Re: multi-tty branch created

[David Kastrup <dak@gnu.org>]

"Károly Lőrentey" <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>
>> One thing that is mentioned that calling emacsclient from a
>> different user will not work.  I think that this is really a
>> non-issue since file accessibility from a different user would also
>> be different and there is no really useful strategy short of using
>> tramp for getting this to work.
>
> I agree with your reasoning but the item is about something slightly
> different:
>
> 	Login: fred
> 	Password:
> 	fred$ emacs
> 		M-x server-start
>
> Meanwhile, in another session:
>
> 	Login: barney
> 	Password:
> 	barney$ su fred
> 	Password:
> 	fred$ emacsclient -t
> 	(Fails due to Emacs not being able to open the tty device.)
>
> The use case: fred sits down before barney's console to show him
> something under his own account.

Still a non-issue in my book: the same won't work with X frames,
either, unless the X11 authentication is seriously insecure.

The way to do this kind of thing is an ssh session, and those will
work with either text or X11.

>> emacsclient operation in multitty is different as compared to
>> previously.  So people can't avoid multitty completely, meaning
>> that we can't bluntly state "situation can't be worse than
>> previously, no regression" but need to evaluate multitty somewhat
>> more closely before finding it suited for trunk, even if the
>> compilation problems on DOS/Windows/Mac have been tackled.
>
> Hold your horses.

You would not want me to: my concerns are likely similar to those of
others, so you want to get them discussed and refuted.

> There is always "emacsclient --current-frame" to prevent emacsclient
> from creating a new terminal.  This retains much of the
> functionality of the original emacsclient, including, I believe,
> things like C-#, and does not use multi-tty features.

Still, environments do no longer work the same even if you don't use
multi-tty features.

> I hope most people would agree that the new emacsclient features are
> a definite improvement.

We are not talking about the features when wanting to avoid
regressions.

>> The precondition for trunk in my opinion would be that it does not
>> impede workability for those people who are working on different
>> parts of Emacs.
>
> Keep in mind that improving emacsclient behaviour is one of the
> primary results of the multi-tty branch.

But we don't want secondary results interfering with the work of those
who don't make use of the primary results.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum