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

[lorentey@elte.hu (Lőrentey Károly)]

[Resend to list]
Kim F. Storm <storm@cua.dk> writes:
> 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 am positive they are broken, and won't even compile.  I did not even
attempt to update them while working, because the branch was initially
very unstable (source reorganization, variable renamings, second
thoughts etc.), and it would have been impossible to keep the ports
that I can not compile in shape.  I decided to update them all in one
go, after the base code stabilized a bit.  The branch is quite stable
now, so I think it is time for me to begin that update.

> 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 am planning to do exactly that. :-)

>> > 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.

Yes; in theory, Elisp packages that refer to window-system need to be
updated for multi-tty support, but I found that in practice most of
them work fine without any changes.  Emacs behaves the same way as it
used to until the user actually creates simultaneous tty and X frames,
so the degradation (if any) is graceful.

>>                                        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?

Not yet.  I will leaf through the manuals sometime and take notes.

-- 
Károly