Subject: bug#39143: 26.3; `widget-complete' in `customize-option'

From: Mauro Aranda <[email-masked]>
Date: Thu, 27 Feb 2025 10:49:16 -0300

Hi Drew,

Drew Adams <[email-masked]> 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.