From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: lorentey@elte.hu (=?iso-8859-2?q?L=F5rentey_K=E1roly?=) Newsgroups: gmane.emacs.devel Subject: Re: It is time for a feature freeze (it is NOW or never). Date: Thu, 15 Apr 2004 21:42:41 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87eks0654s.fsf@sno.mundell.ukfsn.org> <87n06bp4ng.fsf@sno.mundell.ukfsn.org> <8765cwkejr.fsf@mail.jurta.org> <200404071157.UAA25094@etlken.m17n.org> <200404071312.WAA25268@etlken.m17n.org> <87zn9nqras.fsf@emacswiki.org> <87hdvux5uz.fsf@orebokech.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1082058609 18382 80.91.224.253 (15 Apr 2004 19:50:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Apr 2004 19:50:09 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 15 21:49:58 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BECs2-0003ju-00 for ; Thu, 15 Apr 2004 21:49:58 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BECs2-0000a2-00 for ; Thu, 15 Apr 2004 21:49:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BECmF-0005NK-Mm for emacs-devel@quimby.gnus.org; Thu, 15 Apr 2004 15:43:59 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BEClt-0005Jh-Gx for emacs-devel@gnu.org; Thu, 15 Apr 2004 15:43:37 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BEClL-00056Y-Cw for emacs-devel@gnu.org; Thu, 15 Apr 2004 15:43:34 -0400 Original-Received: from [157.181.1.137] (helo=mx1.elte.hu) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BEClK-00056E-NR for emacs-devel@gnu.org; Thu, 15 Apr 2004 15:43:02 -0400 Original-Received: from mailbox1.caesar.elte.hu (mailbox1.caesar.elte.hu [157.181.151.157]) by mx1.elte.hu (Postfix) with ESMTP id 46CA1276C4C for ; Thu, 15 Apr 2004 21:42:59 +0200 (CEST) Original-Received: from eris (eris.elte.hu [157.181.150.146]) by mailbox1.caesar.elte.hu (Postfix) with ESMTP id 9DE95A079512 for ; Thu, 15 Apr 2004 21:42:42 +0200 (CEST) Original-Received: by eris (Postfix, from userid 1000) id C797D47B8F; Thu, 15 Apr 2004 21:42:41 +0200 (CEST) Original-To: emacs-devel@gnu.org In-Reply-To: (Kim F. Storm's message of "15 Apr 2004 03:19:24 +0200") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) X-ELTE-SpamVersion: MailScanner 4.26.8-itk2 (ELTE 1.1) SpamAssassin 2.63 ClamAV 0.65 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21716 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21716 Kim F. Storm writes: > Richard Stallman 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 manua= l will >> > have to be updated when (if) these features are implemented. >>=20 >> That sounds useful, especially with multi-tty support. >>=20 >> Richard -- is this something we should add? >>=20 >> 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. >>=20 >> 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. --=20 K=E1roly