Re: Running an application more than once



Hans Aberg <haberg@xxxxxxxxxx> wrote:

In article <1hzfq0l.2iqkgt1es0uooN%nospam@xxxxxxxxxxxxx>,
nospam@xxxxxxxxxxxxx (Richard Maine) wrote:

...so one copy of Emacs is
probably best dedicated to one task. It is up to the program developer to
decide.

Bad example. While you can run multiple copies of Emacs, the program
developers for Emacs rather explicitly recommend the opposite.

Reference?

Sure. Don't have it in front of me, but I certainly recall seeing that
quite explicitly long ago. Let's see... a few minutes of googling found
it for me.

From the GNU Emacs Manual. I happened to find this one at
<http://www.fnal.gov/docs/products/emacs/emacs/emacs_7.html>.
(I pasted this as a quotation, so it might look as though I'm quoting
you here, but I'm not).

Many other editors are designed to be started afresh each time you want
to edit. You edit one file and then exit the editor. The next time you
want to edit either another file or the same one, you must run the editor
again. With these editors, it makes sense to use a command line argument
to say which file to edit.

But starting a new Emacs each time you want to edit a different file does
not make sense. For one thing, this would be annoyingly slow. For another,
this would fail to take advantage of Emacs's ability to visit more than
one file in a single editing session. And it would lose the other
accumulated context, such as registers, undo history, and the mark ring.

The recommended way to use GNU Emacs is to start it only once, just after
you log in, and do all your editing in the same Emacs session. Each time
you want to edit a different file, you visit it with the existing Emacs,
which eventually comes to have many files in it ready for editing. Usually
you do not kill the Emacs until you are about to log out. See section File
Handling, for more information on visiting more than one file.

Back to quoting you:

So, in other words, you notice that it would be very useful if developed
properly.

Mostly I noticed that Emacs was unreasonably slow on some things and
didn't multi-thread well. Using multiple copies was a workaround, not
actually a desirable feature. Besides the problems with coordinating
access to common files, running multiple copies also had user interface
"issues". More than once I exited the wrong copy.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.



Relevant Pages

  • Re: Great SWT Program
    ... None of the nasty things that you have said or implied about me are at ... but that's not what emacs is. ... multiple top-level windows, ... over and over again for each instance you need to do an edit near. ...
    (comp.lang.java.programmer)
  • how to edit a file as admin
    ... Another little emacs tip. ... The tip is about how to edit files that ... you want to edit a file that requires admin privilege. ...
    (comp.emacs)
  • Emacs too slow for casual editing [was Re: Formatting Posts With VI]
    ... > postponed post is just not fast enough. ... And besides, Emacs isn't the ... > right tool if all one wants to do is edit a file, ... > time one logs into the system and be closed when one logs out of the ...
    (comp.os.linux.misc)
  • Re: Tcl Cross Platform Editors - your top five.
    ... I can't compile Vim on some of these ... platforms for various reasons and Vi is not sufficient. ... Emacs is the best and should compile and or have packages for all ... If you can ssh into a box then you can edit ...
    (comp.lang.tcl)
  • Re: Read gcc info files on solaris; Seek online manual
    ... vi, vim, etc, are editing *tools*. ... file you want to edit. ... Emacs -- different concept altogether. ... simply say "M-x shell", and it gives you a new emacs-buffer ...
    (comp.unix.solaris)