bug#7741: More about folding emacsclient into emacs

[Vaidheeswaran C]

On Monday 13 July 2015 07:30 AM, Glenn Morris wrote:
> Reuben Thomas wrote:
> 
>> So again, it would be good if emacsclient were folded into emacs. I just
>> had a look at their respective command-line options, and I can't see any
>> that clash (where the same option is used for both programs, it's used for
>> the same thing).
>>
>> What would remain is to add options --[no]client to force "emacs" to [not]
>> behave as "emacsclient", and decide a sensible default policy. A sensible
>> place to start seems to be to behave like emacsclient when called with
>> --alternate-editor="", that is, try to connect to a server, and if one
>> can't be found, start normally (emacsclient would instead run "emacs
>> --daemon" here and try to connect to it).
>>
>> Regardless of whether anyone feels like hacking on this, I'd like to know
>> whether it's a tractable design problem (have I missed anything major?) and
>> clikely to be accepted. If so, I might be up for hacking on it.
> 
> I had the same thoughts recently and found that, of course, there is
> already an open report for it.
> 
> So I'm just chiming in very late to say that I agree with pretty much
> everything you said, and I would like to see a patch for this.

Some doubts I had while using emacsclient:

1. Can I control what emacs (i.e., from which path) the emacs daemon
   will be loaded from.

2. I had to use the "-F" option to keep the client frame maximized.
   It is not obvious how to pass in an ALIST on command line.  I was
   wondering if there is an use case where the client would need an
   init script of it's own.  This tiny script can store FRAME params
   for example.

So, frame maximization and an init script is a __behaviour__ that both
the emacsclient and regular emacs possibly share.