Re: Pretest

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

David Kastrup wrote:
> In Unix, fork is cheap.  The processes share the same code, and the
...
> I am aware that Windows does not have fork with similar semantics,
> which is why I then made a different proposal:

Thanks. I did actually misunderstand you quite a bit before and was 
going to correct myself before I read this. We are using different language.


>> For what reason do you want to avoid the wait for the server process
>> to start the way I have implemented it?
> 
> Because it is not reliable.  It depends on actions in the started
> Emacs that are not under the control of emacsclient, and it requires a
> separate mechanism not transparent to the user apart from
> --alternate-editor.

You are right.

>> Doing it that way means that emacsclient always communicates with
>> emacs server in the same way and I think that is very important from
>> a code complexity point of view.
> 
>>From code complexity, emacsclient would just pass its options on to
> the alternate editor, whether that is called emacsproxy or vi.
> 
>> One drawback I can see is that you can not know for sure if the
>> server ever starts. Therefore I have added a simple timeout for how
>> long emacsclient waits for emacs server to start.
> 
> I'd prefer the approach where emacsclient does not depend on Emacs
> server to start.

With a little twist your suggestion would be very similar to mine. The 
main part of your suggestion as I see it is that emacsclient wait on an 
intermediate process. This has the advantage that emacs could 
communicate with it and tell emacsclient about errors. That is good. 
Something like this would have the benefits of both yours and my suggestion:

1) If emacsclient could not contact emacs server then it create the 
intermediate process. This then starts emacs and tells emacs to start 
emacs server with the required arguments.

2) Emacsclient then wait for the intermediate process to disappear. 
After that it checks for errors.

3) If there are errors then it tries to connect to the server again.

This is very similar to my current approach but better I believe. My 
approach looks like this:

1) If emacsclient can not contact emacs server then it starts emacs and 
tells emacs to start emacs server with the required arguments.

2) Emacsclient then loops and tries to connect to the server again. If 
it takes too long then emacsclient assumes there is an error. If it can 
connect that step is the same as 3 above.


I think this would be better. From a user perspective the main differenc 
is better error handling. However it requires some changes to the emacs 
executable and I do not believe it should be implemented now.

My proposal does not require any changes to emacs executable. And the 
code is ready for testing now (except for some details I have asked for 
comments on off the list, I am waiting for answers). However I would 
like to have it tested here by people on emacs devel list before going 
further.