[AUCTeX-devel] Re: Toolbar button for TeX-command-master

[Ralf Angeli]

While Reiner is messing with Gnus' tool bars I thought I mess a bit
with AUCTeX's and follow up on this rather rusty message.

* David Kastrup (2005-05-22) writes:

> Ralf Angeli <address@hidden> writes:
>
>> * David Kastrup (2005-05-22) writes:
>>
>>> Ralf Angeli <address@hidden> writes:
>>>
>>>> In case somebody wants to have a toolbar button for
>>>> `TeX-command-master', you can check out the attached patch.
>>>>
>>>> The button does not update the displayed image.  You will always see
>>>> the cog wheels.
>>>
>>> I think at least the tooltip should mention what the button does,
>>
>> Hm, the functions for computing help strings specified in
>> `TeX-bar-LaTeX-button-alist' will get evaluated only when the
>> toolbar is being built.
>
> Is that a bug?
>
>> It would be quite easy to get dynamic tooltips if the functions were
>> copied verbatim.
>
> Please not.  We have enough work on our hands without reinventing
> Emacs.
>
>> This seems to work although the documentation only says this:
>>
>> ,----[ (info "(elisp)Tool Bar") ]
>> |    The `:help' property specifies a "help-echo" string to display while
>> | the mouse is on that item.  This is displayed in the same way as
>> | `help-echo' text properties (*note Help display::).
>> `----
>
> Help echo properties can be dynamic AFAIR.  If the documentation is
> not accurate here, Emacs should get fixed.

Currently toolbar-x sets the help echo to a string (via
`toolbarx-test-string-or-nil') even if a function was specified.  The
reason seems to be that XEmacs does not support dynamic help echoes.

While something like

(tool-bar-add-item "exit" nil nil
                   :help (lambda (&rest ignored)
                           (number-to-string (nth 1 (current-time)))))

is working in Emacs, the expression

(set-specifier default-toolbar
               (list (vector (list (make-glyph "X")) 'ignore t
                             (lambda () "Huzzah!")))
               (current-buffer))

fails in XEmacs.  (It works if you replace the lambda expression with
a simple string.)

I am not sure if we need to try and find a solution for this.  Firstly
because a button changing its action under certain conditions does not
seem to be the best idea user-interface-wise.  And if we try to remedy
this problem by displaying different button images depicting the next
action, a button which dynamically updates its help echo as soon as
one hovers with the mouse pointer over it won't buy us anything.
That's because we have to update the image without user interaction.

For example if the next action were "View", we'd have to change it to
"LaTeX" as soon as the file in question was edited and saved because
that's what the next action would be if you used `C-c C-c'.  The crux
here is that we can only be sure that the next action is "LaTeX" after
the user saved the file.  That's because we normally ask the user if
she wants to save the file when typing `C-c C-c'.  If she does not
save it, the next action will be "View".

>> The strange part about this is that the function for calculating the
>> help string is called with three arguments.  Don't ask me what those
>> are.  Oh, and I don't know if all that would be possible in XEmacs.
>>
>> Also, there will have to be some more changes.  Because when testing
>> this I got a question if I want to save the document when hovering
>> over the button.
>
> AIIII!  Forget I ever asked.  Seems like something for after the
> release.
>
>>> and it might make sense to compute the button's action on
>>> mouse-over, too, and then change the image to the specific one
>>> while mouse-over is active.
>>>
>>> This is still a hack, but you'd at least know what the button does
>>> before pressing it.  And I think that is essential.
>>
>> I don't know if I want to implement that with the current state of
>> tool chain handling.
>
> Sounds very sane.  Let the magic button be post-release.  Too many
> intricacies involved here.  Just let's keep this problem in mind in
> case the toolchain code gets a haulover at some time.

Given the issues mentioned above I am currently more inclined to drop
the idea of a step-by-step DWIM button altogether and rather change
the toolchain in a way that we can have a do-everything-in-one-step
button, i.e. run latex, bibtex, xindy, dvips, whatsitsname
automatically as often as needed and update the viewer.  Uhm, yes, the
thing we are talking about all the time anyway.

-- 
Ralf