[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multi-tty branch created
From: |
David Kastrup |
Subject: |
Re: multi-tty branch created |
Date: |
Wed, 16 May 2007 19:39:15 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux) |
"Károly Lőrentey" <address@hidden> 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
- Re: multi-tty branch created, (continued)
- Re: multi-tty branch created, David Kastrup, 2007/05/13
- Re: multi-tty branch created, Robert J. Chassell, 2007/05/13
- Re: multi-tty branch created, rentey <address@hidden>, 2007/05/16
- Re: multi-tty branch created, Juanma Barranquero, 2007/05/16
- Re: multi-tty branch created, Károly Lőrentey, 2007/05/16
- Re: multi-tty branch created, David Kastrup, 2007/05/16
- Re: multi-tty branch created, Károly Lőrentey, 2007/05/16
- Re: multi-tty branch created, Jason Rumney, 2007/05/16
- Re: multi-tty branch created, Dan Nicolaescu, 2007/05/16
- Re: multi-tty branch created,
David Kastrup <=
- Re: multi-tty branch created, Károly Lőrentey, 2007/05/16
- Re: multi-tty branch created, Stefan Monnier, 2007/05/17
- Re: multi-tty branch created, rentey <address@hidden>, 2007/05/17
- Re: multi-tty branch created, Stefan Monnier, 2007/05/17
- Re: multi-tty branch created, rentey <address@hidden>, 2007/05/18
- Re: multi-tty branch created, Stefan Monnier, 2007/05/19
Re: multi-tty branch created, Jason Rumney, 2007/05/13