bug#23840: runemacs does not seem to pass command line arguments through to emacs properly

bug#23840: runemacs does not seem to pass command line arguments through to emacs properly

[Eliot Moss]

I use a Thunderbird add-on called "External Editor", that will invoke an
arbitrary editor program, passing on the command line the name of a file
to edit.  If I tell External Editor to use runemacs, the file is not
opened, and any underscores in the file name appear as spaces in the name
of the buffer.  I can ^X^F to the actual file, so the file is there, but
something in the runemacs->emacs transition seems to have converted
underscore to space in the file name.

OTOH, if I tell External Editor to use emacs instead of runemacs, the
proper file is opened but I get an annoying console window, too.

I've not been able to find any documentation on runemacs's command line
arguments, etc.  This suggests that it is intended to simply pass them
on unchanged emacs.  But something work than that seems to be happening.

Regards -- Eliot Moss
(Note: I am not subscribed to the list.)

(PS: I used to use Xemacs for this, but it is moribund and with Windows
10 exiting it causes Windows to think that it has crashed, popping up
two annoying windows that you have to dismiss to get back to Thunderbird.)

bug#23840: runemacs does not seem to pass command line arguments through to emacs properly

[Eli Zaretskii]

> From: Eliot Moss <moss@cs.umass.edu>
> Date: Fri, 24 Jun 2016 10:57:16 -0400
> 
> I use a Thunderbird add-on called "External Editor", that will invoke an
> arbitrary editor program, passing on the command line the name of a file
> to edit.  If I tell External Editor to use runemacs, the file is not
> opened, and any underscores in the file name appear as spaces in the name
> of the buffer.  I can ^X^F to the actual file, so the file is there, but
> something in the runemacs->emacs transition seems to have converted
> underscore to space in the file name.

Don't use runemacs, use emacsclientw.exe, which is part of the Emacs
package on Windows.  And have Emacs run in advance, so that you won't
need to start a new session each time.

bug#23840: runemacs does not seem to pass command line arguments through to emacs properly

[Eli Zaretskii]

[Please keep the bug address on the CC list, so that the discussion is
recorded by the Emacs bug tracker.]

> From: Eliot Moss <moss@cs.umass.edu>
> Date: Fri, 24 Jun 2016 16:01:08 -0400
> 
> On 6/24/2016 3:02 PM, Eli Zaretskii wrote:
> >> From: Eliot Moss <moss@cs.umass.edu>
> >> Date: Fri, 24 Jun 2016 10:57:16 -0400
> >>
> >> I use a Thunderbird add-on called "External Editor", that will invoke an
> >> arbitrary editor program, passing on the command line the name of a file
> >> to edit.  If I tell External Editor to use runemacs, the file is not
> >> opened, and any underscores in the file name appear as spaces in the name
> >> of the buffer.  I can ^X^F to the actual file, so the file is there, but
> >> something in the runemacs->emacs transition seems to have converted
> >> underscore to space in the file name.
> >
> > Don't use runemacs, use emacsclientw.exe, which is part of the Emacs
> > package on Windows.  And have Emacs run in advance, so that you won't
> > need to start a new session each time.
> 
> I get what you're saying, but I use this only for pop-up editing of emails,
> which I need to have work when cygwin is not running.  Most of the time
> I use an X version of emacs within cygwin, so I don't want a second emacs
> server floating around.

The X version comes with emacsclient as well.

> These pop-up editors I use only occasionally with
> Thunderbird and Firefox, when editing an email or text entry gets long
> (like a conference paper review).  Given the light usage, starting a new
> session is not an issue for me.
> 
> But don't you agree that the behavior of runemacs here is odd?

There's nothing wrong with runemacs, it does work as you expect.  I
don't have Thunderbird installed, but I just set EDITOR in the
environment to point to runemacs.exe, started Less browsing a file,
typed 'v' there, which is supposed to invoke $EDITOR, and sure thing,
a fresh Emacs session was started with point on the line where I was
reading in Less.  I also see that Less invoked this command:

  !\path\to\runemacs.exe -Q +29 README

which is exactly as I'd expect (the -Q part comes from the value of
EDITOR I set up, and the +29 part is produced by Less).

So if this doesn't work for you, there's some other factor at work,
because runemacs does pass the arguments to emacs.exe.  For starters,
how exactly did you set up Thunderbird to invoke runemacs?

bug#23840: runemacs does not seem to pass command line arguments through to emacs properly

[Eliot Moss]

On 6/25/2016 2:59 AM, Eli Zaretskii wrote:
> [Please keep the bug address on the CC list, so that the discussion is
> recorded by the Emacs bug tracker.]

Thanks for pointing that out.

>>
>> I get what you're saying, but I use this only for pop-up editing of emails,
>> which I need to have work when cygwin is not running.  Most of the time
>> I use an X version of emacs within cygwin, so I don't want a second emacs
>> server floating around.
>
> The X version comes with emacsclient as well.

That may be, but I need this to work when cygwin is not running.  When cygwin
is not running, I don't have X available (unless I do a whole second setup of
X, only for this use - I'm not inclined to do that).

> There's nothing wrong with runemacs, it does work as you expect.  I
> don't have Thunderbird installed, but I just set EDITOR in the
> environment to point to runemacs.exe, started Less browsing a file,
> typed 'v' there, which is supposed to invoke $EDITOR, and sure thing,
> a fresh Emacs session was started with point on the line where I was
> reading in Less.  I also see that Less invoked this command:

In the External Editor add-on, if I set the text editor to be:

"C:\Program Files\Emacs\bin\emacs.exe" --no-splash --file

then things work, though I get the annoying console window.

If I use this:

"C:\Program Files\Emacs\bin\runemacs.exe" --no-splash --file

then emacs pops up, but says the email message is a new file.

However, I think we're making progress on diagnosing this.  When I
looked very closely at the mode line in emacs, I could see the underscores
were actually there.  The two cases start up pointing to the same file
name in the same folder.  In the runemacs case, however, the file is
not present by the time emacs pops up.  Here is my theory.  runemacs
returns immediately after starting emacs.  Thunderbird sees that
return, reads back in the file it wrote, and deletes the file.  Then
emacs tries to open the file and does not see it.

If this theory is right, what I need / desire is for runemacs to wait
for the emacs child.  But AFAICT runemacs is not designed to do this.
I end up desiring a case not provided for, and hence probably need to
just live with the annoying pop up console window.

At least I think we have an explanation.  Still, it would be nice if
I could tell runemacs to wait ...

I appreciate your help with this.

Regards -- Eliot

bug#23840: runemacs does not seem to pass command line arguments through to emacs properly

[Eli Zaretskii]

> From: Eliot Moss <moss@cs.umass.edu>
> Cc: 23840@debbugs.gnu.org
> Date: Sat, 25 Jun 2016 11:53:22 -0400
> 
> However, I think we're making progress on diagnosing this.  When I
> looked very closely at the mode line in emacs, I could see the underscores
> were actually there.  The two cases start up pointing to the same file
> name in the same folder.  In the runemacs case, however, the file is
> not present by the time emacs pops up.  Here is my theory.  runemacs
> returns immediately after starting emacs.  Thunderbird sees that
> return, reads back in the file it wrote, and deletes the file.  Then
> emacs tries to open the file and does not see it.
> 
> If this theory is right, what I need / desire is for runemacs to wait
> for the emacs child.  But AFAICT runemacs is not designed to do this.
> I end up desiring a case not provided for, and hence probably need to
> just live with the annoying pop up console window.

That's a sensible explanation.

> At least I think we have an explanation.  Still, it would be nice if
> I could tell runemacs to wait ...

You should be able to have that if you give runemacs the -wait option.
But that's a very unusual way of using Emacs, so I won't be surprised
if there are more problems on the way.

bug#23840: runemacs does not seem to pass command line arguments through to emacs properly

[Eliot Moss]

On 6/25/2016 12:08 PM, Eli Zaretskii wrote:
>> From: Eliot Moss <moss@cs.umass.edu>
>> Cc: 23840@debbugs.gnu.org
>> Date: Sat, 25 Jun 2016 11:53:22 -0400

>> If this theory is right, what I need / desire is for runemacs to wait
>> for the emacs child.  But AFAICT runemacs is not designed to do this.
>> I end up desiring a case not provided for, and hence probably need to
>> just live with the annoying pop up console window.
>
> That's a sensible explanation.
>
>> At least I think we have an explanation.  Still, it would be nice if
>> I could tell runemacs to wait ...
>
> You should be able to have that if you give runemacs the -wait option.
> But that's a very unusual way of using Emacs, so I won't be surprised
> if there are more problems on the way.

Aha!  It indeed works with -wait, which needs to be at the beginning of
the command line passed to runemacs (I looked at the source to verify
this).  So, I have a solution -- thank you for your help!

Regards -- EM

bug#23840: runemacs does not seem to pass command line arguments through to emacs properly

[Eli Zaretskii]

> Cc: 23840@debbugs.gnu.org
> From: Eliot Moss <moss@cs.umass.edu>
> Date: Sat, 25 Jun 2016 12:47:06 -0400
> 
> >> At least I think we have an explanation.  Still, it would be nice if
> >> I could tell runemacs to wait ...
> >
> > You should be able to have that if you give runemacs the -wait option.
> > But that's a very unusual way of using Emacs, so I won't be surprised
> > if there are more problems on the way.
> 
> Aha!  It indeed works with -wait, which needs to be at the beginning of
> the command line passed to runemacs (I looked at the source to verify
> this).  So, I have a solution -- thank you for your help!

For the record, the "official" solution is to start a daemon session
of the Cygwin Emacs, possibly with the -nw option in your case, and
then use emacsclient to open frames in that session.  Alternatively,
setting the external editor to 'emacsclient --alternate-editor=""'
will start the daemon the first time it is invoked.

In any case, there's no Emacs bug here, so I'm closing the bug report.