emacs-devel
[Top][All Lists]
Advanced

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

Re: finger-pointer curser as default for mouse-face text


From: David Kastrup
Subject: Re: finger-pointer curser as default for mouse-face text
Date: Mon, 25 Oct 2004 14:51:28 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

Stefan <address@hidden> writes:

>>> What is the behavior of latex-preview in the case of mouse-1 and in
>>> the case of mouse-2?  Is mouse-face applied to the actual text or
>>> just to the (before|after)-string?
>
>> The behavior of preview-latex when clicking with mouse-1 on a preview
>> image is to simply set point on the image (i.e., the behavior is just
>> the default, and preview-latex does not tamper with it).  You will
>> often need to do this to cut and paste the text passage that is hidden
>> by the image, for example, it you are doing a mathematical derivation
>> and start with the source text of the last equation in order to derive
>> the next one.  When clicking with mouse-2 on the image, the image is
>> replaced by the underlying text.  The image has a mouse-face that is
>> visible indication that you can mouse-2 the image.
>
> So it's the image (which is placed on a before-string)

No insinuations, please.  If the image were placed on a before-string,
you could not move point to it in the first place.  The image is
placed in the display property of the text (actually, the display
property of an overlay, and this overlay has the mouse-face).

> which has the `mouse-face', not the buffer's text, right?

Wrong.

> So Kim's patch won't interfere since Kim's patch checks
> (get-char-property (point) 'mouse-face) which should return nil in
> your case.

Shouldn't.

> Have you tried his patch or were you just "running it in your head"
> (like I usually do myself)?

It does not actually matter since I merely cited preview-latex as one
case that would appear not to fit the assumptions behind Kim's patch.
Whether or not an inconsistency in behavior might perchance render the
patch inoperative in this case by shere luck does not change the basic
premise: we need a proper migration strategy to do something like
that.  preview-latex itself is not much of a problem: it is under my
control and I can make it cope if it is the only application in the
world that gets in trouble with such a change.  But I have no reason
to believe that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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