Re: The display margin

[Kim F. Storm]

David Kastrup <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
> 
> > David Kastrup <address@hidden> 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 <address@hidden> http://www.cua.dk