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

Previous Next

Full log

View this message in rfc822 format

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: 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.

Previous Next

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