RE: [External] : Re: master 927b885 1/3: Disable filtering of commands in M-x completion

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

> > And the doc of `mark-even-if-inactive' says
> > nothing about the mark existing - it's only about
> > whether the mark (assuming it exists) is active.
> 
> Precisely.  So what exactly is the problem with the docs?  Are you
> saying you don't know what "active mark" or "active region" means?
> I'd be surprised.

No, I'm not saying that.  To me, that doc describes
sensible behavior.

I sloppily wrote "No mark set, no active region."
in my recipe to you, when I should have said
"Mark not active".  And that mistake set off some
confused back & forth about whether there was a
mark (i.e., mark set).

The problem I raised from the beginning is with
the doc of `interactive' (for code `r').

The doc string says only:

 r -- Region: point and mark as 2 numeric args,
      smallest first.  Does no I/O.

It says nothing about raising an error if
not active and `mark-even*' is nil.  The
expectation from reading that is that
`interactive' just provides the region
limits as args, always - no error.

The Elisp manual says this for `r':

 Point and the mark, as two numeric arguments,
 smallest first.  This is the only code letter
 that specifies two successive arguments rather
 than one.  This will signal an error if the
 mark is not set in the buffer which is current
 when the command is invoked.  No I/O.

It says that an error is raised when there is
no mark (which is true, but incomplete).  It
should perhaps instead say (and so should the
doc string, if we want to be complete), that an
error is raised if either (1) there is no mark
or (2) the mark is not active and
`mark-even-if-inactive' is nil.

Another possibility is to say nothing at all
about raising an error.  The `mark-even*'
behavior doesn't really have anything to do
with `interactive' specifically.

You might say sure, we need not say anything
about an error from inactive with `mark-even*'
= nil, but we should mention an error if no
mark.  IOW, just what we say now.

I'd argue that it can be confusing to just
call out that special (not too common) case,
and not mention the more common case where
an error is raised for an inactive region
(modulo the option value).

But I recognize that that more common error
is not, strictly speaking, about `r'.  And I
don't feel strongly about this.

I'll point out that this all started because
Juri wrote:

  I'd like also to suggest to filter out commands
  having "r" in their interactive specs - they
  signal an error when the region is not active,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  so no need to show them.

And yes, we can assume that Juri (like I) knows
"what 'active mark' or 'active region' means."

What he said is perhaps further demonstration
that the `interactive' `r' doc could be clearer
or more helpful.

Had he not been mistaken about that, there would
have been no follow-up by me, pointing out that
an inactive region _doesn't_ necessarily raise
an error for `interactive' `r'.
___

As for whether commands with `r' in their specs
should be filtered out, presumably the filtering
condition should be this:

(1) no mark OR
    [(2) `mark-even*' = nil
     AND
     (3) inactive region]

(Personally, I'm not in favor of such filtering,
as I've said, but at least it should be accurate.)
___

One source of confusion in our exchange was no
doubt due to my likely using `M-x set-variable'
to set option `mark-even*' to nil.  I shouldn't
have done that.

There's apparently the equivalent of a :set
function in the C definition of the defcustom.
Bypassing that (which `set-variable' does)
results in no error being raised when the region
is inactive.

(This happens if you use `set-variable' at the
outset or after using Customize to "Revert this
session's customization".  It doesn't happen if
you use `set-variable' after using Customize
just to toggle the value.)