[Top][All Lists]

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

Re: The display margin

From: Kim F. Storm
Subject: Re: The display margin
Date: 23 Nov 2003 03:08:25 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Hi Nick (and the rest of the emacs-devel team),

I have just checked in fixes to improve event handling for mouse
clicks in the marginal areas and on the fringes.  Events now have
additional information:


AREA-OR-POS is not changed as such -- but it may now contain
left-fringe and right-fringe.

For clicks in the text area, POS is the same as AREA-OR-POS (the
buffer position clicked on).  For clicks in other areas, POS is the
buffer position of the first visible glyph on the corresponding row.

As an example, try M-x gdba and click mouse-1 on the left margin or
fringe of a source window [it should toggle breakpoint on that line].

[Note: Some strange scrolling happens if I remove a breakpoint in the
lower half of a window, but I strongly suspect this has something to
do with comint doing strange things to the wrong window  -- as I have
traced this (using gdba :-) and it seems to happens inside a comint
filter or some such -- when stepping, it actually happens to scroll
and redisplay the window BEFORE the breakpoint icon disappears.]

Docs in commands.texi have been updated to reflect changes.

Note that previously mouse click on fringes were just handled like
clicks in the text area.  Now they are separate event types, so I have
added bindings for them in mouse.el to allow h-scrolling by clicking
on fringes to work as before. 

If mouse events starts to behave differently than before, pls. let me


Nick Roberts <address@hidden> writes:

>  > You might try something like:
>  > 
>  >    (defun gud-break (&optional event)
>  >      "Set break point."
>  >      (interactive (list last-input-event))
>  >      ;; Go to wherever the event happened.
>  >      (if event (ignore-errors (mouse-set-point event)))
>  >      ...)
>  > 
>  > I haven't tried it, tho.  Also you might need to use separate functions
>  > for gud-break-from-toolbar than gud-break-from-margin.
> If you mean:
> (defun gud-break (&optional event)
>   "Set break point."
>   (interactive (list last-input-event))
>   ;; Go to wherever the event happened.
>   (if event (ignore-errors (mouse-set-point event)))
>   (gud-call "break %f:%l" nil))
> This works fine in the text area but I don't want to redefine any mouse clicks
> there. And it doesn't work in the margin presumably because the point can't
> be set there.
> Clicking on the text area gives positions like:
> (#<window 9 on myprog.c> 132 (19 . 163) 114022256)
> whereas the on the left margin gives:
> (#<window 9 on myprog.c> left-margin (4 . 164) 114018986)
> I don't know enough about emacs internals to know if the line number can be
> easily inferred from the X-Y co-ordinates. However, since the width and height
> of the margin are also expressible in characters could the postion not be
> expressed as something like:
> (#<window 9 on myprog.c> (left-margin . 32) (4 . 164) 114018986)
> where 32, say, gives the character position in the margin (from which the line
> number can easily be calculated)?
> Nick
> _______________________________________________
> Emacs-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

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