From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: It is time for a feature freeze (it is NOW or never). Date: 14 Apr 2004 12:59:11 +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=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1081933266 29222 80.91.224.253 (14 Apr 2004 09:01:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Apr 2004 09:01:06 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 14 11:00: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 1BDgGQ-0005fd-00 for ; Wed, 14 Apr 2004 11:00: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 1BDgGQ-0006SC-00 for ; Wed, 14 Apr 2004 11:00: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 1BDgFv-0004mE-9n for emacs-devel@quimby.gnus.org; Wed, 14 Apr 2004 05:00:27 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDgFe-0004gB-Oc for emacs-devel@gnu.org; Wed, 14 Apr 2004 05:00:10 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDgF2-0004UX-Eb for emacs-devel@gnu.org; Wed, 14 Apr 2004 05:00:03 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.30) id 1BDgEy-0004S6-Uv for emacs-devel@gnu.org; Wed, 14 Apr 2004 04:59:29 -0400 Original-Received: (qmail 80662 invoked from network); 14 Apr 2004 08:59:27 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 14 Apr 2004 08:59:27 -0000 Original-To: emacs-devel@gnu.org In-Reply-To: Original-Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:21619 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21619 L=C5=91rentey K=C3=A1roly writes: > The multi-tty branch changes some internal interfaces which break > non-UN*X ports of Emacs. The changes are not complex at all, but I > can not fix the broken ports without help from Mac/Windows/DOS gurus. > Because of this, the multi-tty branch is certainly not yet ready for > merging. Do you know that the ports are broken with your changes (have you made the changes to those ports?), or do you just suspect they are broken because you haven't been able to test your changes. I usually manage to change this sort of thing (primarily textual, rather than functional changes) on the W32/DOS/MAC ports even though I don't use (or even compile on) them myself. I just make the changes (very carefully), commit my changes, and then leave it to the maintainers of those ports to verify my changes. So far, this procedure hasn't caused much trouble. > > I have looked briefly at the multi-tty pathces, and although it looks > > very sensible and systematic in its approach, it touches on many files > > and interfaces!=20=20 > > > > Since it probably hasn't received much attention (yet) from the core > > developers, I would think that there are still some issues which need > > to be ironed out. For example , what is the value of window-system > > variable if you have both a window frame and a non-window frame open > > at the same time (I haven't looked, so I don't know how this issue has > > been resolved, but there could be other issues like it). >=20 > The window-system variable is frame-local in the multi-tty branch. > Actually, I think this is the most important change on Lisp level; > multi-tty support is otherwise mostly transparent to Lisp code. Indeed.=20=20 Still, one problem with that variable is that it is no longer safe to base other (global) settings on the value of that variable. I think some defcustoms test this variable to select the default setting. But I suppose it works ok in practice. > Of course, the Lisp-level display/frame initialization code has > changed quite a bit, and a few libraries (first and foremost > server.el) have been enhanced for multi-tty support. >=20 > > Also, is the documentation on the multi-tty branch updated to reflect > > changes in interfaces etc. (where it matters). >=20 > I think it matters surprisingly little. Most of the things I changed > are (unfortunately) :-) undocumented.=20=20 That is good. > That said, a few nodes in the > Emacs manuals need to be updated to reflect the changes. Have you identified the sections of the emacs and elisp manuals that need to be changed? >=20 > 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? > I agree that the next release should be from the current HEAD, > without multi-tty. >=20 > --=20 > K=C3=A1roly >=20 >=20 --=20 Kim F. Storm http://www.cua.dk