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

[storm@cua.dk (Kim F. Storm)]

Lőrentey Károly 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!  
> >
> > 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).
> 
> 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.  

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.
> 
> > Also, is the documentation on the multi-tty branch updated to reflect
> > changes in interfaces etc. (where it matters).
> 
> I think it matters surprisingly little.  Most of the things I changed
> are (unfortunately) :-) undocumented.  

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?

> 
> 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.
> 
> -- 
> Károly
> 
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk