Re: The display margin

[David Kastrup]

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.

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