From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Delegating user-reserved key binding space definition to users Date: Tue, 29 Nov 2022 06:54:17 -0500 Message-ID: References: <57b69c22e167d429d21bb969feb22887@webmail.orcon.net.nz> <877czikyfa.fsf@localhost> <87o7sthrwx.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17583"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ihor Radchenko , Psionic K , Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 29 12:55:19 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ozzCp-0004MJ-ET for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Nov 2022 12:55:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozzCB-00062W-Cz; Tue, 29 Nov 2022 06:54:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozzC6-00062K-WF for emacs-devel@gnu.org; Tue, 29 Nov 2022 06:54:35 -0500 Original-Received: from mail-ej1-f50.google.com ([209.85.218.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ozzC5-0000LF-78 for emacs-devel@gnu.org; Tue, 29 Nov 2022 06:54:34 -0500 Original-Received: by mail-ej1-f50.google.com with SMTP id fy37so33104210ejc.11 for ; Tue, 29 Nov 2022 03:54:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=D7k0cryVImBU95wyDzd4aYRvq10mze94OGO1zsCIJrE=; b=QL7GDsTaIX9upqnUO/JA6Qkfaw8XrUFbeHMoM975ncWdtPG02S6fItF5kXn4udauqq mOJyH+JWl9HqoF4vqkgGd1nlw41t0FnId13Rv40S9TdGZGDWjkcca9UnHJjTU6xq9PAA Aa2eda3krsAyi0GAQRfUWFoFtDdXnV+5fL/qk+/wPCiek/LJSR2nXp/ChGHXn3i0QNHK wE71F7GIhRARmXPXd76L3yrcz80YugJTaW8qhodVYbjWW1tqJUh/oC8VI7AYVMVUyIlw G8ERuXAeh3lkvUgM2ZTqePprdKCZmJxmuZ35WpYpp1p55BoZTo+1j6dtiKKQSu87EXBm vbKQ== X-Gm-Message-State: ANoB5pnxdwlqxg0af+D2KjquZoRsVXxRZQ23p8dsFKL2+dPJIgFU837R 8QTTxmQlzV424LsJZ4tf34ZaHEmG1FFM/YerFgE= X-Google-Smtp-Source: AA0mqf7Gq26p1CRuy3yACsOh6Cb+3jnjOxhfyY/SMZi14qzIvAwu7sIivKu6fOUV+4bii1EdQ7k5z5n++7PBu4BKQE0= X-Received: by 2002:a17:906:53d7:b0:7c0:934d:b5e6 with SMTP id p23-20020a17090653d700b007c0934db5e6mr448248ejo.769.1669722869832; Tue, 29 Nov 2022 03:54:29 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=209.85.218.50; envelope-from=john.yates.sheets@gmail.com; helo=mail-ej1-f50.google.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300709 Archived-At: On Mon, Nov 28, 2022 at 1:16 PM Stefan Monnier 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