GNU bug report logs - #51716
29.0.50; [PATCH] Expose xwidget navigation history to Lisp code

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51716 in the body.
You can then email your comments to 51716 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] Expose xwidget navigation history to Lisp code
Date: Tue, 09 Nov 2021 20:15:06 +0800

[Message part 1 (text/plain, inline)]

I found it impossible to navigate the history of an Xwidget WebKit
buffer after following about a dozen links, and clicking back several
times.

This should lay the groundwork for a history navigator in Xwidget WebKit
buffers.  I will probably work on that tomorrow.

Thanks.

[0001-Expose-xwidget-navigation-history-to-Lisp-code.patch (text/x-patch, attachment)]

Message #8 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50;
 [PATCH] Expose xwidget navigation history to Lisp code
Date: Tue, 09 Nov 2021 15:33:54 +0200

> Date: Tue, 09 Nov 2021 20:15:06 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I found it impossible to navigate the history of an Xwidget WebKit
> buffer after following about a dozen links, and clicking back several
> times.
> 
> This should lay the groundwork for a history navigator in Xwidget WebKit
> buffers.  I will probably work on that tomorrow.
> 
> Thanks.
> 
> >From d487e2689212d3dab108e043d49a8aa1787a7015 Mon Sep 17 00:00:00 2001
> From: Po Lu <luangruo <at> yahoo.com>
> Date: Tue, 9 Nov 2021 20:11:05 +0800
> Subject: [PATCH] Expose xwidget navigation history to Lisp code
> 
> * doc/lispref/display.texi (Xwidgets): Document changes.
> * etc/NEWS: Announce new function.
> * src/xwidget.c (Fxwidget_webkit_goto_history): Remove obsolete test.
> (Fxwidget_webkit_back_forward_list): New function.
> (syms_of_xwidget): Define new subr.
> ---
>  doc/lispref/display.texi |  26 ++++++++++
>  etc/NEWS                 |   5 ++
>  src/xwidget.c            | 102 +++++++++++++++++++++++++++++++++++++--
>  3 files changed, 130 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
> index 3ccc755391..a953162ae9 100644
> --- a/doc/lispref/display.texi
> +++ b/doc/lispref/display.texi
> @@ -6953,6 +6953,32 @@ Xwidgets
>  @var{base-uri}, which defaults to @samp{about:blank}.
>  @end defun
>  
> +@defun xwidget-webkit-goto-history xwidget rel-pos
> +Make @var{xwidget}, a WebKit widget, load the @code{rel-pos}th element
> +in its navigation history.
> +
> +If @var{rel-pos} is zero, the current page will be reloaded instead.
> +@end defun
> +
> +@defun xwidget-webkit-back-forward-list xwidget &optional limit
> +Return the navigation history of @var{xwidget}, up to @var{limit}
> +items in each direction.  If not specified, @var{limit} defaults to
> +50.
> +
> +The returned value is a list of the form @code{(@var{back} @var{here}
> +@var{forward})}, where @var{here} is the current navigation item,
> +while @var{back} is a list of items containing the history behind the
> +current navigation item, and @var{forward} is a list of items in front
> +of the current navigation item.  @var{back}, @var{here} and
> +@var{forward} can all be @code{nil}.

Before I dive into the code, let me ask: why not use the usual Emacs
history machinery for this?  IOW, have some xwidget-specific history
variable that would store the browsing history, and use that variable
in conjunction with foo-prev and foo-next commands?  Why do we need to
reinvent the wheel for xwidgets, and why do that in C?

Message #11 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Tue, 09 Nov 2021 21:44:47 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Before I dive into the code, let me ask: why not use the usual Emacs
> history machinery for this?  IOW, have some xwidget-specific history
> variable that would store the browsing history, and use that variable
> in conjunction with foo-prev and foo-next commands?  Why do we need to
> reinvent the wheel for xwidgets, and why do that in C?

WebKit stores navigation history specially.  For instance, it implements
a feature where malicious (i.e. looping) redirects are not recorded in
history.  This is not available from Lisp, as the signals exposed by
WebKitGTK are insufficient to keep track of that data.  Further, I think
there is a way for web pages to tell WebKitGTK whether or not to record
themselves in history, which also cannot be implemented separately.

It can only be done from C, because the necessary information is only
available in C.

Message #14 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Tue, 09 Nov 2021 15:58:35 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51716 <at> debbugs.gnu.org
> Date: Tue, 09 Nov 2021 21:44:47 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Before I dive into the code, let me ask: why not use the usual Emacs
> > history machinery for this?  IOW, have some xwidget-specific history
> > variable that would store the browsing history, and use that variable
> > in conjunction with foo-prev and foo-next commands?  Why do we need to
> > reinvent the wheel for xwidgets, and why do that in C?
> 
> WebKit stores navigation history specially.  For instance, it implements
> a feature where malicious (i.e. looping) redirects are not recorded in
> history.  This is not available from Lisp, as the signals exposed by
> WebKitGTK are insufficient to keep track of that data.  Further, I think
> there is a way for web pages to tell WebKitGTK whether or not to record
> themselves in history, which also cannot be implemented separately.
> 
> It can only be done from C, because the necessary information is only
> available in C.

Please give more details, because I still have only a very vague idea
of the problems you mention, and why they absolutely preclude mapping
the browsing history into Lisp.

Message #17 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Tue, 09 Nov 2021 22:06:45 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> WebKit stores navigation history specially.  For instance, it implements
>> a feature where malicious (i.e. looping) redirects are not recorded in
>> history.  This is not available from Lisp, as the signals exposed by
>> WebKitGTK are insufficient to keep track of that data.  Further, I think
>> there is a way for web pages to tell WebKitGTK whether or not to record
>> themselves in history, which also cannot be implemented separately.
>> 
>> It can only be done from C, because the necessary information is only
>> available in C.

> Please give more details, because I still have only a very vague idea
> of the problems you mention, and why they absolutely preclude mapping
> the browsing history into Lisp.

OK, I should clarify: this function provides the data necessary to map
browsing history into Lisp.

One feature I mentioned was that WebKit removes repetitive (usually
malicious) redirects designed to make it impossible to leave a page
through going back in the history.

WebKit only records its canonical page history in the back-forward list
of the WebKitWebView, which can only be obtained with
webkit_web_view_get_back_forward_list, and as such it needs to be
introduced as a primitive.

Thanks.

Message #20 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Tue, 09 Nov 2021 16:10:52 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51716 <at> debbugs.gnu.org
> Date: Tue, 09 Nov 2021 22:06:45 +0800
> 
> OK, I should clarify: this function provides the data necessary to map
> browsing history into Lisp.

Yes, I've seen that.

> One feature I mentioned was that WebKit removes repetitive (usually
> malicious) redirects designed to make it impossible to leave a page
> through going back in the history.

And we cannot detect those repetitive redirects in Lisp?

> WebKit only records its canonical page history in the back-forward list
> of the WebKitWebView, which can only be obtained with
> webkit_web_view_get_back_forward_list, and as such it needs to be
> introduced as a primitive.

So you must rely on WebKit for producing the history?

But once the history is produced/updated, can it be treated as any
other history variable in Emacs?

Message #23 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Wed, 10 Nov 2021 07:57:26 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> And we cannot detect those repetitive redirects in Lisp?

Yes, and there are various other shenanigans that vary by system
configuration, WebKit configuration, WebKit version, security policy and
such that are impractical to keep track of.  I can't give a concrete
list though.

> So you must rely on WebKit for producing the history?

Yes.

> But once the history is produced/updated, can it be treated as any
> other history variable in Emacs?

Also correct, thanks.

Message #28 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50;
 [PATCH] Expose xwidget navigation history to Lisp code
Date: Wed, 10 Nov 2021 17:25:39 +0200

> Date: Tue, 09 Nov 2021 20:15:06 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> +@defun xwidget-webkit-goto-history xwidget rel-pos
> +Make @var{xwidget}, a WebKit widget, load the @code{rel-pos}th element
                                                 ^^^^^
This should be @var, not @code.

> +in its navigation history.
> +
> +If @var{rel-pos} is zero, the current page will be reloaded instead.
> +@end defun
> +
> +@defun xwidget-webkit-back-forward-list xwidget &optional limit

Hmm... given that we have xwidget-webkit-goto-history, why do we need
this new function as well?  Or why do we need both?

> +The returned value is a list of the form @code{(@var{back} @var{here}
> +@var{forward})}

This list should be wrapped in @w{..}, so that it is kept unbroken
between 2 lines.

> where @var{here} is the current navigation item,
> +while @var{back} is a list of items containing the history behind the
> +current navigation item, and @var{forward} is a list of items in front
> +of the current navigation item.

The notions of "behind" and "in front" are not well-defined in this
context.  The text should make more clear what does each one of those
mean.

>                                  @var{back}, @var{here} and
> +@var{forward} can all be @code{nil}.

What is the meaning of each one being nil?  The text leaves that
unsaid.

> +Navigation items are themselves lists of the form @code{(@var{idx}
> +@var{title} @var{uri})}.

Please use @w{..} here as well.  basically you should use it for any
form that has embedded whitespace, and can therefore be split between
two lines when Texinfo fills and justifies the text.

>                           In these lists, @var{idx} is an index that
> +can be passed to @code{xwidget-webkit-goto-history}, @var{title} is
> +the human-readable title of the item, and @var{uri} is the URI of the
> +item.

URI, not URL?

> +DEFUN ("xwidget-webkit-back-forward-list", Fxwidget_webkit_back_forward_list,
> +       Sxwidget_webkit_back_forward_list, 1, 2, 0,
> +       doc: /* Return the navigation history of XWIDGET, a WebKit xwidget.
> +
> +The history is returned as a list of the form (BACK HERE FORWARD),
   ^^^^^^^^^^^^^^^^^^^^^^^
Passive tense alert!

> +where HERE is the current navigation item, while BACK and FORWARD are
> +lists of navigation items, which are lists of the form (IDX TITLE

"lists of ... , which are lists" uses "lists" twice, which is
redundant.  Better say

   ... are lists of elements of the form (IDX TITLE URI) ...

> +               The user should normally have no reason to load URI
> +manually to reach a specific history item.  Instead, he should pass
> +IDX as an index to `xwidget-webkit-goto-history'.

This belongs to the manual, not a doc string.  (And try to rephrase to
avoid using "he".)

> +BACK and FORWARD will not contain more elements than LIMIT.

Each one or both together? the text is ambiguous about that.

> +#ifdef USE_GTK
> +  webview = WEBKIT_WEB_VIEW (xw->widget_osr);

I guess this again means this function is a no-op without GTK?  Then
let's not define it except in the GTK build.

> +  list = webkit_web_view_get_back_forward_list (webview);
> +  item = webkit_back_forward_list_get_current_item (list);
> +  lim = XFIXNAT (limit);
> +
> +  if (item)
> +    {
> +      item_title = webkit_back_forward_list_item_get_title (item);
> +      item_uri = webkit_back_forward_list_item_get_uri (item);
> +      here = list3 (make_fixnum (0),
> +		    build_string (item_title ? item_title : ""),
> +		    build_string (item_uri ? item_uri : ""));
> +    }
> +  parent = webkit_back_forward_list_get_back_list_with_limit (list, lim);
> +
> +  if (parent)
> +    {
> +      for (i = 1, tem = parent; parent; parent = parent->next, ++i)
> +	{
> +	  item = tem->data;
> +	  item_title = webkit_back_forward_list_item_get_title (item);
> +	  item_uri = webkit_back_forward_list_item_get_uri (item);
> +	  title = build_string (item_title ? item_title : "");
> +	  uri = build_string (item_uri ? item_uri : "");

build_string can produce either multibyte or unibyte strings.  Which
ones do we want?  And shouldn't we decode the strings that come from
WebKit?

> +	  back = Fcons (list3 (make_fixnum (-i), title, uri), back);
> +	}
> +    }
> +
> +  g_list_free (parent);
> +
> +  parent = webkit_back_forward_list_get_forward_list_with_limit (list, lim);
> +
> +  if (parent)
> +    {
> +      for (i = 1, tem = parent; parent; parent = parent->next, ++i)
> +	{
> +	  item = tem->data;
> +	  item_title = webkit_back_forward_list_item_get_title (item);
> +	  item_uri = webkit_back_forward_list_item_get_uri (item);
> +	  title = build_string (item_title ? item_title : "");
> +	  uri = build_string (item_uri ? item_uri : "");
> +	  forward = Fcons (list3 (make_fixnum (i), title, uri), forward);
> +	}

This generates the lists in the reverse order, doesn't it?

Thanks.

Message #31 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Thu, 11 Nov 2021 09:03:19 +0800

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> This should be @var, not @code.

>> +in its navigation history.
>> +
>> +If @var{rel-pos} is zero, the current page will be reloaded instead.
>> +@end defun
>> +
>> +@defun xwidget-webkit-back-forward-list xwidget &optional limit
>
> Hmm... given that we have xwidget-webkit-goto-history, why do we need
> this new function as well?  Or why do we need both?

`xwidget-webkit-goto-history' only lets you navigate to a history index:
it doesn't tell you what that index actually is, or indeed, if it even
exists at all.

>> +The returned value is a list of the form @code{(@var{back} @var{here}
>> +@var{forward})}

> This list should be wrapped in @w{..}, so that it is kept unbroken
> between 2 lines.

Thanks.

>> where @var{here} is the current navigation item,
>> +while @var{back} is a list of items containing the history behind the
>> +current navigation item, and @var{forward} is a list of items in front
>> +of the current navigation item.
>
> The notions of "behind" and "in front" are not well-defined in this
> context.  The text should make more clear what does each one of those
> mean.

I tried to clarify, thanks.

>>                                  @var{back}, @var{here} and
>> +@var{forward} can all be @code{nil}.

> What is the meaning of each one being nil?  The text leaves that
> unsaid.

BACK being nil means that we are at the beginning of the history.
FORWARD being nil means that there is nothing after the current place in
history.  HERE being nil means that WebKit hasn't recorded any pages in
history yet.

I will add that to the documentation, thanks.

> Please use @w{..} here as well.  basically you should use it for any
> form that has embedded whitespace, and can therefore be split between
> two lines when Texinfo fills and justifies the text.

Done, thanks.

>>                           In these lists, @var{idx} is an index that
>> +can be passed to @code{xwidget-webkit-goto-history}, @var{title} is
>> +the human-readable title of the item, and @var{uri} is the URI of the
>> +item.

> URI, not URL?

Yes, as WebKit allows any URI to appear in history items.

>> +DEFUN ("xwidget-webkit-back-forward-list", Fxwidget_webkit_back_forward_list,
>> +       Sxwidget_webkit_back_forward_list, 1, 2, 0,
>> +       doc: /* Return the navigation history of XWIDGET, a WebKit xwidget.
>> +
>> +The history is returned as a list of the form (BACK HERE FORWARD),
>    ^^^^^^^^^^^^^^^^^^^^^^^
> Passive tense alert!

[...]

> "lists of ... , which are lists" uses "lists" twice, which is
> redundant.  Better say
>
>    ... are lists of elements of the form (IDX TITLE URI) ...

Thanks, I fixed.

> This belongs to the manual, not a doc string.

Thanks, I moved it there.

> Each one or both together? the text is ambiguous about that.

I tried to fix that, please check.  Thanks.

>> +#ifdef USE_GTK
>> +  webview = WEBKIT_WEB_VIEW (xw->widget_osr);
>
> I guess this again means this function is a no-op without GTK?  Then
> let's not define it except in the GTK build.

Done, thanks.

>> +  list = webkit_web_view_get_back_forward_list (webview);
>> +  item = webkit_back_forward_list_get_current_item (list);
>> +  lim = XFIXNAT (limit);
>> +
>> +  if (item)
>> +    {
>> +      item_title = webkit_back_forward_list_item_get_title (item);
>> +      item_uri = webkit_back_forward_list_item_get_uri (item);
>> +      here = list3 (make_fixnum (0),
>> +		    build_string (item_title ? item_title : ""),
>> +		    build_string (item_uri ? item_uri : ""));
>> +    }
>> +  parent = webkit_back_forward_list_get_back_list_with_limit (list, lim);
>> +
>> +  if (parent)
>> +    {
>> +      for (i = 1, tem = parent; parent; parent = parent->next, ++i)
>> +	{
>> +	  item = tem->data;
>> +	  item_title = webkit_back_forward_list_item_get_title (item);
>> +	  item_uri = webkit_back_forward_list_item_get_uri (item);
>> +	  title = build_string (item_title ? item_title : "");
>> +	  uri = build_string (item_uri ? item_uri : "");

> build_string can produce either multibyte or unibyte strings.  Which
> ones do we want?  And shouldn't we decode the strings that come from
> WebKit?

Sorry for that. We want UTF-8 strings, as that's the format of strings
which come from WebKitGTK.  (And most GLib-related software, as well).

>> +	  back = Fcons (list3 (make_fixnum (-i), title, uri), back);
>> +	}
>> +    }
>> +
>> +  g_list_free (parent);
>> +
>> +  parent = webkit_back_forward_list_get_forward_list_with_limit (list, lim);
>> +
>> +  if (parent)
>> +    {
>> +      for (i = 1, tem = parent; parent; parent = parent->next, ++i)
>> +	{
>> +	  item = tem->data;
>> +	  item_title = webkit_back_forward_list_item_get_title (item);
>> +	  item_uri = webkit_back_forward_list_item_get_uri (item);
>> +	  title = build_string (item_title ? item_title : "");
>> +	  uri = build_string (item_uri ? item_uri : "");
>> +	  forward = Fcons (list3 (make_fixnum (i), title, uri), forward);
>> +	}

> This generates the lists in the reverse order, doesn't it?

Yes, but what's important here is the index `i', not the order of the
list.  But I agree that it would be OK to nreverse the contents of that
list.

[0001-Expose-xwidget-navigation-history-to-Lisp-code.patch (text/x-patch, attachment)]

Message #34 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sat, 13 Nov 2021 17:02:13 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51716 <at> debbugs.gnu.org
> Date: Thu, 11 Nov 2021 09:03:19 +0800
> 
> >> +  if (item)
> >> +    {
> >> +      item_title = webkit_back_forward_list_item_get_title (item);
> >> +      item_uri = webkit_back_forward_list_item_get_uri (item);
> >> +      here = list3 (make_fixnum (0),
> >> +		    build_string (item_title ? item_title : ""),
> >> +		    build_string (item_uri ? item_uri : ""));
> >> +    }
> >> +  parent = webkit_back_forward_list_get_back_list_with_limit (list, lim);
> >> +
> >> +  if (parent)
> >> +    {
> >> +      for (i = 1, tem = parent; parent; parent = parent->next, ++i)
> >> +	{
> >> +	  item = tem->data;
> >> +	  item_title = webkit_back_forward_list_item_get_title (item);
> >> +	  item_uri = webkit_back_forward_list_item_get_uri (item);
> >> +	  title = build_string (item_title ? item_title : "");
> >> +	  uri = build_string (item_uri ? item_uri : "");
> 
> > build_string can produce either multibyte or unibyte strings.  Which
> > ones do we want?  And shouldn't we decode the strings that come from
> > WebKit?
> 
> Sorry for that. We want UTF-8 strings, as that's the format of strings
> which come from WebKitGTK.  (And most GLib-related software, as well).

Sorry, I don't understand: the above produces strings that will be
used by Emacs Lisp.  So UTF-8 is not relevant; the question is whether
the string that comes from WebKitGTK can include non-ASCII characters.
If it can, we need to decode it, e.g. by decode_string_utf_8 (can
these strings include byte sequences that aren't valid UTF-8?).

When this issue is resolved, the changes can be installed.

Thanks.

Message #37 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 08:18:39 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Sorry, I don't understand: the above produces strings that will be
> used by Emacs Lisp.  So UTF-8 is not relevant; the question is whether
> the string that comes from WebKitGTK can include non-ASCII characters.
> If it can, we need to decode it, e.g. by decode_string_utf_8 (can
> these strings include byte sequences that aren't valid UTF-8?).

Ah, they cannot include byte sequences that aren't valid UTF-8.  Do you
see any further problem?  If not, I will install it with minor changes
(replacing CHECK_XWIDGET with CHECK_LIVE_XWIDGET).

Thanks.

Message #40 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 08:53:44 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51716 <at> debbugs.gnu.org
> Date: Sun, 14 Nov 2021 08:18:39 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Sorry, I don't understand: the above produces strings that will be
> > used by Emacs Lisp.  So UTF-8 is not relevant; the question is whether
> > the string that comes from WebKitGTK can include non-ASCII characters.
> > If it can, we need to decode it, e.g. by decode_string_utf_8 (can
> > these strings include byte sequences that aren't valid UTF-8?).
> 
> Ah, they cannot include byte sequences that aren't valid UTF-8.

If they cannot include invalid UTF-8, then using decode_string_utf_8
is what you need to do.  You cannot use those strings directly in
Lisp, because they will be unibyte strings.  IOW, using build_string
there is incorrect, you need to use make_unibyte_string and
decode_string_utf_8 instead.  build_string is correct only for
plain-ASCII strings.

Message #43 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 07:58:11 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> If they cannot include invalid UTF-8, then using decode_string_utf_8
> is what you need to do.  You cannot use those strings directly in
> Lisp, because they will be unibyte strings.  IOW, using build_string
> there is incorrect, you need to use make_unibyte_string and
> decode_string_utf_8 instead.  build_string is correct only for
> plain-ASCII strings.

Can't he use make_multibyte_string instead?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #46 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 07:59:15 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Can't he use make_multibyte_string instead?

Never mind -- the interface probably doesn't say how many characters
there are in the string, only how many bytes.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #49 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 15:11:30 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Can't he use make_multibyte_string instead?
>
> Never mind -- the interface probably doesn't say how many characters
> there are in the string, only how many bytes.

What about `build_string_from_utf8'?  It seems to call
`make_string_from_utf8' with the length of the string in bytes, which
should be correct.

Message #52 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 08:18:39 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> What about `build_string_from_utf8'?  It seems to call
> `make_string_from_utf8' with the length of the string in bytes, which
> should be correct.

Yes, that looks like the function to use (and basically does what Eli
said, but with extra sanity checks, if I'm reading it correctly).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #55 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: luangruo <at> yahoo.com, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 09:20:01 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Po Lu <luangruo <at> yahoo.com>,  51716 <at> debbugs.gnu.org
> Date: Sun, 14 Nov 2021 07:58:11 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If they cannot include invalid UTF-8, then using decode_string_utf_8
> > is what you need to do.  You cannot use those strings directly in
> > Lisp, because they will be unibyte strings.  IOW, using build_string
> > there is incorrect, you need to use make_unibyte_string and
> > decode_string_utf_8 instead.  build_string is correct only for
> > plain-ASCII strings.
> 
> Can't he use make_multibyte_string instead?

I'd rather not.  Code which uses external strings without decoding
looks wrong, and the time it takes to convince yourself it does TRT
(if it does) is time lost.

decode_string_utf_8 is very fast, and xwidgets aren't supposed to be
in the inner loops of Emacs.  So I see no reason for shortcuts here.

Message #58 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 08:20:19 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Yes, that looks like the function to use (and basically does what Eli
> said, but with extra sanity checks, if I'm reading it correctly).

(And I didn't, because the checks are #if 0-ed.  😀)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #61 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 15:21:26 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Yes, that looks like the function to use (and basically does what Eli
> said, but with extra sanity checks, if I'm reading it correctly).

Thanks, if Eli thinks that's fine, then I will push the change with the
adjustments pointed out here made.

Message #64 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: larsi <at> gnus.org, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 09:29:09 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  51716 <at> debbugs.gnu.org
> Date: Sun, 14 Nov 2021 15:11:30 +0800
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> >
> >> Can't he use make_multibyte_string instead?
> >
> > Never mind -- the interface probably doesn't say how many characters
> > there are in the string, only how many bytes.
> 
> What about `build_string_from_utf8'?  It seems to call
> `make_string_from_utf8' with the length of the string in bytes, which
> should be correct.

You want to save the explicit call to strlen (otherwise there's no
difference between my suggestion and build_string_from_utf8)?  Sure,
but that's not the important point I was trying to make.

Message #67 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 15:33:01 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> You want to save the explicit call to strlen (otherwise there's no
> difference between my suggestion and build_string_from_utf8)?  Sure,
> but that's not the important point I was trying to make.

Yes, I understood your point.  I'll switch the calls to use
`build_string_from_utf8' and install the change, if that's fine with
you.

Thanks a lot!

Message #70 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: larsi <at> gnus.org, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 10:04:33 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: larsi <at> gnus.org,  51716 <at> debbugs.gnu.org
> Date: Sun, 14 Nov 2021 15:33:01 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > You want to save the explicit call to strlen (otherwise there's no
> > difference between my suggestion and build_string_from_utf8)?  Sure,
> > but that's not the important point I was trying to make.
> 
> Yes, I understood your point.  I'll switch the calls to use
> `build_string_from_utf8' and install the change, if that's fine with
> you.

Yes, I said that decoding was the last issue I had with the patch.

Message #73 received at 51716 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 51716 <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 17:45:42 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: larsi <at> gnus.org,  51716 <at> debbugs.gnu.org
>> Date: Sun, 14 Nov 2021 15:33:01 +0800
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > You want to save the explicit call to strlen (otherwise there's no
>> > difference between my suggestion and build_string_from_utf8)?  Sure,
>> > but that's not the important point I was trying to make.
>> 
>> Yes, I understood your point.  I'll switch the calls to use
>> `build_string_from_utf8' and install the change, if that's fine with
>> you.
>
> Yes, I said that decoding was the last issue I had with the patch.

Thanks, pushed.

Message #78 received at 51716-done <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: 51716-done <at> debbugs.gnu.org
Subject: Re: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history
 to Lisp code
Date: Sun, 14 Nov 2021 21:29:12 +0800

Forgot to close the issue, so here it is.
Sorry.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.