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

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

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

> I see what you're saying. You've made it possible to follow links (and click
> buttons) using mouse-1 (in addition to using mouse-2).
>
> I really must not have made myself clear. RMS had the same misunderstanding
> as you.

Well, common user interface practice is that clicking mouse-1 on a
link follows that link.

>
> My point was not that using mouse-2 is not good. I think mouse-2 should
> remain the way to click links and buttons in Emacs, don't you? 

While I find this discussion of which pointer to use "amusing", IMO
using mouse-2 is a serious flaw in the emacs user interface. 

For example, on my notebook, the touchpad doesn't have mouse-2, so
I'm forced to click two mouse buttons which are really not designed to
support that (it's scary EVERY time I need to do so).


>                                                                We want to be
> able to use mouse-1 to select text inside a link, without accidentally
> clicking the link.

Most other applications manage just fine to allow a user to use
mouse-1 for both setting the point, marking a region, and following a
link.

My patch to mouse-drag-region-1 was a sample of how to do use mouse-1
in addition to mouse-2 to following links in emacs too.

The only real problem is how to mark text in the middle of a link -- 
but IMO that's a much less frequent operation that following the link.

And with my patch, you can actually still DRAG to mark, it's only the
single click that doesn't just set the mark, but follows the link as
well.  I don't see ANY problem with that.

At least, we could make it a user option:

(defcustom mouse-1-click-follows-link nil
  "Non-nil means that clicking mouse-1 on a link follows the link.
If value is `always', follow implicit links too (this means that
mouse-2 has a specific binding in the current buffer).
Otherwise, only follow links which have the mouse-face property.

To set point in a link, either drag the mouse (which sets the region),
or double-click in the link."
  :type '(choice ...))

[Of course, my patch need more work to do this, but it is still a
proof of concept].

>
> My point was that the pointer graphic is a hand with a pointing index finger
> (finger-1), and that it would be good to change this default pointer
> graphic. That's all.

I see your point, but I disagree the hand pointer is a bad choice -- it clearly
identifies the link as a link.

>
> I'd prefer to see a graphic that doesn't point with finger-1, because that
> pointer is commonly used in Web browsers (and some other applications) where
> you use mouse-1 to click links. The mental association between that pointer
> and mouse-1 is pretty strong by now (at least for me): the pointer makes me
> want to click mouse-1 (which is incorrect).

Why is that incorrect?  My point is that your perception is correct -- it 
is emacs that's too restrictive here.


>> *** mouse.el	17 Oct 2004 00:11:15 +0200	1.250
>> --- mouse.el	18 Oct 2004 13:16:54 +0200
>> ***************
>> *** 864,869 ****
>> --- 864,874 ----
>>   			 (or end-point
>>   			     (= (window-start start-window)
>>   				start-window-start)))
>> + 		(if (and (eq fun 'mouse-set-point)
>> + 			 (not end-point)
>> + 			 (consp event)
>> + 			 (get-char-property start-point 'mouse-face))
>> + 		    (setcar event 'mouse-2))
>>   		(setq unread-command-events
>>   		      (cons event unread-command-events)))))
>>   	(delete-overlay mouse-drag-overlay)))))

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

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

[Lennart Borgman]

----- Original Message ----- 
From: "Kim F. Storm" <storm@cua.dk>


: Well, common user interface practice is that clicking mouse-1 on a
: link follows that link.
:
: I see your point, but I disagree the hand pointer is a bad choice -- it
clearly
: identifies the link as a link.

I support these points. Whether one likes it or not I think it is good to
follow common user interface practice if it is not too hard. I believe that
is one of the keys to success.

- Lennart

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

[Drew Adams]

Kim, you convinced me (at least).

On mouse-face links, users can get by with other ways to select text, as you
mention (drag, use keyboard etc.), so we could use mouse-1 for link & button
clicks (as a user option).

My only gripe was that the finger-1 pointer graphic didn't fit the
mouse-2-click behavior, so if we changed to mouse-1, that would be fine.

BTW, isn't the behavior you propose what we have already in Customize
buffers?


-----Original Message-----From: Kim F. Storm
using mouse-2 is a serious flaw in the emacs user interface.
For example, on my notebook, the touchpad doesn't have mouse-2, so
I'm forced to click two mouse buttons

Most other applications manage just fine to allow a user to use mouse-1 for
both setting the point, marking a region, and following a link.

My patch to mouse-drag-region-1 was a sample of how to do use mouse-1
in addition to mouse-2 to following links in emacs too. The only real
problem is how to mark text in the middle of a link -- but IMO that's a much
less frequent operation that following the link.

And with my patch, you can actually still DRAG to mark, it's only the
single click that doesn't just set the mark, but follows the link as
well.  I don't see ANY problem with that. At least, we could make it a user
option

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

[Richard Stallman]

    Most other applications manage just fine to allow a user to use
    mouse-1 for both setting the point, marking a region, and following a
    link.

How do they do this?  Could you describe the behavior pattern
of Mouse-1 in those applications?

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Most other applications manage just fine to allow a user to use
>     mouse-1 for both setting the point, marking a region, and following a
>     link.
>
> How do they do this?  Could you describe the behavior pattern
> of Mouse-1 in those applications?

If you click mouse-1 outside a link, it moves the cursor.

If you click on a link, it follows the link.

If you drag inside or over a link behaviour varies with the
application, but my suggestion for emacs is that it highlights the
text and sets point at the end of the drag.

What you typically cannot do directly is set the mouse in the
middle of a link.  Typically you would use mouse-3 (right mouse)
to get a context menu for the link, and then cancel the menu.

Maybe in our case, if we enable this feature (as a user option)
clicking mouse-2 on a link should just set point there?

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

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

[Lennart Borgman]

----- Original Message ----- 
From: "Kim F. Storm" <storm@cua.dk>


: Richard Stallman <rms@gnu.org> writes:
:
: >     Most other applications manage just fine to allow a user to use
: >     mouse-1 for both setting the point, marking a region, and following
a
: >     link.
: >
: > How do they do this?  Could you describe the behavior pattern
: > of Mouse-1 in those applications?
:
: If you click mouse-1 outside a link, it moves the cursor.
:
: If you click on a link, it follows the link.
:
: If you drag inside or over a link behaviour varies with the
: application, but my suggestion for emacs is that it highlights the
: text and sets point at the end of the drag.

This is the behaviour of the most common web browsers (like Firefox). I
think most other applications have tried to mimic this behaviour and I
believe that is good. Consistent behaviour across applications as far as
possible without sacrificing too much is what most users seems to want.

Firefox does not allow selecting by dragging inside a normal link (an
a-tag), since this is preserved for dragging the link. In Emacs there is
currently no need to drag a link as far as I know so Emacs could allow
selecting by dragging inside a link too.


Some further points about mouse use: I mostly use the keyboard and in Emacs
I mostly found that I do not like the mouse behaviour or that it is
inconsistent. Maybe it is because I am still using 21.3.1 or maybe it is
because I am running Emacs on ms windows, I do not know?

Here is how it works in Emacs Info for me:

* For link at the top:
If i click with left button it follows the link. If I click with right
button nothing happens. I can't drag inside a top link.

* For a link on the page:
If I click with with left button point moves. If I click with right button
region is selected selected and highlighted (even though I started with
bin/emacs.exe -q --no-site-file??).


I would be glad for more consistent behaviour both within Emacs and between
Emacs and the most common applications.


- Lennart

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

[Richard Stallman]

    What you typically cannot do directly is set the mouse in the
    middle of a link.  Typically you would use mouse-3 (right mouse)
    to get a context menu for the link, and then cancel the menu.

Mouse-3 in Emacs does not move point; if you cancel the menu,
it won't do anything, so point won't move.

Maybe it is good enough to be able to drag the mouse into the area
and then release it and ignore the mark setting that it made.

This is the sort of change for which we need to conduct a poll of the
users.

    Maybe in our case, if we enable this feature (as a user option)
    clicking mouse-2 on a link should just set point there?

That sounds rather strange and backwards.

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Maybe it is good enough to be able to drag the mouse into the area
> and then release it and ignore the mark setting that it made.
>
> This is the sort of change for which we need to conduct a poll of the
> users.

I found a simpler solution which works really well, as it provides the
fallback directly on mouse-1 itself:

Measure the time between the mouse-1 down event and the up event, and
if it less than 300 ms (configurable), follow the link, else do what
mouse-1 normally does.

So a "fast" click follows the link, a slightly slower click sets the
point (or whatever mouse-1 does).  Dragging the mouse also inhibits
following the link.

Here is a patch:

Index: mouse.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mouse.el,v
retrieving revision 1.251
diff -c -r1.251 mouse.el
*** mouse.el	18 Oct 2004 09:29:26 -0000	1.251
--- mouse.el	24 Oct 2004 12:38:38 -0000
***************
*** 48,53 ****
--- 48,66 ----
    :type 'boolean
    :group 'mouse)
  
+ (defcustom mouse-1-click-follows-link 300
+   "Non-nil means that clicking mouse-1 on a link follows the link.
+ This is only done for links which have the mouse-face property.
+ 
+ If value is an integer, it specifies the maximum duration in
+ milli-seconds of the mouse-1 click to be recognized as a mouse-2 click.
+ If the time between pressing and releasing the mouse button is
+ longer, the normal mouse-1 action, e.g.  set point, is performed."
+   :version "21.4"
+   :type '(choice (const :tag "Disabled" nil)
+                  (number :tag "Max. click time" :value 300)
+                  (other :tag "Enabled" t)))
+ 
  \f
  ;; Provide a mode-specific menu on a mouse button.
  
***************
*** 877,882 ****
--- 890,905 ----
  			 (or end-point
  			     (= (window-start start-window)
  				start-window-start)))
+ 		(if (and mouse-1-click-follows-link
+ 			 (not end-point)
+ 			 (consp event)
+ 			 (get-char-property start-point 'mouse-face)
+ 			 (or (not (integerp mouse-1-click-follows-link))
+ 			     (let ((t0 (posn-timestamp (event-start start-event)))
+ 				   (t1 (posn-timestamp (event-end event))))
+ 			       (and (integerp t0) (integerp t1)
+ 				    (<= (- t1 t0) mouse-1-click-follows-link)))))
+ 		    (setcar event 'mouse-2))
  		(setq unread-command-events
  		      (cons event unread-command-events)))))
  	(delete-overlay mouse-drag-overlay)))))


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

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

[Lennart Borgman]

----- Original Message ----- 
From: "Kim F. Storm" <storm@cua.dk>

: Measure the time between the mouse-1 down event and the up event, and
: if it less than 300 ms (configurable), follow the link, else do what
: mouse-1 normally does.

On ms windows this is again a setting in the registry.

- Lennart

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

[Kim F. Storm]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> ----- Original Message ----- 
> From: "Kim F. Storm" <storm@cua.dk>
>
> : Measure the time between the mouse-1 down event and the up event, and
> : if it less than 300 ms (configurable), follow the link, else do what
> : mouse-1 normally does.
>
> On ms windows this is again a setting in the registry.

Which?  What do you refer to by "again"?

Do you say that on windoze, you have a similar function (mouse click
behaviour depends on how how you hold down the mouse button)?

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

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

[Lennart Borgman]

----- Original Message ----- 
From: "Kim F. Storm" <storm@cua.dk>


: "Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:
: 
: > ----- Original Message ----- 
: > From: "Kim F. Storm" <storm@cua.dk>
: >
: > : Measure the time between the mouse-1 down event and the up event, and
: > : if it less than 300 ms (configurable), follow the link, else do what
: > : mouse-1 normally does.
: >
: > On ms windows this is again a setting in the registry.
: 
: Do you say that on windoze, you have a similar function (mouse click
: behaviour depends on how how you hold down the mouse button)?

(red face). No Sorry. I was thinking about double clicking. 

- Lennart

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

[Richard Stallman]

    : Measure the time between the mouse-1 down event and the up event, and
    : if it less than 300 ms (configurable), follow the link, else do what
    : mouse-1 normally does.

    On ms windows this is again a setting in the registry.

I am not quite sure what "this" refers to here.  What is the
setting in the registry, and what does its value normally mean?
Does MS Windows have this feature?

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

[David Kastrup]

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

> Richard Stallman <rms@gnu.org> writes:
>
>> Maybe it is good enough to be able to drag the mouse into the area
>> and then release it and ignore the mark setting that it made.
>>
>> This is the sort of change for which we need to conduct a poll of the
>> users.
>
> I found a simpler solution which works really well, as it provides the
> fallback directly on mouse-1 itself:
>
> Measure the time between the mouse-1 down event and the up event, and
> if it less than 300 ms (configurable), follow the link, else do what
> mouse-1 normally does.
>
> So a "fast" click follows the link, a slightly slower click sets the
> point (or whatever mouse-1 does).  Dragging the mouse also inhibits
> following the link.

Actually, for me this is somewhat backward: I use a touchpad, and
setting the cursor is naturally done by tapping (which is short),
while following a link currently is done by pressing both mouse keys
together (which by necessity is longer).  Since setting the cursor is
usually followed by typing ahead soon, one wants to continue fast
(because you continue at the point at which you usually look).
Whereas if you follow the link, you are waiting for something to
happen.

So I'd very much prefer making the long press follow the link, even
though a long press is more likely to get interpreted as a drag
instead.

Perhaps the sign of that variable can be used for specifying whether
the long or the short duration means following the link?  Positive
means longer than given duration, negative means shorter?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> So a "fast" click follows the link, a slightly slower click sets the
>> point (or whatever mouse-1 does).  Dragging the mouse also inhibits
>> following the link.
>
> Actually, for me this is somewhat backward: I use a touchpad, and
> setting the cursor is naturally done by tapping (which is short),
> while following a link currently is done by pressing both mouse keys
> together (which by necessity is longer).  Since setting the cursor is
> usually followed by typing ahead soon, one wants to continue fast
> (because you continue at the point at which you usually look).
> Whereas if you follow the link, you are waiting for something to
> happen.

Normally, I would not expect a user to type anything in the middle of
a link, but YMMV.

> So I'd very much prefer making the long press follow the link, even
> though a long press is more likely to get interpreted as a drag
> instead.
>
> Perhaps the sign of that variable can be used for specifying whether
> the long or the short duration means following the link?  Positive
> means longer than given duration, negative means shorter?

Like this:

Index: mouse.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mouse.el,v
retrieving revision 1.251
diff -c -r1.251 mouse.el
*** mouse.el	18 Oct 2004 09:29:26 -0000	1.251
--- mouse.el	24 Oct 2004 19:06:25 -0000
***************
*** 48,53 ****
--- 48,72 ----
    :type 'boolean
    :group 'mouse)
  
+ (defcustom mouse-1-click-follows-link 300
+   "Non-nil means that clicking mouse-1 on a link follows the link.
+ This is only done for links which have the mouse-face property.
+ 
+ If value is an positive integer, it specifies the maximum duration in
+ milli-seconds of the mouse-1 click to be recognized as a mouse-2 click.
+ If the time between pressing and releasing the mouse button is
+ longer, the normal mouse-1 action (typically set point) is performed.
+ 
+ If value is an negative integer, its absolute value specifies the
+ minimum duration in milli-seconds of the mouse-1 click to be recognized
+ as a mouse-2 click.  If the time between pressing and releasing the
+ mouse button is longer, the normal mouse-1 action is performed."
+   :version "21.4"
+   :type '(choice (const :tag "Disabled" nil)
+                  (number :tag "Click time limit" :value 300)
+                  (other :tag "Enabled" t))
+   :group 'mouse)
+ 
  \f
  ;; Provide a mode-specific menu on a mouse button.
  
***************
*** 877,882 ****
--- 896,914 ----
  			 (or end-point
  			     (= (window-start start-window)
  				start-window-start)))
+ 		(if (and mouse-1-click-follows-link
+ 			 (not end-point)
+ 			 (consp event)
+ 			 (get-char-property start-point 'mouse-face)
+ 			 (or (not (integerp mouse-1-click-follows-link))
+ 			     (let ((t0 (posn-timestamp (event-start start-event)))
+ 				   (t1 (posn-timestamp (event-end event))))
+ 			       (and (integerp t0) (integerp t1)
+ 				    (if (> mouse-1-click-follows-link 0)
+ 					(<= (- t1 t0) mouse-1-click-follows-link)
+ 				      (< (- t0 t1) mouse-1-click-follows-link))))))
+ 
+ 		    (setcar event 'mouse-2))
  		(setq unread-command-events
  		      (cons event unread-command-events)))))
  	(delete-overlay mouse-drag-overlay)))))

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

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

[Richard Stallman]

    > Perhaps the sign of that variable can be used for specifying whether
    > the long or the short duration means following the link?  Positive
    > means longer than given duration, negative means shorter?

Giving the user lots of options is no substitute for good design.
The problem here is to make Emacs behave in a way that users expect
without looking at documentation.  Any solution that involves learning
about an option and setting it is automatically a failure.

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

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

: Giving the user lots of options is no substitute for good design.
: The problem here is to make Emacs behave in a way that users expect
: without looking at documentation.  Any solution that involves learning
: about an option and setting it is automatically a failure.

That is a very good point for UI design. This is also why the UI should
behave the way users are acustomed to as far as possible.

- Lennart

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

[Stefan]

> I found a simpler solution which works really well, as it provides the
> fallback directly on mouse-1 itself:

> Measure the time between the mouse-1 down event and the up event, and
> if it less than 300 ms (configurable), follow the link, else do what
> mouse-1 normally does.

Sounds like a terrible idea to me.  Working with X11-over-DSL means that
timing is rather unreliable.  Same thing with heavy-swapping (as happens
when a I do `tla star-merge' :-( ).

And even if the timing could be measured accurately, I don't find the "hold
the mouse button longer" to be intuitive at all for "move point".

I think we're trying to squeeze too much info in those events.  I'm quite
happy with the distinction between click and drag but I don't think we
should go further than that.


        Stefan


PS: David, could you explain exactly what's the problem with Kim's suggested
    patch and latex-preview?  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?

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

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

> PS: David, could you explain exactly what's the problem with Kim's suggested
>     patch and latex-preview?

It's not like I hadn't done this already.

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

Clicking outside the image and then using the cursor keys to get on
the image is not feasible instead: it will uncover the image
automatically with the default settings.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stefan]

>> 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) which has the
`mouse-face', not the buffer's text, right?  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.

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


        Stefan

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

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> 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

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

[Stefan Monnier]

>>>> 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?
[...]
>> So it's the image (which is placed on a before-string)
> No insinuations, please.

I could only "insinuate" since you did not reply to my original question "Is
mouse-face applied to the actual text or just to the (before|after)-string?"

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

Thanks.

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

I quite understand this part.
It's clear that Kim's patch can introduce undesired behavior.
The question is how often such undesired behavior happens in practice.

I suspect that the number of packages where moving point into a piece of
text with the `mouse-face' property does anything more than move point
(while left-clicking only moves point) is extremely small.  `preview-latex'
is very much unusual in this respect.

So I think the migration path should be to apply Kim's patch and provide
a way for a package maintainer to override it in those rare cases where
it interferes (e.g. it could check some text property
"dont-remap-mouse-1-to-mouse-2").


        Stefan

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

[Ralf Angeli]

* Stefan Monnier (2004-10-25) writes:

> I quite understand this part.
> It's clear that Kim's patch can introduce undesired behavior.
> The question is how often such undesired behavior happens in practice.
>
> I suspect that the number of packages where moving point into a piece of
> text with the `mouse-face' property does anything more than move point

With tex-fold.el (part of AUCTeX) there is another package which
reveals text which is hidden by a display property if point is moved
horizontally into the respective area.

> (while left-clicking only moves point)

In tex-fold.el left-clicking currently will reveal the folded text.
(Similar to preview-latex there is an overlay on the text with
'mouse-face set.)  The reactions to mouse clicks will be synchronized
with preview-latex in the future.  What actions will be triggered by
mouse-1 and mouse-2 will be subject to discussion.

> is extremely small.  `preview-latex'
> is very much unusual in this respect.

Well, there is preview-latex and tex-fold.el.  And Talcum
(<URL:http://talcum.sarovar.org/>) reveals text on cursor movement as
well.  I didn't check how it behaves with regard to mouse clicks,
though.

-- 
Ralf

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

[Stefan Monnier]

>> (while left-clicking only moves point)
> In tex-fold.el left-clicking currently will reveal the folded text.

So it's not the same problem as with preview-latex.  The problem with
preview-latex is that the mouse-1 click seems to be the only easy way to
place the cursor on the image without "unfolding" it.

tex-fold.el is more traditional in this respect and Kims' patch is just
annoying (you have to use the keyboard to move point into the area), whereas
for preview-latex using the keyboard is not really an option it seems.


        Stefan

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

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> (while left-clicking only moves point)
>> In tex-fold.el left-clicking currently will reveal the folded text.
>
> So it's not the same problem as with preview-latex.  The problem with
> preview-latex is that the mouse-1 click seems to be the only easy way to
> place the cursor on the image without "unfolding" it.
>
> tex-fold.el is more traditional in this respect and Kims' patch is
> just annoying (you have to use the keyboard to move point into the
> area), whereas for preview-latex using the keyboard is not really an
> option it seems.

preview-latex is a bit difficile: you can use the keyboard for moving
onto the preview itself, _except_ for cursor left/right: that will
trigger the autoreveal.  Similarly, using isearch will trigger it.
Basically there are movements where the guessed intent would be
"uncover", and others where it isn't.  The proposal of Kim (click
to the side, then move to it) falls in the "isn't" category usually.
When marking formulas and stuff, you usually will tend to use vertical
motion commands if you are just using the keyboard, and those won't
uncover things.

It is, of course, an illogical interface to start with, but it happens
to be convenient for normal usage patterns.  And I don't like the
"don't click on it if you just want to position the cursor" idea.

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.  After all, we have the same problem
with recognizing double-clicks.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stefan Monnier]

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

Adding a message saying "please keep the button pressed longer if you want
to follow the link" is really not much better than adding a message that
says "use mouse-2 if you want to follow the link".

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.

> After all, we have the same problem with recognizing double-clicks.

Sure.  But users have wanted double-clicks, so we gave it to them.
Users's aren't asking for variable-duration clicks.  OTOH users are quite
used to not being able to move cursor into a link by just left-clicking on
it.  It may annoy them at times, but it seems to annoy them less than having
to use mouse-2.


        Stefan

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

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> 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.

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

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

The patch also allows you to double click on a link to get the normal
double-click action in the buffer rather than following the link.
To do that, I wait "double-click-time" milliseconds before following
the link -- if any input arrives in that period, I don't follow the
link.  May feel a little "slow", but it's worth a try.


>
> Adding a message saying "please keep the button pressed longer if you want
> to follow the link" is really not much better than adding a message that
> says "use mouse-2 if you want to follow the link".
>
> 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.

>
>> After all, we have the same problem with recognizing double-clicks.
>
> Sure.  But users have wanted double-clicks, so we gave it to them.
> Users's aren't asking for variable-duration clicks.  OTOH users are quite
> used to not being able to move cursor into a link by just left-clicking on
> it.  It may annoy them at times, but it seems to annoy them less than having
> to use mouse-2.

Variable length clicks are a new user interface invention in emacs :-)


Index: mouse.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mouse.el,v
retrieving revision 1.251
diff -c -r1.251 mouse.el
*** mouse.el	18 Oct 2004 09:29:26 -0000	1.251
--- mouse.el	26 Oct 2004 08:56:24 -0000
***************
*** 48,53 ****
--- 48,81 ----
    :type 'boolean
    :group 'mouse)
  
+ (defcustom mouse-1-click-follows-link 300
+   "Non-nil means that clicking mouse-1 on a link follows the link.
+ This is only done for links which have the mouse-face property.
+ 
+ If value is an positive integer, it specifies the maximum
+ duration in milli-seconds of the mouse-1 click to be recognized
+ as a mouse-2 click.  If the time between pressing and releasing
+ the mouse button is longer, the normal mouse-1 command (typically
+ set point) is performed.
+ 
+ If value is an negative integer, its absolute value specifies the
+ minimum duration in milli-seconds of the mouse-1 click to be
+ recognized as a mouse-2 click.  If the time between pressing and
+ releasing the mouse button is longer, the normal mouse-1 command
+ is performed.
+ 
+ Otherwise, mouse-1 unconditionally follows the link, unless you
+ drag the mouse in the link to run the normal mouse-1 command."
+   :version "21.4"
+   :type '(choice (const :tag "Disabled" nil)
+                  (number :tag "Click time limit" :value 300)
+                  (other :tag "Enabled" t))
+   :group 'mouse)
+ 
  \f
  ;; Provide a mode-specific menu on a mouse button.
  
***************
*** 877,882 ****
--- 905,929 ----
  			 (or end-point
  			     (= (window-start start-window)
  				start-window-start)))
+ 		(if (and mouse-1-click-follows-link
+ 			 (not end-point)
+ 			 (consp event)
+ 			 (= click-count 0)
+ 			 (= (event-click-count event) 1)
+ 			 (not (input-pending-p))
+ 			 ;; Don't want to look at overlays here
+ 			 (get-text-property start-point 'mouse-face)
+ 			 (or (not (integerp mouse-1-click-follows-link))
+ 			     (let ((t0 (posn-timestamp (event-start start-event)))
+ 				   (t1 (posn-timestamp (event-end event))))
+ 			       (and (integerp t0) (integerp t1)
+ 				    (if (> mouse-1-click-follows-link 0)
+ 					(<= (- t1 t0) mouse-1-click-follows-link)
+ 				      (< (- t0 t1) mouse-1-click-follows-link)))))
+ 			 (or (not double-click-time)
+ 			     (sit-for 0 (if (integerp double-click-time)
+ 					    double-click-time 500) t)))
+ 		    (setcar event 'mouse-2))
  		(setq unread-command-events
  		      (cons event unread-command-events)))))
  	(delete-overlay mouse-drag-overlay)))))

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

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

[David Kastrup]

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

> Stefan Monnier <monnier@iro.umontreal.ca> 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

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

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

If you keep the button pressed in emacs, the window NEVER appears (as
it is the up-event which follows the link), so I doubt users do that.

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

Well, if the "normal" click follows the link (and I claim that the
normal click is the short click), most users will never think there is
a problem, as they don't usually have to set the mouse in the middle
of a link.

They will probably set it next to the link and move the cursor into
the link (that's how it is often done in other applications).

Now, the more advanced users will ask (or find out by themselves) that
a longer click sets the mouse.  That is no different from a lot of
other functionality in emacs, where the defaults suit the majority,
but can be tweaked by the rest).

I really don't think a message is worth the extra code [but if
that's a prerequisite to get this installed, I'll do it].

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

True, so it's the wrong solution.  What is the right solution?

Below is a patch which checks if the "link" has a dont-follow-link
property.  That requires package authors to adapt their code if they
don't want mouse-1 to follow links, but it is a trivial addition...


Index: mouse.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mouse.el,v
retrieving revision 1.251
diff -c -r1.251 mouse.el
*** mouse.el	18 Oct 2004 09:29:26 -0000	1.251
--- mouse.el	26 Oct 2004 12:25:34 -0000
***************
*** 48,53 ****
--- 48,81 ----
    :type 'boolean
    :group 'mouse)
  
+ (defcustom mouse-1-click-follows-link 300
+   "Non-nil means that clicking mouse-1 on a link follows the link.
+ This is only done for links which have the mouse-face property.
+ 
+ If value is an positive integer, it specifies the maximum
+ duration in milli-seconds of the mouse-1 click to be recognized
+ as a mouse-2 click.  If the time between pressing and releasing
+ the mouse button is longer, the normal mouse-1 command (typically
+ set point) is performed.
+ 
+ If value is an negative integer, its absolute value specifies the
+ minimum duration in milli-seconds of the mouse-1 click to be
+ recognized as a mouse-2 click.  If the time between pressing and
+ releasing the mouse button is longer, the normal mouse-1 command
+ is performed.
+ 
+ Otherwise, mouse-1 unconditionally follows the link, unless you
+ drag the mouse in the link to run the normal mouse-1 command."
+   :version "21.4"
+   :type '(choice (const :tag "Disabled" nil)
+                  (number :tag "Click time limit" :value 300)
+                  (other :tag "Enabled" t))
+   :group 'mouse)
+ 
  \f
  ;; Provide a mode-specific menu on a mouse button.
  
***************
*** 877,882 ****
--- 905,929 ----
  			 (or end-point
  			     (= (window-start start-window)
  				start-window-start)))
+ 		(if (and mouse-1-click-follows-link
+ 			 (not end-point)
+ 			 (consp event)
+ 			 (= click-count 0)
+ 			 (= (event-click-count event) 1)
+ 			 (not (input-pending-p))
+ 			 (get-char-property start-point 'mouse-face)
+ 			 (not (get-char-property start-point 'dont-follow-link))
+ 			 (or (not (integerp mouse-1-click-follows-link))
+ 			     (let ((t0 (posn-timestamp (event-start start-event)))
+ 				   (t1 (posn-timestamp (event-end event))))
+ 			       (and (integerp t0) (integerp t1)
+ 				    (if (> mouse-1-click-follows-link 0)
+ 					(<= (- t1 t0) mouse-1-click-follows-link)
+ 				      (< (- t0 t1) mouse-1-click-follows-link)))))
+ 			 (or (not double-click-time)
+ 			     (sit-for 0 (if (integerp double-click-time)
+ 					    double-click-time 500) t)))
+ 		    (setcar event 'mouse-2))
  		(setq unread-command-events
  		      (cons event unread-command-events)))))
  	(delete-overlay mouse-drag-overlay)))))

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

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

[Drew Adams]

1. We can no doubt find a good way to let click mouse-1 be used to follow
links and push action buttons - and still let it be used as it is now
(99.99%). We've discussed several possibilities, and we can discuss more and
settle on a good design. Already, IMO, acceptable approaches have been
discussed, but there is no reason not to scrutinize the issue more before we
make a change. David is right that whatever design we choose should not be
based only on how current code happens to be implemented; it should make
sense as a design, not just as a coding workaround.


2. Default behavior - One of the main reasons to make this fairly major
change to longstanding Emacs behavior is to bring Emacs behavior in line
with what users experience elsewhere. [This is not an argument for aligning
Emacs to every convention existing outside Emacs, but when a convention is
reasonable and fairly compatible, then it can at least be _considered_ for
possible adoption.]

This conventional behavior is especially important for _new_ Emacs users.
It makes sense, if we make this change to Emacs, to make the new behavior
the _default_ behavior. Let experienced Emacs users turn it off, if they
like, but let new Emacs users find it on by default. It would be silly to
require new users to somehow discover how to achieve this conventional
behavior. Emacs lovers often enjoy discovering not-so-obvious Emacs
features, but the standard, simple stuff should be obvious for newbies.

Sometimes we seem to be taking the view that if a candidate change is
recognized as very useful but it isn't 100% pluggable or it interferes with
current behavior or implementation a tiny bit, then the proper course of
action is to add it to Emacs, but turn it off. IMO, whether a feature should
be on or off by default should be determined first by whether or not it is
useful to most users and it might not be discovered by them if off by
default.

An argument for 100% correctness in 100% of contexts is appropriate to
consider, but as a secondary argument - it should generally not be the main
criterion for whether something is on by default. If something is _very_
broken, then it probably shouldn't be added at all. If something is, say,
1/10 broken and cannot easily be fixed, then one could argue for adding it
only as a non-default option, but if functionality and performance are close
to 100%, then the main argument for defaulting should be in terms of
usefulness.

[Yes, there are also arguments for not turning on something that will
interfere with minimal operation (e.g. -nw), and, yes, those arguments can
trump the main argument about useful service to most users. But sometimes
such minimal operation can be cantoned within, say, a command-line option,
so that the default behavior can be different in this case.]


3. Time-delay - Without having tried the time-delay implementation, my guess
is that it would be an acceptable solution. The longer delay should be used
for the less common behavior in Emacs - and for the behavior that is less
common (inexistant?) outside of Emacs.

IOW, the normal, short click behavior of mouse-1 should be to follow a link
(or to click a button); the longer "click" should set point or drag or
whatever within the link text. As far as an action button (or an active
image or image map) is concerned, I see little reason for this exceptional
mouse-1 behavior there; such behavior should be reserved for links - which
is one more reason that the long "click" should _not_ be the link-follow
action.

Again, we should be looking for the best design in the wider context of UI
conventions that have grown up around us - not looking for ways to minimize
impact on experienced Emacs users or on the current Emacs implementation.


4. Modifier-key - I still think that a keyboard modifier would be an
acceptable alternative if, for some reason (or in some contexts), the
time-delay approach had drawbacks. Someone argued that it would be hard to
remember. In that case, that is a further argument that setting point &
dragging within link text must be a rare activity: if it were common, you
would have no problem remembering the key sequence. For instance, if you use
M-mouse-1 often for secondary selection then you have no trouble remembering
it; if you use it rarely, then you might forget it.

Also (slightly off-topic), doesn't it make more sense to use modifier keys
for operations that you might want to _repeat_ by just holding down the
modifier key? What's the point of having, say, S-mouse-1 call up a
font-selection dialog box (mouse-set-font)? There are a limited number of
modifier keys - why would we "waste" them on operations that cannot be
repeated? (Yes, that can be an argument against using a modifier with
mouse-1 for selecting link text - so be it. The latter still makes more
sense to me than calling up a dialog box.)


5. Alternatives - Since we have several alternative ways to achieve the
current mouse-1 behavior within link text, I don't see a good argument for
not moving forward with the change we're discussing. These alternatives
might be slightly less convenient than just clicking mouse-1 for this
relatively rare need (selecting text within a link), but so what? If you can
accomplish this need in any of a number of ways, what's the big pb? So far,
we've considered these acceptable alternatives, the first of which already
exists:

 - use the keyboard (set mark; move point)
 - press mouse-1 a little longer
 - click mouse-1 with a modifier (e.g. C-S-mouse-1)

 Drew

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> 3. Time-delay - Without having tried the time-delay implementation,
> my guess is that it would be an acceptable solution. The longer
> delay should be used for the less common behavior in Emacs - and for
> the behavior that is less common (inexistant?) outside of Emacs.
>
> IOW, the normal, short click behavior of mouse-1 should be to follow
>a link (or to click a button); the longer "click" should set point or
>drag or whatever within the link text. As far as an action button (or
>an active image or image map) is concerned, I see little reason for
>this exceptional mouse-1 behavior there; such behavior should be
>reserved for links - which is one more reason that the long "click"
>should _not_ be the link-follow action.

I have given some reasons.  Another is that if "nothing happens",
people will click longer in order to get the "I really mean it!"
message across.  This "Damn it computer, do what I mean" approach that
makes people figure out themselves how this is done does not work when
the short click follows links.

Some other programs offer you the possibility to stop some action from
actually happening from a click or drag if you press ESC (or C-g?)
before releasing the button.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

Good points.  I agree with all of your views.

The default behaviour should be that a "normal" mouse-1 click follows a link.

The problem is how to not break external packages like preview-latex or AUCTex.

But CVS emacs is still far from being released, and I guess that if we
make a clean interface how to inhibit the mapping for specific links,
the package authors will have plenty of time to adapt their code for
CVS emacs.

>  - use the keyboard (set mark; move point)

Make that:  click mouse-1 outside the link, move into the link with the keyboard

>  - press mouse-1 a little longer

As my patch does, and it works nicely!

and you forgot:

- drag mouse-1 inside the link (you may drag it back to the character
  you clicked on, so you don't really mark a region).

>  - click mouse-1 with a modifier (e.g. C-S-mouse-1)

I don't see a need for this.  Better reserve such bindings for
future enhancements.


BTW, I agree that S-mouse-1 wastes a good mouse binding, as you can
easily get the same function from the menu Options > Set font/fontset.

I wish I could use S-mouse-1 to start marking a rectangle in CUA.

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

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

[Luc Teirlinck]

Kim Storm wrote:

   But CVS emacs is still far from being released,

If we keep going on like this, there _never_ will be another release.

    and I guess that if we make a clean interface how to inhibit the
    mapping for specific links, the package authors will have plenty
    of time to adapt their code for CVS emacs.

It is also a matter of not only documenting the new behavior, but also
changing references to the old behavior everywhere in all manuals,
which may be spread all over the place.  Realistically speaking,
implementing the new behavior will introduce bugs that will need to be
fixed.  Everything combined, plenty of resources will be diverted from
working on the release, assuming we still want to have one.

I have not been following this discussion, as I have had no time to do
so.  I thought the purpose of a feature freeze was exactly that people
would not have to divert time away from working on the release by
worrying about substantive new features and their possible negative effects.

Sincerely,

Luc.

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

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
>
>    But CVS emacs is still far from being released,
>
> If we keep going on like this, there _never_ will be another release.

I agree, but I think this is an important issue.

>
>     and I guess that if we make a clean interface how to inhibit the
>     mapping for specific links, the package authors will have plenty
>     of time to adapt their code for CVS emacs.
>
> It is also a matter of not only documenting the new behavior, but also
> changing references to the old behavior everywhere in all manuals,
> which may be spread all over the place.  

This is a general - but user customizable - change in behaviour.

As such, we should need to document the current "standard" behaviour,
and then add a section at an appropriate place which says something
like (need to be elaborated on a little bit):

Whenever you can click with mouse-2 to follow a link, you may also be
able to follow the link by a double click or a short click with
mouse-1.  The actual mouse-1 action that you need to follow a link is
controlled by the user option mouse-1-click-follows-link.

One problem is the tooltips which say "click mouse-2 to ...".  
To fix that requires that we change all places where the tooltips
are created (unless there is some place we can put in a clever
rewrite of the message).

>                                          Realistically speaking,
> implementing the new behavior will introduce bugs that will need to be
> fixed.  Everything combined, plenty of resources will be diverted from
> working on the release, assuming we still want to have one.

I don't think there will be many bugs related to this -- some but not many.

> I have not been following this discussion, as I have had no time to do
> so.  I thought the purpose of a feature freeze was exactly that people
> would not have to divert time away from working on the release by
> worrying about substantive new features and their possible negative effects.

That's a problem of a feature freeze that's in place for more than 1 year.

If you look at the change logs, new features still creap in over time.

Global warming may also be a problem :-)

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

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

[Luc Teirlinck]

Kim Storm wrote:

   As such, we should need to document the current "standard" behaviour,

I thought that there was talk about changing the current standard
behavior, in which case changes all over the manuals and tons of other
places would be required.

   One problem is the tooltips which say "click mouse-2 to ...".  
   To fix that requires that we change all places where the tooltips
   are created (unless there is some place we can put in a clever
   rewrite of the message).

I guess you would need to make the message dependent on the value of
the option.

Sincerely,

Luc.

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

[David Kastrup]

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

> That's a problem of a feature freeze that's in place for more than 1
> year.

IIRC, it was more or less this August, give or take a month or two.
Certainly not a year.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

feature freeze (was: finger-pointer curser as default for mouse-face text)

[Reiner Steib]

On Wed, Oct 27 2004, David Kastrup wrote:

> storm@cua.dk (Kim F. Storm) writes:
>
>> That's a problem of a feature freeze that's in place for more than 1
>> year.
>
> IIRC, it was more or less this August, give or take a month or two.
> Certainly not a year.

It was in May, see e.g.
<URL:http://thread.gmane.org/x5wu3kn0nl.fsf@lola.goethe.zz> or
<URL:http://thread.gmane.org/gmane.emacs.devel/21327>.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: feature freeze (was: finger-pointer curser as default for mouse-face text)

[Kim F. Storm]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Oct 27 2004, David Kastrup wrote:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>
>>> That's a problem of a feature freeze that's in place for more than 1
>>> year.
>>
>> IIRC, it was more or less this August, give or take a month or two.
>> Certainly not a year.
>
> It was in May, see e.g.
> <URL:http://thread.gmane.org/x5wu3kn0nl.fsf@lola.goethe.zz> or
> <URL:http://thread.gmane.org/gmane.emacs.devel/21327>.

So with an expected release around May next year, it's 1 year...

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

Re: feature freeze

[David Kastrup]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Oct 27 2004, David Kastrup wrote:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>
>>> That's a problem of a feature freeze that's in place for more than 1
>>> year.
>>
>> IIRC, it was more or less this August, give or take a month or two.
>> Certainly not a year.
>
> It was in May, see e.g.
> <URL:http://thread.gmane.org/x5wu3kn0nl.fsf@lola.goethe.zz> or
> <URL:http://thread.gmane.org/gmane.emacs.devel/21327>.

Still quite a short year.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Drew Adams]

-----Original Message-----From: Kim F. Storm
  document the current "standard" behaviour,
  and then add a section at an appropriate place which says something like:

  Whenever you can click with mouse-2 to follow a link, you may also be
  able to follow the link by a double click or a short click with
  mouse-1.  The actual mouse-1 action that you need to follow a link is
  controlled by the user option mouse-1-click-follows-link.

mouse-1 click to follow links or click action buttons, if available, should
become the _standard_ behavior. Instead of introducing mouse-2 as the
standard behavior, and then saying that mouse-1 "may also be" usable as an
alternative in many contexts, we should just introduce mouse-1 clicking (or
not bother to introduce it at all! - the closer Emacs behavior is to what
users are used to, the less explanation we need). We should not mention
mouse-2 in this context.

What about mouse-2? If mouse-1 clicking follows links, there is no reason
for mouse-2 to duplicate this behavior. I think Kim has (for now) left
mouse-2 as an alternative to mouse-1 in his patch: both do the same thing
wrt links. I would prefer that we adopt mouse-1 and drop mouse-2 (except as
an optional replacement for mouse-1 -- one or the other; not both). Let
users (or future Emacs versions) use mouse-2 for something else in this
context - by default, it should probably be `mouse-yank-at-click' in most
contexts.

Any other, optional (customizable) behavior besides
mouse-1-click-to-follow-a-link should be described in a way that does not
confuse new users into thinking that they need to wrestle with such
customization. IOW, we need to make it clear when we're documenting
customization (optional behavior).

For the (new) standard mouse-1 behavior, we should just speak of "click",
not "short click". Documentation of any "long click" behavior needs to be
separated, so users see clearly that they don't _need_ to understand it just
to be able to "point and shoot".

IOW, let's separate out the esoteric stuff from the main message: click
mouse-1 to follow a link or use an action button.

  One problem is the tooltips which say "click mouse-2 to ...".
  To fix that requires that we change all places where the tooltips
  are created (unless there is some place we can put in a clever
  rewrite of the message).

Such messages should ideally be constructed based on dynamic key bindings,
so that they would automatically reflect the appropriate behavior. Isn't it
possible to use, say, `substitute-command-keys' here?

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

[Kim F. Storm]

[For the busy reader -- see patch to tooltip code at the end.  ++kfs]


"Drew Adams" <drew.adams@oracle.com> writes:

> -----Original Message-----From: Kim F. Storm
>   document the current "standard" behaviour,
>   and then add a section at an appropriate place which says something like:
>
>   Whenever you can click with mouse-2 to follow a link, you may also be
>   able to follow the link by a double click or a short click with
>   mouse-1.  The actual mouse-1 action that you need to follow a link is
>   controlled by the user option mouse-1-click-follows-link.
>
> mouse-1 click to follow links or click action buttons, if available, should
> become the _standard_ behavior. Instead of introducing mouse-2 as the
> standard behavior, and then saying that mouse-1 "may also be" usable as an
> alternative in many contexts, we should just introduce mouse-1 clicking (or
> not bother to introduce it at all! - the closer Emacs behavior is to what
> users are used to, the less explanation we need). We should not mention
> mouse-2 in this context.

Mouse-2 IS the standard behaviour -- Lisp code binds mouse-2, not mouse-1.
Changing that is a HUGE change.  In comparison, the proposed change is a
tiny change which adds a convenient mapping of mouse-1 to mouse-2 in
this specific case.


The text could be rephrased to say:

With the default settings, click mouse-1 to follow a highlighted link.

If you want to set the point rather than follow the link, just keep
the mouse-1 button pressed a little longer (at least 0.35 seconds).

This behaviour is a major change from traditional emacs mouse
behaviour where you use mouse-2 to follow links, while mouse-1
(typically) would set point in the link.

The mouse-2 binding is still the standard binding for following a
link, while the mouse-1 behaviour is customized via the variable
mouse-1-click-follows-link.  For example, you can control the length
of the click, or you can make only a mouse-1 double-click follow
links, while keeping the traditional mouse-1 behaviour.


>
> What about mouse-2? If mouse-1 clicking follows links, there is no reason
> for mouse-2 to duplicate this behavior. I think Kim has (for now) left
> mouse-2 as an alternative to mouse-1 in his patch: both do the same thing
> wrt links. I would prefer that we adopt mouse-1 and drop mouse-2 (except as
> an optional replacement for mouse-1 -- one or the other; not both). Let
> users (or future Emacs versions) use mouse-2 for something else in this
> context - by default, it should probably be `mouse-yank-at-click' in most
> contexts.

I don't think we shall do anything about mouse-2 clicks -- that's the
traditional binding, and the binding you make at the Lisp level.

>   One problem is the tooltips which say "click mouse-2 to ...".
>   To fix that requires that we change all places where the tooltips
>   are created (unless there is some place we can put in a clever
>   rewrite of the message).
>
> Such messages should ideally be constructed based on dynamic key bindings,
> so that they would automatically reflect the appropriate behavior. Isn't it
> possible to use, say, `substitute-command-keys' here?

Here is a patch to the tooltip code to change mouse-2 to mouse-1 on the fly:

*** tooltip.el	01 Sep 2003 17:45:17 +0200	1.34
--- tooltip.el	28 Oct 2004 13:31:16 +0200	
***************
*** 480,486 ****
  (defun tooltip-show-help-function (msg)
    "Function installed as `show-help-function'.
  MSG is either a help string to display, or nil to cancel the display."
!   (let ((previous-help tooltip-help-message))
      (setq tooltip-help-message msg)
      (cond ((null msg)
  	   ;; Cancel display.  This also cancels a delayed tip, if
--- 480,502 ----
  (defun tooltip-show-help-function (msg)
    "Function installed as `show-help-function'.
  MSG is either a help string to display, or nil to cancel the display."
!   (let ((previous-help tooltip-help-message)
! 	mp pos)
!     (if (and mouse-1-click-follows-link
! 	     (stringp msg)
! 	     (save-match-data
! 	       (string-match "^mouse-2" msg))
! 	     (setq mp (mouse-pixel-position))
! 	     (consp (setq pos (cdr mp)))
! 	     (setq pos (posn-at-x-y (car pos) (cdr pos) (car mp)))
! 	     (windowp (posn-window pos)))
! 	(with-current-buffer (window-buffer (posn-window pos))
! 	  (setq lttt (list msg mp pos))
! 	  (if (mouse-on-link-p (posn-point pos))
! 	      (setq msg (concat
! 		    (if (eq mouse-1-click-follows-link 'double)
! 			"double-" "")
! 		    "mouse-1" (substring msg 7))))))
      (setq tooltip-help-message msg)
      (cond ((null msg)
  	   ;; Cancel display.  This also cancels a delayed tip, if

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

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

[Richard Stallman]

    BTW, I agree that S-mouse-1 wastes a good mouse binding, as you can
    easily get the same function from the menu Options > Set font/fontset.

It is probably not used all that much, so if it is not important
for compatibility, we could get rid of it.

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

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

>     BTW, I agree that S-mouse-1 wastes a good mouse binding, as you can
>     easily get the same function from the menu Options > Set font/fontset.
>
> It is probably not used all that much, so if it is not important
> for compatibility, we could get rid of it.

For what's worth, I often use it.  It is somehow important to me because
I run Emacs with teh menu-bar disabled most ot the time.

-- 
http://www.gnu.franken.de/ke/                           |      ,__o
                                                        |    _-\_<,
                                                        |   (*)/'(*)
Key fingerprint = F138 B28F B7ED E0AC 1AB4  AA7F C90A 35C3 E9D0 5D1C

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

[Stefan]

> For what's worth, I often use it.  It is somehow important to me because
> I run Emacs with teh menu-bar disabled most ot the time.

Try C-mouse-3 one of these days ;-)


        Stefan

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

[Richard Stallman]

It is interesting to find a user who often specifies faces.
Can you tell us the circumstances where you do that?

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

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> It is interesting to find a user who often specifies faces.
> Can you tell us the circumstances where you do that?

>From time to time it is necessary to increase the font size: When I want
to demonstrate something to somebody watching my screen, or when I want
to check some accented or foreign characters more closely.

-- 
http://www.gnu.franken.de/ke/                           |      ,__o
                                                        |    _-\_<,
                                                        |   (*)/'(*)
Key fingerprint = F138 B28F B7ED E0AC 1AB4  AA7F C90A 35C3 E9D0 5D1C

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

[Miles Bader]

On Tue, Nov 02, 2004 at 07:08:34PM +0100, Karl Eichwalder wrote:
> > It is interesting to find a user who often specifies faces.
> > Can you tell us the circumstances where you do that?
> 
> >From time to time it is necessary to increase the font size: When I want
> to demonstrate something to somebody watching my screen, or when I want
> to check some accented or foreign characters more closely.

Something like the following elisp code might be more useful for this.  It
implements the C-+ and C-- (that's control-minus :-) bindings many modern GUI
programs use to grow/shrink the default face.

The main problem with these commands -- and so why I haven't pursued adding
them to the official sources[*] -- is that they don't interact well with a
default face which has been set using customize-face (because the Emacs
face-customization machinery sucks).  However the traditional font-setting
menu _also_ doesn't work if you've customized the `default' face, so I'm
assuming you haven't done that... :-)

[*] Perhaps the benefits of these commands outweigh their drawbacks however
and they _should_ be added to CVS; after all the traditional "set font" menu
has the same problem.  Of course the real solution is to overhaul the
face-setting mechanism to not have the horrible looping problems it has.

-Miles


;;; default-grow.el

(defun increase-default-face-height (&optional steps)
  "Increase the height of the default face by STEPS steps.
Each step multiplies the height by 1.2; a negative number of steps
decreases the height by the same amount."
  (interactive
   (list
    (cond ((eq current-prefix-arg '-) -1)
	  ((numberp current-prefix-arg) current-prefix-arg)
	  ((consp current-prefix-arg) -1)
	  (t 1))))
  (let ((frame (selected-frame)))
    (set-face-attribute 'default frame
			:height (floor
				 (* (face-attribute 'default :height frame)
				    (expt 1.3 steps))))))

(defun decrease-default-face-height (&optional steps)
  "Decrease the height of the default face by STEPS steps.
Each step divides the height by 1.2; a negative number of steps
increases the height by the same amount."
  (interactive
   (list
    (cond ((eq current-prefix-arg '-) -1)
	  ((numberp current-prefix-arg) current-prefix-arg)
	  ((consp current-prefix-arg) -1)
	  (t 1))))
  (increase-default-face-height (- steps)))

(global-set-key [(control =)] 'increase-default-face-height)
(global-set-key [(control +)] 'increase-default-face-height)
(global-set-key [(control -)] 'decrease-default-face-height)


-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

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

[Drew Adams]

[I don't know if this is pertinant to this discussion or not - ignore if
not. (CC'ing the list because this is related to Miles's message -- this is
_not_ a request to consider this feature for inclusion in Emacs.)]

Karl,

I too wrote a command (`doremi-grow-font') that increases or decreases the
font size of the frame by an increment. You could bind it to, say, C-+ (and
bind to C-- a lambda that calls `doremi-grow-font' after flipping the sign
of the increment). Like Miles's code, this lets you, in effect, _zoom_ the
Emacs page (buffer) in and out easily.

However, I also wrote another command, `doremi-font-size', that uses
`doremi-grow-font' to let you increase or decrease the font size
incrementally using the arrow keys or the mouse wheel (like IE browser-text
zooming with the mouse wheel). Command `doremi-font-size' uses a very
general function, `doremi', which you can use to do almost anything
incrementally using the arrow keys or mouse wheel.

See, for discussion, code, and documentation,
http://www.emacswiki.org/cgi-bin/wiki/DoReMi (the font-size changing code is
in library http://www.emacswiki.org/elisp/doremi-frm.el; the general
`doremi' function is in library http://www.emacswiki.org/elisp/doremi.el).

Without going into the details of the rest, here is the code of
`doremi-grow-font', to give you an idea:

(defun doremi-grow-font (&optional increment frame)
  "Increase size of font in FRAME by INCREMENT.
Interactively, INCREMENT is given by the prefix argument.
Optional FRAME parameter defaults to current frame."
  (interactive "p")
  (setq frame (or frame (selected-frame)))
  (let ((fontname (cdr (assq 'font (frame-parameters frame)))))
    (when (query-fontset fontname)
      (setq fontname (nth 2 (assq 'ascii (aref (fontset-info fontname frame)
2)))))
    (let ((xlfd-fields (x-decompose-font-name fontname))
          new-font-name)
      (unless xlfd-fields (error "Cannot decompose font name"))
      (aset xlfd-fields
            xlfd-regexp-pixelsize-subnum
            (number-to-string
             (+ (string-to-number (aref xlfd-fields
xlfd-regexp-pixelsize-subnum))
                increment)))
      ;; Must set point size and width to "*", so frame width will adjust to
new font size
      (aset xlfd-fields xlfd-regexp-pointsize-subnum "*")
      (aset xlfd-fields xlfd-regexp-avgwidth-subnum "*")
      (setq new-font-name (x-compose-font-name xlfd-fields))
      (modify-frame-parameters frame (list (cons 'font new-font-name)))
      ;; Update faces that want a bold or italic version of the default
font.
      (frame-update-faces frame))))

Miles's code looks much simpler, and seems to work just as well. I don't
know what other functional differences there might be.

HTH,

  Drew

-----Original Message-----From: Miles Bader

On Tue, Nov 02, 2004 at 07:08:34PM +0100, Karl Eichwalder wrote:
> From time to time it is necessary to increase the font size: When I want
> to demonstrate something to somebody watching my screen, or when I want
> to check some accented or foreign characters more closely.

Something like the following elisp code might be more useful for this.  It
implements the C-+ and C-- (that's control-minus :-) bindings many modern
GUI
programs use to grow/shrink the default face.

... default-grow.el
<snip>

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

[Stefan]

> I too wrote a command (`doremi-grow-font') that increases or decreases the
> font size of the frame by an increment. You could bind it to, say, C-+ (and
> bind to C-- a lambda that calls `doremi-grow-font' after flipping the sign
> of the increment). Like Miles's code, this lets you, in effect, _zoom_ the
> Emacs page (buffer) in and out easily.

BTW, C-+ is OK because it's currently unused, but C-- is already bound and
I've been known to use it, so otherpeople might use it as well.


        Stefan


> -----Original Message-----From: Miles Bader

> On Tue, Nov 02, 2004 at 07:08:34PM +0100, Karl Eichwalder wrote:
>> From time to time it is necessary to increase the font size: When I want
>> to demonstrate something to somebody watching my screen, or when I want
>> to check some accented or foreign characters more closely.

> Something like the following elisp code might be more useful for this.  It
> implements the C-+ and C-- (that's control-minus :-) bindings many modern
> GUI
> programs use to grow/shrink the default face.

> ... default-grow.el
> <snip>



> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

incrementor-decrementor commands and bindings (was: finger-pointer curser as default for mouse-face text)

[Drew Adams]

This is starting to veer off-topic, but FWIW, this follows Stefan's last
point.

This was a main motivation behind my creating function `doremi':

I wanted to have several different incrementing/decrementing commands bound
to "repeatable" key sequences -- that is, chords (e.g. with modifiers) that
can be held down to repeat an action. The number of such chord combinations
is limited, however, and many combinations (e.g. the self-inserting chars,
the arrows) are already taken, so I looked for another approach.

I decided to use just the four arrow keys (and/or the mouse-wheel) for _all_
such commands - easy to use and remember. To do that, I have a non-chord
binding for each incrementor-decrementor command to "start it up"; then the
command itself reads the arrow keys and the mouse-wheel to do its job.

For instance, I have these command bindings:

C-x t c  doremi-bg-rgb - change frame background color incrementally
C-x t z  doremi-font-size - zoom: change frame font size incrementally
C-x t w  doremi-frame-width - change frame width incrementally
C-x t h  doremi-frame-height - change frame height incrementally
C-x t x  doremi-frame-horizontally - move frame left/right incrementally
C-x t y  doremi-frame-vertically - move frame up/down incrementally
C-x t b  doremi-buffers - successively cycle among existing buffers
C-x t m  doremi-bookmarks - successively cycle among bookmarks
C-x t t  doremi-color-themes - successively cycle among color themes
C-x t f  doremi-font - successively cycle among fonts, choosing by name
C-x t u  doremi-frame-configs - undo: cycle among recorded frame configs
C-x t .  save-frame-config - add current frame config to the cycle for `C-x
t u'

[ Actually only one of the `C-x t' bindings `w' and `h' is needed. Likewise,
only one of `x' and `y' really needs to be bound. Each of these commands
lets you use all _four_ arrow keys and/or the mouse-wheel to move the frame
in any direction or change any of its dimensions. So, for instance, a single
binding lets you increment and decrement the frame width and frame height.
It's like having 4 (+2 for the wheel) bindings in one. ]

These particular incrementor-decrementor commands might not seem that
interesting, but you might be able to imagine others that you would find
useful. The point is that if each such command had to use a different pair
of key bindings that let you continually hold the keys pressed, you would
soon run out of chord combinations, and you would in any case have
difficulty remembering them all.

Eventually, BTW, I'd like to see users be able (as an option) to use such
incrementor-decrementor commands to change appropriate settings on Customize
pages (you see the change as its made; you can undo it if you like). This is
not appropriate for all settings, by any means, but for some kinds of
settings it could be useful. An example might be changing the default frame
background color a la `doremi-bg-rgb'. The idea is to move more toward
direct manipulation in the UI.

 - Drew


-----Original Message-----From: Stefan

BTW, C-+ is OK because it's currently unused, but C-- is already bound and
I've been known to use it, so otherpeople might use it as well.

Re: incrementor-decrementor commands and bindings (was: finger-pointercurser as default for mouse-face text)

[Stephan Stahl]

Hi.

Drew Adams said:

> I decided to use just the four arrow keys (and/or the mouse-wheel) for _all_
> such commands - easy to use and remember. To do that, I have a non-chord
> binding for each incrementor-decrementor command to "start it up"; then the
> command itself reads the arrow keys and the mouse-wheel to do its job.

I really like this idea.  However i think the use of the arrowkeys /
mousewheel should be extended to maybe M-p, M-n.  Those keys should be
availible while not in minibuffer-mode and there they mirror the
behaviour of arrowkeys up / down.  I find it annoying to move the hand
off of the homerow.  Guess that's why i do not use things like C-x
<left> / <right> or <S-up>, <S-down>, <S-left>, <S-right> ....
My two cent :).

Stephan
-- 
Stephan Stahl

RE: incrementor-decrementor commands and bindings (was: finger-pointercurser as default for mouse-face text)

[Drew Adams]

Good suggestion. And trivial to add, of course.

FYI, two details I didn't mention -

 1. Using the Meta modifier with the arrow keys and/or the mouse wheel
boosts the incrementation (step size), so change is faster.

 2. There are four variables representing (by default) the up & down arrow
keys and their Meta versions. You can change these variables to use, say,
keys `C-n' and `C-p' instead of up & down. Also, for a command (like
`doremi-frame-horizontally') to use the left & right arrows instead of up &
down, it can just bind the up & down variables to the left & right arrow
keys before calling `doremi'.


-----Original Message-----From: Stephan Stahl
> I decided to use just the four arrow keys (and/or the mouse-wheel) for
_all_
> such commands - easy to use and remember. To do that, I have a non-chord
> binding for each incrementor-decrementor command to "start it up"; then
the
> command itself reads the arrow keys and the mouse-wheel to do its job.

I really like this idea.  However i think the use of the arrowkeys /
mousewheel should be extended to maybe M-p, M-n.  Those keys should be
availible while not in minibuffer-mode and there they mirror the
behaviour of arrowkeys up / down.  I find it annoying to move the hand
off of the homerow.  Guess that's why i do not use things like C-x
<left> / <right> or <S-up>, <S-down>, <S-left>, <S-right> ....

Re: incrementor-decrementor commands and bindings (was: finger-pointercurser as default for mouse-face text)

[Richard Stallman]

Please let's focus on fixing bugs and getting a release ready,
not on discussing plans for new features.

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

[Miles Bader]

On Tue, Nov 02, 2004 at 06:53:21PM -0500, Stefan wrote:
> BTW, C-+ is OK because it's currently unused, but C-- is already bound and
> I've been known to use it, so otherpeople might use it as well.

The current Emacs binding for `C--' (negatie-argument) seems pretty
redundant, as there are many other ways of getting the same thing (`M--',
`C-u -', both of which I suspect are more commonly used).  Since a "reduce
font size" binding of `C--' is rather common in other GUI programs
(gtk/gnome, mozilla), I'd say it easily trumps the current Emacs binding.

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

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

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Tue, Nov 02, 2004 at 06:53:21PM -0500, Stefan wrote:
>> BTW, C-+ is OK because it's currently unused, but C-- is already bound and
>> I've been known to use it, so otherpeople might use it as well.
>
> The current Emacs binding for `C--' (negatie-argument) seems pretty
> redundant, as there are many other ways of getting the same thing (`M--',
> `C-u -', both of which I suspect are more commonly used).  Since a "reduce
> font size" binding of `C--' is rather common in other GUI programs
> (gtk/gnome, mozilla), I'd say it easily trumps the current Emacs binding.

And current C-- users will quickly learn to keep away their fingers :-).

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

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

[Kim F. Storm]

Stefan <monnier@iro.umontreal.ca> writes:

>> I too wrote a command (`doremi-grow-font') that increases or decreases the
>> font size of the frame by an increment. You could bind it to, say, C-+ (and
>> bind to C-- a lambda that calls `doremi-grow-font' after flipping the sign
>> of the increment). Like Miles's code, this lets you, in effect, _zoom_ the
>> Emacs page (buffer) in and out easily.
>
> BTW, C-+ is OK because it's currently unused, but C-- is already bound and
> I've been known to use it, so otherpeople might use it as well.

Perhaps C-M-+ and C-M-- ?

C-M-- is bound to the same command as C-- and M--, so I think
we can steal that binding.


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

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

[David Kastrup]

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

> Stefan <monnier@iro.umontreal.ca> writes:
>
>>> I too wrote a command (`doremi-grow-font') that increases or decreases the
>>> font size of the frame by an increment. You could bind it to, say, C-+ (and
>>> bind to C-- a lambda that calls `doremi-grow-font' after flipping the sign
>>> of the increment). Like Miles's code, this lets you, in effect, _zoom_ the
>>> Emacs page (buffer) in and out easily.
>>
>> BTW, C-+ is OK because it's currently unused, but C-- is already bound and
>> I've been known to use it, so otherpeople might use it as well.
>
> Perhaps C-M-+ and C-M-- ?
>
> C-M-- is bound to the same command as C-- and M--, so I think
> we can steal that binding.

More often than not, this will switch screen resolutions in the X
server.  While one can circumvent this with ESC C--, this pretty much
defeats the purpose of having a keybinding easy to find.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Richard Stallman]

    The main problem with these commands -- and so why I haven't pursued adding
    them to the official sources[*] -- is that they don't interact well with a
    default face which has been set using customize-face (because the Emacs
    face-customization machinery sucks).

Could you please describe the problem in a clearer, more constructivne
way?

    BTW, C-+ is OK because it's currently unused, but C-- is already bound and
    I've been known to use it, so otherpeople might use it as well.

If someday we make faces more useful than now, it might be worth
redefining C-- this way.  The commands could apply to the region when
transient-mark-mode is non-nil.

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

[Kim F. Storm]

Karl Eichwalder <ke@gnu.franken.de> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> It is interesting to find a user who often specifies faces.
>> Can you tell us the circumstances where you do that?
>
>>From time to time it is necessary to increase the font size: When I want
> to demonstrate something to somebody watching my screen, or when I want
> to check some accented or foreign characters more closely.

Perhaps we could restrict the current S-mouse-1 binding to only work
on the modeline for example.

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

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

[Richard Stallman]

    >From time to time it is necessary to increase the font size: When I want
    to demonstrate something to somebody watching my screen, or when I want
    to check some accented or foreign characters more closely.

The question is how common it is for users to use this feature.
Perhaps we should ask them.

However, if we don't have any specific thing we want to do using
S-mouse-1, we may as well leave it alone anyway.

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

[Richard Stallman]

    Well, if the "normal" click follows the link (and I claim that the
    normal click is the short click), most users will never think there is
    a problem, as they don't usually have to set the mouse in the middle
    of a link.

    They will probably set it next to the link and move the cursor into
    the link (that's how it is often done in other applications).

That seems pretty convincing, so I guess it is ok to make this change.

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

[Richard Stallman]

    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.

What's the point of adding it if it will be disabled by default?
Only for people with two-button mice?  These are not common with
GNU/Linux are they?

I thought the whole point was that beginning users would not know
about Mouse-2 and find Emacs harder to use as a result.  The only
way the feature can address this is if it is on by default.
We're looking for ways to make the default Emacs behavior better;
any options are a secondary matter.

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     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.
>
> What's the point of adding it if it will be disabled by default?

Personally, I think it should be enabled by default, but I felt some
general resistance towards this feature building up, so I was just
being defensive :-)

> Only for people with two-button mice?  These are not common with
> GNU/Linux are they?

They are common on laptops (installing GNU/Linux on it didn't seem to
add the missing button :-)


>
> I thought the whole point was that beginning users would not know
> about Mouse-2 and find Emacs harder to use as a result.  The only
> way the feature can address this is if it is on by default.

Agree.

> We're looking for ways to make the default Emacs behavior better;
> any options are a secondary matter.

The problem is to agree on what the behaviour should be...

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

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

[Stefan Monnier]

> (installing GNU/Linux on it didn't seem to add the missing button :-)

It's because you didn't try hard(ware) enough!


        Stefan

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

[David Kastrup]

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

> Richard Stallman <rms@gnu.org> writes:
>
>> Only for people with two-button mice?  These are not common with
>> GNU/Linux are they?
>
> They are common on laptops (installing GNU/Linux on it didn't seem
> to add the missing button :-)

Emulate-3-buttons is offered by X servers as well as gpm and pretty
much required on such systems, not just for Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Only for people with two-button mice?  These are not common with
> GNU/Linux are they?

That's what Microsoft uses, so for a while they were _very_ common on
the sort of commodity hardware most people use.

The middle button seems to have come back recently in the form of a
clickable scroll wheel, which most mice seem to have these days.

-Miles
-- 
We live, as we dream -- alone....

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

[Kai Grossjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Adding a message saying "please keep the button pressed longer if you want
> to follow the link" is really not much better than adding a message that
> says "use mouse-2 if you want to follow the link".

Both Microsoft Windows and Apple MacOS (including X, I guess) allow
you to keep the button pressed a little longer to rename, instead of
select, a file.

So the "keep it pressed longer" action is a known one.

Keeping the button pressed longer to edit the text where the link is
seems natural.  I like this idea.

Kai

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

[David Kastrup]

Kai Grossjohann <kai@emptydomain.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Adding a message saying "please keep the button pressed longer if you want
>> to follow the link" is really not much better than adding a message that
>> says "use mouse-2 if you want to follow the link".
>
> Both Microsoft Windows and Apple MacOS (including X, I guess) allow
> you to keep the button pressed a little longer to rename, instead of
> select, a file.
>
> So the "keep it pressed longer" action is a known one.
>
> Keeping the button pressed longer to edit the text where the link is
> seems natural.  I like this idea.

It would appear that the shorter duration click here is the one that
does the "simpler" action, namely selection, whereas the longer click
does the action with more effect.  Also the shorter click does the
action that does not need to be undone if you don't like it.

Anyway: if we really try modelling ourselves after other systems: in
file managers and the like, one usually selects a single item (and
placed point) by a single click, and executes it by a double click.

I think that nobody will complain if a double click on a link will
cause it to execute instead of marking a word or line.  It is indeed
rare that you need to mark a work from inside a link; and if you do,
you can do it by normal dragging marking without much additional
hassle.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> I think that nobody will complain if a double click on a link will
> cause it to execute instead of marking a word or line.  It is indeed
> rare that you need to mark a work from inside a link; and if you do,
> you can do it by normal dragging marking without much additional
> hassle.

It was a little more complex to implement than the previous methods,
but here is a patch which adds 'double click' support as a user option:

Index: mouse.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mouse.el,v
retrieving revision 1.251
diff -c -r1.251 mouse.el
*** mouse.el	18 Oct 2004 09:29:26 -0000	1.251
--- mouse.el	27 Oct 2004 12:29:31 -0000
***************
*** 48,53 ****
--- 48,77 ----
    :type 'boolean
    :group 'mouse)
  
+ (defcustom mouse-1-click-follows-link 'double
+   "Non-nil means that clicking mouse-1 on a link follows the link.
+ This is only done for links which have the mouse-face property.
+ 
+ If value is the symbol double, a double click follows the link.
+ 
+ If value is an integer, the time between pressing and releasing
+ the mouse button determines whether to follow the link or perform
+ the normal mouse-1 action (typically set point).  The absolute
+ numeric value specifices the maximum duration of a \"short click\"
+ in milli-seconds.  A positive value means that a short click
+ follows the link, and a longer click performs the normal action.
+ A negative value specifies the opposite behaviour.
+ 
+ Otherwise, a single mouse-1 click unconditionally follows the link.
+ 
+ Note that dragging the mouse never follows the link."
+   :version "21.4"
+   :type '(choice (const :tag "Disabled" nil)
+ 		 (const :tag "Double click" double)
+                  (number :tag "Single click time limit" :value 300)
+                  (other :tag "Single click" t))
+   :group 'mouse)
+ 
  \f
  ;; Provide a mode-specific menu on a mouse button.
  
***************
*** 731,736 ****
--- 755,764 ----
        (run-hooks 'mouse-leave-buffer-hook)
        (mouse-drag-region-1 start-event))))
  
+ (defun mouse-on-link-p (pos)
+   (and (get-char-property pos 'mouse-face)
+        (not (get-char-property pos 'dont-follow-link))))
+ 
  (defun mouse-drag-region-1 (start-event)
    (mouse-minibuffer-check start-event)
    (let* ((echo-keystrokes 0)
***************
*** 746,751 ****
--- 774,780 ----
  		     (nth 3 bounds)
  		   ;; Don't count the mode line.
  		   (1- (nth 3 bounds))))
+ 	 on-link remap-double-click
  	 (click-count (1- (event-click-count start-event))))
      (setq mouse-selection-click-count click-count)
      (setq mouse-selection-click-count-buffer (current-buffer))
***************
*** 755,760 ****
--- 784,796 ----
      (if (< (point) start-point)
  	(goto-char start-point))
      (setq start-point (point))
+     (setq on-link (and mouse-1-click-follows-link
+ 		       (mouse-on-link-p start-point)))
+     (setq remap-double-click (and on-link
+ 				  (eq mouse-1-click-follows-link 'double)
+ 				  (= click-count 1)))
+     (if remap-double-click  ;; Don't expand mouse overlay in links
+ 	(setq click-count 0))
      (let ((range (mouse-start-end start-point start-point click-count)))
        (move-overlay mouse-drag-overlay (car range) (nth 1 range)
  		    (window-buffer start-window))
***************
*** 877,882 ****
--- 913,938 ----
  			 (or end-point
  			     (= (window-start start-window)
  				start-window-start)))
+ 		(if (and on-link
+ 			 (not end-point)
+ 			 (consp event)
+ 			 (or remap-double-click
+ 			     (and
+ 			      (not (eq mouse-1-click-follows-link 'double))
+ 			      (= click-count 0)
+ 			      (= (event-click-count event) 1)
+ 			      (not (input-pending-p))
+ 			      (or (not (integerp mouse-1-click-follows-link))
+ 				  (let ((t0 (posn-timestamp (event-start start-event)))
+ 					(t1 (posn-timestamp (event-end event))))
+ 				    (and (integerp t0) (integerp t1)
+ 					 (if (> mouse-1-click-follows-link 0)
+ 					     (<= (- t1 t0) mouse-1-click-follows-link)
+ 					   (< (- t0 t1) mouse-1-click-follows-link)))))
+ 			      (or (not double-click-time)
+ 				  (sit-for 0 (if (integerp double-click-time)
+ 						 double-click-time 500) t)))))
+ 		    (setcar event 'mouse-2))
  		(setq unread-command-events
  		      (cons event unread-command-events)))))
  	(delete-overlay mouse-drag-overlay)))))

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

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

[Richard Stallman]

    Anyway: if we really try modelling ourselves after other systems: in
    file managers and the like, one usually selects a single item (and
    placed point) by a single click, and executes it by a double click.

File managers and browsers represent two different UI traditions, so
they provide different models to follow.  Some things in Emacs are
clearly links; it makes no sense for them to act like file managers.

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

[Richard Stallman]

    > After all, we have the same problem with recognizing double-clicks.

    Sure.  But users have wanted double-clicks, so we gave it to them.
    Users's aren't asking for variable-duration clicks.

This may be the best way to give various different users the different
things they want, more or less.  It is impossible to satisfy all the
constraints here.

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

[Richard Stallman]

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

It would be easy enough to make preview-latex a special case.

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

[Kim F. Storm]

Stefan <monnier@iro.umontreal.ca> writes:

>> I found a simpler solution which works really well, as it provides the
>> fallback directly on mouse-1 itself:
>
>> Measure the time between the mouse-1 down event and the up event, and
>> if it less than 300 ms (configurable), follow the link, else do what
>> mouse-1 normally does.
>
> Sounds like a terrible idea to me.  Working with X11-over-DSL means that
> timing is rather unreliable.  Same thing with heavy-swapping (as happens
> when a I do `tla star-merge' :-( ).

True, but the worst thing that can happen (if you use a positive
value) is that the click sets the point rather than follows the link
-- so if things are slow, just click again (and hope for the best) or
use mouse-2.

I don't think that's terrible at all.

And you can always set the variable to t, meaning that you will need
to drag to set point.

And on a local system, it works really well!!!

>
> And even if the timing could be measured accurately, I don't find the "hold
> the mouse button longer" to be intuitive at all for "move point".

Press harder to make the glue stick :-)

Personally I find "drag to set point" much less intuitive which is why
I'm looking for a better solution.

> I think we're trying to squeeze too much info in those events.  I'm quite
> happy with the distinction between click and drag but I don't think we
> should go further than that.

We are trying to find a simple(!) way to let mouse-1 do its normal thing
in the rare situation (except for David :-) where the user wants to set
point in the middle of a link.

Providing the "long click" as a user option is trivial (it is 3 lines
of code and it is already done), and personally, I find it quite
intuitive.

Whether we want to turn it on by default (with or without timeout) is
another matter.

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

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

[David Kastrup]

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

> Stefan <monnier@iro.umontreal.ca> writes:
>
>>> I found a simpler solution which works really well, as it provides the
>>> fallback directly on mouse-1 itself:
>>
>>> Measure the time between the mouse-1 down event and the up event, and
>>> if it less than 300 ms (configurable), follow the link, else do what
>>> mouse-1 normally does.
>>
>> Sounds like a terrible idea to me.  Working with X11-over-DSL means that
>> timing is rather unreliable.  Same thing with heavy-swapping (as happens
>> when a I do `tla star-merge' :-( ).
>
> True, but the worst thing that can happen (if you use a positive
> value) is that the click sets the point rather than follows the link
> -- so if things are slow, just click again (and hope for the best)
> or use mouse-2.

Whether the system load delays the click or the release event more
can't be guessed in advance, regardless of the settings.  In either
case, you can get the two confused either way.  Which can mean that
the link gets followed where the intent was to set point.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> True, but the worst thing that can happen (if you use a positive
>> value) is that the click sets the point rather than follows the link
>> -- so if things are slow, just click again (and hope for the best)
>> or use mouse-2.
>
> Whether the system load delays the click or the release event more
> can't be guessed in advance, regardless of the settings.  In either
> case, you can get the two confused either way.  Which can mean that
> the link gets followed where the intent was to set point.

Hm, true, but at least on X, the timestamps are recorded by the X
server, so it's not depending on emacs getting any cycles to process
the clicks.

I still believe that it will work _satisfactory_ in practice.  But the
doc string could mention the potential problem.

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

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

[Richard Stallman]

    > Sounds like a terrible idea to me.  Working with X11-over-DSL means that
    > timing is rather unreliable.  Same thing with heavy-swapping (as happens
    > when a I do `tla star-merge' :-( ).

    True, but the worst thing that can happen (if you use a positive
    value) is that the click sets the point rather than follows the link

If the timing can be distorted, it can be distorted in either
direction.  However, we don't see a lot of complaints that double
click doesn't work, so maybe it is not a serious problem.

    Hm, true, but at least on X, the timestamps are recorded by the X
    server, so it's not depending on emacs getting any cycles to process
    the clicks.

That seems to imply there is no real problem of this kind.
It was useful to consider the question, though.

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

[Richard Stallman]

    Measure the time between the mouse-1 down event and the up event, and
    if it less than 300 ms (configurable), follow the link, else do what
    mouse-1 normally does.

That could be a very good solution.  If the user gets distracted and
holds the button down too long, nothing bad happens, so he can easily
try again.  I like it!

However, what about double-clicking?  I think that won't be easy to do.
The user will have to hold the first click longer, then quickly
click again.

We could solve this problem by waiting for double-click-time before
following the link.  Could you give that a try and see if the behavior
is still ok?

    So I'd very much prefer making the long press follow the link, even
    though a long press is more likely to get interpreted as a drag
    instead.

That seems more convenient, since it does not get in the way of double
clicks, and it follows the principle that you do more to get a bigger
action.  However, it has the drawback that beginners just clicking
around won't know to try it.  They might try an ordinary click, see it
doesn't follow the link, and give up.

So maybe the short click, on a link, should display a message saying
"Hold the button down for .3 seconds to follow the link".

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

[David Kastrup]

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

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> I see what you're saying. You've made it possible to follow links (and click
>> buttons) using mouse-1 (in addition to using mouse-2).
>>
>> I really must not have made myself clear. RMS had the same misunderstanding
>> as you.
>
> Well, common user interface practice is that clicking mouse-1 on a
> link follows that link.
>
>>
>> My point was not that using mouse-2 is not good. I think mouse-2 should
>> remain the way to click links and buttons in Emacs, don't you? 
>
> While I find this discussion of which pointer to use "amusing", IMO
> using mouse-2 is a serious flaw in the emacs user interface. 

In Gnus, I get buttons displayed like
[attachment image.jpg]

I can click with the middle button to execute a default operation.
What I do more frequently is click with the left button, then press a
key like "o" to indicate the action.  Most (but I don't think all)
actions can be selected with a context menu on the right mouse button,
but that also means that I have to use a mouse-based file dialog,
which is far more inconvenient.  It is also much faster for me to type
a single letter than to drag the mouse cursor to the right menu entry.

If clicking mouse-1 on the button would launch the default action,
this would be far more inconvenient for me.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> In Gnus, I get buttons displayed like
> [attachment image.jpg]
>
> I can click with the middle button to execute a default operation.
> What I do more frequently is click with the left button, then press a
> key like "o" to indicate the action.  Most (but I don't think all)
> actions can be selected with a context menu on the right mouse button,
> but that also means that I have to use a mouse-based file dialog,
> which is far more inconvenient.  It is also much faster for me to type
> a single letter than to drag the mouse cursor to the right menu entry.
>
> If clicking mouse-1 on the button would launch the default action,
> this would be far more inconvenient for me.

I see the problem.  Maybe mouse-2 could set the point ?

Anyways, nobody would force you to use the mouse-1-follows-link feature.

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

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

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>> In Gnus, I get buttons displayed like
>> [attachment image.jpg]
>>
>> I can click with the middle button to execute a default operation.
>> What I do more frequently is click with the left button, then press a
>> key like "o" to indicate the action.  Most (but I don't think all)
>> actions can be selected with a context menu on the right mouse button,
>> but that also means that I have to use a mouse-based file dialog,
>> which is far more inconvenient.  It is also much faster for me to type
>> a single letter than to drag the mouse cursor to the right menu entry.
>>
>> If clicking mouse-1 on the button would launch the default action,
>> this would be far more inconvenient for me.
>
> I see the problem.  Maybe mouse-2 could set the point ?

Basically you propose that we interchange button-1 and button-2 on
active text areas.  If I take packages like preview-latex, we can
click on formula images in it.  Mouse button 2 gets you the source
text, but you can also just mark it by dragging mouse-1, or by
clicking mouse-1 on the image, and mouse-3 behind it.

Your proposal would mean that I have to click mouse-2 and mouse-3
around the area for marking, or drag mouse-1.

> Anyways, nobody would force you to use the mouse-1-follows-link
> feature.

That's never a good argument.  If we want to introduce a new feature,
we want to make it as good as possible instead of claiming it is the
user's fault anyway if he chooses to activate it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> In Gnus, I get buttons displayed like
>>> [attachment image.jpg]
>>>
>>> I can click with the middle button to execute a default operation.
>>> What I do more frequently is click with the left button, then press a
>>> key like "o" to indicate the action.  Most (but I don't think all)
>>> actions can be selected with a context menu on the right mouse button,
>>> but that also means that I have to use a mouse-based file dialog,
>>> which is far more inconvenient.  It is also much faster for me to type
>>> a single letter than to drag the mouse cursor to the right menu entry.
>>>
>>> If clicking mouse-1 on the button would launch the default action,
>>> this would be far more inconvenient for me.
>>

In the case of gnus attachments, you can click mouse-1 to THE RIGHT of
the button and still be able to use the key bindings.

Alternatively, you can drag mouse-1 in the link to set point there.

>> I see the problem.  Maybe mouse-2 could set the point ?

I generally want to avoid messing with mouse-2 or mouse-3 -- as the
major deviation from common GUI standards only affects mouse-1.

The major problem with mouse-2 is when you only have a two-button mouse
(can you even get a laptop with three mouse buttons).

Sure, I also have a three-button mouse -- but the middle button is
on a mouse wheel which is also awkward to click.

I have been using my little hack for a few days now, and I absolutely
love it.  No more messing with clicking both mouse-buttons or mouse
wheel to follow a link.  I still have to find

>
> Basically you propose that we interchange button-1 and button-2 on
> active text areas.  

I didn't propose it -- it was just an idea...  It's obviously not
a good idea in general.

>> Anyways, nobody would force you to use the mouse-1-follows-link
>> feature.
>
> That's never a good argument.  If we want to introduce a new feature,
> we want to make it as good as possible instead of claiming it is the
> user's fault anyway if he chooses to activate it.

Sure.  We need to find a way to DTRT in cases where mouse-1 is needed.

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

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

[Drew Adams]

What about using keyboard modifiers with mouse-1 on an active area (link,
button) to do what mouse-1 would normally do on an inactive area (e.g.
mouse-drag-region)?

The following are not defined by default, at least in most Emacs modes:
C-M-mouse-1, C-S-mouse-1, M-S-mouse-1.


-----Original Message-----From: Kim F. Storm
In the case of gnus attachments, you can click mouse-1 to THE RIGHT of
the button and still be able to use the key bindings. Alternatively, you can
drag mouse-1 in the link to set point there.

I generally want to avoid messing with mouse-2 or mouse-3 -- as the
major deviation from common GUI standards only affects mouse-1. The major
problem with mouse-2 is when you only have a two-button mouse...

Sure.  We need to find a way to DTRT in cases where mouse-1 is needed.

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

[Stefan Monnier]

> What about using keyboard modifiers with mouse-1 on an active area (link,
> button) to do what mouse-1 would normally do on an inactive area (e.g.
> mouse-drag-region)?

> The following are not defined by default, at least in most Emacs modes:
> C-M-mouse-1, C-S-mouse-1, M-S-mouse-1.

I think the effort required to remember such bindings, coupled with the fact
that they'd only be used on relatively rare occasions, makes me think it's
a bad idea.
Especially since in all likely hood, after setting point in the middle of
a button, you're going to do something with the keyboard rather than with
the mouse, which makes me think that using the keyboard to move to that spot
would work just as well.


        Stefan

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

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What about using keyboard modifiers with mouse-1 on an active area (link,
>> button) to do what mouse-1 would normally do on an inactive area (e.g.
>> mouse-drag-region)?
>
>> The following are not defined by default, at least in most Emacs modes:
>> C-M-mouse-1, C-S-mouse-1, M-S-mouse-1.
>
> I think the effort required to remember such bindings, coupled with the fact
> that they'd only be used on relatively rare occasions, makes me think it's
> a bad idea.
> Especially since in all likely hood, after setting point in the middle of
> a button, you're going to do something with the keyboard rather than with
> the mouse, which makes me think that using the keyboard to move to that spot
> would work just as well.

Ah, but if you use cursor-left or cursor-right to move onto a preview,
the preview opens up into normal text (some sort of special
auto-reveal action).  So in the particular case of preview-latex, it
is not an alternative to click just before or after a preview and then
move onto it using forward-char or backward-char.

I am not claiming that this is the ultimate reason or whatever, I am
just pointing out that in this case it would be problematic.

In addition, we have to be aware that clickable fields are usually
implemented with keymaps.  And that means that there is no way to
magically change all buttons in all applications: it is a convention
rather than an API.  If we want to change to a different convention,
we first need to define an API where the current convention is
accessible to outside packages, then wait for a few releases with the
old convention in place, and then try changing the default and weather
the inconsistency storm from packages that have not yet adhered to the
API telling it what mouse buttons to use.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> I am not claiming that this is the ultimate reason or whatever, I am
> just pointing out that in this case it would be problematic.

My mouse-1 patch only sets in with links that have mouse-face.

Why do preview-latex images need to have mouse-face property ?
Images can have mouse-2 bindings even without that.

>
> In addition, we have to be aware that clickable fields are usually
> implemented with keymaps.  And that means that there is no way to
> magically change all buttons in all applications: it is a convention
> rather than an API.  If we want to change to a different convention,
> we first need to define an API where the current convention is
> accessible to outside packages, then wait for a few releases with the
> old convention in place, and then try changing the default and weather
> the inconsistency storm from packages that have not yet adhered to the
> API telling it what mouse buttons to use.

If mouse-1 has a non-standard binding on a link, my patch obeys that
binding.

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

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

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>> I am not claiming that this is the ultimate reason or whatever, I am
>> just pointing out that in this case it would be problematic.
>
> My mouse-1 patch only sets in with links that have mouse-face.
>
> Why do preview-latex images need to have mouse-face property ?
> Images can have mouse-2 bindings even without that.

But the mouse-face property is the normal way to indicate that using
mouse-2 will do something different from pasting.

>> In addition, we have to be aware that clickable fields are usually
>> implemented with keymaps.  And that means that there is no way to
>> magically change all buttons in all applications: it is a
>> convention rather than an API.  If we want to change to a different
>> convention, we first need to define an API where the current
>> convention is accessible to outside packages, then wait for a few
>> releases with the old convention in place, and then try changing
>> the default and weather the inconsistency storm from packages that
>> have not yet adhered to the API telling it what mouse buttons to
>> use.
>
> If mouse-1 has a non-standard binding on a link, my patch obeys that
> binding.

So what?  preview-latex images don't have a non-standard binding for
mouse-1.  So I am citing it as an example that will cause trouble and
requires a migration plan instead of a sudden change.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>> Why do preview-latex images need to have mouse-face property ?
>> Images can have mouse-2 bindings even without that.
>
> But the mouse-face property is the normal way to indicate that using
> mouse-2 will do something different from pasting.

What visible effect do you get for an image when moving the mouse over it?

You can also change the mouse pointer shape.

>
>>> In addition, we have to be aware that clickable fields are usually
>>> implemented with keymaps.  And that means that there is no way to
>>> magically change all buttons in all applications: it is a
>>> convention rather than an API.  If we want to change to a different
>>> convention, we first need to define an API where the current
>>> convention is accessible to outside packages, then wait for a few
>>> releases with the old convention in place, and then try changing
>>> the default and weather the inconsistency storm from packages that
>>> have not yet adhered to the API telling it what mouse buttons to
>>> use.
>>
>> If mouse-1 has a non-standard binding on a link, my patch obeys that
>> binding.
>
> So what?  preview-latex images don't have a non-standard binding for
> mouse-1.  So I am citing it as an example that will cause trouble and
> requires a migration plan instead of a sudden change.

It was one way to avoid the mouse-1 remapping (by trivial code rewrite).

I have little hope of finding a perfect solution (i.e. one which works
for everything without anything having to adapt to some kind of method
to fine-tune the behaviour in specific cases).  Maybe it's ok if it
works in 95% of all cases (and the remaning 5% must be tweaked a
little to work).

Link on images may be special anyway -- so perhaps I shouldn't remap
over an image.  

Maybe it should be mode specific, i.e. only do this if buffer is in
some known major mode (e.g. info, help, gnus summary, custom).

e.g.

(put 'help-mode 'map-links t)
(put 'info-mode 'map-links t)

could later be enhanced to support:

(put 'preview-latex-mode 'map-links 'text-only)

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

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

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>>> Why do preview-latex images need to have mouse-face property ?
>>> Images can have mouse-2 bindings even without that.
>>
>> But the mouse-face property is the normal way to indicate that using
>> mouse-2 will do something different from pasting.
>
> What visible effect do you get for an image when moving the mouse
> over it?

Transparent areas of the image turn green (or whatever your highlight
color is).  preview-latex explicitly places a transparent border
around images to achieve that effect.  Even if the image is not
transparent, some part of the line spacing usually turns green.

> You can also change the mouse pointer shape.

But that's not the "traditional way" since it was not available for as
long.  And it's beside the point, anyway, since it does not provide
any better idea about when to interchange mouse-1 and mouse-2.

>> So what?  preview-latex images don't have a non-standard binding
>> for mouse-1.  So I am citing it as an example that will cause
>> trouble and requires a migration plan instead of a sudden change.
>
> It was one way to avoid the mouse-1 remapping (by trivial code
> rewrite).
>
> I have little hope of finding a perfect solution (i.e. one which
> works for everything without anything having to adapt to some kind
> of method to fine-tune the behaviour in specific cases).  Maybe it's
> ok if it works in 95% of all cases (and the remaning 5% must be
> tweaked a little to work).

Sure.  That's why I say we need a migration plan.  Providing an
option, and then at some time making that option a default is not a
migration plan.  We need to define what an application needs to do in
order to get consistent behavior both with and without that option,
and we need to get the message out.  And then, at one time, people can
hope to turn this option on and off according to their preferences
without expecting to get something completely inconsistent.  And when
we arrive at that stage, it might make sense switching the default of
the option.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum