GNU bug report logs - #52
FW: [mouse-1 in Customize should respect mouse-1-click-follows-link]

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52 in the body.
You can then email your comments to 52 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <submit <at> debbugs.gnu.org>
Subject: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link]
Date: Tue, 11 Mar 2008 10:07:09 -0800

 


-----Original Message-----
From: emacs-devel-bounces+drew.adams=oracle.com <at> gnu.org
[mailto:emacs-devel-bounces+drew.adams=oracle.com <at> gnu.org] On Behalf Of Drew
Adams
Sent: Sunday, March 09, 2008 8:50 PM
To: emacs-devel <at> gnu.org
Cc: rms <at> gnu.org
Subject: RE: [mouse-1 in Customize should respect
mouse-1-click-follows-link]

Resending.

These are links. They should be controlled by `mouse-1-click-follows-link'.


> From: Richard Stallman Sent: Friday, December 28, 2007 2:10 PM
> 
> What do people think of this issue?
>
>
> ------- Start of forwarded message -------
> From: "Drew Adams" <drew.adams <at> oracle.com>
> To: "Bug-Gnu-Emacs" <bug-gnu-emacs <at> gnu.org>
> Date: Wed, 26 Dec 2007 13:28:30 -0800
> Message-ID: <DHEEKFAFJEFOJHLCFPFDCECBCDAA.drew.adams <at> oracle.com>
> MIME-Version: 1.0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Subject: mouse-1 in Customize should respect 
> mouse-1-click-follows-link
> 
> Click mouse-1 on a link in a Customize buffer that is a link to
> another option name or similar. That is, on text between `' that is
> highlighted with mouseover (`mouse-face').  The link is followed.
> 
> The link should not be followed by `mouse-1' if
> `mouse-1-click-follows-link' is nil.  In that case, only clicking
> `mouse-2' should follow the link.
> 
> 
> In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
>  of 2007-06-02 on RELEASE
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --cflags 
> -Ic:/gnuwin32/include'

Message #10 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 52 <at> debbugs.gnu.org
Subject: Re: FW: [mouse-1 in Customize should respect
	mouse-1-click-follows-link]
Date: Wed, 06 Jul 2011 19:24:03 +0200

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

> These are links. They should be controlled by `mouse-1-click-follows-link'.

[...]

>> Click mouse-1 on a link in a Customize buffer that is a link to
>> another option name or similar. That is, on text between `' that is
>> highlighted with mouseover (`mouse-face').  The link is followed.
>> 
>> The link should not be followed by `mouse-1' if
>> `mouse-1-click-follows-link' is nil.  In that case, only clicking
>> `mouse-2' should follow the link.

That sounds logical.

The actual key binding in these buffers for the mouse is:

<down-mouse-1>	widget-button-click
<down-mouse-2>	widget-button-click

How is `mouse-1-click-follows-link' generally supposed to work?  Is
`widget-button-click' supposed to not do its thing if
`mouse-1-click-follows-link' is nil?  That seems rather yucky.  Or is
the mode not supposed to bind `down-mouse-1' to anything if it's nil?

That variable is unknown to me.  The documentation says:

------
This feature only works in modes that specifically identify
clickable text as links, so it may not work with some external
packages.  See `mouse-on-link-p' for details.
------

Customize can't be said to be an "external package".  :-)  

`mouse-on-link-p' says:

------
A clickable link is identified by one of the following methods:

- If the character at POS has a non-nil `follow-link' text or
overlay property, the value of that property determines what to do.

- If there is a local key-binding or a keybinding at position POS
for the `follow-link' event, the binding of that event determines
what to do.
------

And the widget stuff does put `follow-link' on stuff.  So how is this
supposed to tie together?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #13 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lars Magne Ingebrigtsen'" <larsi <at> gnus.org>
Cc: 52 <at> debbugs.gnu.org
Subject: RE: FW: [mouse-1 in Customize should respect
	mouse-1-click-follows-link]
Date: Wed, 6 Jul 2011 10:32:13 -0700

Thanks for looking at this, Lars.

I'm no expert on how this works or is supposed to work.

A (blind) guess would be that the problem is that these are perhaps not
considered to be "links" by the Customize code.  Dunno.

Emacs can be fussy about what it considers to be a link.  Some of the things
called "buttons" in the code are in fact links from a user viewpoint.  (But some
of them are not - they are truly action buttons.)

Someone more knowledgable than I will need to help here, I'm afraid.

Message #16 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 52 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#52: FW: [mouse-1 in Customize should respect
	mouse-1-click-follows-link]
Date: Wed, 06 Jul 2011 16:09:50 -0400

>>> Click mouse-1 on a link in a Customize buffer that is a link to
>>> another option name or similar. That is, on text between `' that is
>>> highlighted with mouseover (`mouse-face').  The link is followed.

Yes, Custom has always used mouse-1 clicks for that purpose, AFAIK.

> The actual key binding in these buffers for the mouse is:

> <down-mouse-1>	widget-button-click
> <down-mouse-2>	widget-button-click

> How is `mouse-1-click-follows-link' generally supposed to work?  Is

This is supposed to let mouse-1 clicks follow links otherwise only
accessible via mouse-2 clicks (i.e. when there's no binding for mouse-1
on this button/link).

It relies on the `follow-link' text-property and/or key binding to
specifies when this fallback is applicable.

That was introduced in reaction to people complaining about the
non-standard Emacs convention of using mouse-2 to follow links.
But actually some part of Emacs already used mouse-1 to follow links,
such as Customize, so these aren't affected by
mouse-1-click-follows-link.

I think in this present case, Custom should better follow Emacs
conventions and hence only bind mouse-2 and then rely on the follow-link
feature to make mouse-1 also work for those users who like it.


        Stefan

Message #19 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 52 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#52: FW: [mouse-1 in Customize should respect
	mouse-1-click-follows-link]
Date: Thu, 07 Jul 2011 18:19:56 +0200

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

> I think in this present case, Custom should better follow Emacs
> conventions and hence only bind mouse-2 and then rely on the follow-link
> feature to make mouse-1 also work for those users who like it.

That sounds like a good idea.  I've had a go at doing this, but I'm
afraid I wasn't able to make it work.  Somebody who knows more about
`follow-link' and customize should have a look at it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #22 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 52 <at> debbugs.gnu.org,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#52: FW: [mouse-1 in Customize should respect
	mouse-1-click-follows-link]
Date: Thu, 07 Jul 2011 15:03:23 -0400

The original report concerned only Emacs 22:

>> Click mouse-1 on a link in a Customize buffer that is a link to
>> another option name or similar. That is, on text between `' that is
>> highlighted with mouseover (`mouse-face').  The link is followed.
>>
>> In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
>>  of 2007-06-02 on RELEASE

Since Emacs 23, links in the Customize buffer have obeyed
mouse-1-click-follows-link, via custom-mode-link-map.

The other widget buttons used by Customize, like the Exit button, are
always activated with mouse-1, regardless of mouse-1-click-follows-link.
But this is the correct behavior, since those are not links.

So this is a zombie bug report.  I'm closing it.

Message #33 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <52 <at> debbugs.gnu.org>
Subject: FW: bug#52: FW: [mouse-1 in Customize should respect
	mouse-1-click-follows-link]
Date: Thu, 27 Oct 2011 14:13:40 -0700

> From: Chong Yidong Sent: Thursday, July 07, 2011 12:03 PM
>
> Since Emacs 23, links in the Customize buffer have obeyed
> mouse-1-click-follows-link, via custom-mode-link-map.

So it's a regression starting in Emacs 23. ;-)

Actually, the binding is made in `widget-keymap', which is the grandparent of
`custom-mode-link-map'.  But I thought anyway, from looking at the code, that
`custom-mode-link-map' would be the right one to adjust, to change behavior for
this.  But apparently I was wrong - see below.

> The other widget buttons used by Customize, like the Exit button, are
> always activated with mouse-1, regardless of 
> mouse-1-click-follows-link.  But this is the correct behavior,
> since those are not links.
>
> So this is a zombie bug report.  I'm closing it.

You don't give users the choice (easily).  They should be able to control this
via `mouse-1-click-follows-link'.  They should not have to also modify
`custom-mode-link-map' (or, in face, `widget-keymap') directly.

Help buffers have links on function names etc.  Mouse-1 on those links respects
`mouse-1-click-follows-link'.  My code adds links also to function names etc. in
Customize doc strings - same idea as Help.  Those too should respect the user
option.

It's not even clear to me how to control this.  I tried this at first:

(add-hook 'Custom-mode-hook
          (lambda ()
           (define-key custom-mode-link-map
            [mouse-1] 'mouse-set-point)
           (define-key custom-mode-link-map
            [down-mouse-1] 'mouse-drag-region)))

And it didn't work, but I'm not sure why (still).
Keymap `custom-mode-link-map' correctly had this:

<down-mouse-1>  mouse-drag-region
<mouse-1>       mouse-set-point

But clicking mouse-1 on link/button text had this effect:

As soon as mouse-1 was pressed (not released), the face changed to an inset
(depressed) face.  And as soon as mouse-1 was released, the link was followed
(and the face restored).

The inset face looks like `custom-button-pressed', the local value of
`widget-button-pressed-face', and `widget-button-click' was in fact called
(why?).  The debugger said that `widget-button-click' was called interactively
(but it is not bound to any key).

If I did `C-u C-x =' on a link, the help said that the keymap property was nil,
the follow-link property was `mouse-face', and the button property was
`documentation-link (widget)Top'.

And mouse-1 was still bound to `mouse-set-point', etc.!  And it didn't matter
whether the click was quick or I held mouse-1 depressed for a while (to wait out
some timeout).

Actually, if I did something in another app and then came back and clicked
mouse-1 on a link, the first click _sometimes_ did nothing but set point, but
thereafter the other behavior returned (depressed-button face, follow link
etc.).  

This behavior is still a mystery to me.

I eventually got it done by binding the mouse keys in `widget-keymap' instead of
`custom-mode-link-map' in the hook.  Why I would need to do that, I have no
idea.  Do you have an idea?

What's clear is that it is not very clear how a user can easily prevent mouse-1
from following such links in Customize.

And I still don't understand why you don't let the option
`mouse-1-click-follows-link' control this, just as it does in all other buffers.
Why should Customize be handled differently from *Help* etc.?

Message #36 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>,
	"'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 'Lars Magne Ingebrigtsen' <larsi <at> gnus.org>, 52 <at> debbugs.gnu.org
Subject: RE: bug#52: FW: [mouse-1 in Customize should respect
	mouse-1-click-follows-link]
Date: Thu, 27 Oct 2011 14:16:47 -0700

Well, it turns out that that is no solution anyway.  If I do that then even the
real buttons (the rectangular, raised ones) in Customize do not react to
mouse-1.

Sigh.

Why are links treated the same as buttons in Customize?  Maybe that's the
question.  Dunno.

Message #39 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>,
	"'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 52 <at> debbugs.gnu.org
Subject: RE: bug#52: FW: [mouse-1 in Customize should
	respectmouse-1-click-follows-link]
Date: Thu, 27 Oct 2011 14:28:20 -0700

> Well, it turns out that that is no solution anyway.  If I do 
> that then even the real buttons (the rectangular, raised ones)
> in Customize do not react to mouse-1.
> 
> Sigh.
> 
> Why are links treated the same as buttons in Customize?  
> Maybe that's the question.  Dunno.

I want, as before, links to work only with mouse-2, but buttons and menu items
to work with mouse-1.  It seems that's no longer possible (?).

Using the hook I showed, I can use mouse-2 (only) for links (buttons too,
unfortunately), but it seems that mouse-1 (only) is hard-coded for menu items.
So I can use mouse-2 on the State button to open its menu, but then must switch
to mouse-1 to choose a menu item.

I want to be able to select text normally using mouse-1 and mouse-3 etc.,
including text that is linked.  I want to be able to click mouse-2 (only) to
follow links. I want to be able to use mouse-1 for both buttons and menu items.

This is nuts.  Why is it so messy?

Message #42 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Stefan Monnier' <monnier <at> iro.umontreal.ca>, 52 <at> debbugs.gnu.org
Subject: Re: bug#52: FW: [mouse-1 in Customize should
	respectmouse-1-click-follows-link]
Date: Sat, 29 Oct 2011 12:46:14 +0800

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

> I want to be able to select text normally using mouse-1 and mouse-3
> etc., including text that is linked.

Nothing prevents you from doing this.

Message #45 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 'Stefan Monnier' <monnier <at> iro.umontreal.ca>, 52 <at> debbugs.gnu.org
Subject: RE: bug#52: FW: [mouse-1 in Customize should
	respectmouse-1-click-follows-link]
Date: Sat, 29 Oct 2011 08:04:39 -0700

> > I want to be able to select text normally using mouse-1 and mouse-3
> > etc., including text that is linked.
> 
> Nothing prevents you from doing this.

Yeah, how?  See what I wrote.  `mouse-1', held down for no matter how long,
follows links and buttons in Customize.  It does not do this anywhere outside of
Customize.

Message #48 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Stefan Monnier' <monnier <at> iro.umontreal.ca>, 52 <at> debbugs.gnu.org
Subject: Re: bug#52: FW: [mouse-1 in Customize should
	respectmouse-1-click-follows-link]
Date: Sun, 30 Oct 2011 11:25:06 +0800

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

>>
>> Nothing prevents you from doing this.
>
> Yeah, how?  See what I wrote.  `mouse-1', held down for no matter how
> long, follows links and buttons in Customize.  It does not do this
> anywhere outside of Customize.

I can't reproduce this.  With emacs -Q, and doing M-x customize,
dragging `mouse-1' across (say) the "Undo edits" buffer selects that
text, without enabling the button.  Similarly for links.

Message #51 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 'Stefan Monnier' <monnier <at> iro.umontreal.ca>, 52 <at> debbugs.gnu.org
Subject: RE: bug#52: FW: [mouse-1 in Customize should
	respectmouse-1-click-follows-link]
Date: Sun, 30 Oct 2011 07:46:29 -0700

> I can't reproduce this.  With emacs -Q, and doing M-x customize,
> dragging `mouse-1' across (say) the "Undo edits" buffer selects that
> text, without enabling the button.

I see that too for emacs -Q.  So what?

1. _Clicking_, not dragging, mouse-1 on `Undo edits' or `INS' or `State' _does_
activate the button.  No matter how long you hold mouse-1 depressed.
`mouse-1-click-follows-links' is supposed to affect mouse-1 clicks, and a nil
value is supposed to return you to the same (sane) behavior Emacs had before Dev
started making mouse-1 follow links at all.

> Similarly for links.

No again.  In emacs -Q, with nil `mouse-1-click-follows-link', press mouse-1 on
`Hide' and hold it there as long or as short a time as you like (without
dragging). The `Hide' "link" is still followed (or the "button" is activated)
when you release the button.  Mouse-1 click is following links, in spite of the
option value.

2. To reproduce the problem as I reported it in doc strings, with emacs -Q:

(setq mouse-1-click-follows-link  nil)

(defcustom foo-fns ()
  "Some possibilities:
 `foobar', `toto'"
  :type '(repeat symbol) :group 'edit)

(defun foobar ()
  "Foobar's doc string"
  42)

M-x customize-option foo-fns

In the doc string, `foobar' is highlighted when you mouseover it.  It is a link.
Click mouse-1 on it (you might sometimes have to click twice, but not a
double-click).  Help opens.  QED.

Message #54 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 52 <at> debbugs.gnu.org
Subject: RE: bug#52: FW: [mouse-1 in Customize
	shouldrespectmouse-1-click-follows-link]
Date: Sun, 16 Sep 2012 17:26:13 -0700

ping

Message #59 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15682 <at> debbugs.gnu.org, 52 <at> debbugs.gnu.org
Subject: Re: bug#15682: 24.3.50;
 `:link' in `defgroup' does not respect `mouse-1-click-follows-link'
Date: Wed, 27 Apr 2016 18:09:19 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> (defgroup foo nil
>   "..." :prefix "foo-" :group 'editing
>   :link '(url-link "http://www.emacswiki.org/"))
>
> (defcustom foobar t "..." :type 'boolean :group 'foo)
>
> M-x set-variable mouse-1-click-follows-link nil
> M-x customize-option foobar
>
> Click the link `http://www.emacswiki.org/' using `mouse-1'.  The link is
> followed - it should not be followed.
>
> Note that `mouse-on-link-p' returns `t' for positions on this link, and
> such positions have face `custom-link', property `follow-link' with
> value `mouse-face', and property `mouse-face' with a face value, all of
> which show further that the behavior violates the mandate of
> `mouse-1-click-follows-link'.

I've had another peek at this, but the main problem is that I don't
quite understand why the Widget code is so...  complicated.  Why does it
do all the stuff below?  I mean, no other modes that react to mouse
clicks need to ... do all that...

(defun widget-button-click (event)
  "Invoke the button that the mouse is pointing at."
  (interactive "e")
  (if (widget-event-point event)
      (let* ((oevent event)
	     (mouse-1 (memq (event-basic-type event) '(mouse-1 down-mouse-1)))
	     (pos (widget-event-point event))
	     (start (event-start event))
	     (button (get-char-property
		      pos 'button (and (windowp (posn-window start))
				       (window-buffer (posn-window start)))))
	     newpoint)
	(when (or (null button)
		  (catch 'button-press-cancelled
	      ;; Mouse click on a widget button.  Do the following
	      ;; in a save-excursion so that the click on the button
	      ;; doesn't change point.
	      (save-selected-window
		(select-window (posn-window (event-start event)))
		(save-excursion
		  (goto-char (posn-point (event-start event)))
		  (let* ((overlay (widget-get button :button-overlay))
			 (pressed-face (or (widget-get button :pressed-face)
					   widget-button-pressed-face))
			 (face (overlay-get overlay 'face))
			 (mouse-face (overlay-get overlay 'mouse-face)))


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #62 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15682 <at> debbugs.gnu.org, 52 <at> debbugs.gnu.org
Subject: RE: bug#15682: 24.3.50; `:link' in `defgroup' does not respect
 `mouse-1-click-follows-link'
Date: Wed, 27 Apr 2016 09:24:34 -0700 (PDT)

> I've had another peek at this, 

Thanks for looking into it.

> but the main problem is that I don't quite understand why the
> Widget code is so...  complicated.

I sympathize, and I agree that is difficult to fathom.
Can't help with the understanding, however.

> Why does it do all the stuff below?  I mean, no other modes
> that react to mouse clicks need to ... do all that...

Dunno.  But just because the code can be difficult to follow
is not a reason to assume that it does unnecessary things, in
general.  The widget code that I've been able to follow does
DTRT, generally (AFAICT).

I doubt that anyone left understands the widget code well.
Maybe you can find Per Abrahamsen and get him to take a look?
The URLs for him listed here are dead, but maybe looking here
would be a start: https://www.emacswiki.org/emacs/PerAbrahamsen.

Message #65 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15682 <at> debbugs.gnu.org, 52 <at> debbugs.gnu.org
Subject: Re: bug#15682: 24.3.50;
 `:link' in `defgroup' does not respect `mouse-1-click-follows-link'
Date: Wed, 27 Apr 2016 18:53:17 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> Dunno.  But just because the code can be difficult to follow
> is not a reason to assume that it does unnecessary things, in
> general.  The widget code that I've been able to follow does
> DTRT, generally (AFAICT).

It does, but the logic is very hard to follow.  Custom/widget works by
inserting text into the buffer, and then "converting" it to a widget, or
by creating a widget and then inserting it.  And it does it all with
overlays, and seems like it's created its own event handling distinct
from the normal Emacs event handler, sort of.

There are, of course, historical reasons for this.  Per wrote Widget in
the mid 90s when many of these issues hadn't been resolved, and it
worked across many Emacs versions.

I kinda think it might be time to consider doing a rewrite from scratch
using modern Emacs features, and then things like this bug report would
start working automatically.

How big a task would this be?  I mean, of course we'd keep compatibility
(the defcustom language is fine), but just rewrite the UI `M-x
customize' bits...  Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #68 received at 52 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15682 <at> debbugs.gnu.org, 52 <at> debbugs.gnu.org
Subject: RE: bug#15682: 24.3.50; `:link' in `defgroup' does not respect
 `mouse-1-click-follows-link'
Date: Wed, 27 Apr 2016 10:18:09 -0700 (PDT)

> I kinda think it might be time to consider doing a rewrite from scratch
> using modern Emacs features, and then things like this bug report would
> start working automatically.
> 
> How big a task would this be?  I mean, of course we'd keep compatibility
> (the defcustom language is fine), but just rewrite the UI `M-x
> customize' bits...  Hm...

I can't speak to this, sorry.  I'll just mention that I think:
(1) it could be a large undertaking and (2) there is existing
code out there that depends on or enhances cus*.el and wid*.el
code.

Personally, I would prefer that we live with it, and try to
improve it incrementally, rather than opting for a rewrite or
replacement.  I'd like to see a resident Emacs expert on wid*
and cus*, rather than someone who doesn't master it just trying
for a replacement.

(Yes, I'm conservative wrt this stuff.  Emacs is one of the
few things I'm conservative about. ;-))

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.