[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multi-tty design (Re: Reordering etc/NEWS)
From: |
Karoly Lorentey |
Subject: |
Re: Multi-tty design (Re: Reordering etc/NEWS) |
Date: |
Fri, 18 May 2007 13:04:06 +0200 |
User-agent: |
Thunderbird 2.0.0.0 (Windows/20070326) |
David Kastrup wrote:
>>>> But if that's really the case, we can still make `process-environment'
>>>> have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have
>>>> all existing third-party Elisp code continue to work without changes.
>>> I'm not sure I understand: wouldn't this choice break the mentioned AUCTeX
>>> code, then?
>> No, not at all. The special environment may be set up for a single
>> client/terminal/whatever only, but I doubt the code switches frames
>> before it starts whatever subprocess it wants to start in the temporary
>> environment.
>
> Uh what? This is code being run when Emacs is started up, namely when
> custom-set-variables is called.
I'm sorry; I thought we are talking about a piece of code that let-binds
process-environment. Clearly I was wrong.
If the code uses setenv to permanently set variables, then it would work
fine on multi-terminal sessions in my proposed terminal-local design.
For single-terminal users, the code will remain working no matter what
it does.
> It would only work unchanged with
> terminal-local process-environment if the non-terminal local tail of
> process-environment was shared.
The actual underlying requirement is that `setenv' should affect all
existing and future terminals. Tail-merging is an implementation choice.
> And that is a solution which has some
> appeal because of its cleverness, but which is clearly too clever and
> fragile to make for something one wants to document and use.
I disagree. It is actually a very simple and predictable system that's
easy to explain.
>> I find this nice, but others loathe it, so it probably isn't worth the
>> added complexity. The issue is moot now anyway. :-)
>
> I don't find it nice. I don't see how the issue is moot unless I have
> been quite convincing...
I have withdrawn the current implementation, and no longer want to push
for it. I'm not interesting in arguing about its features any more.
> Note that two emacsclient processes (and possibly an emacs -nw)
> started in the same tty will all share their settings (which I
> consider reasonable), while starting, say, two emacsclient processes
> in two different "screen" ttys will each give them their own settings.
So what? That's not a bug per se.
> I really feel we should restrict that to terminal-related variables by
> default. That's simple to understand and has no strong drawbacks that
> I can see.
I say we must support both. Clearly, people are divided on the issue.
Once we have greater experience with these features, we can standardize
on the right thing. I doubt we will be able to convince each other now.
> The one thing which I don't have a clear idea how to solve
> consistently is what frames/windows/emacsclient sessions C-x # is
> going to close and what buffers to discard. But maybe that can be
> solved with a single variable that associates a "session" with frames
> and buffers.
Frames are associated with their clients by their 'client parameter.
Buffers for files opened from the command line of emacsclient are
recorded in `server-clients'. The behaviour of C-# should match
whatever is on the trunk.
> Another possibility would be to diss C-x # completely.
I'm all for that, but I guess existing emacsclient users may complain,
and there is really no reason to remove it.
> However,
> killing an associated buffer at least for the simplest use case
>
> emacsclient filename
> edit the file
> C-x # or similar
>
> seems desirable. But I think that this issue is separate, and should
> be.
OK, I agree.
--
Karoly
signature.asc
Description: OpenPGP digital signature
- Re: Multi-tty design (Re: Reordering etc/NEWS), (continued)
- Re: Multi-tty design (Re: Reordering etc/NEWS), Stefan Monnier, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), rentey <address@hidden>, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), Ken Raeburn, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), Károly Lőrentey, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), Stefan Monnier, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), Karoly Lorentey, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS),
Karoly Lorentey <=
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), Karoly Lorentey, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), Miles Bader, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), Stefan Monnier, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), rentey <address@hidden>, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), Stefan Monnier, 2007/05/17
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), Stefan Monnier, 2007/05/18
- Re: Multi-tty design (Re: Reordering etc/NEWS), David Kastrup, 2007/05/18