auctex-devel
[Top][All Lists]
Advanced

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

[AUCTeX-devel] toolbar quality.


From: David Kastrup
Subject: [AUCTeX-devel] toolbar quality.
Date: Sat, 02 Dec 2006 15:25:16 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

Hi,

I am less and less convinced that we should enable the toolbars by
default as long as we have no active developer who actually has a clue
how they work.

Here are two places which _clearly_ spell trouble to me.

toolbar-x.el:1620:

    ;; un-reverting variables
    (setq default (nreverse default))
    (setq top     (nreverse top))
    (setq right   (nreverse right))
    (setq bottom  (nreverse bottom))
    (setq left    (nreverse left))

It is clear from the preceding code that the values on which nreverse
is executed are _not_ consed there but passed in from other data
structures, and as a result, those other data structures are
_destroyed_ in the process.

grepping for nreverse turns up several other instances where nreverse
appears to destroy lists that are passed in from somewhere else.

As a rule, nreverse is the wrong function to use if the list has not
been consed up by local code in the same function and it is known that
no other references to the list exist.

Then we have

toolbar-x.el:1327:

    (let (tool-bar-map)
      (set (make-local-variable 'tool-bar-map) (make-sparse-keymap))

where the make-local-variable operates on a let-binding, a _huge_
nono.  The whole code in which this is embedded reeks of "workaround",
and it is not even clear what it is trying to work around.  Which
makes it harder to guess what would be required, and why.

And we have repeated reports that enabling/disabling the toolbar
renders Emacs and/or XEmacs non-functional in certain circumstances.

If we don't find anybody willing to
a) audit the toolbar code and fix obvious blunders like the ones I
listed.
b) get acquainted more than superficially with its operation

I don't see how we can justify leaving it enabled by default.  The
current state of affairs does not cut it.

Miguel, any chance you'll be able to look at some of the problems?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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