Standardizing more key bindings?

Standardizing more key bindings?

[Thibaut Verron]

Dear all,

It was pointed out recently that one of the features of spacemacs and
the like offer is that key bindings are better standardized across
packages. The example given, I believe, was sending a region to the
REPL.

This kind of standardization is something that Emacs already does, for
some commands: we have indent-*-function, revert-buffer-function, for
instance, which make it easy to bind similar behaviours to the same
key across major modes.

For the REPL example, I guess it should be possible to split basic
functionality into some well-defined functions, and let packages
assign those functions? Like a comint-create-process-function, a
comint-send-region-function, a comint-send-buffer-function, etc.

It doesn't seem too complicated to implement, but it would require
precisely identifying the meaningful building blocks, and package
maintainers would have to refactor their code to make use of those
variables.

I seem to recall Stefan bringing up such a discussion a few years ago,
the goal then being to simplify setting up a comint buffer.

Another possibility would be to define variables for "preferred" key
bindings for some behaviours, so that packages would only have to bind
those if non nil. This is minimal work for the package maintainers,
and also easy to do by third party (fourth party?) packages or by the
user for packages which are no longer maintained.

But that would be a new concept for Emacs.

Both options can be tentatively implemented as a separate package
(similarly to no-litter).

What do you think?

Best,
Thibaut

Re: Standardizing more key bindings?

[Stefan Monnier]

> I seem to recall Stefan bringing up such a discussion a few years ago,
> the goal then being to simplify setting up a comint buffer.

FWIW, here's the code I have for that, written about 5 years ago and
never actually used, so take it with a large grain of salt.


        Stefan


;;; prog-proc.el --- Interacting from a source buffer with an inferior process  -*- lexical-binding:t -*-

;; Copyright (C) 2012  Free Software Foundation, Inc.

;; Author: (Stefan Monnier) <monnier@iro.umontreal.ca>

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;; Prog-Proc is a package designed to complement Comint: while Comint was
;; designed originally to handle the needs of inferior process buffers, such
;; as a buffer running a Scheme repl, Comint does not actually provide any
;; functionality that links this process buffer with some source code.
;;
;; That's where Prog-Proc comes into play: it provides the usual commands and
;; key-bindings that lets the user send his code to the underlying repl.

;;; Code:


(eval-when-compile (require 'cl-lib))
(require 'comint)
(require 'compile)

(defvar prog-proc-mode-map
  (let ((map (make-sparse-keymap)))
    (define-key map [?\C-c ?\C-l] 'prog-proc-load-file)
    (define-key map [?\C-c ?\C-c] 'prog-proc-compile)
    (define-key map [?\C-c ?\C-z] 'prog-proc-switch-to)
    (define-key map [?\C-c ?\C-r] 'prog-proc-send-region)
    (define-key map [?\C-c ?\C-b] 'prog-proc-send-buffer)
    ;; FIXME: Add
    ;; (define-key map [?\M-C-x] 'prog-proc-send-defun)
    ;; (define-key map [?\C-x ?\C-e] 'prog-proc-send-last-sexp)
    ;; FIXME: Add menu.  Now, that's trickier because keymap inheritance
    ;; doesn't play nicely with menus!
    map)
  "Keymap for `prog-proc-mode'.")

(defvar-local prog-proc--buffer nil
  "The inferior-process buffer to which to send code.")

(defmacro prog-proc-define-token (name &optional parent)
  ;; FIXME: This use of cl-defstruct ends up defining needlessly the
  ;; predicate, the constructor and their respective inliners.
  ;; `(progn
  ;;    (cl-defstruct (,name
  ;;                   (:predicate nil)
  ;;                   (:copier nil)
  ;;                   (:constructor nil)
  ;;                   (:constructor ,name)
  ;;                   ,@(when parent `((:include ,parent)))))
  ;;    (defconst ,name (,name)))
  (let ((tag-sym (intern (format "cl-struct-%S" name)))
        (children-sym (intern (format "cl-struct-%S-tags" name))))
    `(progn
       (defvar ,children-sym)
       (eval-and-compile
         (cl-struct-define ',name nil ',(or parent
                                            ;; FIXME: Make a "token" parent.
                                            'cl-structure-object)
                           nil nil '((cl-tag-slot)) ',children-sym ',tag-sym t))
       (defconst ,name (vector ',tag-sym)))))

(cl-defstruct (prog-proc-descriptor
            (:constructor prog-proc-make)
            (:predicate nil)
            (:copier nil))
  (name nil :read-only t)
  (run nil :read-only t)
  (load-cmd nil :read-only t)
  (chdir-cmd nil :read-only t)
  (command-eol "\n" :read-only t)
  (compile-commands-alist nil :read-only t))

(defvar prog-proc-descriptor nil
  "Struct containing the various functions to create a new process, ...")

(defmacro prog-proc--prop (prop)
  `(,(intern (format "prog-proc-descriptor-%s" prop))
    (or prog-proc-descriptor
        ;; FIXME: Look for available ones and pick one.
        (error "Not a `prog-proc' buffer"))))
(defmacro prog-proc--call (method &rest args)
  `(funcall (prog-proc--prop ,method) ,@args))

;; The inferior process and his buffer are basically interchangeable.
;; Currently the code takes prog-proc--buffer as the main reference,
;; but all users should either use prog-proc-proc or prog-proc-buffer
;; to find the info.

(defun prog-proc-proc ()
  "Return the inferior process for the code in current buffer."
  (or (and (buffer-live-p prog-proc--buffer)
           (get-buffer-process prog-proc--buffer))
      (when (derived-mode-p 'prog-proc-mode 'prog-proc-comint-mode)
        (setq prog-proc--buffer (current-buffer))
        (get-buffer-process prog-proc--buffer))
      (let ((ppd prog-proc-descriptor)
            (buf (prog-proc--call run)))
        (with-current-buffer buf
          (if (and ppd (null prog-proc-descriptor))
              (set (make-local-variable 'prog-proc-descriptor) ppd)))
        (setq prog-proc--buffer buf)
        (get-buffer-process prog-proc--buffer))))

(defun prog-proc-buffer ()
  "Return the buffer of the inferior process."
  (process-buffer (prog-proc-proc)))

(defun prog-proc-run-repl ()
  "Start the read-eval-print process, if it's not running yet."
  (interactive)
  (ignore (prog-proc-proc)))

(defun prog-proc-switch-to ()
  "Switch to the buffer running the read-eval-print process."
  (pop-to-buffer (prog-proc-buffer)))

(defun prog-proc-send-string (proc str)
  "Send command STR to PROC, with an EOL terminator appended."
  (with-current-buffer (process-buffer proc)
    ;; FIXME: comint-send-string does not pass the string through
    ;; comint-input-filter-function, so we have to do it by hand.
    ;; Maybe we should insert the command into the buffer and then call
    ;; comint-send-input?
    (prog-proc-comint-input-filter-function nil)
    (comint-send-string proc (concat str (prog-proc--prop command-eol)))))

(defun prog-proc-load-file (file &optional and-go)
  "Load FILE into the read-eval-print process.
FILE is the file visited by the current buffer.
If prefix argument AND-GO is used, then we additionally switch
to the buffer where the process is running."
  (interactive
   (list (or buffer-file-name
             (read-file-name "File to load: " nil nil t))
         current-prefix-arg))
  (comint-check-source file)
  (let ((proc (prog-proc-proc)))
    (prog-proc-send-string proc (prog-proc--call load-cmd file))
    (when and-go (pop-to-buffer (process-buffer proc)))))

(defvar prog-proc--tmp-file nil)

(defun prog-proc-send-region (start end &optional and-go)
  "Send the content of the region to the read-eval-print process.
START..END delimit the region; AND-GO if non-nil indicate to additionally
switch to the process's buffer."
  (interactive "r\nP")
  (if (> start end) (let ((tmp end)) (setq end start) (setq start tmp))
    (if (= start end) (error "Nothing to send: the region is empty")))
  (let ((proc (prog-proc-proc))
        (tmp (make-temp-file "emacs-region")))
    (write-region start end tmp nil 'silently)
    (when prog-proc--tmp-file
      (ignore-errors (delete-file (car prog-proc--tmp-file)))
      (set-marker (cdr prog-proc--tmp-file) nil))
    (setq prog-proc--tmp-file (cons tmp (copy-marker start)))
    (prog-proc-send-string proc (prog-proc--call load-cmd tmp))
    (when and-go (pop-to-buffer (process-buffer proc)))))

(defun prog-proc-send-buffer (&optional and-go)
  "Send the content of the current buffer to the read-eval-print process.
AND-GO if non-nil indicate to additionally switch to the process's buffer."
  (interactive "P")
  (prog-proc-send-region (point-min) (point-max) and-go))

(define-derived-mode prog-proc-mode prog-mode "Prog-Proc"
  "Major mode for editing source code and interact with an interactive loop."
  )

;;; Extended comint-mode for Prog-Proc.

(defun prog-proc-chdir (dir)
  "Change the working directory of the inferior process to DIR."
  (interactive "DChange to directory: ")
  (let ((dir (expand-file-name dir))
        (proc (prog-proc-proc)))
    (with-current-buffer (process-buffer proc)
      (prog-proc-send-string proc (prog-proc--call chdir-cmd dir))
      (setq default-directory (file-name-as-directory dir)))))

(defun prog-proc-comint-input-filter-function (str)
  ;; `compile.el' doesn't know that file location info from errors should be
  ;; recomputed afresh (without using stale info from earlier compilations).
  (compilation-forget-errors)       ;Has to run before compilation-fake-loc.
  (if (and prog-proc--tmp-file (marker-buffer (cdr prog-proc--tmp-file)))
      (compilation-fake-loc (cdr prog-proc--tmp-file)
                            (car prog-proc--tmp-file)))
  str)

(defvar prog-proc-comint-mode-map
  (let ((map (make-sparse-keymap)))
    (define-key map [?\C-c ?\C-r] 'prog-proc-run-repl)
    (define-key map [?\C-c ?\C-l] 'prog-proc-load-file)
    map))

(define-derived-mode prog-proc-comint-mode comint-mode "Prog-Proc-Comint"
  "Major mode for an inferior process used to run&compile source code."
  ;; Enable compilation-minor-mode, but only after the child mode is setup
  ;; since the child-mode might want to add rules to
  ;; compilation-error-regexp-alist.
  (add-hook 'after-change-major-mode-hook #'compilation-minor-mode nil t)
  ;; The keymap of compilation-minor-mode is too unbearable, so we
  ;; need to hide most of the bindings.
  (let ((map (make-sparse-keymap)))
    (dolist (keys '([menu-bar] [follow-link]))
      ;; Preserve some of the bindings.
      (define-key map keys (lookup-key compilation-minor-mode-map keys)))
    (add-to-list 'minor-mode-overriding-map-alist
                 (cons 'compilation-minor-mode map)))

  (add-hook 'comint-input-filter-functions
            #'prog-proc-comint-input-filter-function nil t))

(defvar prog-proc--compile-command nil
  "The command used by default by `prog-proc-compile'.")

(defun prog-proc-compile (command &optional and-go)
  "Pass COMMAND to the read-eval-loop process to compile the current file.

You can then use the command \\[next-error] to find the next error message
and move to the source code that caused it.

Interactively, prompts for the command if `compilation-read-command' is
non-nil.  With prefix arg, always prompts.

Prefix arg AND-GO also means to switch to the read-eval-loop buffer afterwards."
  (interactive
   (let* ((dir default-directory)
	  (cmd "cd \"."))
     ;; Look for files to determine the default command.
     (while (and (stringp dir)
                 (progn
                   (cl-dolist (cf (prog-proc--prop compile-commands-alist))
                     (when (file-exists-p (expand-file-name (cdr cf) dir))
                       (setq cmd (concat cmd "\"; " (car cf)))
                       (cl-return nil)))
                   (not cmd)))
       (let ((newdir (file-name-directory (directory-file-name dir))))
	 (setq dir (unless (equal newdir dir) newdir))
	 (setq cmd (concat cmd "/.."))))
     (setq cmd
	   (cond
	    ((local-variable-p 'prog-proc--compile-command)
             prog-proc--compile-command)
	    ((string-match "^\\s-*cd\\s-+\"\\.\"\\s-*;\\s-*" cmd)
	     (substring cmd (match-end 0)))
	    ((string-match "^\\s-*cd\\s-+\"\\(\\./\\)" cmd)
	     (replace-match "" t t cmd 1))
	    ((string-match ";" cmd) cmd)
	    (t prog-proc--compile-command)))
     ;; code taken from compile.el
     (list (if (or compilation-read-command current-prefix-arg)
               (read-from-minibuffer "Compile command: "
				     cmd nil nil '(compile-history . 1))
             cmd))))
     ;; ;; now look for command's file to determine the directory
     ;; (setq dir default-directory)
     ;; (while (and (stringp dir)
     ;; 	    (dolist (cf (prog-proc--prop compile-commands-alist) t)
     ;; 	      (when (and (equal cmd (car cf))
     ;; 			 (file-exists-p (expand-file-name (cdr cf) dir)))
     ;; 		(return nil))))
     ;;   (let ((newdir (file-name-directory (directory-file-name dir))))
     ;;     (setq dir (unless (equal newdir dir) newdir))))
     ;; (setq dir (or dir default-directory))
     ;; (list cmd dir)))
  (set (make-local-variable 'prog-proc--compile-command) command)
  (save-some-buffers (not compilation-ask-about-save) nil)
  (let ((dir default-directory))
    (when (string-match "^\\s-*cd\\s-+\"\\([^\"]+\\)\"\\s-*;" command)
      (setq dir (match-string 1 command))
      (setq command (replace-match "" t t command)))
    (setq dir (expand-file-name dir))
    (let ((proc (prog-proc-proc))
          (eol (prog-proc--prop command-eol)))
      (with-current-buffer (process-buffer proc)
        (setq default-directory dir)
        (prog-proc-send-string
         proc (concat (prog-proc--call chdir-cmd dir)
                      ;; Strip the newline, to avoid adding a prompt.
                      (if (string-match "\n\\'" eol)
                          (replace-match " " t t eol) eol)
                      command))
        (when and-go (pop-to-buffer (process-buffer proc)))))))


\f
(provide 'prog-proc)

;;; prog-proc.el ends here

Re: Standardizing more key bindings?

[yarnton--- via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

I was actually planning to post the same suggestion in the How to make Emacs popular again thread.

Emacs is a bit unfriendly, even to advanced users, in this regard. There are some de facto conventions about keybindings, especially in programming modes. Enforcing said conventions a bit more strictly, either with some written guidelines or programmatically, would be a great step forward.

As you have noted, Spacemacs and other customization layers do a good job at making the whole interface more consistent.


[-- Attachment #2: Type: text/html, Size: 723 bytes --]

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It was pointed out recently that one of the features of spacemacs and
  > the like offer is that key bindings are better standardized across
  > packages. The example given, I believe, was sending a region to the
  > REPL.

In principle, this is a good idea.  In practice, each specific case is
likely to have its own difficulties, larger or smaller.

It would be useful to look at whatever changes Emacs variants
have made.  Their choices may have been good ones.

  > The example given, I believe, was sending a region to the
  > REPL.

Would you be so kind as to post again the text that you're referring
to?  As far as I know, Emacs does not have such a command.  It has M-:
and C-x C-e.

Or... are you talking about languages other than Lisp?  Most of those
languages do not HAVE functions comparable to read, eval, and print.
They may have the ability to execute a program sent interactively
but the term REPL is not applicable to them.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Thibaut Verron]

>   > The example given, I believe, was sending a region to the
>   > REPL.
>
> Would you be so kind as to post again the text that you're referring
> to?  As far as I know, Emacs does not have such a command.  It has M-:
> and C-x C-e.

Assuming that you mean "does have", that's actually not what I have in
mind. For emacs lisp, the closest would be a command sending a region
to a IELM buffer and evaluating it. It is not the same as M-:, for
instance when it comes to acting on the selected buffer.

>
> Or... are you talking about languages other than Lisp?  Most of those
> languages do not HAVE functions comparable to read, eval, and print.
> They may have the ability to execute a program sent interactively
> but the term REPL is not applicable to them.

My terminology might be inexact. I'm thinking of the interactive
interfaces of software like Python, R, Caml, Shell...

My point is that currently there is no way of binding C-c C-e, C-c C-r
or whatever to "send this region to the process-interaction buffer".

Re: Standardizing more key bindings?

[Thibaut Verron]

Le lun. 28 sept. 2020 à 06:38, Thibaut Verron
<thibaut.verron@gmail.com> a écrit :
>
> >   > The example given, I believe, was sending a region to the
> >   > REPL.
> >
> > Would you be so kind as to post again the text that you're referring
> > to?  As far as I know, Emacs does not have such a command.  It has M-:
> > and C-x C-e.
>
> Assuming that you mean "does have", that's actually not what I have in
> mind. For emacs lisp, the closest would be a command sending a region
> to a IELM buffer and evaluating it. It is not the same as M-:, for
> instance when it comes to acting on the selected buffer.
>

I looked the original message up, the message ID is
<f4e5da8a-0460-0429-37ed-43db8c537203@protonmail.com> (is that the
string you can search for?).

My memory was off, the actual example was "start a REPL" and not "send
a region".

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I looked the original message up, the message ID is
  > <f4e5da8a-0460-0429-37ed-43db8c537203@protonmail.com> (is that the
  > string you can search for?).

Thaks.  I can search with grep for any text that is in the message in
my saved mail.


    Here are a few examples:
    - They have tried to create standard keybinding layouts, so that, for example, 
    "SPC m s" is generally the keybinding used to launch any programming language 
    REPL that has a corresponding layer. This sort of consistency is helpful to new

Thanks.  Now I think I understand in a general way what they did, and it
seems like a good idea in general.

But I don't see how a key sequence can possibly start with SPC.  How
could you tpe text?

The term "REPL" is inapplicable for most of these languages, since
they do not have anything comparable ton read, eval, or print.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Thibaut Verron]

> But I don't see how a key sequence can possibly start with SPC.  How
> could you tpe text?

Spacemacs uses vi-like bindings.


> The term "REPL" is inapplicable for most of these languages, since
> they do not have anything comparable ton read, eval, or print.

I don't understand. Don't all interactive interpreters read input,
evaluate it, then print the result?

Re: Standardizing more key bindings?

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

> I don't understand. Don't all interactive interpreters read input,
> evaluate it, then print the result?

Far from it.  Lua before version 5.3 used to only read and evaluate (you
had to add printing code for anything to be printed):

    $ lua5.2
    Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
    > 1 + 1
    stdin:1: unexpected symbol near '1'
    > print(1 + 1)
    2
    > 
    $ lua5.3 
    Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
    > 1 + 1
    2
    > print(1 + 1)
    2
    > 

A more serious problem is the conflation of reading and evaluation, Lisp
is unique in giving you easy access to the parse tree and representing
it using the same plain old data structures as all other Lisp code.

Even when it comes to the print part there are still languages limiting
how an arbitrary data structure is printed, if it's possible at all.
Some place limitations on whitespace control (for example mandatory
newlines), others do not allow you to print the object in a form that
can be read in again (for example by failing to print with escape
characters).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Standardizing more key bindings?

[Dmitry Gutov]

On 29.09.2020 06:30, Richard Stallman wrote:
> The term "REPL" is inapplicable for most of these languages, since
> they do not have anything comparable ton read, eval, or print.

It's useless to fight to reserve this term to Lisp: it has been solidly 
coined for similar programs in non-homoiconic languages as well for the 
last 10-20 years at least.

The languages in question might not have the same kind of 'read', but 
they usually have 'eval', and their REPLs do 'print'.

Re: Standardizing more key bindings?

[Dmitry Gutov]

On 27.09.2020 12:31, Thibaut Verron wrote:
> For the REPL example, I guess it should be possible to split basic
> functionality into some well-defined functions, and let packages
> assign those functions? Like a comint-create-process-function, a
> comint-send-region-function, a comint-send-buffer-function, etc.

I applaud this initiative, but one of the steps would be to define 
common bindings to use in all "inferior" (REPL) modes, and that is 
likely to conflict with existing bindings.

And that would require some backward-incompatible changes, which is 
always a hard sell around here.

Re: Standardizing more key bindings?

[Thibaut Verron]

Le mar. 29 sept. 2020 à 23:58, Dmitry Gutov <dgutov@yandex.ru> a écrit :
>
> On 27.09.2020 12:31, Thibaut Verron wrote:
> > For the REPL example, I guess it should be possible to split basic
> > functionality into some well-defined functions, and let packages
> > assign those functions? Like a comint-create-process-function, a
> > comint-send-region-function, a comint-send-buffer-function, etc.
>
> I applaud this initiative, but one of the steps would be to define
> common bindings to use in all "inferior" (REPL) modes, and that is
> likely to conflict with existing bindings.

It doesn't have to be in the global-map, it could be a minor mode
activated by those major-modes or users that want it.
And the keymap doesn't even have to be populated by default, I guess.

If python.el is refactored to use a new proc-send-buffer command, they
can still bind C-c C-c to that in python-mode-map, but a user who
prefers to use C-c C-b in all modes can bind C-c C-b in proc-mode-map.

Minor clarification: I'm not talking about the process buffers
themselves, but the normal edition buffers for the corresponding
language. E.g. emacs-lisp buffers, not IELM.

Opening Up More Keymaps Re: Standardizing more key bindings?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2155 bytes --]


Almost as courageous as Lars' request to change line-length limits
(hopefully not quite as controversial)

Perhaps it's time we opened up some additional keymaps so that we can
experiment with  keybindings without causing too much trouble for
long-term users.

Proposal:

1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
   suspends Emacs on the console.

   Perhaps turn C-z into a new prefix key, and bind the above commands
   to C-z z -- that gives us a whole new keymap to play with for the
   future.

   2. F2 is currently taken up by 2c (2column support) and perhaps it's
      time to recover that key, I suspect 2c is not as heavily used to
      justify a common key like F2, and it would still have C-x6
      dedicated to it if we take F2 away from it.

      
Thibaut Verron <thibaut.verron@gmail.com> writes:

> Le mar. 29 sept. 2020 ¨¤ 23:58, Dmitry Gutov <dgutov@yandex.ru> a ¨¦crit :
>>
>> On 27.09.2020 12:31, Thibaut Verron wrote:
>> > For the REPL example, I guess it should be possible to split basic
>> > functionality into some well-defined functions, and let packages
>> > assign those functions? Like a comint-create-process-function, a
>> > comint-send-region-function, a comint-send-buffer-function, etc.
>>
>> I applaud this initiative, but one of the steps would be to define
>> common bindings to use in all "inferior" (REPL) modes, and that is
>> likely to conflict with existing bindings.
>
> It doesn't have to be in the global-map, it could be a minor mode
> activated by those major-modes or users that want it.
> And the keymap doesn't even have to be populated by default, I guess.
>
> If python.el is refactored to use a new proc-send-buffer command, they
> can still bind C-c C-c to that in python-mode-map, but a user who
> prefers to use C-c C-b in all modes can bind C-c C-b in proc-mode-map.
>
> Minor clarification: I'm not talking about the process buffers
> themselves, but the normal edition buffers for the corresponding
> language. E.g. emacs-lisp buffers, not IELM.
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

Le mer. 30 sept. 2020 à 18:58, T.V Raman <raman@google.com> a écrit :
>
>
> Almost as courageous as Lars' request to change line-length limits
> (hopefully not quite as controversial)
>
> Perhaps it's time we opened up some additional keymaps so that we can
> experiment with  keybindings without causing too much trouble for
> long-term users.

I don't understand the purpose. Would those new keymaps be for temporary,
experimental, bindings, to be later moved to a better position? Or would
they be meant to be eventually used by default?

>
> Proposal:
>
> 1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
>    suspends Emacs on the console.
>
>    Perhaps turn C-z into a new prefix key, and bind the above commands
>    to C-z z -- that gives us a whole new keymap to play with for the
>    future.

I personally like to have C-z free. I use it when I need to pass keypresses
to applications without caring about Emacs missing them. For instance my
Screen prefix key is C-z. Suspend-frame is bound to C-x C-z (which makes
sense to me with the other C-x bindings). So I would immediately undo such
a change in my configuration.

More importantly, C-z suspending the terminal application is a common
binding. One could argue that we have enough trouble with non-standard
bindings in Emacs not to add more now.

Maybe this behaviour could be preserved in non-GUI interfaces and the
(hypothetical) C-z key reserved for commands which only make sense in a
graphical setting? I cannot think of a single such command at the moment,
though.

>
>    2. F2 is currently taken up by 2c (2column support) and perhaps it's
>       time to recover that key, I suspect 2c is not as heavily used to
>       justify a common key like F2, and it would still have C-x6
>       dedicated to it if we take F2 away from it.
>

I just tried <f2>-s to see what it is about, now my Emacs is frozen (100%
CPU). As far as I'm concerned this key can (and will) die tomorrow. :)

[-- Attachment #2: Type: text/html, Size: 2417 bytes --]

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Robert Pluim]

>>>>> On Wed, 30 Sep 2020 19:29:12 +0200, Thibaut Verron <thibaut.verron@gmail.com> said:

    Thibaut> Le mer. 30 sept. 2020 à 18:58, T.V Raman <raman@google.com> a écrit :
    >> 
    >> 
    >> Almost as courageous as Lars' request to change line-length limits
    >> (hopefully not quite as controversial)
    >> 
    >> Perhaps it's time we opened up some additional keymaps so that we can
    >> experiment with  keybindings without causing too much trouble for
    >> long-term users.

    Thibaut> I don't understand the purpose. Would those new keymaps be for temporary,
    Thibaut> experimental, bindings, to be later moved to a better position? Or would
    Thibaut> they be meant to be eventually used by default?

This is an important question that needs an answer.

    >> 
    >> Proposal:
    >> 
    >> 1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
    >> suspends Emacs on the console.
    >> 
    >> Perhaps turn C-z into a new prefix key, and bind the above commands
    >> to C-z z -- that gives us a whole new keymap to play with for the
    >> future.

    Thibaut> I personally like to have C-z free. I use it when I need to pass keypresses
    Thibaut> to applications without caring about Emacs missing them. For instance my
    Thibaut> Screen prefix key is C-z. Suspend-frame is bound to C-x C-z (which makes
    Thibaut> sense to me with the other C-x bindings). So I would immediately undo such
    Thibaut> a change in my configuration.

As would I, but for a different reason: I put CTRL under my left
thumb, so C-z is a very convenient prefix for stuff I do all the time.

    Thibaut> More importantly, C-z suspending the terminal application is a common
    Thibaut> binding. One could argue that we have enough trouble with non-standard
    Thibaut> bindings in Emacs not to add more now.

    Thibaut> Maybe this behaviour could be preserved in non-GUI interfaces and the
    Thibaut> (hypothetical) C-z key reserved for commands which only make sense in a
    Thibaut> graphical setting? I cannot think of a single such command at the moment,
    Thibaut> though.

I strongly dislike differences in keybindings between gui and
non-gui. Just look at all the questions that come up about org-mode
because some of its commonly used keybindings donʼt work in a terminal.
    >> 
    >> 2. F2 is currently taken up by 2c (2column support) and perhaps it's
    >> time to recover that key, I suspect 2c is not as heavily used to
    >> justify a common key like F2, and it would still have C-x6
    >> dedicated to it if we take F2 away from it.
    >> 

    Thibaut> I just tried <f2>-s to see what it is about, now my Emacs is frozen (100%
    Thibaut> CPU). As far as I'm concerned this key can (and will) die tomorrow. :)

Iʼve never used two column mode, it would be nice to have F2 bound to
some useful functions. Iʼm not sure what TV had in mind here.

Robert
-- 

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Stefan Monnier]

> 1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
>    suspends Emacs on the console.

Then again, `C-z` is a standard binding for `undo`.  ;-)

>    Perhaps turn C-z into a new prefix key, and bind the above commands
>    to C-z z -- that gives us a whole new keymap to play with for the
>    future.

It's true that there's some logic to use C-z, C-x, and C-c for standard
prefix keys.  Yet, I think this can only make sense if we have a clear
idea of what kinds of bindings we'd put into this prefix.

>    2. F2 is currently taken up by 2c (2column support) and perhaps it's
>       time to recover that key, I suspect 2c is not as heavily used to
>       justify a common key like F2, and it would still have C-x 6
>       dedicated to it if we take F2 away from it.

I agree that the binding of `f2` to `2C-command` can be dropped.
Not sure what to bind it to instead, OTOH.


        Stefan

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[T.V Raman]

Since keybindings are  a strong emotional issue, I was hoping to
divide and conquer the problem, i.e. first free up a new prefix key,
then experiment  by putting a set of related commands on that key --
rather than chasing our tails with arguments over which key to start with.
Stefan Monnier writes:
 > > 1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
 > >    suspends Emacs on the console.
 > 
 > Then again, `C-z` is a standard binding for `undo`.  ;-)
 > 
 > >    Perhaps turn C-z into a new prefix key, and bind the above commands
 > >    to C-z z -- that gives us a whole new keymap to play with for the
 > >    future.
 > 
 > It's true that there's some logic to use C-z, C-x, and C-c for standard
 > prefix keys.  Yet, I think this can only make sense if we have a clear
 > idea of what kinds of bindings we'd put into this prefix.
 > 
 > >    2. F2 is currently taken up by 2c (2column support) and perhaps it's
 > >       time to recover that key, I suspect 2c is not as heavily used to
 > >       justify a common key like F2, and it would still have C-x 6
 > >       dedicated to it if we take F2 away from it.
 > 
 > I agree that the binding of `f2` to `2C-command` can be dropped.
 > Not sure what to bind it to instead, OTOH.
 > 
 > 
 >         Stefan

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Robert Pluim]

>>>>> On Wed, 30 Sep 2020 11:35:35 -0700, "T.V Raman" <raman@google.com> said:

    TVR> Since keybindings are  a strong emotional issue, I was hoping to
    TVR> divide and conquer the problem, i.e. first free up a new prefix key,
    TVR> then experiment  by putting a set of related commands on that key --
    TVR> rather than chasing our tails with arguments over which key
    TVR> to start with.

I think F2 is fair game. C-z not so much

Robert
-- 

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Stefan Monnier]

> Since keybindings are  a strong emotional issue, I was hoping to
> divide and conquer the problem, i.e. first free up a new prefix key,
> then experiment  by putting a set of related commands on that key --
> rather than chasing our tails with arguments over which key to start with.

I think `C-z` is fair game in GUI but freeing it up for other uses in tty
mode will be a very hard sell.  This leaves it as "free for GUI-only
bindings" which makes it much less useful than a true "free prefix keymap".


        Stefan


> Stefan Monnier writes:
>  > > 1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
>  > >    suspends Emacs on the console.
>  > 
>  > Then again, `C-z` is a standard binding for `undo`.  ;-)
>  > 
>  > >    Perhaps turn C-z into a new prefix key, and bind the above commands
>  > >    to C-z z -- that gives us a whole new keymap to play with for the
>  > >    future.
>  > 
>  > It's true that there's some logic to use C-z, C-x, and C-c for standard
>  > prefix keys.  Yet, I think this can only make sense if we have a clear
>  > idea of what kinds of bindings we'd put into this prefix.
>  > 
>  > >    2. F2 is currently taken up by 2c (2column support) and perhaps it's
>  > >       time to recover that key, I suspect 2c is not as heavily used to
>  > >       justify a common key like F2, and it would still have C-x 6
>  > >       dedicated to it if we take F2 away from it.
>  > 
>  > I agree that the binding of `f2` to `2C-command` can be dropped.
>  > Not sure what to bind it to instead, OTOH.
>  > 
>  > 
>  >         Stefan
>
> -- 
> ♉Id: kg:/m/0285kf1  🦮♉

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[T.V Raman]

that's an interesting perspective.  Am surprized that you feel tty
users would find C-z z significantly harder than just C-z as the key
to suspend Emacs.


Stefan Monnier writes:
 > > Since keybindings are  a strong emotional issue, I was hoping to
 > > divide and conquer the problem, i.e. first free up a new prefix key,
 > > then experiment  by putting a set of related commands on that key --
 > > rather than chasing our tails with arguments over which key to start with.
 > 
 > I think `C-z` is fair game in GUI but freeing it up for other uses in tty
 > mode will be a very hard sell.  This leaves it as "free for GUI-only
 > bindings" which makes it much less useful than a true "free prefix keymap".
 > 
 > 
 >         Stefan
 > 
 > 
 > > Stefan Monnier writes:
 > >  > > 1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
 > >  > >    suspends Emacs on the console.
 > >  > 
 > >  > Then again, `C-z` is a standard binding for `undo`.  ;-)
 > >  > 
 > >  > >    Perhaps turn C-z into a new prefix key, and bind the above commands
 > >  > >    to C-z z -- that gives us a whole new keymap to play with for the
 > >  > >    future.
 > >  > 
 > >  > It's true that there's some logic to use C-z, C-x, and C-c for standard
 > >  > prefix keys.  Yet, I think this can only make sense if we have a clear
 > >  > idea of what kinds of bindings we'd put into this prefix.
 > >  > 
 > >  > >    2. F2 is currently taken up by 2c (2column support) and perhaps it's
 > >  > >       time to recover that key, I suspect 2c is not as heavily used to
 > >  > >       justify a common key like F2, and it would still have C-x 6
 > >  > >       dedicated to it if we take F2 away from it.
 > >  > 
 > >  > I agree that the binding of `f2` to `2C-command` can be dropped.
 > >  > Not sure what to bind it to instead, OTOH.
 > >  > 
 > >  > 
 > >  >         Stefan
 > >
 > > -- 
 > > ♉Id: kg:/m/0285kf1  🦮♉

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Noam Postavsky]

On Wed, 30 Sep 2020 at 15:58, T.V Raman <raman@google.com> wrote:

> that's an interesting perspective.  Am surprized that you feel tty
> users would find C-z z significantly harder than just C-z as the key
> to suspend Emacs.

C-x C-z is already bound to suspend, works fine in tty (and is easier
than C-z z, IMO).

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[T.V Raman]

:-) I was merely proposing C-z z for suspend to make up for taking
away C-z Noam Postavsky writes:
 > On Wed, 30 Sep 2020 at 15:58, T.V Raman <raman@google.com> wrote:
 > 
 > > that's an interesting perspective.  Am surprized that you feel tty
 > > users would find C-z z significantly harder than just C-z as the key
 > > to suspend Emacs.
 > 
 > C-x C-z is already bound to suspend, works fine in tty (and is easier
 > than C-z z, IMO).

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Stefan Monnier]

> that's an interesting perspective.  Am surprized that you feel tty
> users would find C-z z significantly harder than just C-z as the key
> to suspend Emacs.

I assume tty users have "C-z to suspend" hardwired in their fingers and
would be quite surprised if any application decides to use another
binding for it.


        Stefan


> Stefan Monnier writes:
>  > > Since keybindings are  a strong emotional issue, I was hoping to
>  > > divide and conquer the problem, i.e. first free up a new prefix key,
>  > > then experiment  by putting a set of related commands on that key --
>  > > rather than chasing our tails with arguments over which key to start with.
>  > 
>  > I think `C-z` is fair game in GUI but freeing it up for other uses in tty
>  > mode will be a very hard sell.  This leaves it as "free for GUI-only
>  > bindings" which makes it much less useful than a true "free prefix keymap".
>  > 
>  > 
>  >         Stefan
>  > 
>  > 
>  > > Stefan Monnier writes:
>  > >  > > 1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
>  > >  > >    suspends Emacs on the console.
>  > >  > 
>  > >  > Then again, `C-z` is a standard binding for `undo`.  ;-)
>  > >  > 
>  > >  > >    Perhaps turn C-z into a new prefix key, and bind the above commands
>  > >  > >    to C-z z -- that gives us a whole new keymap to play with for the
>  > >  > >    future.
>  > >  > 
>  > >  > It's true that there's some logic to use C-z, C-x, and C-c for standard
>  > >  > prefix keys.  Yet, I think this can only make sense if we have a clear
>  > >  > idea of what kinds of bindings we'd put into this prefix.
>  > >  > 
>  > >  > >    2. F2 is currently taken up by 2c (2column support) and perhaps it's
>  > >  > >       time to recover that key, I suspect 2c is not as heavily used to
>  > >  > >       justify a common key like F2, and it would still have C-x 6
>  > >  > >       dedicated to it if we take F2 away from it.
>  > >  > 
>  > >  > I agree that the binding of `f2` to `2C-command` can be dropped.
>  > >  > Not sure what to bind it to instead, OTOH.
>  > >  > 
>  > >  > 
>  > >  >         Stefan
>  > >
>  > > -- 
>  > > ♉Id: kg:/m/0285kf1  🦮♉
>
> -- 
> ♉Id: kg:/m/0285kf1  🦮♉

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[T.V Raman]

I can relate to the muscle memory, but was hoping that emacs 28
feature of echoing partial key-sequences would help.
The fact remains that keyboards are not getting any more keys any time
soon, and given that existing prefix keys are already used in one way
or another, we dont have much wiggleroom.

Anyway, time to move on, just keep this around as an idea for
experimentation if we ever get around to a  set of related commands,
eg, for programming environments etc 


Stefan Monnier writes:
 > > that's an interesting perspective.  Am surprized that you feel tty
 > > users would find C-z z significantly harder than just C-z as the key
 > > to suspend Emacs.
 > 
 > I assume tty users have "C-z to suspend" hardwired in their fingers and
 > would be quite surprised if any application decides to use another
 > binding for it.
 > 
 > 
 >         Stefan
 > 
 > 
 > > Stefan Monnier writes:
 > >  > > Since keybindings are  a strong emotional issue, I was hoping to
 > >  > > divide and conquer the problem, i.e. first free up a new prefix key,
 > >  > > then experiment  by putting a set of related commands on that key --
 > >  > > rather than chasing our tails with arguments over which key to start with.
 > >  > 
 > >  > I think `C-z` is fair game in GUI but freeing it up for other uses in tty
 > >  > mode will be a very hard sell.  This leaves it as "free for GUI-only
 > >  > bindings" which makes it much less useful than a true "free prefix keymap".
 > >  > 
 > >  > 
 > >  >         Stefan
 > >  > 
 > >  > 
 > >  > > Stefan Monnier writes:
 > >  > >  > > 1. C-z as a prefix --- at present c-z   runs suspend-frame under X, and
 > >  > >  > >    suspends Emacs on the console.
 > >  > >  > 
 > >  > >  > Then again, `C-z` is a standard binding for `undo`.  ;-)
 > >  > >  > 
 > >  > >  > >    Perhaps turn C-z into a new prefix key, and bind the above commands
 > >  > >  > >    to C-z z -- that gives us a whole new keymap to play with for the
 > >  > >  > >    future.
 > >  > >  > 
 > >  > >  > It's true that there's some logic to use C-z, C-x, and C-c for standard
 > >  > >  > prefix keys.  Yet, I think this can only make sense if we have a clear
 > >  > >  > idea of what kinds of bindings we'd put into this prefix.
 > >  > >  > 
 > >  > >  > >    2. F2 is currently taken up by 2c (2column support) and perhaps it's
 > >  > >  > >       time to recover that key, I suspect 2c is not as heavily used to
 > >  > >  > >       justify a common key like F2, and it would still have C-x 6
 > >  > >  > >       dedicated to it if we take F2 away from it.
 > >  > >  > 
 > >  > >  > I agree that the binding of `f2` to `2C-command` can be dropped.
 > >  > >  > Not sure what to bind it to instead, OTOH.
 > >  > >  > 
 > >  > >  > 
 > >  > >  >         Stefan
 > >  > >
 > >  > > -- 
 > >  > > ♉Id: kg:/m/0285kf1  🦮♉
 > >
 > > -- 
 > > ♉Id: kg:/m/0285kf1  🦮♉

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[chad]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

FWIW, a few weeks back I proposed changing C-z away from suspend-frame for
a similar goal, and got generally negative feedback about gui versus
terminal differences. The proposal also involved C-S-z, which doesn't work
in some terminal environments, so that probably skewed feedback somewhat.

From experience, I've been rebinding C-z (to a keymap) for around 30 years
now, and stopped having any trouble with it around 27 years ago. (At the
time, I would frequently use both hardware terminals, especially vt-100,
vt-101, and vt-220's, and sometimes DOS or OS/9 systems with serial
modems.)

In practical terms, I suspect the conflict between "C-z is SIGSTOP" and
"C-z is undo" is the biggest fault line between "typical personal computer
users" and "unix-ish users", and thus is effectively a "third rail" of
Emacs HCI discussions. That might just be pessimistic assumptions talking,
though.

~Chad

[-- Attachment #2: Type: text/html, Size: 1096 bytes --]

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Gregory Heytings via Emacs development discussions.]

>> that's an interesting perspective.  Am surprized that you feel tty 
>> users would find C-z z significantly harder than just C-z as the key to 
>> suspend Emacs.
>
> I assume tty users have "C-z to suspend" hardwired in their fingers and 
> would be quite surprised if any application decides to use another 
> binding for it.
>

That's correct, except if that application uses C-z C-z to suspend. 
Repeating a key until it produces the expected effect is also something 
tty users are used to do.  For example repeating C-c until the program 
aborts.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Stefan Monnier]

>>> that's an interesting perspective.  Am surprized that you feel tty users
>>> would find C-z z significantly harder than just C-z as the key to
>>> suspend Emacs.
>> I assume tty users have "C-z to suspend" hardwired in their fingers and
>> would be quite surprised if any application decides to use another binding
>> for it.
> That's correct, except if that application uses C-z C-z to
> suspend.  Repeating a key until it produces the expected effect is also
> something tty users are used to do.  For example repeating C-c until the
> program aborts.

Very good point, there are cases where `C-z` needs to be repeated
(e.g. to suspend editing a commit message in "Zile launched by Git" ;-)

I usually consider those as bugs, but it does make `C-z C-z` into
a viable option.  Obviously, not a good option if you want to bind `C-z`
to `undo` but viable if you want to use `C-z` for a new keymap ;-)


        Stefan

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1574 bytes --]

chad <yandros@gmail.com> writes:


that's a good perspective, especially it comes with the test of time.
Also, for a tty-user, it's  interesting to think of the conditions under
which you would suspend emacs. I suspect it happens less and less,
since:
1. Linux TTY has multiple VCs,
   2. Linux TTY users who are using Emacs have the option of running
      with a terminal multiplexer like screen and friends,

      the above likely reduce how often you might hit C-z to suspend
      emacs so you can use your TTY for something else.

> FWIW, a few weeks back I proposed changing C-z away from suspend-frame
> for a similar goal, and got generally negative feedback about gui
> versus terminal differences. The proposal also involved C-S-z, which
> doesn't work in some terminal environments, so that probably skewed
> feedback somewhat.
>
> From experience, I've been rebinding C-z (to a keymap) for around 30
> years now, and stopped having any trouble with it around 27 years ago.
> (At the time, I would frequently use both hardware terminals,
> especially vt-100, vt-101, and vt-220's, and sometimes DOS or OS/9
> systems with serial modems.) 
>
> In practical terms, I suspect the conflict between "C-z is SIGSTOP"
> and "C-z is undo" is the biggest fault line between "typical personal
> computer users" and "unix-ish users", and thus is effectively a "third
> rail" of Emacs HCI discussions. That might just be pessimistic
> assumptions talking, though.
>
> ~Chad
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1391 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Splitting the discussion into "free up C-z" and "what shall we use it
for if available" is a good recipe in general to avoid deadlock.

In general I step back to saying emacs needs more keys --- 20 years ago
when I mostly never used a laptop as often, I even considered getting a
foot-pedal.


>>>> that's an interesting perspective.  Am surprized that you feel tty users
>>>> would find C-z z significantly harder than just C-z as the key to
>>>> suspend Emacs.
>>> I assume tty users have "C-z to suspend" hardwired in their fingers and
>>> would be quite surprised if any application decides to use another binding
>>> for it.
>> That's correct, except if that application uses C-z C-z to
>> suspend.  Repeating a key until it produces the expected effect is also
>> something tty users are used to do.  For example repeating C-c until the
>> program aborts.
>
> Very good point, there are cases where `C-z` needs to be repeated
> (e.g. to suspend editing a commit message in "Zile launched by Git" ;-)
>
> I usually consider those as bugs, but it does make `C-z C-z` into
> a viable option.  Obviously, not a good option if you want to bind `C-z`
> to `undo` but viable if you want to use `C-z` for a new keymap ;-)
>
>
>         Stefan
>
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Stefan Monnier]

> In general I step back to saying emacs needs more keys --- 20 years ago
> when I mostly never used a laptop as often, I even considered getting a
> foot-pedal.

FWIW, all my keyboards have plenty of keys to provide free modifiers
(super/hyper).


        Stefan

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[T.V Raman]

I too have C-; C-' and C-, as prefix keys, but I've used them all --

Stefan Monnier writes:
 > > In general I step back to saying emacs needs more keys --- 20 years ago
 > > when I mostly never used a laptop as often, I even considered getting a
 > > foot-pedal.
 > 
 > FWIW, all my keyboards have plenty of keys to provide free modifiers
 > (super/hyper).
 > 
 > 
 >         Stefan

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 30 Sep 2020 16:45:31 -0400
> Cc: emacs-devel@gnu.org, thibaut.verron@gmail.com, dgutov@yandex.ru
> 
> > that's an interesting perspective.  Am surprized that you feel tty
> > users would find C-z z significantly harder than just C-z as the key
> > to suspend Emacs.
> 
> I assume tty users have "C-z to suspend" hardwired in their fingers and
> would be quite surprised if any application decides to use another
> binding for it.

Do they?  Perhaps we should have a survey.  FWIW, I use "C-x C-z" for
that since about forever (I need "C-z" for something much more useful
and frequent).

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Stefan Monnier]

>> > that's an interesting perspective.  Am surprized that you feel tty
>> > users would find C-z z significantly harder than just C-z as the key
>> > to suspend Emacs.
>> I assume tty users have "C-z to suspend" hardwired in their fingers and
>> would be quite surprised if any application decides to use another
>> binding for it.
> Do they?  Perhaps we should have a survey.  FWIW, I use "C-x C-z" for
> that since about forever (I need "C-z" for something much more useful
> and frequent).

In my case, the reason I have it "hardwired" is because most
applications don't offer any option to customize it, so I only get to
choose between `C-z` and `C-z`.

Any other choice in Emacs makes Emacs stand out as the odd guy (tho, it
is true that there are some exceptions for programs like `tmux` or
`mosh`).


        Stefan

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > But I don't see how a key sequence can possibly start with SPC.  How
  > > could you tpe text?

  > Spacemacs uses vi-like bindings.

That is so far away from Emacs that it is hardly relevant to Emacs.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Thibaut Verron]

>   > Spacemacs uses vi-like bindings.
>
> That is so far away from Emacs that it is hardly relevant to Emacs.

I agree. More generally, the specific binding that they chose for that
command (or set of commands) is not relevant to the discussion.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Ergus]

This thread is totally sacrilegious.. changing C-z to something really
useful?! Heresy in the Emacs church!... I am totally in favor!!!

For the fist step (release C-z)

I see 2 main proposals:
C-x C-z : which is already there

C-z C-z : which will not fight with the user's muscular memory (as we
repeat commands when they don't work the first time). But will require
to be careful with what other commands we add later in the C-z map.

At this point I would say (as a terminal exclusive user) that I don't
care any of those because I already use C-z C-z for that since the
beginning. (Actually C-z C-z C-z because I have tmux prefix also in
C-z).

For new users they have more C-z as undo in their muscular memory... so
I have experienced that they get very confused when C-z makes the window
disappear or closes emacs. Some of them think that emacs just failed and
open a new one.

At this point one of the admins should make a decision and do the change
because there will be not more agreement than this (I think that this is
the higher democratic limit ever reached in an agreement about a
changing default binding here.)

About F2 I don't really think will bother many people as there is an
alternative `C-x 6` since ever.

So please, admins, Close this with a decision from your side and we can
continue with something else. (Otherwise this will be forgotten in few
days)

Best,
Ergus

On Thu, Oct 01, 2020 at 05:35:20AM +0300, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Wed, 30 Sep 2020 16:45:31 -0400
>> Cc: emacs-devel@gnu.org, thibaut.verron@gmail.com, dgutov@yandex.ru
>>
>> > that's an interesting perspective.  Am surprized that you feel tty
>> > users would find C-z z significantly harder than just C-z as the key
>> > to suspend Emacs.
>>
>> I assume tty users have "C-z to suspend" hardwired in their fingers and
>> would be quite surprised if any application decides to use another
>> binding for it.
>
>Do they?  Perhaps we should have a survey.  FWIW, I use "C-x C-z" for
>that since about forever (I need "C-z" for something much more useful
>and frequent).
>

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> For new users they have more C-z as undo in their muscular memory... so
> I have experienced that they get very confused when C-z makes the window
> disappear or closes emacs. Some of them think that emacs just failed and
> open a new one.

There is a trade-off between being weird to hard core terminal users in
this case, and being weird to the rest of the world.  IMO, undo is by
far the best default for C-z.

> About F2 I don't really think will bother many people as there is an
> alternative `C-x 6` since ever.

Fully agreed.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Caio Henrique]

Stefan Kangas <stefankangas@gmail.com> writes:

> There is a trade-off between being weird to hard core terminal users in
> this case, and being weird to the rest of the world.  IMO, undo is by
> far the best default for C-z.

Maybe we could compromise, i.e. if terminal: C-z C-z -> suspend-frame ;
if GUI: C-z C-z -> undo? 

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I applaud this initiative, but one of the steps would be to define
  > > common bindings to use in all "inferior" (REPL) modes,

That is a good idea, but please let's call them "interpreter modes",
to avoid misleading implications about how these languages work.

  > It doesn't have to be in the global-map, it could be a minor mode
  > activated by those major-modes or users that want it.

The first question is, should thee bindings be conceptually global?
I don't think so.

To make them global means they conflict with a lot more other bindings,
and that makes the task of choosing these bindings harder.
It also means that the change would be a bigger incompatibility.

Thus, I think we should plan on having these bindings only
in the major modes that involve talking to an intepreter.

How to _implement_ these bindings is another question.
The easy way is for each major modes to establish the bindings
in its major mode map.  That is simple and coherent with
the rest of Emacs.

The idea of having one single keymap to implement them presumes that
any given binding is implemented by the same command in all these modes.
Is that true?  I doubt it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

C-z is the normal character to suspend any program, under the shell.
Emacs is unusual in that it detects C-z by hand and suspends itself.
For most programs, C-z generats SIGTSTP to suspend the process.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

C-z suspends most programs, running under a login shell.
It should suspend Emacs too.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Thibaut Verron]

> To make them global means they conflict with a lot more other bindings,
> and that makes the task of choosing these bindings harder.
> It also means that the change would be a bigger incompatibility.

I don't suggest that we choose bindings. The question is can we have
infrastructure making is easy for users (or starter kit developers,
etc) to set such bindings across modes.

> The first question is, should thee bindings be conceptually global?
> I don't think so.
> (...)
> Thus, I think we should plan on having these bindings only
> in the major modes that involve talking to an intepreter.

Yes, definitely.

> How to _implement_ these bindings is another question.
> The easy way is for each major modes to establish the bindings
> in its major mode map.  That is simple and coherent with
> the rest of Emacs.

But today, it typically results in different bindings, and rebinding,
if wanted, has to be done in each of the modes.

> The idea of having one single keymap to implement them presumes that
> any given binding is implemented by the same command in all these modes.
> Is that true?  I doubt it.

That is one possibility suggested in my original message. To have one
single entry point for those commands, which then calls functions
defined by the mode, similar to how indentation works.

Re: Standardizing more key bindings?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 01 Oct 2020 23:45:29 -0400
> Cc: emacs-devel@gnu.org, dgutov@yandex.ru
> 
> The first question is, should thee bindings be conceptually global?
> I don't think so.
> 
> To make them global means they conflict with a lot more other bindings,
> and that makes the task of choosing these bindings harder.
> It also means that the change would be a bigger incompatibility.
> 
> Thus, I think we should plan on having these bindings only
> in the major modes that involve talking to an intepreter.

They could also be defined by prog-mode, which is (or should be) the
parent of all programming modes.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, dgutov@yandex.ru,
> 	thibaut.verron@gmail.com, raman@google.com
> Date: Thu, 01 Oct 2020 23:49:10 -0400
> 
> C-z is the normal character to suspend any program, under the shell.
> Emacs is unusual in that it detects C-z by hand and suspends itself.
> For most programs, C-z generats SIGTSTP to suspend the process.

I understand.  However, suspending Emacs is a very infrequent
operation these days, what with most everyone working in a windowed
environment.  And OTOH there are some very frequently-used commands
that can be conveniently bound to C-z; suspending is still possible
with C-x C-z.

That said, I'm not necessarily arguing to unbind C-z or rebind it by
default, I'm just explaining why I did that myself, long time ago.  I
assume there are others like me.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Ergus]

On Thu, Oct 01, 2020 at 11:54:16PM -0400, Richard Stallman wrote:
>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>[[[ whether defending the US Constitution against all enemies,     ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>C-z suspends most programs, running under a login shell.
>It should suspend Emacs too.
>
I agree with this conceptually. But this is more a desperate measure due
to the lack of bindings. Also there are some programs that don't use C-z;
as Stefan mentioned on yesterday.

To be not so disruptive that's why I think that C-z C-z is the most
conservative alternative.

>-- 
>Dr Richard Stallman
>Chief GNUisance of the GNU Project (https://gnu.org)
>Founder, Free Software Foundation (https://fsf.org)
>Internet Hall-of-Famer (https://internethalloffame.org)
>
>

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Ergus]

On Fri, Oct 02, 2020 at 09:56:39AM +0300, Eli Zaretskii wrote:
>> From: Richard Stallman <rms@gnu.org>
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, dgutov@yandex.ru,
>> 	thibaut.verron@gmail.com, raman@google.com
>> Date: Thu, 01 Oct 2020 23:49:10 -0400
>>
>> C-z is the normal character to suspend any program, under the shell.
>> Emacs is unusual in that it detects C-z by hand and suspends itself.
>> For most programs, C-z generats SIGTSTP to suspend the process.
>
>I understand.  However, suspending Emacs is a very infrequent
>operation these days, what with most everyone working in a windowed
>environment.  And OTOH there are some very frequently-used commands
>that can be conveniently bound to C-z; suspending is still possible
>with C-x C-z.
>
>That said, I'm not necessarily arguing to unbind C-z or rebind it by
>default, I'm just explaining why I did that myself, long time ago.  I
>assume there are others like me.
>
May I ask what you bind to C-z in your config?

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Eli Zaretskii]

> Date: Fri, 2 Oct 2020 13:34:39 +0200
> From: Ergus <spacibba@aol.com>
> Cc: rms@gnu.org, dgutov@yandex.ru, raman@google.com,
> 	monnier@iro.umontreal.ca, thibaut.verron@gmail.com,
> 	emacs-devel@gnu.org
> 
> May I ask what you bind to C-z in your config?

  (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))
  (global-set-key "\M-z" (function (lambda () (interactive) (scroll-down 1))))

Re: Standardizing more key bindings?

[Stefan Monnier]

>   > > I applaud this initiative, but one of the steps would be to define
>   > > common bindings to use in all "inferior" (REPL) modes,
> That is a good idea, but please let's call them "interpreter modes",
> to avoid misleading implications about how these languages work.

FWIW, I disagree: in my part of the world, "REPL" is the standard term
to talk about an interactive loop that "read"s a chunk of code,
"eval"uates it, and then "print"s the result.  AFAIK this description
fits the "REPL" acronym and fits most interactive loops like that of
a shell, or those of languages like OCaml, Lua, Python, younameit.


        Stefan

Re: Standardizing more key bindings?

[Stefan Monnier]

>> The first question is, should thee bindings be conceptually global?
>> I don't think so.
>> 
>> To make them global means they conflict with a lot more other bindings,
>> and that makes the task of choosing these bindings harder.
>> It also means that the change would be a bigger incompatibility.
>> 
>> Thus, I think we should plan on having these bindings only
>> in the major modes that involve talking to an intepreter.
>
> They could also be defined by prog-mode, which is (or should be) the
> parent of all programming modes.

My experiment in this direction (which I posted earlier in this thread)
makes `prog-proc-mode` a derived mode of `prog-mode` because not all
programming languages have a corresponding REPL.


        Stefan

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > FWIW, I disagree: in my part of the world, "REPL" is the standard term
  > to talk about an interactive loop that "read"s a chunk of code,
  > "eval"uates it, and then "print"s the result.

Let's not disguise the superiority of Lisp
by erroneously attributing to other languages
the superior design of Lisp that the others lack.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I understand.  However, suspending Emacs is a very infrequent
  > operation these days, what with most everyone working in a windowed
  > environment.

It is not "very" infrequent, when running Emacs on a tty.  It is
somewhat infrequent.  It wouldn't bother me to type the character
twice on those occasions.

However, C-z and C-c are the standard ways to get out of a program,
and if neither of them works, people will get trapped in it.

If C-z C-z is the way to suspend, and the first C-z (when it echoes)
displays a message such as "To suspend Emacs, type C-z again now",
I think that will enable people to get out.

C-x C-z is not adequate for this.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Thus, I think we should plan on having these bindings only
  > > in the major modes that involve talking to an intepreter.

  > They could also be defined by prog-mode, which is (or should be) the
  > parent of all programming modes.

There are quite a few programming modes where these operations are not
useful -- compiled languages which don't have an interpreter.

Perhaps someday C will have an interpreter.  (I tried to get that
done, 30 years ago.)  One could argue that the interpreter keys
should be kept available for that purpose even in C mode.

On the other hand, those keys might have existing definitions in these
modes, and finding other bindings for those definitions could be a
pain.  And that would be an incompatible change.

On the gripping hand, it wouldn't be hard to make the specific modes
override the new prog-mode bindings with their traditional definitions.

So I guess it is ok to put them in prog-mode.

But that presumes we use just one command to implement each
of these operations, in all the modes where they are useful.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I don't suggest that we choose bindings. The question is can we have
  > infrastructure making is easy for users (or starter kit developers,
  > etc) to set such bindings across modes.

Defining them in prog-mode, or in a submode of it, would achieve that
goal.  But we should not expect users to choose different keys for
these commands, not very often.

In order for these bindings to be convenient, we would want to arrange
that they don't conflict with other bindings.  The way to do that is
by moving some of the other definitions of these keys.

Once we do that, these keys would be clearly the best keys to use for
these commands, since they wouldn't conflict with anything.  Using any
other keys for these commands would tend to cause inconvenience, so
few users would do that.

Practically speaking, our choice would be choosing for the community
(except the few who make radical changes), so we should choose well.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The idea of having one single keymap to implement them presumes that
  > > any given binding is implemented by the same command in all these modes.
  > > Is that true?  I doubt it.

  > That is one possibility suggested in my original message. To have one
  > single entry point for those commands, which then calls functions
  > defined by the mode, similar to how indentation works.

We could implement it that way, but it may not be the best way.  There
is generally no advantage in defining a command simply to call a
variable and have modes change the variable instead of the key's
binding.

Possible drawbacks include:

* It is extra work (even if not very hard work).  It is extra churn.

* It means the doc string can't be adapted for a specific mode.

* It means that a specific mode can't add features to the command.

I set up function variables for indentation operations because they
are _not_ equivalent to the user-level commands.  Rather, they are
lower-level operations, and some of the user-level commands call them
multiple times.

These variables made it possible to have indentation commands which
did nontrivial work in a mode-independent way by calling the
variables' values.

However, over the years, some modes needed to replace the generic
indentation commands with specific ones.

Does this apply to sending code to an interpreter?  I don't know.
Perhaps there is some sub-operation for which it would be nice to
define such a mode-set variable.  But that is another issue.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: dgutov@yandex.ru, thibaut.verron@gmail.com, emacs-devel@gnu.org
> Date: Sat, 03 Oct 2020 23:38:55 -0400
> 
>   > They could also be defined by prog-mode, which is (or should be) the
>   > parent of all programming modes.
> 
> There are quite a few programming modes where these operations are not
> useful -- compiled languages which don't have an interpreter.

That's a valid consideration.  But does it really invalidate the
proposal?  If you don't have a language interpreter to send it a
region of the buffer, then these key sequences will never be used,
because there's no program to send them to.  Right?

> Perhaps someday C will have an interpreter.  (I tried to get that
> done, 30 years ago.)  One could argue that the interpreter keys
> should be kept available for that purpose even in C mode.

There are C interpreters out there, although they are not widespread.
There's also the JIT C compiler in GDB, which can be regarded as a
kind of C interpreter.  And then there's 'cdecl', which can be used as
such an interpreter, albeit with very limited capabilities.

So even for a compiled language such as C, this notion would sometimes
make sense, I think.

> On the other hand, those keys might have existing definitions in these
> modes, and finding other bindings for those definitions could be a
> pain.  And that would be an incompatible change.
> 
> On the gripping hand, it wouldn't be hard to make the specific modes
> override the new prog-mode bindings with their traditional definitions.
> 
> So I guess it is ok to put them in prog-mode.

Agreed.

> But that presumes we use just one command to implement each
> of these operations, in all the modes where they are useful.

Yes, I think that's the intention.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

Le dim. 4 oct. 2020 à 05:38, Richard Stallman <rms@gnu.org> a écrit :

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I understand.  However, suspending Emacs is a very infrequent
>   > operation these days, what with most everyone working in a windowed
>   > environment.
>
> It is not "very" infrequent, when running Emacs on a tty.  It is
> somewhat infrequent.  It wouldn't bother me to type the character
> twice on those occasions.
>
> However, C-z and C-c are the standard ways to get out of a program,
> and if neither of them works, people will get trapped in it.
>
> If C-z C-z is the way to suspend, and the first C-z (when it echoes)
> displays a message such as "To suspend Emacs, type C-z again now",
> I think that will enable people to get out.
>
> C-x C-z is not adequate for this.
>

The exact same arguments could apply to C-c being "replaced" by C-x C-c.

[-- Attachment #2: Type: text/html, Size: 1487 bytes --]

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Alfred M. Szmidt]

   The exact same arguments could apply to C-c being "replaced" by C-x C-c. 

There is a big difference in that C-c is already used by Emacs for
other things, one is for users, and the second is for local
keybindings in modes.  Changing that would break quite a bit of
things.

C-z z or similar for suspend with a message seems like a good
compromise.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Howard Melman]

Eli Zaretskii <eliz@gnu.org> writes:

> I understand.  However, suspending Emacs is a very infrequent
> operation these days, what with most everyone working in a windowed
> environment.  And OTOH there are some very frequently-used commands
> that can be conveniently bound to C-z; suspending is still possible
> with C-x C-z.
>
> That said, I'm not necessarily arguing to unbind C-z or rebind it by
> default, I'm just explaining why I did that myself, long time ago.  I
> assume there are others like me.

FWIW I'm a GUI only user and long ago I added a bunch of
frame commands to the ctl-x-5-map and did:

(global-set-key (kbd "C-z") ctl-x-5-map)

As a mac user I get the best of both worlds as my command key
is super- so s-z still works as undo.

-- 

Howard

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

Le dim. 4 oct. 2020 à 15:46, Alfred M. Szmidt <ams@gnu.org> a écrit :

>    The exact same arguments could apply to C-c being "replaced" by C-x
> C-c.
>
> There is a big difference in that C-c is already used by Emacs for
> other things, one is for users, and the second is for local
> keybindings in modes.  Changing that would break quite a bit of
> things.


I meant when C-c was chosen, I wasn't suggesting to change things now.

But if C-x C-c for C-c was never too confusing, C-x C-z for C-z should be
fine too.

In any case, C-z can display a message guiding the user to the proper key
sequence. And one could argue that C-c could show such a message
too(without breaking anything).

C-z z or similar for suspend with a message seems like a good
> compromise.


I agree in general, with a preference for C-z C-z. But if C-z becomes a
prefix key, C-z C-z (or even C-z z) will have the same "prime" status as
C-c C-c today.

If C-z is purely for users with the exception of binding to suspend-frame,
it should not be a problem, as users can always override it they don't care
about tty suspend.

>

[-- Attachment #2: Type: text/html, Size: 2033 bytes --]

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Alfred M. Szmidt]

       The exact same arguments could apply to C-c being "replaced" by C-x C-c. 

    There is a big difference in that C-c is already used by Emacs for
    other things, one is for users, and the second is for local
    keybindings in modes.  Changing that would break quite a bit of
    things.

   I meant when C-c was chosen, I wasn't suggesting to change things now. 

I suspect that C-c was choosen long before GNU Emacs.

   But if C-x C-c for C-c was never too confusing, C-x C-z for C-z
   should be fine too.

That makes no sense to me, C-x C-c and C-c <foo> have nothing in
common, one kills Emacs by asking the user the other is used by other
modes and users.  C-c (SIGINT) in Unix has a entierly different
behaviour than all of those...

   In any case, C-z can display a message guiding the user to the
   proper key sequence. And one could argue that C-c could show such a
   message too(without breaking anything).

C-c doesn't interrupt Emacs; so having it show a message would be
missleading to the user.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

Le dim. 4 oct. 2020 à 19:00, Alfred M. Szmidt <ams@gnu.org> a écrit :

>        The exact same arguments could apply to C-c being "replaced" by C-x
> C-c.
>
>     There is a big difference in that C-c is already used by Emacs for
>     other things, one is for users, and the second is for local
>     keybindings in modes.  Changing that would break quite a bit of
>     things.
>
>    I meant when C-c was chosen, I wasn't suggesting to change things now.
>
> I suspect that C-c was choosen long before GNU Emacs.
>

That does not necessarily make the then-reasoning invalid.

>
 But if C-x C-c for C-c was never too confusing, C-x C-z for C-z
>    should be fine too.
>
> That makes no sense to me, C-x C-c and C-c <foo> have nothing in
> common, one kills Emacs by asking the user the other is used by other
> modes and users.  C-c (SIGINT) in Unix has a entierly different
> behaviour than all of those...
>

Only for programs which don't intercept it (either the key or the signal).
Others choose to intercept the key or the signal and request confirmation,
ask for saving, etc.

For practical purposes, in a responsive process, C-x C-c is "quit now", aka
C-c anywhere else. Even if the mechanism is somewhat different, it's not an
entirely different behavior.

I don't have a computer at hand to test, but I wouldn't be too surprised if
sending SIGINT to an emacs process called save-buffers-kill-emacs.


   In any case, C-z can display a message guiding the user to the
>    proper key sequence. And one could argue that C-c could show such a
>    message too(without breaking anything).
>
> C-c doesn't interrupt Emacs; so having it show a message would be
> missleading to the user.
>

I don't understand. What would be misleading in a message "To quit emacs,
type C-x C-c"?

>

[-- Attachment #2: Type: text/html, Size: 3191 bytes --]

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Alfred M. Szmidt]

Might be worth noting that the behaviour of C-z also dates back to the
Lisp Machines where it meant to go back to top-level -- which is
similar enough behaviour to "suspend" in Unix (i.e. you punt your
process somehow and go back to whatever you where doing).

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Alfred M. Szmidt]

   I don't have a computer at hand to test, but I wouldn't be too
   surprised if sending SIGINT to an emacs process called
   save-buffers-kill-emacs.

SIGINT to Emacs calls keyboard-quit.

       In any case, C-z can display a message guiding the user to the
       proper key sequence. And one could argue that C-c could show
       such a message too(without breaking anything).

    C-c doesn't interrupt Emacs; so having it show a message would be
    missleading to the user.

   I don't understand. What would be misleading in a message "To quit
   emacs, type C-x C-c"?

Why should that be shown for a key that is not only unrelated to C-x
C-c but also used for an entierly different purpose?  The issue with
C-z is that one is modifying its behaviour slightly from what users
already expect, i.e. suspending Emacs.  

Showing a message that C-z no longer suspends Emacs, but if you press
z or C-z again it will do that is being helpful.  In ten years time,
maybe that message can be removed.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Juri Linkov]

> To be not so disruptive that's why I think that C-z C-z is the most
> conservative alternative.

This is what I successfully used for many years to dedicate the whole
C-z kemap to user-defined keys while keeping suspend-frame on C-z C-z:

#+begin_src emacs-lisp
(defvar my-map
  (let ((map (make-sparse-keymap))
        (old (global-key-binding "\C-z")))
    (global-unset-key "\C-z")
    (define-key global-map "\C-z" map)
    (define-key map "\C-z" old)
    map))
#+end_src

And when cua-mode is enabled, C-z is bound to undo.

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Showing a message that C-z no longer suspends Emacs, but if you press
  > z or C-z again it will do that is being helpful.  In ten years time,
  > maybe that message can be removed.

As long as Emacs is used, there will be people who run it on a tty and
don't know how to get out.  If C-c doesn't do it, they will try C-z.
At least one of them should point the way to the exit.

  > Might be worth noting that the behaviour of C-z also dates back to the
  > Lisp Machines where it meant to go back to top-level

I am pretty sure it worked on ITS in 1976.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > C-x C-z is not adequate for this.

  > The exact same arguments could apply to C-c being "replaced" by C-x C-c.

You are making the argument that, since the two issues are similar in form,
the proper decisions must be similar in form.

That reasoning sounds uncontestable, but sometimes it is not valid.
Sometimes similar questions have dissimilar answers.
If you look for examples you will surely find some.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > But that presumes we use just one command to implement each
  > > of these operations, in all the modes where they are useful.

  > Yes, I think that's the intention.

This is not a moral issue, just a practical one.  So there is no
reason to try to prejudge it.  If that method works out well,
it's ok to use.  But I urge people not to cling to this method
if another proves more effective.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Opening Up More Keymaps Re: Standardizing more key bindings?

[Lars Brinkhoff]

Richard Stallman wrote:
> > Might be worth noting that the behaviour of C-z also dates back to the
> > Lisp Machines where it meant to go back to top-level
>
> I am pretty sure it worked on ITS in 1976.

It certainly did.  ITS programs can use superimage input mode to
intercept ^Z, but Emacs didn't do that in 1976 or any other year as far
as I can tell.

The Unix meaning of ^Z to suspend the current process group also comes
from ITS.

(This is not a comment on whether Emacs should do something different
about C-z now.)

Re: Standardizing more key bindings?

[Nikolay Kudryavtsev]

Hi.

So I'm one of those people who loves to torture his muscle memory and 
I've tried most of the major variations of Emacs keybinding systems over 
the years, this being the vanilla, Evil(Spacemacs) and ErgoEmacs.

This led me to thinking that maybe Emacs actually needs a separate 
intermediate level of abstraction for keybinding customization. And the 
solution that came to my head is something akin to Clojure's protocols. 
The problem is that there are cases where we have multiple 
interconnected keybindings, the most simple example being 
cut-copy-paste. Lets say we have a cut-copy-paste protocol and the 
default keybinding implementation of it that's shipped with Emacs. Then 
the CUA-mode becomes an alternative keybinding implementation of that 
protocol. Same thing with comint. As such, a package developers would be 
able to define that their package uses this and that protocol and then 
they'll automatically get the bindings. And the keybinding system 
developers can just provide alternative bindings for existing protocols 
and their job will be done, in the ideal world of course. This way we'll 
accomplish keybinding polymorphism.

Anyway, just presenting probably the most over-engineered solution to 
this problem.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Standardizing more key bindings?

[Stefan Monnier]

> This led me to thinking that maybe Emacs actually needs a separate
> intermediate level of abstraction for keybinding customization.

I agree, but I don't know what such a thing would look like.

> And the solution that came to my head is something akin to Clojure's
> protocols.

I don't know what this means, concretely.

The only thing that seems "clear" is that to get the kind of
"polymorphism" that corresponds to adapting to various styles of
key-choices, we should devise a way for packages (other than key-choices
packages like `evil-mode` or `god-mode`, obviously) to never
specify/choose actual keys.


        Stefan

Re: Standardizing more key bindings?

[Nikolay Kudryavtsev]

Keybinding protocol would be a set of functions we expect a package 
implementing it to implement. Then package developers write protocol 
implementations and keybinding packages(and users) write protocol bindings.

So one decent example I have is minibuffer completion. Lets say I'm 
using ErgoEmacs and it expects previous element to work on F11 and next 
element on F12. But there are multiple minibuffer completion packages, 
like Ivy, Icicles, Helm and ErgoEmacs developers have to currently try 
to provide concrete bindings for whatever they choose to support.

Lets say there's a minibuffer-completion protocol:

(def-kb-protocol minibuffer-completion '(next-element))

Then keybinding system developers just have to provide bindings for that 
protocol:

(kb-protocol-bind minibuffer-completion '((F12 next-element)))

And minibuffer completion packages just have to provide implementation:

(kb-protocol-impl minibuffer-completion '((next-element ivy-next-line)))

Ideally if we provide a robust set of such protocols we can accomplish 
uniformity of common actions between different modes, but also the 
ability to do quick keybinding for the same action across a range of 
modes as long as they implement the protocol itself.

Then we just have to make sure that the bundled modes comply with the 
set of protocols we ship.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Standardizing more key bindings?

[Stefan Monnier]

> So one decent example I have is minibuffer completion. Lets say I'm using
> ErgoEmacs and it expects previous element to work on F11 and next element on
> F12. But there are multiple minibuffer completion packages, like Ivy,
> Icicles, Helm and ErgoEmacs developers have to currently try to provide
> concrete bindings for whatever they choose to support.

The problem with it is that all of those completion packages provide
a slightly different set of commands.  So while the "next element" and
"previous element" command can easily be handled such that the choice of
key is handled elsewhere, you're still stuck with the choice of key for
the commands specific to Helm (say), unless your protocol covers "a
superset of all the completion packages".  If it's not a superset, then
the few missing commands will end up sticking out like a sore thumb
(or even conflict with some other keybinding).

So, I think the "keytheme" packages should be able to do more than give
explicit bindings to a particular set of (concrete or abstract)
commands.  They should also be able to describe their style in a more
"intensional" way, which would be used to *compute* the key to use for
a new command based on some suggestion from the command's package.


        Stefan

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This led me to thinking that maybe Emacs actually needs a separate 
  > intermediate level of abstraction for keybinding customization.

What occurs to me is that we could have a level of indirection in
keybindings.  C-w could be bound to something like cut-region-binding,
and cut-region-binding could be bound to some command (by default,
kill-region).  And likewise M-w and C-y.

Turning on CUA mode would bind C-x to cut-region-binding and C-w to
something else, and other bindings likewise.

I have written the indirecting key bindings like symbols, but since
symbbols as key bindings have another meaning, I think they must not
be symbols.  They should be some data type chosen to distinguish these
indirections all other valid key bindings.

Perhaps lists of the form (:indirect KEY-INDIRECTED-TO).

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Nikolay Kudryavtsev]

Yeah, having such protocols would result in having to struggle to define 
the protocol for each case to be just robust enough. Well if Helm has 
some completely unique command, we can't really standardize it, since we 
need to classify it first. In the end it's a (hypothetical)tool for 
keybinding standardization with generic customization being the bonus.

As for being able to keytheme Emacs in a more intentional(declarative?) 
manner, I agree that it would have been great, I just don't see any 
workable solution to accomplish that. Lets say in my theme package I 
want some utility menu for commands in the current major mode, let's say 
on C-c C-u. Then I'll have to defer to mode developers to classify their 
commands somehow. Lets say elisp-mode has byte-compile-file command 
classified as utility. Then my declarative bindings go through all 
commands classified as utility and byte-compile-file gets automatically 
bound to C-c C-u C-a for example. And we're stuck with pretty much the 
same problem as with the keybinding-protocols I described only in a more 
freeform fashion.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I wrote

    > The term "REPL" is inapplicable for most of these languages, since
    > they do not have anything comparable ton read, eval, or print.

You responded,

  > It's useless to fight to reserve this term to Lisp: it has been solidly 
  > coined for similar programs in non-homoiconic languages as well for the 
  > last 10-20 years at least.

which seems to be a change of subject, because you're talking about
some sort of "fight".

I'm talking about the question of what terminology we should use in
describing and designing GNU Emacs.  We should use clear and correct
terminology.

Doing that does not require that we fight with other groups
that make other decisions.

  > The languages in question might not have the same kind of 'read', but 
  > they usually have 'eval', and their REPLs do 'print'.

'read' and 'eval' are things that those lanuages don't have.  Their
command loops do have the ability to read and execute an expression,
but that does not break down, in those languages, into a combination
of 'read' and 'eval' in the Lisp sense.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

References to "REPL" from past

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-11-01 00:27]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> I wrote
> 
>     > The term "REPL" is inapplicable for most of these languages, since
>     > they do not have anything comparable ton read, eval, or print.
> 
> You responded,
> 
>   > It's useless to fight to reserve this term to Lisp: it has been solidly 
>   > coined for similar programs in non-homoiconic languages as well for the 
>   > last 10-20 years at least.
> 
> which seems to be a change of subject, because you're talking about
> some sort of "fight".
> 
> I'm talking about the question of what terminology we should use in
> describing and designing GNU Emacs.  We should use clear and correct
> terminology.
> 
> Doing that does not require that we fight with other groups
> that make other decisions.
> 
>   > The languages in question might not have the same kind of 'read', but 
>   > they usually have 'eval', and their REPLs do 'print'.
> 
> 'read' and 'eval' are things that those lanuages don't have.  Their
> command loops do have the ability to read and execute an expression,
> but that does not break down, in those languages, into a combination
> of 'read' and 'eval' in the Lisp sense.

See references here:
https://code.i-harness.com/en/q/baf810 - use eww for those not using Javascript

as the above link is research on Python's "REPL" in response to RMS on
previous discussions

As the times pass people dillute or divert some definitions, take it
out of the context and today even HTML has REPL:
https://repl.it/languages/html (does not work without Javascript)

Re: Standardizing more key bindings?

[Stefan Monnier]

>   > The languages in question might not have the same kind of 'read', but 
>   > they usually have 'eval', and their REPLs do 'print'.
> 'read' and 'eval' are things that those lanuages don't have.

Many (most?) of those languages do have `eval`, and many have some form
of `read` available as well.

> Their command loops do have the ability to read and execute an
> expression, but that does not break down, in those languages, into
> a combination of 'read' and 'eval' in the Lisp sense.

So what?  Their command loop does do "read, then eval, then print".
It's only natural that what "read", "eval", and "print" means for
language Foo is not necessarily the same as what it means for
language Bar.

Maybe you could argue that Lisp's "read" and "eval" are better, but that
doesn't mean that other languages's command loop aren't "REPLs".

Whether the "read", the "eval", and the "print" part are made available
to the language or only used by the interactive loop doesn't change the
code of the interactive loop, nor how the user interacts with it.
IOW, it's still a "REPL".


        Stefan

Re: Standardizing more key bindings?

[Dmitry Gutov]

On 01.11.2020 06:27, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> I wrote
> 
>      > The term "REPL" is inapplicable for most of these languages, since
>      > they do not have anything comparable ton read, eval, or print.
> 
> You responded,
> 
>    > It's useless to fight to reserve this term to Lisp: it has been solidly
>    > coined for similar programs in non-homoiconic languages as well for the
>    > last 10-20 years at least.
> 
> which seems to be a change of subject, because you're talking about
> some sort of "fight".

> I'm talking about the question of what terminology we should use in
> describing and designing GNU Emacs.  We should use clear and correct
> terminology.

We should also try to call things generally the same names what other 
people have already assigned to them. That allows us to benefit from a 
shared language (a technical dialect of English) and help users that 
just start out with Emacs to do it faster and easier.

> Doing that does not require that we fight with other groups
> that make other decisions.

If we assign a different name for a thing than most other people use, 
our name will be "fighting" the existing name in the minds of our users.

That would be more apparent, however, if Emacs were more popular.

>    > The languages in question might not have the same kind of 'read', but
>    > they usually have 'eval', and their REPLs do 'print'.
> 
> 'read' and 'eval' are things that those lanuages don't have.
You might want to familiarize yourself more with e.g. JavaScript.

eval('1 + 1')
=> 2

RE: Standardizing more key bindings?

[Drew Adams]

> We should also try to call things generally the same names what other
> people have already assigned to them. That allows us to benefit from a
> shared language (a technical dialect of English) and help users that
> just start out with Emacs to do it faster and easier.
> 
> If we assign a different name for a thing than most other people use,
> our name will be "fighting" the existing name in the minds of our users.

Are they in fact the same thing?

Is your argument that a REPL _is_ the same thing
in Lisp as in other languages?  If so, you should
be OK with using "REPL" for Lisp too.

Or is your argument that REPL is _not_ the same
thing?  If so, since others have apparently by
now co-opted the name, Lisp can switch to using
"Replstiltskin".

Ah, yes, fairy tales...

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So what?  Their command loop does do "read, then eval, then print".

No, it doesn't.  It parses and executes a command, but it is
misleading to describe that as "read, then eval" in those languages.

  > Whether the "read", the "eval", and the "print" part are made available
  > to the language or only used by the interactive loop

Those conceptual parts are implemented separately in Lisp because Lisp
exposes them.  In a language which does not expose them to users, they
may not exist as separate parts in the code.
                                                         doesn't change the
  > code of the interactive loop, nor how the user interacts with it.

We want to make users aware of how Lisp is different, not look for
ways to downplay the differences.


If you have new pertinent facts to show me, I am interested.
However, different ways of stating your position will not
convince me, so please skip it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > You might want to familiarize yourself more with e.g. JavaScript.

I would very much like to, but I have never found the time to do it.

  > eval('1 + 1')
  > => 2

It looks like that "eval" operates on a string,
not on the output of a read function.  I think there is no read function
in JavaScript.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Standardizing more key bindings?

[Yuri Khan]

On Mon, 2 Nov 2020 at 12:41, Richard Stallman <rms@gnu.org> wrote:

>   > So what?  Their command loop does do "read, then eval, then print".
>
> No, it doesn't.  It parses and executes a command, but it is
> misleading to describe that as "read, then eval" in those languages.
>
>   > Whether the "read", the "eval", and the "print" part are made available
>   > to the language or only used by the interactive loop
>
> Those conceptual parts are implemented separately in Lisp because Lisp
> exposes them.  In a language which does not expose them to users, they
> may not exist as separate parts in the code.

Python has ast.parse(), compile() and exec(), all three exposed in the
standard library. Can we please continue to use the REPL term for
Python, even though there is an additional intermediate step between
reading and evaluation.

Re: Standardizing more key bindings?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Mon, Nov 02, 2020 at 01:14:49PM +0700, Yuri Khan wrote:
> On Mon, 2 Nov 2020 at 12:41, Richard Stallman <rms@gnu.org> wrote:
> 
> >   > So what?  Their command loop does do "read, then eval, then print".
> >
> > No, it doesn't.  It parses and executes a command, but it is
> > misleading to describe that as "read, then eval" in those languages.
> >
> >   > Whether the "read", the "eval", and the "print" part are made available
> >   > to the language or only used by the interactive loop
> >
> > Those conceptual parts are implemented separately in Lisp because Lisp
> > exposes them.  In a language which does not expose them to users, they
> > may not exist as separate parts in the code.
> 
> Python has ast.parse(), compile() and exec(), all three exposed in the
> standard library. Can we please continue to use the REPL term for
> Python, even though there is an additional intermediate step between
> reading and evaluation.

The difference is that in Python, this is an after-thought. In the Lisps,
it's a design principle. One can feel that :-)
Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Standardizing more key bindings?

[Dmitry Gutov]

On 02.11.2020 08:14, Yuri Khan wrote:
> Python has ast.parse(), compile() and exec(), all three exposed in the
> standard library.

I'd be willing to bet that any given Python REPL doesn't use them, though.

Re: Python REPL using standard library functions

[Yuri Khan]

On Mon, 2 Nov 2020 at 16:50, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 02.11.2020 08:14, Yuri Khan wrote:
> > Python has ast.parse(), compile() and exec(), all three exposed in the
> > standard library.
>
> I'd be willing to bet that any given Python REPL doesn't use them, though.

One of the guiding principles of Python is “There must be one — and
preferably only one — obvious way to do it”. Implementing a REPL in
terms of ast.parse, compile() and exec is one obvious way to do it.
There is a catch that compile() with an option argument can be used
instead of ast.parse, so that’s another obvious way to do it. Both are
fully exposed to the user though.

Indeed, my limited experimentation shows I can augment these built-in
functions and they are immediately picked up by at least one REPL:

$ ipython3
In [1]: import ast
In [2]: old_ast_parse = ast.parse
In [3]: def my_parse(*args, **kwargs):
   ...:     print('in ast.parse')
   ...:     return old_ast_parse(*args, **kwargs)
   ...:
In [4]: ast.parse = my_parse
In [5]: 2+2
Out[5]: 4

# no effect so far

In [7]: old_compile = __builtins__.compile
In [8]: def my_compile(*args, **kwargs):
   ...:     print('in compile')
   ...:     return old_compile(*args, **kwargs)
   ...:
In [9]: __builtins__.compile = my_compile
In [10]: 2+2
in compile
in compile
in compile
in compile
in compile
in compile
Out[10]: 4

# now we are getting something,
# not sure why so many calls

In [11]: old_exec = __builtins__.exec
in compile
in compile
in compile
in compile
in compile
in compile
In [12]: def my_exec(*args, **kwargs):
    ...:     print('in exec')
    ...:     return old_exec(*args, **kwargs)
    ...:
in compile
in compile
in compile
in compile
in compile
in compile
In [13]: __builtins__.exec = my_exec
in compile
in compile
in compile
in compile
in compile
in compile
In [14]: 2+2
in compile
in compile
in compile
in compile
in compile
in compile
in exec
Out[14]: 4

Re: Python REPL using standard library functions

[Dmitry Gutov]

On 02.11.2020 13:40, Yuri Khan wrote:
> On Mon, 2 Nov 2020 at 16:50, Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>> On 02.11.2020 08:14, Yuri Khan wrote:
>>> Python has ast.parse(), compile() and exec(), all three exposed in the
>>> standard library.
>>
>> I'd be willing to bet that any given Python REPL doesn't use them, though.
> 
> One of the guiding principles of Python is “There must be one — and
> preferably only one — obvious way to do it”. Implementing a REPL in
> terms of ast.parse, compile() and exec is one obvious way to do it.
> There is a catch that compile() with an option argument can be used
> instead of ast.parse, so that’s another obvious way to do it. Both are
> fully exposed to the user though.

Is eval implemented in terms of either?

> Indeed, my limited experimentation shows I can augment these built-in
> functions and they are immediately picked up by at least one REPL:

The basic Python REPL doesn't seem to use it (your experiment doesn't 
result in anything being printed). Perhaps ipython uses ast.parse for 
syntax highlighting?

Ruby's standard library also includes a parser. The 'eval' method 
doesn't seem to be implemented in terms of it. At least, not directly.

In any case, I disagree that whether something is a REPL or not, should 
be decided by its implementation details.