The display margin

The display margin

[Nick Roberts]

Following Kim's changes, I thought it might be timely to ask a question
about the display margin.

When a breakpoint is set, using M-x gdba as debugger, an icon is placed in the
margin. The toolbar can be used to do this but the cursor must be placed on the
appropriate line beforehand. I would like to be able to do this directly with a
binding like:

(define-key gud-minor-mode-map [left-margin mouse-1] 'gud-break)

This does work but currently only if cursor is placed on the appropriate line
beforehand as with the toolbar.

Q: Could this binding be made to work, so that the breakpoint is set where
the click is made in the margin, regardless of the location of the cursor?

Nick

Re: The display margin

[Stefan Monnier]

> 
> Following Kim's changes, I thought it might be timely to ask a question
> about the display margin.
> 
> When a breakpoint is set, using M-x gdba as debugger, an icon is placed in the
> margin. The toolbar can be used to do this but the cursor must be placed on the
> appropriate line beforehand. I would like to be able to do this directly with a
> binding like:
> 
> (define-key gud-minor-mode-map [left-margin mouse-1] 'gud-break)
> 
> This does work but currently only if cursor is placed on the appropriate line
> beforehand as with the toolbar.
> 
> Q: Could this binding be made to work, so that the breakpoint is set where
> the click is made in the margin, regardless of the location of the cursor?

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.


	Stefan

Re: The display margin

[Nick Roberts]

 > 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

Re: The display margin

[Kim F. Storm]

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:

   (WINDOW AREA-OR-POS (X . Y) TIMESTAMP OBJECT POS (COL . ROW))

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
know.

++kfs

Nick Roberts <nick@nick.uklinux.net> 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
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[Nick Roberts]

 > 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:
 > 
 >    (WINDOW AREA-OR-POS (X . Y) TIMESTAMP OBJECT POS (COL . ROW))
 > 
 > 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].

Kim,

I like this very much. This means that at some stage the unintuitive tool bar
buttons for gud-break and gud-remove could go. Well for M-x gdba, at least.
Other debuggers in GUD would still need them. I will try to arrange for the
source buffer to always display the margin so that this feature can be used
when there are no prior breakpoints. Also the GDB command 'info line' says
which lines contain code. When I have time, I will try to work this in so
that breakpoints can only be set on those lines.

Thanks,

Nick

Re: The display margin

[David Kastrup]

Nick Roberts <nick@nick.uklinux.net> writes:

>  > 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:
>  > 
>  >    (WINDOW AREA-OR-POS (X . Y) TIMESTAMP OBJECT POS (COL . ROW))
>  > 
>  > 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].
> 
> Kim,
> 
> I like this very much.

The click information for GNU Emacs is quite insufficient, anyway.
XEmacs, as far as I can remember, can tell from an event what object
has been clicked on and what pixel relative to the object's origin
has been hit.  With GNU Emacs, in contrast, you have to set up a
separate keymap for every object in order to have a chance to find
out which of several ones have been clicked, and no chance of finding
the relative position at all.

And the object/click correlation is done at the time when you query
the event, not when the click was done: if you click in order to do a
cut&paste operation on some buffer, and Emacs churns away internally
at the time, finally places a dialog box "Explode now?" on the
screen, then finally processes the click event, it will associate at
it with the exploding object instead of what was on the screen at the
time of the click.

I digress.  Anyway, I want more information from clicks.  At the
very least, the object they appeared on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: The display margin

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Nick Roberts <nick@nick.uklinux.net> writes:
> 
> >  > 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:
> >  > 
> >  >    (WINDOW AREA-OR-POS (X . Y) TIMESTAMP OBJECT POS (COL . ROW))
> >  > 
> >  > 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].
> > 
> > Kim,
> > 
> > I like this very much.
> 
> The click information for GNU Emacs is quite insufficient, anyway.
> XEmacs, as far as I can remember, can tell from an event what object
> has been clicked on and what pixel relative to the object's origin
> has been hit.  With GNU Emacs, in contrast, you have to set up a
> separate keymap for every object in order to have a chance to find
> out which of several ones have been clicked, and no chance of finding
> the relative position at all.

The OBJECT part of an event (retrievable with the new posn-object
function) will give you the object clicked on, that is, if the object
you click on is an overlay string or display property string or image,
then the string and a character position in that string is returned.

I agree that for images, a relative pixel coordiante would be useful too;
I'll look into that.

> 
> And the object/click correlation is done at the time when you query
> the event, not when the click was done: if you click in order to do a
> cut&paste operation on some buffer, and Emacs churns away internally
> at the time, finally places a dialog box "Explode now?" on the
> screen, then finally processes the click event, it will associate at
> it with the exploding object instead of what was on the screen at the
> time of the click.

Yes, that may be true -- mouse events are put into the normal input
queue, so if there are other events (like async process i/o) going on
before emacs processes the input queue, it may hit the wrong object
before it gets a change to process it.

But I don't quite follow the line of thought above; emacs must have
processed the mouse event if it displays an "Explode now?" dialog box;
and as such, it must have a handle to the clicked-on object prior to
showing that dialog box.  Can you show me a piece of code which
demonstrates the problem?

> 
> I digress.  Anyway, I want more information from clicks.  At the
> very least, the object they appeared on.

Doesn't this work with my latest changes?

++kfs

Re: The display margin

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> > I digress.  Anyway, I want more information from clicks.  At the
> > very least, the object they appeared on.
> 
> Doesn't this work with my latest changes?

Thinking more about it, an image object isn't returned if you use a
display image property directly in the buffer.  It should work if you
use an display string property, and that string has a display image
property.

I'll see if I can improve that.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> The click information for GNU Emacs is quite insufficient, anyway.
> XEmacs, as far as I can remember, can tell from an event what object
> has been clicked on and what pixel relative to the object's origin
> has been hit.

I have just added this information to mouse clicks and two functions to
access it:

Function `posn-object' returns the object clicked on, either an image
or a cons (string . pos), or nil if there is nothing special at the
place where you click the mouse (use posn-point to look at that).

Function `posn-object-x-y' return a cons (dx . dy) which is the pixel
coordinates relative to the top left corner of the object (image or
character) that you click on.

In addition, the mouse cursor now changes to an arrow (rather than the
text mouse cursor) when it hoovers above an image.

Finally, when you use a block cursor, images are no longer shown in
"negative" when your window cursor is a filled block cursor (only the
border of the image is highlighted now).  So clicking on an image no
longer makes it "unreadable"...

> I digress.  Anyway, I want more information from clicks.  At the
> very least, the object they appeared on.

What more do you want ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > The click information for GNU Emacs is quite insufficient, anyway.
> > XEmacs, as far as I can remember, can tell from an event what object
> > has been clicked on and what pixel relative to the object's origin
> > has been hit.
> 
> I have just added this information to mouse clicks and two functions to
> access it:
> 
> Function `posn-object' returns the object clicked on, either an image
> or a cons (string . pos), or nil if there is nothing special at the
> place where you click the mouse (use posn-point to look at that).
> 
> Function `posn-object-x-y' return a cons (dx . dy) which is the pixel
> coordinates relative to the top left corner of the object (image or
> character) that you click on.
> 
> In addition, the mouse cursor now changes to an arrow (rather than the
> text mouse cursor) when it hoovers above an image.

Rationale for that?  Just interested.  Maybe this should rather depend
on an appropriate image property?

> Finally, when you use a block cursor, images are no longer shown in
> "negative" when your window cursor is a filled block cursor (only
> the border of the image is highlighted now).  So clicking on an
> image no longer makes it "unreadable"...

Oh great.  That means that all the complicated image border creation
stuff within preview-latex becomes unnecessary, and we'll have to
check for this functionality conditionally.  Any good idea for a test
for whether the previous terror blinking or the new border blinking is
used on images?

> > I digress.  Anyway, I want more information from clicks.  At the
> > very least, the object they appeared on.
> 
> What more do you want ?

Well, further preview-latex usability problems are that Emacs often
goes ballistic when large height images are concerned, particularly
larger than window size images.  Scrolling those to a particular
viewing position is pretty much impossible, scrollbar interaction is
nonworkable, and scroll-wheel stuff is pretty much unpredictable as
well (there have been Emacs versions where wheel-use could lead to
lockup with large images, I am not sure whether this is currently the
case).

When using XEmacs on such images, repeated use of Pagedown scrolled
larger-than-window images through at a pace of about one normal line
height per keypress.  While this was far from scrolling a window worth
of material, at least the scrolling made some progress and one had a
possibility to see all parts of such an image.

In contrast, IIRC, Emacs does not even touch the window-vscroll value
(which would move by a fraction of the image) unless at the very end
of buffer.

One possibility to see the effect it to use

C-h i d m Emacs RET C-x 2

and drag the mode line of the upper window such that the "Emacs"
headline is only partially visible.

Repeated presses of C-v will then stop on the headline and not make
any more progress.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: The display margin

[Stefan Monnier]

> Well, further preview-latex usability problems are that Emacs often
> goes ballistic when large height images are concerned, particularly
> larger than window size images.  Scrolling those to a particular
> viewing position is pretty much impossible, scrollbar interaction is
> nonworkable, and scroll-wheel stuff is pretty much unpredictable as
> well (there have been Emacs versions where wheel-use could lead to
> lockup with large images, I am not sure whether this is currently the
> case).

This indeed needs fixing.  I think one good way to fix it is if we could
easily change back&forth between pixel-positions and internal-positions
(which might look like click-event positions in that they should say
if and where the position is inside an image).

This way we could compute the pixel-position of the middle of the window,
then compute the logical internal-position corresponding to it and move
that to windows-start (using vscroll if necessary).

The pos-to-pixel translation has also been requested by people who want to
popup tooltips or menus at point (rather than at the mouse-position).


        Stefan

Re: The display margin

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> > In addition, the mouse cursor now changes to an arrow (rather than the
> > text mouse cursor) when it hoovers above an image.
> 
> Rationale for that?  Just interested.  Maybe this should rather depend
> on an appropriate image property?

That would be an improvement, yes.  Will see what I can do.

The rationale is that the "active point" of text cursor (the vertical
bar) is somewhere in the middle of the vertical line, i.e. it's no
good as a pointer if you want to have precise clicks on an image.

But of course, if that image is showing text, a text cursor may
still make sense...

> 
> > Finally, when you use a block cursor, images are no longer shown in
> > "negative" when your window cursor is a filled block cursor (only
> > the border of the image is highlighted now).  So clicking on an
> > image no longer makes it "unreadable"...
> 
> Oh great.  That means that all the complicated image border creation
> stuff within preview-latex becomes unnecessary, and we'll have to
> check for this functionality conditionally.  

Is this good or bad?

>                                              Any good idea for a test
> for whether the previous terror blinking or the new border blinking is
> used on images?

Well, in principle, any test that identifies this as GNU Emacs 21.4 or
newer would do...  But if you want something which really narrows
down when this was introduced, (fboundp 'posn-object-x-y) will do.

I suppose you already have checks for different versions in preview-latex?

> 
> > > I digress.  Anyway, I want more information from clicks.  At the
> > > very least, the object they appeared on.
> > 
> > What more do you want ?

I was just asking in the context of "required information in mouse
click events".  Your answer seems to be "nothing further".

> 
> Well, further preview-latex usability problems are that Emacs often
> goes ballistic when large height images are concerned, particularly
> larger than window size images.  Scrolling those to a particular
> viewing position is pretty much impossible, scrollbar interaction is
> nonworkable, and scroll-wheel stuff is pretty much unpredictable as
> well (there have been Emacs versions where wheel-use could lead to
> lockup with large images, I am not sure whether this is currently the
> case).

I know it's an issue, and I will look into it.
 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > > In addition, the mouse cursor now changes to an arrow (rather
> > > than the text mouse cursor) when it hoovers above an image.
> > 
> > Rationale for that?  Just interested.  Maybe this should rather
> > depend on an appropriate image property?
> 
> That would be an improvement, yes.  Will see what I can do.
> 
> The rationale is that the "active point" of text cursor (the
> vertical bar) is somewhere in the middle of the vertical line,
> i.e. it's no good as a pointer if you want to have precise clicks on
> an image.
> 
> But of course, if that image is showing text, a text cursor may
> still make sense...

In general, a change of cursor is an indicator that the behavior of
clicking will change.  Since different cursors might indicate
different behaviors, it certainly makes sense to have this as a
separate property.

Now the question is whether one would want a change of cursor in case
such a specific property is _not_ present.  One can't see in advance
whether the user will call one of the pixel-accurate functions for
finding out the position of a click, so we have no clue about the
necessity for aiming.  Since the position functions are new, as long
as we introduce the cursor change properties at about the same time,
programmers will have the possibility to get a changed cursor when
they want a better aim for their users.

Now there is one situation when one _does_ have a
change-of-behavior-on-click, and that is when we have a local keymap
on the image, in particular one with mouse clicks in it.  But this is
not really fundamentally different from textual buttons (like the
widgets used in customization buffers).  So _if_ we get a default
cursor change, I think it should be orthogonal to the image issue and
rather depend on keymaps.

> > > Finally, when you use a block cursor, images are no longer shown
> > > in "negative" when your window cursor is a filled block cursor
> > > (only the border of the image is highlighted now).  So clicking
> > > on an image no longer makes it "unreadable"...
> > 
> > Oh great.  That means that all the complicated image border
> > creation stuff within preview-latex becomes unnecessary, and we'll
> > have to check for this functionality conditionally.
> 
> Is this good or bad?

It would have been even better if it had been done previously.

> > Any good idea for a test for whether the previous terror blinking
> > or the new border blinking is used on images?
> 
> Well, in principle, any test that identifies this as GNU Emacs 21.4
> or newer would do...  But if you want something which really narrows
> down when this was introduced, (fboundp 'posn-object-x-y) will do.

This has such an _indirect_ flavor to it.  Let's hope that nobody
does a branch having one but not the other feature.

> I suppose you already have checks for different versions in
> preview-latex?

Mostly not.  We have split out the functionality where Emacs and
XEmacs differ significantly into separate files (and where they differ
only in minor aspects, the XEmacs-specific file defines compatibility
macros during byte-compilation), but that's about it.

We don't want to have any compile-time checks beyond the basic
Emacs/XEmacs dichotomy: we already get enough reports by people trying
to use the .elc files compiled with one of them for the other.
Telling them to recompile for just upgrading the version would puzzle
them completely.

> > > > I digress.  Anyway, I want more information from clicks.  At
> > > > the very least, the object they appeared on.
> > > 
> > > What more do you want ?
> 
> I was just asking in the context of "required information in mouse
> click events".  Your answer seems to be "nothing further".

Actually, given that we now have a pixel-accurate position within the
object (maybe this is generalizable in some manner also for text?), it
would be nice having a way of knowing the pixel-accurate size of a
displayed object in the first place so that one can calculate the
relative position in the image easily, too.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: The display margin

[Thien-Thi Nguyen]

David Kastrup <dak@gnu.org> writes:

   Actually, given that we now have a pixel-accurate position within the
   object (maybe this is generalizable in some manner also for text?),
   it would be nice having a way of knowing the pixel-accurate size of a
   displayed object in the first place so that one can calculate the
   relative position in the image easily, too.

it is difficult to generalize this to text because the same text can be
presented differently depending on font, overlays, display properties
and probably many other influences i can't think of at the moment.  a
specific query (mouse click) can yield a specific answer but such info
is not inherently in the text (anymore).  w/ images it's easy of course.

this is the problem i'm mulling wrt determining what is the right thing
to do in order to support a fractional return value for the function
`current-column'.

thi

Re: The display margin

[David Kastrup]

Thien-Thi Nguyen <ttn@glug.org> writes:

> David Kastrup <dak@gnu.org> writes:
> 
>    Actually, given that we now have a pixel-accurate position within
>    the object (maybe this is generalizable in some manner also for
>    text?), it would be nice having a way of knowing the
>    pixel-accurate size of a displayed object in the first place so
>    that one can calculate the relative position in the image easily,
>    too.
> 
> it is difficult to generalize this to text because the same text can
> be presented differently depending on font, overlays, display
> properties and probably many other influences i can't think of at
> the moment.  a specific query (mouse click) can yield a specific
> answer but such info is not inherently in the text (anymore).

Well, it was just an idea.

> w/ images it's easy of course.

Is it?  What if the image type is PostScript or some other scalable
format, and the buffer is displayed on two frames on two different
displays with different resolutions?  Ok, I guess the answer is "this
will break Emacs", anyway.

Questions like that need the concerned window to be answerable, I
guess.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: The display margin

[Thien-Thi Nguyen]

   From: David Kastrup <dak@gnu.org>
   Date: 28 Nov 2003 17:02:31 +0100

   Well, it was just an idea.

it's the right idea.  whether nor my brain will grow enough to be able
to accomodate and realize it into code is another question...

   > w/ images it's easy of course.

   Is it?  What if the image type is PostScript or some other scalable
   format, and the buffer is displayed on two frames on two different
   displays with different resolutions?  Ok, I guess the answer is "this
   will break Emacs", anyway.

oops, didn't think of those cases.  yes, anything that scales, be it
text or image, presents a challenge for coordinating info between the
data and its presentation.  cyclic dependencies means someone has to cut
something somewhere...

   Questions like that need the concerned window to be answerable, I
   guess.

minimally, which view being asked must be known.

thi

Re: The display margin

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > David Kastrup <dak@gnu.org> writes:
> > 
> > > > In addition, the mouse cursor now changes to an arrow (rather
> > > > than the text mouse cursor) when it hoovers above an image.
> > > 
> > > Rationale for that?  Just interested.  Maybe this should rather
> > > depend on an appropriate image property?
> > 
> > That would be an improvement, yes.  Will see what I can do.
> > 
> > The rationale is that the "active point" of text cursor (the
> > vertical bar) is somewhere in the middle of the vertical line,
> > i.e. it's no good as a pointer if you want to have precise clicks on
> > an image.
> > 
> > But of course, if that image is showing text, a text cursor may
> > still make sense...
> 
> In general, a change of cursor is an indicator that the behavior of
> clicking will change.  Since different cursors might indicate
> different behaviors, it certainly makes sense to have this as a
> separate property.

I will add both a generic 'pointer' text property, and a specific
image :pointer property.  

Maybe also an image :keymap property, but that will require more work,
so I will have to investigate further before doing so.

> Now there is one situation when one _does_ have a
> change-of-behavior-on-click, and that is when we have a local keymap
> on the image, in particular one with mouse clicks in it.  But this is
> not really fundamentally different from textual buttons (like the
> widgets used in customization buffers).  So _if_ we get a default
> cursor change, I think it should be orthogonal to the image issue and
> rather depend on keymaps.

I think an explicit pointer property is better; then you can always
get the exact behaviour you want (who says that just because there is
a local keymap as some position, that keymap has any mouse-specific
bindings)?

> 
> > > > Finally, when you use a block cursor, images are no longer shown
> > > > in "negative" when your window cursor is a filled block cursor
> > > > (only the border of the image is highlighted now).  So clicking
> > > > on an image no longer makes it "unreadable"...
> > > 
> > Is this good or bad?
> 
> It would have been even better if it had been done previously.

That's life...

> 
> > or newer would do...  But if you want something which really narrows
> > down when this was introduced, (fboundp 'posn-object-x-y) will do.
> 
> This has such an _indirect_ flavor to it.  Let's hope that nobody
> does a branch having one but not the other feature.

Sure.  Maybe (boundp 'void-text-area-pointer) will be better as it's
in the C code [will be when my current fixes are committed in a few days].

> > I was just asking in the context of "required information in mouse
> > click events".  Your answer seems to be "nothing further".
> 
> Actually, given that we now have a pixel-accurate position within the
> object (maybe this is generalizable in some manner also for text?), it
> would be nice having a way of knowing the pixel-accurate size of a
> displayed object in the first place so that one can calculate the
> relative position in the image easily, too.

I'll look into adding this info as well ... at least for images.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > storm@cua.dk (Kim F. Storm) writes:
> > 
> > > But of course, if that image is showing text, a text cursor may
> > > still make sense...
> > 
> > In general, a change of cursor is an indicator that the behavior of
> > clicking will change.  Since different cursors might indicate
> > different behaviors, it certainly makes sense to have this as a
> > separate property.
> 
> I will add both a generic 'pointer' text property, and a specific
> image :pointer property.  
> 
> Maybe also an image :keymap property, but that will require more
> work, so I will have to investigate further before doing so.

I've been using keymaps on images for years already (via the display
property or so).  It was the only way to make an image clickable
since you could not enquire whether a click position was on an image
or on text beside it (at least for images on zero-width overlays).

> > > or newer would do...  But if you want something which really
> > > narrows down when this was introduced, (fboundp
> > > 'posn-object-x-y) will do.
> > 
> > This has such an _indirect_ flavor to it.  Let's hope that nobody
> > does a branch having one but not the other feature.
> 
> Sure.  Maybe (boundp 'void-text-area-pointer) will be better as it's
> in the C code [will be when my current fixes are committed in a few
> days].

Guess we'll find something.

> > > I was just asking in the context of "required information in
> > > mouse click events".  Your answer seems to be "nothing further".
> > 
> > Actually, given that we now have a pixel-accurate position within
> > the object (maybe this is generalizable in some manner also for
> > text?), it would be nice having a way of knowing the
> > pixel-accurate size of a displayed object in the first place so
> > that one can calculate the relative position in the image easily,
> > too.
> 
> I'll look into adding this info as well ... at least for images.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: The display margin

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Maybe also an image :keymap property, but that will require more
> > work, so I will have to investigate further before doing so.
> 
> I've been using keymaps on images for years already (via the display
> property or so).  It was the only way to make an image clickable
> since you could not enquire whether a click position was on an image
> or on text beside it (at least for images on zero-width overlays).

What I meant was an "image map" feature, i.e. where different areas
(hot-spots) of an image had different pointer shapes and key bindings.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > storm@cua.dk (Kim F. Storm) writes:
> > 
> > > Maybe also an image :keymap property, but that will require more
> > > work, so I will have to investigate further before doing so.
> > 
> > I've been using keymaps on images for years already (via the
> > display property or so).  It was the only way to make an image
> > clickable since you could not enquire whether a click position was
> > on an image or on text beside it (at least for images on
> > zero-width overlays).
> 
> What I meant was an "image map" feature, i.e. where different areas
> (hot-spots) of an image had different pointer shapes and key
> bindings.

Oh ok, I have not thought of that one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: The display margin

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > David Kastrup <dak@gnu.org> writes:
> > 
> > > storm@cua.dk (Kim F. Storm) writes:
> > > 
> > > > Maybe also an image :keymap property, but that will require more
> > > > work, so I will have to investigate further before doing so.
> > > 
> > > I've been using keymaps on images for years already (via the
> > > display property or so).  It was the only way to make an image
> > > clickable since you could not enquire whether a click position was
> > > on an image or on text beside it (at least for images on
> > > zero-width overlays).
> > 
> > What I meant was an "image map" feature, i.e. where different areas
> > (hot-spots) of an image had different pointer shapes and key
> > bindings.
> 
> Oh ok, I have not thought of that one.

I have just committed changes to implement an image map feature.
See NEWS for details.

Additions to the elisp manual will follow in a few days.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[Richard Stallman]

    I have just committed changes to implement an image map feature.
    See NEWS for details.

That is an interesting improvement.  Thanks!

Re: The display margin

[Kim F. Storm]

Nick Roberts <nick@nick.uklinux.net> writes:

> I like this very much. This means that at some stage the unintuitive tool bar
> buttons for gud-break and gud-remove could go. Well for M-x gdba, at least.
> Other debuggers in GUD would still need them. I will try to arrange for the
> source buffer to always display the margin so that this feature can be used
> when there are no prior breakpoints. Also the GDB command 'info line' says
> which lines contain code. When I have time, I will try to work this in so
> that breakpoints can only be set on those lines.

It's not necessary to have a display margin -- as clicking on the left
fringe will also generate an event to toggle the breakpoint ...
provided that the buffer's local-map is setup to the
gud-minor-mode-map.  

So once you click in the fringe to set a breakpoint, you can open the
margin.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[Nick Roberts]

 > It's not necessary to have a display margin -- as clicking on the left
 > fringe will also generate an event to toggle the breakpoint ...
 > provided that the buffer's local-map is setup to the
 > gud-minor-mode-map.  
 > 
 > So once you click in the fringe to set a breakpoint, you can open the
 > margin.

Thats interesting. If I try this with M-x gdb (and presumably any other
debugger in GUD) it doesn't open the margin (as these don't currently display
breakpoint icons) but it does set a breakpoint. However, clicking at the same
location on the fringe in this case it doesn't seem to toggle the breakpoint
but sets another one on the same line.

Can gdb-mouse-toggle-breakpoint be modified so that it works in the fringe
for these debuggers too?


    Nick                                         http://www.nick.uklinux.net

Re: The display margin

[Kim F. Storm]

Nick Roberts <nick@nick.uklinux.net> writes:

>  > It's not necessary to have a display margin -- as clicking on the left
>  > fringe will also generate an event to toggle the breakpoint ...
>  > provided that the buffer's local-map is setup to the
>  > gud-minor-mode-map.  
>  > 
>  > So once you click in the fringe to set a breakpoint, you can open the
>  > margin.
> 
> Thats interesting. If I try this with M-x gdb (and presumably any other
> debugger in GUD) it doesn't open the margin (as these don't currently display
> breakpoint icons) but it does set a breakpoint. However, clicking at the same
> location on the fringe in this case it doesn't seem to toggle the breakpoint
> but sets another one on the same line.
> 
> Can gdb-mouse-toggle-breakpoint be modified so that it works in the fringe
> for these debuggers too?

Of course, but that's for you to find out :-)

My current implementation of gdb-mouse-toggle-breakpoint was just a
proof of concept, so it cheats by checking whether it is clicked on an
object (blindly assuming that it's a breakpoint icon) or not.  If
there is an object, it clears the breakpoint; otherwise it sets it.

I suppose you will have to improve that so that it consults the list
of breakpoints (somehow) and determines whether there already is a
breakpoint at the current line (and deletes it).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The display margin

[David PONCE]

Hi Kim,

> Finally, when you use a block cursor, images are no longer shown in
> "negative" when your window cursor is a filled block cursor (only
> the border of the image is highlighted now).  So clicking on an
> image no longer makes it "unreadable"...

That's very nice!  However when using a bar cursor the image is
still shown in "negative".  Perhaps it would make sense to use an
hollow cursor in that case too.

Another possibility could be to just draw the bar in that case (a la
"Open Office").

To do the latter I applied the following patch to xterm.c:

Index: src/xterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xterm.c,v
retrieving revision 1.822
diff -c -r1.822 xterm.c
*** src/xterm.c	17 Nov 2003 06:06:24 -0000	1.822
--- src/xterm.c	28 Nov 2003 12:43:35 -0000
***************
*** 7335,7340 ****
--- 7335,7341 ----
    if (cursor_glyph == NULL)
      return;
  
+ #if 0
    /* If on an image, draw like a normal cursor.  That's usually better
       visible than drawing a bar, esp. if the image is large so that
       the bar might not be in the window.  */
***************
*** 7345,7350 ****
--- 7346,7352 ----
        draw_phys_cursor_glyph (w, row, DRAW_CURSOR);
      }
    else
+ #endif
      {
        Display *dpy = FRAME_X_DISPLAY (f);
        Window window = FRAME_X_WINDOW (f);


I am not sure what solution is the best.

David