From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#50497: [PATCH] Adding eww-{next,previous,up,top}-path. Date: Mon, 13 Sep 2021 20:51:39 +0300 Organization: LINKOV.NET Message-ID: <87zgsgqsoc.fsf@mail.linkov.net> References: <87lf45xh86.fsf@ypei.me> <87ee9wpt38.fsf@gnus.org> <878s04ijhc.fsf@mail.linkov.net> <87czpfnw4j.fsf@gnus.org> <87pmtfx7fs.fsf@mail.linkov.net> <878s00j416.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28443"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: Yuchen Pei , 50497@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 13 20:00:33 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mPqFt-0007Ao-0L for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Sep 2021 20:00:33 +0200 Original-Received: from localhost ([::1]:58214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mPqFr-0004jN-6V for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Sep 2021 14:00:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mPqFP-0004j5-CE for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2021 14:00:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35225) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mPqFP-00008g-3m for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2021 14:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mPqFP-0005TH-2N for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2021 14:00:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2021 18:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50497 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 50497-submit@debbugs.gnu.org id=B50497.163155599820981 (code B ref 50497); Mon, 13 Sep 2021 18:00:02 +0000 Original-Received: (at 50497) by debbugs.gnu.org; 13 Sep 2021 17:59:58 +0000 Original-Received: from localhost ([127.0.0.1]:46768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPqFK-0005SL-CU for submit@debbugs.gnu.org; Mon, 13 Sep 2021 13:59:58 -0400 Original-Received: from relay11.mail.gandi.net ([217.70.178.231]:36821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPqFI-0005S5-4V for 50497@debbugs.gnu.org; Mon, 13 Sep 2021 13:59:57 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 40B6A10000D; Mon, 13 Sep 2021 17:59:47 +0000 (UTC) In-Reply-To: <878s00j416.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 13 Sep 2021 10:03:33 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214245 Archived-At: >>> That's also true, so I was sceptical about adding that (because it also >>> makes `C-s' etc behave sub-optimally in 99.7% of web pages), so I've >>> been pondering whether to remove it (or at least hide it behind and >>> option defaulting to "off"). >> >> But users like it: >> https://www.reddit.com/r/emacs/comments/9oi1e3/ewws_awesome_isearch_support_just_blew_my_mind/ > > Yeah, it's a neat trick (which makes people go "ooo"). So disabling it > would be a shame. But it does make the user experience slightly worse > most of the time... > > Actually, we could just tweak it -- today it says "repeat for next > buffer" even if there's no next buffer (it only checks afterwards), > apparently. Hm... Right, if eww only sets > `multi-isearch-next-buffer-function' when there's a rel=next/prev, then > this awkwardness disappears. But still I'd like to make `C-s' less sub-optimal when used on pages with a rel=next/prev and to fix such complaints: "It turns out that this interacts badly with asynchronous loading of web pages -- I think the buffer is being searched before the web content is loaded, but with local content it's either all managing to happen fast enough that the issue doesn't arise, or it's being done in a more synchronous manner. Hopefully this can be addressed, but in the meantime you may need to test with local html files." What do you think about supporting synchronous mode in eww? When adding a variable that causes eww-retrieve to use url-retrieve-synchronously, isearch part could look like this: (defun eww-isearch-next-buffer (&optional _buffer wrap) (let ((eww-synchronous t)) (if wrap (condition-case nil (eww-top-url) (error nil)) (if isearch-forward (eww-next-url) (eww-previous-url)))) (current-buffer))