From: "Károly Lőrentey" <karoly@lorentey.hu>
To: emacs-devel@gnu.org
Subject: Re: multi-tty branch created
Date: Wed, 16 May 2007 22:48:38 +0200 [thread overview]
Message-ID: <f2fqnc$tig$1@sea.gmane.org> (raw)
In-Reply-To: <85ps503by4.fsf@lola.goethe.zz>
[-- Attachment #1.1: Type: text/plain, Size: 3174 bytes --]
David Kastrup wrote:
> "Károly Lőrentey" <karoly@lorentey.hu> writes:
>>> 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.
Yes. But saying that multi-tty is somehow more suspect because it
changes emacsclient sounds strange to me. Well of course it changes it.
The entire point of the branch is to fix how emacsclient works. D'oh!
I was arguing that all the existing functionality is retained by design.
If there is a feature that was lost, then that's a bug.
>> 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.
Yes they do. "emacsclient --current-frame" does not create a new set of
local environment variables, but reuses the original environment of the
Emacs process. It should work exactly the same as emacsclient on the
trunk. Does it not?
As I said, the one and only truly incompatible change in the multi-tty
branch is that even without any emacsclient connections,
`process-environment' is nil by default, and there is a new
`environment' function for listing all variables. I don't think you can
argue with a straight face that all hell will break loose if we make
such a change, or that it is unacceptable to make our hackers adapt
existing code for these changes. After all, we are working on a new
major version, and there aren't all that many Emacs packages that care
about environment variables. A sizable portion of the few that do
simply call getenv and setenv, or let-bind `process-environment', which
works fine with multi-tty as well. I have presented my reasons for the
change; I still think the client-local environment semantics are the
right way to go, although the implementation may be improved.
>> 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.
As I have explained, "emacsclient --current-frame" is the way people can
get back the original behaviour. If there are serious bugs, the legions
of people who're now testing multi-tty will likely report them before
the merge. Is that not sufficient to prevent undue interference?
I encourage people on supported platforms to try their favourite
emacsclient options in the multi-tty branch, and report anything that
breaks.
--
Karoly
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
next prev parent reply other threads:[~2007-05-16 20:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-13 13:31 multi-tty branch created Miles Bader
2007-05-13 14:50 ` David Kastrup
2007-05-13 16:12 ` Miles Bader
2007-05-13 16:14 ` David Kastrup
2007-05-13 16:13 ` David Kastrup
2007-05-13 19:28 ` Robert J. Chassell
2007-05-16 13:24 ` Károly Lo"rentey
2007-05-16 13:46 ` Juanma Barranquero
2007-05-16 15:04 ` Károly Lőrentey
2007-05-16 15:34 ` David Kastrup
2007-05-16 16:11 ` Károly Lőrentey
2007-05-16 21:17 ` Jason Rumney
2007-05-16 16:20 ` Dan Nicolaescu
2007-05-16 17:39 ` David Kastrup
2007-05-16 20:48 ` Károly Lőrentey [this message]
2007-05-17 14:02 ` Stefan Monnier
2007-05-17 16:04 ` Károly Lo"rentey
2007-05-17 23:24 ` Stefan Monnier
2007-05-18 18:02 ` Károly Lo"rentey
2007-05-19 14:07 ` Stefan Monnier
2007-05-13 20:07 ` Jason Rumney
2007-05-14 10:21 ` Karoly Lorentey
2007-05-14 11:55 ` Jason Rumney
2007-05-15 13:03 ` Karoly Lorentey
2007-05-15 22:05 ` Ken Raeburn
2007-05-14 6:00 ` Manoj Srivastava
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='f2fqnc$tig$1@sea.gmane.org' \
--to=karoly@lorentey.hu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.