RE: [External] : Re: master 6eeab90632: Don't accept whitespace or hex floats in rgbi: colour specs

[Drew Adams <drew.adams@oracle.com>]

> > If the leading whitespace and hex floats don't cause
> > problems, why not keep the ability to understand them?
> > It could come in handy.
> 
> So it might seem, but over-tolerant implementation is generally a
> mistake. It restricts compatibility in the other direction (what worked
> with Emacs won't work elsewhere), restricts future changes and
> implementations, detects fewer user mistakes, and makes documentation
> and specifications less useful. It's not doing the user a service.

+1.

Dunno about this particular case, but there are
often (at least) two different use cases for such
things.  They could both be accommodated easily
by adding an optional arg, LAX, or its opposite,
STRICT, to choose the other behavior.

The two behaviors are:

1. LAX: Allow nonexact, nonkosher, or in some
   way looser matches.

2. STRICT: Allow only exact matches.

Examples:

1. JSON - in practice - in the wild, lots of
nonstandard syntax is used.  Applications often
want to support such syntax because, well, it's
used - common.

But if you want/need to know _whether_ some
data is well-formed JSON data according to the
standard, then you don't want to allow data
that's not well-formed.

https://docs.oracle.com/en/database/oracle/oracle-database/21/adjsn/conditions-is-json-and-is-not-json.html#GUID-1B6CFFBE-85FE-41DD-BA14-DD1DE73EAB20

(There's also the notion of "validity",
relative to a JSON schema.  That's different;
there, the schema decides what's allowed.)


2. Thing-at-point - Emacs (unfortunately) doesn't
test for a THING being _at_ point.  It instead
tests for a THING being either at point or at
(1- point).

This could be considered a good thing in contexts
where all you want is to maximize the chances of
obtaining a thing from the buffer for use as, say,
a default value for input.  But it's definitely
a bad thing if what you want is to actually find
out if there is a THING at point - that is, if
you really want a THING only if it's AT point.

My own approach is to have thing-at-point and its
bounds actually check for a thing _AT_ point, and
to provide other functions for obtaining a THING
that's _near_ point, where you can control what
"near" means.  See bug #9300:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9300

https://www.emacswiki.org/emacs/ThingAtPointPlus


3. Completion - If your aim is to maximize the
number of possible completion candidates, then a
very loose kind of matching can be good.  But if
you want to obtain a set of candidates that are
particularly appropriate, then such looseness
can just introduce noise.

This is a problem with the `completion-styles'
design of Emacs.  The fallback process, from a
failing style to the next and so on, is really
aimed at maximizing the chances of finding a
candidate of some kind (the styles define the
possible kinds - the matching is a union/OR of
all of those kinds).  Your code can't know
which kind of matching was used successfully.

My own approach lets users change completion
methods on the fly, that is, control their use
as _alternatives_.  Then you know what kind of
matching is used and is successful or not.

(I also support using `completion-styles', in
combination with other methods.  But you're
not a captive of the fallback behavior that
`completion-styles' design locks you into.)

https://www.emacswiki.org/emacs/Icicles_-_Completion_Methods_and_Styles#VanillaEmacsStylesAndOption_completing-styles

______________________

You get the point.  There are advantages to both
LAX and STRICT.  (And there can be more complex
division/choices than just a binary LAX/STRICT.)

A LAX choice can help if the priority is to get
(or support) _something_, rather than raising
an error or returning nil or NULL.  A STRICT
choice is useful if you want to know _whether_
there's a match, and not just obtain _something_.
___

Without bothering to understand more about this
RGBI thing, a naive suggestion would be to add
an optional STRICT arg.  That would leave the
behavior as it is now, by default (so backward
compatible, if that's important).  But it would
also let you test for an exact match.

(If this is a new feature, so there's no need to
keep the existing behavior by default, then you
could change it to be STRICT by default and
accept an optional LAX arg.)
___

We should keep this kind of thing in mind.

Pretty much any time there's some matching or
built-in predicate-satisfying involved, it's
worth thinking about whether it makes sense to
either add an optional argument to provide
either (1) a common "opposite" behavior (LAX or
STRICT) or (2) a predicate, or other function,
to specify the behavior (overriding the default
behavior).

This hopefully all seems obvious.  But I think
it's not always kept in mind.