caldwell / build-emacs

Build scripts for www.emacsformacosx.com
http://www.emacsformacosx.com/about
GNU General Public License v3.0
364 stars 61 forks source link

The emacs command in the terminal does not run non-windowed by default #95

Closed jamesquilty closed 4 years ago

jamesquilty commented 4 years ago

I'm not sure that this is the right place, but I'm at a loss where else to raise this.

macOS 10.15 Catalina does not include a pre-installed emacs binary, unlike previous versions. I installed emacs with homebrew cask install emacs expecting that it would behave from the terminal the same way previous versions behaved, per https://www.emacswiki.org/emacs/EmacsForMacOS:

After installation, using the emacs command in the terminal or shell will run the -nw version of Emacs.

but it doesn't. Running emacs from the terminal invokes Emacs.app, as does git and crontab and any other shell command configured to use the VISUAL or EDITOR environment variables.

I'm not particularly happy with the commonly suggested solution of using emacs -nwinstead because there are a large number of places where I'll have to do this and I'm sure I'll miss one-or-other of them. I'd rather configure emacs to run non-windowed from the shell, consistent with the pre-installed emacs on previous versions of macOS and the statement at https://www.emacswiki.org/emacs/EmacsForMacOS. How can I do that, or can that configuration be integrated in the build/launch script please?

caldwell commented 4 years ago

Emacs is working as intended. I didn't write those instructions and I believe they are wrong. If there are multiple term backends available (ie, mac and plain terminal or X and plain terminal) then Emacs will choose the fancier one unless the -nw option is specified. Emacs doesn't pay attention to how it was launched (I'm not sure it really can 100% tell that it was launched by the OS or from the cli). Either way, it's not really in the purview of this project to change that behavior.

One way to do what you want would be to write a little shell script like ec (described here) and then point EDITOR and such to that. It's got the same issue that you have to make sure you get all the places that call emacs and make them call ec (though really EDITOR and VISUAL should cover 99% of things).

jamesquilty commented 3 years ago

@caldwell I appreciate your efforts in maintaining a build of Emacs for macOS because otherwise I'd be without the text editor with which I've become familiar (on macOS 10.15). I've hesitated to reply because I'm aware of the context.

That said, emacs on the command-line opening the GUI has been a constant source of frustration for me. What has finally prompted me to reply is that I was ssh'd into a computer and typed emacs and the GUI version — which I couldn't see or control — opened 🙁.

Emacs is not working as I intend. I can't afford the ongoing effort of maintaining "a little shell script" across all the machines and user accounts I have, which is why I haven't done it in the last year. I think there's clearly a need for a CLI-default or CLI-only option, consistent with other emacs builds which I use daily (Arch Linux, Raspberry Pi OS). I'm not particularly interested in switching to the Emacs GUI when I'm working on the command line.

If changing this behaviour is not within this project's purview, would you please be able to tell me the project in which this behaviour has been set so that I can raise this issue there?

Edit to add: Do I perhaps want brew install --formula emacs to allow formula/emacs to build... or will that just give me a locally-built version of the Emacs GUI in /Applications with the same issue?

caldwell commented 3 years ago

I don't know if the brew install will do what you want. You'd have to look at the brew "formula" for emacs and see if they build the macOS stuff (it's the default when detected) or not. They may have a config option to turn off the GUI stuff, and if they don't, they be amenable to a patch to add one. But I can't speak for them.

To change the default of what emacs does when run from the terminal when it is compiled with macOS features would have to come from the main Emacs source code. Again, I don't want to speak for the main Emacs developers, but I suspect there will be pushback on that change (since it would affect everyone). But perhaps they would be open to an environment variable or something similar.

Emacs is not working as I intend.

Sure, but since you are not in charge, that kinda doesn't matter, unless you can convince everyone else involved in the project that they are wrong (and for what it's worth, what I think doesn't matter either since I'm not an Emacs developer). That's probably going to be an uphill battle (but maybe not, who am I to say, really…). Changing a fundamental behavior like that is beyond the purview of this project, though. I understand you are frustrated—I wish I had the easy answer you are looking for.

As it stands the only thing I can think of is to always make sure you add the -nw option to your EDITOR/VISUAL vars. You don't want to manage a bunch of scripts (fair enough) but since macOS defaults those to vi you must set those up somewhere, right? Setting up an alias like alias emacs=emacs -nw in the same place is also pretty effective for when you are just typing at the shell.

The other option is to build Emacs yourself. It's actually not that hard (unpack, ./configure --without-ns && make) and it's not a long process either (the release tarballs come with the lisp pre-compiled so only the C code needs to be compiled—without the macOS code that's even fewer files to compile). You can use brew to install any pre-requisites you need. I think all you need to do is pass the --without-ns option to ./configure when you run it. That will get rid of the mac specific gui code completely and give you a emacs that's just like the old built-in /usr/bin/emacs ("old" because Apple gave up and stopped shipping it :-( ).

jamesquilty commented 3 years ago

Thanks for the advice on building emacs without the GUI. I've added trying this to my backlog and I'll attempt it some time. It's a big backlog, but since this behaviour bites me often I might end up attempting my own build sooner than otherwise.