What `opic0ids' really is [was: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw.]

["Stuart D. Herring" <herring@lanl.gov>]

> I say we should GIVE THE USER THE CHOICE.  I have proposed a way of
> doing this to which nobody's commented yet: Have three values for the
> variable with the furlong long name, namely (t nil mode).  t and nil
> will carry on meaning what they mean, and the symbol 'mode, the
> default, will mean "Major mode may set its own default here".
>
> Comments, please!

I've not been in this thread thus far, but I feel that the point may be
being missed here.  open-paren-in-column-0-is-defun-start is purely an
optimization:

1. If the user knows that "bad" C0 parens are sufficiently rare
("sufficiently" for his purposes) that assuming them to be defun-start
points, he should set the variable to t (perhaps as a file-local in a long
C file which would otherwise be a problem).

2. If another user knows that code she deals with does not follow good
indentation standards or is using some preprocessor or so that makes that
assumption invalid, she should set the variable to nil (again, perhaps
locally).

3. If a mode knows that its language requires that the rule be followed
(or that it is followed in all halfway-sensible cases), it MAY (see RFC
2119) set opic0ids to t locally in its buffers, but it SHOULD NOT assume
that the variable is non-nil (in that, perhaps, it assumes that low-level
functions involved in `beginning-of-defun' will act as they do when it is
non-nil) unless it specifically dynamically binds the variable so.

4. If a mode knows that its language requires or merely often involves
that other C0 parens appear, it SHOULD set opic0ids to nil locally in its
buffers.  If a user overrides this setting, the mode SHOULD NOT fail or
raise errors, and MUST NOT make incorrect textual buffer modifications,
but may of course produce and/or cache incorrect answers about the
structure of text in the buffer.

All that I think is common sense or follows from the definition of
opic0ids as an optimization control.  My own suggested guidelines follow.

5. A mode MAY ignore opic0ids in its own code (and bind it conveniently
when calling into standard routines) if parens are not associated with
defuns in its language.  A mode MAY similarly ignore the variable if (for
some operation) it provides a more powerful, faster, more convenient, or
otherwise superior (e.g., updates useful internal data) mechanism for
finding the beginnings of defuns that incurs no user-perceptible
performance penalty for any operation on a well-formed file of a size and
complexity ever encountered in practice on the overwhelming majority of
modern hardware.

6. Any feature or behavior without which a mode is usable (even if
crippled) and which has the potential in any plausible scenario to delay
editing (particularly repeatedly) MUST be controllable by a user option
(although the default value SHOULD enable it so that it is available
except when problematic and is known in the first place).

7. A mode SHOULD interpret the assumption implied by opic0ids non-nil as
appropriate to that mode; for instance, in C mode, where functions begin
not with their opening { but rather with the return type of the function,
a C0 paren (with opic0ids set) may be assumed to be the beginning of a
function's root block, but the mode should still arrange to move before
the argument list, name, and return type (as possible) when performing
`beginning-of-defun' or the equivalent.

8. A mode MUST NOT use the value of opic0dis to decide whether to make
other unrelated assumptions or simplifications, but it MAY provide a value
of a user option which means "enable <feature> iff opic0ids is set".

9. All code MUST NOT assume the converse -- that all starts of defuns are
heralded by C0 parens -- as a result of the value of opic0ids.

10. All code SHOULD NOT assume that converse ever, unless their language
requires it to be the case.  If it is prohibitively expensive not to
assume it, it may be assumed, but this variance MUST be documented and
SHOULD be controlled by a user option (whose default value MAY allow the
assumption) if feasible.

I note that in 21.3.1 (the only version I have available at the moment)
Emacs Lisp mode violates #10.

Sorry that this is something of a rant, but I want to put out a set of
rules such that either
A) we come to agree that they are a good representation of how things
should be, so that we now have a guide for how to resolve things;
B) we discover that we are not in agreement about what the goals/effects
of this user option are/should be, so that we can address them instead of
wasting time talking at cross purposes; or
C) we find that I was right to stay out of this thread because I do not
understand the subject or have uselessly unique ideas about it, so that I
will resume silence and not waste anyone's time with lots of shorter
messages that would be no more helpful.

So, er, which is it?
Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.