Gary, There are ways to start emacs without using EmacsW32. I believe the -a option in emacsclient now works correctly. What are the proper exit statues you are talking about? Matt. PS: I have also come up with a method to start emacs, register a few things like right-click edit with Emacs and org-protocol links, and then remove these registry settings to run emacs in a portable manner. I have also made this distribution a cross-platform emacs that works on my usb key on either a mac or windows machine. The sources are at https://github.com/mlf176f2/EmacsPortable.App. It is in a pre-release state. If you are interested, I can send you some binaries. I haven't been able to use EmacsW32 for awhile since I don't typically have administrator rights and can't install InnoSetup files. I found out I could extract them after I built my solution. -----Original Message----- From: [mailto: On Behalf Of Gary Oberbrunner Sent: Monday, May 07, 2012 1:54 PM To: Lennart Borgman Cc: ; Adam Golding Subject: Re: [h-e-w] EMACSW32 and Windows 7 Win+Arrow Shortcuts----- Original Message ----- > From: "Lennart Borgman" > Unfortunately it will probably be a long time until I can merge > again. > There are a lot of things I am dependent on in EmacsW32 (escpecially > for org-mode).Hi Lennart; long-time EmacsW32 user here, as well as org-mode (mostly for doc writing). Last year though I switched back to the GNU builds to get on the latest Emacs versions. The only thing I really miss from EmacsW32 is the improvements in emacsclient, to auto-start emacs if it's not already running, and how it returns proper exit statuses. What else is in EmacsW32 that you're thinking about that helps with org-mode?
----- Original Message ----- > From: "Matthew Fidler" > > Gary, > There are ways to start emacs without using EmacsW32. I believe the > -a option in emacsclient now works correctly. > What are the proper exit statues you are talking about?Hi Matt. Perhaps this was only ever an emacsW32 bug, and/or maybe it was fixed long ago. I don't have current source here (guess I should), but basically, emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself). At the time, the symptom was easy to reproduce. In a shell window inside emacs (I use cygwin zsh, but any shell will work), run emacsclient foo || echo BAD then C-x # to close the server buffer, and then look back in the shell window: % emacsclientw foo || echo BAD Waiting for Emacs... BAD %> I have also come up with a method to start emacs, register a few > things like right-click edit with Emacs and org-protocol linksIt would certainly be nice if Emacs came with a decent set of registry keys and start menu shortcuts so that it (client) would _just work_ without hand-editing registry or creating start menu shortcuts. If your code can be run after unpacking a standard nightly build on a fresh machine and it finishes setting up Emacs, I bet a lot of people would use it. For me at least, that integration was the biggest draw of W32Emacs over stock. I guess I should try again with stock emacsclient/emacsclientw and see how things have progressed.
> It would certainly be nice if Emacs came with a decent set of
> registry keys and start menu shortcuts so that it (client)
> would _just work_ without hand-editing registry or creating
> start menu shortcuts.
>
> If your code can be run after unpacking a standard nightly
> build on a fresh machine and it finishes setting up Emacs,
> I bet a lot of people would use it. For me at least, that
> integration was the biggest draw of W32Emacs over stock.FWIW, that messing with the registry etc. is a main reason that I would *not*
use EmacsW32.
(Note: I am not saying that anyone else should not use it. I'm very glad that
Lennart has made EmacsW32 available.)
I have multiple versions of Emacs on my laptop. It is trivial to create a
shortcut to any of them that I want to start with just a click. And none of
them takes precedence over any others (registry settings etc.). I never touch
the registry for Emacs (what for?). And a shortcut need not be related to the
Start menu, BTW. You can put a shortcut anywhere.
What's the big deal about creating a shortcut? Why is that harder than running
some "installer"? I find unzipping and (optionally) creating a shortcut sans
effort and sans surprises - painless. So much so that I sometimes have more
than one shortcut to the same binary, with different startup switches etc.
YMMV - just one user experience.
On Tue, May 8, 2012 at 4:26 PM, Drew Adams wrote:
>
> FWIW, that messing with the registry etc. is a main reason that I would *not*
> use EmacsW32.
>
> (Note: I am not saying that anyone else should not use it. I'm very glad that
> Lennart has made EmacsW32 available.)The installation process let you choose if it should change the
registry or not ;-)
> > FWIW, that messing with the registry etc. is a main reason
> > that I would *not* use EmacsW32.
> >
> > (Note: I am not saying that anyone else should not use it.
> > I'm very glad that Lennart has made EmacsW32 available.)
>
> The installation process let you choose if it should change the
> registry or not ;-)Yes, well, messing with the registry is only one thing to inhibit. There is
lots of other messing about that I would also want to prevent (opt out of).
But some of those are no doubt things that others might appreciate. People's
needs are different.
Again, I'm not trying to convince anyone not to use EmacsW32 - far from it. I'm
just saying that for my purposes, which include having multiple builds of
unmessed-with vanilla GNU Emacs on the same machine, and equally accessible, I
have no need for EmacsW32, and it would just be a bother.
And I am not convinced that it is easier to "install" Emacs with such an
installer than it is to unzip a zip archive and optionally create a shortcut to
the executable. Especially if you start fiddling with telling the installer to
do this but not do that, etc.
That was my main point. It seems to me that the advantage of EmacsW32 can come
from the many changes that it makes to Emacs, not from its ease of installing or
any resultant ease in starting Emacs.
And I prefer not to have such changes to Emacs, so I see no EmacsW32 advantage
for my use case.
FYI: The EmacsPortable.App launcher lets you opt out of all the registry
changes it does.On Tue, May 8, 2012 at 10:16 AM, Drew Adams wrote:
> > > FWIW, that messing with the registry etc. is a main reason
> > > that I would *not* use EmacsW32.
> > >
> > > (Note: I am not saying that anyone else should not use it.
> > > I'm very glad that Lennart has made EmacsW32 available.)
> >
> > The installation process let you choose if it should change the
> > registry or not ;-)
>
> Yes, well, messing with the registry is only one thing to inhibit. There
> is
> lots of other messing about that I would also want to prevent (opt out of).
>
> But some of those are no doubt things that others might appreciate.
> People's
> needs are different.
>
> Again, I'm not trying to convince anyone not to use EmacsW32 - far from
> it. I'm
> just saying that for my purposes, which include having multiple builds of
> unmessed-with vanilla GNU Emacs on the same machine, and equally
> accessible, I
> have no need for EmacsW32, and it would just be a bother.
>
> And I am not convinced that it is easier to "install" Emacs with such an
> installer than it is to unzip a zip archive and optionally create a
> shortcut to
> the executable. Especially if you start fiddling with telling the
> installer to
> do this but not do that, etc.
>
> That was my main point. It seems to me that the advantage of EmacsW32 can
> come
> from the many changes that it makes to Emacs, not from its ease of
> installing or
> any resultant ease in starting Emacs.
>
> And I prefer not to have such changes to Emacs, so I see no EmacsW32
> advantage
> for my use case.
>
>
On Tue, May 8, 2012 at 5:16 PM, Drew Adams wrote:
>> > FWIW, that messing with the registry etc. is a main reason
>> > that I would *not* use EmacsW32.
>> >
>> > (Note: I am not saying that anyone else should not use it.
>> > I'm very glad that Lennart has made EmacsW32 available.)
>>
>> The installation process let you choose if it should change the
>> registry or not ;-)
>
> Yes, well, messing with the registry is only one thing to inhibit. There is
> lots of other messing about that I would also want to prevent (opt out of).It is not the only choice there is in the installation process ... ;-)
> >> The installation process let you choose if it should change the
> >> registry or not ;-)
> >
> > Yes, well, messing with the registry is only one thing to
> > inhibit. There is lots of other messing about that I
> > would also want to prevent (opt out of).
>
> It is not the only choice there is in the installation process ... ;-)That's exactly what I meant.
----- Original Message ----- > From: "Drew Adams" > > If your code can be run after unpacking a standard nightly > > build on a fresh machine and it finishes setting up Emacs, > > I bet a lot of people would use it. For me at least, that > > integration was the biggest draw of W32Emacs over stock. > > FWIW, that messing with the registry etc. is a main reason that I > would *not* use EmacsW32.Fair enough. Different strokes for different folks.> What's the big deal about creating a shortcut? Why is that harder > than running > some "installer"? I find unzipping and (optionally) creating a > shortcut sans effort and sans surprises - painless.Because the installer is one-click (well not really but you don't have anything to remember) and then you're up and running. I admit the shortcut thing should not irk me as much as it does, but there are too many options for me to always remember, and at least in the old days, it was hard to get exactly right and -a didn't work so you had to write a little .bat file and use that. Maybe that's all behind us now. Partly it's because I'm an old-school Linux guy and all this emacs vs. runemacs and emacsclient vs. emacsclientw stuff isn't burned into my brain enough to remember when I'm setting up a new system. I admit that although I've been using Emacs since 1982, submitted patches, and written thousands of lines of elisp, I'm at the point now where I just want it to work without fuss on a new machine - my focus is elsewhere. Guess I'm getting lazy. :-) How about if Emacs shipped with a bin/EmacsClient.lnk shortcut with the right options already in it? Hmm, don't think that would work -- .lnk files have the install dir baked into them. Or maybe addpm.exe could create it.
> Fair enough. Different strokes for different folks. We agree. That was one of my points. I don't claim that my own use of Emacs binaries is the only use or is typical.> > What's the big deal about creating a shortcut? Why is that > > harder than running some "installer"? I find unzipping and > > (optionally) creating a shortcut sans effort and sans > > surprises - painless. > > Because the installer is one-click (well not really but you > don't have anything to remember) and then you're up and > running.Only if you want *all* of what it changes by default. As soon as you start picking and choosing - even to obtain just a standard, unaltered GNU Emacs build, you have left the one-click installation scenario. And then you need to know what you're choosing and how to interpret the installer dialog etc.> I admit the shortcut thing should not irk me as > much as it does, but there are too many options for me to > always remember, and at least in the old days, it was hard to > get exactly right and -a didn't work so you had to write a > little .bat file and use that. Maybe that's all behind us > now. Partly it's because I'm an old-school Linux guy and all > this emacs vs. runemacs and emacsclient vs. emacsclientw > stuff isn't burned into my brain enough to remember when I'm > setting up a new system.I understand. But you probably only have to learn _once_ what it is that you want, and then just repeat that each time afterward. If you always use the same thing then there is only one thing to remember. And if you always use the same thing then you can just update your existing shortcut to point to the new binary location. And if the location does not change (e.g. you need only one build) then you need not do ANYTHING more than unzip the new zip file to the same location - your shortcut need not change at all.> I admit that although I've been using Emacs since 1982, > submitted patches, and written thousands of lines of elisp, > I'm at the point now where I just want it to work without > fuss on a new machine - my focus is elsewhere. Guess I'm > getting lazy. :-)Again, I'm with you. But you might have fewer surprises by sticking with a vanilla GNU Emacs build. Just a suggestion.> How about if Emacs shipped with a bin/EmacsClient.lnk > shortcut with the right options already in it? Hmm, don't > think that would work -- .lnk files have the install dir > baked into them. Or maybe addpm.exe could create it.Use `M-x report-emacs-bug' to offer such suggestions to the Emacs developers. That command is for enhancement requests in addition to bug reports.
----- Original Message ----- > From: "Drew Adams" ----- Original Message ----- > From: "Drew Adams" ... > > I admit the shortcut thing should not irk me as > > much as it does, but there are too many options for me to > > always remember, and at least in the old days, it was hard to > > get exactly right and -a didn't work so you had to write a > > little .bat file and use that. ... > > I understand. But you probably only have to learn _once_ what it is > that you > want, and then just repeat that each time afterward. If you always > use the same > thing then there is only one thing to remember. > > And if you always use the same thing then you can just update your > existing shortcut to point to the new binary location. > > And if the location does not change (e.g. you need only one build) > then you need > not do ANYTHING more than unzip the new zip file to the same location > - your shortcut need not change at all.Yeah, I should just get over it -- as long as newish builds actually work, which it sounds like they do (-a is said to work properly now, and probably the exit status thing is fine). So, emacs Windows wizards, is the best Emacs shortcut for Windows now just "emacsclient -na emacs"? Or is it "emacsclientw -na runemacs"? BTW, the Emacs wiki http://www.emacswiki.org/emacs/EmacsClient) still suggests writing a bat file containing "emacsclientw -na runemacs.exe %1" -- from this discussion, I presume that level of indirection is no longer needed. That discussion is also scarily confusing even to me, a seasoned Windows and Linux developer. Note that if you like to associate file types with emacs, like .txt and so on, each of those is a separate registry command, so if you move your emacs, you have to adjust all of them. Or write a bat script and use that. At least I think this is true. I always keep my emacs in the same place: c:\Program Files (x86)\Emacs\Emacs. Old versions go in C:\Program Files (x86)\Emacs\Emacs-24.0.91 and so on. That way they all automatically read my site-lisp which I keep in c:\Program Files (x86)\Emacs\site-lisp.> > I admit that although I've been using Emacs since 1982, > > submitted patches, and written thousands of lines of elisp, > > I'm at the point now where I just want it to work without > > fuss on a new machine - my focus is elsewhere. Guess I'm > > getting lazy. :-) > > Again, I'm with you. But you might have fewer surprises by sticking > with a vanilla GNU Emacs build. Just a suggestion.You're right -- and I have been running vanilla builds for the last year or so, since I switched away from W32Emacs. But I admit I'm still running the special W32-patched emacsclient as my main way of starting emacs. I should wean myself away from that and start fresh.> ... Or maybe addpm.exe could create it. > > Use `M-x report-emacs-bug' to offer such suggestions to the Emacs > developers. > That command is for enhancement requests in addition to bug reports.Good point. Of course I know how much the Emacs community *loves* to work on Windows features. :-) But you're right, if I don't ask then it certainly won't happen.
(I can't speak to your other comments & questions. Hopefully someone else will be able to help.)> Note that if you like to associate file types with emacs, > like .txt and so on, each of those is a separate registry > command,Or use Windows Explorer > Tools > Folder Options > File Types Or use `Open With...' ...and then pick your Emacs executable. That's a lot easier than messing directly with the registry, no?> so if you move your emacs, you have to adjust all of > them. Or write a bat script and use that. At least I think > this is true.Yes, you need to put the folder that contains emacsclient or gnuclientw or whatever you use for Emacs file associations in your PATH environment var. But again, if you have only one Emacs build, then that location won't change.
> Date: Tue, 08 May 2012 12:34:00 -0400 (EDT)
> From: Gary Oberbrunner
> Cc: , Lennart Borgman ,
> Matthew Fidler ,
> Adam Golding
>
> So, emacs Windows wizards, is the best Emacs shortcut for Windows now just "emacsclient -na emacs"? Or is it "emacsclientw -na runemacs"?The latter, of course. The rule is, when you don't have a program to
wait for Emacs to finish editing, use emacsclientw, otherwise use
emacsclient.
----- Original Message -----
> From: "Eli Zaretskii"
> To: "Gary Oberbrunner"
> Cc: "drew adams" , , "lennart borgman" ,
> "matthew fidler" ,
> Sent: Tuesday, May 8, 2012 1:49:53 PM
> Subject: Re: [h-e-w] EMACSW32 and Windows 7 Win+Arrow Shortcuts
>
> > Date: Tue, 08 May 2012 12:34:00 -0400 (EDT)
> > From: Gary Oberbrunner
> > Cc: , Lennart Borgman
> > ,
> > Matthew Fidler ,
> > Adam Golding
> >
> > So, emacs Windows wizards, is the best Emacs shortcut for Windows
> > now just "emacsclient -na emacs"? Or is it "emacsclientw -na
> > runemacs"?
>
> The latter, of course. The rule is, when you don't have a program to
> wait for Emacs to finish editing, use emacsclientw, otherwise use
> emacsclient.Good to know. So for my $EDITOR env var (git commits and so on), the right thing should be:
"emacsclient -na runemacs"
? (adjusted for paths and so on)
As for your "of course", where do I go to be enlightened in that way? (i.e. where's that documented?) That way I can stop bugging this list.
> Date: Tue, 08 May 2012 14:04:16 -0400 (EDT) > From: Gary Oberbrunner > Cc: drew adams , , lennart borgman , matthew fidler , > > > > So, emacs Windows wizards, is the best Emacs shortcut for Windows > > > now just "emacsclient -na emacs"? Or is it "emacsclientw -na > > > runemacs"? > > > > The latter, of course. The rule is, when you don't have a program to > > wait for Emacs to finish editing, use emacsclientw, otherwise use > > emacsclient. > > Good to know. So for my $EDITOR env var (git commits and so on), the right thing should be: > "emacsclient -na runemacs" > ? (adjusted for paths and so on)Yes, I think so. (I cannot be sure, as I don't use git.)> As for your "of course", where do I go to be enlightened in that > way? (i.e. where's that documented?)In the Emacs manual (the Windows appendix). It's possible that this was only added in the recent versions, though.
----- Original Message -----
> From: "Eli Zaretskii"
> The latter, of course. The rule is, when you don't have a program to
> wait for Emacs to finish editing, use emacsclientw, otherwise use
> emacsclient.You know more than I about these things, I'm sure, but this doesn't seem accurate to me.
As far as I can tell, emacsclientw is a GUI program and emacsclient is a CLI program. Both wait for the server to finish before they return, unless you use -n, in which case both of them return right away.
Perhaps a better rule is, when the invoking program is a GUI program (e.g. you're in a shell within emacs), use emacsclientw (emacsclient pops up an annoying console window in this case); when the invoking program is a CLI program where you want messages to come out on stdout, use emacsclient.
Does that work?
> Date: Tue, 08 May 2012 14:34:22 -0400 (EDT)
> From: Gary Oberbrunner
> Cc: drew adams , , lennart borgman , matthew fidler ,
>
> > The latter, of course. The rule is, when you don't have a program to
> > wait for Emacs to finish editing, use emacsclientw, otherwise use
> > emacsclient.
>
> You know more than I about these things, I'm sure, but this doesn't seem accurate to me.
>
> As far as I can tell, emacsclientw is a GUI program and emacsclient is a CLI program. Both wait for the server to finish before they return, unless you use -n, in which case both of them return right away.
>
> Perhaps a better rule is, when the invoking program is a GUI program (e.g. you're in a shell within emacs), use emacsclientw (emacsclient pops up an annoying console window in this case); when the invoking program is a CLI program where you want messages to come out on stdout, use emacsclient.
>
> Does that work?That's another way of putting the same condition, yes.
Gary,On Tue, May 8, 2012 at 9:08 AM, Gary Oberbrunner wrote: > ----- Original Message ----- > > It would certainly be nice if Emacs came with a decent set of registry > keys and start menu shortcuts so that it (client) would _just work_ without > hand-editing registry or creating start menu shortcuts.The focus of EmacsPortable is to run Emacs on a usb stick without installing it. Therefore registry keys are setup when emacs is running, and removed when emacs is not running. It wouldn't be too hard to "install" it and make these setting permanent, but currently this is not as supported. In addition to supporting a emacsclient/emacs setting it also implements a pseudo-daemon, where emacs runs your startup settings once and continues to run in the "background" with a hidden frame in the windows tray. It makes secondary start-ups faster. I no longer groan when I accidentally close the last visible emacs window. This does not support faster terminal-mode emacs, since it is not a real emacs daemon. I'm not sure if an emacs daemon is going to be supported in emacs 24 under windows, but currently it is not.> If your code can be run after unpacking a standard nightly build on a > fresh machine and it finishes setting up Emacs, I bet a lot of people would > use it. For me at least, that integration was the biggest draw of W32Emacs > over stock. >My code can be run after unpacking any nightly build on a fresh machine. It also sets up "shortcuts" or executables for every version of emacs you have included in a specific directory. This can be expanded to adding shortcuts for every version of emacs installed as well. The only draw-back is that I write my startup in org-mode so... you have to install a more recent version of org-mode than what is included in emacs 23 to get the startup working. Another caveat is your startup files are shared in a specific folder. If you byte-compile your startup files in a more recent emacs, it may choke on earlier versions of emacs. The directory structure is also slightly different, conforming with PortableApps.com directory structure. Let me know if you would like to try this out as a tester.
On 5/8/2012 10:08 AM, Gary Oberbrunner wrote:
>
> It would certainly be nice if Emacs came with a decent set of
> registry keys and start menu shortcuts so that it (client) would
> _just work_ without hand-editing registry or creating start menu
> shortcuts.I really like emacs being independent of the registry.
- I can easily replicate my setup on multiple Windows machines.
- I can move settings between multiple OSes, even those that don't have
a registry.
- I can share settings on my dual boot Windows/Linux machine.
It's hard for me to imagine anyone skilled enough to use emacs that
doesn't know how to create a shortcut in a Windows menu or taskbar.
On Wed, May 9, 2012 at 7:34 PM, Ken Goldman wrote:
> On 5/8/2012 10:08 AM, Gary Oberbrunner wrote:
>>
>>
>> It would certainly be nice if Emacs came with a decent set of
>> registry keys and start menu shortcuts so that it (client) would
>> _just work_ without hand-editing registry or creating start menu
>> shortcuts.
>
>
> I really like emacs being independent of the registry.
>
> - I can easily replicate my setup on multiple Windows machines.
>
> - I can move settings between multiple OSes, even those that don't have a
> registry.
>
> - I can share settings on my dual boot Windows/Linux machine.
>
> It's hard for me to imagine anyone skilled enough to use emacs that doesn't
> know how to create a shortcut in a Windows menu or taskbar.There are many types of shortcuts you can create and all of them are
not that easy.