help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practic


From: Ludwig, Mark
Subject: RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)
Date: Thu, 27 Jun 2013 15:34:37 +0000

> From: Juanma Barranquero, Thursday, June 27, 2013 9:52 AM
> 
> On Thu, Jun 27, 2013 at 4:28 PM, Ludwig, Mark <ludwig.mark@siemens.com>
> wrote:
> 
> > I don't agree.  Why is it useful to make the user click OK (the only
> > available button) /before/ launching the alternate editor?
> 
> Because if we don't say anything, the user won't be aware that there's
> a problem. 

I am not saying that emacsclientw should not to say anything.  :-)  

I am saying that it should not wait for me to click OK before
proceeding to launch the alternate editor (if any).

Consider that the non-windows version (emacsclient) does just this.
It will issue the error message to the console and, since it's
non-interactive, it will proceed to launch the alternate editor (if
any).

> > Let's say you're correct that there is a running Emacs that's not
> > responding, so the dialog information is reporting an "interesting"
> > situation.  I claim that it /still/ doesn't matter, because
> > emacsclientw has made its only attempt to connect to the
> > supposedly-running server (which failed) and all the user can do is
> > click OK, after which emacsclientw will launch the alternate editor
> > (if any).  If there were a "Retry" button, that would be /very/different.
> 
> I didn't say that Emacs is not responding, I said that Emacs is not
> responding to server requests. Perhaps you inadvertedly deactivated
> the server mode, and jus M-x server-mode <RET> will activate it again
> without having to exit and reload Emacs. If that seems far-fetched to
> you, well, it's happened to me more times that I could count.

Sure, and I claim that this does still not change the uselessness of
waiting for the user to click OK before launching the alternate
editor.  Let's say you're correct that somehow the server was
deactivated, and all you need to do is reactivate it.  Nothing you do
in response to the dialog changes what will happen with that instance
of emacsclientw.  If you have an alternate editor, it gets launched
(unless you take the extraordinary steps necessary to kill the
emacsclientw process while the dialog is sitting there).  If you don't
have an alternate editor, you have to perform the action again after
fixing the Emacs server.

I certainly understand that my perspective is based on the fact that I
use alternate editor, but I didn't invent the concept; I'm just trying
to use it.

Thanks,
Mark


reply via email to

[Prev in Thread] Current Thread [Next in Thread]