I really like the client-server structure of emacs. However, I feel uncomfortable to run 'emacsclient' to attach to running emacs server. Is there any specific reason that emacs seperated emacsclient from emacs binary? Is it possible to integrate them without hacky-dirty shell aliasing?
1 Answer
Emacs is a big, complicated program. It must know how to handle large text files, and to interact with users in a graphical user interface or in a text terminal. It can display graphics. On my machine, it loads 34 libraries just in order to start. The binary is 15 megabytes. Many people, myself included, only start emacs once in a rare while, and hardly ever quit the program, except when the computer needs to be rebooted for some other reason.
Emacsclient, on the other hand, is a small, simple program. On my computer, it is 37 kilobytes, about 0.2% the size of the full emacs, and it loads a single library. As a result, it will load and execute with no perceptible delay. This is because it has a very simple task to perform: Namely, to talk to the running emacs instance and tell it what file the user wishes to edit and how, optionally waiting for the user to finish editing the file. Thus, it makes perfect sense for emacsclient to be its own program.
In any case, it does not enlarge the emacs distribution by much. For emacs is much more than just the emacs executable! It is also a large number of elisp files – 1466 of them on my system right now, plus various documentation files and other data. Hence, throwing in an extra executable like emacsclient does not make the whole package noticably more complex.
answered Feb 18, 2019 at 19:55
consul,jenkins,seleniumand lots and lots more act this way. Essentially, you'd expect that whenever you runemacsit'd act likeemacsclient, while you'd need to run something likeemacs -hubto start the server. My guess is that it's too much work to prevent all extra loading in emacs to turn it intoemacsclient.