auctex-devel
[Top][All Lists]
Advanced

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

[AUCTeX-devel] Re: 2008-03-12; AUC-TeX doesn't honor XEmacs toolbar visi


From: David Kastrup
Subject: [AUCTeX-devel] Re: 2008-03-12; AUC-TeX doesn't honor XEmacs toolbar visibility specification
Date: Thu, 17 Apr 2008 23:47:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2008-04-16) writes:
>
>> Anybody on the developer list who'd have an idea about what the
>> problem could be here?
>
> Isn't it obvious?  He is using XEmacs.

How does it make us look when we appear too stupid to get along with
XEmacs as long as there are still users that manage it?

Something like that.

>> Didier Verna <address@hidden> writes:
>>
>>> XEmacs provides a set of custom variables (specifiers actually) to
>>> control the visilibity of the toolbar(s). These are
>>> ((default|left|right|top|bottom)-)?toolbar-visible-p. It seems that
>>> AUC-TeX doesn't honor either of these (the toolbar is displayed
>>> whatever their value).
>
> I really don't get how these variables are supposed to work.

They are specifiers.

> Why does everything in XEmacs have to be so contorted?

Because it is versatile: you can specify how something should look in a
particular buffer, in a particular frame, on a particular display, in
general a "locale".  That's the idea.  We have something like that for
face definitions in Emacs, where you can specify face details per
display capability and based on brightness.

Try
M-x customize-face RET highlight RET
and then press "State -> For All Kinds of Displays"

and then you get a lot of special-cased stuff.  XEmacs specifiers are a
sort of generalizations and they work for images, toolbars, menu bars
and other stuff.

Really a brilliant and versatile idea.  Apparently.  Unfortunately, I've
never understood anything about them.  It has been some time since I
tried last time.  Problem is that they are not an opaque data structure,
no really complete set of accessor functions exists, the documentation
is a maze of cross-referring incomplete fragments, it is not clear when
and how a "specifier" gets replaced by an "instantiation" and what that
means and so on.  Things might have improved since I last looked,
possibly.  No idea.

I have read something akin to "hope you did not use setq on those, they
are specifiers" concerning some of those variables on the XEmacs
developer list.

I probably come across as a complete nutcase, but anyway, the gist of
this may be: if there are ways to tell XEmacs "don't show this if the
toolbar is supposed to be off" or to _know_ when to do something
particular or not, and some XEmacs user can figure this out, or can
figure out which questions to ask on xemacs-beta, this might get us a
good measure forward to doing the right thing.

> At least for the easy case of `toolbar-visible-p' the following patch
> seems to do the trick.  However, setting `toolbar-visible-p' to t in a
> LaTeX buffer will display the tool bar with the default buttons, not
> with LaTeX-specific ones.  So one could probably put the test
> somewhere earlier into the call stack.
>
> --- toolbar-x.el.~1.17.~      2008-02-09 19:39:05.000000000 +0100
> +++ toolbar-x.el      2008-04-17 21:57:44.000000000 +0200
> @@ -1622,7 +1622,7 @@
>                         left-width)))
>      ;; deal with specifiers
>      ;; - remove all specifiers for toolbars witout buttons
> -    (if default
> +    (if (and default toolbar-visible-p)
>       (progn
>         (if (memq (default-toolbar-position) '(top bottom))
>             (set-specifier default-toolbar-visible-p

I have my doubts this is correct.  The
(set-specifier default-toolbar-visible-p ...
seems to indicate that the respective variable takes specifiers that
would conceivably depend...

Actually, I have no clue.  It is obvious that we need to do something
about this in AUCTeX, but I suppose we need to ask somebody who
understands this specifier business.

Didier, any idea who'd be the right person to question?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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