GNU bug report logs - #47673
Absurdly long input field in Customize

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 47673 in the body.
You can then email your comments to 47673 AT debbugs.gnu.org in the normal way.

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

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

From: scame <laszlomail <at> protonmail.com>
To: "scame via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Absurdly long input field in Customize
Date: Fri, 09 Apr 2021 13:20:12 +0000

[Message part 1 (text/plain, inline)]

See attached pic. The value is a number, does it really need this unsightly long input field?

[Message part 2 (text/html, inline)]

[Capture.PNG (image/png, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: scame <laszlomail <at> protonmail.com>
Cc: 47673 <at> debbugs.gnu.org
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Fri, 09 Apr 2021 16:46:33 +0300

> Date: Fri, 09 Apr 2021 13:20:12 +0000
> From:  scame via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> See attached pic.  The value is a number, does it really need this unsightly long input field?

What you see is not the actual length of the field, not at all.

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

From: scame <laszlomail <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "47673 <at> debbugs.gnu.org" <47673 <at> debbugs.gnu.org>
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Fri, 09 Apr 2021 13:50:36 +0000

>
> What you see is not the actual length of the field, not at all.

OK, so is it that long, because the newline also has that
text property? Then why put it on the newline?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: scame <laszlomail <at> protonmail.com>
Cc: 47673 <at> debbugs.gnu.org
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Fri, 09 Apr 2021 17:05:14 +0300

> Date: Fri, 09 Apr 2021 13:50:36 +0000
> From: scame <laszlomail <at> protonmail.com>
> Cc: "47673 <at> debbugs.gnu.org" <47673 <at> debbugs.gnu.org>
> 
> > What you see is not the actual length of the field, not at all.
> 
> OK, so is it that long, because the newline also has that
> text property? Then why put it on the newline?

Presumably because otherwise the face will not be extended to match
the input length.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: scame <laszlomail <at> protonmail.com>
Cc: 47673 <at> debbugs.gnu.org
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Mon, 12 Apr 2021 11:02:07 +0200

scame <laszlomail <at> protonmail.com> writes:

> See attached pic.  The value is a number, does it really need this
> unsightly long input field?

It's just how all text input in Customize works -- it's a non-editable
buffer, but it makes these bits writeable by using a lot of magic behind
the scenes.

So it'll just have to be that way until somebody reimplements Customize
completely, and I'm closing this bug report.

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

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

From: scame <laszlomail <at> protonmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "47673 <at> debbugs.gnu.org" <47673 <at> debbugs.gnu.org>
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Mon, 12 Apr 2021 09:55:10 +0000

>
> It's just how all text input in Customize works -- it's a non-editable
> buffer, but it makes these bits writeable by using a lot of magic behind
> the scenes.

Does this edit buffer need to appear so wide? Can't it be displayed shorter?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: scame <laszlomail <at> protonmail.com>
Cc: "47673 <at> debbugs.gnu.org" <47673 <at> debbugs.gnu.org>
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Mon, 12 Apr 2021 12:03:54 +0200

scame <laszlomail <at> protonmail.com> writes:

> Does this edit buffer need to appear so wide? Can't it be displayed shorter?

It deletes everything up to the end of the line.

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

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

From: scame <laszlomail <at> protonmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "47673 <at> debbugs.gnu.org" <47673 <at> debbugs.gnu.org>
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Mon, 12 Apr 2021 15:19:01 +0000

>
> > Does this edit buffer need to appear so wide? Can't it be displayed shorter?
>
> It deletes everything up to the end of the line.
>

I checked the code, and from a cursory look the problem seems to be that the :extend property was added to the widget-field face, that's why every field became as wide as the screen, because the newline after the field has this face:

  https://github.com/emacs-mirror/emacs/commit/b5781e63cbe7e4c24e4eea3a400880857348ad19

this was done to fix this bug:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774


and apparently no one noticed this change made all customize fields very long.

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

From: scame <laszlomail <at> protonmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "47673 <at> debbugs.gnu.org" <47673 <at> debbugs.gnu.org>
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Mon, 12 Apr 2021 15:25:27 +0000

Forgot to add that it is easy to test. Just open a customize item which has a text edit field. The field extends to the end of the window.

Then you eval this:

  (set-face-attribute 'widget-field nil :extend nil)

and the field is not super long anymore.

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

From: Juri Linkov <juri <at> linkov.net>
To: scame via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: scame <laszlomail <at> protonmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 "47673 <at> debbugs.gnu.org" <47673 <at> debbugs.gnu.org>
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Mon, 12 Apr 2021 19:24:22 +0300

> I checked the code, and from a cursory look the problem seems to be that
> the :extend property was added to the widget-field face, that's why every
> field became as wide as the screen, because the newline after the field has
> this face:
>
>   https://github.com/emacs-mirror/emacs/commit/b5781e63cbe7e4c24e4eea3a400880857348ad19
>
> this was done to fix this bug:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774

In bug#37774 I proposed to support a new value of the :extend attribute
that will extend the field to the fixed width equal to 70 from fill-column.
Would this solve the issue?  Then the field's width will be not too short,
and not overly long.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: laszlomail <at> protonmail.com, 47673 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#47673: Absurdly long input field in Customize
Date: Mon, 12 Apr 2021 19:53:27 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 12 Apr 2021 19:24:22 +0300
> Cc: laszlomail <at> protonmail.com, larsi <at> gnus.org
> 
> In bug#37774 I proposed to support a new value of the :extend attribute
> that will extend the field to the fixed width equal to 70 from fill-column.
> Would this solve the issue?  Then the field's width will be not too short,
> and not overly long.

As the discussion there shows, that proposal has some issues.  On top
of that, I don't currently see how to implement that cleanly (face
merging doesn't know anything about the current column).

Previous Next

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