Re: Delegating user-reserved key binding space definition to users

[John Yates <john@yates-sheets.org>]

On Mon, Nov 28, 2022 at 1:16 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > However, some major modes introduce new concepts.  For example, think
> > about paredit-forward-slurp-sexp, which can be an equivalent of Org's
> > heading promotion or moving word at point forward in sentences.  How
> > could you remap to group these 3 very different yet similar (for some
> > users) commands together?
>
> Great example, indeed, thanks.
>
> In this context, I'd like the package to be able to explain that this
> command is about a "sexp"-granularity operation and about
> "forward"-direction operation, so that the keybinding style may
> automatically find a natural/consistent key (or set of keys) to use for
> it depending on whether the current keybinding style uses f/b, or j/k,
> or left/right, or ... for forward/backward operations.

[I have followed this thread only intermittently.
Please forgive any repetition of things already said.]

I agree with Stefan, that is a wonderful example.

Objects:  We need a codified vocabulary.
* Display objects: char, line, column, window, . . .
* Text containers: file, buffer, register, . . .
* Text objects: char, word, sexp, sentence, . . .

How are tree-sitter provided objects accomodated?

Clearly this vocabulary would be drawn largely from
current usage.  Codification is necessary for the
proposed package to be able to reason about these
concepts.

When a package introduces a new object, its author
should be able make statements like:
* X is a new object
* Object X is most akin to but coexists with object Y
* Object X subsumes and eclipses object Y

Ordering: The available key sequences have a vague
partial order related to the number and ergonomics
of keystrokes involved.  This should be formalized.
A user should be able to weigh in on this partial order.

To aid in aligning the choices of bindings with the
preceding partial order we need to formalize partial
orders over objects that emacs users already intuit:
* char < (line | column) < window < frame < display
* char < word < (sexp | sentence) . . .

Verbs: Once you have objects you clearly need
imperative verbs.
* insert
* delete
* move
* transpose

Properties: The applicability of properties to verbs
needs to be defined.  My sense is that direction is
inapplicable to verbs such as:
* yank
* save