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.

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: 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: 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: 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: 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: 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: 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)

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.