From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: 51716@debbugs.gnu.org
Subject: bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history to Lisp code
Date: Wed, 10 Nov 2021 17:25:39 +0200 [thread overview]
Message-ID: <83o86s2ft8.fsf@gnu.org> (raw)
In-Reply-To: <871r3p8r05.fsf@yahoo.com> (bug-gnu-emacs@gnu.org)
> 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@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.
next prev parent reply other threads:[~2021-11-10 15:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <871r3p8r05.fsf.ref@yahoo.com>
2021-11-09 12:15 ` bug#51716: 29.0.50; [PATCH] Expose xwidget navigation history to Lisp code Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-09 13:33 ` Eli Zaretskii
2021-11-09 13:44 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-09 13:58 ` Eli Zaretskii
2021-11-09 14:06 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-09 14:10 ` Eli Zaretskii
2021-11-09 23:57 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-10 15:25 ` Eli Zaretskii [this message]
2021-11-11 1:03 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-13 15:02 ` Eli Zaretskii
2021-11-14 0:18 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-14 6:53 ` Eli Zaretskii
2021-11-14 6:58 ` Lars Ingebrigtsen
2021-11-14 6:59 ` Lars Ingebrigtsen
2021-11-14 7:11 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-14 7:18 ` Lars Ingebrigtsen
2021-11-14 7:20 ` Lars Ingebrigtsen
2021-11-14 7:21 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-14 7:29 ` Eli Zaretskii
2021-11-14 7:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-14 8:04 ` Eli Zaretskii
2021-11-14 9:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-14 7:20 ` Eli Zaretskii
2021-11-14 13:29 ` Po Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83o86s2ft8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=51716@debbugs.gnu.org \
--cc=luangruo@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.