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

[Drew Adams]

> >> > (defun foo (&optional beg end)
> >> >   (interactive "r")
> >> >   (message "FOO"))
> >>
> >> Yes, I'm sure.  'M-x foo RET' without an active
> >> region raises an error:
> >>   command-execute: The mark is not active now
> >
> > I don't see that in Emacs 27.1 or prior (with
> > `emacs -Q').  Is this perhaps new for 28?
> > If so, why would we do that?
> 
> It raises an error because the value of
> mark-even-if-inactive was changed to nil,
> so the region exists only when explicitly activated.

Really?  That's a horrible change in default behavior
(IMHO).  Why was that done?

And that simple `foo' definition is enough to point
to regressive behavior.  That command should just
work - across all Emacs versions.  `M-x foo' should
not raise an error suddenly in Emacs 28.  (IMHO.)

This backward-incompatible change will mean that
code such as that for the simple `foo' command will
need to bind that user option to non-nil (and binding
a user option is supposedly a no-no for vanilla Emacs).

> >> This means that more complex interactive specs
> >> need manual tagging using a new tag:
> >>   (declare (predicate (use-region-p)))
> >
> > But even that won't handle arbitrary `interactive'
> > sexps, right?
> 
> `declare' could use the same logic used in 
> `interactive' that detects region boundaries.

Nearly anything is possible, of course.  Once you
head down a rabbit hole like this you end up
fiddling to change/fix/adapt stuff left & right.

This ought to be a sign that we're headed in the
wrong direction.  (Yet another sign.)

> >> Same tag:
> >>   (declare (predicate (not buffer-read-only)))
> >
> > And what about commands that might be usable
> > interactively, but whose `interactive' spec
> > doesn't encapsulate all that's involved?  In that
> > case, manual addition of a declaration will need
> > to look into the logic of the command body as
> > well.  (Admittedly, such commands are uncommon.)
> 
> Yes, here it should share the same logic as well.

(Yet another sign.  Left & right...)

> >> Using a prefix arg for 'C-h f' and 'C-h v' to limit the list
> >> of completions would be nice.
> >>
> >> But I guess M-x can't use a prefix arg to limit completions?
> >
> > Why do you think so?  `C-u M-x describe-function TAB'
> > (with my definition from `help-fns+.el') shows only
> > commands as candidates.
> 
> The docstring of `execute-extended-command' says:
> 
>   To pass a prefix argument to the command you are invoking,
>   give a prefix argument to ‘execute-extended-command’.
> 
> And indeed `C-u M-x forward-char RET' moves 4 chars forwards.
> So you can't use `C-u M-x TAB' to limit the number of completions.
> Maybe then use another prefix like `C-x', i.e. `C-x M-x'?
> This is similar to how `C-x M-:' combines the prefix `C-x'
> to run `repeat-complex-command'.

1. The context here was using a prefix arg for `C-h f'
and `C-h v'.

2. I mentioned that _my_ version of `describe-function'
lets a prefix arg limit candidates to commands.

3. So `C-u M-x describe-function' limits candidates to
commands.

(Similarly for `C-h v'.)

Why are you changing the subject here to invocation of
non-`describe-*' commands with `M-x'?  What's the point?