* Re: Keymaps on images have pretty much stopped working [not found] ` <m3d69ztg1e.fsf@kfs-l.imdomain.dk> @ 2004-01-06 23:45 ` Kim F. Storm 2004-01-07 0:23 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Kim F. Storm @ 2004-01-06 23:45 UTC (permalink / raw) Cc: emacs-devel > David Kastrup <dak@gnu.org> writes: > > > Ok, I'll try again to make an example. I have just committed a fix. This involves modifying the layout of the mouse event. As an added bonus, the actual width and height of the image is now included in the event (so you can now make relative position calculations). I still need to fix the posn-* functions and correct the documentation. > > > And with larger > > buffers with lots of icons I also had the situation where the wrong > > icons thought they were clicked on. > > I don't know for sure, but this may be fixed as well. Please report if it still occurs. > > Pressing C-h k followed by a middle mouse click on either icon causes > > an error (with backtrace if debug-on-error is t). This works now. -- Kim F. Storm http://www.cua.dk ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Keymaps on images have pretty much stopped working 2004-01-06 23:45 ` Keymaps on images have pretty much stopped working Kim F. Storm @ 2004-01-07 0:23 ` David Kastrup 2004-01-07 0:49 ` David Kastrup 2004-01-07 6:09 ` Eli Zaretskii 2 siblings, 0 replies; 5+ messages in thread From: David Kastrup @ 2004-01-07 0:23 UTC (permalink / raw) Cc: emacs-devel no-spam@cua.dk (Kim F. Storm) writes: > > David Kastrup <dak@gnu.org> writes: > > > > > Ok, I'll try again to make an example. > > I have just committed a fix. This involves modifying the layout of > the mouse event. As an added bonus, the actual width and height of > the image is now included in the event (so you can now make relative > position calculations). At first glance, this seems to work again. Thanks. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Keymaps on images have pretty much stopped working 2004-01-06 23:45 ` Keymaps on images have pretty much stopped working Kim F. Storm 2004-01-07 0:23 ` David Kastrup @ 2004-01-07 0:49 ` David Kastrup 2004-01-07 6:09 ` Eli Zaretskii 2 siblings, 0 replies; 5+ messages in thread From: David Kastrup @ 2004-01-07 0:49 UTC (permalink / raw) Cc: emacs-devel no-spam@cua.dk (Kim F. Storm) writes: > > David Kastrup <dak@gnu.org> writes: > > > Pressing C-h k followed by a middle mouse click on either icon causes > > > an error (with backtrace if debug-on-error is t). > > This works now. I get the following here (as an example): <mouse-3> (translated from <down-mouse-3> <mouse-3>) at that spot runs the command (lambda (event) (interactive "e") (preview-context-menu #<overlay from 1327 to 1345 in diffspeed.tex> event)) which is an interactive Lisp function. (anonymous EVENT) Not documented. This is quite correct and nice, except for the mysterious (anonymous EVENT) line which fails to look like something recognizable by ordinary humans. If I wanted to bicker (not me, would I?), I might also notive that the line breaking and indendation seems a bit odd. If I compare this with, say, C-g, I have C-g runs the command keyboard-quit which is an interactive compiled Lisp function in `simple'. It is bound to C-g. (keyboard-quit) Signal a `quit' condition. During execution of Lisp code, this character causes a quit directly. Now it is apparent that the (anonymous EVENT) line is probably supposed to be equivalent to the (keyboard-quit) line. I find even the (keyboard-quit) line quite disingenious: its purpose is not obvious. It becomes more apparent with commands like M-!: ESC ! (translated from <escape> !) runs the command shell-command which is an interactive compiled Lisp function in `simple'. It is bound to M-!, <menu-bar> <tools> <shell>. (shell-command COMMAND &optional OUTPUT-BUFFER ERROR-BUFFER) Execute string COMMAND in inferior shell; display output, if any. With prefix argument, insert the COMMAND's output at point. [...] So it would appear to be a synopsis to go with the DOC string. I'd say at least an empty line before it would make sense (after all, it goes with the DOC string and _that_ is separated from it with a blank line). Personally, I'd say to remove that blank line above the DOC string and instead insert it before the function call synopsis. And I think in case of anonymous functions, the synopsis is wasted. Will we ever have a documentation string to go with it in the first place? Unlikely. And the arguments it takes are already apparent from the whole blurb quoting its lambda expression above. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Keymaps on images have pretty much stopped working 2004-01-06 23:45 ` Keymaps on images have pretty much stopped working Kim F. Storm 2004-01-07 0:23 ` David Kastrup 2004-01-07 0:49 ` David Kastrup @ 2004-01-07 6:09 ` Eli Zaretskii 2004-01-07 11:03 ` Kim F. Storm 2 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2004-01-07 6:09 UTC (permalink / raw) Cc: dak, emacs-devel > From: no-spam@cua.dk (Kim F. Storm) > Date: 07 Jan 2004 00:45:38 +0100 > > I have just committed a fix. This involves modifying the layout of > the mouse event. Does this affect in any way the text-mode platforms that support the mouse, like MS-DOS and xt-mouse? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Keymaps on images have pretty much stopped working 2004-01-07 6:09 ` Eli Zaretskii @ 2004-01-07 11:03 ` Kim F. Storm 0 siblings, 0 replies; 5+ messages in thread From: Kim F. Storm @ 2004-01-07 11:03 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@elta.co.il> writes: > > From: no-spam@cua.dk (Kim F. Storm) > > Date: 07 Jan 2004 00:45:38 +0100 > > > > I have just committed a fix. This involves modifying the layout of > > the mouse event. > > Does this affect in any way the text-mode platforms that support the > mouse, like MS-DOS and xt-mouse? > The recent additions to the mouse event only adds extra elements to the end of the existing list of information. The modification I was referring to was relative to my recent additions to the list, not to the original contents of the list. So it should be transparent. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-01-07 11:03 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <x5vfnsk99n.fsf@lola.goethe.zz> [not found] ` <E1AdDOG-0002DB-DH@fencepost.gnu.org> [not found] ` <x5r7yfqz6c.fsf@lola.goethe.zz> [not found] ` <m3d69ztg1e.fsf@kfs-l.imdomain.dk> 2004-01-06 23:45 ` Keymaps on images have pretty much stopped working Kim F. Storm 2004-01-07 0:23 ` David Kastrup 2004-01-07 0:49 ` David Kastrup 2004-01-07 6:09 ` Eli Zaretskii 2004-01-07 11:03 ` Kim F. Storm
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.