emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] : Re: command mode-specificity [was: scratch/command 064f


From: Stefan Monnier
Subject: Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]
Date: Wed, 17 Feb 2021 11:12:28 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> I think it would be good to try and clarify what should be the
>> criterion, and not in terms of "should be listed in M-x" since that
>> inherently depends on opinions, but rather in more technical terms that
>> depend on what the command does.
>> [ A bit like with docstrings: we like docstrings that say what the
>>   function does rather than when/where it's meant to be used.  ]
>>
>> Maybe something like "would inevitably signal an error"?
>
> I don't think there's any hard and fast criterion that can be used,
> though.

That's what I suspect also, but I think we need to try and "formalize"
this at least to the extent possible, so we can decide whether a given
problem is due to a tagging-error or to an incorrect expectation on the
side of the user of that tagging info.

> For instance, there was one mode I tagged up that had a
> `foo-quit' command, which just buried the buffer.  Now, that's a command
> that can work anywhere...  but the reason it exists is presumably
> because the person who wrote it either missed out on inheriting from
> `special-mode', or didn't know you can bind `bury-buffer' directly, or
> whatever.

I know exactly what you mean ;-)

[ BTW, the better course of action in those cases is of course to mark
  those commands obsolete and derive from special-mode (or at least to
  align the code&behavior as much as possible with that of
  special-mode).  ]

> Now, lots of commands do, indeed, signal an error outside the proper
> mode, or completely mess things up outside the proper mode, and those
> are no-brainers.
>
> I'd planned on writing a little essay for the lispref manual about this,
> once I'd gotten some more experience, because it's not immediately
> obvious what's the right thing to do until you've evaluated a few
> instances.

Great, looking forward to it.  BTW, I think you can already put
something in it and refine it later on; for the benefit of other people
who might want to help the tagging process.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]