Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: > The example that you gave at the start didn't toggle anything: it just > added a function to tooltip-hook. Right, sorry. It would have been better to poste the complete minor mode function. --8<---cut here---start->8--- (defun rdictcc-tooltip-mode (&optional arg) "Display tooltips with the translations of the word under the mouse pointer." (interactive "P") (require 'tooltip) (require 'gud) ;; The tooltips are currently part of GUD (let ((val (if arg (> (prefix-numeric-value arg) 0) (not rdictcc-tooltip-mode (if val ;; Switch tooltip mode on (progn (make-local-variable 'rdictcc-tooltip-mode) (setq rdictcc-tooltip-mode val) (make-local-variable 'tooltip-delay) (setq tooltip-delay rdictcc-tooltip-delay) (gud-tooltip-mode 1) (add-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t t) (make-local-variable 'track-mouse) (setq track-mouse val)) ;; Switch tooltip mode off (kill-local-variable 'rdictcc-tooltip-mode) (kill-local-variable 'tooltip-delay) (kill-local-variable 'track-mouse) (remove-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t --8<---cut here---end--->8--- > Anyway, I'll look at splitting out the functionality after the > release. Thanks a lot. > The pretest is meant to be imminent, but the last one for Emacs 21 > took about a year, so I wouldn't hold your breath. No problem. I'll be patient. Bye, Tassilo -- My opinions may have changed, but not the fact that I am right. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
> > It might be fine for personalising Emacs but not a general package. > > Your construction above adds the function to the hook at the end. So, > > for example, if that's in a buffer that I'm using for debugging, the > > tooltips will display translations of my variable names rather than > > their values, which might not be what I want. > > Sure, but my rdictcc-tooltip-mode as well as dictionary-el's tooltip > mode are buffer local. If a user enables one of them in a debugging > buffer he might really want translations. After toggling the mode off, > the GUD-tooltips will be back again. The example that you gave at the start didn't toggle anything: it just added a function to tooltip-hook. Anyway, I'll look at splitting out the functionality after the release. The pretest is meant to be imminent, but the last one for Emacs 21 took about a year, so I wouldn't hold your breath. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: Hi Nick, > It might be fine for personalising Emacs but not a general package. > Your construction above adds the function to the hook at the end. So, > for example, if that's in a buffer that I'm using for debugging, the > tooltips will display translations of my variable names rather than > their values, which might not be what I want. Sure, but my rdictcc-tooltip-mode as well as dictionary-el's tooltip mode are buffer local. If a user enables one of them in a debugging buffer he might really want translations. After toggling the mode off, the GUD-tooltips will be back again. I mean, there are always minor modes which can conflict, so the user has to decide what he needs at a time. Enabling flyspell-mode in a buffer with elisp code will overwrite the normal font-locking, which might be exactly what the user wants. Bye, Tassilo -- VI VI VI - The Roman Number Of The Beast ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
> > I think thats the problem of just adding to tooltip-hook. You have a > > list of functions and the last non-nil one wins. > > Yeah, so I'm fine with appending my function (locally) to the hook like > this: > > (add-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t t) Well I guess it depends which buffers the local hook gets added too. > > > Anyway, I think those event-based tooltips are useful for a lot of > > > tasks where calculation of the tooltip contents is time-intensive > > > and should not be performed beforehand. So splitting it out into an > > > own library `event-tooltip' or so would be a good idea. > > > > Well, it's part of the answer. > > ??? > > I don't get you here. Part of which answer? It might be fine for personalising Emacs but not a general package. Your construction above adds the function to the hook at the end. So, for example, if that's in a buffer that I'm using for debugging, the tooltips will display translations of my variable names rather than their values, which might not be what I want. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: > It returns nil in buffers where GUD tooltips are not meant to work i.e > when the major-mode is not a member of gud-tooltip-modes. > > I think thats the problem of just adding to tooltip-hook. You have a > list of functions and the last non-nil one wins. Yeah, so I'm fine with appending my function (locally) to the hook like this: (add-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t t) > > Anyway, I think those event-based tooltips are useful for a lot of > > tasks where calculation of the tooltip contents is time-intensive > > and should not be performed beforehand. So splitting it out into an > > own library `event-tooltip' or so would be a good idea. > > Well, it's part of the answer. ??? I don't get you here. Part of which answer? Bye, Tassilo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
> The only drawback of this is that I load too much (the whole GUD stuff > instead of only the tooltip functionality), thus consuming a little more > memory than necessary. Another drawback is that on every mouse event > `gud-tooltip-tips' is executed (returning nil). If this is all, that's > no big problem for me. It returns nil in buffers where GUD tooltips are not meant to work i.e when the major-mode is not a member of gud-tooltip-modes. I think thats the problem of just adding to tooltip-hook. You have a list of functions and the last non-nil one wins. > Anyway, I think those event-based tooltips are useful for a lot of tasks > where calculation of the tooltip contents is time-intensive and should > not be performed beforehand. So splitting it out into an own library > `event-tooltip' or so would be a good idea. Well, it's part of the answer. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: Hi Nick, > I don't know what dictionary-el or your mode do but, if possible, its > best to add tooltips through the `help-echo' text property. My mode [1] opens a tooltip with translations of the word you're pointing at. The translation is done by an external Ruby script. Of course the translation process should only run if the user points at the word for a given amount of time (e.g. `tooltip-delay'). The problem with `help-echo' is that I would have to propertize every word in the buffer before tooltips would be available, thus I would have to call that external script on every word. This would take a lot of time and memory consumtion would increase dramatically, because every word would hold a set of possible translations in its `help-echo' property. Most of this work would be superfluous anyway, because normally the user knows most words and only needs translations of a handfull new words. Another thing with `help-echo' is that I would need to propertize newly typed words on the fly. (Ok, this should be possible somehow, flyspell does this, too.) > If dictionary-el is generally useful and it needs GUD-type tooltips > then the best way to do this might be to make it part of Emacs. dictionary-el is quite similar, but instead querying an external Ruby script it queries a dict server, so it's more general than simple word-translation, but IMHO most dict dictionaries are quite outdated (at least the translation dicts), which was the reason to write my own tool. To make it short: I would not include it, but the author may think different. Currently I'm fine with (require 'gud) (gud-tooltip-mode 1) [...] The only drawback of this is that I load too much (the whole GUD stuff instead of only the tooltip functionality), thus consuming a little more memory than necessary. Another drawback is that on every mouse event `gud-tooltip-tips' is executed (returning nil). If this is all, that's no big problem for me. Anyway, I think those event-based tooltips are useful for a lot of tasks where calculation of the tooltip contents is time-intensive and should not be performed beforehand. So splitting it out into an own library `event-tooltip' or so would be a good idea. Bye, Tassilo Footnotes: [1] http://www.uni-koblenz.de/%7Eheimdall/apps.php -- A child of five could understand this! Fetch me a child of five! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
> > dictionary-el isn't part of Emacs 22. I have split GUD tooltips > > (which use track-mouse from ordinary ones (which don't). > > dictionary-el and my own mode display tooltips based on the word under > the mouse pointer. The event based approach makes it easy to extract the > word. If there's a better way, please let me know. I don't know what dictionary-el or your mode do but, if possible, its best to add tooltips through the `help-echo' text property. > Currently I use an own timer an lots of ugly code to work arround this. > > > This means that they can be toggled independently. At some stage, if > > other packages want to use tooltips in the way GUD does, that part > > could be split out of gud.el. > > That would be really nice. If dictionary-el is generally useful and it needs GUD-type tooltips then the best way to do this might be to make it part of Emacs. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: Hi Nick, > > | (setq track-mouse on)) >^^^ t? Just a typo. > > | (defun my-tooltip-function (event) > > | (interactive "e") > > | ;; process event... > > | (tooltip-show "Huzzah!")) > > ` > > This didn't seem to work very well on Emacs 21 when I tried it. Also > there's no mechanism to remove my-tooltip-function from tooltip-hook. > > You can get it to work as before by using: > > (defun my-tooltip-mode (&optional arg) >;; [snip] >(gud-tooltip-mode 1) > ^^^ Indeed, this works. > > This convenient approach (used for example by dictionary-el) > > doesn't work anymore in Emacs 22. > > dictionary-el isn't part of Emacs 22. I have split GUD tooltips > (which use track-mouse from ordinary ones (which don't). dictionary-el and my own mode display tooltips based on the word under the mouse pointer. The event based approach makes it easy to extract the word. If there's a better way, please let me know. Currently I use an own timer an lots of ugly code to work arround this. > This means that they can be toggled independently. At some stage, if > other packages want to use tooltips in the way GUD does, that part > could be split out of gud.el. That would be really nice. Bye, Tassilo -- A child of five could understand this! Fetch me a child of five! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: > You can get it to work as before by using: > > (defun my-tooltip-mode (&optional arg) >;; [snip] >(gud-tooltip-mode 1) > ^^^ Simply change (tooltip-mode 1) to (gud-tooltip-mode 1) seems work well. Hope someone can make a proper patch for dictionary-el. It's a nice feature. -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
> I'm not quite sure if this is a bug or a intended change in tooltip > handling, but here I go. > > Supporting own tooltips in Emacs 21 was basically a matter of: > > , > | (defun my-tooltip-mode (&optional arg) > | ;; [snip] > | (tooltip-mode 1) > | (add-hook 'tooltip-hook 'my-tooltip-function) > | (make-local-variable 'track-mouse) > | (setq track-mouse on)) ^^^ t? I don't think this is the right way to use track-mouse anyway . > | (defun my-tooltip-function (event) > | (interactive "e") > | ;; process event... > | (tooltip-show "Huzzah!")) > ` This didn't seem to work very well on Emacs 21 when I tried it. Also there's no mechanism to remove my-tooltip-function from tooltip-hook. You can get it to work as before by using: (defun my-tooltip-mode (&optional arg) ;; [snip] (gud-tooltip-mode 1) ^^^ > This convenient approach (used for example by dictionary-el) doesn't > work anymore in Emacs 22. dictionary-el isn't part of Emacs 22. I have split GUD tooltips (which use track-mouse from ordinary ones (which don't). This means that they can be toggled independently. At some stage, if other packages want to use tooltips in the way GUD does, that part could be split out of gud.el. It would need to be documented so that they could be used in a way that doesn't interfere with existing use, as your example does. > If I set `track-mouse' to a non-nil value, > even the standard tooltips which worked before (e.g. the modeline help > tooltips) don't work anymore. track-mouse is a variable, not a user uption for tooltips. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Bug in tooltip handling
Hi all, I'm not quite sure if this is a bug or a intended change in tooltip handling, but here I go. Supporting own tooltips in Emacs 21 was basically a matter of: , | (defun my-tooltip-mode (&optional arg) | ;; [snip] | (tooltip-mode 1) | (add-hook 'tooltip-hook 'my-tooltip-function) | (make-local-variable 'track-mouse) | (setq track-mouse on)) | | (defun my-tooltip-function (event) | (interactive "e") | ;; process event... | (tooltip-show "Huzzah!")) ` This convenient approach (used for example by dictionary-el) doesn't work anymore in Emacs 22. If I set `track-mouse' to a non-nil value, even the standard tooltips which worked before (e.g. the modeline help tooltips) don't work anymore. I use the CVS HEAD of yesterday. Bye, Tassilo -- [Emacs] is written in Lisp, which is the only computer language that is beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
