Re: emacsclientw

["Stuart D. Herring" <herring@lanl.gov>]

Not attempting to raise the dead (threads) here, but I realized I never
actually replied to this:

>> > (they wonder why they just cannot associate the
>> > emacs exe directly with certain file types without getting multiple
>> > copies running).
>>
>> They can't do that with any other program either without knowing the
>> internals of what DDE commands it uses, and setting them up in the
>> association.
>
> I did not know that.

It's not entirely true.  Explorer (the shell) is capable of remembering
DDE commands for a file type and executing them itself when the program is
already running, and many installers arrange for this to happen (because
it's too complicated to do manually).  (Obviously such an installer could
be developed for emacsclient, but it's also a valid goal to minimize the
complexity of installation.)

However, nothing prevents a program that is so-minded from detecting that
it is already running (this is particularly easy on Windows), executing a
DDE transaction with said established process that corresponds to its
command-line arguments, and then exiting.

Many if not most "professional" Windows programs do this, as their
monolithic (often MDI with a complicated GUI) design heavily favors having
precisely 0 or 1 copies running at any time.  Unfortunately, many of them
do this without providing any alternative behavior.

The emacsclient design is arguably better, where the decision between
communication and execution is made by a separate process with its own
customizable logic.  However, it is not true that Windows users will
automatically accept as reasonable the situation where said separate
program must be the one associated with their files, because the
automatic/monolithic behavior is so common.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.