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: Tue, 26 Oct 2004 11:25:01 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

address@hidden (Kim F. Storm) writes:

> Stefan Monnier <address@hidden> writes:
>
>>> If the time stamps for the clicks indeed come from the X server,
>>> then Kim's timed scheme would probably not be very susceptible to
>>> system load/traffic congestion effects.
>>
>> The problm with it is that it goes against what we're trying to do,
>> which is to get Emacs's UI in line with "what non-Emacs users
>> expect".  I.e. such users will just do a simple click and expect it
>> to follow the link.
>
> Yes, that's what we are trying to achieve -- the fundamental problem
> we discuss here is actually how to recognize when the stuff is a
> link and when it is something else which has a mouse-face property.
>
> In the examples given until now, the non-links have the mouse-face
> on an overlay -- so maybe to fix would be to only follow link which
> have the mouse-face as a text property in the buffer.

It does not make sense to introduce an arbitrary inconsistency because
this would fix a problem with an arbitrary example that just happens
to exist with that sort of implementation by chance instead of
design.  If we can come up with a useful strategy that has a
reasonable chance of not breaking more than it fixes, then
preview-latex will be the one that has to adapt.  But just because
preview-latex is an example where things will break does not mean that
it is the only possible one.

> If we can safely differentiate between links and non-links I think a
> short click should follow the link (double-clicks typically don't
> make sense there anyway) and a long click should set point

Well, I happen to disagree, since following a link is the more time
consuming action, anyway, and people might be tempted to press until
the browser window appears.

In any case, neither option is the behavior that a user would guess
without being explicitly introduced to it.  So we need to turn it off
by default, or give an explanatory message of some kind by default.

> Appended is a patch which uses get-text-property rather than
> get-char-property to ignore overlay mouse-face properties.

I firmly object to such a course.  While we should not let ourselves
be influenced too much by that, with XEmacs there is not even a
distinction between overlays and text properties.  The choice between
the two when using Emacs should depend _exclusively_ on whether you
need the association with the text or the buffer, and not on any
chance side effects introduced to accidentally work with some package.

>> And if you add to the equation the extra code and conceptual
>> complexity of using timing-dependent information, I find it ends up
>> a loser.
>
> I don't really want to add any message there -- if we leave the
> feature disabled by default, the users who turn it on doesn't need
> to be told how to get the alternative behaviour.
>
> If we turn on the feature by default, there should at least be some
> way to disable that message.

Sure.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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