Properly using :value-to-external and :value-to-internal?

Properly using :value-to-external and :value-to-internal?

[Ryan]

Hi all,

I could use some help writing a special widget for use in the 
"defcustom" declaration that I'm writing. I'm writing a variable that's 
a list of match conditions. Each match condition is a choice between a 
literal string that only matches exactly, a prefix string that matches 
anything that starts with the prefix, or a regexp. The problem is that 
all three of these things is internally just a string, so there's no way 
to tell which one the variable has been set to. Here's a minimal example 
demonstrating the problem:

|(defcustom myvar""  "String or regexp"
   :type'(choice(string:tag"String")
                  (regexp:tag"Regexp")))|


Regardless of whether the user chooses the String or Regexp options, the 
variable gets set to a string and there's no way to tell whether or not 
it's supposed to be a regexp. What I'd like to do is have the variable 
be set to one if either "(TYPE . VALUE)", where TYPE is one of 'string 
or 'regexp and VALUE is whatever the user entered. I figured that I 
could accomplish this by creating a few custom widgets with special 
":value-to-external" and ":value-to-internal" properties that handle the 
conversion between bare strings and the cons cells that I want. However, 
no matter what I try, i seem to run into errors, probably because the 
":match" and ":validate" properties are looking at the cons cells 
instead of the bare strings and rejecting them. So can someone give me 
an example of a "define-widget" call that looks and works just like a 
"string" widget but actually gives "(string . VALUE)" as its value?

Thanks,

-Ryan Thompson

RE: Properly using :value-to-external and :value-to-internal?

[Drew Adams]

> I could use some help writing a special widget for use in the
> "defcustom" declaration that I'm writing. I'm writing a variable that's
> a list of match conditions. Each match condition is a choice between a
> literal string that only matches exactly, a prefix string that matches
> anything that starts with the prefix, or a regexp. The problem is that
> all three of these things is internally just a string, so there's no way
> to tell which one the variable has been set to. Here's a minimal example
> demonstrating the problem:
> 
> |(defcustom myvar""  "String or regexp"
>    :type'(choice(string:tag"String")
>                   (regexp:tag"Regexp")))|
> 
> 
> Regardless of whether the user chooses the String or Regexp options, the
> variable gets set to a string and there's no way to tell whether or not
> it's supposed to be a regexp. What I'd like to do is have the variable
> be set to one if either "(TYPE . VALUE)", where TYPE is one of 'string
> or 'regexp and VALUE is whatever the user entered. I figured that I
> could accomplish this by creating a few custom widgets with special
> ":value-to-external" and ":value-to-internal" properties that handle the
> conversion between bare strings and the cons cells that I want. However,
> no matter what I try, i seem to run into errors, probably because the
> ":match" and ":validate" properties are looking at the cons cells
> instead of the bare strings and rejecting them. So can someone give me
> an example of a "define-widget" call that looks and works just like a
> "string" widget but actually gives "(string . VALUE)" as its value?

Good question.  I don't have any real help for you, unfortunately.
Perhaps someone else will.

It's clear that once the variable has a value that is a string you
cannot tell whether the user picked `Regexp' or `String'.  A regexp
string is a string (and vice versa, though some strings are invalid as
regexps).  It is really only during customization that a difference is
manifested.  (This is a bit like the character/integer thing: some
integers are not chars, but many are.)

I do use `define-widget' in several places in my code, including in a
redefinition of the `color' widget, which, like the `string' widget,
is based on widget `editable-field'.  I think the answer is to do what
you suggested (e.g. use a cons) and to define :match, :validate,
:complete-function, etc. appropriately.