emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: It is time for a feature freeze (it is NOW or never).


From: Lőrentey Károly
Subject: Re: It is time for a feature freeze (it is NOW or never).
Date: Thu, 15 Apr 2004 21:42:41 +0200
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux)

Kim F. Storm <address@hidden> writes:
> Richard Stallman <address@hidden> writes:
>
>>     > I think it would be useful if Emacs had display-local variables, and a
>>     > display type that is accessible from Lisp code.  The Elisp manual will
>>     > have to be updated when (if) these features are implemented.
>> 
>>     That sounds useful, especially with multi-tty support.
>> 
>>     Richard -- is this something we should add?
>> 
>> If it is necessary, we could add it with the multi-tty support.
>> However, if we can do without it, let's do without it.  These would
>> surely not be used very often.  It could be a feature not worth the
>> effort it costs.
>> 
>> When would you use it?
>
> I like to have a menu-bar on a window system, but don't like it on
> a terminal.  Maybe a display-local variable could do that.
>
> There could also be a need for different keymaps to co-exist.

There are a few special display-local variables even in the current
Emacs CVS trunk:

        File: elisp,  Node: Multiple Displays
        [...]
           A few Lisp variables are "terminal-local"; that is, they have a
        separate binding for each terminal.  The binding in effect at any time
        is the one for the terminal that the currently selected frame belongs
        to.  These variables include `default-minibuffer-frame',
        `defining-kbd-macro', `last-kbd-macro', and `system-key-alist'.  They
        are always terminal-local, and can never be buffer-local (*note
        Buffer-Local Variables::) or frame-local.

(The implementation involves calculating offsets into struct kboard,
and other such fun; see defvar_kboard in lread.c and the DEFVAR_KBOARD
macro.)

My other proposal, making a primitive Lisp type for displays would
greatly simplify a few things, for example implementing support for
two separate Emacs displays on the same device.  I know that sounds
like a stupid thing to do, but I (and judging from the bug reports,
others) frequently want to run more than one separate emacsclient tty
sessions on the same terminal.  (Think classical UNIX shell-centric
vi-style: you start editing a file by `emacsclient foo', remember
something, so you press C-z to get back to the shell.  A few commands
later you need to make a quick edit in another file, so naturally you
type `emacsclient bar', only to find that it fails because Lisp code
can not currently distinguish between two separate displays on the
same device.  It's annoying.)

> Some modes may also initialize things differently based on the display
> type, e.g. depending on whether images are supported or not.

I think that is not a good idea to do in new Lisp code, as the same
buffer may later be displayed on another device, possibly even
simultaneously.

-- 
Károly




reply via email to

[Prev in Thread] Current Thread [Next in Thread]