From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#34374: 27.0.50; Outside an eww buffer, optionally use new buffer when calling eww instead of reusing *eww* Date: Fri, 08 Feb 2019 08:52:28 +0200 Message-ID: <83lg2qrcur.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88611"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 34374@debbugs.gnu.org To: =?UTF-8?Q?G=C3=B6ktu=C4=9F?= Kayaalp Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 08 07:53:15 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gs02D-000MpO-Nx for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Feb 2019 07:53:13 +0100 Original-Received: from localhost ([127.0.0.1]:52122 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gs02C-0001z9-GP for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Feb 2019 01:53:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gs026-0001yz-8B for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2019 01:53:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gs024-00089w-0w for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2019 01:53:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39542) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gs022-00089D-Hj for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2019 01:53:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gs022-0002EI-BA for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2019 01:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Feb 2019 06:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34374 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 34374-submit@debbugs.gnu.org id=B34374.15496087598533 (code B ref 34374); Fri, 08 Feb 2019 06:53:02 +0000 Original-Received: (at 34374) by debbugs.gnu.org; 8 Feb 2019 06:52:39 +0000 Original-Received: from localhost ([127.0.0.1]:38823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gs01e-0002DY-MN for submit@debbugs.gnu.org; Fri, 08 Feb 2019 01:52:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gs01d-0002DL-9n for 34374@debbugs.gnu.org; Fri, 08 Feb 2019 01:52:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gs01X-0007o5-C0; Fri, 08 Feb 2019 01:52:31 -0500 Original-Received: from [176.228.60.248] (port=3437 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gs01X-0000im-08; Fri, 08 Feb 2019 01:52:31 -0500 In-reply-to: (message from =?UTF-8?Q?G=C3=B6ktu=C4=9F?= Kayaalp on Fri, 08 Feb 2019 00:19:36 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:155245 Archived-At: > From: Göktuğ Kayaalp > Date: Fri, 08 Feb 2019 00:19:36 +0300 > > Eww should support conveniently avoiding using the same buffer even when > not in an eww buffer (M-x eww or browse-url). Currently, in an eww > buffer, ‘eww-open-in-new-buffer’ opens the link under point in a new > buffer, and ‘eww’ reuses the buffer. When running ‘eww’ outside an eww > buffer, it reuses the ‘*eww*’ buffer. Attached is a patch where by > default this behaviour is retained, but when a new custom, > ‘eww-reuse-buffer’ is truthy (defaults to nil), Eww uses a new buffer > (obtained via ‘generate-new-buffer’) instead, unless the current buffer > is an eww buffer. The navigation behaviour in eww buffers is retained. Wouldn't it be more convenient if you could invoke eww with a prefix argument for that? > I have manually tested the general use of EWW with this patch applied. > But I haven’t found a test suite for EWW; if I missed it, I can run it, > or any other suggested testing. You could start a test suite, although testing eww should ideally work even if no network connection is available. > Subject: [PATCH] Support not reusing *eww* buffer when navigating from a > non-eww one It is best to reword this header line to be positive instead of negative. > +(defcustom eww-reuse-buffer t > + "Reuse the *eww* buffer when not in an `eww-mode' buffer." For a boolean option, the first line of the doc string should say either Non-nil means reuse the *eww* buffer ... or Whether to reuse the *eww* buffer ... (the former is preferable). > +When the current buffer is not in `eww-mode', if > +`eww-reuse-buffer' is non-nil, the *eww* buffer will be reused if > +available, otherwise generated; if set to nil instead, a new > +buffer will be used in case *eww* is already in use." Once this feature exists and is used, wouldn't it be better to program it so it either reuses the current EWW buffer or creates a new one, regardless of whether the current buffer's name is "*eww*"? IOW, should we really hardcode "*eww*" in this feature? > - (get-buffer-create "*eww*"))) > + (funcall > + (if eww-reuse-buffer #'get-buffer-create #'generate-new-buffer) > + "*eww*"))) Any particular reason to use funcall here, instead of calling the functions literally? Thanks.