bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8717: 23.3; widget match functions should be passed internal represe


From: Mauro Aranda
Subject: bug#8717: 23.3; widget match functions should be passed internal representation?
Date: Mon, 2 Nov 2020 09:45:29 -0300

Dave Abrahams <dave@boostpro.com> writes:

> Please consider this widget definition:
>
>   (defun el-get-repeat-value-to-internal (widget list-or-element)
>     (if (listp list-or-element) list-or-element (list list-or-element)))
>
>   (defun el-get-repeat-match (widget value)
>     (widget-editable-list-match widget (el-get-repeat-value-to-internal widget value)))
>
>   (define-widget 'el-get-repeat 'repeat
>     "A variable length list of non-lists that can also be represented as a single element"
>     :value-to-internal 'el-get-repeat-value-to-internal
>     :match 'el-get-repeat-match)
>
> I found it surprising that the :match field was required (if you don't
> include it, a value of "foo" does not match an (el-get-repeat string)
> widget.

It took me more than one read to understand this bug report, because the
title asks one thing, but the code presented doesn't do that, and maybe
that goes to show how confusing this stuff can be.

The :match function should be passed a value in the external format.
That is, the value as seen by the rest of Emacs.  A value matches the
repeat widget if the value is a list, and all the members match the type
specified by the repeat widget.  So, "foo" can't match a repeat widget
or a widget that derives from the repeat widget, unless the derived
widget overrides the :match function.

el-get-repeat-value-to-internal is not converting a value to an
"internal format", it is just adapting the value to an "external format"
that the repeat widget can represent.  Of course, if for the widget that
way of representing a value is useful, it can represent it that way,
but that doesn't mean that the :match function takes the value in the
internal format.

> I'm not sure what the proper remedy is; the documentation does
> not distinguish between where the system will operate on the "internal"
> and "external" values.  So, at least clarification in the docs is needed
> regardless, IMO.

The manual doesn't even say what an "external value" and an
"internal value" is.  And surely it needs more work in this and other
concepts, but would be it OK to install something along the lines of the
attached patch, to clarify this?

Attachment: 0001-Document-that-the-match-function-for-a-widget-takes-.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]