bug#19109: eww-setup-buffer: use set-buffer instead of switch-to-buffer

bug#19109: eww-setup-buffer: use set-buffer instead of switch-to-buffer

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

Package:  emacs
Severity: wishlist
X-Debbugs-Cc: emacs-devel@gnu.org

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >> It’s also perfectly possible to create that buffer but do /not/
 >> switch to it until it’s ready.  It won’t help in the scenario being
 >> discussed, but to be honest, EWW already pops its buffers way to
 >> often to my taste.

 >> Consider, for instance, invoking eww-reload in a handful of buffers
 >> in a row, – EWW will switch to each of these buffers as soon as
 >> one’s done, which could very well happen in the middle of user
 >> interaction with some specific buffer.

 > I think this is a case of "don't do that, then".

	Yes.  And that means that eww-reload is essentially synchronous,
	– you can’t really invoke it and switch to doing some other
	thing; you have to wait until it completes.

 > Granted, it’s possible to switch to a EWW buffer, invoke eww-reload,
 > wait for it to complete, and only /then/ go to some other buffer
 > (whether EWW or not), but that kind of spoils the benefits of
 > asynchronous url-retrieve operation, doesn’t it?

	Personally, I just use the patch MIMEd, which makes EWW forget
	about its indiscreet habit of interrupting my activity.

	FWIW, ERC provides support for several possible behaviors when a
	new buffer gets created (see erc-join-buffer), and perhaps EWW
	should follow the suit.  OTOH, I fail to readily recall an Emacs
	package which would use switch-to-buffer on a priorly existing
	buffer as part of some background task.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 256 bytes --]

--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -419,7 +419,7 @@
   (goto-char (point-min)))
 
 (defun eww-setup-buffer (&optional buffer)
-  (switch-to-buffer
+  (set-buffer
    (if (buffer-live-p buffer)
        buffer
      (get-buffer-create "*eww*")))

bug#19109: eww-setup-buffer: use set-buffer instead of switch-to-buffer

[Lars Magne Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

>  > I think this is a case of "don't do that, then".
>
> 	Yes.  And that means that eww-reload is essentially synchronous,
> 	– you can’t really invoke it and switch to doing some other
> 	thing; you have to wait until it completes.

You have a very singular usage pattern.  The normal usage pattern is to
have a single *eww* buffer.  If you want a different pattern, and then
you go around asking Emacs to reload all the buffers, and you are then
not happy about how that works for you, then --

Closing.

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

bug#19109: eww-setup-buffer: use set-buffer instead of switch-to-buffer

[Ivan Shmakov]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >>> I think this is a case of "don't do that, then".

 >> Yes.  And that means that eww-reload is essentially synchronous, –
 >> you can’t really invoke it and switch to doing some other thing; you
 >> have to wait until it completes.

 > You have a very singular usage pattern.  The normal usage pattern is
 > to have a single *eww* buffer.

	This statement is untrue in two respects:

	• the current eww-setup-buffer behavior also affects the “single
	  *eww* buffer” case;

	• I’ve seen questions regarding multi-buffer EWW usage on IRC as
	  soon as 24.4 got released; presumably, this means that there
	  /are/ EWW users that are interested in this usage pattern.

	Besides, there’re many more Emacs users which use other browsers
	in either multi-window or multi-tab configuration.  I do not
	believe they will just happily forget about their long-time
	preferences when considering switching to EWW.

 > If you want a different pattern, and then you go around asking Emacs
 > to reload all the buffers, and you are then not happy about how that
 > works for you, then --

 > Closing.

	Objection.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19109: EWW buffers

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

 >> It’s also perfectly possible to create that buffer but do /not/
 >> switch to it until it’s ready.

 > Actually changing the displayed buffer from a process filter
 > (i. e. asynchronously) is a bad idea, just like prompting the user.

	Yet, this is exactly what EWW currently does.  Specifically,
	eww-setup-buffer is called asynchronously when the download
	completes (from the eww-display- functions, which in turn get
	called from eww-render, which is used as the ‘url-retrieve’
	callback by EWW), /and/ eww-setup-buffer uses switch-to-buffer.

	I have filed a bug (#19109) for the issue, which was promptly
	tagged ‘notabug’ and closed.  Could someone please check if it
	really is a proper resolution?

	Personally, I’ve replaced switch-to-buffer there with
	set-buffer, and use that for I guess around a year now, –
	without any apparent issues.

 > So yes, the *eww* buffer should be created and displayed right away
 > (empty at first).  Iceweasel does the same, FWIW, so I don't think
 > it's a problem.

	(Neither do I.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19109: eww.el: do not switch buffers asynchronously

[Ivan Shmakov]

title 19109 eww.el: do not switch buffers asynchronously 
tags  19109 - notabug
fixed 19109 25.1
thanks

	As of 2c783bb66163, I could no longer reproduce this issue.
	Apparently, it was fixed with the following commit.

commit 6fd82d61a2b82e772e8cde0e04516f5c3ca98ed3
Author:     Lars Magne Ingebrigtsen <larsi@gnus.org>
AuthorDate: Sun Nov 23 17:22:41 2014 +0100
Commit:     Lars Magne Ingebrigtsen <larsi@gnus.org>
CommitDate: Sun Nov 23 17:22:41 2014 +0100

    Switch to the *eww* buffer immediately to avoid doing it asynchronously
    
    (eww): Pop to the *eww* buffer immediately after executing the
    `M-x eww' command to avoid having buffers pop up later.
    (eww-display-html): Don't pop the *eww* buffer.
    (eww-display-raw): Ditto.
    (eww-display-image): Ditto.

	Thanks again for taking care of this one.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19109: eww.el: do not switch buffers asynchronously

[Glenn Morris]

I suggust not setting Reply-to <bug-address> when you mail the control
server, else the bug tracker tries to mail itself. Such messages are
auto-discarded by Mailman, but it still seems like a bad idea to me.

bug#19109: mailing control@, but requesting that no replies be sent there

[Ivan Shmakov]

>>>>> Glenn Morris <rgm@gnu.org> writes:

	[Please drop Cc: 19109@debbugs.gnu.org when replying, unless the
	reply is specific to that bug report.]

 > I suggest not setting Reply-to <bug-address> when you mail the
 > control server, else the bug tracker tries to mail itself.  Such
 > messages are auto-discarded by Mailman, but it still seems like a bad
 > idea to me.

	Agreed.

	Curiously, what’s the proper way to prevent (wide) replies to my
	messages from having Cc: control@ by default?  (Other than
	requesting just that in plain English at the top of the
	message’s body, that is.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19109: mailing control@, but requesting that no replies be sent there

[Stephen J. Turnbull]

Ivan Shmakov writes:

 > 	Curiously, what’s the proper way to prevent (wide) replies to my
 > 	messages from having Cc: control@ by default?  (Other than
 > 	requesting just that in plain English at the top of the
 > 	message’s body, that is.)

You might be able to Bcc control, which is probably best.  However
control (or the MTA in front of it) may insist that it be in the
explicit addressees.

Otherwise, it's not possible for you to control this.