auctex-devel
[Top][All Lists]
Advanced

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

[AUCTeX-devel] Re: toolbar quality.


From: Reiner Steib
Subject: [AUCTeX-devel] Re: toolbar quality.
Date: Sat, 02 Dec 2006 19:51:40 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux)

On Sat, Dec 02 2006, Ralf Angeli wrote:

> * David Kastrup (2006-12-02) writes:
>> 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.

No doubt that you have much more clue about Lisp subtleties than me.
But I'm quite sure that the previous code modified the global value
<http://thread.gmane.org/v98xknj3dd.fsf%40marauder.physik.uni-ulm.de>.
Also Nick's report suggests that the global value was modified (using
11.83).

What do you suggest instead of `make-local-variable'?  Or do you
suggest to move it up before the `let' expression?

BTW, why do we have `setq-default' in `toolbarx-emacs-refresh' if we
don't make the variable buffer local?  Maybe the bug is in
`toolbarx-emacs-add-button': Does
  (setq tool-bar-map (copy-sequence temp-tool-bar-map))
look correct?

> Reiner, can we revert that change and get a reproducible test case
> which shows the LaTeX tool bar appearing in non-LaTeX buffers?  That
> way we might find a better fix.
>
> Besides, I'm still waiting for a reproducible test case for the tool
> bar becoming empty.  If somebody has such a thing ...

My change wasn't for the "LaTeX tool bar appearing in non-LaTeX
buffers" bug, but for the "tool bar becoming empty" bug.  IIRC, you
and me both weren't able to reproduce the former bug (reported by Nick
Roberts using 11.83) with the current code from CVS.

The "tool bar becoming empty" bug was reproducible for me and my
colleagues at my site.  But I guess there the need for some
site-specific settings, a hook or somesuch or loading some buffers
(via desktop?).  With «emacs -Q --eval '(load "auctex.el" nil t t)'» I
can't tickle the bug (after reverting my change), but with a normal
session, I can.  Iow, I don't have a simple test case at hand and I
don't have time to dig into this, sorry.

[ citation supplemented ]
>> And we have repeated reports that enabling/disabling the toolbar
>> renders Emacs and/or XEmacs non-functional in certain circumstances.
[...]
>> I don't see how we can justify leaving it enabled by default.  The
>> current state of affairs does not cut it.

We have it enabled in CVS for half a year in CVS.  I don't recall more
user-visible problems beside Nick's and my report (I'm offline in the
train, so I can't check the archives ATM).

My *guess* is that >= 90% of our users don't even know how to / don't
ever want to turn off the tool bar.  I think the benefit of the TeX
buttons outweighs the rare (?) problems.

(Unfortunately Gnus behaves much worse WRT tool bar off/on, IIRC.)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/





reply via email to

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