GNU bug report logs - #39143
26.3; `widget-complete' in `customize-option'

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 39143 in the body.
You can then email your comments to 39143 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: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; `widget-complete' in `customize-option'
Date: Wed, 15 Jan 2020 09:54:58 -0800 (PST)

emacs -Q

`M-x customize-option default-frame-alist'

Click `INS'.

Enter `cursor-color' for field `Parameter: '.

Put cursor at beginning of field `Value: ', and delete the default
value, `nil'.

Use `M-TAB' (or `ESC TAB').

You get this error/message: "Not in an editable field".

Two parts to this report.  The first is a bug; the second is an
enhancement request for handling of option `default-frame-alist' and
other frame-alist options.

1. That message is incorrect.  The cursor is definitely in an editable
field.  (Same incorrect message if you first type `Blu', then `M-TAB'.)

2. Emacs should provide reasonable completion for both fields,
`Parameter' and `Value', for `default-frame-alist'.

2a. Completion can be lax for `Parameter', providing candidates that are
predefined parameters, but letting you enter other values too.

2b. Completion can perhaps be strict for `Value' for some known
parameters, but it would probably be better if it were lax in all cases,
unless there is a strict requirement about the possible values in some
case.


In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 10.0.17763

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 39143 <at> debbugs.gnu.org
Subject: Re: bug#39143: 26.3; `widget-complete' in `customize-option'
Date: Wed, 15 Jan 2020 20:06:10 +0200

> Date: Wed, 15 Jan 2020 09:54:58 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> emacs -Q
> 
> `M-x customize-option default-frame-alist'
> 
> Click `INS'.
> 
> Enter `cursor-color' for field `Parameter: '.
> 
> Put cursor at beginning of field `Value: ', and delete the default
> value, `nil'.
> 
> Use `M-TAB' (or `ESC TAB').
> 
> You get this error/message: "Not in an editable field".

In Emacs 27 get the message "No completions available for this field"
instead.  So this problem is already solved.

> 1. That message is incorrect.  The cursor is definitely in an editable
> field.  (Same incorrect message if you first type `Blu', then `M-TAB'.)

This part is already solved.

> 2. Emacs should provide reasonable completion for both fields,
> `Parameter' and `Value', for `default-frame-alist'.

It does provide completions for Parameter, although it's debatable
whether they are "reasonable".

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39143 <at> debbugs.gnu.org
Subject: RE: bug#39143: 26.3; `widget-complete' in `customize-option'
Date: Wed, 15 Jan 2020 10:39:19 -0800 (PST)

> > You get this error/message: "Not in an editable field".
> > 1. That message is incorrect.  The cursor is definitely in an
> > editable field.
> 
> In Emacs 27 get the message "No completions available for this field"
> instead.  So this problem is already solved.

Good.  Thanks for the quick reply.

> > 2. Emacs should provide reasonable completion for both fields,
> > `Parameter' and `Value', for `default-frame-alist'.
> 
> It does provide completions for Parameter, although it's debatable
> whether they are "reasonable".

I guess you mean in Emacs 27.  (Not in Emacs 26, AFAICT.)

Trying an Emacs 27 snapshot from 2019-12-28, it seems
that the completion is reasonable enough.

So this report can be classified as an enhancement request
that we provide some (lax) completion for `Value'.  Thx.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>, 39143 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39143: 26.3; `widget-complete' in `customize-option'
Date: Thu, 27 Feb 2025 10:49:16 -0300

Hi Drew,

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


>> > 2. Emacs should provide reasonable completion for both fields,
>> > `Parameter' and `Value', for `default-frame-alist'.
>>
>> It does provide completions for Parameter, although it's debatable
>> whether they are "reasonable".

> Trying an Emacs 27 snapshot from 2019-12-28, it seems
> that the completion is reasonable enough.

Improving completion for Parameter should be pretty easy, provided we
have a list of all the parameters that have special meanings (and maybe
filter them to only keep the ones that make sense to customize via
default-frame-alist, initial-frame-alist, etc.).

For example:

(defconst frame--special-parameters
  '("alpha" "alpha-background" "auto-hide-function" "auto-lower"
    "auto-raise" "background-color" "background-mode" "border-color"
    "border-width" "bottom-divider-width" "bottom-visible" "buffer-list"
    "buffer-predicate" "child-frame-border-width" "cursor-color"
    "cursor-type" "delete-before" "display" "display-type"
    "drag-internal-border" "drag-with-header-line" "drag-with-mode-line"
    "drag-with-tab-line" "explicit-name" "fit-frame-to-buffer-margins"
    "fit-frame-to-buffer-sizes" "font" "font-backend" "foreground-color"
    "fullscreen" "fullscreen-restore" "height" "horizontal-scroll-bars"
    "icon-left" "icon-name" "icon-top" "icon-type"
    "inhibit-double-buffering" "internal-border-width" "keep-ratio"
    "left" "left-fringe" "line-spacing" "menu-bar-lines" "min-height"
    "min-width" "minibuffer" "minibuffer-exit" "mouse-color"
    "mouse-wheel-frame" "name" "no-accept-focus" "no-focus-on-map"
    "no-other-frame" "no-special-glyphs" "ns-appearance"
    "ns-transparent-titlebar" "outer-window-id" "override-redirect"
    "parent-frame" "right-fringe" "rigth-divider-width" "screen-gamma"
    "scroll-bar-background" "scroll-bar-foreground" "scroll-bar-height"
    "scroll-bar-width" "shaded" "skip-taskbar" "snap-width" "sticky"
    "tab-bar-lines" "title" "tool-bar-lines" "tool-bar-position" "top"
    "top-visible" "tty-color-mode" "undecorated" "unspittable"
    "use-frame-synchronization" "user-position" "user-size"
    "vertical-scroll-bars" "visibility" "wait-for-wm" "width" "z-group")
  "List of special frame parameters that makes sense to Customize.")

(defcustom initial-frame-alist nil
  "Alist of parameters for the initial window-system (a.k.a. \"GUI\") 
frame.

..."
  :type `(repeat (cons :format "%v"
                       (symbol :tag "Parameter"
                               :completions ,frame--special-parameters)
                       (sexp :tag "Value")))
  :group 'frames)

I built the list by looking at the manual.  It's possible I've omitted
something important or added something irrelevant, since I've never
customized this, I think.

But anyway, this shows we can easily improve completion for Parameter
and I can submit a patch for it if desired.

> So this report can be classified as an enhancement request
> that we provide some (lax) completion for `Value'.  Thx.

Now this part is tricky, because completion candidates would have to
depend on the value of Parameter.

I see two alternatives:

1) Provide completion based on the parameter's value, by coding a complete
function that checks the parameter's value and gives suitable
candidates.  This wouldn't benefit a lot of the parameters, but it does
improve the situation.

2) Improve the customization experience by using a "dynamic" cons, which
adapts the second type (currently sexp) depending on the value of the
first type (the symbol).  This is something I did for the
customize-dirlocals command.

So, for example:
If the parameter is "fullscreen", then the second type will be a choice
widget with "fullwidth", "fullheight", "fullboth", "maximized" choices.

If the parameter is "width", then the second type will be a choice
widget with options: integer, cons, float.

And so on.

But I do worry that the added complexity would turn into a downside for
this alternative.


I can work on patches for both alternatives (I prefer the 2nd one), but
I'd like to hear opinions about this.  Thanks.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Mauro Aranda <maurooaranda <at> gmail.com>, "39143 <at> debbugs.gnu.org"
 <39143 <at> debbugs.gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: RE: [External] : Re: bug#39143: 26.3; `widget-complete' in
 `customize-option'
Date: Thu, 27 Feb 2025 17:21:57 +0000

Hi Mauro,

Thanks for looking into this.  I'd completely forgotten about it.

I do think that improving completion for Customize thingies could encourage more use of the Customize UI.

I think everything you said and suggested sounds good.  I agree about the double-edged sword of the added complexity - not just for the coding but also for users.

Parameter-specific completion can really help, but with different kinds of parameters some users might get confused by the different kinds of completion for them.

Overall, I think it would be a definite improvement.  And with some completion "frameworks" (and perhaps even with some ~recent vanilla Emacs improvements?) users could maybe get interactive help on the completion possibilities.

Anything you find you can do to improve this will be welcome.  Use your own judgment; it'll be fine, I'm sure.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>,
 "39143 <at> debbugs.gnu.org" <39143 <at> debbugs.gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: [External] : Re: bug#39143: 26.3; `widget-complete' in
 `customize-option'
Date: Fri, 28 Feb 2025 10:28:13 -0300

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

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

> Hi Mauro,
>
> Thanks for looking into this.  I'd completely forgotten about it.
>
> I do think that improving completion for Customize thingies could
> encourage more use of the Customize UI.
>
> I think everything you said and suggested sounds good.  I agree about
> the double-edged sword of the added complexity - not just for the
> coding but also for users.
>
> Parameter-specific completion can really help, but with different
> kinds of parameters some users might get confused by the different
> kinds of completion for them.
>
> Overall, I think it would be a definite improvement.  And with some
> completion "frameworks" (and perhaps even with some ~recent vanilla
> Emacs improvements?) users could maybe get interactive help on the
> completion possibilities.
>
> Anything you find you can do to improve this will be welcome.  Use
> your own judgment; it'll be fine, I'm sure.

Thanks Drew.

The attached patch is alternative 1: Provide better completion for
Parameter and provide completion for Value when we know the
alternatives.  I think it is an improvement, and it doesn't make the UI
more complex, which alternative 2 does.

[0001-Provide-better-completion-for-customizing-frame-para.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 39143 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: [External] : Re: bug#39143: 26.3; `widget-complete' in
 `customize-option'
Date: Sun, 09 Mar 2025 11:45:06 +0200

> Date: Fri, 28 Feb 2025 10:28:13 -0300
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> From: Mauro Aranda <maurooaranda <at> gmail.com>
> 
> The attached patch is alternative 1: Provide better completion for
> Parameter and provide completion for Value when we know the
> alternatives.  I think it is an improvement, and it doesn't make the UI
> more complex, which alternative 2 does.

Thanks.  I think we should install this, but I wonder how can we make
sure that whenever a new frame-parameter is added, the list in
frame--special-parameters will be considered for updating?

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39143 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: [External] : Re: bug#39143: 26.3; `widget-complete' in
 `customize-option'
Date: Sun, 9 Mar 2025 08:08:57 -0300

On 9/3/25 06:45, Eli Zaretskii wrote:
>> Date: Fri, 28 Feb 2025 10:28:13 -0300
>> Cc: Eli Zaretskii <eliz <at> gnu.org>
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> The attached patch is alternative 1: Provide better completion for
>> Parameter and provide completion for Value when we know the
>> alternatives.  I think it is an improvement, and it doesn't make the UI
>> more complex, which alternative 2 does.
>
> Thanks.  I think we should install this, but I wonder how can we make
> sure that whenever a new frame-parameter is added, the list in
> frame--special-parameters will be considered for updating?

Thanks Eli.  I don't know of any good way to make sure of that, other
than adding a comment to frame_parms in frame.c.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 39143 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: [External] : Re: bug#39143: 26.3; `widget-complete' in
 `customize-option'
Date: Sun, 09 Mar 2025 13:20:07 +0200

> Date: Sun, 9 Mar 2025 08:08:57 -0300
> Cc: drew.adams <at> oracle.com, 39143 <at> debbugs.gnu.org
> From: Mauro Aranda <maurooaranda <at> gmail.com>
> 
> On 9/3/25 06:45, Eli Zaretskii wrote:
>  >> Date: Fri, 28 Feb 2025 10:28:13 -0300
>  >> Cc: Eli Zaretskii <eliz <at> gnu.org>
>  >> From: Mauro Aranda <maurooaranda <at> gmail.com>
>  >>
>  >> The attached patch is alternative 1: Provide better completion for
>  >> Parameter and provide completion for Value when we know the
>  >> alternatives.  I think it is an improvement, and it doesn't make the UI
>  >> more complex, which alternative 2 does.
>  >
>  > Thanks.  I think we should install this, but I wonder how can we make
>  > sure that whenever a new frame-parameter is added, the list in
>  > frame--special-parameters will be considered for updating?
> 
> Thanks Eli.  I don't know of any good way to make sure of that, other
> than adding a comment to frame_parms in frame.c.

A comment is good, but please add comments in both places
cross-referencing the other place.

Thanks.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39143 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: [External] : Re: bug#39143: 26.3; `widget-complete' in
 `customize-option'
Date: Sun, 9 Mar 2025 11:30:38 -0300

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

On 9/3/25 08:20, Eli Zaretskii wrote:
>> Date: Sun, 9 Mar 2025 08:08:57 -0300
>> Cc: drew.adams <at> oracle.com, 39143 <at> debbugs.gnu.org
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> On 9/3/25 06:45, Eli Zaretskii wrote:
>>  >> Date: Fri, 28 Feb 2025 10:28:13 -0300
>>  >> Cc: Eli Zaretskii <eliz <at> gnu.org>
>>  >> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>  >>
>>  >> The attached patch is alternative 1: Provide better completion for
>>  >> Parameter and provide completion for Value when we know the
>>  >> alternatives.  I think it is an improvement, and it doesn't make 
the UI
>>  >> more complex, which alternative 2 does.
>>  >
>>  > Thanks.  I think we should install this, but I wonder how can we make
>>  > sure that whenever a new frame-parameter is added, the list in
>>  > frame--special-parameters will be considered for updating?
>>
>> Thanks Eli.  I don't know of any good way to make sure of that, other
>> than adding a comment to frame_parms in frame.c.
>
> A comment is good, but please add comments in both places
> cross-referencing the other place.

I attach the updated patch.

[0001-Provide-better-completion-for-customizing-frame-para.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 39143 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#39143: 26.3; `widget-complete' in `customize-option'
Date: Sun, 09 Mar 2025 17:15:50 +0200

> Date: Sun, 9 Mar 2025 11:30:38 -0300
> Cc: drew.adams <at> oracle.com, 39143 <at> debbugs.gnu.org
> From: Mauro Aranda <maurooaranda <at> gmail.com>
> 
>  >> Thanks Eli.  I don't know of any good way to make sure of that, other
>  >> than adding a comment to frame_parms in frame.c.
>  >
>  > A comment is good, but please add comments in both places
>  > cross-referencing the other place.
> 
> I attach the updated patch.

Thanks, LGTM.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39143 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#39143: 26.3; `widget-complete' in `customize-option'
Date: Sun, 9 Mar 2025 19:10:45 -0300

close 39143 31.1
quit


On 9/3/25 12:15, Eli Zaretskii wrote:
>> Date: Sun, 9 Mar 2025 11:30:38 -0300
>> Cc: drew.adams <at> oracle.com, 39143 <at> debbugs.gnu.org
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>>  >> Thanks Eli.  I don't know of any good way to make sure of that, 
other
>>  >> than adding a comment to frame_parms in frame.c.
>>  >
>>  > A comment is good, but please add comments in both places
>>  > cross-referencing the other place.
>>
>> I attach the updated patch.
>
> Thanks, LGTM.

Great, thanks.

Pushed to master, and closing the bug.

Previous Next

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