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

Feature Freeze

[Nick Roberts]

The last three bugs that I've seen are due to changes made in the last few
days.  I don't know what problems they solved and clearly the bugs they've
introduced is more apparent than the ones they've fixed.

If the intention really is to make a release how about introducing a freeze
where *all* developers must get approval before making *any* changes?  Or
alternatively let's forget the freeze and allow any changes.  This intermediate
state is a nonsense.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Feature Freeze

[Chong Yidong]

> If the intention really is to make a release how about introducing a
> freeze where *all* developers must get approval before making *any*
> changes?

The changes to sit-for were discussed at length on this list.

Re: Feature Freeze

[Nick Roberts]

Chong Yidong writes:
 > > If the intention really is to make a release how about introducing a
 > > freeze where *all* developers must get approval before making *any*
 > > changes?
 > 
 > The changes to sit-for were discussed at length on this list.

I'm talking generally.  Fixing a bug introduced into Emacs three years ago
seems like progress.  Fixing a bug introduced three days ago doesn't.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Feature freeze

[Chong Yidong]

Hi people,

It's time to begin the feature freeze.

A couple of people still have small non-bugfix patches scheduled to go
into CVS; please check these in over the 24 hours, or email me if you
have problems.  Otherwise, don't commit any more new features.  If in
doubt, email emacs-devel for discussion.

Two exceptions: we'll allow the proced.el and rmail-mbox changes.

There currently isn't any detailed schedule for the release.  My hope
(and I think Stefan concurs) is to have 23.1 out in about six months
from now.  Maybe this is optimistic; we'll see.

My rough plan is to go through the bug list and finish those pertinent
to both Emacs 22 and Emacs 23 first.  About 2 weeks from now, I'll start
the Emacs 22.3 pretest, which hopefully won't take much effort and can
be completed in a month or two.  Once 22.3 is released, we'll take
another look at the bug count and see how soon afterwards we can start
the 23.1 pretest.

There are 180+ outstanding bugs, which can be browsed at the bugtracker
here:

http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?which=pkg&data=emacs&archive=no&version=&dist=unstable

Let's get to work on these.  If you need help using the bug tracker,
please email me.

Thanks!

Re: Feature freeze

[Kenichi Handa]

In article <87tze6mz3c.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> Hi people,
> It's time to begin the feature freeze.

> A couple of people still have small non-bugfix patches scheduled to go
> into CVS; please check these in over the 24 hours, or email me if you
> have problems.  Otherwise, don't commit any more new features.  If in
> doubt, email emacs-devel for discussion.

> Two exceptions: we'll allow the proced.el and rmail-mbox changes.

> There currently isn't any detailed schedule for the release.  My hope
> (and I think Stefan concurs) is to have 23.1 out in about six months
> from now.  Maybe this is optimistic; we'll see.

> My rough plan is to go through the bug list and finish those pertinent
> to both Emacs 22 and Emacs 23 first.  About 2 weeks from now, I'll start
> the Emacs 22.3 pretest, which hopefully won't take much effort and can
> be completed in a month or two.  Once 22.3 is released, we'll take
> another look at the bug count and see how soon afterwards we can start
> the 23.1 pretest.

As I wrote before, I'm now working on the new implementation
of automatic-character-composition that doesn't use text
property.  The work is not for a new feature, but I realized
that an element in composition-function-table must be
changed slightly, and a few new Lisp functions must be
added (in a broad sense, it's a new feature).  Please let me
check-in the necessary changes for that work even after the
feature freeze.

---
Kenichi Handa
handa@ni.aist.go.jp

Feature freeze

[Stefan Monnier]

> But... a formal announcemente about which state are we just now and
> when do we <em>expect</em> to release the first pretest tarball would
> be welcome.

OK, so to clarify:
- We started the feature freeze on July 1.
- The freeze is somewhat progressive/soft and we hope to harden it by end
  of July.
- The first pretest will come out as soon as we don't have enough bugs
  open to keep us busy (more or less).  How long that will take after
  the hard feature freeze is not yet determined.


        Stefan

Feature freeze

[Stefan Monnier]

If you want to install some new features in Emacs's trunk, do it now,
because the trunk will be feature-frozen starting next week-end.


        Stefan "who wouldn't want Santa to come and install some
                undiscussed new feature while we sleep"

Re: Feature freeze

[Jambunathan K]

Stefan

I would like to merge my pending changes to ox-odt.el directly to the
Emacs trunk.

A recent change in LibreOffice 4.1 is causing the documents produced by
the ODT exporter to be "un-openable".  See
http://lists.gnu.org/archive/html/emacs-orgmode/2013-12/msg00047.html

If you are interested you can send me the instruction off the list.

NOTE: In principle, I will not commit my changes to Org-mode repo.  The
rest can be negotiated.

Jambunathan K.

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> If you want to install some new features in Emacs's trunk, do it now,
> because the trunk will be feature-frozen starting next week-end.
>
>
>         Stefan "who wouldn't want Santa to come and install some
>                 undiscussed new feature while we sleep"

Re: Feature freeze

[Stefan Monnier]

> I would like to merge my pending changes to ox-odt.el directly to the
> Emacs trunk.

AFAIK, currently, you haven't signed the necessary copyright paperwork,
so we can't accept your changes.  If you want to contribute patches to
Emacs, please address this first.

As for changes to Org, you can send them via M-x report-emacs-bug or
send them to Org maintainers directly.  The Org code will be sync'd back
to Emacs (they got a special "feature freeze exemption"), so it will
work as well.


        Stefan

Re: Feature freeze

[Jambunathan K]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I would like to merge my pending changes to ox-odt.el directly to the
>> Emacs trunk.

> If you want to contribute patches to Emacs, please address this first.

Will do (See "Conditions Apply" below).

> As for changes to Org, you can send them via M-x report-emacs-bug or
> send them to Org maintainers directly.  The Org code will be sync'd back
> to Emacs (they got a special "feature freeze exemption"), so it will
> work as well.

As the original author of ox-odt.el, I would like to manage the changes
directly in Emacs trunk.  I don't want to deal with any intermediaries
committing changes on my behalf.

Re: Feature freeze

[Glenn Morris]

Stefan Monnier wrote:

> The Org code will be sync'd back to Emacs (they got a special "feature
> freeze exemption")

Any special reason for this exception?
Is it just "lives in an external repo and is big"?
Because there were large non-bugfix Org mode changes late during
the 24.3 cycle, which were so big they were basically impossible to
check, and they caused some problems:

http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00108.html

So personally I'm disappointed to see the same thing on the cards again.

Re: Feature freeze

[Stefan Monnier]

> Any special reason for this exception?
> Is it just "lives in an external repo and is big"?

Pretty much, yes.

> Because there were large non-bugfix Org mode changes late during
> the 24.3 cycle, which were so big they were basically impossible to
> check, and they caused some problems:
> http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00108.html
> So personally I'm disappointed to see the same thing on the cards again.

This "feature freeze exemption" isn't meant to imply "commit any time
you like".  Basically, what it means for me is that if/when they have
code ready to merge into Emacs, we may accept it even after the freeze,
as long as there's still enough time before the release.

E.g. installing a new version in January should be fine, February,
probably, and after that, less likely, tho it depends on how well the
release process is going.  Does that sound good enough for you?


        Stefan

Re: Feature freeze

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 16 Dec 2013 13:49:25 -0500
> Cc: emacs-devel@gnu.org
> 
> This "feature freeze exemption" isn't meant to imply "commit any time
> you like".  Basically, what it means for me is that if/when they have
> code ready to merge into Emacs, we may accept it even after the freeze,
> as long as there's still enough time before the release.

How is this different from what I might have in my local feature
branch?

Re: Feature freeze

[Stefan Monnier]

>> This "feature freeze exemption" isn't meant to imply "commit any time
>> you like".  Basically, what it means for me is that if/when they have
>> code ready to merge into Emacs, we may accept it even after the freeze,
>> as long as there's still enough time before the release.
> How is this different from what I might have in my local feature
> branch?

The code coming in from Org's repository has generally gone through some
reasonable beta-testing (and normally, the rest of Emacs
doesn't/shouldn't depend on Org's code, so a problem in Org mode
shouldn't affect the rest of the release too significantly).



        Stefan

Re: Feature freeze

[Jambunathan K]

Stefan

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I would like to merge my pending changes to ox-odt.el directly to the
>> Emacs trunk.
>
> AFAIK, currently, you haven't signed the necessary copyright paperwork,
> so we can't accept your changes.  If you want to contribute patches to
> Emacs, please address this first.

My offer stands.

Don't hesitate to write to me if there is a felt need for having my
patches in Emacs.  I will oblige in no time.

Jambunathan K

Re: Feature freeze

[Michael Albinus]

Jambunathan K <kjambunathan@gmail.com> writes:

> I would like to merge my pending changes to ox-odt.el directly to the
> Emacs trunk.

[...]

> NOTE: In principle, I will not commit my changes to Org-mode repo.  The
> rest can be negotiated.

IIRC, you have vetoed applying any of your patches to the org-mode
project. Do you have changed your mind?

If not, I believe your patches are not applicable to Emacs proper as well.

> Jambunathan K.

Best regards, Michael.

Re: Feature freeze

[Jambunathan K]

Michael Albinus <michael.albinus@gmx.de> writes:

>> NOTE: In principle, I will not commit my changes to Org-mode repo.  The
>> rest can be negotiated.
>
> IIRC, you have vetoed applying any of your patches to the org-mode
> project.

There is no such veto.

I will not personally commit to Orgmode repo.  If the code gets merged
from Emacs repo back to Orgmode repo (by someone else) I have nothing
against it.

> Do you have changed your mind?

I have never changed my mind.

ODT exporter was created as a "donation" to Emacs.  It will remain so.
I still answer questions on the mailing list and accumulate patches in a
private repo.

Re: Feature freeze

[Michael Albinus]

Jambunathan K <kjambunathan@gmail.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>>> NOTE: In principle, I will not commit my changes to Org-mode repo.  The
>>> rest can be negotiated.
>>
>> IIRC, you have vetoed applying any of your patches to the org-mode
>> project.
>
> There is no such veto.
>
> I will not personally commit to Orgmode repo.  If the code gets merged
> from Emacs repo back to Orgmode repo (by someone else) I have nothing
> against it.
>
>> Do you have changed your mind?
>
> I have never changed my mind.

Then I must have misunderstood you:

"ox-odt.el/ox-freemind.el: Please remove it from Org core and don't
 distribute these files with Org."

<http://thread.gmane.org/gmane.emacs.orgmode/68127>

"I would like to remove ox-html.el from Org distribution."

<http://thread.gmane.org/gmane.emacs.orgmode/68128>

Best regards, Michael.

Re: Feature freeze

[Jambunathan K]

Michael Albinus <michael.albinus@gmx.de> writes:

> Then I must have misunderstood you:

Yes.  But you are not alone in that camp...

Re: Feature freeze

[Jambunathan K]

> "ox-odt.el/ox-freemind.el: Please remove it from Org core and don't
>  distribute these files with Org."
>
> <http://thread.gmane.org/gmane.emacs.orgmode/68127>
>
> "I would like to remove ox-html.el from Org distribution."
>
> <http://thread.gmane.org/gmane.emacs.orgmode/68128>

Irrelevant.  The code is part of Org-mode repo and it is part of Emacs.

Re: Feature freeze

[Michael Albinus]

Jambunathan K <kjambunathan@gmail.com> writes:

>> "ox-odt.el/ox-freemind.el: Please remove it from Org core and don't
>>  distribute these files with Org."
>>
>> <http://thread.gmane.org/gmane.emacs.orgmode/68127>
>>
>> "I would like to remove ox-html.el from Org distribution."
>>
>> <http://thread.gmane.org/gmane.emacs.orgmode/68128>
>
> Irrelevant.  The code is part of Org-mode repo and it is part of Emacs.

I remember you did a lot of people busy with this kind of requests. It
would be annoying to see such messages from you again, that's why I have
asked for your today's position.

Until you claim that those games are over now from your side, I would
recommend not to accept patches from you. But of course, I'm neither the
Emacs nor the Org-mode maintainer.

Best regards, Michael.

Re: Feature freeze

[Jambunathan K]

Michael Albinus <michael.albinus@gmx.de> writes:

> But of course, I'm neither the Emacs nor the Org-mode maintainer.

Yes.

Re: Feature freeze

[Juanma Barranquero]

On Tue, Dec 17, 2013 at 7:52 AM, Michael Albinus <michael.albinus@gmx.de> wrote:

> Until you claim that those games are over now from your side, I would
> recommend not to accept patches from you.

+1

Re: Feature freeze

[Jambunathan K]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Dec 17, 2013 at 7:52 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
>
>> Until you claim that those games are over now from your side, I would
>> recommend not to accept patches from you.
>
> +1

What sort of absurdity is this.  You take CA or Disclaimer, you put the
patch in Emacs and forget about it.

Hint: Jambunathan K is a GIGO machine.  Next time you talk to me, try
putting in something other than Garbage.

Re: Feature freeze

[Jay Belanger]

Jambunathan K <kjambunathan@gmail.com> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> On Tue, Dec 17, 2013 at 7:52 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
>>
>>> Until you claim that those games are over now from your side, I would
>>> recommend not to accept patches from you.
>>
>> +1
>
> What sort of absurdity is this.

The sort that is based on your previous behavior.

Re: Feature freeze

[Jambunathan K]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> The sort that is based on your previous behavior.

What was that previous behaviour based on?  Could you summarize in your
own words why I cancelled my assignment in first place?  Let me see how
much of a context you can provide.

Jambunathan K.

Re: Feature freeze

[Jay Belanger]

> What was that previous behaviour based on?

Your immaturity, I would assume.
Since you refuse to say that your games are over now, I take it you
leave open the possibility that they might continue.

> Could you summarize in your own words why I cancelled my assignment in
> first place?

It was the hissy fit and your stated desire to cause problems that
bothered people, which were not acceptable behavior under any
circumstances.

Re: Feature freeze

[Jambunathan K]

Jay

Don't take covers.  Answer my question or leave the room.

Jambunathan K.

Jay Belanger <jay.p.belanger@gmail.com> writes:

>> What was that previous behaviour based on?
>
> Your immaturity, I would assume.
> Since you refuse to say that your games are over now, I take it you
> leave open the possibility that they might continue.
>
>> Could you summarize in your own words why I cancelled my assignment in
>> first place?
>
> It was the hissy fit and your stated desire to cause problems that
> bothered people, which were not acceptable behavior under any
> circumstances.

Re: Feature freeze

[Jay Belanger]

Jambunathan K <kjambunathan@gmail.com> writes:

> Answer my question or leave the room.

The only worthwhile question that you asked was why people were agreeing
with the statement:

>>> Until you claim that those games are over now from your side, I would
>>> recommend not to accept patches from you.

I explained why people have a problem with your behavior, but you seem
to be ignoring that, and as before, you are behaving poorly.  You seem
intent on throwing another hissy fit, and the concern that you might
again purposely try to cause problems is real.
I'll let others worry about that; as for you:
  *plonk*

Re: Feature freeze

[Jambunathan K]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> I'll let others worry about that

"Better done than said"

Re: Feature freeze

[Glenn Morris]

People, please stop rising to the bait.

Re: Feature freeze

[Jambunathan K]

Glenn Morris <rgm@gnu.org> writes:

> People, please stop rising to the bait.

Knee-jerk reaction from one and all, save from some quarters.

Re: Feature freeze

[Stefan Monnier]

People, can we please move on to other things than bashing each other?
Thank you,


        Stefan

Re: Feature freeze

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Doesn’t it make more sense to have the feature freeze in the beginning of January? Many people will take some time off work around Christmas and will probably have a bit of extra time to work on things they want to include in Emacs 24.4. I was planning to integrate ruby-tools in ruby-mode, but I’m not sure I’ll be able to do it by the end of the week.

--  
Cheers,
Bozhidar


On Sunday, December 15, 2013 at 3:35 PM, Stefan Monnier wrote:

> If you want to install some new features in Emacs's trunk, do it now,
> because the trunk will be feature-frozen starting next week-end.
>  
>  
> Stefan "who wouldn't want Santa to come and install some
> undiscussed new feature while we sleep"
>  
>  



[-- Attachment #2: Type: text/html, Size: 1413 bytes --]

Feature freeze

[Stefan Monnier]

The trunk is now officially "frozen for new features".
IOW, feel free to keep installing bug-fixes, manual updates, and things
like that, but refrain from installing changes that introduce new
features.


        Stefan

Re: Feature freeze

[Dmitry Gutov]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The trunk is now officially "frozen for new features".
> IOW, feel free to keep installing bug-fixes, manual updates, and things
> like that, but refrain from installing changes that introduce new
> features.

Is it too late to install the "make electric-pair-mode smarter/more
useful" patch? It's been discussed for some time.

Re: Feature freeze

[Leo Liu]

On 2013-12-24 12:49 +0800, Dmitry Gutov wrote:
> Is it too late to install the "make electric-pair-mode smarter/more
> useful" patch? It's been discussed for some time.

I also wish it applied.

Leo

Re: Feature freeze

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

I'm also in favour of installing the electric-pair-mode patch. It will be a
big improvement for newcomers who are unlikely to use a third-party
alternative (at least not from day 1).


On 24 December 2013 08:08, Leo Liu <sdl.web@gmail.com> wrote:

> On 2013-12-24 12:49 +0800, Dmitry Gutov wrote:
> > Is it too late to install the "make electric-pair-mode smarter/more
> > useful" patch? It's been discussed for some time.
>
> I also wish it applied.
>
> Leo
>
>

[-- Attachment #2: Type: text/html, Size: 890 bytes --]

Re: Feature freeze

[Stefan Monnier]

>> The trunk is now officially "frozen for new features".
>> IOW, feel free to keep installing bug-fixes, manual updates, and things
>> like that, but refrain from installing changes that introduce new
>> features.
> Is it too late to install the "make electric-pair-mode smarter/more
> useful" patch? It's been discussed for some time.

No, this one is "already accepted", so it can be installed.


        Stfean

Re: Feature freeze

[João Távora]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> The trunk is now officially "frozen for new features".
>>> IOW, feel free to keep installing bug-fixes, manual updates, and things
>>> like that, but refrain from installing changes that introduce new
>>> features.
>> Is it too late to install the "make electric-pair-mode smarter/more
>> useful" patch? It's been discussed for some time.
>
> No, this one is "already accepted", so it can be installed.

I can do it myself if someone grants me write permission on Savannah.

BTW that could also help with the (unrelated) synch'ing of yasnippet's
upstream and GNU ELPA's.

João

Re: Feature freeze

[Stefan Monnier]

> I can do it myself if someone grants me write permission on Savannah.

Good idea.  Please request membership in the "emacs" group from your
savannah account,


        Stefan

Re: Feature freeze

[João Távora]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I can do it myself if someone grants me write permission on Savannah.
>
> Good idea.  Please request membership in the "emacs" group from your
> savannah account,

So I did and I commited the new features in revno: 115759. Have a look
and tell me how much I messed up :-) Not much I hope...

João

Re: Feature freeze

[João Távora]

>>> I can do it myself if someone grants me write permission on Savannah.
>> Good idea.  Please request membership in the "emacs" group from your
>> savannah account,
> So I did and I commited the new features in revno: 115759. Have a look
> and tell me how much I messed up :-) Not much I hope...

Two things:

* Somehow my patch didn't make it to emacs-diffs, but bzr log reports
  it.

  However, and curiously, I can see it parenting a revision pushed shortly
  thereafter, http://thread.gmane.org/gmane.emacs.diffs/123754.

  Did anything funny happen? I followed the instructions at
  http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc11.

* I noticed only now that the new tests for the "autowrapping"
  functionality in test/automated/electric-tests.el (i.e. the ones that
  use `region-active-p') are broken, but only when run from "make
  check", a target that I became aware of just now.

  Should these be skipped in that situation?

João

Re: Feature freeze

[Eli Zaretskii]

> From: joaotavora@gmail.com (João Távora)
> Date: Thu, 26 Dec 2013 23:46:01 +0000
> Cc: emacs-devel@gnu.org, João Távora <joaot@siscog.pt>,
> 	Dmitry Gutov <dgutov@yandex.ru>
> 
> * Somehow my patch didn't make it to emacs-diffs, but bzr log reports
>   it.

emacs-diffs is a moderated list, so messages by non-members get held
until approved by the moderator (who is a human, and needs to sleep
from time to time).

>   However, and curiously, I can see it parenting a revision pushed shortly
>   thereafter, http://thread.gmane.org/gmane.emacs.diffs/123754.
> 
>   Did anything funny happen? I followed the instructions at
>   http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc11.

Nothing funny, thank you.  Your commit was delivered to the repository
as expected, but the email message to emacs-diffs, generated by bzr on
your behalf, was held (until a few minutes ago).

Re: Feature freeze

[Dmitry Gutov]

On 27.12.2013 00:16, João Távora wrote:
> So I did and I commited the new features in revno: 115759. Have a look
> and tell me how much I messed up :-) Not much I hope...

Works quite well so far, thank you.

The commit not showing up in emacs-diffs is weird, though. I've seen my 
commits appear out of order, but they did show up eventually.

Re: Feature freeze

[David Engster]

Stefan Monnier writes:
> The trunk is now officially "frozen for new features".
> IOW, feel free to keep installing bug-fixes, manual updates, and things
> like that, but refrain from installing changes that introduce new
> features.

I would very much like to get the better help support for EIEIO methods
and classes in the next release. We discussed it here in February:

http://thread.gmane.org/gmane.emacs.devel/156807

I got sidetracked at that time, but I'm currently working it. The
essential functionality won't change, though: the main work is done in
eieio.el and eieio-opt.el. The only things that get's added to
help-fns.el is the new `help-fns-describe-function-functions' hook.

Would it be OK to apply it in the coming days?

Also, I'd like to do another sync from CEDET upstream, but AFAICS that's
only bugfixes.

-David

Re: Feature freeze

[Stefan Monnier]

> I got sidetracked at that time, but I'm currently working it. The
> essential functionality won't change, though: the main work is done in
> eieio.el and eieio-opt.el. The only things that get's added to
> help-fns.el is the new `help-fns-describe-function-functions' hook.
> Would it be OK to apply it in the coming days?

I remember discussions around that, yes.  Send us the patch and we'll
see if that can be installed.

> Also, I'd like to do another sync from CEDET upstream, but AFAICS that's
> only bugfixes.

If it's only bug-fixes then it's fine, yes.


        Stefan

Re: Feature freeze

[David Engster]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Stefan Monnier writes:
>> I got sidetracked at that time, but I'm currently working it. The
>> essential functionality won't change, though: the main work is done in
>> eieio.el and eieio-opt.el. The only things that get's added to
>> help-fns.el is the new `help-fns-describe-function-functions' hook.
>> Would it be OK to apply it in the coming days?
>
> I remember discussions around that, yes.  Send us the patch and we'll
> see if that can be installed.

Much to my surprise I didn't get much done over the holidays, but
anyway, here it is.

The patch looks large, but as you can see, most of the stuff is just for
displaying the class/constructor/slot descriptions. The real core of the
patch is, as I've written above, the new hook in help-fns.el.

Is it OK to install, or will it have to wait?

-David


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: eieio-help-fns-patch.diff --]
[-- Type: text/x-diff, Size: 16935 bytes --]

=== modified file 'lisp/emacs-lisp/eieio-opt.el'
--- lisp/emacs-lisp/eieio-opt.el	2014-01-01 07:43:34 +0000
+++ lisp/emacs-lisp/eieio-opt.el	2014-01-06 21:32:16 +0000
@@ -77,101 +77,76 @@
 ;;;###autoload(defalias 'describe-class 'eieio-describe-class)
 
 ;;;###autoload
-(defun eieio-describe-class (class &optional headerfcn)
+(defun eieio-describe-class (class)
   "Describe a CLASS defined by a string or symbol.
-If CLASS is actually an object, then also display current values of that object.
-Optional HEADERFCN should be called to insert a few bits of info first."
-  (interactive (list (eieio-read-class "Class: ")))
-  (with-output-to-temp-buffer (help-buffer) ;"*Help*"
-    (help-setup-xref (list #'eieio-describe-class class headerfcn)
-		     (called-interactively-p 'interactive))
-
-    (when headerfcn (funcall headerfcn))
-    (prin1 class)
-    (princ " is a")
-    (if (class-option class :abstract)
-	(princ "n abstract"))
-    (princ " class")
-    ;; Print file location
-    (when (get class 'class-location)
-      (princ " in `")
-      (princ (file-name-nondirectory (get class 'class-location)))
-      (princ "'"))
-    (terpri)
-    ;; Inheritance tree information
-    (let ((pl (eieio-class-parents class)))
-      (when pl
-	(princ " Inherits from ")
-	(while pl
-	  (princ "`") (prin1 (car pl)) (princ "'")
-	  (setq pl (cdr pl))
-	  (if pl (princ ", ")))
-	(terpri)))
-    (let ((ch (eieio-class-children class)))
-      (when ch
-	(princ " Children ")
-	(while ch
-	  (princ "`") (prin1 (car ch)) (princ "'")
-	  (setq ch (cdr ch))
-	  (if ch (princ ", ")))
-	(terpri)))
-    (terpri)
-    ;; System documentation
-    (let ((doc (documentation-property class 'variable-documentation)))
-      (when doc
-	(princ "Documentation:")
-	(terpri)
-	(princ doc)
-	(terpri)
-	(terpri)))
-    ;; Describe all the slots in this class
-    (eieio-describe-class-slots class)
-    ;; Describe all the methods specific to this class.
-    (let ((methods (eieio-all-generic-functions class))
-	  (doc nil))
-      (if (not methods) nil
-	(princ "Specialized Methods:")
-	(terpri)
-	(terpri)
-	(while methods
-	  (setq doc (eieio-method-documentation (car methods) class))
-	  (princ "`")
-	  (prin1 (car methods))
-	  (princ "'")
-	  (if (not doc)
-	      (princ "  Undocumented")
-	    (if (car doc)
-		(progn
-		  (princ "  :STATIC ")
-		  (prin1 (car (car doc)))
-		  (terpri)
-		  (princ (cdr (car doc)))))
-	    (setq doc (cdr doc))
-	    (if (car doc)
-		(progn
-		  (princ "  :BEFORE ")
-		  (prin1 (car (car doc)))
-		  (terpri)
-		  (princ (cdr (car doc)))))
-	    (setq doc (cdr doc))
-	    (if (car doc)
-		(progn
-		  (princ "  :PRIMARY ")
-		  (prin1 (car (car doc)))
-		  (terpri)
-		  (princ (cdr (car doc)))))
-	    (setq doc (cdr doc))
-	    (if (car doc)
-		(progn
-		  (princ "  :AFTER ")
-		  (prin1 (car (car doc)))
-		  (terpri)
-		  (princ (cdr (car doc)))))
-	    (terpri)
-	    (terpri))
-	  (setq methods (cdr methods))))))
-  (with-current-buffer (help-buffer)
-    (buffer-string)))
+If CLASS is actually an object, then also display current values of that object."
+  ;; Header line
+  (prin1 class)
+  (insert " is a"
+	  (if (class-option class :abstract)
+	      "n abstract"
+	    "")
+	  " class")
+  (let ((location (get class 'class-location)))
+    (when location
+      (insert " in `")
+      (help-insert-xref-button
+       (file-name-nondirectory location)
+       'eieio-class-def class location)
+      (insert "'")))
+  (insert ".\n")
+  ;; Parents
+  (let ((pl (eieio-class-parents class))
+	cur)
+    (when pl
+      (insert " Inherits from ")
+      (while (setq cur (pop pl))
+	(insert "`")
+	(help-insert-xref-button (symbol-name cur)
+				 'help-function cur)
+	(insert (if pl "', " "'")))
+      (insert ".\n")))
+  ;; Children
+  (let ((ch (eieio-class-children class))
+	cur)
+    (when ch
+      (insert " Children ")
+      (while (setq cur (pop ch))
+	(insert "`")
+	(help-insert-xref-button (symbol-name cur)
+				 'help-function cur)
+	(insert (if ch "', " "'")))
+      (insert ".\n")))
+  ;; System documentation
+  (let ((doc (documentation-property class 'variable-documentation)))
+    (when doc
+      (insert "\n" doc "\n\n")))
+  ;; Describe all the slots in this class
+  (eieio-describe-class-slots class)
+  ;; Describe all the methods specific to this class.
+  (let ((methods (eieio-all-generic-functions class))
+	(type [":STATIC" ":BEFORE" ":PRIMARY" ":AFTER"])
+	counter doc argshl dochl)
+    (when methods
+      (insert (propertize "Specialized Methods:\n\n" 'face 'bold))
+      (while methods
+	(setq doc (eieio-method-documentation (car methods) class))
+	(insert "`")
+	(help-insert-xref-button (symbol-name (car methods))
+				 'help-function (car methods))
+	(insert "'")
+	(if (not doc)
+	    (insert "  Undocumented")
+	  (setq counter 0)
+	  (dolist (cur doc)
+	    (when cur
+	      (insert " " (aref type counter) " "
+		      (prin1-to-string (car cur) (current-buffer))
+		      "\n"
+		      (cdr cur)))
+	    (setq counter (1+ counter))))
+	(insert "\n\n")
+	(setq methods (cdr methods))))))
 
 (defun eieio-describe-class-slots (class)
   "Describe the slots in CLASS.
@@ -185,28 +160,27 @@
 	 (i      0)
 	 (prot   (eieio--class-protection cv))
 	 )
-    (princ "Instance Allocated Slots:")
-    (terpri)
-    (terpri)
+    (insert (propertize "Instance Allocated Slots:\n\n"
+			'face 'bold))
     (while names
-      (if (car prot) (princ "Private "))
-      (princ "Slot: ")
-      (prin1 (car names))
-      (when (not (eq (aref types i) t))
-	(princ "    type = ")
-	(prin1 (aref types i)))
-      (unless (eq (car deflt) eieio-unbound)
-	(princ "    default = ")
-	(prin1 (car deflt)))
-      (when (car publp)
-	(princ "    printer = ")
-	(prin1 (car publp)))
-      (when (car docs)
-	(terpri)
-	(princ "  ")
-	(princ (car docs))
-	(terpri))
-      (terpri)
+      (insert
+       (concat
+	(when (car prot)
+	  (propertize "Private " 'face 'bold))
+	(propertize "Slot: " 'face 'bold)
+	(prin1-to-string (car names))
+	(unless (eq (aref types i) t)
+	  (concat "    type = "
+		  (prin1-to-string (aref types i))))
+	(unless (eq (car deflt) eieio-unbound)
+	  (concat "    default = "
+		  (prin1-to-string (car deflt))))
+	(when (car publp)
+	  (concat "    printer = "
+		  (prin1-to-string (car publp))))
+	(when (car docs)
+	  (concat "\n  " (car docs) "\n"))
+	"\n"))
       (setq names (cdr names)
 	    docs (cdr docs)
 	    deflt (cdr deflt)
@@ -219,61 +193,30 @@
 	  i     0
 	  prot  (eieio--class-class-allocation-protection cv))
     (when names
-	(terpri)
-	(princ "Class Allocated Slots:"))
-	(terpri)
-	(terpri)
+      (insert (propertize "\nClass Allocated Slots:\n\n" 'face 'bold)))
     (while names
-      (when (car prot)
-	(princ "Private "))
-      (princ "Slot: ")
-      (prin1 (car names))
-      (unless (eq (aref types i) t)
-	(princ "    type = ")
-	(prin1 (aref types i)))
-      (condition-case nil
-	  (let ((value (eieio-oref class (car names))))
-	    (princ "   value = ")
-	    (prin1 value))
+      (insert
+       (concat
+	(when (car prot)
+	  "Private ")
+	"Slot: "
+	(prin1-to-string (car names))
+	(unless (eq (aref types i) t)
+	  (concat "    type = "
+		  (prin1-to-string (aref types i))))
+	(condition-case nil
+	    (let ((value (eieio-oref class (car names))))
+	      (concat "   value = "
+		      (prin1-to-string value)))
 	  (error nil))
-      (when (car docs)
-	(terpri)
-	(princ "  ")
-	(princ (car docs))
-	(terpri))
-      (terpri)
+	(when (car docs)
+	  (concat "\n\n " (car docs) "\n"))
+	"\n"))
       (setq names (cdr names)
 	    docs (cdr docs)
 	    prot (cdr prot)
 	    i (1+ i)))))
 
-;;;###autoload
-(defun eieio-describe-constructor (fcn)
-  "Describe the constructor function FCN.
-Uses `eieio-describe-class' to describe the class being constructed."
-  (interactive
-   ;; Use eieio-read-class since all constructors have the same name as
-   ;; the class they create.
-   (list (eieio-read-class "Class: ")))
-  (eieio-describe-class
-   fcn (lambda ()
-	 ;; Describe the constructor part.
-	 (prin1 fcn)
-	 (princ " is an object constructor function")
-	 ;; Print file location
-	 (when (get fcn 'class-location)
-	   (princ " in `")
-	   (princ (file-name-nondirectory (get fcn 'class-location)))
-	   (princ "'"))
-	 (terpri)
-	 (princ "Creates an object of class ")
-	 (prin1 fcn)
-	 (princ ".")
-	 (terpri)
-	 (terpri)
-	 ))
-  )
-
 (defun eieio-build-class-list (class)
   "Return a list of all classes that inherit from CLASS."
   (if (class-p class)
@@ -330,87 +273,99 @@
 ;;;###autoload(defalias 'describe-generic 'eieio-describe-generic)
 (defalias 'eieio-describe-method 'eieio-describe-generic)
 
-;;;###autoload
-(defun eieio-describe-generic (generic)
-  "Describe the generic function GENERIC.
-Also extracts information about all methods specific to this generic."
-  (interactive (list (eieio-read-generic "Generic Method: ")))
-  (eieio--check-type generic-p generic)
-  (with-output-to-temp-buffer (help-buffer) ; "*Help*"
-    (help-setup-xref (list #'eieio-describe-generic generic)
-		     (called-interactively-p 'interactive))
-
-    (prin1 generic)
-    (princ " is a generic function")
-    (when (generic-primary-only-p generic)
-      (princ " with only ")
-      (when (generic-primary-only-one-p generic)
-	(princ "one "))
-      (princ "primary method")
-      (when (not (generic-primary-only-one-p generic))
-	(princ "s"))
-      )
-    (princ ".")
-    (terpri)
-    (terpri)
-    (let ((d (documentation generic)))
-      (if (not d)
-	  (princ "The generic is not documented.\n")
-	(princ "Documentation:")
-	(terpri)
-	(princ d)
-	(terpri)
-	(terpri)))
-    (princ "Implementations:")
-    (terpri)
-    (terpri)
-    (let ((i 4)
-	  (prefix [ ":STATIC" ":BEFORE" ":PRIMARY" ":AFTER" ] ))
-      ;; Loop over fanciful generics
-      (while (< i 7)
-	(let ((gm (aref (get generic 'eieio-method-tree) i)))
-	  (when gm
-	    (princ "Generic ")
-	    (princ (aref prefix (- i 3)))
-	    (terpri)
-	    (princ (or (nth 2 gm) "Undocumented"))
-	    (terpri)
-	    (terpri)))
-	(setq i (1+ i)))
-      (setq i 0)
-      ;; Loop over defined class-specific methods
-      (while (< i 4)
-	(let ((gm (reverse (aref (get generic 'eieio-method-tree) i)))
-	      location)
-	  (while gm
-	    (princ "`")
-	    (prin1 (car (car gm)))
-	    (princ "'")
-	    ;; prefix type
-	    (princ " ")
-	    (princ (aref prefix i))
-	    (princ " ")
-	    ;; argument list
-	    (let* ((func (cdr (car gm)))
-		   (arglst (eieio-lambda-arglist func)))
-	      (prin1 arglst))
-	    (terpri)
-	    ;; 3 because of cdr
-	    (princ (or (documentation (cdr (car gm)))
-		       "Undocumented"))
-	    ;; Print file location if available
-	    (when (and (setq location (get generic 'method-locations))
-		       (setq location (assoc (caar gm) location)))
-	      (setq location (cadr location))
-	      (princ "\n\nDefined in `")
-	      (princ (file-name-nondirectory location))
-	      (princ "'\n"))
-	    (setq gm (cdr gm))
-	    (terpri)
-	    (terpri)))
-	(setq i (1+ i)))))
-  (with-current-buffer (help-buffer)
-    (buffer-string)))
+(define-button-type 'eieio-method-def
+  :supertype 'help-xref
+  'help-function (lambda (class method file)
+		   (eieio-help-find-method-definition class method file))
+  'help-echo (purecopy "mouse-2, RET: find method's definition"))
+
+(define-button-type 'eieio-class-def
+  :supertype 'help-xref
+  'help-function (lambda (class file)
+		   (eieio-help-find-class-definition class file))
+  'help-echo (purecopy "mouse-2, RET: find class definition"))
+
+;;;###autoload
+(defun eieio-help-constructor (ctr)
+  "Describe CTR if it is a class constructor."
+  (when (class-p ctr)
+    (let ((location (get ctr 'class-location)))
+      (goto-char (point-min))
+      (delete-region (point) (point-at-eol))
+      (prin1 ctr)
+      (insert " is an object constructor function in `")
+      (help-insert-xref-button
+       (file-name-nondirectory location)
+       'eieio-class-def ctr location)
+      (insert "'.\nCreates an object of class " (symbol-name ctr) ".")
+      (goto-char (point-max))
+      (save-excursion
+	(insert (propertize "\n\nClass description:\n" 'face 'bold))
+	(eieio-describe-class ctr))
+      )))
+
+
+;;;###autoload
+(defun eieio-help-generic (generic)
+  "Describe GENERIC if it is a generic function."
+  (when (generic-p generic)
+    (save-excursion
+      (goto-char (point-min))
+      (when (re-search-forward " in `.+'.$" nil t)
+	(replace-match ".")))
+    (save-excursion
+      (insert "\n\nThis is a generic function"
+	      (cond
+	       ((and (generic-primary-only-p generic)
+		     (generic-primary-only-one-p generic))
+		" with only one primary method")
+	       ((generic-primary-only-p generic)
+		" with only primary methods")
+	       (t ""))
+	      ".\n\n")
+      (insert (propertize "Implementations:\n\n" 'face 'bold))
+      (let ((i 4)
+	    (prefix [ ":STATIC" ":BEFORE" ":PRIMARY" ":AFTER" ] ))
+	;; Loop over fanciful generics
+	(while (< i 7)
+	  (let ((gm (aref (get generic 'eieio-method-tree) i)))
+	    (when gm
+	      (insert "Generic "
+		      (aref prefix (- i 3))
+		      "\n"
+		      (or (nth 2 gm) "Undocumented")
+		      "\n\n")))
+	  (setq i (1+ i)))
+	(setq i 0)
+	;; Loop over defined class-specific methods
+	(while (< i 4)
+	  (let* ((gm (reverse (aref (get generic 'eieio-method-tree) i)))
+		 cname location)
+	    (while gm
+	      (setq cname (caar gm))
+	      (insert "`")
+	      (help-insert-xref-button (symbol-name cname)
+				       'help-variable cname)
+	      (insert "' " (aref prefix i) " ")
+	      ;; argument list
+	      (let* ((func (cdr (car gm)))
+		     (arglst (eieio-lambda-arglist func)))
+		(prin1 arglst (current-buffer)))
+	      (insert "\n"
+		      (or (documentation (cdr (car gm)))
+			  "Undocumented"))
+	      ;; Print file location if available
+	      (when (and (setq location (get generic 'method-locations))
+			 (setq location (assoc cname location)))
+		(setq location (cadr location))
+		(insert "\n\nDefined in `")
+		(help-insert-xref-button
+		 (file-name-nondirectory location)
+		 'eieio-method-def cname generic location)
+		(insert "'\n"))
+	      (setq gm (cdr gm))
+	      (insert "\n")))
+	  (setq i (1+ i)))))))
 
 (defun eieio-lambda-arglist (func)
   "Return the argument list of FUNC, a function body."
@@ -584,21 +539,13 @@
 
 ;;; HELP AUGMENTATION
 ;;
-(define-button-type 'eieio-method-def
-  :supertype 'help-xref
-  'help-function (lambda (class method file)
-		   (eieio-help-find-method-definition class method file))
-  'help-echo (purecopy "mouse-2, RET: find method's definition"))
-
-(define-button-type 'eieio-class-def
-  :supertype 'help-xref
-  'help-function (lambda (class file)
-		   (eieio-help-find-class-definition class file))
-  'help-echo (purecopy "mouse-2, RET: find class definition"))
-
 (defun eieio-help-find-method-definition (class method file)
   (let ((filename (find-library-name file))
 	location buf)
+    (when (symbolp class)
+      (setq class (symbol-name class)))
+    (when (symbolp method)
+      (setq method (symbol-name method)))
     (when (null filename)
       (error "Cannot find library %s" file))
     (setq buf (find-file-noselect filename))
@@ -622,6 +569,8 @@
       (beginning-of-line))))
 
 (defun eieio-help-find-class-definition (class file)
+  (when (symbolp class)
+    (setq class (symbol-name class)))
   (let ((filename (find-library-name file))
 	location buf)
     (when (null filename)

=== modified file 'lisp/emacs-lisp/eieio.el'
--- lisp/emacs-lisp/eieio.el	2014-01-01 07:43:34 +0000
+++ lisp/emacs-lisp/eieio.el	2014-01-04 09:04:08 +0000
@@ -865,6 +865,10 @@
 of `eq'."
   (error "EIEIO: `change-class' is unimplemented"))
 
+;; Hook ourselves into help system for describing classes and methods.
+(add-hook 'help-fns-describe-function-functions 'eieio-help-generic)
+(add-hook 'help-fns-describe-function-functions 'eieio-help-constructor)
+
 ;;; Interfacing with edebug
 ;;
 (defun eieio-edebug-prin1-to-string (object &optional noescape)

=== modified file 'lisp/help-fns.el'
--- lisp/help-fns.el	2014-01-01 07:43:34 +0000
+++ lisp/help-fns.el	2014-01-04 09:04:08 +0000
@@ -32,6 +32,12 @@
 
 ;;; Code:
 
+(defvar help-fns-describe-function-functions nil
+  "List of functions to run in help buffer in `describe-function'.
+Those functions will be run after the header line and argument
+list was inserted, and before the documentation will be inserted.
+The functions will receive the function name as argument.")
+
 ;; Functions
 
 ;;;###autoload
@@ -653,7 +659,7 @@
           (help-fns--compiler-macro function)
           (help-fns--parent-mode function)
           (help-fns--obsolete function)
-
+	  (run-hook-with-args 'help-fns-describe-function-functions function)
           (insert "\n"
                   (or doc "Not documented.")))))))
 

Re: Feature freeze

[Stefan Monnier]

> Is it OK to install, or will it have to wait?

Looks OK.  Please install, tho see nitpicks below.

> +  ;; Describe all the slots in this class

Please punctuate the comments (IIUC you didn't actually change this
comment, but while you're there, you might as well do it ;-).

> +(defvar help-fns-describe-function-functions nil
> +  "List of functions to run in help buffer in `describe-function'.
> +Those functions will be run after the header line and argument
> +list was inserted, and before the documentation will be inserted.
> +The functions will receive the function name as argument.")
> +
>  ;; Functions
> 
>  ;;;###autoload
> @@ -653,7 +659,7 @@
>            (help-fns--compiler-macro function)
>            (help-fns--parent-mode function)
>            (help-fns--obsolete function)
> -
> +	  (run-hook-with-args 'help-fns-describe-function-functions function)

Looks good, but please move help-fns--compiler-macro,
help-fns--parent-mode, help-fns--obsolete to
help-fns-describe-function-functions while you're there.


        Stefan

Re: Feature freeze

[David Engster]

Stefan Monnier writes:
>>  ;;;###autoload
>> @@ -653,7 +659,7 @@
>>            (help-fns--compiler-macro function)
>>            (help-fns--parent-mode function)
>>            (help-fns--obsolete function)
>> -
>> +	  (run-hook-with-args 'help-fns-describe-function-functions function)
>
> Looks good, but please move help-fns--compiler-macro,
> help-fns--parent-mode, help-fns--obsolete to
> help-fns-describe-function-functions while you're there.

Yes, will do.

One more question which I forgot to ask: I did rename
`eieio-describe-constructor' and `eieio-describe-generic' to
`eieio-help-constructor' and `eieio-help-generic', since they are not
interactive anymore but augment an existing help buffer. Those two
however had aliases `describe-constructor' and `describe-generic', which
I'd like to remove. Would that be OK? I don't think anyone was using
those, and calling the normal `describe-function' on a constructor or
generic will now give the same information.

If you'd like to keep them, I'd simply re-implement them as small
wrappers for `describe-function'.

-David

Re: Feature freeze

[Stefan Monnier]

> interactive anymore but augment an existing help buffer. Those two
> however had aliases `describe-constructor' and `describe-generic', which
> I'd like to remove. Would that be OK?

Yes, thanks,


        Stefan

Re: Feature freeze

[David Engster]

Stefan Monnier writes:
>> interactive anymore but augment an existing help buffer. Those two
>> however had aliases `describe-constructor' and `describe-generic', which
>> I'd like to remove. Would that be OK?
>
> Yes, thanks,

Pushed. I will update NEWS tomorrow.

What I didn't find out is how to update the extracted autoloads at the
end of lisp/emacs-lisp/eieio.el, so those are still wrong. 'make
autoloads' doesn't do the trick. Any hints?

-David

Re: Feature freeze

[Glenn Morris]

David Engster wrote:

> What I didn't find out is how to update the extracted autoloads at the
> end of lisp/emacs-lisp/eieio.el, so those are still wrong. 'make
> autoloads' doesn't do the trick. Any hints?

There's something weird there.
How did those autoloads get into eieio.el in the first place, when it is
not the value of any other file's generated-autoload-file setting?
(They are also in loaddefs.el, which is where `make autoloads' will
update them.)

Maybe there was such a setting at some point in the past, but it was
removed? Or were those autoloads added to eieio.el by hand?

I suggest you fix it up by hand.

Re: Feature freeze

[Glenn Morris]

Glenn Morris wrote:

> Maybe there was such a setting at some point in the past, but it was
> removed?

Yes: I intentionally added it in r103332.
It was removed it r110325 "Update CEDET from upstream".
I guess that was unintentional.

I suggest you check that revision and make any necessary fixes.


In a way, this is an autoloads bug:
If a file foo.el used to contain a file-local generated-autoload-file: bar.el
setting, but then it gets removed, the autoloads will not be removed
from bar.el.

Re: Feature freeze

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 08 Jan 2014 17:37:31 -0500
> 
> In a way, this is an autoloads bug:
> If a file foo.el used to contain a file-local generated-autoload-file: bar.el
> setting, but then it gets removed, the autoloads will not be removed
> from bar.el.

Perhaps we should fix this, either in the Makefile or maybe via some
file-local variables wizardry.

Re: Feature freeze

[David Engster]

Glenn Morris writes:
> Glenn Morris wrote:
>
>> Maybe there was such a setting at some point in the past, but it was
>> removed?
>
> Yes: I intentionally added it in r103332.
> It was removed it r110325 "Update CEDET from upstream".
> I guess that was unintentional.

Yes, that was my fault. Thanks for looking into this.

> I suggest you check that revision and make any necessary fixes.

But I guess there must be some reason why you used 'eieio.el' as
generated autoload file instead of using loaddefs.el? Is it OK to just
remove the autoloads from eieio.el and fix AUTOGEN_VCS in Makefile.in,
or should I restore it to the way it was?

-David

Re: Feature freeze

[Glenn Morris]

David Engster wrote:

> But I guess there must be some reason why you used 'eieio.el' as
> generated autoload file instead of using loaddefs.el? 

I did that because those autoloads were already in eieio.el, but
hand-written rather than auto-generated.

You know better than I where those autoloads need to be.
Do they only make sense after eieio is loaded, or are they external
access points.

Re: Feature freeze

[David Engster]

Glenn Morris writes:
> David Engster wrote:
>> But I guess there must be some reason why you used 'eieio.el' as
>> generated autoload file instead of using loaddefs.el? 
>
> I did that because those autoloads were already in eieio.el, but
> hand-written rather than auto-generated.

Ah yes, I now dimly remember writing those...

> You know better than I where those autoloads need to be.
> Do they only make sense after eieio is loaded, or are they external
> access points.

They really only make sense when EIEIO is already loaded, so I restored
the old behavior.

-David

Re: Feature freeze

[Nix]

On 6 Jan 2014, David Engster outgrape:
> Much to my surprise I didn't get much done over the holidays, but
> anyway, here it is.

As an eieio user long frustrated by the opacity caused by its poor help
integration:

Best patch so far this year! Thank you thank you!

(not that that's really saying *that* much, what with freeze and New
Year and all. But still.)

Re: Feature freeze

[Stefan Monnier]

> The trunk is now officially "frozen for new features".

BTW, the plan is to keep it frozen for a month or so, after which we'll
make a release branch and open up the trunk for changes again.


        Stefan

Re: Feature freeze

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The trunk is now officially "frozen for new features".
> IOW, feel free to keep installing bug-fixes, manual updates, and things
> like that, but refrain from installing changes that introduce new
> features.

Do we have a list of bug numbers, which shall be fixed before the
release? Preferred as (user) tags in debbugs or alike, that the list can
be kept up-to-date.

>         Stefan

Best regards, Michael.

Re: Feature freeze

[Stefan Monnier]

>> The trunk is now officially "frozen for new features".
>> IOW, feel free to keep installing bug-fixes, manual updates, and things
>> like that, but refrain from installing changes that introduce new
>> features.
> Do we have a list of bug numbers, which shall be fixed before the
> release? Preferred as (user) tags in debbugs or alike, that the list can
> be kept up-to-date.

No, but I encourage everyone to tag as "important" any bug that they
think should be fixed.  Of course, that should be someone else's bug.
If you think your own bug-report is important, send me an email.


        Stefan

Re: Feature freeze

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> No, but I encourage everyone to tag as "important" any bug that they
> think should be fixed.  Of course, that should be someone else's bug.
> If you think your own bug-report is important, send me an email.

That will work fine if the bug is related to Emacs only. When it is
assigned to several packages in parallel, like Emacs and Gnus, it is not
obvious whether it must be fixed in the next Emacs release or the next
Gnus release.

But let's start with this. Conflicts in intended release versionss the
bug shall be fixed could be solved when they happen. With the debbugs
package from GNU ELPA, we get the list of bugs:

(debbugs-gnu '("serious" "important") '("emacs") nil t)

Admittedly, the last one has been submitted by me. Maybe somebody else
could check, whether the severity is proper. It is a security flaw, so I
believe it shall be fixed soon.

If one prefers the bug list as TODO items of org-mode, one could apply

(debbugs-org '("serious" "important") '("emacs") nil)

>         Stefan

Best regards, Michael.

Feature freeze

[Stefan Monnier]

Time is up!

I think it's about time we freeze the features for Emacs-25.  There are
a few things I hope can still make it into this new release, (such as
the xwidget branch (long overdue) and the dynload/modules, for example),
so the exact schedule and details are still up for discussion.

But I'll leave these decisions to someone else, because I also take this
opportunity to step down as head maintainer.

It's time for me to move on, and it's time for new blood to take
the lead.  I'm not about to disappear, but I won't be reading
emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
something from me, put me explicitly in the Cc.

Thank you all for bearing with me as head maintainer, it's been a great
ride, I hope you enjoyed it as much as I did.


        Stefan

Re: Feature freeze

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

Hey Stefan,

Wishing you success with your next venture too. It was great to have
discussions and learn from you on this list.

You will be missed. Looking forward to what new ideas are being put into
the pipeline with the help and support of the next head maintainer.

Kaushal
On Sep 21, 2015 4:43 PM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:

> Time is up!
>
> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.
>
> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.
>
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
>
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 1590 bytes --]

Re: Feature freeze

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

I regularly describe to fellow programmers how vibrant the emacs project
has become.  You deserve the lion's share of the credit.  May we be blessed
with a new head maintainer as competent, creative, courteous and visionary
as you have been

Best of luck,

/john

[-- Attachment #2: Type: text/html, Size: 374 bytes --]

Re: Feature freeze

[Rasmus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Time is up!

Cool! 

> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.
>
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
>
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Damn, I hate Mondays...  Well, best of luck!  And thanks a lot for all of
your contributions thus far and also future contributions.

Rasmus

-- 
Dobbelt-A

Re: Feature freeze

[Xue Fuqiao]

Hi Stefan,

Thanks for your great 7 years of being an elite technical leader, and
pulling Emacs forward for 10+ years!  Especially thanks for your
contributions to vc-svn, Emacs server, PCL-CVS (just like Magit for
Git!), smerge-mode and diff-mode, mpc, smie, pcase, cl-lib (CL at
runtime!), gv, nadvice (which is really easy to use) and countless
contributions to GNU ELPA, *.texi and doc strings, Unicode support,
CEDET, plus many other places all over Emacs.

Personally, I'd like to express my gratitude for your guidance and
patience, which makes me more proficient in Emacs development.  Wish you
success with your next venture!

Re: Feature freeze

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 21 Sep 2015 15:39:55 -0400
> 
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
> 
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

We did enjoy that ride, and you _will_ be missed.  Thank you for those
wonderful years, and I hope your "infrequent" appearances here will be
more frequent.

Re: Feature freeze

[martin rudalics]

 > I also take this opportunity to step down as head maintainer.

I was afraid this would happen.

Thanks for bearing with us, martin

Re: Feature freeze

[Zack Piper]

On Mon, 21 Sep 2015 21:39:55 +0200,
Stefan Monnier wrote:
> 
> Time is up!
> 
> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.

I'm looking forward to these features.

> 
> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.

Thank you for your hard work, and good luck in your future endeavors.

> 
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
> 
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.
> 
> 
>         Stefan
> 

Re: Feature freeze

[Aurélien Aptel]

On Mon, Sep 21, 2015 at 9:39 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.

Yeah I would also like to have the modules in too! I'll update the
relevant thread.

> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Aww :( You will be missed.
You always took time to explain stuff when I asked dumb questions,
really appreciated that :D

Re: Feature freeze

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 144 bytes --]

Thanks for all your work and time, Stefan. You've done a brilliant job. And
thanks for dragging me onto this mess as well.

Best of luck,
Artur

[-- Attachment #2: Type: text/html, Size: 187 bytes --]

Re: Feature freeze

[Tassilo Horn]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Thanks for all your work and time, Stefan.  You've done a brilliant
> job.

I second this.  You've been a fantastic maintainer!

> And thanks for dragging me onto this mess as well.

Oh, yes.  Thanks also for dragging Artur into this mess! :-)

Bye,
Tassilo

Re: Feature freeze

[Eric Abrahamsen]

Aurélien Aptel <aurelien.aptel+emacs@gmail.com> writes:

> On Mon, Sep 21, 2015 at 9:39 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>> I think it's about time we freeze the features for Emacs-25.  There are
>> a few things I hope can still make it into this new release, (such as
>> the xwidget branch (long overdue) and the dynload/modules, for example),
>> so the exact schedule and details are still up for discussion.
>
> Yeah I would also like to have the modules in too! I'll update the
> relevant thread.
>
>> Thank you all for bearing with me as head maintainer, it's been a great
>> ride, I hope you enjoyed it as much as I did.
>
> Aww :( You will be missed.
> You always took time to explain stuff when I asked dumb questions,
> really appreciated that :D

Amen to this. I got a lot of assistance and encouragement, and that made
the process of contributing to (and using) Emacs really pleasurable.
Thanks, and stick around.

Re: Feature freeze

[Alan Mackenzie]

Hello, Stefan.

On Mon, Sep 21, 2015 at 03:39:55PM -0400, Stefan Monnier wrote:
> Time is up!

> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.

> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.

> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.

> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Yes, all good things come to an end.  Thanks for all the hard work over
the years (and decades), and wishing you a more relaxed and less
stressful future.

We're going to miss you!

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Feature freeze

[Oleh Krehel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

You were a great maintainer, thanks for all your work.
And best of luck in your new projects.

    Oleh

Re: Feature freeze

[Dmitry Gutov]

Hello Stefan,

On 09/21/2015 10:39 PM, Stefan Monnier wrote:

> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Thank you very much for your work, patience and fruitful discussions 
over the years (as well as the less fruitful ones, all of those are 
surely my fault).

It's hard for me to imagine Emacs development without your guiding hand, 
but I hope we'll manage somehow.

Best of luck in all your endeavors. Come back to govern anytime. ;)

Re: Feature freeze

[Paul Eggert]

On 09/21/2015 12:39 PM, Stefan Monnier wrote:
> Thank you all for bearing with me as head maintainer

It was more the other way round: you were bearing us, and doing it so 
well that we all got a little spoiled.  Thanks for the ride, and please 
don't be a stranger.

Re: Feature freeze

[Bastien]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 09/21/2015 12:39 PM, Stefan Monnier wrote:
>> Thank you all for bearing with me as head maintainer
>
> It was more the other way round: you were bearing us, and doing it so
> well that we all got a little spoiled.*

Exactly my feelings.  *Thanks* Stefan!

-- 
 Bastien

Re: Feature freeze

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

Hi Stefan,

> I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.

I'm wondering how it will work from there.  Will you look for a new head
maintainer, or is this task up to somebody else?  Or maybe we already
have a new head maintainer and I missed it?

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Feature freeze

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We need a new Emacs maintainer (better, two).  I have asked Stefan to
help recruit the new maintainers and work with them in a transition.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Feature freeze

[Leo Liu]

On 2015-09-22 03:39 +0800, Stefan Monnier wrote:
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Stefan, thanks for the generous contribution to emacs which has become
my favourite development environment. Thanks also for teaching me many
things emacs ;)

Leo

Re: Feature freeze

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

On 09/21/2015 12:39 PM, Stefan Monnier wrote:
> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.

Thanks for your hard work and numerous improvements to Emacs. Good luck
with everything!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Feature freeze

[John Wiegley]

>>>>> Daniel Colascione <dancol@dancol.org> writes:

> On 09/21/2015 12:39 PM, Stefan Monnier wrote:
>> But I'll leave these decisions to someone else, because I also take this
>> opportunity to step down as head maintainer.

> Thanks for your hard work and numerous improvements to Emacs. Good luck with
> everything!

Indeed, Stefan, I can't thank you enough. Emacs is the center of my electronic
life!

John

Re: Feature freeze

[joakim]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Time is up!
>
> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.

It would be pretty nice to finally merge the Xwidget branch.

I'm not sure how to proceed though. I'm pretty swamped with work at the
moment, and I would likely need some assistance.

> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.
>
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
>
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.
>
>
>         Stefan
>

-- 
Joakim Verona