Proposal: "C-z <letter>" reserved for users

Proposal: "C-z <letter>" reserved for users

[S Boucher via Users list for the GNU Emacs text editor]

C-z is bound to a low frequency use function (suspend-frame)... and speaking for myself, I probably can count on one hand the number of times I've used it in the last 25years :-)

I would suggest:1) move suspend-frame to "C-c C-z" (that is still a quick shortcut)
2) reserve C-z <letter> for users
That still leaves a whole lot with C-z C-... C-z M-...

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

S Boucher via Users list for the GNU Emacs text editor wrote:

> C-z is bound to a low frequency use function
> (suspend-frame)... and speaking for myself, I probably can
> count on one hand the number of times I've used it in the
> last 25years :-)
>
> I would suggest:1) move suspend-frame to "C-c C-z" (that is
> still a quick shortcut) 2) reserve C-z <letter> for users
> That still leaves a whole lot with C-z C-... C-z M-...

ikr?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Howard Melman]

S Boucher via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> C-z is bound to a low frequency use function (suspend-frame)... and
> speaking for myself, I probably can count on one hand the number of
> times I've used it in the last 25years :-)
>
> I would suggest:1) move suspend-frame to "C-c C-z" (that
> is still a quick shortcut) 2) reserve C-z <letter> for users
> That still leaves a whole lot with C-z C-... C-z M-...

FWIW I used to bind the ctl-x-5-map to C-z add was happier
typing C-z f than C-x 5 f.  I shifted to this frame oriented
transient on C-z for a while now and have been happy.  I'm
sure it could be improved but as a first attempt it's been
pretty good for me.

;;; frame commands from ctl-x-5-map
(define-transient-command hrm-frame-transient ()
  "Frame commands mirroring ctl-x-5-map"
  ["Configure Frames"
   ["Manage"
    ("2" "New" make-frame-command)
    ("0" "Delete" delete-frame)
    ("k" "Kill Frame & Buffer" kill-buffer-and-frame)
    ("1" "Delete others" delete-other-frames)
    ]
   ["Select"
    ("o" "Other" other-frame)
    ("n" "Next" other-frame)
    ("p" "Previous" select-previous-frame)
    ]
   ["Display"
    ("-" "Fixed Width" variable-pitch-mode)
    ("l" "Lower" lower-frame)
    ("=" "Maximize" toggle-frame-maximized)
    ("i" "Iconify" iconify-frame)
    ]
   ["Move"
    ("<" "Left" move-frame-left :transient t)
    (">" "Right" move-frame-right :transient t)
    ]
   ]
  ["Open in other Frame"
   ["Files"
    ("b" "Buffer" switch-to-buffer-other-frame)
    ("C-o" "Buffer other frame" display-buffer-other-frame)
    ("C-f" "File" find-file-other-frame)
    ("f" "File" find-file-other-frame)
    ("r" "File Read-Only" find-file-read-only-other-frame)
    ]
   ["Apps"
    ("d" "Dired" dired-other-frame)
    ("." "Xref" xref-find-definitions-other-frame)
    ("m" "Compose Mail" compose-mail-other-frame)
    ]
   ["Help For"
    ("V" "Variable" find-variable-other-frame)
    ("F" "Function" find-function-other-frame)
    ("K" "Key" find-function-on-key-other-frame)
    ("L" "Library" find-library-other-frame)
    ]
   ]
  )
(global-set-key (kbd "C-z") 'hrm-frame-transient)


-- 

Howard

Re: Proposal: "C-z <letter>" reserved for users

[Christopher Miles]

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

<#secure method=pgpmime mode=sign>

Hi, Howard, your keybinding is great.

I copied your code, found some command is not defined.

Can you share your Emacs configuration? Thanks in advance. 😄

Howard Melman <hmelman@gmail.com> writes:

S Boucher via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> writes:

C-z is bound to a low frequency use function (suspend-frame)… and speaking for myself, I probably can count on one hand the number of times I've used it in the last 25years :-)

I would suggest:1) move suspend-frame to "C-c C-z" (that is still a quick shortcut) 2) reserve C-z <letter> for users That still leaves a whole lot with C-z C-… C-z M-…

FWIW I used to bind the ctl-x-5-map to C-z add was happier typing C-z f than C-x 5 f. I shifted to this frame oriented transient on C-z for a while now and have been happy. I'm sure it could be improved but as a first attempt it's been pretty good for me.

;;; frame commands from ctl-x-5-map (define-transient-command hrm-frame-transient () "Frame commands mirroring ctl-x-5-map" ["Configure Frames" ["Manage" ("2" "New" make-frame-command) ("0" "Delete" delete-frame) ("k" "Kill Frame & Buffer" kill-buffer-and-frame) ("1" "Delete others" delete-other-frames) ] ["Select" ("o" "Other" other-frame) ("n" "Next" other-frame) ("p" "Previous" select-previous-frame) ] ["Display" ("-" "Fixed Width" variable-pitch-mode) ("l" "Lower" lower-frame) ("=" "Maximize" toggle-frame-maximized) ("i" "Iconify" iconify-frame) ] ["Move" ("<" "Left" move-frame-left :transient t) (">" "Right" move-frame-right :transient t) ] ] ["Open in other Frame" ["Files" ("b" "Buffer" switch-to-buffer-other-frame) ("C-o" "Buffer other frame" display-buffer-other-frame) ("C-f" "File" find-file-other-frame) ("f" "File" find-file-other-frame) ("r" "File Read-Only" find-file-read-only-other-frame) ] ["Apps" ("d" "Dired" dired-other-frame) ("." "Xref" xref-find-definitions-other-frame) ("m" "Compose Mail" compose-mail-other-frame) ] ["Help For" ("V" "Variable" find-variable-other-frame) ("F" "Function" find-function-other-frame) ("K" "Key" find-function-on-key-other-frame) ("L" "Library" find-library-other-frame) ] ] ) (global-set-key (kbd "C-z") 'hrm-frame-transient)

[-- Attachment #2: ATT00001.txt --]
[-- Type: text/plain, Size: 253 bytes --]

-- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

Re: Proposal: "C-z <letter>" reserved for users

[Howard Melman]

Christopher Miles <numbchild@gmail.com> writes:

> <#secure method=pgpmime mode=sign>
>
> Hi, Howard, your keybinding is great.
>
> I copied your code, found some command is not defined.
>
> Can you share your Emacs configuration? Thanks in
> advance. 😄

I had forgotten I'd defined some simple commands.  I'm not
inclined to share my whole config, but here are a few that
are used in this transient.

Howard

(defun move-frame-right ()
  "Move the current frame right 200 pixels"
  (interactive)
  (let* ((p (frame-position))
	 (x (car p))
	 (y (cdr p)))
    (set-frame-position (selected-frame) (+ x 200) y)))

(defun move-frame-left ()
  "Move the current frame left 200 pixels"
  (interactive)
  (let* ((p (frame-position))
	 (x (car p))
	 (y (cdr p)))
    (set-frame-position (selected-frame) (- x 200) y)))

(defun select-previous-frame (&optional arg)
  "Select the -ARG'th visible frame on current display, and raise it.

All frames are arranged in a cyclic order.
This command selects the frame ARG steps previously in that order.
It is the reverse of `other-frame'."
  (interactive "p")
  (other-frame (* -1 arg)))

(defun kill-buffer-and-frame ()
  "Kill the current buffer and the current frame."
  (interactive)
  ;; do this trick in case of dedicated window in special frame
  ;; in that case kill-buffer will delete-frame too
  ;; can't check after kill buffer since selected-frame will have changed
  (if (window-dedicated-p (selected-window))
      (kill-buffer (current-buffer))
    (kill-buffer (current-buffer))
    (delete-frame)))



>
> Howard Melman <hmelman@gmail.com> writes:
>
> S Boucher <help-gnu-emacs@gnu.org> writes:
>
> C-z is bound to a low frequency use function (suspend-frame)… and
> speaking for myself, I probably can count on one hand the number of
> times I've used it in the last 25years :-)
>
> I would suggest:1) move suspend-frame to "C-c C-z" (that is still a
> quick shortcut) 2) reserve C-z <letter> for users That still leaves a
> whole lot with C-z C-… C-z M-…
>
> FWIW I used to bind the ctl-x-5-map to C-z add was happier typing C-z
> f than C-x 5 f. I shifted to this frame oriented transient on C-z for
> a while now and have been happy. I'm sure it could be improved but as
> a first attempt it's been pretty good for me.
>
> ;;; frame commands from ctl-x-5-map
> (define-transient-command hrm-frame-transient ()
>   "Frame commands mirroring ctl-x-5-map"
>   ["Configure Frames"
>    ["Manage"
>     ("2" "New" make-frame-command)
>     ("0" "Delete" delete-frame)
>     ("k" "Kill Frame & Buffer" kill-buffer-and-frame)
>     ("1" "Delete others" delete-other-frames)
>     ]
>    ["Select"
>     ("o" "Other" other-frame)
>     ("n" "Next" other-frame)
>     ("p" "Previous" select-previous-frame)
>     ]
>    ["Display"
>     ("-" "Fixed Width" variable-pitch-mode)
>     ("l" "Lower" lower-frame)
>     ("=" "Maximize" toggle-frame-maximized)
>     ("i" "Iconify" iconify-frame)
>     ]
>    ["Move"
>     ("<" "Left" move-frame-left :transient t)
>     (">" "Right" move-frame-right :transient t)
>     ]
>    ]
>   ["Open in other Frame"
>    ["Files"
>     ("b" "Buffer" switch-to-buffer-other-frame)
>     ("C-o" "Buffer other frame" display-buffer-other-frame)
>     ("C-f" "File" find-file-other-frame)
>     ("f" "File" find-file-other-frame)
>     ("r" "File Read-Only" find-file-read-only-other-frame)
>     ]
>    ["Apps"
>     ("d" "Dired" dired-other-frame)
>     ("." "Xref" xref-find-definitions-other-frame)
>     ("m" "Compose Mail" compose-mail-other-frame)
>     ]
>    ["Help For"
>     ("V" "Variable" find-variable-other-frame)
>     ("F" "Function" find-function-other-frame)
>     ("K" "Key" find-function-on-key-other-frame)
>     ("L" "Library" find-library-other-frame)
>     ]
>    ]
>   )
> (global-set-key (kbd "C-z") 'hrm-frame-transient)

-- 

Howard

RE: [External] : Re: Proposal: "C-z <letter>" reserved for users

[Drew Adams]

> (defun move-frame-right ()
>   "Move the current frame right 200 pixels"
>   (interactive)
>   (let* ((p (frame-position))
> 	 (x (car p))
> 	 (y (cdr p)))
>     (set-frame-position (selected-frame) (+ x 200) y)))

FWIW, `frame-cmds.el' uses this:

(defun move-frame-right (&optional n frame)
  "Move frame to the right.
Move it N times `frame-char-width', where N is the prefix arg.
In Lisp code, FRAME is the frame to move."
  (interactive "p")
  (unless n (setq n  1))
  (setq n  (* n (frame-char-width frame)))
  (modify-frame-parameters frame
                           (list
                             (list 'left
                                   '+
                                   (frcmds-new-frame-position
                                     frame 'left n)))))

`frcmds-new-frame-position' increments frame
position, handling the various position formats.
___

https://www.emacswiki.org/emacs/download/frame-cmds.el
___

> (defun kill-buffer-and-frame ()
>   "Kill the current buffer and the current frame."
>   (interactive)
>   ;; do this trick in case of dedicated window in special frame
>   ;; in that case kill-buffer will delete-frame too can't check
>   ;; after kill buffer since selected-frame will have changed
>   (if (window-dedicated-p (selected-window))
>       (kill-buffer (current-buffer))
>     (kill-buffer (current-buffer))
>     (delete-frame)))

FWIW, this is a bit similar (from `misc-cmds.el'):

;; Candidate as a replacement for `kill-buffer', at least
;; when used interactively.
;;
;; E.g.: (define-key global-map [remap kill-buffer]
;;                   'kill-buffer-and-its-windows)
;;
;; Can't just redefine `kill-buffer', because some programs
;; count on a specific other buffer taking the place of the
;; killed buffer (in the window).
;;
(defun kill-buffer-and-its-windows (buffer)
  "Kill BUFFER and delete its windows.  Default is `current-buffer'.
BUFFER may be either a buffer or its name (a string)."
  (interactive (list (read-buffer "Kill buffer: " (current-buffer)
                                  'existing)))
  (setq buffer  (get-buffer buffer))
  (if (buffer-live-p buffer)
      (let ((wins  (get-buffer-window-list
            buffer nil t))) ; On all frames.
        (when (kill-buffer buffer) ; Delete wins only if buf killed.
          (dolist (win  wins) ; User might keep buffer if modified.
            (when (window-live-p win)
              ;; Ignore error, in particular, "Attempt to delete
              ;; the sole visible or iconified frame".
              (ignore-errors (delete-window win))))))
    (when (interactive-p)
      (error "Can't kill - not a live buffer: `%s'" buffer))))
___

https://www.emacswiki.org/emacs/download/misc-cmds.el

Re: Proposal: "C-z <letter>" reserved for users

[Christopher Miles]

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

<#secure method=pgpmime mode=sign>

Thanks for your sharing. Very convinient commands. Thanks

Howard Melman <hmelman@gmail.com> writes:

Christopher Miles <numbchild@gmail.com> writes:

<#!secure method=pgpmime mode=sign>

Hi, Howard, your keybinding is great.

I copied your code, found some command is not defined.

Can you share your Emacs configuration? Thanks in advance. 😄

I had forgotten I'd defined some simple commands. I'm not inclined to share my whole config, but here are a few that are used in this transient.

Howard

(defun move-frame-right () "Move the current frame right 200 pixels" (interactive) (let* ((p (frame-position)) (x (car p)) (y (cdr p))) (set-frame-position (selected-frame) (+ x 200) y)))

(defun move-frame-left () "Move the current frame left 200 pixels" (interactive) (let* ((p (frame-position)) (x (car p)) (y (cdr p))) (set-frame-position (selected-frame) (- x 200) y)))

(defun select-previous-frame (&optional arg) "Select the -ARG'th visible frame on current display, and raise it.

All frames are arranged in a cyclic order. This command selects the frame ARG steps previously in that order. It is the reverse of `other-frame'." (interactive "p") (other-frame (* -1 arg)))

(defun kill-buffer-and-frame () "Kill the current buffer and the current frame." (interactive) ;; do this trick in case of dedicated window in special frame ;; in that case kill-buffer will delete-frame too ;; can't check after kill buffer since selected-frame will have changed (if (window-dedicated-p (selected-window)) (kill-buffer (current-buffer)) (kill-buffer (current-buffer)) (delete-frame)))


Howard Melman <hmelman@gmail.com> writes:

S Boucher <help-gnu-emacs@gnu.org> writes:

C-z is bound to a low frequency use function (suspend-frame)… and speaking for myself, I probably can count on one hand the number of times I've used it in the last 25years :-)

I would suggest:1) move suspend-frame to "C-c C-z" (that is still a quick shortcut) 2) reserve C-z <letter> for users That still leaves a whole lot with C-z C-… C-z M-…

FWIW I used to bind the ctl-x-5-map to C-z add was happier typing C-z f than C-x 5 f. I shifted to this frame oriented transient on C-z for a while now and have been happy. I'm sure it could be improved but as a first attempt it's been pretty good for me.

;;; frame commands from ctl-x-5-map (define-transient-command hrm-frame-transient () "Frame commands mirroring ctl-x-5-map" ["Configure Frames" ["Manage" ("2" "New" make-frame-command) ("0" "Delete" delete-frame) ("k" "Kill Frame & Buffer" kill-buffer-and-frame) ("1" "Delete others" delete-other-frames) ] ["Select" ("o" "Other" other-frame) ("n" "Next" other-frame) ("p" "Previous" select-previous-frame) ] ["Display" ("-" "Fixed Width" variable-pitch-mode) ("l" "Lower" lower-frame) ("=" "Maximize" toggle-frame-maximized) ("i" "Iconify" iconify-frame) ] ["Move" ("<" "Left" move-frame-left :transient t) (">" "Right" move-frame-right :transient t) ] ] ["Open in other Frame" ["Files" ("b" "Buffer" switch-to-buffer-other-frame) ("C-o" "Buffer other frame" display-buffer-other-frame) ("C-f" "File" find-file-other-frame) ("f" "File" find-file-other-frame) ("r" "File Read-Only" find-file-read-only-other-frame) ] ["Apps" ("d" "Dired" dired-other-frame) ("." "Xref" xref-find-definitions-other-frame) ("m" "Compose Mail" compose-mail-other-frame) ] ["Help For" ("V" "Variable" find-variable-other-frame) ("F" "Function" find-function-other-frame) ("K" "Key" find-function-on-key-other-frame) ("L" "Library" find-library-other-frame) ] ] ) (global-set-key (kbd "C-z") 'hrm-frame-transient)

[-- Attachment #2: ATT00001.txt --]
[-- Type: text/plain, Size: 253 bytes --]

-- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

Re: Proposal: "C-z <letter>" reserved for users

[Eli Zaretskii]

> Date: Sun, 7 Feb 2021 23:29:14 +0000 (UTC)
> From:  S Boucher via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> I would suggest:1) move suspend-frame to "C-c C-z" (that is still a quick shortcut)

It is already on "C-x C-z".

Re: Proposal: "C-z <letter>" reserved for users

[Francis Belliveau]

It would be nice for standard distro to not include a c-z binding, since it already exists on a key-sequence binding.

I have remapped c-z to my own key-map, but when I must use emacs without my personal bindings,  continually get messed up by accidental "suspend".

It is certainly a dangerous function to have mapped to such an easy key to hit, and my fingers are trained to hit that key a lot for other reasons. 
I can see where it was once very useful, but much less so in this day of GUI's.

Fran

> On Feb 7, 2021, at 22:31, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Sun, 7 Feb 2021 23:29:14 +0000 (UTC)
>> From:  S Boucher via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
>> 
>> I would suggest:1) move suspend-frame to "C-c C-z" (that is still a quick shortcut)
> 
> It is already on "C-x C-z".
> 

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Francis Belliveau wrote:

> It is certainly a dangerous function to have mapped to such
> an easy key to hit

Agree 100%:

  (put 'suspend-frame 'disabled  t)
  (global-unset-key "\C-z")
  (global-unset-key "\C-x\C-z")
  
-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Skip Montanaro]

>
> > It is certainly a dangerous function to have mapped to such
> > an easy key to hit
>
> Agree 100%:
>
>   (put 'suspend-frame 'disabled  t)
>   (global-unset-key "\C-z")
>   (global-unset-key "\C-x\C-z")
>

In what way is it dangerous? At least on the various Unix and Linux systems
I've used over the years, the worst that happens is that it hides/iconifies
the frame. Just reopen it.

It definitely should not be disabled in tty mode.

Skip

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Skip Montanaro wrote:

>>> It is certainly a dangerous function to have mapped to
>>> such an easy key to hit
>>
>> Agree 100%:
>>
>>   (put 'suspend-frame 'disabled  t)
>>   (global-unset-key "\C-z")
>>   (global-unset-key "\C-x\C-z")
>
> In what way is it dangerous? At least on the various Unix
> and Linux systems I've used over the years, the worst that
> happens is that it hides/iconifies the frame.
> Just reopen it.
>
> It definitely should not be disabled in tty mode.

There _is_ some problem with it, right now I don't remember
what it was but is was very annoying and frustrating.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Marcin Borkowski]

On 2021-02-09, at 01:52, Skip Montanaro <skip.montanaro@gmail.com> wrote:

>>
>> > It is certainly a dangerous function to have mapped to such
>> > an easy key to hit
>>
>> Agree 100%:
>>
>>   (put 'suspend-frame 'disabled  t)
>>   (global-unset-key "\C-z")
>>   (global-unset-key "\C-x\C-z")
>>
>
> In what way is it dangerous? At least on the various Unix and Linux systems
> I've used over the years, the worst that happens is that it hides/iconifies
> the frame. Just reopen it.

It *is* dangerous.  Typing my `C-z whatever' keybinding w/o looking at
the screen and then typing more makes that "more" go to whatever
application the window manager decides to focus on.  In a worst-case
scenario one could be typing e.g. a password into a faceb**k message
(which would be a disaster, though arguably binding `C-z whatever' to
anything that requires subsequent typing of a password is asking for
trouble).

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Proposal: "C-z <letter>" reserved for users

[Skip Montanaro]

>
> It *is* dangerous.  Typing my `C-z whatever' keybinding ...


That, I believe, is on you. If you want to personalize your Emacs
environment, that's fine, but C-z is a perfectly fine keybinding as-is. I
agree it is low-use, but when you need it, you need it. I assume if you
encounter it in some context where it's a surprise, you are either typing
into someone else's Emacs instance (see below) or you ran Emacs with "-q".
If the latter, don't do that except in the rare cases where you are
debugging ELisp problems. If the former, get the other person to type. If
you are using Emacs in a context where you normally don't have your
personal setup available (say, as root on a machine for which you don't
have a login), be careful or use vi. If you do have a login, use "-u". (I
don't know how Emacs works on Windows. My only experience is with Unix,
Linux and MacOS, all of which support using Emacs from a terminal window,
where C-z is an absolute requirement.)

C-z has been there in every version of Emacs I have ever used (Gosling
Emacs, GNU Emacs, XEmacs, jed, microemacs, ...). In fact, while poking
around for a microemacs package on my laptop, I just encountered another
Emacs-like editor for the first time, mg, and installed it on my Raspberry
Pi. Yup, C-z works there as well. C-z is about as fundamental a keybinding
as C-a, C-e, C-f and C-b. If you run "emacs -nw" how do you pause it to get
back to your shell prompt? In fact, C-z works in vi (and less and tar and
rsync and ssh (sort of) ...) as well. There is a very good reason C-z is
bound to suspend-frame.

This thread reminded me of a situation I encountered way BITD when I was
working at GE R&D. We were early adopters of Sun's new fangled
workstations. One group got the ball rolling with Sun-1s (we went to see
it, but Sun hadn't even installed the operating system yet - still, it was
awesome), but most of us began our Unix love affair with the Sun-2 series.
(Before that we were VMS users and most of us software types either used
Gosling Emacs or DEC's screen-oriented editor whose name I've long ago
forgotten.) This incident probably occurred in the Sun-2/Sun-3 era (so,
according to Wikipedia, well before 1990). For some reason, a couple of us
needed to help out another guy we didn't know. (Maybe he was new and we
were helping him with site-specific configuration? I no longer recall.) We
needed to do something with Emacs. He was also an Emacs user, but had so
thoroughly remapped his keybindings that his Emacs instance was completely
unusable by anybody but him. I don't think he had remapped from QWERTY to
Dvorak, but essentially everything not bound to self-insert-command was
different. I don't know why "emacs -q" didn't come to mind. Maybe it was an
already running session? In any case, we had to dictate to him what to do,
because we were unable to use his editor.

Skip

Re: Proposal: "C-z <letter>" reserved for users

[Marcus Harnisch]

On 09/02/2021 13.19, Skip Montanaro wrote:
> C-z has been there in every version of Emacs I have ever used (Gosling
> Emacs, GNU Emacs, XEmacs, jed, microemacs, ...).

FWIW, XEmacs (21.5) changed that binding many years ago (2002, ) to 
#'zap-up-to-char when running in a GUI system. IMHO, this corresponds 
nicely with “M-z”, and was one of the first things that went into my 
init.el when jumping ship.

Kindly,
Marcus

Re: Proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> C-z is about as fundamental a keybinding as C-a, C-e, C-f and C-b. If 
> you run "emacs -nw" how do you pause it to get back to your shell 
> prompt? In fact, C-z works in vi (and less and tar and rsync and ssh 
> (sort of) ...) as well. There is a very good reason C-z is bound to 
> suspend-frame.
>

Which is why the proposal in the "PROPOSAL: Repurpose one key..." thread 
mentions that C-z C-z would be bound by default to suspend-frame.

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings wrote:

>> C-z is about as fundamental a keybinding as C-a, C-e, C-f
>> and C-b. If you run "emacs -nw" how do you pause it to get
>> back to your shell prompt?

Right, that was what happened!

But if you do that, how do you return to Emacs?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Skip Montanaro]

>
> Gregory Heytings wrote:
>
> >> C-z is about as fundamental a keybinding as C-a, C-e, C-f
> >> and C-b. If you run "emacs -nw" how do you pause it to get
> >> back to your shell prompt?
>
> Right, that was what happened!
>
> But if you do that, how do you return to Emacs?
>

On Unix-like systems, the fg built-in command does the trick. Try "man
bash" then search for "^SHELL BUILTIN" or "man fg" (at least on some
systems).

Skip

>

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Skip Montanaro wrote:

> On Unix-like systems, the fg built-in command does the
> trick. Try "man bash" then search for "^SHELL BUILTIN" or
> "man fg" (at least on some systems).

OK!

I just did `suspend-frame' but nothing happened. It only works
on emacs-nw?

I have

  GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
  Version 3.24.5, cairo version 1.16.0) of 2020-10-23

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Skip Montanaro]

>
> I just did `suspend-frame' but nothing happened. It only works
> on emacs-nw?
>
> I have
>
>   GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
>   Version 3.24.5, cairo version 1.16.0) of 2020-10-23


I'm not yet up to v28, but M-x suspend-frame RET does as it would expect
for me. OTOH, In a GUI instance M-x suspend-emacs RET complains that Emacs
can't be suspended while there is a visible frame. It does work for me in
an instance started with -nw. In fact, help on suspend-frame shows that
it's a bit higher level, calling the correct lower level function depending
on environment.


S

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Skip Montanaro wrote:

> On Unix-like systems, the fg built-in command does the
> trick. Try "man bash" then search for "^SHELL BUILTIN" or
> "man fg" (at least on some systems).

fg says 'fg: no job control in this shell'?

And no man page.

fg is indeed a shell built-in so should be mentioned in
zshall(1)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Skip Montanaro]

>
> fg says 'fg: no job control in this shell'?
>
> And no man page.
>
> fg is indeed a shell built-in so should be mentioned in
> zshall(1)


Not using bash(1) I imagine. The man page for zsh(1) references
zshbuiltins(1), which has sections for fg(1) and bg(1).

S

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Skip Montanaro wrote:

>> fg says 'fg: no job control in this shell'?
>>
>> And no man page.
>>
>> fg is indeed a shell built-in so should be mentioned in
>> zshall(1)
>
> [...] The man page for zsh(1) references zshbuiltins(1),
> which has sections for fg(1) and bg(1).

Do you mean this? But it doesn't say anything. How do you
use it?

       fg [ job ... ]
       job ...
              Bring each specified job in turn to the
              foreground. If no job is specified, resume the
              current job.

Besides, fg and bg still just says no job control in
this shell.

`suspend-frame' works BTW. It didn't work before because
of tmux. Without tmux in the plain tty it works. Only I don't
get back to it so have to pkill it instead :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

no job control in this shell (was: Proposal: "C-z <letter>" reserved for users)

[Skip Montanaro]

(sending help-gnu-emacs to bcc as this is kind of out of the realm of
Emacs...)

Emanuel wrote:


> Do you mean this? But it doesn't say anything. How do you
> use it?
>
>        fg [ job ... ]
>        job ...
>               Bring each specified job in turn to the
>               foreground. If no job is specified, resume the
>               current job.
>
> Besides, fg and bg still just says no job control in
> this shell.
>
> `suspend-frame' works BTW. It didn't work before because
> of tmux. Without tmux in the plain tty it works. Only I don't
> get back to it so have to pkill it instead :)


Are you a bash user? The references you posted kind of suggested zsh to me,
but it wasn't clear. If you are using bash, does executing

set -m

allow you to use job control (fg and bg)? When I searched for "no job
control in this shell," that was the suggestion. If I execute

set +m
emacs -nw

I am unable to suspend emacs using C-z, so I suspect that might be what's
going on.

From the documentation for set -m in the bash man page:

              -m      Monitor  mode.   Job control is enabled.  This option
is
                      on by default for interactive  shells  on  systems
 that
                      support  it  (see JOB CONTROL above).  All processes
run
                      in a separate process group.  When a background job
com‐
                      pletes, the shell prints a line containing its exit
sta‐
                      tus.

Skip

Re: no job control in this shell (was: Proposal: "C-z <letter>" reserved for users)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Skip Montanaro wrote:

> The references you posted kind of suggested zsh to me

Yes, zsh.

> If you are using bash, does executing
>
> set -m
>
> allow you to use job control (fg and bg)? When I searched
> for "no job control in this shell," that was the suggestion.
> If I execute
>
> set +m
> emacs -nw

Indeed, that works. It works even without the set and -nw.
`suspend-frame', do something else, jobs, fg JOB back to
Emacs. All of that works, with bash.

I don't need this so we can drop it, just wanted to do it once
to see what was going on.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-09 20:00]:
> Gregory Heytings wrote:
> 
> >> C-z is about as fundamental a keybinding as C-a, C-e, C-f
> >> and C-b. If you run "emacs -nw" how do you pause it to get
> >> back to your shell prompt?
> 
> Right, that was what happened!
> 
> But if you do that, how do you return to Emacs?

You have fg, bg kill %NUMBER comands, that is all shell. Actually C-z
is expectation coming from shell. I did not know that C-z has to be
implemented in Emacs or other software. My opinion was that C-z is
shell control of other software, regardless if that other software
have implemented various key bindings I was thinking shell is in
charge and in authority over programs running in the shell.

So C-z is my expectation to work always. Maybe is not so in reality.

This would invoke job #1 to come into foreground:

$ fg 1

This would invoke job #2 to come into foreground:

$ fg 2

So you could have multiple Emacs sessions or multiple editors in the
same shell and switching between them that way. That is not same as
screen/tmux as suspending a job does not continue execution of the
job.

Jean

Re: Proposal: "C-z <letter>" reserved for users

[Skip Montanaro]

>
> Which is why the proposal in the "PROPOSAL: Repurpose one key..." thread
> mentions that C-z C-z would be bound by default to suspend-frame.
>

Sorry, missed that in my haste I guess.

Re: Proposal: "C-z <letter>" reserved for users

[Francis Belliveau]

I have had it actually "exit" on me when I didn't want it to.
That's what I call dangerous.  I agree that normally it is only Disruptive.

> On Feb 8, 2021, at 19:52, Skip Montanaro <skip.montanaro@gmail.com> wrote:
> 
>> 
>>> It is certainly a dangerous function to have mapped to such
>>> an easy key to hit
>> 
>> Agree 100%:
>> 
>> (put 'suspend-frame 'disabled  t)
>> (global-unset-key "\C-z")
>> (global-unset-key "\C-x\C-z")
>> 
> 
> In what way is it dangerous? At least on the various Unix and Linux systems
> I've used over the years, the worst that happens is that it hides/iconifies
> the frame. Just reopen it.
> 
> It definitely should not be disabled in tty mode.
> 
> Skip

Re: Proposal: "C-z <letter>" reserved for users

[Marcin Borkowski]

On 2021-02-08, at 17:22, Francis Belliveau <f.belliveau@comcast.net> wrote:

> It would be nice for standard distro to not include a c-z binding, since it already exists on a key-sequence binding.
>
> I have remapped c-z to my own key-map, but when I must use emacs without my personal bindings,  continually get messed up by accidental "suspend".

This!  Same here.

-- 
Marcin Borkowski
http://mbork.pl

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Francis Belliveau <f.belliveau@comcast.net> [2021-02-08 23:36]:
> It would be nice for standard distro to not include a c-z binding, since it already exists on a key-sequence binding.
> 
> I have remapped c-z to my own key-map, but when I must use emacs without my personal bindings,  continually get messed up by accidental "suspend".
> 
> It is certainly a dangerous function to have mapped to such an easy key to hit, and my fingers are trained to hit that key a lot for other reasons. 
> I can see where it was once very useful, but much less so in this
> day of GUI's.

Emacs is used on console by millions of people. Console itself defines
C-z as suspend of the job, so C-z is always expecte to suspend the
job for many programs, not only Emacs. Changing it personally may seem
convenient at first sight but is not good solution for global users.

For example if I write:

$ ls -lR /

it may give me long listing of files, and I may want to suspend it, so
C-z works during ls just in the same manner as with Emacs.

Then I may write:

$ jobs

$ jobs
[1]-  Stopped                 emacs -nw -Q
[2]+  Stopped                 ls -F -lR

So I have 2 unfinished jobs on console. I can now decide to continue
with the job #1 or job #2.

Those are common job control commands:
https://en.wikipedia.org/wiki/Job_control_%28Unix%29#Commands

> A job running in the foreground can be stopped by typing the suspend
> character (Ctrl-Z). This sends the "terminal stop" signal (SIGTSTP)
> to the process group. By default, SIGTSTP causes processes receiving
> it to stop, and control is returned to the shell. However, a process
> can register a signal handler for or ignore SIGTSTP. A process can
> also be paused with the "stop" signal (SIGSTOP), which cannot be
> caught or ignored.

So changing the C-z to something else is contrary to defaults that are
on many POSIX and similar system.

I believe that C-z does same thing in many various shells, not only in
Bash.

Job control is important part of computer operation, that is why C-z
shall remain untouched, just how it is now.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Yuri Khan]

On Tue, 9 Feb 2021 at 13:45, Jean Louis <bugs@gnu.support> wrote:

> Emacs is used on console by millions of people. Console itself defines
> C-z as suspend of the job, so C-z is always expecte to suspend the
> job for many programs, not only Emacs.

> Job control is important part of computer operation, that is why C-z
> shall remain untouched, just how it is now.

Why though? I believe when you suspend a program what you really want
is a shell prompt, and you could get that by opening a new tab or pane
in your terminal emulator, or a new screen, window or pane in tmux.

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-02-09 12:11]:
> On Tue, 9 Feb 2021 at 13:45, Jean Louis <bugs@gnu.support> wrote:
> 
> > Emacs is used on console by millions of people. Console itself defines
> > C-z as suspend of the job, so C-z is always expecte to suspend the
> > job for many programs, not only Emacs.
> 
> > Job control is important part of computer operation, that is why C-z
> > shall remain untouched, just how it is now.
> 
> Why though? I believe when you suspend a program what you really want
> is a shell prompt, and you could get that by opening a new tab or pane
> in your terminal emulator, or a new screen, window or pane in tmux.

When considering various options one has to be aware of multiple
global installations of Emacs.

Console is not always terminal emulator under X, or tmux or screen.

Not all computers have those installed. Not evey user can install
those. Majority of students and including professors cannot install
anything on the system. Those installation jobs may be done by system
operators or BOFHs. Emacs may run on multi user systems where users
cannot or need not have any permissions to install additional software
such as screen or tmux.

Then when looking onto the job control in my opinion every program
that runs in shell should provide facilities for job control from
shell. Today there are millions if not billions of installations of
GNU/Linux on various VPSes and dedicated online servers. Personally I
use 4-5 of them and during one month I may change few of them. So many
shell commands and work is done strictly in terminals.

When I am suspending job in shell I may just want to do the other job
while having one running. I may want to use shell and I may want to do
administration with some other software than one suspended.

Suspending jobs in shell is fundamental, single software pieces like
Emacs should not break those year long features.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-02-09 12:11]:
> On Tue, 9 Feb 2021 at 13:45, Jean Louis <bugs@gnu.support> wrote:
> 
> > Emacs is used on console by millions of people. Console itself defines
> > C-z as suspend of the job, so C-z is always expecte to suspend the
> > job for many programs, not only Emacs.
> 
> > Job control is important part of computer operation, that is why C-z
> > shall remain untouched, just how it is now.
> 
> Why though? I believe when you suspend a program what you really want
> is a shell prompt, and you could get that by opening a new tab or pane
> in your terminal emulator, or a new screen, window or pane in tmux.

Another issue with screen and tmux is that switching to different
screen or pane is not same as suspending a job. There are many
different use cases to suspend a job, imagine if I open up new VPS for
video processing and I invoke a command that goes over capacities of
the VPS, maybe everything blocks, I may need C-z to unblock
myself.

Shell job suspended is not same as job running in other shell or other
pane or window as those remain unsuspended and running, while
suspended one stops and do not use resources.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Marcin Borkowski]

On 2021-02-09, at 07:41, Jean Louis <bugs@gnu.support> wrote:

> Job control is important part of computer operation, that is why C-z
> shall remain untouched, just how it is now.

But why bind C-z when Emacs is run under a graphical windowing system?

-- 
Marcin Borkowski
http://mbork.pl

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Marcin Borkowski <mbork@mbork.pl> [2021-02-09 11:07]:
> 
> On 2021-02-09, at 07:41, Jean Louis <bugs@gnu.support> wrote:
> 
> > Job control is important part of computer operation, that is why C-z
> > shall remain untouched, just how it is now.
> 
> But why bind C-z when Emacs is run under a graphical windowing
> system?

From description of `suspend-frame':

Do whatever is right to suspend the current frame.
Calls ‘suspend-emacs’ if invoked from the controlling tty device,
‘suspend-tty’ from a secondary tty device, and
‘iconify-or-deiconify-frame’ from a graphical frame.

It iconifies the window and user can use other windows. That is close
to what C-z does in terminal.

Having C-z do that in X is quite good and harmonized to what C-z does
in the shell.

I do believe that many people do not use that feature and that people
may re-assign C-z to something else. But those are personal
preferences, it would not be good to simple take away C-z from users
as that breaks habits and introduces new problems.

But me for example, I do not use window frames or window icons such as
maximize, minimize, iconify in my Window Manager. I have used various
window managers, now using IceWM. To iconify the window by using mouse
I would need to search in the anyway hidden toolbar for the proper
window, then right mouse click and then minimize. That is
tiresome. Alternative is that I do Alt-F9 that minimizes window.

But then again I am user of various window managers. In other window
manager I would not maybe know or remember what is the key to minimize
the window.

If I only remember C-z for Emacs that works at all times independent
of window manager. My `z' is much closer to my left hand fingers than
Alt-F9 as Window Manager function.

That is why C-z is way better and handier solution to minimize the frame.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> Emacs is used on console by millions of people. Console itself defines 
> C-z as suspend of the job, so C-z is always expecte to suspend the job 
> for many programs, not only Emacs.
>
> [...]
>
> Those are common job control commands: 
> https://en.wikipedia.org/wiki/Job_control_%28Unix%29#Commands
>

As you see on that page, C-c also has a standard meaning, which Emacs 
doesn't follow.  Besides, the proposal binds "C-z C-z" to "frame-suspend".

C-z, C-c, job control commands [was: not good proposal: "C-z <letter>" reserved for users]

[tomas]

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

On Tue, Feb 09, 2021 at 09:13:13AM +0000, Gregory Heytings wrote:
> 
> >
> >Emacs is used on console by millions of people. Console itself
> >defines C-z as suspend of the job, so C-z is always expecte to
> >suspend the job for many programs, not only Emacs.
> >
> >[...]
> >
> >Those are common job control commands:
> >https://en.wikipedia.org/wiki/Job_control_%28Unix%29#Commands
> >
> 
> As you see on that page, C-c also has a standard meaning, which
> Emacs doesn't follow.  Besides, the proposal binds "C-z C-z" to
> "frame-suspend".

I have the hunch (but alas, no evidence) that C-c wasn't as wide
a consensus for "interrupt" back then as it is now. Possibly,
C-g was another contender (which would explain C-g's position
in Emacs today).

Something for the historians.

Cheers
 - t

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

Re: C-z, C-c, job control commands [was: not good proposal: "C-z <letter>" reserved for users]

[Skip Montanaro]

>
> > As you see on that page, C-c also has a standard meaning, which
> > Emacs doesn't follow.  Besides, the proposal binds "C-z C-z" to
> > "frame-suspend".
>
> I have the hunch (but alas, no evidence) that C-c wasn't as wide
> a consensus for "interrupt" back then as it is now. Possibly,
> C-g was another contender (which would explain C-g's position
> in Emacs today).
>

Just a guess, but was C-g a Multics thing? When I first started using GNU
Emacs it didn't always behave nicely. When you wanted to get a crash dump,
I think two C-g key presses in quick succession were the trick.
Fortunately, Emacs is fairly stable now. :-)

Skip

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-09 12:13]:
> 
> > 
> > Emacs is used on console by millions of people. Console itself defines
> > C-z as suspend of the job, so C-z is always expecte to suspend the job
> > for many programs, not only Emacs.
> > 
> > [...]
> > 
> > Those are common job control commands:
> > https://en.wikipedia.org/wiki/Job_control_%28Unix%29#Commands
> > 
> 
> As you see on that page, C-c also has a standard meaning, which Emacs
> doesn't follow.  Besides, the proposal binds "C-z C-z" to "frame-suspend".

The proposal is good for Emacs but not good for shell users. Shell is
fundamental to Emacs, it is foundation. Shell users expect C-z to work
so that other jobs can be run in the shell. Breaking Emacs job is easy
by quitting emacs, that has less priority and I do not assume that
each job control feature has to be implemented in Emacs.

Personal usage pattern is such that often I interrupt jobs in shell
and run them again upon the need. The expectation on how to suspend
the job comes from shell, it does not come from Emacs.

Hard to explain.

Imagine if every shell program would have different job control keys,
that would be hell to remember.

I can suspend vim, I can suspend mg (Emacs replacement), I can suspend
zile, nvi, and mc (Midnight Commander), and I do not know which other
terminal run program I cannot suspend with C-z -- but then for Emacs
proposal says to depart from long year expected feature of the shell
and to break the feauture and to introduce some other key.

That would not be nice. I guess that is introduced by people who do
not use job control in shell, for them personally it does not matter,
but think of millions of Emacs users, they may expect it.

I don't think such things that are fundamental or features that have
been implemented for years should be questioned. Anyway I will agree
to whatever developers wish and want.

Some people have good computer, not everybody has. I have Lenovo T410
that I use to process videos and commands are run through Emacs
Lisp. I may invoke the command and heat computer so much that if I
invoke other program it goes into shutdown. I guess it is some feature
of overheating. I may need to suspend Emacs not to do anything, so
that I can run some other program in background. Video processing may
take sometimes days. I do not think that many users process videos by
using Emacs Lisp, but that is how I do it. If process is interrupted
than I have to manually find the interrupted file, that is not easy
but I did some measures on how to find it easier. I may invoke video
processing in multiple directories though I try to avoid that. And
Emacs Lisp command is doing it one by one, not in parallel as not to
give much burden to CPU and again invoke overheating. Thus suspending
does make sense for me.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Marcin Borkowski]

On 2021-02-10, at 11:36, Jean Louis <bugs@gnu.support> wrote:

> * Gregory Heytings <gregory@heytings.org> [2021-02-09 12:13]:
>> 
>> > 
>> > Emacs is used on console by millions of people. Console itself defines
>> > C-z as suspend of the job, so C-z is always expecte to suspend the job
>> > for many programs, not only Emacs.
>> > 
>> > [...]
>> > 
>> > Those are common job control commands:
>> > https://en.wikipedia.org/wiki/Job_control_%28Unix%29#Commands
>> > 
>> 
>> As you see on that page, C-c also has a standard meaning, which Emacs
>> doesn't follow.  Besides, the proposal binds "C-z C-z" to "frame-suspend".
>
> The proposal is good for Emacs but not good for shell users. Shell is
> fundamental to Emacs, it is foundation. Shell users expect C-z to work
> so that other jobs can be run in the shell. Breaking Emacs job is easy
> by quitting emacs, that has less priority and I do not assume that
> each job control feature has to be implemented in Emacs.

It just occurred to me that maybe we can have the pie and eat it, too:
why not designate `suspend-frame' as disabled by default?  Many Emacs
commands which may be confusing for beginners are set up this way, and
that makes sense - a seasoned user can easily enable a command (for the
current session or for all of them), you don't even have to write
a single line of Elisp for that.  This way we remove (or at least
reduce) the danger for someone who does not know what `C-z' does.

WDYT?

-- 
Marcin Borkowski
http://mbork.pl

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Marcin Borkowski <mbork@mbork.pl> [2021-02-10 15:46]:
> 
> On 2021-02-10, at 11:36, Jean Louis <bugs@gnu.support> wrote:
> 
> > * Gregory Heytings <gregory@heytings.org> [2021-02-09 12:13]:
> >> 
> >> > 
> >> > Emacs is used on console by millions of people. Console itself defines
> >> > C-z as suspend of the job, so C-z is always expecte to suspend the job
> >> > for many programs, not only Emacs.
> >> > 
> >> > [...]
> >> > 
> >> > Those are common job control commands:
> >> > https://en.wikipedia.org/wiki/Job_control_%28Unix%29#Commands
> >> > 
> >> 
> >> As you see on that page, C-c also has a standard meaning, which Emacs
> >> doesn't follow.  Besides, the proposal binds "C-z C-z" to "frame-suspend".
> >
> > The proposal is good for Emacs but not good for shell users. Shell is
> > fundamental to Emacs, it is foundation. Shell users expect C-z to work
> > so that other jobs can be run in the shell. Breaking Emacs job is easy
> > by quitting emacs, that has less priority and I do not assume that
> > each job control feature has to be implemented in Emacs.
> 
> It just occurred to me that maybe we can have the pie and eat it, too:
> why not designate `suspend-frame' as disabled by default?  Many Emacs
> commands which may be confusing for beginners are set up this way, and
> that makes sense - a seasoned user can easily enable a command (for the
> current session or for all of them), you don't even have to write
> a single line of Elisp for that.  This way we remove (or at least
> reduce) the danger for someone who does not know what `C-z' does.

From shell point of view C-z shall suspend the job. I do not even
consider C-z being Emacs-based but now I assume it is decision of
Emacs to keep C-z as how it should be in the shell. When opening a new
VPS to process various jobs one would then need to first configure
Emacs to have job control working. That is not useful. It would break
many habits and expected behavior.

There is no danger in shell as C-z almost in all cases means "suspend
job". Any other editor I know in shell is suspended by C-z.

Removing job control to shell users cannot be called a feature, it is
anti-feature.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> There is no danger in shell as C-z almost in all cases means
> "suspend job". Any other editor I know in shell is suspended
> by C-z.

The other day I wrote that it didn't work with tmux. But that
was incorrect, it was zsh that made it not work.

With bash, it works both ways (`suspend-frame', then fg) in
a plain Linux VT (tty) but also in a VT with tmux on top.

In zsh, suspend-frame doesn't work in a tmux pane but it does
work with a plain tty. However fg still doesn't work, it says
the by-now familiar 'no job control in this shell'.

zsh should be one of the more common shells these days, while
not as common as bash, of course. Still common enough to make
one hesitant about the degree of standardization in this case.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-10 22:33]:
> Jean Louis wrote:
> 
> > There is no danger in shell as C-z almost in all cases means
> > "suspend job". Any other editor I know in shell is suspended
> > by C-z.
> 
> The other day I wrote that it didn't work with tmux. But that
> was incorrect, it was zsh that made it not work.
> 
> With bash, it works both ways (`suspend-frame', then fg) in
> a plain Linux VT (tty) but also in a VT with tmux on top.
> 
> In zsh, suspend-frame doesn't work in a tmux pane but it does
> work with a plain tty. However fg still doesn't work, it says
> the by-now familiar 'no job control in this shell'.
> 
> zsh should be one of the more common shells these days, while
> not as common as bash, of course. Still common enough to make
> one hesitant about the degree of standardization in this case.

What I know is that I learned job control very early when learning
about the shell and I use it frequently. I do expect from each shell
program to allow me to suspend it. Those running and listing programs
must be also interruptable. And I also expect to be able to stop the
output by using Control-S. This I am writing here not related to
Emacs, but to give user experience testimony. That is how I have
worked over last decades.

Related to zsh:
http://zsh.sourceforge.net/Doc/Release/Jobs-_0026-Signals.html

Re: not good proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> From shell point of view C-z shall suspend the job. I do not even 
> consider C-z being Emacs-based but now I assume it is decision of Emacs 
> to keep C-z as how it should be in the shell. When opening a new VPS to 
> process various jobs one would then need to first configure Emacs to 
> have job control working. That is not useful. It would break many habits 
> and expected behavior.
>

The proposal in this thread has little to do with the proposal in the 
"PROPOSAL: Repurpose one key..." thread.  In that proposal it is 
explicitly stated that C-z C-z would be bound to "suspend-frame".  IOW, 
all you'd have to do is to press three keys instead of two to suspend. 
Repeating a key until it produces the desired effect is something terminal 
users are used to do, for example, repeating C-c until the program aborts.

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-10 22:31]:
> > From shell point of view C-z shall suspend the job. I do not even
> > consider C-z being Emacs-based but now I assume it is decision of Emacs
> > to keep C-z as how it should be in the shell. When opening a new VPS to
> > process various jobs one would then need to first configure Emacs to
> > have job control working. That is not useful. It would break many habits
> > and expected behavior.
> 
> The proposal in this thread has little to do with the proposal in the
> "PROPOSAL: Repurpose one key..." thread.  In that proposal it is explicitly
> stated that C-z C-z would be bound to "suspend-frame".  IOW, all you'd have
> to do is to press three keys instead of two to suspend. Repeating a key
> until it produces the desired effect is something terminal users are used to
> do, for example, repeating C-c until the program aborts.

I understand you wish to use C-z as prefix for more functions, is it?

Is that the only key?

Maybe you are always on the US keyboard, but I am not. I travel in
development countries and may use Norwegian, German, Croatia or US and
US-like keyboards, and such keyboards do not have always Z and Y on
same place, they are exchangeable. It is not really handy and
practical to remember and get used to it, especially for people using
multiple computers.

Why not repurpose C-0 to C-9 as that could be anyway used with C-u 9
for example, and then C-0 to C-9 could become various prefix keys.

C-0 0 or/and C-0 C-0 could become same as what is now C-0 while
keeping all those C-0 to C-9 as various prefix keys.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> Why not repurpose C-0 to C-9 as that could be anyway used with C-u 9 for 
> example, and then C-0 to C-9 could become various prefix keys.
>

Because C-0 ... C-9 cannot be used in a terminal / console.

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> From shell point of view C-z shall suspend the job. I do not even 
>> consider C-z being Emacs-based but now I assume it is decision of Emacs 
>> to keep C-z as how it should be in the shell. When opening a new VPS to 
>> process various jobs one would then need to first configure Emacs to 
>> have job control working. That is not useful. It would break many habits 
>> and expected behavior.
>>
>
> The proposal in this thread has little to do with the proposal in the 
> "PROPOSAL: Repurpose one key..." thread.  In that proposal it is 
> explicitly stated that C-z C-z would be bound to "suspend-frame".  IOW, 
> all you'd have to do is to press three keys instead of two to suspend. 
> Repeating a key until it produces the desired effect is something terminal 
> users are used to do, for example, repeating C-c until the program aborts.

Here are my opinions on these things.

* Moratorium on New Emacs Keybindings.

At present there's lot of work going on outside of core Emacs.  I think
it makes sense for core Emacs not to use too many keybindings.  I can
see the sense the argument Drew Adams makes.

If a *general* moratorium isn't possible, then how about a more specific
one?  How about applying it only to certain keymaps or prefix keys.


* A Prefix-Key for Global Third-Party Packages.

I think this is a good idea too.  Picking the right key is a problem.

There is another issue....  I'm not sure that third-party packages will
use the feature.  I'm also on the Reddit Emacs group.  Several of the
people there use and develop third-party packages.  It seems to me that
they often do that because they don't want to contribute to core.  Some
don't like the core Emacs development team and don't  agree with their
direction for Emacs.  So, would they use such a prefix key if it were
offered?  Perhaps not.

It woud be a feature for those 3rd-party package authors who want to
co-operate with the core Emacs devs.  I don't know how many of those
there are, but I doubt it's all of them.

** Which Key to Use?

Like Jean Louis, I think that the suggestion of changing C-z is awful.
I use it all the time.  Like Jean said it's expected in Unix like
environments.

Of the keys suggested I think the best is "M-o" since it's current
default binding isn't very useful.


* Pop-Up Message Asking the User on Adding Keybindings.

I think this is a fairly good idea.  The question is whether package
authors will use it, like the prefix-key idea.

Also the code would have to be written.


BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Joost Kremers]

On Thu, Feb 11 2021, Robert Thorpe wrote:
> Here are my opinions on these things.
>
> * Moratorium on New Emacs Keybindings.
>
> At present there's lot of work going on outside of core Emacs.  I think
> it makes sense for core Emacs not to use too many keybindings.  I can
> see the sense the argument Drew Adams makes.

Since it's really easy in Emacs to (re)bind keys, I don't really see this as
much of a problem. (Mind you, I'm firmly of the conviction that external
packages should *not* create any global bindings.)

> If a *general* moratorium isn't possible, then how about a more specific
> one?  How about applying it only to certain keymaps or prefix keys.

Which would be equivalent to reserving more keys for users to bind, right?

> * A Prefix-Key for Global Third-Party Packages.
>
> I think this is a good idea too.  

I've explained elsewhere[1] why I think this is not a good idea. Basically, I
don't see a problem here that couldn't be solved much more easily by updating
the keybinding conventions to say that external packages should not create any
global bindings by default.

Reserving keys for external packages means that Emacs needs some way to deal
with conflicting external key bindings, which will inevitably arise. (My own
packages don't create any global bindings, but I'd be very tempted to add them
if this becomes official policy, because it will be what users will come to
expect, and I suspect I won't be the only 3rd-party package maintainer that
feels that way.)

So you'd have to come up with a new function that creates global key bindings,
but checks first to make sure the keys are still free (which, BTW, means the
order in which packages are loaded becomes relevant) and pop up a warning asking
the user what to do if they're not. This choice then has to be saved somewhere,
presumably in `custom-set-variables`.

You'd probably also need to add a customisation option to completely disable
creating 3rd-party global bindings to keep grumpy old (and maybe not so old) men
and women like me happy. Or, to put that in a more positive way: I prefer to
keep my global key bindings in my init file together with the code that loads
the relevant package and not have to consider whether a 3rd-party package messes
with my key bindings somewhere.

Anyway, I feel that you'd end up with a system that is more complex than
necessary for the problem it tries to solve, which isn't that big to begin with
(IMHO, of course).

> There is another issue....  I'm not sure that third-party packages will
> use the feature.  I'm also on the Reddit Emacs group.  Several of the
> people there use and develop third-party packages.  It seems to me that
> they often do that because they don't want to contribute to core.  Some
> don't like the core Emacs development team and don't  agree with their
> direction for Emacs.  So, would they use such a prefix key if it were
> offered?  Perhaps not.

Since it would not only a concession to the Emacs development team but also a
courtesy to one's users, I suspect many package developers will cooperate. Some
won't, of course, but that will always be the case, no matter what solution is
adopted.

Joost



Footnotes:
[1]  https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00365.html

-- 
Joost Kremers
Life has its moments

Re: not good proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> Basically, I don't see a problem here that couldn't be solved much more 
> easily by updating the keybinding conventions to say that external 
> packages should not create any global bindings by default.
>

IMO that would be the worst possible solution, and would be an extremely 
negative signal towards third-party library developers.  Do you remember 
that Emacs is an _extensible_ editor?  See 
https://www.gnu.org/software/emacs/emacs-paper.html .

Why shouldn't an extension package for a general-purpose editor (not 
necessarily Emacs, think Atom or Sublime or...) change the user interface 
of that editor when it is installed?

>
> Reserving keys for external packages means that Emacs needs some way to 
> deal with conflicting external key bindings, which will inevitably 
> arise.
>

Yes, and this has been acknowledged from the outset.  It's a different 
problem however, these are conflicts between external packages, not 
between an external package and Emacs core or between an external package 
and users' personal bindings.  And, as you yourself say, these conflicts 
can be handled by specific functions, in a user-friendly way.  It can also 
be expected that best practices will arise by themselves, like "using as 
few keys as possible", "using a keymap on a single key if possible", "not 
using the same keys as an existing major package", "use the 4 key for 
commands in other-window and the 5 key for commands in other-frame", ...

Re: not good proposal: "C-z <letter>" reserved for users

[Joost Kremers]

On Thu, Feb 11 2021, Gregory Heytings wrote:
>>
>> Basically, I don't see a problem here that couldn't be solved much more 
>> easily by updating the keybinding conventions to say that external 
>> packages should not create any global bindings by default.
>
> IMO that would be the worst possible solution, and would be an extremely 
> negative signal towards third-party library developers.

Why? It's been my interpretation of the intent of the key binding conventions
and as a package maintainer I have never been bothered by it. In fact, I see it
as a courtesy to the users of my packages that I do not stomp on whatever key
bindings they may have set already.

So I guess this comes down to very different views we have about what
constitutes "user-friendly" in this particular case.

>  Do you remember 
> that Emacs is an _extensible_ editor? 

[I had a hostile reaction here to what I perceived to be a hostile remark from
you. If that was a reaction to something I said, I apologise.]

> Why shouldn't an extension package for a general-purpose editor (not 
> necessarily Emacs, think Atom or Sublime or...) change the user interface 
> of that editor when it is installed?

It depends on the change and the purpose of the package. Global key bindings are
a limited resource, which is why I'd expect 3rd-party packages of any editor to
be conservative about creating new ones. Same thing with the top-level menu,
especially if a package wants to add a new item that is permanently visible.
Adding a menu entry to an existing (sub)menu is fine, since they're more
flexible (they can scroll, for example), but there, too, I'd expect 3rd-party
packages to tread carefully (e.g., if you want to add a dozen new entries, then
maybe put them together in a new submenu).

For packages whose primary purpose is to change the user interface, it's
different, of course. An Emacs package that exists to change global key bindings
(evil comes to mind) are fine, because the user installs them for that purpose.
But I don't install Magit to change my UI.

Now, I've never used any other editor than Emacs (not seriously, anyway), but
when I look at screen casts of people using Atom or PyCharm or something,
they're clicking their way through the interface with skill and accuracy. If I
were such a user, I wouldn't want an external package to suddenly change my
menus for me, especially if part of the appeal of the editor I'm using is the
fact that I can modify and lay out the menus in exactly the way I like. (I don't
know if that's the case with Atom or Sublime or VSCode or any of the other
editors out there, because, as I said, I've never used them.)

>> Reserving keys for external packages means that Emacs needs some way to 
>> deal with conflicting external key bindings, which will inevitably 
>> arise.
>
> Yes, and this has been acknowledged from the outset.  It's a different 
> problem however, these are conflicts between external packages, not 
> between an external package and Emacs core or between an external package 
> and users' personal bindings.

I don't really see it as a different problem. To me it's immaterial whether
there's a conflict between Emacs and an external package, between two external
packages or between a user's bindings and an external package; they're all
conflicts caused by an external package creating a global key binding.

>  And, as you yourself say, these conflicts 
> can be handled by specific functions, in a user-friendly way.

Yes. But the argument isn't that conflicts will arise. The argument is that in
order to handle them properly, we need a system that is more complex than the
alternative. And, in my opinion, too complex for the problem at hand.

You obviously feel differently, which is fine. After all, in the end, what you
or I feel isn't all that important. Just two more data points for the Emacs
developers to make a decision.

-- 
Joost Kremers
Life has its moments

Re: not good proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> [I had a hostile reaction here to what I perceived to be a hostile 
> remark from you. If that was a reaction to something I said, I 
> apologise.]
>

I admit I don't know which is the remark you perceived as a hostile one. 
Be assured that being hostile wasn't my intention; I try hard to not make 
any hostile remarks.

>>> Reserving keys for external packages means that Emacs needs some way 
>>> to deal with conflicting external key bindings, which will inevitably 
>>> arise.
>>
>> Yes, and this has been acknowledged from the outset.  It's a different 
>> problem however, these are conflicts between external packages, not 
>> between an external package and Emacs core or between an external 
>> package and users' personal bindings.
>
> I don't really see it as a different problem. To me it's immaterial 
> whether there's a conflict between Emacs and an external package, 
> between two external packages or between a user's bindings and an 
> external package; they're all conflicts caused by an external package 
> creating a global key binding.
>

Under the postulate that external packages should not create any global 
bindings, it's indeed the same problem ;-)

Re: not good proposal: "C-z <letter>" reserved for users

[Joost Kremers]

On Fri, Feb 12 2021, Gregory Heytings wrote:
>>
>> [I had a hostile reaction here to what I perceived to be a hostile 
>> remark from you. If that was a reaction to something I said, I 
>> apologise.]
>>
>
> I admit I don't know which is the remark you perceived as a hostile one. 

The one I quoted:

>>> Do you remember that Emacs is an _extensible_ editor? 

My first reaction was "Yes, of course I remember, thank you very much".

> Be assured that being hostile wasn't my intention; I try hard to not make 
> any hostile remarks.

Yes, I should have assumed that right away. I actually feel a little silly now
for bringing it up. 

>> I don't really see it as a different problem. [...]
>
> Under the postulate that external packages should not create any global 
> bindings, it's indeed the same problem ;-)

Hey, we agree on something! I guess that's progress. ;-)

-- 
Joost Kremers
Life has its moments

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Joost Kremers wrote:

>> Under the postulate that external packages should not
>> create any global bindings, it's indeed the same problem
>> ;-)
>
> Hey, we agree on something! I guess that's progress. ;-)

Maybe compile a list of what external "packages" and files
should and shouldn't do...?

But I remember something like that from the docs...

Also incorporate into (checkdoc-current-buffer t) if whatever
you come up with isn't there already.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Joost Kremers <joostkremers@fastmail.fm> writes:

> On Thu, Feb 11 2021, Robert Thorpe wrote:
>> Here are my opinions on these things.
>>
>> * Moratorium on New Emacs Keybindings.
>>
>> At present there's lot of work going on outside of core Emacs.  I think
>> it makes sense for core Emacs not to use too many keybindings.  I can
>> see the sense the argument Drew Adams makes.
>
> Since it's really easy in Emacs to (re)bind keys, I don't really see this as
> much of a problem. (Mind you, I'm firmly of the conviction that external
> packages should *not* create any global bindings.)
>
>> If a *general* moratorium isn't possible, then how about a more specific
>> one?  How about applying it only to certain keymaps or prefix keys.
>
> Which would be equivalent to reserving more keys for users to bind, right?

On this issue I agree with Gregory Heytings.

I think that user-friendliness is beneficial.  It would help with
that if packages could bind some keys by default.

Yes, it makes it more complex for those of us who don't want that.  But
we've learned how to use Emacs and we know how to fix it.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 12.02.2021 10:10, Robert Thorpe wrote:
> I think that user-friendliness is beneficial.  It would help with
> that if packages could bind some keys by default.

The current tradition is that a package provides a major or minor mode 
(or several), puts one of them in their init file, and *those* install 
some default keymaps.

auto-mode-alist entries, however, can be added through autoloads.

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 12.02.2021 10:10, Robert Thorpe wrote:
>> I think that user-friendliness is beneficial.  It would help with
>> that if packages could bind some keys by default.
>
> The current tradition is that a package provides a major or minor mode 
> (or several), puts one of them in their init file, and *those* install 
> some default keymaps.
>
> auto-mode-alist entries, however, can be added through autoloads.

Yes.  But I don't think that solves the problems that Gregory Heyting
and Drew Adams are talking about.

Firstly, it can't do anything about changes in keybindings in future
Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
"C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
been mapped for Emacs 28 (or perhaps the version after that).

The author of a third party package can't easily deal with that.  What if
their minor mode used "C-x x"?  In that case it will remove the keymaps
of a core feature (or the core feature will remove it's keymap).

As Gregory Heyting has pointed out, what about packages that are not
modes?  Not every package is a minor mode or major mode.  So, how should
other types of package behave?

Lastly, the usability issue is still there.  I think beginners find this
kind of thing difficult.  These days there are lots of Emacs "starter
kits" that claim to make Emacs simpler.  A lot of what they do is
configuring third-party packages.

Philip Kaludercic suggested some code for prompting users before mapping
keys.  I think that's a good idea.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Robert Thorpe <rt@robertthorpeconsulting.com> [2021-02-13 10:38]:
> Firstly, it can't do anything about changes in keybindings in future
> Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
> "C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
> been mapped for Emacs 28 (or perhaps the version after that).
> 
> The author of a third party package can't easily deal with that.  What if
> their minor mode used "C-x x"?  In that case it will remove the keymaps
> of a core feature (or the core feature will remove it's keymap).

Instead of solving hypothetical problems, let us list third party
packages and any complaints practically and specifically and suggest
possible solutions to those specific problem.

I have my personal packages and I never had problem of key
reservation. The prefix key is on `s-p' and recently I have placed it
also on `C-c p' and also on F5. I would not bind it globally and
automatically for users, rather ecommend that users decide where to
bind the prefix key.

Helm package does it this way:

(defcustom helm-command-prefix-key "C-x c"

so users could change that prefix to anything they wish and want while
Helm has already provided a default. Helm has no problem how I see it.

Which packages have the problem with Emacs and need reservation?

> Lastly, the usability issue is still there.  I think beginners find this
> kind of thing difficult.

That will always be the case for beginners within or without Emacs
subject. They are beginners. We were all beginners and may find this
or that difficult when beginning new things.

> These days there are lots of Emacs "starter kits" that claim to make
> Emacs simpler.  A lot of what they do is configuring third-party
> packages.

One group of users will find that simpler one group will not. Variety
of users find this or that simpler, we can see from our conversations
here. What may be simple for you may be complex for me and so on.

> Philip Kaludercic suggested some code for prompting users before mapping
> keys.  I think that's a good idea.

That would be good idea. It would be good if packages would be advised
how to bind keys and to provide alternatives if some of the keys are
already bound by users. One can use the below function.

key-binding is a built-in function in ‘C source code’.

(key-binding KEY &optional ACCEPT-DEFAULT NO-REMAP POSITION)

Then the function (key-binding (kbd "s-p p")) yields at my side with
`cf-tabulated-people'. It could be used to detect which key is already
bound and then the configuration wizard could ask or suggest to user
how otherwise to bind the keys.

It could say that prefix key for the package could be placed on
{C-c j} or {C-c k} and could ask user to accept it, it would be then
entered into the configuration file.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> It would be good if packages would be advised how to bind
> keys and to provide alternatives if some of the keys are
> already bound by users. One can use the below function.

Good idea, but like I said, there is a whole section of such
conventions in the docs. I'll look for it...

> key-binding is a built-in function in ‘C source code’.
>
> (key-binding KEY &optional ACCEPT-DEFAULT NO-REMAP POSITION)
>
> Then the function (key-binding (kbd "s-p p")) yields at my
> side with `cf-tabulated-people'. It could be used to detect
> which key is already bound and then the configuration wizard
> could ask or suggest to user how otherwise to bind the keys.

Indeed, the byte compiler, checkdoc and/or the docstrings
should reflect these conventions, and the more interactively,
and the less RTFM/tl;dr, the better.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

RE: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Drew Adams]

> >> I think that user-friendliness is beneficial.  It would help with
> >> that if packages could bind some keys by default.
> >
> > The current tradition is that a package provides a major or minor
> mode
> > (or several), puts one of them in their init file, and *those*
> install
> > some default keymaps.
> >
> > auto-mode-alist entries, however, can be added through autoloads.
> 
> Yes.  But I don't think that solves the problems that Gregory Heyting
> and Drew Adams are talking about.
> 
> Firstly, it can't do anything about changes in keybindings in future
> Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
> "C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
> been mapped for Emacs 28 (or perhaps the version after that).

To be clear, my understanding, from following bug
and emacs-devel threads, is as follows.  Anyone
can correct me if I'm mistaken in any way.

1. `C-x p' was recently grabbed as a prefix key
for Project (by Dmitry, in fact) - over my pleas
and arguments not to.  That was maybe 8 months ago?

Bookmark+ had, for many years, lots and lots of
keys on that prefix key.  The only arguments by
Dmitry in favor of grabbing that key for Project
were, in effect, (a) we want to do it and (b) we
don't need to care what Bookmark+ has been using.
OK.

As a result of that, I changed Bookmark+ last July
to use `C-x x' instead.  (There was no mention of
`C-x x' in that discussion, and it was unbound.)

2. Recently, Lars decided to bind `revert-buffer'
to `C-x x g'.  There was subsequent discussion
about using that prefix key `C-x x' for things
related to buffers, in general.  I don't know
exactly what's been done in that regard.

Needless to say, I again objected, saying that
I've moved Bookmark+ keys from prefix `C-x p' to
`C-x x', and asking that they not now usurp also
`C-x x'.  But AFAIK, `C-x x' has, yes, now been
grabbed by Emacs as a default global binding.

(There was quite a lot of objection, BTW, to the
idea that Emacs needs a _global_ key for reverting
a buffer.  I'm not even sure there was _anyone_
arguing in favor of that, besides the maintainer
who came up with the idea.)

3. There was talk in emacs-devel (or a bug thread?)
about binding `C-x /' by default.  I don't know
what finally happened in that regard.  But I chimed
in about that too, saying that I use that prefix key
for zones.el.  I mentioned this while pointing out
there is a _general_ problem here: Emacs grabbing
more keys for default bindings, leaving 3rd-party
code with fewer and fewer options.

4. I'll mention too that for Bookmark+ when I
changed from `C-x p' to `C-x x' I added a user
option for which key to use.  So users can deal
with the new conflict themselves, if I don't
end up trying yet another key as the default.

> The author of a third party package can't easily
> deal with that.  What if their minor mode used
> "C-x x"?  In that case it will remove the keymaps
> of a core feature (or the core feature will remove
> it's keymap).

Indeed.  And the anecdotal stories from me are
just that: one user's experience.  There's a long
history (future) in front of us.  This problem
will only become exacerbated.  The field of keys
that are not used by default Emacs is small and
dwindling.  And that, precisely at a time when the
development of 3rd-party libraries is growing.

We are no longer in the old Wild West days of a
vast, open new continent to colonize.

_Some_ solution is needed for this problem, which
will only increase.  _Because_ I objected recently,
raising this as a general problem, there has been
some discussion.  But the main Emacs maintainer has
declared that there is _no_ such problem.  End of
story, perhaps, but not, IMO, end of problem.

I proposed one possible solution - a _moratorium_
by Emacs from grabbing more keys by default.  Look
up the word "moratorium", if you aren't familiar
with it.

If you like, you can consider my proposal to be:
Let's at least STOP now from binding any more keys
by default, while we entertain discussion for other
possible solutions.  And as long as no adequate
solution, preferably somewhat consensual, is found,
Emacs just shouldn't bind more keys.  It can
repurpose keys that are already bound by default,
but it should stay away from binding new ones.

And I explicitly allowed for _exceptions_, to be
decided by the maintainers - after some general
discussion.  So IMO, this is not at all a radical
proposal.  It's essentially "STOP THE BLEEDING!"
as a _first step_.

> As Gregory Heyting has pointed out, what about
> packages that are not modes?  Not every package
> is a minor mode or major mode.

In fact, I'm pretty sure that most - maybe all -
libraries are not simply implementations of a mode.

Dealing with a mode, especially in terms of key
bindings, isn't really problematic.  Especially a
minor mode.  Sure, there can still be some key
conflicts, but that's nothing new.  Users juggle
multiple minor modes already.

> So, how should other types of package behave?
> 
> Lastly, the usability issue is still there.
> I think beginners find this kind of thing difficult.
> These days there are lots of Emacs "starter kits"
> that claim to make Emacs simpler.  A lot of what
> they do is configuring third-party packages.
> 
> Philip Kaludercic suggested some code for prompting
> users before mapping keys.  I think that's a good idea.

Maybe that could be part of a solution.  But many
users will not appreciate, or not be prepared for,
making such key-binding decisions at the outset and
on the fly.  And prompting would likely be in some
order, e.g., the first package loaded would prompt
first, or the first prompt would occur when the
first key conflict is detected.

There are lots of details and things to consider.
But I'm glad that at least some people are seriously
considering the problem and starting to think about
it.

Unfortunately, the main threads in emacs-devel about
this, kind of got hijacked by interjecting the
possibility of changing some existing Emacs default
key bindings.  I specifically wanted to avoid that,
or rather, to move that to a parallel, and longer
discussion.

I really would like to see us, FIRST, stop the
bleeding by agreeing that Emacs should stop binding
default keys while we figure things out and, SECOND,
start discussing solutions in parallel, with less
urgency, carefully.  And that discussion can, yes,
consider particular _existing_ key bindings and
possibilities of refactoring Emacs default key
bindings.

But the first step should be to agree to stop the
bleeding: "Emacs: hands-off new default keys, please."

Re: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-13 23:49]:
> To be clear, my understanding, from following bug
> and emacs-devel threads, is as follows.  Anyone
> can correct me if I'm mistaken in any way.
> 
> 1. `C-x p' was recently grabbed as a prefix key
> for Project (by Dmitry, in fact) - over my pleas
> and arguments not to.  That was maybe 8 months ago?
> 
> Bookmark+ had, for many years, lots and lots of
> keys on that prefix key.  The only arguments by
> Dmitry in favor of grabbing that key for Project
> were, in effect, (a) we want to do it and (b) we
> don't need to care what Bookmark+ has been using.
> OK.

Basically, the attempt to reserve some keys which were already in use
by third party packages did not work well and you participate in
mailing lists. Does Magit author participate too? As now it looks like
much attention is given to Magit but to me it looks like none of them
who are authors requested any favor from Emacs to reserve it for them.

I have just done M-x rgrep and found that many installed packages
simply suggest global key bindings, just few of them really bind it.

> 4. I'll mention too that for Bookmark+ when I
> changed from `C-x p' to `C-x x' I added a user
> option for which key to use.  So users can deal
> with the new conflict themselves, if I don't
> end up trying yet another key as the default.

That looks good as solution. Packages rather make the key maps and
then simple function could suggest few of key bindings and detect
which one is already bound to which keys and then suggest the menu or
choice where to place the prefix key.

Function could accept a list of various suggested prefix keys and then
verify each key if it is bound to something, and present the listing
let us say from 1 to 10 where keys are presented and displayed as
being bound. User can then choose to unbind specific key or use those
free keys as prefix for the package. If series of keys is not enough
at some point of time, new versions of the package could employ newer
or updated list.

(global-set-key-prefix-by-choice '("C-c p" "C-c o" "C-c j" "C-x x" "C-x /" "M-z"))

Then it could be presented as:

1. C-c p - free as prefix key, press [1] to select
2. C-c o - free as prefix key, press [2] to select
3. C-c j - free as prefix key, press [3] to select
4. C-x x - bound to `some-other-function', press [4] to select
5. C-x / - bound to `one-more-function', press [5] to select
6. M-z   - bound to `zap-to-chat', press [6] to select

Are you sure? Yes?

If you wish to customize the prefix key again for this package, run
M-x customize-prefix-for-package-X

> I proposed one possible solution - a _moratorium_
> by Emacs from grabbing more keys by default.  Look
> up the word "moratorium", if you aren't familiar
> with it.

* Overview of noun moratorium

The noun moratorium has 2 senses (no senses from tagged texts)
1. moratorium -- (a legally authorized postponement before some obligation must be discharged)
2. moratorium -- (suspension of an ongoing activity)

So you suggest suspension of grabbing more keys? That sounds good idea
to me as well. There is no urgent need for that. That is why there are
reserved C-c keys, users can bind those new functions. If there is
some important function to be bound than that could or should be
solved with discussion.

> If you like, you can consider my proposal to be:
> Let's at least STOP now from binding any more keys
> by default, while we entertain discussion for other
> possible solutions.  And as long as no adequate
> solution, preferably somewhat consensual, is found,
> Emacs just shouldn't bind more keys.  It can
> repurpose keys that are already bound by default,
> but it should stay away from binding new ones.

Maybe it will work the other way around, you start proposing to bind
more keys by default, maybe that can work better? I am not joking too
much. When pushing too much one thing in public space there is effect
that people may want the other thing (not being pushed one). Start
pushing the opposite, maybe that suddenly start working and keys stop
being bound.

> I really would like to see us, FIRST, stop the
> bleeding by agreeing that Emacs should stop binding
> default keys while we figure things out and, SECOND,
> start discussing solutions in parallel, with less
> urgency, carefully.  And that discussion can, yes,
> consider particular _existing_ key bindings and
> possibilities of refactoring Emacs default key
> bindings.
> 
> But the first step should be to agree to stop the
> bleeding: "Emacs: hands-off new default keys, please."

If I have understood it well, maybe I may be mistaken, but the
discussion to reserve the key yieled intentionall or not intentionally
with proposals to bind range of new keys. I am not sure if implemented
already, but I have seen the list. That is why, how about stop pushing
to bind keys and demand more bindings, maybe that causes less
bindings?

Jean

Re: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 13.02.2021 22:48, Drew Adams wrote:
> 4. I'll mention too that for Bookmark+ when I
> changed from `C-x p' to `C-x x' I added a user
> option for which key to use.  So users can deal
> with the new conflict themselves, if I don't
> end up trying yet another key as the default.

It's a pretty good approach, isn't it?

Overall, the user response to finally having some default bindings to 
project commands have been quite positive.

But those users who don't think the project- package is important enough 
can override the 'C-x p' binding and use it for Bookmark+.

Re: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Philip Kaludercic]

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

Drew Adams <drew.adams@oracle.com> writes:

>> Yes.  But I don't think that solves the problems that Gregory Heyting
>> and Drew Adams are talking about.
>> 
>> Firstly, it can't do anything about changes in keybindings in future
>> Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
>> "C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
>> been mapped for Emacs 28 (or perhaps the version after that).
>
> To be clear, my understanding, from following bug
> and emacs-devel threads, is as follows.  Anyone
> can correct me if I'm mistaken in any way.
>
> 1. `C-x p' was recently grabbed as a prefix key
> for Project (by Dmitry, in fact) - over my pleas
> and arguments not to.  That was maybe 8 months ago?
>
> Bookmark+ had, for many years, lots and lots of
> keys on that prefix key.  The only arguments by
> Dmitry in favor of grabbing that key for Project
> were, in effect, (a) we want to do it and (b) we
> don't need to care what Bookmark+ has been using.
> OK.
>
> As a result of that, I changed Bookmark+ last July
> to use `C-x x' instead.  (There was no mention of
> `C-x x' in that discussion, and it was unbound.)
>
> 2. Recently, Lars decided to bind `revert-buffer'
> to `C-x x g'.  There was subsequent discussion
> about using that prefix key `C-x x' for things
> related to buffers, in general.  I don't know
> exactly what's been done in that regard.
>
> Needless to say, I again objected, saying that
> I've moved Bookmark+ keys from prefix `C-x p' to
> `C-x x', and asking that they not now usurp also
> `C-x x'.  But AFAIK, `C-x x' has, yes, now been
> grabbed by Emacs as a default global binding.
>
> (There was quite a lot of objection, BTW, to the
> idea that Emacs needs a _global_ key for reverting
> a buffer.  I'm not even sure there was _anyone_
> arguing in favor of that, besides the maintainer
> who came up with the idea.)
>
> 3. There was talk in emacs-devel (or a bug thread?)
> about binding `C-x /' by default.  I don't know
> what finally happened in that regard.  But I chimed
> in about that too, saying that I use that prefix key
> for zones.el.  I mentioned this while pointing out
> there is a _general_ problem here: Emacs grabbing
> more keys for default bindings, leaving 3rd-party
> code with fewer and fewer options.
>
> 4. I'll mention too that for Bookmark+ when I
> changed from `C-x p' to `C-x x' I added a user
> option for which key to use.  So users can deal
> with the new conflict themselves, if I don't
> end up trying yet another key as the default.

I hope I'm not oversimplifying, but doesn't this demonstrate the problem
with third-party code when it attempt to bind maps or commands by
default? Default keybindings can be safely overridden (I myself have
done so for multiple keys C-x C-r, C-x u, M-u/l/c, M-/, ...), so as
Dmitry says, the users may override project.el's map or move it
somewhere else, as long as a package like bookmark+ does not insist on a
specific prefix? I am not familiar with bookmark+, so maybe I am missing
something...

-- 
	Philip K.

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

RE: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Drew Adams]

> I hope I'm not oversimplifying, but doesn't this demonstrate the
> problem with third-party code when it attempt to bind maps or commands by
> default? Default keybindings can be safely overridden (I myself have
> done so for multiple keys C-x C-r, C-x u, M-u/l/c, M-/, ...), so as
> Dmitry says, the users may override project.el's map or move it
> somewhere else, as long as a package like bookmark+ does not insist on
> a specific prefix? I am not familiar with bookmark+, so maybe I am
> missing something...

Users can always override _any_ keybindings.

This is not about user bindings.  It's about
default Emacs bindings and 3rd-party code.

Re: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Drew Adams <drew.adams@oracle.com> writes:

> I proposed one possible solution - a _moratorium_
> by Emacs from grabbing more keys by default.  Look
> up the word "moratorium", if you aren't familiar
> with it.
> 
> If you like, you can consider my proposal to be:
> Let's at least STOP now from binding any more keys
> by default, while we entertain discussion for other
> possible solutions.  And as long as no adequate
> solution, preferably somewhat consensual, is found,
> Emacs just shouldn't bind more keys.  It can
> repurpose keys that are already bound by default,
> but it should stay away from binding new ones.
> 
> And I explicitly allowed for _exceptions_, to be
> decided by the maintainers - after some general
> discussion.  So IMO, this is not at all a radical
> proposal.  It's essentially "STOP THE BLEEDING!"
> as a _first step_.

In that case I agree with you completely about this subject.

I sympathize with your problems.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 13.02.2021 09:37, Robert Thorpe wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 12.02.2021 10:10, Robert Thorpe wrote:
>>> I think that user-friendliness is beneficial.  It would help with
>>> that if packages could bind some keys by default.
>>
>> The current tradition is that a package provides a major or minor mode
>> (or several), puts one of them in their init file, and *those* install
>> some default keymaps.
>>
>> auto-mode-alist entries, however, can be added through autoloads.
> 
> Yes.  But I don't think that solves the problems that Gregory Heyting
> and Drew Adams are talking about.
> 
> Firstly, it can't do anything about changes in keybindings in future
> Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
> "C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
> been mapped for Emacs 28 (or perhaps the version after that).

Is that a problem? When such package finds out about a change like this, 
they can change the default binding, or they might keep it as it was.

After all, the changes like the ones you have mentioned are additive, 
both the project keymap and the later addition of buffer-related 
commands on 'C-x x'. They haven't been there before, and a fair number 
of users might not miss them if xyz-mode (which they do use) takes up 
either of the sequences.

> The author of a third party package can't easily deal with that.  What if
> their minor mode used "C-x x"?  In that case it will remove the keymaps
> of a core feature (or the core feature will remove it's keymap).

Minor mode keymaps generally override the global keymap.

> As Gregory Heyting has pointed out, what about packages that are not
> modes?  Not every package is a minor mode or major mode.  So, how should
> other types of package behave?

Depends on how their setup is documented. Minor or major modes are the 
majority, though.

> Lastly, the usability issue is still there.  I think beginners find this
> kind of thing difficult.

Having a key sequence overridden by a minor mode?

Considering beginners don't usually read the manual, they might not even 
know they are missing anything. Which might be a loss, of course, in 
certain cases. But not a difficulty.

> These days there are lots of Emacs "starter
> kits" that claim to make Emacs simpler.  A lot of what they do is
> configuring third-party packages.
> 
> Philip Kaludercic suggested some code for prompting users before mapping
> keys.  I think that's a good idea.

Some infrastructure for suggesting custom key bindings might work, but I 
feel the current third-party tradition has held up pretty well.

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.02.2021 09:37, Robert Thorpe wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
...
>> Yes.  But I don't think that solves the problems that Gregory Heyting
>> and Drew Adams are talking about.
>> 
>> Firstly, it can't do anything about changes in keybindings in future
>> Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
>> "C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
>> been mapped for Emacs 28 (or perhaps the version after that).
>
> Is that a problem? When such package finds out about a change like this, 
> they can change the default binding, or they might keep it as it was.

I disagree.  You're asking the authors of third-party packages to
constantly respond to the capricious behaviour of the maintainers.  I
think they're likely to take their efforts elsewhere if that continues.

I think Third party package authors should not have to do that.  The
maintainers of Emacs should provide a way to deal with the situation.

> After all, the changes like the ones you have mentioned are additive, 
> both the project keymap and the later addition of buffer-related 
> commands on 'C-x x'. They haven't been there before, and a fair number 
> of users might not miss them if xyz-mode (which they do use) takes up 
> either of the sequences.

Don't you think that's a suboptimal situation?  Yes, it may be that some
users never miss features.  Perhaps lots of users never use your project
features because they have already bound C-x p to something else.

Equally well though, users may miss out on something that they would
have found useful.

I think it's better to do something about future collision up-front, to
deal with them *before* more happen.

>> The author of a third party package can't easily deal with that.  What if
>> their minor mode used "C-x x"?  In that case it will remove the keymaps
>> of a core feature (or the core feature will remove it's keymap).
>
> Minor mode keymaps generally override the global keymap.

But not usually in a way that causes conflicts.  Usually the keys that
minor modes over-ride are not used by other things.

In that past, when lots of development was in core Emacs managing key
collisions was an internal job amongst the maintainers.  Now there are
thousands of 3rd-party packages on ELPA and MELPA.

I don't think the hoping the muddling through will be OK is a good
policy.

>> As Gregory Heyting has pointed out, what about packages that are not
>> modes?  Not every package is a minor mode or major mode.  So, how should
>> other types of package behave?
>
> Depends on how their setup is documented. Minor or major modes are the 
> majority, though.
>
>> Lastly, the usability issue is still there.  I think beginners find this
>> kind of thing difficult.
>
> Having a key sequence overridden by a minor mode?
>
> Considering beginners don't usually read the manual, they might not even 
> know they are missing anything. Which might be a loss, of course, in 
> certain cases. But not a difficulty.

I don't see the distinction.  I think every loss is also a "difficulty".

>> These days there are lots of Emacs "starter
>> kits" that claim to make Emacs simpler.  A lot of what they do is
>> configuring third-party packages.
>> 
>> Philip Kaludercic suggested some code for prompting users before mapping
>> keys.  I think that's a good idea.
>
> Some infrastructure for suggesting custom key bindings might work, but I 
> feel the current third-party tradition has held up pretty well.

In my view what we've seen in this thread points the other way.  It
might have held up well in the past but it's showing it's age.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 15.02.2021 06:49, Robert Thorpe wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 13.02.2021 09:37, Robert Thorpe wrote:
>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>>
> ...
>>> Yes.  But I don't think that solves the problems that Gregory Heyting
>>> and Drew Adams are talking about.
>>>
>>> Firstly, it can't do anything about changes in keybindings in future
>>> Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
>>> "C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
>>> been mapped for Emacs 28 (or perhaps the version after that).
>>
>> Is that a problem? When such package finds out about a change like this,
>> they can change the default binding, or they might keep it as it was.
> 
> I disagree.  You're asking the authors of third-party packages to
> constantly respond to the capricious behaviour of the maintainers.  I
> think they're likely to take their efforts elsewhere if that continues.

Third-party developers are used to change, and the direction of 
emacs-devel is more often thought of as too reactionary or glacial, 
rather than capricious.

What did create some outcry is how the maintainer made the change 
without contacting, or really considering, the #1 popular third-party 
package which has been making use of this binding for years.

> I think Third party package authors should not have to do that.  The
> maintainers of Emacs should provide a way to deal with the situation.

Wearing my third-party author hat, I can say it's often nice to be able 
to use/recommend a short key sequence to the users, even if that might 
lead to some conflicts down the line. Which doesn't happen for years anyway.

>> After all, the changes like the ones you have mentioned are additive,
>> both the project keymap and the later addition of buffer-related
>> commands on 'C-x x'. They haven't been there before, and a fair number
>> of users might not miss them if xyz-mode (which they do use) takes up
>> either of the sequences.
> 
> Don't you think that's a suboptimal situation?  Yes, it may be that some
> users never miss features.  Perhaps lots of users never use your project
> features because they have already bound C-x p to something else.

There are tradeoffs in any decision.

Freeing 'C-z' up, for example, won't help most authors anyway.

> Equally well though, users may miss out on something that they would
> have found useful.
> 
> I think it's better to do something about future collision up-front, to
> deal with them *before* more happen.

I have some doubts that we'll be able to free up nice enough key 
bindings that third-party packages will all want to use.

And even if that happens, collisions between externally maintained 
packages can happen just as well. There is no foolproof solution.

Knowing the ecosystem and being considerate toward the existing players 
can go a long way, though.

Initiatives like xref (where you take an aspect of the UI and make it 
customizable, but keep the key bindings the same across the packages) 
can help too. Inferior modes and test runners could use the same treatment.

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2021-02-15 21:29]:
> There are tradeoffs in any decision.
> 
> Freeing 'C-z' up, for example, won't help most authors anyway.

That is not freeing, that is blocking shell users.

User experience from yesterday, I was running "guix search editor" in the quest
to find ways to get Leo editor running on my computer, but with fail. Any way,
I found "ne" or nice editor, and I installed it. But I did not know
keybindings, so Control-Z would work, it would save my work. What if I had some
other jobs running in the same time, let us say some processing in background,
I invoke "ne" and do not know how to exit, I wish to read the manual, but I
cannot, so Control-Z works, I can read the manual and come back to "ne", exit
out of it, and come back to my more important job processing.

So far all editors I have invoked also give the support for shell job control,
just nano needs tweaking beforehand. I am surprised.

Exactly same thing would happen if shell user invokes Emacs but cannot exit or
get surprised. What if Emacs user invokes by mistake spacemacs, maybe cannot
exit out of it. I have been invoking viper mode in past and did not know how to
exit out of it as I did not know where is M-x any more.

You think you are freeing the key, but I think you are disabling freedom to
shell users.

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Jean Louis <bugs@gnu.support> [2021-02-16 10:24]:
> * Dmitry Gutov <dgutov@yandex.ru> [2021-02-15 21:29]:
> > There are tradeoffs in any decision.
> > 
> > Freeing 'C-z' up, for example, won't help most authors anyway.
> 
> That is not freeing, that is blocking shell users.

Just to make sure, I do not mean "you" when using "you". I wanted to say "that
would be blocking of shell users", it is conditional, just piece of information
that serves for further considerations.

That C-z re-binding to something else is less useful also shows the pottential
conflict with CUA bindings, as when users decide to use CUA, C-z becomes
something else. 

That is why C-x C-z is not quite same as C-z as when user decide to use CUA
mode, C-z becomes undo also in console. Then C-x C-z is only thing that works. 

Re: not good proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> There is another issue....  I'm not sure that third-party packages will 
> use the feature.  I'm also on the Reddit Emacs group.  Several of the 
> people there use and develop third-party packages.  It seems to me that 
> they often do that because they don't want to contribute to core.  Some 
> don't like the core Emacs development team and don't agree with their 
> direction for Emacs.  So, would they use such a prefix key if it were 
> offered?  Perhaps not.
>
> It woud be a feature for those 3rd-party package authors who want to 
> co-operate with the core Emacs devs.  I don't know how many of those 
> there are, but I doubt it's all of them.
>

It would be part of the key binding conventions.  Of course nobody is 
forced to follow these conventions, nobody is fined if the don't, but 
AFAICS the vast majority of package developers do follow them.  Those who 
dislike the core Emacs development team do care about their users, and 
would not want to make their life more complicated than necessary.

>
> Like Jean Louis, I think that the suggestion of changing C-z is awful. I 
> use it all the time.  Like Jean said it's expected in Unix like 
> environments.
>

As has been explained again and again, including in the post to which you 
are replying, "C-z C-z" would remain bound to "suspend-frame", all you'd 
have to do is to press three keys instead of two.  That isn't "awful", 
especially for a command you don't use once a minute.  And in case you 
personally really need "suspend-frame" on "C-z", you would of course 
always have the possibility to (global-set-key (kbd "C-z") 
'suspend-frame), and to move the keymap(s) reserved for third-party 
libraries on some other key of your choice.

>
> Of the keys suggested I think the best is "M-o" since it's current 
> default binding isn't very useful.
>

A meta key alone wouldn't be an appealing solution for third-party 
developers, it must either a control key alone, or a control key and its 
corresponding meta key.

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Gregory Heytings <gregory@heytings.org> writes:

> It would be part of the key binding conventions.  Of course nobody is 
> forced to follow these conventions, nobody is fined if the don't, but 
> AFAICS the vast majority of package developers do follow them.  Those who 
> dislike the core Emacs development team do care about their users, and 
> would not want to make their life more complicated than necessary.

I hope you're right.

> As has been explained again and again, including in the post to which you 
> are replying, "C-z C-z" would remain bound to "suspend-frame", all you'd 
> have to do is to press three keys instead of two.  That isn't "awful", 
> especially for a command you don't use once a minute.  And in case you 
> personally really need "suspend-frame" on "C-z", you would of course 
> always have the possibility to (global-set-key (kbd "C-z") 
> 'suspend-frame), and to move the keymap(s) reserved for third-party 
> libraries on some other key of your choice.

I agree with Jean Louis on that too.  I think C-z C-z is not good
enough.  Every other terminal application uses C-z by itself, it's a
convention.  It's been that way for decades.  If you write a terminal
application and do nothing special then C-z will suspend it.  That's
because it sends SIGTSTP.

Conventions make the whole operating system easier to use.

In your other replies you talk about casual users of Emacs.  What about
casual users who also use the shell?  One of my friends is like that -
he uses the shell for everything.  But he uses Emacs for editing.  That
workflow means suspending Emacs very often.  To users like that you are
breaking a very old and well established expectation.

>> Of the keys suggested I think the best is "M-o" since it's current 
>> default binding isn't very useful.
>>
>
> A meta key alone wouldn't be an appealing solution for third-party 
> developers, it must either a control key alone, or a control key and its 
> corresponding meta key.

I don't see why.  What wrong with just a meta key?  On modern keyboards
the Alt and Ctrl keys are usually the same size.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>> A meta key alone wouldn't be an appealing solution for third-party 
>> developers, it must either a control key alone, or a control key and 
>> its corresponding meta key.
>
> I don't see why.  What wrong with just a meta key?  On modern keyboards 
> the Alt and Ctrl keys are usually the same size.
>

It's of course not a matter of key size.  In Emacs key bindings, control 
ones are "primary", and meta ones are "secondary".  You open, save, quit, 
move, search, ... with control keybindings, in fact you can use Emacs 
without ever using meta keys.  The opposite isn't true.  Relegating 
third-party libraries on a secondary key binding can't be an appealing 
solution.

Re: not good proposal: "C-z <letter>" reserved for users

[Joost Kremers]

On Fri, Feb 12 2021, Gregory Heytings wrote:
>>> A meta key alone wouldn't be an appealing solution for third-party 
>>> developers, it must either a control key alone, or a control key and 
>>> its corresponding meta key.
>>
>> I don't see why.  What wrong with just a meta key?  On modern keyboards 
>> the Alt and Ctrl keys are usually the same size.
>
> It's of course not a matter of key size.  In Emacs key bindings, control 
> ones are "primary", and meta ones are "secondary".  You open, save, quit, 
> move, search, ... with control keybindings, in fact you can use Emacs 
> without ever using meta keys.  The opposite isn't true.  Relegating 
> third-party libraries on a secondary key binding can't be an appealing 
> solution.

That's a strange argument to make. Meta keys are as integral to Emacs as control
keys. The existence of such pairs as C-f / M-f, C-b / M-b or C-t / M-t etc. makes
that clear. Sure you can use Emacs without ever using meta keys, but it would be
damned inconvenient. I mean, you could say the same about the control key:
just use the mouse menu and cursor keys and you'll be able to get a lot done.

Of course, I see your point that the control key is more or less the
prototypical modifier key, but why should that mean that reserving a meta key
for external packages would be unappealing? (Plus, on Macs, the prototypical
modifier key seems to be command, not control.)

-- 
Joost Kremers
Life has its moments

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 12.02.2021 07:42, Robert Thorpe wrote:

> I agree with Jean Louis on that too.  I think C-z C-z is not good
> enough.  Every other terminal application uses C-z by itself, it's a
> convention.  It's been that way for decades.  If you write a terminal
> application and do nothing special then C-z will suspend it.  That's
> because it sends SIGTSTP.

Could we someday stop considering Emacs a "terminal application"? Yes, 
it has a version that works in the terminal, but it's limited in 
features compared to the graphical one.

Even non-graphical features, such as available key binding space.

> Conventions make the whole operating system easier to use.
> 
> In your other replies you talk about casual users of Emacs.  What about
> casual users who also use the shell?  One of my friends is like that -
> he uses the shell for everything.  But he uses Emacs for editing.  That
> workflow means suspending Emacs very often.  To users like that you are
> breaking a very old and well established expectation.

'C-x C-z', a binding which has existed for a long time, is not too hard 
to type.

Re: not good proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> Could we someday stop considering Emacs a "terminal application"? Yes, 
> it has a version that works in the terminal, but it's limited in 
> features compared to the graphical one.
>

According to the recent survey, 30% of the Emacs users use it in a 
terminal or console.  It is true that the non-graphical version has some 
limits, which are limits that are imposed by terminals and consoles, but 
the fact that it is possible to use the same program in both situations 
is, IMO, invaluable.

Re: not good proposal: "C-z <letter>" reserved for users

[Howard Melman]

Gregory Heytings <gregory@heytings.org> writes:

>> Could we someday stop considering Emacs a "terminal application"?
>> Yes, it has a version that works in the terminal, but it's limited
>> in features compared to the graphical one.
>
> According to the recent survey, 30% of the Emacs users use it in a
> terminal or console.  It is true that the non-graphical version has
> some limits, which are limits that are imposed by terminals and
> consoles, but the fact that it is possible to use the same program in
> both situations is, IMO, invaluable.

I'm not a terminal user and I suspect this is changing
something too longstanding to be considered but the subject
is "not good proposal" so ...

Leverage the fact that suspend is basically only useful in
the terminal and the frame commands are only useful in the
GUI and put them both on C-z.  In the terminal it's suspend
and in the GUI move (and rename via an alias) the
ctl-x-5-map to C-z.

This means in the GUI C-z is a frame command prefix and it
has nice symmetry with many commands on C-x right next to
it; C-z 2, C-z 1, C-z 0, C-z o, C-z b, C-z m, etc.  I'd also
add to the map commands like find-file-other-frame on C-f,
kill-buffer-and-frame on C-k, and of course suspend-frame on
C-z C-z.  As I said previously, I've been doing this for
years and like it a lot.

This then frees up C-x 5 as a prefix key.  It's probably a
year too late (though this muscle memory can't be too strong
yet), but I'd move the C-x t tab-bar commands to C-x 5 and
free up the more convenient C-x t prefix for something else.
It's not as convenient as an unbound C-z but it's something.
And it also solves the wasted C-x 5 prefix in a terminal
which no one seems to care about :)

-- 

Howard

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Howard Melman <hmelman@gmail.com> [2021-02-12 22:49]:
> I'm not a terminal user and I suspect this is changing
> something too longstanding to be considered but the subject
> is "not good proposal" so ...

Raspberry Pi installations worlwide are I guess in millions, people
access it remotely through terminal emulators or serial consoles.

Virutal Private Servers, dedicate servers are in millions or billions,
system administrators access it remotely through terminal emulators or
serial consoles.

Those are shell users. Shell users expect Ctrl-Z to work and not
because of Emacs but because of the basics of shell job controls.

When changing a key that would drastically deter compatibility with
known conventions one has to consider millions of applications in
shell.

Ctrl-Z is mentioned as suspending the job in almost every popular
shell on GNU/Linux systems and BSD systems. Number of installations of
those systems in Internet prevails. Administrators access it through
shell.

> This then frees up C-x 5 as a prefix key.  It's probably a
> year too late (though this muscle memory can't be too strong
> yet), but I'd move the C-x t tab-bar commands to C-x 5 and
> free up the more convenient C-x t prefix for something else.
> It's not as convenient as an unbound C-z but it's something.
> And it also solves the wasted C-x 5 prefix in a terminal
> which no one seems to care about :)

I have been using C-x 5 numerous times today and every day, last year
and last years. I hope that those user experiences may give you more
insights. 

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Howard Melman]

Jean Louis <bugs@gnu.support> writes:

> Ctrl-Z is mentioned as suspending the job in almost every popular
> shell on GNU/Linux systems and BSD systems. Number of installations of
> those systems in Internet prevails. Administrators access it through
> shell.

I'm aware there are terminal emacs users, I'm just not one
of them.  You seemed to have missed the part where I said
"In the terminal it's suspend and in the GUI move (and
rename via an alias) the ctl-x-5-map to C-z.".  

I was proposing to leave the binding of C-z in terminal
emacs to be a suspend function and just change it in the GUI.

>> This then frees up C-x 5 as a prefix key.  It's probably a
>> year too late (though this muscle memory can't be too strong
>> yet), but I'd move the C-x t tab-bar commands to C-x 5 and
>> free up the more convenient C-x t prefix for something else.
>> It's not as convenient as an unbound C-z but it's something.
>> And it also solves the wasted C-x 5 prefix in a terminal
>> which no one seems to care about :)
>
> I have been using C-x 5 numerous times today and every day, last year
> and last years. I hope that those user experiences may give you more
> insights. 

Also the part where I said "I suspect this is changing
something too longstanding to be considered but the subject
is "not good proposal" so ..." 

-- 

Howard

Re: not good proposal: "C-z <letter>" reserved for users

[ken]

On 02/12/2021 04:05 PM, Howard Melman wrote:
> I was proposing to leave the binding of C-z in terminal
> emacs to be a suspend function and just change it in the GUI.

This would break a lot of things unnecessarily.  For one, any code a 
user has written which functions fine in his/her gui would fail if one 
day it was used in emacs invoked in a terminal.

... also if someone wanted to test emacs code outside any possible 
effect of the window manager.  How would that be done?

... people would also need to write separate or additional code for 
functions running in a gui or in a terminal.

And there would certainly arise instances where people on this list 
would be trying to help a user with a problem which would be confounded 
by whether the user was in a terminal or in a gui.

There are times when I simply want to suspend (minimize) an emacs frame 
in the gui and so use C-z to do that.  I can't believe I'm the only 
emacs human doing that.

One of the many wonderful things about emacs is that it's platform 
independent.  Let's not sacrifice that.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> I'm not a terminal user and I suspect this is changing
>> something too longstanding to be considered but the subject
>> is "not good proposal" so ...
>
> Raspberry Pi installations worlwide are I guess in millions
> [...]

Even correct guesses are awarded 0 points. Please stop guessing
about data.

> Virutal Private Servers, dedicate servers are in millions or
> billions [...]

...

> When changing a key that would drastically deter
> compatibility with known conventions one has to consider
> millions [...]

Ha :) You are too much :)

Are you a millionaire by any chance Jean Louis? Or perhaps
a billionaire?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 00:10]:
> Even correct guesses are awarded 0 points. Please stop guessing
> about data.
> 
> > Virutal Private Servers, dedicate servers are in millions or
> > billions [...]

Those are not mine, those are installations worldwide.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> Virutal Private Servers, dedicate servers are in millions
>> or billions [...]
>
> Those are not mine, those are installations worldwide.

Hey, how many drips of H2O are the in the Niagara falls?
Millions or billions, right?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 11:05]:
> Jean Louis wrote:
> 
> >> Virutal Private Servers, dedicate servers are in millions
> >> or billions [...]
> >
> > Those are not mine, those are installations worldwide.
> 
> Hey, how many drips of H2O are the in the Niagara falls?
> Millions or billions, right?

For H20 who knows.

I have no idea of number of Internet servers, it requires researching
and thinking how to estimate it.

https://en.wikipedia.org/wiki/List_of_countries_by_number_of_Internet_hosts

https://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/

If 1&1 company has 70000 Internet servers in 2010, maybe now they have
double or triple that amount. I do not know how many VPS-es are
spawned on each server and not each is used for VPS business. But let
us say 50000 servers are used for VPS-e and 20 virtual machines are
spawned, that is already 500,000 VPS-es, so 1 company could alone
already represent 1 million of VPS-es spawned. If there are 1000
companies that may reach 1 billion.

I do believe there must be millions of VPSes that are sold to
customers and administered by customers in one way or the other.

I also believe that there must be billions of VPS-es anyway, but not
necessarily administered by customers, many can be spawned
automatically up and down for process control or whatever operations.

Among manye millions or VPS-es spawned I believe that number of people
entering into VPS by using shell is considerable, maybe one tenth of
the number, that could easily by one million of people. One part of
those could be sometimes using Emacs.

For example company Digitalocean provides VPSes to people, they
provide instructions for Emacs here:
https://www.digitalocean.com/community/tutorials/how-to-use-the-emacs-editor-in-linux

That means Digitalocean provides for its customers tutorial and there
are customers who use Emacs and entering their VPSes and handling
shell stuff.

But how many is hard to know. Such customers will rather not invoke
popularity contests statistics reporting or consider VPS to be their
personal machine.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> If 1&1 company has 70000 Internet servers in 2010, maybe now
> they have double or triple that amount. I do not know how
> many VPS-es are spawned on each server and not each is used
> for VPS business. But let us say 50000 servers [cut]

Nope.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings wrote:

> According to the recent survey, 30% of the Emacs users use
> it in a terminal or console.

Where can one read that survey?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Philip Kaludercic]

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

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Gregory Heytings wrote:
>
>> According to the recent survey, 30% of the Emacs users use
>> it in a terminal or console.
>
> Where can one read that survey?

The results were summarized here: https://emacssurvey.org/2020/

31.9% of the 7344 respondents claimed to use the TUI version.

-- 
	Philip K.

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

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Philip Kaludercic wrote:

>>> According to the recent survey, 30% of the Emacs users use
>>> it in a terminal or console.
>>
>> Where can one read that survey?
>
> The results were summarized here:
> https://emacssurvey.org/2020/
>
> 31.9% of the 7344 respondents claimed to use the
> TUI version.

7344???

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-12 15:52]:
> > Could we someday stop considering Emacs a "terminal application"? Yes,
> > it has a version that works in the terminal, but it's limited in
> > features compared to the graphical one.
> 
> According to the recent survey, 30% of the Emacs users use it in a terminal
> or console.  It is true that the non-graphical version has some limits,
> which are limits that are imposed by terminals and consoles, but the fact
> that it is possible to use the same program in both situations is, IMO,
> invaluable.

When I am in VPS or dedicated server I will use first any editor that
is available.

On NetBSD servers I may type "emacs" as user and face either the real
Emacs or some kind of replacement such as `mg' or some other editor
with Emacs key bindings, but not real Emacs. Sometimes depending of
the system I may type "emacs" and find myself in `vi' or `vim'

If I have to administer or change some system configuration, or
install some software, then me as system administrator may not
identify myself as "Emacs user" but may use Emacs as text editor when
ready or available. There are millions of such users who are not
identified as Emacs users. I have been referencing data of how many
times is Emacs installed just on Debian servers by those users who did
submit to report their usage through popularity contest. If I remember
well it is more than 16000. Debian GNU/Linux is probably most popular
VPS operating system. There are millions of VPSes opened up globally
and instances are opening each in a while. Administrators may need
just one hour of few hours or maybe days to set it up, they may not
dwell in Emacs like we do.

I do not consider that survey authentic. But let us say it is. In my
opinion that 30% from the survey is much greater number in reality. If
we assume that 30% would apply also to those who reported Emacs
installations in Debian GNU/Linux than there is at least 4800 users
among those 16000 who reported using Emacs in that OS. What about the
total number of Debian users or GNU/Linux users in total? I have been
referencing it already, those are millions of people an Emacs must be
used by millions of people. In my opinion that shall be 8 millions
people. What if it is 50% or 4 millions of people than 30% of console
users would represent population of over million of people.

This data is just for consideration of such proposals to stop
considering using Emacs in console.

People not identifying as Emacs users may be Emacs
users. Identification and hobby and enthusiasm is one thing, separate
from duties, business or research. Person may be writing for decades
on Emacs without even knowing that he is or could be a dedicated
enthusiastic Emacs user who reports each in a while on GNU mailing
lists or public forums.

As nano user who do not identify as nano user:

I am using nano, but I am not nano user in my identifications.

As vim user who do not identify as vim user:

I do use vim each in a while and before I have been using it almost
regularly. I would be using vim even now but I do not know how to
setup various input methods like I do it in Emacs. It is faster editor
for specific tasks. In Emacs I can enter oe and get German umlaut or
other alphabets or cyrillic without problem, but I lack that important
capability in vim and so I use it for English only. Maybe it does
exist. I do not identify as vim user and would not have time neither
interest to answer whatever surveys about vim.

As zile user who do not identify as zile user:

I have never sent zile bug report neither I know how to do it. Zile
just works. I may install it on VPS or systems where I need faster and
quicker editing in English without UTF-8. It is sometimes my
replacement for Emacs in `mutt' or when some development version of
Emacs is making me problems, or when Emacs is too heavy and I still
need to edit things.

I am also user of mousepad text editor, and I never participate in any
forums nor bug reporting related to it so I do not identify as user of
mousepad. I also use `mcedit' from time to time, very fancy and usable
editor that I invoke through Midnight Commander. I will use `mg' and
`e3' editor as `e3em' Emacs version without hesitations as well but do
not identify as user of it. In MIT Scheme there is one editor that I
may invoke, it is like Emacs or its derivative, but I am not
identified as user of it.

From the above description of my persona user experience one can
assume that there are millions of Emacs users who will not identify as
such neither follow forums, replies or send bug reports, they will
edit some files, not necessarily dwell inside of the editor and
establish romantic relations with it like we do it here.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> I do not consider that survey authentic. But let us say it
> is. In my opinion that 30% from the survey is much greater
> number in reality. If we assume that 30% would apply also to
> those who reported Emacs installations in Debian GNU/Linux
> than there is at least 4800 users among those 16000 who
> reported using Emacs in that OS.

Is this another survey I didn't hear about?

Please always provide reference(s) when you make claims that
involve data.

> What about the total number of Debian users or GNU/Linux
> users in total? I have been referencing it already, those
> are millions of people an Emacs must be used by millions of
> people.

??? Again where do you get all these millions from?

> In my opinion that shall be 8 millions people.

...

> What if it is 50% or 4 millions of people than 30% of
> console users would represent population of over million
> of people.

Indeed... what if :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Jean Louis wrote:
>
>> I do not consider that survey authentic. But let us say it
>> is. In my opinion that 30% from the survey is much greater
>> number in reality. If we assume that 30% would apply also to
>> those who reported Emacs installations in Debian GNU/Linux
>> than there is at least 4800 users among those 16000 who
>> reported using Emacs in that OS.
>
> Is this another survey I didn't hear about?
>
> Please always provide reference(s) when you make claims that
> involve data.

I don't know where Jean Louis got his info from.  I assume the Debian
survey is the "popcon" one.  You can find the results for Emacs here:

https://qa.debian.org/popcon.php?package=emacs

The Emacs usage survey mentioned was shared on Emacs-Devel but not here.
I don't know why.  It was shared in some other places too.  I get the
impression it was by someone very modern who isn't into things like
email lists.

I don't know if it's millions, but lots of people use Emacs.  As you can
see, the Debian survey shows about 14000.  Also, there are 49000
subscribers to Emacs Reddit.  I suspect not every Emacs user is on
Reddit, so the number is probably higher than 49000.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Robert Thorpe <rt@robertthorpeconsulting.com> [2021-02-13 11:29]:
> Emanuel Berg via Users list for the GNU Emacs text editor
> <help-gnu-emacs@gnu.org> writes:
> 
> > Jean Louis wrote:
> >
> >> I do not consider that survey authentic. But let us say it
> >> is. In my opinion that 30% from the survey is much greater
> >> number in reality. If we assume that 30% would apply also to
> >> those who reported Emacs installations in Debian GNU/Linux
> >> than there is at least 4800 users among those 16000 who
> >> reported using Emacs in that OS.
> >
> > Is this another survey I didn't hear about?
> >
> > Please always provide reference(s) when you make claims that
> > involve data.
> 
> I don't know where Jean Louis got his info from.  I assume the Debian
> survey is the "popcon" one.  You can find the results for Emacs here:
> 
> https://qa.debian.org/popcon.php?package=emacs

That is one that I used, then I have amplified it by the estimated
number of Ubuntu users and used the percentage of Emacs users in
popularity contest to find about estimated number of total Emacs
users. My email is somewhere in the mailing lists.

> The Emacs usage survey mentioned was shared on Emacs-Devel but not here.
> I don't know why.  It was shared in some other places too.  I get the
> impression it was by someone very modern who isn't into things like
> email lists.

I think that author rushed and unintentionally neglected possible
communication channels. 

> I don't know if it's millions, but lots of people use Emacs.  As you can
> see, the Debian survey shows about 14000.  Also, there are 49000
> subscribers to Emacs Reddit.  I suspect not every Emacs user is on
> Reddit, so the number is probably higher than 49000.

There are categories how people use Emacs. Only enthusiastic ones will
report on bug reporting lists or public websites. But if we speak of
global number of users that must be in millions.

Some references:
https://askubuntu.com/questions/80379/how-many-ubuntu-users-are-there-worldwide#80383

They wish to have 200 million Ubuntu users in 2015:
https://www.omgubuntu.co.uk/2011/05/mark-shuttleworth-delivers-uds-keynote-address-sets-goal-for-200-million-ubuntu-users-in-4-years

Now Debian Popularity Contest:
https://qa.debian.org/popcon.php?package=emacs

Let us say the number of "emacs" installation is 13% in Debian.

The rank shows 6.83% among all packages. Correct me if I am
wrong. Does that 6.83% mean that among all packages installed 6.83% of
users installed Emacs? I am not sure any more.

dpkg number of installations is 204612 and dpkg is on first place
emacs number of installations is 13973 and

(defun pct-of-number-in-total (number total)
  "Return the percentage that NUMBER represents in a TOTAL."
  (let* ((percent (/ (float total) 100))
         (percentage (/ (float number) percent)))
    percentage))

(pct-of-number-in-total 13973 204612) yields 6.8290227357144255

Popularity contest is not reported by all users, just by some.

I am assuming that Ubuntu users are very similar to Debian users. Then
it means to me that 6.82% users of supposed 200 million of Ubuntu
users must be also Emacs users.

That alone would make 13,640,000 Emacs users.

There is number of millions of uncounted Debian users, Arch Linux
users, other GNU/Linux users and BSD derivatives and so many other
distributions with Emacs inside. Add that to the amount above.

There are those enthusiastic users, having or showing great excitement
and interest, and there are those who are just users without great
excitement. 

There is great number of Bash users who are not enthusiastic, would
never report any bugs, would not publish programs or would not program
at all, but would be using shell with unimpressed "So what?"
statement. I am just assuming that ratio of enthusiastic Bash users is
so much less to the number of non enthusiastic users than Emacs'
ratio. Do people form online communities around Bash? Do they have
forums? Do they participate equally in mailing lists? That is how I
think of enthusiastic users in Bash world. The ratio is probably less
than the number of enthusiastic users in Emacs.

Those enthusiastic will report somewhere, we know about them at least
as commenters, bug reporters, readers of the forum if not
participants. Somewhat enthusiastic user will read at least what
others are saying. Non-enthusiastic will not even read it, but will be
user.

When changing something in Emacs we better think on the impact of all
users.

There is large number of proprietary software users who install free
software VPS-es and dedicated servers worldwide, one part of them may
expect the decades old function to work. Those are professionals
providing various software. In my opinion there is more proprietary
software users who use free software on VPS-es and dedicated servers
than exclusively free software users. Those are business makers,
business mostly come from proprietary software makers and users. That
is how I perceive the world of today. They may not be GNU/Linux users
at all -- but they may be Windows users who spawn VPS-es and/or use
dedicated servers for business, setting up databases for customers,
maintaining their operating systems, websites, serious or crucial
business operations. Such users will never even report in.  Debian
popularity contest. They use software for business, not for fan.

Then we come here on our mailing lists and among 20 people or maybe 50
people, somebody may decide capriciously to break some decades old
function or some key binding for the sake of future reservation of
imaginary third party packages, something like that. Just few of those
50 people will be thinking on the worldwide impact. Some will thinkg
that Emacs users report to Emacs mailing lists, and if those do not
report, they cannot be Emacs users and will assume that changes impact
only those who report to Emacs list. Just few of wise people will be
aware of the global impact.

Surely, Emacs is distributed without warranty, but legal liability
does not exclude human responsibility, that is why developers work on
improving it. They do carry large responsibilities. And they have to
be enough confident to do anything including breaking some
compatibilities and destryoing some things in exchange for creation of
new things. That is why there is longer period of time until new Emacs
development versions become "stable".

Breaking some function may then impact users, their work, their
efforts, their money flow, they may lose data, they may even lose a
job if they lose data, it may impact their life and families.

Before some decades I worked for free in humanitarian
organization. Computer got stuck. It was running proprietary Windoze
system on good hardware. The Windoze system froze. There was no way to
shut it down. It had to be hard reset and after hard reset there was
no data on hard disk any more. Hard disk worked without
problems. There was no virus or anything. Data of the work of last 6
months was lost, including some letters, numbers, etc. All important
and valuable. Would that not be humanitarian organization I would have
or could probably lose the job when such thing happens regardless if
it was not my fault. Maybe family could depend of the person
there.

One mistake in program does have butterfly effects worldwide.[1]

So removing a function in Emacs that is assumed to be there by
millions of users does have some effect and impact on those users.

They may never report about it. They may be affected without
importing.


Jean


1: https://en.wikipedia.org/wiki/Butterfly_effect

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> (defun pct-of-number-in-total (number total)
>   "Return the percentage that NUMBER represents in a TOTAL."
>   (let* ((percent (/ (float total) 100))
>          (percentage (/ (float number) percent)))
>     percentage))
> (pct-of-number-in-total 13973 204612) yields 6.8290227357144255

(defun percent (n d)
  (let ((pct (* 100 (/ n d 1.0))))
    (message "%.1f%%" pct)))

(percent 13973 204612) ; 6.8%

One thing I don't understand tho - from the `format' docstring

  For %e and %f sequences, the number after the "." in the
  precision specifier says how many decimal places to show; if
  zero, the decimal point itself is omitted.

Still (percent 0 200) ; 0.0%

Or does that refer to "if one _sets_ it to zero"

(message "%.0f%%" 0) ; 0%

Right, so that's it... Yeah, so obvious, saying it makes one
confused instead :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Jean Louis wrote:
>
>> (defun pct-of-number-in-total (number total)
>>  "Return the percentage that NUMBER represents in a TOTAL."
>>  (let* ((percent (/ (float total) 100))
>>         (percentage (/ (float number) percent)))
>>    percentage))
>
> (defun percent (n d)
>   (let ((pct (* 100 (/ n d 1.0))))
>     (message "%.1f%%" pct)))
>
> (percent 13973 204612) ; 6.8%

The 1.0 and (float) just don't look good. Maybe one should do
it onee time and be done with it.

(defun // (n d)
  (/ n d 1.0) )
;; (// 8 256) ; 0.03125
;; (/  8 256) ; 0

But maybe then people would think it (//) would correspond
somehow to **, or `expt'...

(defalias '** #'expt)

and, it would require a lot of `require's from all over... but
then one would get away with the unidiomatic 1.0s for good!

https://dataswamp.org/~incal/emacs-init/math.el

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 17:56]:
> > Jean Louis wrote:
> >
> >> (defun pct-of-number-in-total (number total)
> >>  "Return the percentage that NUMBER represents in a TOTAL."
> >>  (let* ((percent (/ (float total) 100))
> >>         (percentage (/ (float number) percent)))
> >>    percentage))
> >
> > (defun percent (n d)
> >   (let ((pct (* 100 (/ n d 1.0))))
> >     (message "%.1f%%" pct)))
> >
> > (percent 13973 204612) ; 6.8%
> 
> The 1.0 and (float) just don't look good. Maybe one should do
> it onee time and be done with

Thanks, I knew somebody will improve it for free.

Now I will use:

(defun pct-of-number-in-total (number total)
  "Return the percentage that NUMBER represents in a TOTAL."
  (/ number total 0.01))

Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Thanks, I knew somebody will improve it for free.
>
> Now I will use:
>
> (defun pct-of-number-in-total (number total)
>   "Return the percentage that NUMBER represents in a TOTAL."
>   (/ number total 0.01))

But that's even better, one less function AND no 1.0 or
`float'.

(defun percent (n d)
  (let ((pct (/ n d 0.01)))
    (message "%.1f%%" pct)))
;; (percent 8  256) ; 3.1%
;; (percent 0 1337) ; 0.0%

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 18:21]:
> Jean Louis wrote:
> 
> > Thanks, I knew somebody will improve it for free.
> >
> > Now I will use:
> >
> > (defun pct-of-number-in-total (number total)
> >   "Return the percentage that NUMBER represents in a TOTAL."
> >   (/ number total 0.01))
> 
> But that's even better, one less function AND no 1.0 or
> `float'.
> 
> (defun percent (n d)
>   (let ((pct (/ n d 0.01)))
>     (message "%.1f%%" pct)))
> ;; (percent 8  256) ; 3.1%
> ;; (percent 0 1337) ; 0.0%

Does 1337 comes from your early years?

Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> (defun percent (n d)
>>   (let ((pct (/ n d 0.01)))
>>     (message "%.1f%%" pct)))
>> ;; (percent 8  256) ; 3.1%
>> ;; (percent 0 1337) ; 0.0%
>
> Does 1337 comes from your early years?

It does, but keeping every single file since day one enables
me to operate at a high level even today...

  "You can fire your arrows from the Tower of Babel. But you
  can NEVER strike God!"
  X-Men: Apocalypse (2016)
  <https://transcripts.fandom.com/wiki/X-Men:_Apocalypse>

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Jean Louis]

I have stumbled upon your various key settings on your website.

Please make the Super key work in console. What has to be done?

Jean

Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> I have stumbled upon your various key settings on
> your website.
>
> Please make the Super key work in console. What has to
> be done?

I don't have a Super key - or do I? aaah - but anyway, if it
doesn't work like the way I describe for other keys, it
doesn't work according to that method :)

Anyway on the TODO list is to proofread that old tutorial and
make a  blog post of it. Stay tuned...

  https://dataswamp.org/~incal/blog/climbing-gear/climbing-gear.html

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 18:25]:
> Jean Louis wrote:
> 
> > I have stumbled upon your various key settings on
> > your website.
> >
> > Please make the Super key work in console. What has to
> > be done?
> 
> I don't have a Super key - or do I? aaah - but anyway, if it
> doesn't work like the way I describe for other keys, it
> doesn't work according to that method :)

That key between Control and Alternative? Or dentist have taken it out
by mistake?

> Anyway on the TODO list is to proofread that old tutorial and
> make a  blog post of it. Stay tuned...
> 
>   https://dataswamp.org/~incal/blog/climbing-gear/climbing-gear.html

I am descending rather, mostly into dark pits as 10-30 meters deep,
climbing by necessity, using Grigri and other stuff. Good to see that,
I may consider at some places making my sleeping place on the tree. I
can get some details from the picture. You have not damage the tree by
using those belts. Now to stay on topic ;-) how did you use Emacs
there, was it for calculation of forces?

Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> That key between Control and Alternative? Or dentist have
> taken it out by mistake?

That is keycode 125 according to showkey(1) (do
'chmod +s /bin/showkey' if it doesn't work) so with the
console key workaround it would work.

> I am descending rather, mostly into dark pits as 10-30
> meters deep, climbing by necessity, using Grigri and other
> stuff.

Really? Cool! Photos?

> Good to see that, I may consider at some places making my
> sleeping place on the tree. I can get some details from the
> picture. You have not damage the tree by using those belts.
> Now to stay on topic ;-) how did you use Emacs there, was it
> for calculation of forces?

See for example:

  https://dataswamp.org/~incal/emacs-init/wood.el

But mostly Emacs was used to build and maintain a rational
mind which was then applied to construction :P

Emacs was of course used to do the HTML and CSS. Winter theme!
  
  https://dataswamp.org/~incal/blog/tree-house/tree-house.html
  https://dataswamp.org/~incal/blog/global.css

Special mention: Using Tramp made the workflow soo much better
and faster! So thank you, Tramp maintainer(s)! (and whoever
genius who first thought of it!)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

OT: more praise to Tramp - was: Re: Make Super key work in console - was Re: math

[ken]

On 02/13/2021 03:26 PM, Emanuel Berg via Users list for the GNU Emacs 
text editor wrote:
> Special mention: Using Tramp made the workflow soo much better
> and faster! So thank you, Tramp maintainer(s)! (and whoever
> genius who first thought of it!)

Yes, Tramp (predated though, I believe, by ange-ftp) was and is an 
amazing feat of technology, making the difficult, and sometimes the 
impossible, absolutely trivial.

console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Anyway on the TODO list is to proofread that old tutorial
> and make a blog post of it. Stay tuned...

Here is a revised version of the tutorial, still a text file:

  https://dataswamp.org/~incal/tty-emacs-keys.txt

Blog post RSN.

feedback welcome

keep it real time

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 02:44]:
> > Anyway on the TODO list is to proofread that old tutorial
> > and make a blog post of it. Stay tuned...
> 
> Here is a revised version of the tutorial, still a text file:
> 
>   https://dataswamp.org/~incal/tty-emacs-keys.txt

Feedback:

In relation of virtual terminal and tty in relation of Supera key they
are not quite same. `konsole' is virtual terminal and allows usage of
Super key. For example loadkeys, dumpkeys, they don't work in XTerm
here as they cannot get descriptor of the console. That is not
same. Correct your text if you find it so after inspection of this
statement.

I see you have knowledge on that, so please, help us define Super key
to work in other virtual terminals such as XTerm and separately,
define Super key in tty. At least tell me what could be done or how
would you approach it even if it does not work at first.

Yesterday `showkey' have shown to me in tty that it is
125. Alright. Now how to make it work in Emacs?

Do you mean with loadkeys?

How?

Re: console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> In relation of virtual terminal and tty in relation of
> Supera key they are not quite same. `konsole' is virtual
> terminal and allows usage of Super key. For example
> loadkeys, dumpkeys, they don't work in XTerm here as they
> cannot get descriptor of the console. That is not same.
> Correct your text if you find it so after inspection of
> this statement.

OK, added xterm as an explicit example:

  At the very least in the context of this tutorial, VT, tty
  and console all refer to the same thing. But they are not
  the same as any Unix "terminal emulator" (e.g., xterm, rxvt
  etc) as they run in X. For sure, none of this stuff works
  in X.

> and separately, define Super key in tty. At least tell me
> what could be done Yesterday `showkey' have shown to me in
> tty that it is 125. Alright. Now how to make it work
> in Emacs?

The tutorial is supposed to answer that question :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 09:22]:
> Jean Louis wrote:
> 
> > In relation of virtual terminal and tty in relation of
> > Supera key they are not quite same. `konsole' is virtual
> > terminal and allows usage of Super key. For example
> > loadkeys, dumpkeys, they don't work in XTerm here as they
> > cannot get descriptor of the console. That is not same.
> > Correct your text if you find it so after inspection of
> > this statement.
> 
> OK, added xterm as an explicit example:
> 
>   At the very least in the context of this tutorial, VT, tty
>   and console all refer to the same thing. But they are not
>   the same as any Unix "terminal emulator" (e.g., xterm, rxvt
>   etc) as they run in X. For sure, none of this stuff works
>   in X.
> 
> > and separately, define Super key in tty. At least tell me
> > what could be done Yesterday `showkey' have shown to me in
> > tty that it is 125. Alright. Now how to make it work
> > in Emacs?
> 
> The tutorial is supposed to answer that question :)

It means you do not know a solution, I will assume so. We need it. It
could liberate thousands of possible key combinations before the
keyboard dies on desktop. Rush.

Re: console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Yuri Khan]

On Sun, 14 Feb 2021 at 15:06, Jean Louis <bugs@gnu.support> wrote:

> It means you do not know a solution, I will assume so. We need it. It
> could liberate thousands of possible key combinations before the
> keyboard dies on desktop. Rush.

For X, please see Kitty [1]. It is a terminal emulator that implements
an alternative key encoding scheme [2] which allows to represent all
modifier keys, all modifier+key combinations, even key releases.

[1]: https://sw.kovidgoyal.net/kitty/
[2]: https://sw.kovidgoyal.net/kitty/keyboard-protocol.html

There is a “small” issue — you will need to create a terminal-specific
initialization file [3] in Emacs that defines an ‘input-decode-map’
that will translate Kitty escape sequences to Emacs representation,
and you will need to invent a way to ignore key release sequences.

[3]: (info "(elisp) Terminal-Specific")

Last time I tried that, I set up ‘input-decode-map’ so that it
translates each key release sequence to an empty key sequence. But,
due to the way prefix key prompting works in Emacs, it clears the echo
area each time a key is released. Which pretty much kills every status
message Emacs might produce in response to a key *press*.

Maybe there are other ways to ignore key release sequences. I have not
been able to devote enough time into discovering them.

If you succeed in setting up Emacs with Kitty’s advanced key protocol,
I’d be very interested.

Re: console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-02-14 11:38]:
> On Sun, 14 Feb 2021 at 15:06, Jean Louis <bugs@gnu.support> wrote:
> 
> > It means you do not know a solution, I will assume so. We need it. It
> > could liberate thousands of possible key combinations before the
> > keyboard dies on desktop. Rush.
> 
> For X, please see Kitty [1]. It is a terminal emulator that implements
> an alternative key encoding scheme [2] which allows to represent all
> modifier keys, all modifier+key combinations, even key releases.
> 
> [1]: https://sw.kovidgoyal.net/kitty/
> [2]: https://sw.kovidgoyal.net/kitty/keyboard-protocol.html
> 
> There is a “small” issue — you will need to create a terminal-specific
> initialization file [3] in Emacs that defines an ‘input-decode-map’
> that will translate Kitty escape sequences to Emacs representation,
> and you will need to invent a way to ignore key release sequences.
> 
> [3]: (info "(elisp) Terminal-Specific")
> 
> Last time I tried that, I set up ‘input-decode-map’ so that it
> translates each key release sequence to an empty key sequence. But,
> due to the way prefix key prompting works in Emacs, it clears the echo
> area each time a key is released. Which pretty much kills every status
> message Emacs might produce in response to a key *press*.

In `konsole' terminal emulator the Super key just works. Terminal
emulators are under X, they are not console. I do not see much of
problem in setting Super for some terminal emulators, but that is not
a point for Emacs being compatible both on console and X.

I would like that we find way for Super key to works equally in
console, that means without X, on tty, and over SSH, equally as it
runs inside of the X.

That would liberate many new keys which would be harmonized between
the GUI and console Emacs version.

Jean

Re: console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Terminal emulators are under X, they are not console.

Well, IMO there are just two things. There are terminals, i.e.
physical entities, and there are terminal emulators.
"Virtual terminal" is just another name for a terminal
emulator. Think about it, the software, what it does, even the
name - it is the same thing.

So the Linux VTs, which are the ttys, which are sometimes
referred to as the console, all of that, which is the same
thing, that is a terminal emulator, technically speaking.

The X terminal emulators, e.g. xterm, rxvt etc, are also ...
terminal emulators! However they are not the Linux VTs, or the
ttys, and they shouldn't be referred to as the console.

Not if one wants to avoid confusion, at least.

> That would liberate many new keys which would be harmonized
> between the GUI and console Emacs version.

Hm... Do the X terminal emulators have a common configuration
with respect to keys, even? Or do you do that on the XX level?

XX = X and only X

:)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 16:44]:
> So the Linux VTs, which are the ttys, which are sometimes
> referred to as the console, all of that, which is the same
> thing, that is a terminal emulator, technically speaking.

Alright.

> The X terminal emulators, e.g. xterm, rxvt etc, are also ...
> terminal emulators! However they are not the Linux VTs, or the
> ttys, and they shouldn't be referred to as the console.

I do not refer to such as console, but I do refer to that which
appears before X as console.

Anyway, `loadkeys' does not work in X terminals.

> > That would liberate many new keys which would be harmonized
> > between the GUI and console Emacs version.
> 
> Hm... Do the X terminal emulators have a common configuration
> with respect to keys, even? Or do you do that on the XX level?

For terminal emulators I have no concern currently. I wish to enable
Super key in combination with other keys on console or however you
call the text that appears before the X is spawned.

Jean

Re: console key tutorial, revised (was: Re: Make Super key work in console - was Re: math (was: Re: not good proposal: "C-z <letter>" reserved for users))

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> and separately, define Super key in tty. At least tell me
>>> what could be done Yesterday `showkey' have shown to me in
>>> tty that it is 125. Alright. Now how to make it work
>>> in Emacs?
>> 
>> The tutorial is supposed to answer that question [...]
>
> It means you do not know a solution, I will assume so.
> We need it. It could liberate thousands of possible key
> combinations before the keyboard dies on desktop. Rush.

# supposed Super key
keycode 125 = U+1004

(define-key input-decode-map [?\u1004] [super-key])
(global-set-key [super-key]
  (lambda () (interactive) (message "Jean is a lamer")) )

Works great! I'll use it every day, I think.

Files:

  https://dataswamp.org/~incal/conf/vt/remap.inc
  https://dataswamp.org/~incal/emacs-init/console-keys.el

Tutorial:

  https://dataswamp.org/~incal/tty-emacs-keys.txt

But I'll revert remap.inc soon, so check it out right now.
Turns out, I already had that key assign, as the
Compose key... (but I think I'll keep the Elisp. I just like
it)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Snippet for website inquiries by using one click on the email address

[Jean Louis]

When you show a picture on a website, it is still a picture and not an
interactive form with user where user can click on the email address
and invoke the mail client to contact you.

You do that probably to avoid spam, but whoever contacts you and know
your email address may anyway have viruses or may sign up onto spammy
websites such as LinkedIn or others and provide all their contacts to
third party. Third party can sell email addresses to other companies,
or crackers can steal databases.

Thus with the email address as image you avoid nothing as
webmaster. It is better if you let people contact you straight by
clicking on the email address.

To avoid spam you may assign email addresses such as being 1, 2 or 3
etc.

1. In January is welcome1@example.com

2. In May, maybe it becomes welcome2@example.com, disable
   welcome1@example.com when you start receiving some considerable
   spam.
   
3. Continue by this pattern

For HTML you do as this:

For any inquiries simply 
<a href="mailto:welcome1@example.com?subject=Inquiry&nbsp;from&nbsp;website&amp;body=Hello,%0D%0A%0D%0Athis&nbsp;is&nbsp;my&nbsp;inquiry&nbsp;from&nbsp;https://www.example.com&nbsp;and&nbsp;here&nbsp;is&nbsp;my&nbsp;message:%0D%0A%0D%0A%0D%0A" title="welcome1@example.com">send email</a> to us.

Such email address is then specific for website inquiries only. People
do many things to avoid spam and thus also avoid customers. Allow
customers to contact you by one click and swallow some possible
spam. When you see too many spam, just update the website with new
email address such as welcome2@example.com and disable the other one
as it was dedicated for website only.

Jean

Re: Snippet for website inquiries by using one click on the email address

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> When you show a picture on a website, it is still a picture
> and not an interactive form with user where user can click
> on the email address and invoke the mail client to
> contact you.
>
> You do that probably to avoid spam, but whoever contacts you
> and know your email address may anyway have viruses or may
> sign up onto spammy websites such as LinkedIn or others and
> provide all their contacts to third party. Third party can
> sell email addresses to other companies, or crackers can
> steal databases.

This refers to this image:

  https://dataswamp.org/~incal/mailto.png

> Thus with the email address as image you avoid nothing
> as webmaster.

But regardless of whatever, I don't get spam.

Besides spammers don't work like that anymore. They trade huge
dumps on Darknet rather than employ crawlers that crack
people's images with their e-mails... (hm, I didn't know this
custom was so widely spread! they got the idea from me?
from my part at least, I never saw it anywhere else)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Make Super key work in console

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis:

> Now is it possible to define Super-LETTER as prefix?

;; Super-Jean's key
(define-key input-decode-map [?\u1004] [super-key])

(define-prefix-command 'super-jean)

(global-set-key [super-key] 'super-jean)

(global-set-key
 [super-key ?\l]
 (lambda ()
   (interactive)
   (message "Manny's skills are uncanny")) )

https://dataswamp.org/~incal/figures/emacs/super-jean.png

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Make Super key work in console

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 22:39]:
> Jean Louis:
> 
> > Now is it possible to define Super-LETTER as prefix?
> 
> ;; Super-Jean's key
> (define-key input-decode-map [?\u1004] [super-key])
> 
> (define-prefix-command 'super-jean)
> 
> (global-set-key [super-key] 'super-jean)
> 
> (global-set-key
>  [super-key ?\l]
>  (lambda ()
>    (interactive)
>    (message "Manny's skills are uncanny")) )

OK that almost works. I say almost. 

First it started working so I can get the uncanny skills. But then I have tried to evaluated:

(global-set-key [super-key ?\a] 'tetris)

And that one does not work. 

I have also discovered that it does not act as true modifier, it acts rather as a key after key. So I cannot press Super and hold it pressed to invoke other key. In fact I have to press Super and then release it to press the other key for the function to start working.

Do you know why I cannot invoke tetris? Not that I need tetris, I would like to use my business management in console too by using the Super key. Of course I can replace the prefix with something else, but I still explore that possibility of using Super in the console. 

It would also release or liberate many keys for Emacs in console. You are doing good progress.

Now:

- why tetris does not work?

- can we make it a true modifier, even if we replace its underlying meaning to something else?

Then we can invoke a function that can detect if Emacs is running in console and that function can replace the prefix and modify it to something similar as you have proposed.

In GUI there would be no need for modification.

Jean

Re: Make Super key work in console

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> OK that almost works. I say almost. 
>
> First it started working so I can get the uncanny skills.
> But then I have tried to evaluated:
>
> (global-set-key [super-key ?\a] 'tetris)
>
> And that one does not work. 

Something up with a. Try with some other char, l for example,
it works. BTW I realized the ?\ isn't needed, like one does
just [l] for a one-element vector. No idea why a doesn't work.

> I have also discovered that it does not act as true
> modifier, it acts rather as a key after key. So I cannot
> press Super and hold it pressed to invoke other key.

It is described in the tutorial:

  https://dataswamp.org/~incal/tty-emacs-keys.txt

I you follow the links to the example files, you see I get
even very exotic combinations to works, for example
Meta Shift Return.

That said, let me ask, how do you define a "true modifier" in
Emacs? I mean not just for keys that previously don't work,
but in general?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Make Super key work in console

[Yuri Khan]

On Mon, 15 Feb 2021 at 23:37, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Something up with a. Try with some other char, l for example,
> it works. BTW I realized the ?\ isn't needed, like one does
> just [l] for a one-element vector. No idea why a doesn't work.

Because ?\a is the BEL character, also known as ?\C-g.

Re: Make Super key work in console

[Emanuel Berg via Users list for the GNU Emacs text editor]

Yuri Khan wrote:

>> Something up with a. Try with some other char, l for
>> example, it works. BTW I realized the ?\ isn't needed, like
>> one does just [l] for a one-element vector. No idea why
>> a doesn't work.
>
> Because ?\a is the BEL character, also known as ?\C-g.

No problem - we use the same method to rewire that as well :P

No. But thanks for the clarification...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Make Super key work in console

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-02-15 21:07]:
> On Mon, 15 Feb 2021 at 23:37, Emanuel Berg via Users list for the GNU
> Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> 
> > Something up with a. Try with some other char, l for example,
> > it works. BTW I realized the ?\ isn't needed, like one does
> > just [l] for a one-element vector. No idea why a doesn't work.
> 
> Because ?\a is the BEL character, also known as ?\C-g.

Alright, but I would like to find solution to be able to bind Super key in
console with any character regardless. In combination with Super it should not
be bell character.

Re: Make Super key work in console

[Yuri Khan]

On Tue, 16 Feb 2021 at 13:57, Jean Louis <bugs@gnu.support> wrote:

> Alright, but I would like to find solution to be able to bind Super key in
> console with any character regardless. In combination with Super it should not
> be bell character.

You understand that the main obstacle to that is the lack of a
standardized encoding for key data in the terminal protocol? Before we
have that, you will have to find a new workaround for every terminal
emulator you use.

Earlier, I have pointed you to the only terminal emulator I know that
is trying to actually solve the problem, by inventing a protocol
extension that faithfully represents all keys. Get Emacs playing nice
with that, then push for adoption of that protocol extension in other
terminal emulators, including Linux console.

Re: Make Super key work in console

[Jean Louis]

Good procedure proposal, I have to research it

On February 16, 2021 7:42:36 AM UTC, Yuri Khan <yuri.v.khan@gmail.com> wrote:
>On Tue, 16 Feb 2021 at 13:57, Jean Louis <bugs@gnu.support> wrote:
>
>> Alright, but I would like to find solution to be able to bind Super
>key in
>> console with any character regardless. In combination with Super it
>should not
>> be bell character.
>
>You understand that the main obstacle to that is the lack of a
>standardized encoding for key data in the terminal protocol? Before we
>have that, you will have to find a new workaround for every terminal
>emulator you use.
>
>Earlier, I have pointed you to the only terminal emulator I know that
>is trying to actually solve the problem, by inventing a protocol
>extension that faithfully represents all keys. Get Emacs playing nice
>with that, then push for adoption of that protocol extension in other
>terminal emulators, including Linux console.


Jean

Re: Make Super key work in console

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-02-16 10:43]:
> On Tue, 16 Feb 2021 at 13:57, Jean Louis <bugs@gnu.support> wrote:
> 
> > Alright, but I would like to find solution to be able to bind Super key in
> > console with any character regardless. In combination with Super it should not
> > be bell character.
> 
> You understand that the main obstacle to that is the lack of a
> standardized encoding for key data in the terminal protocol? Before we
> have that, you will have to find a new workaround for every terminal
> emulator you use.

I got that, but let me know where is that defined that I can at least
ask one by one so that implementation comes sooner. I think it is sooo
late that some keys used for decades are not implemented.

> Earlier, I have pointed you to the only terminal emulator I know that
> is trying to actually solve the problem, by inventing a protocol
> extension that faithfully represents all keys. Get Emacs playing nice
> with that, then push for adoption of that protocol extension in other
> terminal emulators, including Linux console.

That sounds as good strategy. I have yet to research that. I know that
`konsole' works, I have to research your option.

Jean

Re: Make Super key work in console

[Yuri Khan]

On Sat, 20 Feb 2021 at 21:35, Jean Louis <bugs@gnu.support> wrote:

> > You understand that the main obstacle to that is the lack of a
> > standardized encoding for key data in the terminal protocol? Before we
> > have that, you will have to find a new workaround for every terminal
> > emulator you use.
>
> I got that, but let me know where is that defined that I can at least
> ask one by one so that implementation comes sooner. I think it is sooo
> late that some keys used for decades are not implemented.

Probably nowhere except each terminal emulator’s source code.

> > Earlier, I have pointed you to the only terminal emulator I know that
> > is trying to actually solve the problem, by inventing a protocol
> > extension that faithfully represents all keys. Get Emacs playing nice
> > with that, then push for adoption of that protocol extension in other
> > terminal emulators, including Linux console.
>
> That sounds as good strategy. I have yet to research that. I know that
> `konsole' works, I have to research your option.

I was surprised to learn that Konsole chose to translate Super+<key>
into C-x @ s <key>, exactly what Emacs interprets back as S-<key>.

https://bugs.kde.org/show_bug.cgi?id=96282

In my opinion, it’s not a good way. Just piling dirty hacks to cover
the lack of general-purpose key representation.

Re: Make Super key work in console

[Stefan Monnier]

> I was surprised to learn that Konsole chose to translate Super+<key>
> into C-x @ s <key>, exactly what Emacs interprets back as S-<key>.

Yuck!


        Stefan

Re: Make Super key work in console

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 20 Feb 2021 10:46:20 -0500
> 
> > I was surprised to learn that Konsole chose to translate Super+<key>
> > into C-x @ s <key>, exactly what Emacs interprets back as S-<key>.
> 
> Yuck!

Why "Yuck"?  This is in no way singular: many terminal emulators
convert M-SOMETHING into ESC SOMETHING, at least as an option.

Re: Make Super key work in console

[Yuri Khan]

On Sat, 20 Feb 2021 at 23:08, Eli Zaretskii <eliz@gnu.org> wrote:

> > > I was surprised to learn that Konsole chose to translate Super+<key>
> > > into C-x @ s <key>, exactly what Emacs interprets back as S-<key>.
> >
> > Yuck!
>
> Why "Yuck"?  This is in no way singular: many terminal emulators
> convert M-SOMETHING into ESC SOMETHING, at least as an option.

Yuck that, too.

Re: Make Super key work in console

[Yuri Khan]

On Sat, 20 Feb 2021 at 23:16, Yuri Khan <yuri.v.khan@gmail.com> wrote:
>
> On Sat, 20 Feb 2021 at 23:08, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > > > I was surprised to learn that Konsole chose to translate Super+<key>
> > > > into C-x @ s <key>, exactly what Emacs interprets back as S-<key>.
> > >
> > > Yuck!
> >
> > Why "Yuck"?  This is in no way singular: many terminal emulators
> > convert M-SOMETHING into ESC SOMETHING, at least as an option.
>
> Yuck that, too.

In case further explanation is needed:

* The fact that terminals encode functional keys, editing keys,
Alt+keys as ESC sequences has made it impossible to reliably[1] detect
a single Escape key press.

* Many terminals of VT-100 descent encode keys as CSI sequences (ESC [
…), making it impossible to reliably[1] detect a single Alt+[ key
combination.

* In application keypad mode, terminals also encode arrow keys as SS3
sequences (ESC O …), making it impossible to reliably[1] detect an
Alt+Shift+o.

[1]: yes, a 100ms timeout goes a long way, unless you’re working over
ssh on a laggy/jerky connection.

Other deficiencies of key representations in terminals include:

* Ctrl+key combinations are only defined for letter keys and select punctuation.
* Ctrl+Shift+keys are indistinguishable from Ctrl+keys.
* Alt+key combinations are Caps Lock-sensitive.
* Tab is indistinguishable from Ctrl+I, Backspace from either Ctrl+H
or Ctrl+?, and Enter from either Ctrl+J or Ctrl+M.
* There is much uncertainty about whether the sequence called F13
should mean Shift+F1 or Shift+F3.

Re: Make Super key work in console

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-02-20 19:39]:
> On Sat, 20 Feb 2021 at 23:16, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> >
> > On Sat, 20 Feb 2021 at 23:08, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > > > I was surprised to learn that Konsole chose to translate Super+<key>
> > > > > into C-x @ s <key>, exactly what Emacs interprets back as S-<key>.
> > > >
> > > > Yuck!
> > >
> > > Why "Yuck"?  This is in no way singular: many terminal emulators
> > > convert M-SOMETHING into ESC SOMETHING, at least as an option.
> >
> > Yuck that, too.
> 
> In case further explanation is needed:
> 
> * The fact that terminals encode functional keys, editing keys,
> Alt+keys as ESC sequences has made it impossible to reliably[1] detect
> a single Escape key press.
> 
> * Many terminals of VT-100 descent encode keys as CSI sequences (ESC [
> …), making it impossible to reliably[1] detect a single Alt+[ key
> combination.

VT100 are almost not in existence and use, there are some sold, but
that is now very rare. Why people don't start making PC or other type
of modern computers as terminal emulators. That is what is practically
used. We emulate machines which we do not have.

Wow, progress of 21st century.

It is alright to have terminal emulators but only to access software
servers that also emulates access by such terminals.

Both the server side software and terminal emulators shall start
emulating these modern computers we have.

Maybe terminal capabilities databases already have some of emulations
that do represent modern computers.

Now in /usr/share/terminfo I can find entries like `ibmpc' or `unixpc'
do you think any of them could have the Super key entry there? I have
tried using such with Emacs in console but do not see that Super key
is working.

As maybe just changing $TERM variable could make it work, what do you
think?

> * In application keypad mode, terminals also encode arrow keys as SS3
> sequences (ESC O …), making it impossible to reliably[1] detect an
> Alt+Shift+o.
> 
> [1]: yes, a 100ms timeout goes a long way, unless you’re working over
> ssh on a laggy/jerky connection.
> 
> Other deficiencies of key representations in terminals include:
> 
> * Ctrl+key combinations are only defined for letter keys and select punctuation.
> * Ctrl+Shift+keys are indistinguishable from Ctrl+keys.
> * Alt+key combinations are Caps Lock-sensitive.
> * Tab is indistinguishable from Ctrl+I, Backspace from either Ctrl+H
> or Ctrl+?, and Enter from either Ctrl+J or Ctrl+M.
> * There is much uncertainty about whether the sequence called F13
> should mean Shift+F1 or Shift+F3.

Maybe it is possible to define new terminfo file that supports all the
keys commonly found on today's keyboard.

Jean

Re: Make Super key work in console

[Yuri Khan]

On Sun, 21 Feb 2021 at 12:32, Jean Louis <bugs@gnu.support> wrote:

> Now in /usr/share/terminfo I can find entries like `ibmpc' or `unixpc'
> do you think any of them could have the Super key entry there? I have
> tried using such with Emacs in console but do not see that Super key
> is working.
>
> As maybe just changing $TERM variable could make it work, what do you
> think?

Terminfo database entries do not *define* how terminals work. They
*describe* it so that applications can decode the character stream
they receive.

By changing your TERM variable, you tell your applications “Disregard
what my terminal emulator says about itself (if anything); treat it as
if it were what I say”. It’s an escape hatch, not a configuration
facility.

> Maybe it is possible to define new terminfo file that supports all the
> keys commonly found on today's keyboard.

It would be possible, but you would still need a terminal emulator
that actually emits the sequences you put in that terminfo entry.

Re: Make Super key work in console

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-02-21 10:19]:
> On Sun, 21 Feb 2021 at 12:32, Jean Louis <bugs@gnu.support> wrote:
> 
> > Now in /usr/share/terminfo I can find entries like `ibmpc' or `unixpc'
> > do you think any of them could have the Super key entry there? I have
> > tried using such with Emacs in console but do not see that Super key
> > is working.
> >
> > As maybe just changing $TERM variable could make it work, what do you
> > think?
> 
> Terminfo database entries do not *define* how terminals work. They
> *describe* it so that applications can decode the character stream
> they receive.
> 
> By changing your TERM variable, you tell your applications “Disregard
> what my terminal emulator says about itself (if anything); treat it as
> if it were what I say”. It’s an escape hatch, not a configuration
> facility.

I got the point.

> > Maybe it is possible to define new terminfo file that supports all the
> > keys commonly found on today's keyboard.
> 
> It would be possible, but you would still need a terminal emulator
> that actually emits the sequences you put in that terminfo entry.

Yes, and that is what I cannot easily inspect, I can just assume that
some terminal types like "ibmpc" or "unixpc" could maybe have that key
defined. At least you may get idea on how I think that problem is
maybe solved at least for terminal emulators, but I cannot verify it
that it works.

Re: Make Super key work in console

[Stefan Monnier]

>> > I was surprised to learn that Konsole chose to translate Super+<key>
>> > into C-x @ s <key>, exactly what Emacs interprets back as S-<key>.
>> Yuck!
> Why "Yuck"?

Terminal's escape sequences should start with ESC.

Also, is `C-x @ s ESC` presumed to be `s-ESC` or is it `super` applied to
the escape sequence that this ESC starts?

I mean, our encoding is poor (since it doesn't allow combining several
`C-x @` together, for example), but it can be justified by the desire to
cater to the most common case without unduly burdening the user how has
to type those keys.

But for a terminal emulator, the one who "types those keys" is the
terminal emulator, so it wouldn't be "burdened" by having to type
a few more keys to have a clear and unambiguous encoding.

> This is in no way singular: many terminal emulators convert
> M-SOMETHING into ESC SOMETHING, at least as an option.

That also somewhat sucks, but *much* less (and it was done at a time
when you could argue that resource constraints made it important to have
a "short and simple" approach rather than a "general, robust, and
reliable" one).


        Stefan

Re: Make Super key work in console

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 20 Feb 2021 11:49:46 -0500
> 
> But for a terminal emulator, the one who "types those keys" is the
> terminal emulator, so it wouldn't be "burdened" by having to type
> a few more keys to have a clear and unambiguous encoding.
> 
> > This is in no way singular: many terminal emulators convert
> > M-SOMETHING into ESC SOMETHING, at least as an option.
> 
> That also somewhat sucks, but *much* less (and it was done at a time
> when you could argue that resource constraints made it important to have
> a "short and simple" approach rather than a "general, robust, and
> reliable" one).

I don't think I understand.  Given the APIs used by text-mode programs
to read keyboard input, what are the alternatives for those "yucky"
methods?

Re: Make Super key work in console

[Stefan Monnier]

>> But for a terminal emulator, the one who "types those keys" is the
>> terminal emulator, so it wouldn't be "burdened" by having to type
>> a few more keys to have a clear and unambiguous encoding.
>> 
>> > This is in no way singular: many terminal emulators convert
>> > M-SOMETHING into ESC SOMETHING, at least as an option.
>> 
>> That also somewhat sucks, but *much* less (and it was done at a time
>> when you could argue that resource constraints made it important to have
>> a "short and simple" approach rather than a "general, robust, and
>> reliable" one).
>
> I don't think I understand.  Given the APIs used by text-mode programs
> to read keyboard input, what are the alternatives for those "yucky"
> methods?

Using escape sequences that start with ESC (and which hence collide
with actual uses of the ESC key) was arguably unavoidable, indeed.

But using "just ESC" as "the escape sequence for meta" leads to more conflicts
since it doesn't just conflict with the use of the ESC key but also with
ESC used for escape sequences.

They should have used "ESC <something>" for the meta key so you don't
get conflicts like `M-O` conflicting with escape sequences that start
with `ESC O`.


        Stefan

Re: Make Super key work in console

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 20 Feb 2021 13:13:33 -0500
> 
> > I don't think I understand.  Given the APIs used by text-mode programs
> > to read keyboard input, what are the alternatives for those "yucky"
> > methods?
> 
> Using escape sequences that start with ESC (and which hence collide
> with actual uses of the ESC key) was arguably unavoidable, indeed.
> 
> But using "just ESC" as "the escape sequence for meta" leads to more conflicts
> since it doesn't just conflict with the use of the ESC key but also with
> ESC used for escape sequences.
> 
> They should have used "ESC <something>" for the meta key so you don't
> get conflicts like `M-O` conflicting with escape sequences that start
> with `ESC O`.

By "they" you mean Emacs?  Because AFAIK it was Emacs which started
translating "ESC KEY" to Meta-KEY.

Re: Make Super key work in console

[Stefan Monnier]

>> They should have used "ESC <something>" for the meta key so you don't
>> get conflicts like `M-O` conflicting with escape sequences that start
>> with `ESC O`.
> By "they" you mean Emacs?

No, I'm talking about the terminal (emulators).

> Because AFAIK it was Emacs which started translating "ESC KEY" to
> Meta-KEY.

And just as for `C-x @ <foo>`, this is acceptable for Emacs where it's
more important to make sure the sequence is short, for the convenience
of the user, even if it comes at the cost of introducing some
occasional conflicts.
For terminal emulators there's no such tradeoff to make.


        Stefan

Re: Make Super key work in console

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 20 Feb 2021 16:14:06 -0500
> 
> >> They should have used "ESC <something>" for the meta key so you don't
> >> get conflicts like `M-O` conflicting with escape sequences that start
> >> with `ESC O`.
> > By "they" you mean Emacs?
> 
> No, I'm talking about the terminal (emulators).

Then I don't understand how this could be possible.

> > Because AFAIK it was Emacs which started translating "ESC KEY" to
> > Meta-KEY.
> 
> And just as for `C-x @ <foo>`, this is acceptable for Emacs where it's
> more important to make sure the sequence is short, for the convenience
> of the user, even if it comes at the cost of introducing some
> occasional conflicts.
> For terminal emulators there's no such tradeoff to make.

They wanted to support Emacs and software that adopted the Emacs
keybindings (such as Readline, Bash, etc.).

Re: Make Super key work in console

[Stefan Monnier]

>> >> They should have used "ESC <something>" for the meta key so you don't
>> >> get conflicts like `M-O` conflicting with escape sequences that start
>> >> with `ESC O`.
>> > By "they" you mean Emacs?
>> No, I'm talking about the terminal (emulators).
> Then I don't understand how this could be possible.

I guess we're miscommunication, then.  But I don't know which part you
don't understand.

> They wanted to support Emacs and software that adopted the Emacs
> keybindings (such as Readline, Bash, etc.).

Right, a quick hack.


        Stefan

Re: Make Super key work in console

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-02-20 18:27]:
> > I got that, but let me know where is that defined that I can at least
> > ask one by one so that implementation comes sooner. I think it is sooo
> > late that some keys used for decades are not implemented.
> 
> Probably nowhere except each terminal emulator’s source code.

Aha, like that, so each is different.

> > > Earlier, I have pointed you to the only terminal emulator I know that
> > > is trying to actually solve the problem, by inventing a protocol
> > > extension that faithfully represents all keys. Get Emacs playing nice
> > > with that, then push for adoption of that protocol extension in other
> > > terminal emulators, including Linux console.
> >
> > That sounds as good strategy. I have yet to research that. I know that
> > `konsole' works, I have to research your option.
> 
> I was surprised to learn that Konsole chose to translate Super+<key>
> into C-x @ s <key>, exactly what Emacs interprets back as S-<key>.
> 
> https://bugs.kde.org/show_bug.cgi?id=96282
> 
> In my opinion, it’s not a good way. Just piling dirty hacks to cover
> the lack of general-purpose key representation.

That is not good way is it does not recognize Super key.

Re: Make Super key work in console

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> In my opinion, it’s not a good way. Just piling dirty hacks
>> to cover the lack of general-purpose key representation.
>
> That is not good way is it does not recognize Super key.

Super-Jean forgets that in this very thread, his key was shown
to work just as any other key, using this method.

That said, while this so-called dirty hack is very useful to
people using Emacs in a Linux VT, I agree with Yuri it
shouldn't be thought of as a way to solve this issue more
broadly...

I mean, of course not. Even Super-Jean understands that
(I think)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Make Super key work in console

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-21 08:07]:
> Jean Louis wrote:
> 
> >> In my opinion, it’s not a good way. Just piling dirty hacks
> >> to cover the lack of general-purpose key representation.
> >
> > That is not good way is it does not recognize Super key.
> 
> Super-Jean forgets that in this very thread, his key was shown
> to work just as any other key, using this method.

by having file `key':

 keycode 125 = U+1004

and by doing the command:

$ sudo loadkeys key

and by evaluating:

(define-key input-decode-map [?\u1004] [super-key])

(define-prefix-command 'super-jean)

(global-set-key [super-key] 'super-jean)

(global-set-key
 [super-key ?\l]
 (lambda ()
   (interactive)
   (message "Manny's skills are uncanny"))

 (global-set-key [super-key ?\t] 'tetris)
 
I cannot get it to work in the console. I am not speaking of X
terminal emulators.

Do you get it to work in console?

What am I doing wrong?

Re: Make Super key work in console

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> (global-set-key
>  [super-key ?\l]
>  (lambda ()
>    (interactive)
>    (message "Manny's skills are uncanny"))

add one )

>  (global-set-key [super-key ?\t] 'tetris)

(global-set-key [super-key t] #'tetris)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Make Super key work in console

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-21 09:11]:
> Jean Louis wrote:
> 
> > (global-set-key
> >  [super-key ?\l]
> >  (lambda ()
> >    (interactive)
> >    (message "Manny's skills are uncanny"))
> 
> add one )
> 
> >  (global-set-key [super-key ?\t] 'tetris)
> 
> (global-set-key [super-key t] #'tetris)

Thank you.

That one works well, thank you. Now there is workaround for Super key
to work in console.

That does not yet solve working in terminal as `loadkeys' does not
work in terminal.

That is good. Now I can make the program to recognize if it is
console, virtual terminal or X and make it work in console accordingly
in the same way as how it works in X.

Re: Make Super key work in console

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> (global-set-key
>>>  [super-key ?\l]
>>>  (lambda ()
>>>    (interactive)
>>>    (message "Manny's skills are uncanny"))
>>
>> add one )
>> 
>>>  (global-set-key [super-key ?\t] 'tetris)
>> 
>> (global-set-key [super-key t] #'tetris)
>
> Thank you.

np :)

> That one works well, thank you. Now there is workaround for
> Super key to work in console.

Well, it depends what you mean with the Super key but sure it
should give you a bunch of more shortcuts to play with.

> That does not yet solve working in terminal as `loadkeys'
> does not work in terminal.

'terminal' here denotes 'X terminal emulator, e.g. xterm'

"Does not work", well, in a way it does indeed not, because it
isn't an X program :)

> That is good. Now I can make the program to recognize if it
> is console, virtual terminal or X and make it work in
> console accordingly in the same way as how it works in X.

But hold it, X and xterm and all the terminal emulators for
X that's big business compared to the by-design almost (?)
under-featured console. So google what you want for X, either
you will find it really professionally or just forget about it
for all intents and purposes - virtually!

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2021-02-12 15:55]:
> On 12.02.2021 07:42, Robert Thorpe wrote:
> 
> > I agree with Jean Louis on that too.  I think C-z C-z is not good
> > enough.  Every other terminal application uses C-z by itself, it's a
> > convention.  It's been that way for decades.  If you write a terminal
> > application and do nothing special then C-z will suspend it.  That's
> > because it sends SIGTSTP.
> 
> Could we someday stop considering Emacs a "terminal application"? Yes, it
> has a version that works in the terminal, but it's limited in features
> compared to the graphical one.

Millions of users use computers and maintain systems on remote VPSes
and dedicated servers. Vultru, Gandi, Digitalocean, Servetheworld.net
and many other providers offer such systems. They are managed
remotely.

Remote computers are accessed by using terminal emulators. While
remote X program can run, that is not common to do over slower
Internet networks. I can easily run graphical Emacs from a remote
computer in local area network but cannot do the same from various VPS
providers, and why should I as such dedicated servers and VPSes are
meant to run servers and not X Window environments.

Those editors useful for system administration within GNU/Linux and
BSD derivative operating systems must always run on console or
through terminal emulators.

I cannot see any significant limitations of features. 

> 'C-x C-z', a binding which has existed for a long time, is not too hard to
> type.

Maybe it did exist, I have never used C-x C-z for shell job control as
shell job control is not perceived in Emacs in the first place, rather
in the description of various shells.

Korn shell job control uses Ctrl-Z:
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/osmanagement/korn_shell_job_ctrl.html

Bash job control uses Ctrl-Z:
https://www.gnu.org/software/bash/manual/html_node/Job-Control-Basics.html

zsh job control uses Ctrl-Z:
https://gist.github.com/CMCDragonkai/6084a504b6a7fee270670fc8f5887eb4

There is POSIX standard on job control:
https://en.wikipedia.org/wiki/Job_control_(Unix)#Commands

"A job running in the foreground can be stopped by typing the suspend
character (Ctrl-Z). This sends the "terminal stop" signal (SIGTSTP) to
the process group. By default, SIGTSTP causes processes receiving it
to stop, and control is returned to the shell. However, a process can
register a signal handler for or ignore SIGTSTP. A process can also be
paused with the "stop" signal (SIGSTOP), which cannot be caught or
ignored. "

So Emacs could decide to ignore the shell job control and become
incompatible to shell users' expectations that Control-Z should work
when invoked from shell. The command is expected from shell, not from
Emacs. Emacs either complies, like it does not, or developers could
decide not to comply to those expectations.

That would be detrimental.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 12.02.2021 22:26, Jean Louis wrote:
> So Emacs could decide to ignore the shell job control and become
> incompatible to shell users' expectations that Control-Z should work
> when invoked from shell.

We do have bindings are are similar to the shell's, but not exact 
copies, like 'C-c C-d' or 'C-c C-c' in comint.

You find them once, and then use them, no problem.

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2021-02-13 00:09]:
> On 12.02.2021 22:26, Jean Louis wrote:
> > So Emacs could decide to ignore the shell job control and become
> > incompatible to shell users' expectations that Control-Z should work
> > when invoked from shell.
> 
> We do have bindings are are similar to the shell's, but not exact copies,
> like 'C-c C-d' or 'C-c C-c' in comint.

Maybe you speak of other thing not related to job control.

Control-Z in shell should suspend jobs no matter what job is
doing. That expectation comes from shell, not Emacs, Emacs keybindings
are not relevant for shell job control.

Like C-c C-d or C-c C-c that maybe does something in Emacs mode is not
related to shell outside of Emacs, it does nothing in other modes. So
is not related to shell, as the shell we speak here is the outside
shell from where Emacs is invoked. Not the M-x shell.

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 13.02.2021 09:59, Jean Louis wrote:
> Maybe you speak of other thing not related to job control.

Yes, I'm talking about other shell-inspired bindings, creating an analogy.

Re: not good proposal: "C-z <letter>" reserved for users

[Eli Zaretskii]

> Date: Fri, 12 Feb 2021 23:26:26 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Gregory Heytings <gregory@heytings.org>,
>  Robert Thorpe <rt@robertthorpeconsulting.com>, help-gnu-emacs@gnu.org
> 
> So Emacs could decide to ignore the shell job control

C-z in Emacs doesn't invoke job control, it invokes an Emacs command
that _emulates_ job control by sending the SIGTSTP signal to the Emacs
process (if the underlying platform supports suspending; otherwise it
invokes a subsidiary shell).  The "real" job control is disabled when
you enter Emacs, by virtue of the keyboard input setup Emacs does at
startup.

So please don't assume C-z is some shell job control magic; it isn't.
This is Emacs emulating that magic, because we decided long ago to do
that.  Arguing that Emacs does it because the underlying shell does it
is therefore counter-productive.

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-02-13 10:13]:
> > Date: Fri, 12 Feb 2021 23:26:26 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Gregory Heytings <gregory@heytings.org>,
> >  Robert Thorpe <rt@robertthorpeconsulting.com>, help-gnu-emacs@gnu.org
> > 
> > So Emacs could decide to ignore the shell job control
> 
> C-z in Emacs doesn't invoke job control, it invokes an Emacs command
> that _emulates_ job control by sending the SIGTSTP signal to the Emacs
> process (if the underlying platform supports suspending;

That is how I understood it that it is. Emacs basically helps the
shell users and complies more or less to it by providing SIGTSTP
signal. Yesterday I was reading that programs need not follow that
pattern, so program like Emacs decides if to provide SIGTSTP on
Control-Z or not.

For the shell user that is technicality and not important. Shell user
need to stop the job because either something is happening that need
some handling or some other job need to be invoked in the mean time,
or information verified. Emacs occupies all screen, when suspended
user is back into the outside shell and can handle things and come
back, or decide to unsuspend Emacs hours or days later.

> otherwise it invokes a subsidiary shell).  The "real" job control is
> disabled when you enter Emacs, by virtue of the keyboard input setup
> Emacs does at startup.

You have explained now technical thing, and that is interesting. I was
thinking that shell has authority and one can suspend any
program. That is how I expected shell to work for decades. I don't
remember cases where it did not work.

Now I wonder if all programs are first disabling shell control and
then deciding to emulate it. For example Midnight Commander or other
editors, I can suspend with Control-Z without problem. I wonder if it
is the program doing it or the shell itself.

> So please don't assume C-z is some shell job control magic; it isn't.
> This is Emacs emulating that magic, because we decided long ago to do
> that.  Arguing that Emacs does it because the underlying shell does it
> is therefore counter-productive.

Maybe there is some misunderstanding. Your explanation is definitely
clarifying for others, for me I understood it already though without
those technicalities.

Development at the time of deciding to provide Suspend on Control-Z
probably did follow the assumption that that is what shell users
expect to happen when they click Control-Z so for that key Emacs
complies to job control willingly, not submissively.

I hope we are fine.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Eli Zaretskii]

> Date: Sat, 13 Feb 2021 11:37:56 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: dgutov@yandex.ru, rt@robertthorpeconsulting.com,
>   gregory@heytings.org, help-gnu-emacs@gnu.org
> 
> > So please don't assume C-z is some shell job control magic; it isn't.
> > This is Emacs emulating that magic, because we decided long ago to do
> > that.  Arguing that Emacs does it because the underlying shell does it
> > is therefore counter-productive.
> 
> Maybe there is some misunderstanding. Your explanation is definitely
> clarifying for others, for me I understood it already though without
> those technicalities.

Your understanding didn't show in the text you were writing.  That is
why I replied to the large number of messages you devoted to the C-z
issue, which quite clearly said that C-z _is_ job control.  Showing
how the various shells handle that didn't help.  People on this list
are not necessarily fluent in the Emacs internals, so telling them
that C-z is just a key binding in Emacs, like any other one, looked
important to me.

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-02-13 12:09]:
> > Date: Sat, 13 Feb 2021 11:37:56 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: dgutov@yandex.ru, rt@robertthorpeconsulting.com,
> >   gregory@heytings.org, help-gnu-emacs@gnu.org
> > 
> > > So please don't assume C-z is some shell job control magic; it isn't.
> > > This is Emacs emulating that magic, because we decided long ago to do
> > > that.  Arguing that Emacs does it because the underlying shell does it
> > > is therefore counter-productive.
> > 
> > Maybe there is some misunderstanding. Your explanation is definitely
> > clarifying for others, for me I understood it already though without
> > those technicalities.
> 
> Your understanding didn't show in the text you were writing.  That is
> why I replied to the large number of messages you devoted to the C-z
> issue, which quite clearly said that C-z _is_ job control.  Showing
> how the various shells handle that didn't help.  People on this list
> are not necessarily fluent in the Emacs internals, so telling them
> that C-z is just a key binding in Emacs, like any other one, looked
> important to me.

Sure, that is right. I also understood it is decision of a program
recently. I was thinking shell has more power over invoked programs,
but it does not.

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 12.02.2021 07:42, Robert Thorpe wrote:
>
>> I agree with Jean Louis on that too.  I think C-z C-z is not good
>> enough.  Every other terminal application uses C-z by itself, it's a
>> convention.  It's been that way for decades.  If you write a terminal
>> application and do nothing special then C-z will suspend it.  That's
>> because it sends SIGTSTP.
>
> Could we someday stop considering Emacs a "terminal application"? Yes, 
> it has a version that works in the terminal, but it's limited in 
> features compared to the graphical one.

I only use graphical Emacs myself.  But I think that terminal Emacs is
still important, as Jean Louis says.

Lots of people who have started using Emacs recently came to from the
terminal.  You can see that on Emacs Reddit.

I'm not a web developer myself, but it seems to have happened like
this....  Web people put their stuff on test servers to try it out.
Sometimes they prepare it or compile it on their own PC then copy it to
the test server.  To save time some people started developing on the
test server using things like VNC or Microsoft Remote Desktop.  That
removes the copying over step.  Other would do tweaks to the code on the
server by direct editing on the server, but keep the main code on their
own PC.

All that worked until web services became popular.  Then the test server
was no longer a nearby, dedicated server accessed by a fast network.  It
was an instance on a virtualized machine far away.  That has made using
graphical tools to access these test servers less practical.  So, some
people have moved to terminal programs instead.  A terminal editor like
Emacs is very useful for making quick changes on a remote virtual
machine.  That seems to have brought Emacs to a new audience.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 13.02.2021 10:17, Robert Thorpe wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 12.02.2021 07:42, Robert Thorpe wrote:
>>
>>> I agree with Jean Louis on that too.  I think C-z C-z is not good
>>> enough.  Every other terminal application uses C-z by itself, it's a
>>> convention.  It's been that way for decades.  If you write a terminal
>>> application and do nothing special then C-z will suspend it.  That's
>>> because it sends SIGTSTP.
>>
>> Could we someday stop considering Emacs a "terminal application"? Yes,
>> it has a version that works in the terminal, but it's limited in
>> features compared to the graphical one.
> 
> I only use graphical Emacs myself.  But I think that terminal Emacs is
> still important, as Jean Louis says.
> 
> Lots of people who have started using Emacs recently came to from the
> terminal.  You can see that on Emacs Reddit.

Those are often former Vim developers, too. So it might not be due to 
the nature of their work, but largely due to their previous habits.

It's not a 100% conclusion of the survey we have referred to previously,
but its results state that ~30% of all users are in the terminal, ~30% 
of all users are using a Vim key bindings emulation, and ~30% of all 
users have been using Vim as their primary editor previously. They can't 
be all the same users, but it's an interesting coincidence.

> I'm not a web developer myself, but it seems to have happened like
> this....  Web people put their stuff on test servers to try it out.
> Sometimes they prepare it or compile it on their own PC then copy it to
> the test server.  To save time some people started developing on the
> test server using things like VNC or Microsoft Remote Desktop.  That
> removes the copying over step.  Other would do tweaks to the code on the
> server by direct editing on the server, but keep the main code on their
> own PC.

I'm a web developer by trade, so maybe I could clarify a few things.

First, we don't usually edit the code on the server unless it's 
something really urgent and critical (and even then, we try not to). We 
edit the code on the local machine, check it into version control, and 
then perform the deployment using something like Ansible. We do 
automated testing, and for manual testing we usually do automated 
deployments as well, only on different servers.

Editing code on the remote machine can happen, but it's usually 
something minor you don't need a full-featured editor for. And you don't 
have your personal Emacs config on that server anyway, so why even 
bother. Tramp is available as an alternative, too.

Second, I'm the only one who uses Emacs in our department. Vim, VS Code 
and IntelliJ are the popular options. And I can see the reasons. So if 
you see me clamoring for change here, that's why.

> All that worked until web services became popular.  Then the test server
> was no longer a nearby, dedicated server accessed by a fast network.  It
> was an instance on a virtualized machine far away.  That has made using
> graphical tools to access these test servers less practical.  So, some
> people have moved to terminal programs instead.  A terminal editor like
> Emacs is very useful for making quick changes on a remote virtual
> machine.  That seems to have brought Emacs to a new audience.

I do see people working in the terminal, but that's either someone using 
Vim (which has no popular graphical UI still), or running tests, or 
doing some exploration in a REPL. Some edit code inside Docker, though.

But I rarely ever see someone using the 'C-z' -> 'fg' pair, in fact, I 
struggle to remember anyone do that (except some of the sysadmins, I 
guess). I am aware of that capability myself, but never take advantage 
of it, opting instead for an additional split in the terminal emulator. 
Overall, it seems to be like it had been more important in the earlier 
age when operating systems had no real multitasking. Now we have 
terminal splits, and tmux, and so on.

If it actually matters to the decision makers, I could make a poll or 
two (maybe on Reddit, maybe on my workplace) about whether people know 
about this feature, and whether they use it regularly.

That's not to say I would vote for removing it in favor of just freeing 
a key binding. If we do it, it should be for something important, like 
making Emacs's key bindings more mainstream. Even if it's just C-z and C-Z.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Dmitry Gutov wrote:

>> I only use graphical Emacs myself. But I think that
>> terminal Emacs is still important, as Jean Louis says.
>> Lots of people who have started using Emacs recently came
>> to from the terminal. You can see that on Emacs Reddit.
>
> Those are often former Vim developers, too. So it might not
> be due to the nature of their work, but largely due to their
> previous habits.
>
> It's not a 100% conclusion of the survey we have referred to
> previously, but its results state that ~30% of all users are
> in the terminal, ~30% of all users are using a Vim key
> bindings emulation, and ~30% of all users have been using
> Vim as their primary editor previously. They can't be all
> the same users, but it's an interesting coincidence.

They write

  Also if you have some cool analysis and want to share it,
  please let us know and we can link to you. [1]

(I'll CC this reply to them)

I'm just one person (d'oh) who didn't even knew of the survey,
and TBH I was totally chocked by that digit (7344 responses) -
I mean, here were are some 20 bunch of guys talking about the
same damn stuff year in year out - and suddenly 7344 people
have responded to a, to me unheard of survey! - but anyway ...
in my case it isn't correct.

I did CS at the university and in the intro course they
mentioned Emacs. I used nano at the time, in a manner of
speaking. I tried Emacs in the Linux VT because I was, and
still is I guess, a keyboard/typing fan(atic), and setting the
keys there was much simper, I thought, i.e. in the VTs, than
in xterm, my then-and-now X terminal emulator of choice.

So I never did Vim. I understand "visudo" but apart from
understanding it it doesn't make sense to me based on previous
or any experience whatsoever actually.

> But I rarely ever see someone using the 'C-z' -> 'fg' pair,
> in fact, I struggle to remember anyone do that (except some
> of the sysadmins, I guess). I am aware of that capability
> myself, but never take advantage of it, opting instead for
> an additional split in the terminal emulator. Overall, it
> seems to be like it had been more important in the earlier
> age when operating systems had no real multitasking. Now we
> have terminal splits, and tmux, and so on.

Indeed, I think the terminal multiplexers and in particular
tmux has removed the need for C-z/fg. It is better as well,
since you don't let go of Emacs.

> I'm a web developer by trade, so maybe I could clarify
> a few things.

OT: I've read that

  You should include the following <meta> viewport element in
  all your web pages: <meta name="viewport"
  content="width=device-width, initial-scale=1.0"> [2]

but after spending tons of time on the HTML5/CSS on a couple
of blog articles [3] using that meta tag screws everything up,
even (especially) on my smartphone, a Samsung Galaxy Note 2
LTE GT-N7105 16GB. Without it, I think it looks good.

I'd LOVE to get feedback from a pro, if you can find the time
(working with this professionally, I get it you might not
enjoy doing it on your spare time as well. but maybe it won't
take many minutes. I hope not :))

[1] https://emacssurvey.org/2020/

[2] https://www.w3schools.com/css/css_rwd_viewport.asp

[3] https://dataswamp.org/~incal/blog/climbing-gear/climbing-gear.html
    https://dataswamp.org/~incal/blog/box-10/marco-antonio-barrera.html
    https://dataswamp.org/~incal/blog/box-10/list.html
    https://dataswamp.org/~incal/blog/tree-house/tree-house.html
    - all using the same CSS file:
    https://dataswamp.org/~incal/blog/global.css

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 04:54]:
> I'm just one person (d'oh) who didn't even knew of the survey,
> and TBH I was totally chocked by that digit (7344 responses) -
> I mean, here were are some 20 bunch of guys talking about the
> same damn stuff year in year out - and suddenly 7344 people
> have responded to a, to me unheard of survey! - but anyway ...
> in my case it isn't correct.

It was advertised mostly on Reddit page. That page does not even
advertise official Emacs website. Sadly. I consider it biased and
specific to specific groups of users, mostly on Reddit.

> So I never did Vim. I understand "visudo" but apart from
> understanding it it doesn't make sense to me based on previous
> or any experience whatsoever actually.

I have no idea which editors I have used before, if I remember well
some Norton Commander related or similar. With GNU/Linux in 1999 I
have learned about various editors equally, so Emacs and vi or nvi at
that time. For most of shorter tasks today I may choose nvi or vi,
like BSD version. Sometimes vim; for dwelling, doing life and
programming I use Emacs. I wish I could or maybe I should, expand all
the database related functions to use the program `bemenu' instead of
Emacs narrowing completion frameworks or tabulated-list-mode whenever
I am using some other editor. That way I could program Emacs Lisp to
be invoked from other editors to help me in editing and processing
actions related to people equally. https://github.com/Cloudef/bemenu

> Indeed, I think the terminal multiplexers and in particular
> tmux has removed the need for C-z/fg. It is better as well,
> since you don't let go of Emacs.

Concurrent running of a processes in the same time is not related to
suspending a job or unsuspending it, or running the job in the
background of single shell.

tmux, screen or nohup are not related to shell job control. They run
processes and continue running them even if user logs off. That
feature is not related to job control of a process, but it can be
helpful to keep the suspended job in a shell even if user logs off.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> It was advertised mostly on Reddit page. That page does not
> even advertise official Emacs website. Sadly. I consider it
> biased and specific to specific groups of users, mostly
> on Reddit.

Well, bring 7344 people to the table, I don't care how biased
it is... [1]

>> Indeed, I think the terminal multiplexers and in particular
>> tmux has removed the need for C-z/fg. It is better as well,
>> since you don't let go of Emacs.
>
> Concurrent running of a processes in the same time is not
> related to suspending a job or unsuspending it, or running
> the job in the background of single shell.
>
> tmux, screen or nohup are not related to shell job control.
> They run processes and continue running them even if user
> logs off. That feature is not related to job control of
> a process, but it can be helpful to keep the suspended job
> in a shell even if user logs off.

Of course a terminal multiplexer (read tmux) it is not the
same as job control. It is better, that's why it has
superseded the C-z/fg practice.

To experience one immediate advantage - literally immediate -
compare opening a new tmux pane to doing C-z. With tmux, you
still have interactive control over Emacs, or whatever other
of a dozen or so applications and interfaces you might have
open, visible at the same time, with tmux panes all over
a huge monitor. Including, if you wish, a dedicated pane, just
to do job control! Compare this to suspending Emacs and then
'fg' it back and forth.

You also mention the 'persistent IRC' stunt that can be done
with tmux:

  tmux attach [-t X]
  tmux kill-session -t X
  tmux list-sessions
  tmux new -s X-s 'tmux set remain-on-exit on; X'

and, I'm sure, the tmux expert can think of many more.

There is even a book on tmux:

@book{tmux,
  author     = {Brian P Hogan},
  isbn       = {978-1-93435-696-8},
  publisher  = {Brian P Hogan},
  title      = {tmux: Productive Mouse-Free Development},
  year       = {2012}
}

Also, you seem to say this is such a fundamental practice,
however with zsh, it isn't even enabled by default. (IME
people seem to use bash, zsh, and - the OpenBSD people - ksh
(which is actually rksh, for legal reasons). FTR it _is_
enabled by default on bash and ksh.)

So it isn't even enabled by default on one of the most
commonly used shells.

tmux should be many magnitudes more powerful for several
reasons, in this aspect and others. Use it and get into the
game :)

[1] https://emacssurvey.org/2020/

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 11:34]:
> > tmux, screen or nohup are not related to shell job control.
> > They run processes and continue running them even if user
> > logs off. That feature is not related to job control of
> > a process, but it can be helpful to keep the suspended job
> > in a shell even if user logs off.
> 
> Of course a terminal multiplexer (read tmux) it is not the
> same as job control. It is better, that's why it has
> superseded the C-z/fg practice.

Does it do job control?

From screen manual:

,----
| 	suspend
| 
| 	Suspend screen.   The windows  are in the  `detached' state,
| 	while  screen is suspended. This feature relies on the shell
| 	being able to do job control.
`----

It maybe cooperates with job control, relies on it, but `screen' does
not do job control.

Of course you may compare chicken and apples, sure, it is freedom, but
chicken will never grow on the tree.

> To experience one immediate advantage - literally immediate -
> compare opening a new tmux pane to doing C-z. With tmux, you
> still have interactive control over Emacs, or whatever other
> of a dozen or so applications and interfaces you might have
> open, visible at the same time, with tmux panes all over
> a huge monitor. Including, if you wish, a dedicated pane, just
> to do job control! Compare this to suspending Emacs and then
> 'fg' it back and forth.

So you prefer to compare processes running in parallel to compare to
processes that are stopped. It is fine with me, but that neither
tmux/screen/nohup suspend the process, they run them.

Running is not equal to suspend.

Stopping is not equal to running.

Running ≠ Stopping

Control-Z in shell does Stopping of a process. It does not let process
run in background. `bg' command could run it in the background, but
that is not same as stopping.

Tmux and screen let processes run in background, they are not tools
designed to stop the process, they let job control to the shell.

> You also mention the 'persistent IRC' stunt that can be done
> with tmux:
> 
>   tmux attach [-t X]
>   tmux kill-session -t X
>   tmux list-sessions
>   tmux new -s X-s 'tmux set remain-on-exit on; X'

I use screen and surely I know what it means in tmux, I have long
running, days and weeks running processes on remote servers that I may
control by using screen. But again, making things persistent is not
equal to making things stop. It is not comparable.

> Also, you seem to say this is such a fundamental practice,
> however with zsh, it isn't even enabled by default. (IME
> people seem to use bash, zsh, and - the OpenBSD people - ksh
> (which is actually rksh, for legal reasons). FTR it _is_
> enabled by default on bash and ksh.)
> 
> So it isn't even enabled by default on one of the most
> commonly used shells.
> 
> tmux should be many magnitudes more powerful for several
> reasons, in this aspect and others. Use it and get into the
> game :)

Sure, you win.

We can also join to it, that X Window system is more powerful to shell
job control, even the water boiler is more powerful to it. But is not
relevant.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> Of course a terminal multiplexer (read tmux) it is not the
>> same as job control. It is better, that's why it has
>> superseded the C-z/fg practice.
>
> Does it do job control?

If "it" equals tmux and "do job control" equals invoke the
shell built-in commands fg and bg - then yes.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 16:36]:
> Jean Louis wrote:
> 
> >> Of course a terminal multiplexer (read tmux) it is not the
> >> same as job control. It is better, that's why it has
> >> superseded the C-z/fg practice.
> >
> > Does it do job control?
> 
> If "it" equals tmux and "do job control" equals invoke the
> shell built-in commands fg and bg - then yes.

OK so how do you suspend a process in Tmux and unsuspend it?

What is the equivalent to SIGTSTP or SIGSTOP and what is the
equivalent to SIGCONT?

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>>> Of course a terminal multiplexer (read tmux) it is not
>>>> the same as job control. It is better, that's why it has
>>>> superseded the C-z/fg practice.
>>>
>>> Does it do job control?
>> 
>> If "it" equals tmux and "do job control" equals invoke the
>> shell built-in commands fg and bg - then yes.
>
> OK so how do you suspend a process in Tmux and unsuspend it?
>
> What is the equivalent to SIGTSTP or SIGSTOP and what is the
> equivalent to SIGCONT?

"equivalent"?

$ kill -TSTP PID

All signals:

$ kill -l

HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE
ALRM TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ
VTALRM PROF WINCH POLL PWR SYS

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 18:33]:
> Jean Louis wrote:
> 
> >>>> Of course a terminal multiplexer (read tmux) it is not
> >>>> the same as job control. It is better, that's why it has
> >>>> superseded the C-z/fg practice.
> >>>
> >>> Does it do job control?
> >> 
> >> If "it" equals tmux and "do job control" equals invoke the
> >> shell built-in commands fg and bg - then yes.
> >
> > OK so how do you suspend a process in Tmux and unsuspend it?
> >
> > What is the equivalent to SIGTSTP or SIGSTOP and what is the
> > equivalent to SIGCONT?

In tmux. You said that tmux does job control, so how does it do?

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> In tmux. You said that tmux does job control, so how does
> it do?

I say a lot, and most of it is actually really thoughtworthy.
That just makes me curious, what were my words exactly?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Jean Louis <bugs@gnu.support> writes:

> * Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 16:36]:
>> Jean Louis wrote:
>> 
>> >> Of course a terminal multiplexer (read tmux) it is not the
>> >> same as job control. It is better, that's why it has
>> >> superseded the C-z/fg practice.
>> >
>> > Does it do job control?
>> 
>> If "it" equals tmux and "do job control" equals invoke the
>> shell built-in commands fg and bg - then yes.
>
> OK so how do you suspend a process in Tmux and unsuspend it?
>
> What is the equivalent to SIGTSTP or SIGSTOP and what is the
> equivalent to SIGCONT?

Emmanuel, I agree with Jean Louis about this.  A tool that can't stop
and restart jobs does not provide all the facilities of shell job
control.  Tmux and GNU Screen are not full replacements for job control.
Having a job in another tab is not the same as stopping it. Job control
is very useful in some cases and I expect you'll start using it once
you've learned about it.  For jobs that consume lots of CPU time those
commands are very useful.  As are the associated utilities such as kill,
top, nice and renice.

I suspect that your zsh is capable of job control.  I expect one of two
things have happened.  Either (1) you have accidentally disabled it in your
zsh config.  Or, (2) it's because you have launched zsh in such a way
that it thinks that it's a non-interactive shell.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Robert Thorpe wrote:

> Emmanuel, I agree with Jean Louis about this. A tool that
> can't stop and restart jobs does not provide all the
> facilities of shell job control. Tmux and GNU Screen are not
> full replacements for job control.

Roobert, first, what's the definition of a job? Is it
a process or what it is, technically speaking?

Second, what is it you want to do with it, that cannot be done
from the shell, but it _can_ be done with "shell job control"?

> Having a job in another tab is not the same as stopping it.

I guess not :)

> Job control is very useful in some cases and I expect you'll
> start using it once you've learned about it. For jobs that
> consume lots of CPU time those commands are very useful.

Again, what commands are we talking about and what do they do?

> As are the associated utilities such as kill, top, nice
> and renice.

kill, top, nice and renice deal with processes and they can be
- what am I saying - they ARE - used from the shell. So just
fire up a new pane in tmux and use them all you want, happens
every day.

> I suspect that your zsh is capable of job control. I expect
> one of two things have happened. Either (1) you have
> accidentally disabled it in your zsh config.

I just put 'return' as the first line of ~/.zshrc, then
starting with \zsh and doing fg and it still says

  fg: no job control in this shell.

> Or, (2) it's because you have launched zsh in such a way
> that it thinks that it's a non-interactive shell.

Well, I don't launch zsh, it happens automatically when
a Linux VT, Emacs shell mode, or X terminal emulator
is started.

This function [1] tells if zsh is interactive. And you better
believe it is.

interactive-zsh () {
    [[ $- == *i* ]] && echo 'you better believe it' || echo 'not so'
}

[1] https://unix.stackexchange.com/a/26782

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[tomas]

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

On Mon, Feb 15, 2021 at 07:15:42PM +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:

[...]

> Roobert, first, what's the definition of a job? Is it
> a process or what it is, technically speaking?

Job, in the current sense (UNIX) is more a process group.

The fine details are, as usual, well described in the
Wikipedia page [1].

Cheers

[1] https://en.wikipedia.org/wiki/Job_control_%28Unix%29

 - t

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

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

> interactive-zsh () {
>     [[ $- == *i* ]] && echo 'you better believe it' || echo 'not so'
> }

Perhaps better:

interactive-zsh () {
    [[ -o interactive ]] && echo "it's better" || echo "not so"
}

--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Stefan Möding]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> I just put 'return' as the first line of ~/.zshrc, then
> starting with \zsh and doing fg and it still says

>   fg: no job control in this shell.

Also try setting the monitor option:

% fg
fg: no job control in this shell.

% set -m
% fg
fg: no current job

It should be the default in interactive shells though...

-- 
Stefan

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Möding wrote:

>> I just put 'return' as the first line of ~/.zshrc, then
>> starting with \zsh and doing fg and it still says
>
>>   fg: no job control in this shell.
>
> Also try setting the monitor option:
>
> % fg
> fg: no job control in this shell.
>
> % set -m
> % fg
> fg: no current job

Yes, It works.

You can disable it with 'set +m' or 'setopt nomonitor'.

> It should be the default in interactive shells though...

Maybe it is a configuration issue, there are lots of places
you can do that and then forget about it...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-15 21:19]:
> Robert Thorpe wrote:
> 
> > Emmanuel, I agree with Jean Louis about this. A tool that
> > can't stop and restart jobs does not provide all the
> > facilities of shell job control. Tmux and GNU Screen are not
> > full replacements for job control.
> 
> Roobert, first, what's the definition of a job? Is it
> a process or what it is, technically speaking?

Read the Job Control Basics in Bash manual.

I do not see that GNU Screen and Tmux are any replacement for job control. They
just give to user possibility to run multiple shells or other programs in the
same time so that programs do not get interrupted if user does something else. 

That is not related to job control. It does not relate to suspending a job, as
terminal multiplexers do not suspend or stop the job temporarily, they run the
processes. Inside of them one can use job control, but that is not feature of
those programs screen and tmux, it is feature of shell.

> Second, what is it you want to do with it, that cannot be done
> from the shell, but it _can_ be done with "shell job control"?
> 
> > Having a job in another tab is not the same as stopping it.
> 
> I guess not :)

That is what you can do with job control. You can stop the shell. And
regardless in which environment one is, like within screen or tmux, console,
terminal, even Emacs, one can suspend process in shell. Screen or tmux are not
about suspending a process or stopping a process.

I have asked if that exists, I do not know for tmux, but in screen there is no
such thing.

Just read the Bash manual on job control.

> kill, top, nice and renice deal with processes and they can be
> - what am I saying - they ARE - used from the shell. So just
> fire up a new pane in tmux and use them all you want, happens
> every day.

Today by emergency I have used Control-Z, but let me remember why. I think I
was searching which program could be doing some nasty staff, was it Emacs or
other program. Yesterday me and you we were playing with this and I have put
emacs as my login shell. Then I found there are multiple invokations of Emacs,
I could not believe it. Something like "emacs -c zgrep --version | head -1" was
invoked so many times, and I did not know what is happening. Emacs frames were
appearing one after the other. During that work, I was greping in Emacs sources
and trying to find a solution, so I could suspend grep in background with
Control-Z inside of shell (not inside of Emacs, as X interface was not usable
any more) and I could grep maybe other sources or do $ git log, as I was
thinking it could be possible Emacs bug or something, so I was first greping,
then thinking let me review git log. 

Processes have been spawned several every second. In 2-3 seconds I would get 40
emacs processes. X became unusable, I had to switch to console. It looked like
denial of service attack. All what it did is that some program, some process
tried to invoke the login shell and my login shell was "emacs" and login shell
wanted to get version number of zgrep. Instead of shell, emacs was spawned that
does not have option "-c".

When system is under load there is no time to spawn tmux or screen. It is
emergency, I went to console, there is panic level, I was greping and awking
processes and killing bunch of them which have "zgrep" and "emacs" in command
line in order to be able to find some references what is doing it.

kill, top, nice, etc, they are all good and fine especially when you have time
and you need not urgently stop a process.

When process is already running in the shell, you have Control-Z.

Imagine you log by SSH into remote server and you start maintaining a database,
process may take a lot of resources and you do not know what is happening. User
cannot predict that something like that is to happen to first invoke screen or
tmux to be able to switch easier from one terminal to other.

In your considerations you also assume that every user has installation rights,
but that is not so, there are much more shell users who do not have
installation rights. To have screen/tmux they would need to ask their
administrator to install it, but Control-Z works instantly. 

Just because you as user use Emacs personally and individually without other
users on your computer, does not mean that Emacs is for single user computers.
Neither Emacs nor other GNU/Linux and UNIX-like software. It is meant for multi
user computers. My family use multi user computers. Each family member have
their user space. They can use software that is installed, but cannot install
themselves, at least not globally. Local installations are possible, but is
difficult.

Universities and various institutions do not give root rights to every user.
They may not have screen/tmux. 

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> It does not relate to suspending a job, as terminal
> multiplexers do not suspend or stop the job temporarily,
> they run the processes. Inside of them one can use job
> control [...]

You can, but often you don't have to, because there is no need
to suspend and start processes back and forth just to get
access to the shell. Instead you just open a new tmux pane and
do whatever you intend to do, there.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-17 01:10]:
> Jean Louis wrote:
> 
> > It does not relate to suspending a job, as terminal
> > multiplexers do not suspend or stop the job temporarily,
> > they run the processes. Inside of them one can use job
> > control [...]
> 
> You can, but often you don't have to, because there is no need
> to suspend and start processes back and forth just to get
> access to the shell. Instead you just open a new tmux pane and
> do whatever you intend to do, there.

To get access to shell is maybe purpose for some people, I do not
know. I will use that to suspend one job while doing some other
job. As I said, I do not myself really consider one editor instance as
something as "running job" it is more like "pending or ready" process.

My side I have things that process over one day, two days. Sometimes
it is sending emails. If I leave it running it is continous process,
sends emails and reports with a single dot "." -- then screen becomes
full of dots........... but then sometimes Internet stops working as I
use mobile Internet. That is where emails go into the queue, but even
if they go into Courier mail queue, the queue may be itself having
some number of expiry days and all emails sent become rejected by my
own physical computer serving my in my premise. Of course people use
remote servers for that, but because I do not consider them reliable,
rather unsafe, I keep databases safe on my off-line computers and just
relay to remote servers.

Jobs of that kind that run all the time need suspension, not switch to
other screen. By switching to other shell, screen, tmux, one does not
suspend the job, and does not suspend the activity. By killing it with
proper signal the activity may be stopped. True. But that can be done
in emergency and only under conditions when person does have access to
different resource and especially enough time. When something goes
wrong there is no time, you need Control-Z.

Who did not learn using job control, does not need it. Who did learn
it, uses it. I am using it frequently. Sometimes it is the only way
out of some program. Public shell servers can be useful for processing
of data, why not, I will use some processing on remote servers that
are not mine as if there is no secret information.

In other words, there are numerous situations where one to
stop/suspend process, and be able to continue the process, this is
totally orthogonal to switching between processes or supervising what
running processes do as that is what screen/tmux do.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> It does not relate to suspending a job, as terminal
>>> multiplexers do not suspend or stop the job temporarily,
>>> they run the processes. Inside of them one can use job
>>> control [...]
>> 
>> You can, but often you don't have to, because there is no
>> need to suspend and start processes back and forth just to
>> get access to the shell. Instead you just open a new tmux
>> pane and do whatever you intend to do, there.
>
> To get access to shell is maybe purpose for some people,
> I do not know. I will use that to suspend one job while
> doing some other job

Why?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Second, what is it you want to do with it, that cannot be done
> from the shell, but it _can_ be done with "shell job control"?

...

> kill, top, nice and renice deal with processes and they can be
> - what am I saying - they ARE - used from the shell. So just
> fire up a new pane in tmux and use them all you want, happens
> every day.

I never said that shell job control is the only way to achieve these
objectives.

But, it is a very quick way of doing it.  Opening another tmux tab then
running something like kill or top is much more long-winded.  It takes
dozens of keypresses rather than just one.

Like I said, try using shell job control and I'm sure you'll like it.
It's especially useful for the kind of process that tend to take over
your entire computer and make it slow.

I very much doubt that Debian have given you a version of Zsh without
job-control.  I expect it's disabled by a configuration somewhere.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Robert Thorpe wrote:

> I never said that shell job control is the only way to
> achieve these objectives.
>
> But, it is a very quick way of doing it. Opening another
> tmux tab then running something like kill or top is much
> more long-winded. It takes dozens of keypresses rather than
> just one.

Well, if I would really rely on this, I think I'd have
a dedicated tmux pane or set of panes with some interactive
software and all the processes shown and grouped in an
organized way.

But the point is, if you have tmux you don't need to suspend
your editor in order to do a routine task. You can just bring
forward an empty tmux pane anytime and do whatever task
there instead.

The very few times one has to kill processes manually sending
signals the shell tools seem more than enough capable and also
fast enough to do this.

Like I said, if I ever needed something better and faster, and
I don't know where that'd be? - but anyway then I'd look for
something even bigger, rather than much smaller.

- Sir, we have a problem! The shell tools aren't fast enough!
- Son, suspend the text editor!
- Sir yes sir!

?

> I very much doubt that Debian have given you a version of
> Zsh without job-control. I expect it's disabled by
> a configuration somewhere.

Yes, I take that back. It is enabled by default.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Robert Thorpe wrote:
>
>> I never said that shell job control is the only way to
>> achieve these objectives.
>>
>> But, it is a very quick way of doing it. Opening another
>> tmux tab then running something like kill or top is much
>> more long-winded. It takes dozens of keypresses rather than
>> just one.
>
> Well, if I would really rely on this, I think I'd have
> a dedicated tmux pane or set of panes with some interactive
> software and all the processes shown and grouped in an
> organized way.
>
> But the point is, if you have tmux you don't need to suspend
> your editor in order to do a routine task. You can just bring
> forward an empty tmux pane anytime and do whatever task
> there instead.
>
> The very few times one has to kill processes manually sending
> signals the shell tools seem more than enough capable and also
> fast enough to do this.
>
> Like I said, if I ever needed something better and faster, and
> I don't know where that'd be? - but anyway then I'd look for
> something even bigger, rather than much smaller.
>
> - Sir, we have a problem! The shell tools aren't fast enough!
> - Son, suspend the text editor!
> - Sir yes sir!

I don't really want to talk about this much more, since it's not that
relevant to Emacs.  Still....

Some problems can be solved by one big tool.  Other problems are better
solved by several tools.  In my view process control is one of the
latter.  Yes, things like top are very useful, but so are simpler things
like shell job control commands.

It's not a matter of particularly wanting to stop the Emacs job.  Though
I certainly stop it from time-to-time.  It's more that once you have job
control and you get into the habit of using it then you expect every
program to obey Control-z.

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-18 02:24]:
> But the point is, if you have tmux you don't need to suspend
> your editor in order to do a routine task.

This statement comes because of your personalized use of the
editor. Millions of users use it in same way and there may be hundreds
of thousands or thousands only using it in somewhat different way then
you would ever think.

I use Emacs sometimes to accept CGI information.

Often I use it to process media information for days, that is where
suspending makes sense, as it releases CPU, hard disk, it lessens
heating of a computer, maybe it allows for a picture to be mogrified
before the process continues to run.

> You can just bring forward an empty tmux pane anytime and do
> whatever task there instead.

You are so right, but that is supervision of various processes, not
suspending of a process.

Sometimes I do use click and pray methods where I am unsure of the
outcome and I invoke program to see if it does what I mean it does,
sometimes it does not, that is where suspending is first.

In Emacs Ctrl-g is first used, but if Ctrl-g does not work, Ctrl-z may
work. It is true that Ctrl-g rarely does not work, but last few months
of experience tells me that it did not work as expected on multiple
occasions, such as those when memory was taken by Emacs extensively,
this still happens sometimes, sometimes when emails were sent in the
queue, maybe because of various invokations of outside processes.

> The very few times one has to kill processes manually sending
> signals the shell tools seem more than enough capable and also
> fast enough to do this.

That is your perception and I agree it is most of time like that, as
you do not have any heavy processing. Other people may have processing
that takes resources, that makes it not responsive.

> - Sir, we have a problem! The shell tools aren't fast enough!
> - Son, suspend the text editor!
> - Sir yes sir!

hahahahhah

But sure, I understand that joke, only that editor is not just editor,
it has capabilities of looping and processing so much more than just
visible text. I see now that development version included
--without-modules, so I just think that new version includes modules
by default unlike how it was before. One important module I use is
PostgreSQL which is connection to the database. No other editor that I
know has possibility to connect to the database. Majority of editors
is not even extensible. Emacs Lisp is a true programming language, so
almost any kind of processing is available with it. My editor is not
editor, it processes things without my supervision, it may run in
background for days doing tasks and being not-responsive to me, and I
may suspend it during my day time.

Not that shell tools are not fast enough, in fact, Emacs can be used
as shell tool and in batch mode it does same what Guile, MIT Scheme,
SBLC or CLISP or other Lisp similar or other shell scripts do.

I have 4080 pages in my website revision system, what if all of them
in Org mode that has to be exported to HTML? Emacs is not quite fast,
but it is currently the only one that can convert the Org mode to
HTML. HTML has to be saved. So the WRS (website revision system) is
running in background either by using CLISP as Common Lisp or by using
Emacs Lisp, and is processing pages, and invoking externala Emacs Lisp
script to process Org to HTML, Org is then saved with its HTML
template on the hard disk, and later synchronized with webserver.

Before I had 30000 pages, what if all of them are in Org mode, then I
would have need much more processing power. But most of them I write
in markdown and use discount markdown version which is the fastest
one, I know it because I have tested all of the markdown versions and
discount was fastest, followed by peg markdown. I know that because I
have been processing thousands of web pages and expanding them into
HTML for Internet marketing.

Editor is not just editor.

#!/usr/local/bin/emacs --script

;;;; Good idea from https://joelmccracken.github.io/entries/reading-writing-data-in-emacs-batch-via-stdin-stdout/

(defun org-stdin-to-html-full ()
  "Reads org text body from STDIN and export full HTML"
  (let ((org-document-content "")
	this-read)
    (while (setq this-read (ignore-errors
                             (read-from-minibuffer "")))
      (setq org-document-content (concat org-document-content this-read "\n")))

    (with-temp-buffer
      (org-mode)
      (insert org-document-content)
      (org-html-export-as-html)
      (princ (buffer-string)))))


(defun org-stdin-to-html-body-only ()
  "Reads org text body from STDIN and export full only body HTML"
  (let ((org-document-content "")
	this-read)
    (while (setq this-read (ignore-errors
                             (read-from-minibuffer "")))
      (setq org-document-content (concat org-document-content this-read "\n")))

    (with-temp-buffer
      (org-mode)
      (insert org-document-content)
      (org-html-export-as-html nil nil nil t)
      (princ (buffer-string)))))

(org-stdin-to-html-body-only)

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> You can just bring forward an empty tmux pane anytime and
>> do whatever task there instead.
>
> You are so right, but that is supervision of various
> processes, not suspending of a process.

You can for example suspend a process like this:

  $ kill -STOP PID

>> But the point is, if you have tmux you don't need to
>> suspend your editor in order to do a routine task.
>
> This statement comes because of your personalized use of
> the editor.

That's true! If you do some other thing, what I describe
won't happen.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-20 22:23]:
> Jean Louis wrote:
> 
> >> You can just bring forward an empty tmux pane anytime and
> >> do whatever task there instead.
> >
> > You are so right, but that is supervision of various
> > processes, not suspending of a process.
> 
> You can for example suspend a process like this:
> 
>   $ kill -STOP PID

Sure I know that, since last 20 years. We have to look at those
proposals globally, not personally. Objectively not subjectively.

It is great that some shell providers offer tmux/screen like:
https://blinkenshell.org/wiki/Start

Yet that may not be the case for many other users.

But mentioning tmux/screen is not relevant to suspending a process,
like I have repeated several times. It is not good misleading users
who read this mailing list to think that tmux/screen replaces
something like suspending or continuing of a process.

In Windoze systems, one will invoke process manager or task manager, I
am not sure how it is called. If I remember well that would be with
right mouse click on taskbar or Ctrl-Alt-Del but I am not sure as
Windoze is changing over time. And that will work if there are no
extensive CPU processes, as otherwise quicker suspend is not
possible. So I have no idea for Windoze

For GNU/Linux and BSD derivatives, console and terminal emulators are
extensively used, there are millions of BSD-derivate types of servers
that do not run X, and many will have users who do not have access to
root powers to install some software. However, screen/tmux do not
replace job control, as they offer as main service the continuation of
software being run even when user logs off. Processes in tmux/screen
still run, I know that, as I will often download heavy torrents by
using screen.

To be able to `kill -STOP PID' one has to have access to second
terminal, or double shell or tmux/screen, but the time necessary to
invoke those extra commands may be too long as in that time the
program may already damage data, user may lose data, disk may be
filled completely, files could be deleted by mistake and so
on. Control-Z is used in emergency. Sometimes it may be used to switch
from task to task, but that is just one case use, there are many
different cases uses. 

In Emacs mailing lists people often forget that that Emacs and other
software runs on multiuser computers. Universities, organizations,
various computer providers, website providers, may provide shell
access but not all types of software. Sometimes is impossible to
install everything as user as what you can install as root. Not every
user is using self-owned computer. Not every programming language is
installable. System administrators may disable execution of programs
on user partititions, so user could maybe download executable or
compile it, but never run it or execute it.

Now you say you can do kill -STOP PID, but of course I know, that is
however something you do when you have access to command line. As if
you do have access to command line in that case there is probably no
need to quickly suspend a process by using Control-Z and probably
there is no emergency situation where suspending a process is
necessary. You may go slow by typing many letters, of course, after
first searching for the process PID.

Not every user can install tmux, screen, you name it. Not every user
has Internet access to be able to install it. We have to look at
proposals globally, planetary, not only for those users in developing
countries. Is not objecitve to say that that everybody has Internet
access and that every user can even pay for Internet access.

As a side note to think about: Majority of stationaries with computers
in developing countries in East Africa are NOT connected to
Internet. That means it is harder to find stationary where I can tell
them "please download https://www.example.com/1.pdf" as their
computers are not connected to Internet.

Universities and libraries may have GNU/Linux installed but without
access to installation of software, without access to administrator,
sometimes without an administrator at all.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> But mentioning tmux/screen is not relevant to suspending
> a process, like I have repeated several times. It is not
> good misleading users who read this mailing list to think
> that tmux/screen replaces something like suspending or
> continuing of a process.

With tmux, you can do almost everything you can do with your
computer, including suspending a process. More than that, if
you use tmux, you don't have to suspend and resume processes
as you maybe may choose to do if you for some reason choose to
operate your text editor and programming environment in
a single window with no possibility to open an new shell pane
or go to another window.

> as in that time the program may already damage data, user
> may lose data, disk may be filled completely, files could be
> deleted [...]

Luckily there is a solution solution to these problems:
Control-Z

> In Emacs mailing lists people often forget that that Emacs
> and other software runs on multiuser computers.
> Universities, organizations, various computer providers,
> website providers, may provide shell access but not all
> types of software. Sometimes is impossible to install
> everything as user as what you can install as root

Indeed, for the tmux solution to work - and actually tmux in
general - tmux has to be installed.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 04:54]:
> OT: I've read that
> 
>   You should include the following <meta> viewport element in
>   all your web pages: <meta name="viewport"
>   content="width=device-width, initial-scale=1.0"> [2]
> 
> but after spending tons of time on the HTML5/CSS on a couple
> of blog articles [3] using that meta tag screws everything up,
> even (especially) on my smartphone, a Samsung Galaxy Note 2
> LTE GT-N7105 16GB. Without it, I think it looks good.

I am using this for years and fastest templates there are, and it is
visible and readable on every device.

<meta name="viewport" content="width=device-width, initial-scale=1">

from http://freeliquidtemplates.com/ and it is fastest, Page Speed of
100% easily reachable if you know how to prepare images, CSS and
Javascript well (which I do not use). We sell for hundreds of
thousands of dollars by using simplest and fastest page templates.

What exactly is going wrong with it?

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> <meta name="viewport" content="width=device-width, initial-scale=1">
>
> [...]
> 
> What exactly is going wrong with it?

I wonder!

Without it:

  https://dataswamp.org/~incal/blog/tree-house/tree-house.html

With viewport:

  https://dataswamp.org/~incal/blog/tree-house/tree-house-view.html

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 11:51]:
> Jean Louis wrote:
> 
> > <meta name="viewport" content="width=device-width, initial-scale=1">
> >
> > [...]
> > 
> > What exactly is going wrong with it?
> 
> I wonder!
> 
> Without it:
> 
>   https://dataswamp.org/~incal/blog/tree-house/tree-house.html

This version above is not showing well on Lineage OS mobile phone, it
shows as desktop version under the GNU IceCat browser, letters are not
readable and not accommodating the space well.

> With viewport:
> 
>   https://dataswamp.org/~incal/blog/tree-house/tree-house-view.html

Works well on GNU IceCat browser on LineageOS mobile phone, letters
are readable and all is well.

On desktop the browser Iceweasel-uxp from Hyperbola GNU/Linux-libre
shows both versions just fine without problems.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> Without it:
>> 
>>   https://dataswamp.org/~incal/blog/tree-house/tree-house.html
>
> This version above is not showing well on Lineage OS mobile
> phone, it shows as desktop version under the GNU IceCat
> browser, letters are not readable and not accommodating the
> space well.

This version looks, if I may, very good on my smartphone [1]
and in Emacs-w3m, tho then you don't get the winter theme or
the photos, but still, it is functional from
a reader's perspective.

It looks just as good if I rotate the phone.

>> With viewport:
>> 
>>   https://dataswamp.org/~incal/blog/tree-house/tree-house-view.html
>
> Works well on GNU IceCat browser on LineageOS mobile phone,
> letters are readable and all is well.

This looks so bad I'd consider it pla1n br0ken.

[1] Samsung Galaxy Note 2 LTE GT-N7105 16GB

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

handling viewport in HTML - was Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 11:51]:
> Jean Louis wrote:
> 
> > <meta name="viewport" content="width=device-width, initial-scale=1">
> >
> > [...]
> > 
> > What exactly is going wrong with it?

Still it does not answer the question what is wrong with it.

Which OS do you use and which browser?

What do you see wrong?

Make a screenshot.

Re: handling viewport in HTML - was Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> <meta name="viewport" content="width=device-width, initial-scale=1">
>> 
>> What exactly is going wrong with it?
>
> Still it does not answer the question what is wrong with it.

I have set up the CSS [1] to make it look good. Using that
tag, it looks bad, br0ken, even.

> Which OS do you use and which browser?

Android 4.4.2 with Firefox 68.11.0

> Make a screenshot.

No thanks, too ugly.

[1] https://dataswamp.org/~incal/blog/global.css

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: handling viewport in HTML - was Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

> I have set up the CSS [1] to make it look good. Using that
> tag, it looks bad, br0ken, even.

So remove the CSS and try it out.

Re: handling viewport in HTML - was Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> I have set up the CSS [1] to make it look good. Using that
>> tag, it looks bad, br0ken, even.
>
> So remove the CSS and try it out.

I'm redoing everything as we speak, what a joke. Now it looks
half bad both places instead of one fantastic and one
horrible. Ha.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: handling viewport in HTML - was Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

> I'm redoing everything as we speak, what a joke. Now it
> looks half bad both places instead of one fantastic and one
> horrible. Ha.

OK, I think I did it. It looks really good on a smartphone and
OK in a computer browser.
  
That was frustrating!

Method:

1. insert the meta tag

2. pick onee way of viewing the page(s)

3. optimize the CSS for that way

4. never look at the page in any other way

https://dataswamp.org/~incal/blog/climbing-gear/climbing-gear.html
https://dataswamp.org/~incal/blog/box-10/marco-antonio-barrera.html
https://dataswamp.org/~incal/blog/box-10/list.html
https://dataswamp.org/~incal/blog/tree-house/tree-house.html

thrice-accursed CSS:
  https://dataswamp.org/~incal/blog/global.css

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: handling viewport in HTML - was Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 14.02.2021 18:26, Emanuel Berg via Users list for the GNU Emacs text 
editor wrote:
> 4. never look at the page in any other way

But you look at both from a smartphone and a browser, right? And it's okay?

You might also look into 
https://developer.mozilla.org/en-US/docs/Web/CSS/@media, to be able to 
tailor the display to the device it's viewed from.

Re: handling viewport in HTML - was Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Dmitry Gutov wrote:

>> 4. never look at the page in any other way
>
> But you look at both from a smartphone and a browser, right?

It was amazing/horrible (smartphone/computer), now it is
really-good/OK, I'd say.

> And it's okay?

Good enough for government work :)

Or have a look! Do you agree? What can be improved?

  https://dataswamp.org/~incal/blog/tree-house/tree-house.html

Previous posts, all using the same CSS.

  https://dataswamp.org/~incal/blog/climbing-gear/climbing-gear.html
  https://dataswamp.org/~incal/blog/box-10/marco-antonio-barrera.html
  https://dataswamp.org/~incal/blog/box-10/list.html

The CSS:

  https://dataswamp.org/~incal/blog/global.css

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 14.02.2021 03:54, Emanuel Berg via Users list for the GNU Emacs text 
editor wrote:
> OT: I've read that
> 
>    You should include the following <meta> viewport element in
>    all your web pages: <meta name="viewport"
>    content="width=device-width, initial-scale=1.0"> [2]
> 
> but after spending tons of time on the HTML5/CSS on a couple
> of blog articles [3] using that meta tag screws everything up,
> even (especially) on my smartphone, a Samsung Galaxy Note 2
> LTE GT-N7105 16GB. Without it, I think it looks good.
> 
> I'd LOVE to get feedback from a pro, if you can find the time
> (working with this professionally, I get it you might not
> enjoy doing it on your spare time as well. but maybe it won't
> take many minutes. I hope not :))

Sorry, I have been doing backend only for a number of years now, so I'm 
not exactly a pro at this.

In any case, the answer is unlikely to be just "use this one tag in a 
different way".

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Dmitry Gutov wrote:

> so I'm not exactly a pro at this

Heh, we-ell, I don't know about that, but no problem, of
course :)

> In any case, the answer is unlikely to be just "use this one
> tag in a different way".

Makes sense. Because as it stands, it ruins everything :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2021-02-14 03:36]:
> > Lots of people who have started using Emacs recently came to from the
> > terminal.  You can see that on Emacs Reddit.
> 
> Those are often former Vim developers, too. So it might not be due to the
> nature of their work, but largely due to their previous habits.

People still think Vim is best programming editor as referenced on
this page:
https://www.slant.co/topics/12/~best-programming-text-editors

Side notes:

I wish I could liberate Emacs Lisp and be able to use it anywhere, in
any application. Espanso does at least global expansion of
abbreviations and functional abbreviations.

Espanso detects when you type a keyword and replaces it while you're typing.
https://espanso.org/

If I could use globally Emacs Lisp in similar fashion like Espanso,
then I would be using Vim or other editors. Espanso also proves it
could be possible to globalize and listen on any text in X
environment. If I type :people I get it expanded to 220005 in any
editor under X (works with Vim in many terminals but not all) as it
uses database to query the number of the people.

> It's not a 100% conclusion of the survey we have referred to previously,
> but its results state that ~30% of all users are in the terminal, ~30% of
> all users are using a Vim key bindings emulation, and ~30% of all users have
> been using Vim as their primary editor previously. They can't be all the
> same users, but it's an interesting coincidence.

If there are 200 million Ubuntu users, 13 million Emacs users by using
Popularity Contest survey data, then 30% of those would be few
millions of Emacs users using it in terminal. 

> First, we don't usually edit the code on the server unless it's something
> really urgent and critical (and even then, we try not to).

Safe and good principle of work.

> I do see people working in the terminal, but that's either someone using Vim
> (which has no popular graphical UI still), or running tests, or doing some
> exploration in a REPL. Some edit code inside Docker, though.

I am not working with anybody in the team and still see so many
reasons of using terminal and editor inside of terminal. How many
self-hosted software is today offered and available, it is more than
ever. People who need to install such software mostly need to use
terminal. Awesome list is here:
https://github.com/awesome-selfhosted/awesome-selfhosted

Almost any of such software needs terminal. Almost any Fediverse
installation needs terminal, configurations, and launches or launch
setups in terminal. Adding new users to remote servers may need a
terminal, handling spam filtering, setting up emails, DNS, DMARC, SPF,
may need terminal, setting up VPNs, downloading Python packages to
server, updating servers with new packages and version of the system
needs a terminal. And so on, and so on. Today is terminal used more
than ever. Today there are more Vim users then ever before. There are
more Emacs users then before. There is more free software and cool
software then before, people are installing it. Github is telling
there are 50 million developers. A lot of software is meant for remote
servers, remote databases, replication databases, CDNs, and so on and
so on. People use terminals more than ever before. New terminal
applications in various graphical environments are not developed
without reason.

Websites have to be configured usually through terminal. You are maybe
using web based website configuration but somebody had to install web
based configuration system through terminal or physically (or maybe
not with automated instances).

Recent applications I have been installing through terminal are
Nextcloud, Improved File Manager, advertising server, Gnusocial
Fediverse instance, Pleroma Fediverse instance, Courier mail server,
then I often use terminal to setup new website configurations with
Nginx web server.

Today we have more websites, more configurations and more terminal
users. Not less. We have more applications, and terminal user number
is raising, not becoming smaller.

IMF: https://github.com/misterunknown/ifm

> But I rarely ever see someone using the 'C-z' -> 'fg' pair, in fact, I
> struggle to remember anyone do that (except some of the sysadmins, I
> guess).

If you have not get clear picture of number of terminal users you
cannot possibly know somebody is using job control in their shells.

If you have not invoke programs that process large data sets it is
harder to understand. 220005 people need to be updated for their
number of interactions (their emails, SMS, calls, notes, tasks) and
that process involves harvesting their emails, counting it,
harvesting the database and counting. I wish it would be fast but it
is not. The process will take usually 2 days. I do it maybe once per
quarter. It blocks the system and computer has to be used. Suspending
a job is easier, then unsuspending it when I am not personally on
computer.

Sending emails to thousands of people may also need to be suspended
and unsuspended. People do that mostly on remote servers, that is why
those servers are dedicated. But I do not keep the database on the
remote server for safety, so I am sending it from office computer.

Depending of the mail queue involved and environmental circumstances,
things can go wrong. Power can be off due to outage in East Africa
where I am circumstantially located. Network provider may cencor some
of the IP addresses or there can be political voting during which
period Internet may completely censored depending of the nature of
specific dictator. Without knowing WHEN is Internet going to be
unsuspended one may need to suspend current jobs. If programming is
good, interrupting job could be better solution, but sometimes
suspending is better one.

Video processing may need days, weeks to finish. I have programmed it
by Emacs Lisp that invokes `ffmpeg' in such a way to process file by
file. Such instance of Emacs may run separately in console, or
terminal. I can then change my graphics environment without having
process interrupted in console. I can suspend the process in terminal
and have it waiting on separate workspace until I unsuspend it during
the night time or my absence from the office.

(defun video2webm-dired ()
  "Converts any video to webm"
  (interactive)
  (let* ((bitrate (read-number "Bitrate: " 300))
	 (videos (dired-get-marked-files))
	 (videos (mapcar 'video-mime-type-p videos))
	 (videos (seq-remove 'null videos))
	 (async-shell-command-buffer 'new-buffer)
	 (command (format "ffmpeg -y -i `?` -c:v libvpx-vp9 -b:v %sk -pass 1 -passlogfile `?` -speed 4 -c:a libopus -f webm /dev/null -async 1 -vsync passthrough && ffmpeg -y -i `?` -c:v libvpx-vp9 -b:v %sk -pass 2 -passlogfile `?` -speed 1 -c:a libopus \`?`.webm -async 1 -vsync passthrough && rm `?`-0.log;" bitrate bitrate)))
    (dired-do-async-shell-command command nil videos)))

I could as well use Common Lisp or other programming language, again I
would need suspend option as processing videos from mp4 to webm for
websites takes days or weeks depending of size of videos. Other people
delegate that job to YouTube, I don't and do processing on my
computer.

> I am aware of that capability myself, but never take advantage of it, opting
> instead for an additional split in the terminal emulator. Overall, it seems
> to be like it had been more important in the earlier age when operating
> systems had no real multitasking. Now we have terminal splits, and tmux, and
> so on.

Suspending a job is not same as concurrently running multiple
jobs. It requires more understanding.

Even if I use `screen' or `nohup' I may still like to SIGSTOP the
process. I can do it by using `kill' command or `top' or similar
process manager, but if process is running in the shell I may do it by
using Control-Z and invoking SIGTSTP signal. I resume it either with
`fg' in shell or by using `kill' SIGCONT or other process manager.

SIGTSTP is invoked by Control-Z and may be prevented by application
which I have recently learn that Emacs is basically emulating job
control. SIGSTOP cannot be prevented, so I can suspend even this frame
here I could easily SIGSTOP by using `htop' and SIGCONT to continue.

Majority of people have strong computers and will never reach their
maximum capacities as not everybody is doing parallel tasks, video
processing, database extensive calculations and queries, updates or
database indexing. Of course that this group of people will never
understand it.

`mu4e' is popular Emacs package and it offers indexing option that
invokes the outside process of `mu' command indexing the database of
emails. I have 465691 emails as they are related to customers, so it
is hard to just delete emails as even customer before 10 years may
inquire again and I lose money if I do not know who is that
person. Emails are kept to keep good relations with people and to be
able to follow up on the already established relation. Mailing list
emails I simply delete after reading or answering. Now I have to
invoke `mu index' and I will either do it inside of terminal, or on
console or inside of Emacs.

If I start doing it inside of Emacs, then Emacs becomes not
responsive. Doing it in separate process helps the free Emacs instance
to be usable. Extensive file system harvesting by `mu' tools for mail
indexing may slow down the computer and make it less usable even if it
is separate process. Suspending such jobs helps human to do the human
stuff. Unsuspending them at times of absence of a human is next
logical action.

Myself I use job suspending options in shell for reasons of data
safety, when something is going wrong, for reasons of switching
between two applications when I wish to actually suspend one and
invoke the other,and for reasons of computing extensive processes
where such need to be stopped until later time.

I wish I could be able to index my emails every day, but that is too
expensive, occupies the computer too much, so I don't do that, I do it
every few weeks. I wish I would be able to just invoke video
processing and that computer is free for me, but it is not. Sometimes
I delegate video processing to remote computers in same building. What
if power is soon to be off? Outages are sometimes announced by radio
and known to last for one day or longer. I need to suspend the
computer, not only the job, or battery may not last long, not all
computers have automated sleep mode and not every computer has the
UPS system.

> If it actually matters to the decision makers, I could make a poll or two
> (maybe on Reddit, maybe on my workplace) about whether people know about
> this feature, and whether they use it regularly.

I do believe firmly that not many users use it. But that is case for
the Bash and general computing. Emacs is on top of the Bash, Bash is
fundamental to Emacs and job control is more fundamental to Emacs.

If I do extensive computing in X Window system, then I can still
invoke graphical task manager and send SIGSTOP to stop Emacs, but if I
am in console, and process (Emacs) is already running, I have no other
option but to use Control-Z to suspend it and trust Emacs to do
exactly what I expect.

If it is not dangerous process that maybe causes loss of data, or not
computing extensive process, or not something urgent then I could log
in with SSH again and suspend it from `top', `htop' or similar.

The point is that Control-Z is used when there is emergency, not
without emergency. There is some demand for Control-Z, it will not be
used often. And it will definitely not be used by people who do not
know about Bash job control.

If you are making a poll, then make a poll among people who know what
is job control. You can choose any community for your polls, but that
will not make your survey authentic. If I ask chicks behind my house
they will say pee, pee, but I am sure they will answer negatively on
job control question, as they have never learned about Bash, and many
people who learned about Bash, Korn Shell, dash, zsh, did not learn
about job control. Ask those who KNOW about the job control if they
use it and when and how. That will be authentic information.

But that is normal considering that Bash and other shells are used
mostly by set of power users. There is bunch of other Bash related
features that are mostly not used by majority of users, that means
nothing. Function is important, it is part of POSIX standard and
number of users using it means not that function shall be abandoned or
forgotten.

Especially not so if you have not done research on job
control. Currently you are comparing SIGTSTP/SIGSTOP on process to
running it concurrently in Tmux or Screen, which shows you have
fundamental misunderstanding on what Control-Z actually
does.

Concurrent running of multiple processes is not equal to stopping a
process and being able to continue with it later.

If I suspend a job in bash, I may decide to run it in background, but
not automatically.

1. Control-Z suspends the job, it stops running.

2. fg brings it in foreground

3. bg allows it to run in background, shell is free for other commands
   in parallel

4. Invoking other jobs in meantime is possible without interrupting
   the suspended job to be continual, they can be continued later with
   fg or bg commands in shell

5. nohup, screen and tmux are not job control commands. They help you
   run programs without your direct supervision and without
   interrupting them when you log off. But is not related to job
   control.

See: (info "(bash) Job Control")

Additionally if you think that job control is useless, than start by
sending bug report to bash, dash, ksh and other shells, as that is
where job control is used, in the shell, Emacs being just one of
thousands of possible processes who respect the Control-Z. You could
as well make a proposal to change the POSIX standard.

That terminals are used, this query of newest questions on
Stackoverflow may tell:
https://stackoverflow.com/search?tab=newest&q=terminal

But I cannot make proper query to find only people who relate to
suspending a job:
https://stackoverflow.com/search?tab=newest&q=bash%20suspend

That some people have need for suspending:
https://stackoverflow.com/questions/65936832/how-to-suspend-and-resume-processes-from-a-python-script

Somebody needs to often kill process:
https://stackoverflow.com/questions/3510673/find-and-kill-a-process-in-one-line-using-bash-and-regex

People using SIGSTOP in debugging:
https://stackoverflow.com/search?tab=newest&q=SIGSTOP

People using SIGTSTP:
https://stackoverflow.com/search?tab=newest&q=SIGTSTP


Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> If there are 200 million Ubuntu users, 13 million Emacs
> users by using Popularity Contest survey data

Do you have references to these to? Please submit, I'll take
a look...

> I am not working with anybody in the team and still see so
> many reasons of using terminal and editor inside of
> terminal.

Well, let's not get carried away here. Depending on what you
do, the difference between GUI Emacs and a "TUI" Emacs can be
close to zero. Most often it is very small, I'd reckon.
Emacs is a TEXT editor, GUI or no GUI, doesn't change that.

> (defun video2webm-dired ()
>   "Converts any video to webm"
>   (interactive)
>   (let* ((bitrate (read-number "Bitrate: " 300))
> 	 (videos (dired-get-marked-files))
> 	 (videos (mapcar 'video-mime-type-p videos))
> 	 (videos (seq-remove 'null videos))
> 	 (async-shell-command-buffer 'new-buffer)
> 	 (command (format "ffmpeg -y -i `?` -c:v libvpx-vp9 -b:v %sk -pass 1 -passlogfile `?` -speed 4 -c:a libopus -f webm /dev/null -async 1 -vsync passthrough && ffmpeg -y -i `?` -c:v libvpx-vp9 -b:v %sk -pass 2 -passlogfile `?` -speed 1 -c:a libopus \`?`.webm -async 1 -vsync passthrough && rm `?`-0.log;" bitrate bitrate)))
>     (dired-do-async-shell-command command nil videos)))
>
> I could as well use Common Lisp or other programming
> language [...]

Typically one would use a shell script language for that, be
it bash, ksh or zsh. I have tons of video and other multimedia
stuff with zsh [1] But one also think of Python and ... by all
means, even Elisp, as you have just shown. With Lisp, one can
do everything and anything, it is the Pythagorean theorem of
computing...

[1] https://dataswamp.org/~incal/conf/.zsh/

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 11:44]:
> Well, let's not get carried away here. Depending on what you
> do, the difference between GUI Emacs and a "TUI" Emacs can be
> close to zero. Most often it is very small, I'd reckon.
> Emacs is a TEXT editor, GUI or no GUI, doesn't change that.

That is what I wish it to be. What is in focus in conversation is
using it on terminal and that is especially useful when accessing
remote applications.

> Typically one would use a shell script language for that, be
> it bash, ksh or zsh. I have tons of video and other multimedia
> stuff with zsh [1] But one also think of Python and ... by all
> means, even Elisp, as you have just shown. With Lisp, one can
> do everything and anything, it is the Pythagorean theorem of
> computing...

Yes. And process runs with small differences, nevertheless
days. Running it with Common Lisp or Emacs Lisp makes no much of
difference. Shell as language is not quite comfortable for PostgreSQL
database processing, may be good for video processing. One video may
be alone 1-2 days of processing length. When interrupted without
possibility to continue, one may lose one day and have to restart
it.

Maybe better way of doing such jobs is to enter them into the queue
and have process handle the queue.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Shell as language is not quite comfortable for PostgreSQL
> database processing, may be good for video processing.

Shell programming is good for everything that involves shell
commands and features, CLI tools, batch processing, and so on.
But other languages can do that as well, no doubt.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 16:27]:
> Jean Louis wrote:
> 
> > Shell as language is not quite comfortable for PostgreSQL
> > database processing, may be good for video processing.
> 
> Shell programming is good for everything that involves shell
> commands and features, CLI tools, batch processing, and so on.
> But other languages can do that as well, no doubt.

Well... it would be pain in the ass to use shell to handle and process
database entries, but I am sure it can be done by passing SQL to
`psql' and receiving information back.

Emacs Lisp has the dynamic module for that. CLISP has a module to
connect to PostgreSQL and MIT Scheme and various other languages.

Those modules make life easier.

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 14.02.2021 09:58, Jean Louis wrote:

>> It's not a 100% conclusion of the survey we have referred to previously,
>> but its results state that ~30% of all users are in the terminal, ~30% of
>> all users are using a Vim key bindings emulation, and ~30% of all users have
>> been using Vim as their primary editor previously. They can't be all the
>> same users, but it's an interesting coincidence.
> 
> If there are 200 million Ubuntu users, 13 million Emacs users by using
> Popularity Contest survey data, then 30% of those would be few
> millions of Emacs users using it in terminal.

Not all Ubuntu users are software developers. Decent math otherwise.

>> I do see people working in the terminal, but that's either someone using Vim
>> (which has no popular graphical UI still), or running tests, or doing some
>> exploration in a REPL. Some edit code inside Docker, though.
> 
> I am not working with anybody in the team and still see so many
> reasons of using terminal and editor inside of terminal. How many
> self-hosted software is today offered and available, it is more than
> ever. People who need to install such software mostly need to use
> terminal.

I'm not talking about the terminal in general and its usefulness, or 
about what people *can* do with it. Only about what they actually do 
with regards to the feature in question.

Because even though "suspend job" is handy to have in the toolset, if an 
average user only reaches for it twice a year, that command doesn't 
really need a key binding as prominent as 'C-z'.

In comparison, I hit 'undo' at least a dozen times per hour.

>> But I rarely ever see someone using the 'C-z' -> 'fg' pair, in fact, I
>> struggle to remember anyone do that (except some of the sysadmins, I
>> guess).
> 
> If you have not get clear picture of number of terminal users you
> cannot possibly know somebody is using job control in their shells.

You can do that by watching people work. And I do have a clear picture 
of the number of terminal users.

> If you have not invoke programs that process large data sets it is
> harder to understand. 220005 people need to be updated for their
> number of interactions (their emails, SMS, calls, notes, tasks) and
> that process involves harvesting their emails, counting it,
> harvesting the database and counting. I wish it would be fast but it
> is not. The process will take usually 2 days. I do it maybe once per
> quarter. It blocks the system and computer has to be used. Suspending
> a job is easier, then unsuspending it when I am not personally on
> computer.

Interesting. That sounds like the case closer to "non-multitasking" 
systems I was talking about.

Here, I can launch a resource-intensive process or two, and still use 
the computer myself.

> Sending emails to thousands of people may also need to be suspended
> and unsuspended. People do that mostly on remote servers, that is why
> those servers are dedicated. But I do not keep the database on the
> remote server for safety, so I am sending it from office computer.
> 
> Depending of the mail queue involved and environmental circumstances,
> things can go wrong. Power can be off due to outage in East Africa
> where I am circumstantially located. Network provider may cencor some
> of the IP addresses or there can be political voting during which
> period Internet may completely censored depending of the nature of
> specific dictator. Without knowing WHEN is Internet going to be
> unsuspended one may need to suspend current jobs. If programming is
> good, interrupting job could be better solution, but sometimes
> suspending is better one.

You might also want to look into giving that process a lower priority, 
so that it gives way to your interactive tasks when you're logged in.

> Video processing may need days, weeks to finish. I have programmed it
> by Emacs Lisp that invokes `ffmpeg' in such a way to process file by
> file. Such instance of Emacs may run separately in console, or
> terminal. I can then change my graphics environment without having
> process interrupted in console. I can suspend the process in terminal
> and have it waiting on separate workspace until I unsuspend it during
> the night time or my absence from the office.
> 
> (defun video2webm-dired ()
>    "Converts any video to webm"
>    (interactive)
>    (let* ((bitrate (read-number "Bitrate: " 300))
> 	 (videos (dired-get-marked-files))
> 	 (videos (mapcar 'video-mime-type-p videos))
> 	 (videos (seq-remove 'null videos))
> 	 (async-shell-command-buffer 'new-buffer)
> 	 (command (format "ffmpeg -y -i `?` -c:v libvpx-vp9 -b:v %sk -pass 1 -passlogfile `?` -speed 4 -c:a libopus -f webm /dev/null -async 1 -vsync passthrough && ffmpeg -y -i `?` -c:v libvpx-vp9 -b:v %sk -pass 2 -passlogfile `?` -speed 1 -c:a libopus \`?`.webm -async 1 -vsync passthrough && rm `?`-0.log;" bitrate bitrate)))
>      (dired-do-async-shell-command command nil videos)))
> 
> I could as well use Common Lisp or other programming language, again I
> would need suspend option as processing videos from mp4 to webm for
> websites takes days or weeks depending of size of videos. Other people
> delegate that job to YouTube, I don't and do processing on my
> computer.

That's neat. But if you only do that once or twice per month, perhaps 
the 'C-x C-z' binding could suffice?

>> I am aware of that capability myself, but never take advantage of it, opting
>> instead for an additional split in the terminal emulator. Overall, it seems
>> to be like it had been more important in the earlier age when operating
>> systems had no real multitasking. Now we have terminal splits, and tmux, and
>> so on.
> 
> Suspending a job is not same as concurrently running multiple
> jobs. It requires more understanding.

Right. But I was assuming that people reach similar goals with those two 
techniques. Perhaps not.

>> If it actually matters to the decision makers, I could make a poll or two
>> (maybe on Reddit, maybe on my workplace) about whether people know about
>> this feature, and whether they use it regularly.
> 
> I do believe firmly that not many users use it. But that is case for
> the Bash and general computing. Emacs is on top of the Bash, Bash is
> fundamental to Emacs and job control is more fundamental to Emacs.

Is it? I mean, Emacs itself has shell, eshell, and other features that 
sometimes duplicate Bash's functionality.

> If you are making a poll, then make a poll among people who know what
> is job control. You can choose any community for your polls, but that
> will not make your survey authentic. If I ask chicks behind my house
> they will say pee, pee, but I am sure they will answer negatively on
> job control question, as they have never learned about Bash, and many
> people who learned about Bash, Korn Shell, dash, zsh, did not learn
> about job control. Ask those who KNOW about the job control if they
> use it and when and how. That will be authentic information.

I won't be making the poll without the maintainers' request. That would 
be just a waste of time.

But if that happens, we should poll everybody. Because the question is 
not whether to remove the feature, but whether it should take up an 
important key sequence. And if people are using it very rarely, it 
shouldn't.

> If I suspend a job in bash, I may decide to run it in background, but
> not automatically.
> 
> 1. Control-Z suspends the job, it stops running.
> 
> 2. fg brings it in foreground
> 
> 3. bg allows it to run in background, shell is free for other commands
>     in parallel
> 
> 4. Invoking other jobs in meantime is possible without interrupting
>     the suspended job to be continual, they can be continued later with
>     fg or bg commands in shell
> 
> 5. nohup, screen and tmux are not job control commands. They help you
>     run programs without your direct supervision and without
>     interrupting them when you log off. But is not related to job
>     control.
> 
> See: (info "(bash) Job Control")

This is Bash's manual. No Emacs's.

> Additionally if you think that job control is useless, than start by
> sending bug report to bash, dash, ksh and other shells, as that is
> where job control is used, in the shell, Emacs being just one of
> thousands of possible processes who respect the Control-Z. You could
> as well make a proposal to change the POSIX standard.

I don't think it is useless.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Dmitry Gutov wrote:

> Because even though "suspend job" is handy to have in the
> toolset, if an average user only reaches for it twice a year,
> that command doesn't really need a key binding as prominent as
> 'C-z'.

Well, yes, but C-z isn't a good key. You have to move your
entire hand, and it is awkward (keys too close) at that.

> In comparison, I hit 'undo' at least a dozen times per hour.

I have `undo' M-0. Left thumb, right ring finger. Much better
IMO.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 15.02.2021 02:39, Emanuel Berg via Users list for the GNU Emacs text 
editor wrote:
>> Because even though "suspend job" is handy to have in the
>> toolset, if an average user only reaches for it twice a year,
>> that command doesn't really need a key binding as prominent as
>> 'C-z'.
> Well, yes, but C-z isn't a good key. You have to move your
> entire hand, and it is awkward (keys too close) at that.
> 
>> In comparison, I hit 'undo' at least a dozen times per hour.
> I have `undo' M-0. Left thumb, right ring finger. Much better
> IMO.

M-0 is not too bad, but I think we can agree that 99/100 new users will 
look for 'undo' on 'C-z'.

Who use C-x u or C-/ for undo? Who uses C-z for undo?

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2021-02-15 05:24]:
> On 15.02.2021 02:39, Emanuel Berg via Users list for the GNU Emacs text
> editor wrote:
> > > Because even though "suspend job" is handy to have in the
> > > toolset, if an average user only reaches for it twice a year,
> > > that command doesn't really need a key binding as prominent as
> > > 'C-z'.
> > Well, yes, but C-z isn't a good key. You have to move your
> > entire hand, and it is awkward (keys too close) at that.
> > 
> > > In comparison, I hit 'undo' at least a dozen times per hour.
> > I have `undo' M-0. Left thumb, right ring finger. Much better
> > IMO.
> 
> M-0 is not too bad, but I think we can agree that 99/100 new users will look
> for 'undo' on 'C-z'.

Personally I have never used C-z for undo in Emacs. I do use it in browser as that is the only option.

I have been using undo with C-x u for long time and still do so on many keyboards that are not this US type of a keyboard. On this US type I use C-/ 

Emacs was terminal application in first place, so at that time there was no Control-Z as undo I believe, it was meant probably for something else (guess what). 

More references for your research:
https://en.wikipedia.org/wiki/Substitute_character#Other_uses

Also take in consideration that Xerox is US company and they used QWERTY, as US company did not think of international planning. I do not agree that Control-Z is internationally good key for undo as sometimes it is close to left hand, sometimes it is in the middle of keyboard on QWERTZ layouts: https://en.wikipedia.org/wiki/QWERTZ

For you is easy to access Control-Z but when I am in Germany or simply use such layout, and I do, my mind switches and my Z is in the middle of keyboard. Not any more easy to access with one hand. Control-Z becomes little pain with left hand and is easier to access with both hands on QWERTZ keyboards.

Re: Who use C-x u or C-/ for undo? Who uses C-z for undo?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Also take in consideration that Xerox is US company and they
> used QWERTY, as US company did not think of
> international planning.

Despite this overlook on behalf of the US companies, they
nonetheless seem to have had a certain degree of international
success, even in the field of computers.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Who use C-x u or C-/ for undo? Who uses C-z for undo?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-15 21:00]:
> Jean Louis wrote:
> 
> > Also take in consideration that Xerox is US company and they
> > used QWERTY, as US company did not think of
> > international planning.
> 
> Despite this overlook on behalf of the US companies, they
> nonetheless seem to have had a certain degree of international
> success, even in the field of computers.

Alright, sure, but my statement was specific to Xerox and in relation to the
reference from Wikipedia. Not that I invented the statement or conclusion.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Dmitry Gutov wrote:

> M-0 is not too bad, but I think we can agree that 99/100 new
> users will look for 'undo' on 'C-z'.

But they will also look for ... I don't even remember any
more, what are the Windows keys for copy, paste, etc? Not our
keys for kill and yank anyway.

There is a mode to get those keys BTW. Not sure if it includes
C-z...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[tomas]

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

On Mon, Feb 15, 2021 at 06:56:25PM +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Dmitry Gutov wrote:
> 
> > M-0 is not too bad, but I think we can agree that 99/100 new
> > users will look for 'undo' on 'C-z'.
> 
> But they will also look for ... I don't even remember any
> more, what are the Windows keys for copy, paste, etc? Not our
> keys for kill and yank anyway.
> 
> There is a mode to get those keys BTW. Not sure if it includes
> C-z...

Yes, the mode is called "CUA bindings", it is documented, and yes,
C-z is bound to "undo" there. It seems we can make everyone happy.

Unless, that is, someone wants to force me to use C-z for undo,
because I'm happy with C-x u :-)

Cheers
 - t

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

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-15 03:41]:
> Dmitry Gutov wrote:
> 
> > Because even though "suspend job" is handy to have in the
> > toolset, if an average user only reaches for it twice a year,
> > that command doesn't really need a key binding as prominent as
> > 'C-z'.
> 
> Well, yes, but C-z isn't a good key. You have to move your
> entire hand, and it is awkward (keys too close) at that.

That is what you know on Swedish keyboard. Not everybody is
aware that Z key is often interchanged with Y. There are
QWERTY and QWERTZ keyboards.

Researching about keys requires effort.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> That is what you know on Swedish keyboard. Not everybody is
> aware that Z key is often interchanged with Y. There are
> QWERTY and QWERTZ keyboards.

Yet another shocking insight - brought to you by: Super-Jean

And I'm not using a Swedish keyboard, you %&$#@!

I use a Logitech G Pro Tenkeyless with the US layout, which is
more fitted for programmers.

I use the compose key for Swedish chars:

  https://dataswamp.org/~incal/conf/vt/remap.inc

Some cool keyboard effects BTW:

  https://dataswamp.org/~incal/conf/.zsh/led-kb
  https://dataswamp.org/~incal/kb/kb-full-group.conf
  https://dataswamp.org/~incal/kb/kb-bright-small.conf

And this goodie:

(defun scramble-string (str)
  "Randomize the characters of a string."
  (interactive "sscramble me: ")
  (let ((rand-str (seq-sort (lambda (_ __) (zerop (random 2))) str )))
    (if (called-interactively-p 'any)
        (message rand-str)
      rand-str) ))

(defun comic-book-insult ()
  (interactive)
  (insert (concat (scramble-string "@#$%&") "!")) )

https://dataswamp.org/~incal/emacs-init/sort-incal.el

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-15 21:38]:
> Jean Louis wrote:
> 
> > That is what you know on Swedish keyboard. Not everybody is
> > aware that Z key is often interchanged with Y. There are
> > QWERTY and QWERTZ keyboards.
> 
> Yet another shocking insight - brought to you by: Super-Jean
> 
> And I'm not using a Swedish keyboard, you %&$#@!
> 
> I use a Logitech G Pro Tenkeyless with the US layout, which is
> more fitted for programmers.

After some research I think not even Swedish keyboards have QWERTZ layout, so
that is why you did not react sooner yesterday. I was waiting for this reaction
btw.

> I use the compose key for Swedish chars:
> 
>   https://dataswamp.org/~incal/conf/vt/remap.inc

Of course.

I use several input methods for various languages, so anything works. Recently
I found how to make remapping in Vim, so that input methods work about the
same.

Thinking now I would like to invoke Emacs Lisp globally so that I can invoke it
from Vim and insert snippets or invoke Emacs functions from any editor.

espanso could lead there, I could write something like:

:sig

and it would spawn Emacs frame with list of signatures, after selection,
signature would just appear in any editor.

Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Because even though "suspend job" is handy to have in the toolset, if an 
> average user only reaches for it twice a year, that command doesn't 
> really need a key binding as prominent as 'C-z'.
>
> In comparison, I hit 'undo' at least a dozen times per hour.
>

I often hit C-z about a dozen times per hour!

BR,
Robert Thorpe

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2021-02-15 01:14]:
> On 14.02.2021 09:58, Jean Louis wrote:
> 
> > > It's not a 100% conclusion of the survey we have referred to previously,
> > > but its results state that ~30% of all users are in the terminal, ~30% of
> > > all users are using a Vim key bindings emulation, and ~30% of all users have
> > > been using Vim as their primary editor previously. They can't be all the
> > > same users, but it's an interesting coincidence.
> > 
> > If there are 200 million Ubuntu users, 13 million Emacs users by using
> > Popularity Contest survey data, then 30% of those would be few
> > millions of Emacs users using it in terminal.
> 
> Not all Ubuntu users are software developers. Decent math otherwise.

They are definitely not and I have not mentioned they are. Popularity
Contest is not for developers. Being developer is the only
characteristic for user to be Emacs user. Being ethusiastic user like
we are is not the only characteristic to be Emacs user. Popularity
Contest counts number of installations and, I just guess, asks users
if they use the package often.

> I'm not talking about the terminal in general and its usefulness, or about
> what people *can* do with it. Only about what they actually do with regards
> to the feature in question.

From online questions and answers such as Stackoverflow, by using
their search engine, you may get quite a good information what people
do with terminals. My personal opinion would be based on what people
as user of those features like terminal are talking on some
websites.

> Because even though "suspend job" is handy to have in the toolset, if an
> average user only reaches for it twice a year, that command doesn't really
> need a key binding as prominent as 'C-z'.
> 
> In comparison, I hit 'undo' at least a dozen times per hour.

I will not go into my circle of friends or even co-workers and
assume that if they don't use terminal functions that nobody use
them. Especially I will not be inclined to remove well known functions
because my close circle of friends or co-workers do not use them. They
have nothing to say about it.

For your awareness I have learned Control-Z since I have learned
basics of shell somewhere in 1999-2000 and I have used Control-Z in
terminal and in console many times during the last year.

I wish I would see more understanding from your side on what job
control is, but I have not get the impression you got it.

You seem to have understanding that key binding like Control-Z is for
enthusiastic users, those who may report on this mailing list, who
identify themselves as "Emacs users", and who would be average users.

My understanding is that Control-Z is for shell users, those who
invoke various running processes and who need to suspend the process
until later time, or maybe need to suspend it before deciding to kill
it, or need to suspend it due to lack of some computing resources, or
temporarily review of other actions in background before reverting
back to Emacs. There is always some urgency involved and suspending
Emacs as process may rather not be related to Emacs, rather to
environmnet.

It is not meant for average, beginner or advanced user of Emacs, it is
rather meant as compliance to shell user expectations. That is how I
see it. It is definitely not related to the status of the Emacs user.

Let us think of Emacs user as beginner, Vim user as beginner,
GNU/Linux beginner who is discovering terminal and Bash or other
shell, on BSD derivativs may be Korn shell or other shell, on Debian
it could be dash as system shell or Bash as user shell, any OS has
already some kind of shell. Such users are exploring system. At least
I know I was exploring systems in larval stage for about one year
during the night, during the day I was sleeping. Control-C and
Control-Z and Control-S are ways of stopping some executions of
various programs being invoked.

What if user is really Emacs beginner but shell user? Invoking Emacs
does not necessarily get him out of it. Control-Z suspends Emacs, user
can invoke maybe Internet access with lynx and find out how to exit
from Emacs with C-x C-c, or read info or other text files. Replace now
"Emacs" with any program there.

Use the Internet search to get more awareness as that is where
PowerShell users are crying for Control-Z implementation:
https://duckduckgo.com/?q=powershell+control-z+suspend&atb=v154-3am&ia=web

Realize that Control-Z comes as expectation from the shell job
control. It does not come from Emacs job control. When something goes
wrong or attention is required, Control-Z is one among intuitive keys
to stop the job in shell.

It invokes SIGTSTP or terminal stop signal.

I do not know any other program that I can invoke in the shell as
terminal program and not being able to suspend it. This is because
programs know that they should not fiddle with shell job control.

Job control gives users what? Control. Emacs shall not taking them
that control. Shell invocations are numerous, there are millions of
ways how is that used, it is not just an Emacs thing.

When I invoke `emacs -Q' from terminal I can stop GUI from terminal
with Control-Z -- that is I guess not a key that Emacs captures and
emulates, it is I guess function in shell. That is useful for
debugging. 

Recently I had my uptime 7 days, but before, I could never reach even
2-3 days as Emacs is hanging or doing some weird stuff with memory,
bug is well known. Control-Z in those situations could maybe help in
gaining access to computer.

Emacs is not just editor, it is programming language. Any programming
language shall be suspendable from shell.

When I invoke Emacs to update interactions of 220008 people, I do not
use that Emacs instance any more. It becomes unusable as it is
processing data. All I can see are dots, like ".........."
representing one person per dot being handled and process may last for
one day. Suspending such processes I do over GUI process manager or in
shell with Control-Z. I can remember before in time I have been using
Perl to process a lot of data in the same way, I would run it in shell
and sometimes suspend, or resume.

Because Emacs has Emacs Lisp as programming language, one shall give
users always power and control from outside to suspend whatever
process is running within shell.

Sometimes nothing in Emacs can help, like C-g numerous times may not
easily suspend the process execution. I have some SQL queries and
normally I require myself to enter at least 3 chars for the SQL
query search. But I have forgotten in some functions to verify for 3
chars, so even searpching for "a" becomes possible. That is where C-g
becomes almost impossible.

Control-Z is for critical shell and terminal handlings and users'
control over processes invoked in shell. 

> > > But I rarely ever see someone using the 'C-z' -> 'fg' pair, in fact, I
> > > struggle to remember anyone do that (except some of the sysadmins, I
> > > guess).
> > 
> > If you have not get clear picture of number of terminal users you
> > cannot possibly know somebody is using job control in their shells.
> 
> You can do that by watching people work. And I do have a clear picture of
> the number of terminal users.

You can watch people who do not know bash, those are not
representative people. I gave you good reference of those who need
Control-Z in PowerShell, they cry for it.

But we cannot take an example from those people who are not shell
users, and even if shell users, from those who do not know what is job
control.

Quote:

"There are basically three types of people in the world: those who
know little or nothing about bash job control, those who know enough
to believe that it's nothing that they would ever use, and those who
can just skim the rest of this post."

from:
https://www.linuxjournal.com/content/job-control-bash-feature-you-only-think-you-dont-need

If job control in shell would not be useful, there would no articles
about it. The quote applies well here in this discussion.

> > If you have not invoke programs that process large data sets it is
> > harder to understand. 220005 people need to be updated for their
> > number of interactions (their emails, SMS, calls, notes, tasks) and
> > that process involves harvesting their emails, counting it,
> > harvesting the database and counting. I wish it would be fast but it
> > is not. The process will take usually 2 days. I do it maybe once per
> > quarter. It blocks the system and computer has to be used. Suspending
> > a job is easier, then unsuspending it when I am not personally on
> > computer.
> 
> Interesting. That sounds like the case closer to "non-multitasking" systems
> I was talking about.
> 
> Here, I can launch a resource-intensive process or two, and still use the
> computer myself.

That is your adjustment or view point on what is resource
intensive. Emacs was and would still be hanging doing something with
hard disk and memory, it makes this T410 Thinkpad almost
halt. Sometimes the only way to liberate computer is to reset it
hard. That is for Emacs. You probably have better computer than this
one. And this is I guess i5 CPU, something with 4 GB of memory.

This is multi-tasking system, but there are processes that require lot
of resources, indexing databases, processing database information and
handling files. Editing alone is almost never a problem.

> You might also want to look into giving that process a lower priority, so
> that it gives way to your interactive tasks when you're logged in.

Thanks, yes, I do that. I index emails with `mu index' by giving it
lowest priority. It still pretty much consumes resources. I have been
using fast desktop computers, it was still using resources that impact
somewhat the work.

alias lazy='nice -n19 /usr/local/bin/mu index --lazy-check --maildir /home/data1/protected/Maildir/'

I guess that with `nice -n19' I am doing that. But I am not sure if
M-x mu4e and updating of the database would "nice" the process to
lower priority, Emacs because less usable during tha indexing time.

Look at this:

- invoke Emacs on remote machine
- run mu4e and update the mail database
- realize that now machine is not responsive (surprise!)
- realize that maybe websites and other servers are not serving people
- Control-Z to suspend the job releases process
- re-nice the process, either Emacs or indexing process (or other)
- bring Emacs back to foreground

Of course one could try using Emacs and M-x proced to do similar
re-nicing, or top, htop or similar, but Emacs would still be slowed
down, it could take longer until user becomes able to re-nice process
from within Emacs.

> > Video processing may need days, weeks to finish. I have programmed it
> > by Emacs Lisp that invokes `ffmpeg' in such a way to process file by
> > file. Such instance of Emacs may run separately in console, or
> > terminal. I can then change my graphics environment without having
> > process interrupted in console. I can suspend the process in terminal
> > and have it waiting on separate workspace until I unsuspend it during
> > the night time or my absence from the office.
> > 
> > (defun video2webm-dired ()
> >    "Converts any video to webm"
> >    (interactive)
> >    (let* ((bitrate (read-number "Bitrate: " 300))
> > 	 (videos (dired-get-marked-files))
> > 	 (videos (mapcar 'video-mime-type-p videos))
> > 	 (videos (seq-remove 'null videos))
> > 	 (async-shell-command-buffer 'new-buffer)
> > 	 (command (format "ffmpeg -y -i `?` -c:v libvpx-vp9 -b:v %sk -pass 1 -passlogfile `?` -speed 4 -c:a libopus -f webm /dev/null -async 1 -vsync passthrough && ffmpeg -y -i `?` -c:v libvpx-vp9 -b:v %sk -pass 2 -passlogfile `?` -speed 1 -c:a libopus \`?`.webm -async 1 -vsync passthrough && rm `?`-0.log;" bitrate bitrate)))
> >      (dired-do-async-shell-command command nil videos)))
> > 
> > I could as well use Common Lisp or other programming language, again I
> > would need suspend option as processing videos from mp4 to webm for
> > websites takes days or weeks depending of size of videos. Other people
> > delegate that job to YouTube, I don't and do processing on my
> > computer.
> 
> That's neat. But if you only do that once or twice per month, perhaps the
> 'C-x C-z' binding could suffice?

You lack the fundamental understanding from where Control-Z comes
from. It is not from Emacs, it is not for Emacs. In general Control-Z
does no function in Emacs, it suspends the job outside of Emacs. It
comes from shell user expectation, not necessary from average or Emacs
user expectation.

Control-Z in shell is used in emergency situations. It is not used by
plan neither is possible to predict situations where it becomes
useful.

Video processing is just one example. I may sometimes out of
dissatisfaction with local computer open up a powerful VPS and process
videos on that VPS.

Control-Z is not meant only for Emacs users primarily, it comes from
shell job control, it is meant for whoever and whatever
reasons. Beginners invoking Emacs, Vim or any other software may
liberate their shell with Control-Z.

Shell user invokes a command and get surprised, something is wrong,
maybe cannot exit Emacs. Control-Z may be one of choices. Control-C
could be other choice if it works. After Control-Z user may `kill %1'
the suspended job if it is the only one, or `kill %2' if it is the
second one.

If process cannot be suspended by the binding that is related to shell
(Control-Z) you are putting at stake users' data for capricious
reasons.

> > > I am aware of that capability myself, but never take advantage of it, opting
> > > instead for an additional split in the terminal emulator. Overall, it seems
> > > to be like it had been more important in the earlier age when operating
> > > systems had no real multitasking. Now we have terminal splits, and tmux, and
> > > so on.
> > 
> > Suspending a job is not same as concurrently running multiple
> > jobs. It requires more understanding.
> 
> Right. But I was assuming that people reach similar goals with those two
> techniques. Perhaps not.

- invoke terminal tetris
- suspend it
- put it in background, you can resume playing

- invoke tetris in tmux/screen
- log off, or do something else in other screen
- come back and your game is lost

Suspending a job is not losing a game.

Putting suspended job in background may allow it to lose the game.

Another example how user of nano editor was surprised that Control-Z
was not supported by nano editor:
https://teamtreehouse.com/community/using-ctrlz-to-suspend-nano-in-terminal-macintosh

Remove Control-Z from Emacs and you will get many such website pages
as people will search for it. It is not just "binding" in Emacs, it is
expectation outside of Emacs.

Some Reddit talk on suspending Emacs:
https://www.reddit.com/r/emacs/comments/2t2cej/best_way_to_use_emacs_in_the_terminal_ctrlz/

or people speaking here:
https://news.ycombinator.com/item?id=5920732

I cannot see the Reddit talk due to censorship in the country I am
located. No time for Tor and VPN now.

> > > If it actually matters to the decision makers, I could make a poll or two
> > > (maybe on Reddit, maybe on my workplace) about whether people know about
> > > this feature, and whether they use it regularly.
> > 
> > I do believe firmly that not many users use it. But that is case for
> > the Bash and general computing. Emacs is on top of the Bash, Bash is
> > fundamental to Emacs and job control is more fundamental to Emacs.
> 
> Is it? I mean, Emacs itself has shell, eshell, and other features that
> sometimes duplicate Bash's functionality.

Yes, sure it has.

Some shell will normally be used to run the operating system, but you
could, if you wish, use exclusively Emacs as your default shell. Just
use `chsh' and change it to Emacs, provided that /etc/shells is also
set. It is free world. In that case there will be no job control, as
there is no shell, and job control relates to shell job control. You
may spawn your X window straight from Emacs. Most probably you could
use it as PID 1 as well. There are many reasons why is that not best
way of using the system, but for personal use why not.

Then when user enters system by using SSH, instead of Bash, then Emacs
may be invoked, why not. Then when there is resource intensive
process, or possibly damaging process, it will not be suspendable by
Control-Z, then good luck.

> > If you are making a poll, then make a poll among people who know what
> > is job control. You can choose any community for your polls, but that
> > will not make your survey authentic. If I ask chicks behind my house
> > they will say pee, pee, but I am sure they will answer negatively on
> > job control question, as they have never learned about Bash, and many
> > people who learned about Bash, Korn Shell, dash, zsh, did not learn
> > about job control. Ask those who KNOW about the job control if they
> > use it and when and how. That will be authentic information.
> 
> I won't be making the poll without the maintainers' request. That would be
> just a waste of time.
> 
> But if that happens, we should poll everybody. Because the question is not
> whether to remove the feature, but whether it should take up an important
> key sequence. And if people are using it very rarely, it shouldn't.

That functionality is useful in rare situations. If use is rare it
does not mean it should be taken away from users.

This is because you come from different background and I come from
different background. I am terminal user since years, I do not intend
to ever "switch", of course that I know how to use Thunderbird, but
what I can do with `mutt' is impossible to do with Thunderbird. I have
tried it for years. For example, I cannot just press a key in
Thunderbird and see user's profile in Emacs (all previous emails, SMS,
notes) as that is what I do with mutt. I cannot press a key on
mailer-daemon email and tell to database that email address of
specific user is invalid.

Polling exclusively the enthusiastic Emacs users, those who report
here, is biased as expectation for Control-z comes from shell and
terminal users in the first place, not Emacs users. Functionality is
obviously not there to be used frequently. It suspends the
process.

We have seen here on the mailing list in last days that several people
assumed that some keys are anyway not used by anybody, and some people
said "NO", I use it every day.

M-t for example I never use personally, should I for that reason
assume it is "rare" and not used by average users and because it is
not used by average users rather remove the key in the mainstream
Emacs? I don't think so. I am aware that such poll would be biased
from beginning.

If you wish to make a poll, make it on all keys as that would not be
biased poll.

Or make a package that tracks which keys are used except of those with
self-insert, and I will gladly run it and submit data to you. That
would not be biased.

Make something similar like popularity contest in Debian, just for
keys, wait for one year and evaluate results.

That would not be biased way.

And polling new or casual users or Emacs is impossible as they will
never report anywhere.

Control-Z will be used by those shell and terminal users who know what
is job control.

From that group of people, those Emacs beginners will be using
Control-Z.

From that group of people, those Emacs users who use Emacs Lisp or
Emacs for more extensive processing, will be those who use Control-Z.

Average Emacs users will not be using Control-Z as average Emacs user
does not handle extensive processing.

Sarcasm follows:

Go ahead and ask average group of users to remove a function on the
key that is not used by average group of users (call it "rarely
used"). You will not get complaints of beginners, as they will never
report here. You may get few complaints of those who find it weird.

But if you wish to apply such criterion then you should apply it on
all Emacs key bindings:

- ask only average users who report here or in other Emacs communities

- find what is not used by average users, what is rare

- remove or replace the function

Again you will never hear of beginners complaining, you will hear
complaints of those not average users who, for opinion of average
users, use some functions rarely.

All that makes no sense.

> > If I suspend a job in bash, I may decide to run it in background, but
> > not automatically.
> > 
> > 1. Control-Z suspends the job, it stops running.
> > 
> > 2. fg brings it in foreground
> > 
> > 3. bg allows it to run in background, shell is free for other commands
> >     in parallel
> > 
> > 4. Invoking other jobs in meantime is possible without interrupting
> >     the suspended job to be continual, they can be continued later with
> >     fg or bg commands in shell
> > 
> > 5. nohup, screen and tmux are not job control commands. They help you
> >     run programs without your direct supervision and without
> >     interrupting them when you log off. But is not related to job
> >     control.
> > 
> > See: (info "(bash) Job Control")
> 
> This is Bash's manual. No Emacs's.

Exactly true! That is where your misunderstanding of Control-Z
expectation comes from. Expectation for Control-Z does not come from
Emacs users, it comes from shell users. From dash, ksh, Bash and other
shell users, including from PowerShell users who miss that function
from Bash, just as referenced on the link above.

Jean

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> You seem to have understanding that key binding like
> Control-Z is for enthusiastic users, those who may report on
> this mailing list, who identify themselves as "Emacs users",
> and who would be average users.

???

> My understanding is that Control-Z is for shell users [...]

Historically I'm sure but now people use terminal multiplexers.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-15 21:25]:
> Jean Louis wrote:
> 
> > You seem to have understanding that key binding like
> > Control-Z is for enthusiastic users, those who may report on
> > this mailing list, who identify themselves as "Emacs users",
> > and who would be average users.
> 
> ???
> 
> > My understanding is that Control-Z is for shell users [...]
> 
> Historically I'm sure but now people use terminal multiplexers.

OK, and again you think that terminal multiplexer is equal or similar to
suspending a job?

In terminal multiplexer you may run multiple processes in the same time. But if
you wish to suspend a job that you have invoked from shell, then again you need
to use Control-Z to suspend it.

Other way to suspend job in terminal multiplexer would be to go into other
shell and use top or other way to find the process PID and then kill it with
signal SIGSTOP.

Control-Z gives terminal stop or SIGTSTP to shell straight and without delays
and is used in emergency times.

That multiple programs may run in terminal multiplexer is not equal with
suspending a process straight from the shell.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> That multiple programs may run in terminal multiplexer is
> not equal with suspending a process straight from the shell.

Correct, because other than sending a single signal to
a process, in a tmux pane you can also do everything else.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Philip Kaludercic]

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

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.02.2021 10:17, Robert Thorpe wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> On 12.02.2021 07:42, Robert Thorpe wrote:
>>>
>>>> I agree with Jean Louis on that too.  I think C-z C-z is not good
>>>> enough.  Every other terminal application uses C-z by itself, it's a
>>>> convention.  It's been that way for decades.  If you write a terminal
>>>> application and do nothing special then C-z will suspend it.  That's
>>>> because it sends SIGTSTP.
>>>
>>> Could we someday stop considering Emacs a "terminal application"? Yes,
>>> it has a version that works in the terminal, but it's limited in
>>> features compared to the graphical one.
>> I only use graphical Emacs myself.  But I think that terminal Emacs
>> is
>> still important, as Jean Louis says.
>> Lots of people who have started using Emacs recently came to from
>> the
>> terminal.  You can see that on Emacs Reddit.
>
> Those are often former Vim developers, too. So it might not be due to
> the nature of their work, but largely due to their previous habits.
>
> It's not a 100% conclusion of the survey we have referred to previously,
> but its results state that ~30% of all users are in the terminal, ~30%
> of all users are using a Vim key bindings emulation, and ~30% of all 
> users have been using Vim as their primary editor previously. They
> can't be all the same users, but it's an interesting coincidence.

We do have the raw data from https://emacssurvey.org/2020/, it is
possible to how these factors influence one another, but in the end, I
don't think that makes terminal Emacs usage illegitimate.

-- 
	Philip K.

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

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 14.02.2021 13:28, Philip Kaludercic wrote:

> We do have the raw data from https://emacssurvey.org/2020/, it is
> possible to how these factors influence one another, but in the end, I
> don't think that makes terminal Emacs usage illegitimate.

I'm happy to accommodate terminal users in my packages, I'm just saying 
they don't necessarily use the terminal for its extra features, job 
control in particular.

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Dmitry Gutov wrote:

> I'm happy to accommodate terminal users in my packages, I'm
> just saying they don't necessarily use the terminal for its
> extra features, job control in particular.

OK, if that's the way it should be, I'm not gonna be any less
generous. So here it is: GUI users can use my Elisp as well!
Even those who don't play Quake. Because I know and accept,
not all of them do.

...

Oh, no! I just realized! Because that's exactly right!
Quake doesn't have a GUI, it even has a text command
interpreter! So it is the worst possible example! Ma-an, I'm
so embarrassed, me and my words - I should have said Pizza
Tycoon instead...

But this shouldn't be about me. It should be about Emacs.
I have to snap out of it for our greater cause.

So now it seems the big issue is - how do we bridge the
insurmountable pit, that has opened itself, tearing the Emacs
community (or "nation") apart, with two seemingly
fundamentally different computer user types (races, if you
will), on either side?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 14.02.2021 15:14, Emanuel Berg via Users list for the GNU Emacs text 
editor wrote:
> So now it seems the big issue is - how do we bridge the
> insurmountable pit, that has opened itself, tearing the Emacs
> community (or "nation") apart, with two seemingly
> fundamentally different computer user types (races, if you
> will), on either side?

ttyquake?

Re: not good proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Dmitry Gutov wrote:

>> So now it seems the big issue is - how do we bridge the
>> insurmountable pit, that has opened itself, tearing the
>> Emacs community (or "nation") apart, with two seemingly
>> fundamentally different computer user types (races, if you
>> will), on either side?
>
> ttyquake?

It actually exists. Well, I always said text is superior for
almost everything in computing. Yes: almost.

Thanks for this session Emacs friends all over the world ...
now, finally time to crash another system, for an unspecified
amount of time. Luckily Lisp is the most round, curly, and
colorful of all programming languages (it can be capricious,
as well), so if I dream about it - let's gozzz

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: not good proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Robert Thorpe <rt@robertthorpeconsulting.com> [2021-02-11 10:55]:
> There is another issue....  I'm not sure that third-party packages will
> use the feature.  I'm also on the Reddit Emacs group.  Several of the
> people there use and develop third-party packages.  It seems to me that
> they often do that because they don't want to contribute to core.  Some
> don't like the core Emacs development team and don't  agree with their
> direction for Emacs.  So, would they use such a prefix key if it were
> offered?  Perhaps not.

In relation to those negative impressions, it would be good to lessen
generalization as then this is presented here to other people on
mailing list and feeling may go down the hill, maybe for no good
reason or justification.

Instead of telling "they don't want to contribute to core" it would be
better to say "one person" or "two persons" or better "two persons
among 12" would not like to contribute to the core and then to tell
reasons why, so to be more specific.

Core developers are IMHO friendly and hard working programmers,
extremely cooperative compared to many other societies of people, and
that statement now draws some imaginary negative image without
presenting any facts to it.

"Some don't like the core Emacs development team" -- so instead of
generalizations like that, it would be good to provide the references
as hyperlinks to those statements, that we understand what are the
actual real world problems as only so the problems can be
solved. 

Did those developers already try to participate in emacs development?
There is no factual information, so generalization like that, so is
better to minimize spreading of uncertainties.

You may invite specific people to tell here on the mailing list if
they have any proposal for improvements.

What I see personally is that developers give 20 times more effort in
discussion and there is effort to comfort various opinions of unknown
and known people on this mailing list, they behave kind. Somebody may
like it or not, but instead of generalization it is better to know
exact references to any factual problems.

Jean

RE: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Drew Adams]

[Removed bugs@gnu.support from cc list.
Why was it included?]

> Here are my opinions on these things.
> 
> * Moratorium on New Emacs Keybindings.
> 
> At present there's lot of work going on outside of core Emacs.  I think
> it makes sense for core Emacs not to use too many keybindings.  I can
> see the sense the argument Drew Adams makes.
> 
> If a *general* moratorium isn't possible, then how about a more
> specific one?  How about applying it only to certain keymaps
> or prefix keys.

We shouldn't assume from the get-go that a more
general hands-off isn't possible.

(I know you said "if".  But Emacs devel _can_
sometimes be moved by what its users say they want.)

> * A Prefix-Key for Global Third-Party Packages.
> 
> I think this is a good idea too.  Picking the
> right key is a problem.

1. Limiting to one key is, well, unnecessary,
   premature limiting.

2. It's not a great idea to couple (1) this
   suggestion of reserving a single key with
   (2) a proposal to repurpose a key that's
   already bound.

#2 just complicates things.  The entire thread
on emacs-devel has been somewhat hijacked now,
and turned into discussions about particular
keys that might be changed, with people chiming
in about not wanting some key they use to be lost.

It's far smarter to reserve keys that do NOT
already have default bindings.  There are a few
such, still free.  We should keep them free (no
default bindings), reserving them for 3rd-party
code (and of course for users - users can ALWAYS
change any keys for themselves).
 
> ** Which Key to Use?

See previous.  Don't start by proposing to change
any keys already bound by default.  Start by
getting Emacs dev to reserve some that are NOT
already bound.

Skip, at least to start out with, all the
back-&-forth about this or that key that X thinks
is useless and Y thinks is essential and uses all
day long every day.

Don't mix up the need to save free keys with the
possibility that some keys already bound could
be put to better use.

Re: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Drew Adams <drew.adams@oracle.com> writes:

> [Removed bugs@gnu.support from cc list.
> Why was it included?]

That email address is Jean Louis, that's why it's there.  I find it
confusing too.

>> If a *general* moratorium isn't possible, then how about a more
>> specific one?  How about applying it only to certain keymaps
>> or prefix keys.
>
> We shouldn't assume from the get-go that a more
> general hands-off isn't possible.
>
> (I know you said "if".  But Emacs devel _can_
> sometimes be moved by what its users say they want.)

I'm not convinced that a totally general moratorium would be good.  For
example, on this list a few days ago we talked about info-apropos.  John
Yates suggested binding it to a key in the C-h prefix.

I think something like that is fairly harmless.  Changing something two
prefixes away is likely to affect nobody (e.g. C-x 8 1).

BR,
Robert Thorpe

RE: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Drew Adams]

> > [Removed bugs@gnu.support from cc list.
> > Why was it included?]
> 
> That email address is Jean Louis, that's why it's there.  I find it
> confusing too.

Oh, sorry about that.  I thought it was maybe
some other mailing list.

> >> If a *general* moratorium isn't possible, then how about a more
> >> specific one?  How about applying it only to certain keymaps
> >> or prefix keys.
> >
> > We shouldn't assume from the get-go that a more
> > general hands-off isn't possible.
> >
> > (I know you said "if".  But Emacs devel _can_
> > sometimes be moved by what its users say they want.)
> 
> I'm not convinced that a totally general moratorium would be good.  For
> example, on this list a few days ago we talked about info-apropos.
> John Yates suggested binding it to a key in the C-h prefix.
> 
> I think something like that is fairly harmless.  Changing something two
> prefixes away is likely to affect nobody (e.g. C-x 8 1).

I agree that there are nuances, and that adding a key
to an already bound prefix key is less aggressive than
binding a top-level key by default.

Good point.  But let's at least start with a first-level
approximation.  The problem is not so much the kind of
thing you describe there.  The problem is things like
Emacs suddenly deciding to bind `C-x p', `C-x x', `C-x /'
etc. by default.

Details about possibly binding _any_ more keys by default
should be discussed generally, widely.  That's not been
done.  A general convention that Emacs should not do this
is in order, IMHO.  And I made clear that exceptions can
always be handled by good, general discussion followed by
maintainer decision.

It's not black & white.  There is a serious problem, and
I think there we should establish a general convention/rule/guideline/understanding that Emacs should
keep its mitts off keys not already bound.

As I pointed out, there's plenty of room for Emacs to
restructure existing default key bindings, to consolidate
using prefix keys or whatever.  And doing that can free
up keys both for new Emacs default bindings and 3rd-party
code.  For the former, I'm thinking along the lines you
mentioned - e.g. add a binding on some existing default
prefix key, while removing some global default key, i.e.,
move a command from a somewhat wasted default key to a
default prefix key.

Let Emacs restructure, to find keys it thinks it needs.
There's room for that.

Of course, doing that is hard work.  It requires and
invites the kind of my-key vs your-key discussion we've
now been seeing.  It's much _easier_ for Emacs to just
grab another virgin key.  But that's wrong - that's the
problem.

Re: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Robert Thorpe]

Drew Adams <drew.adams@oracle.com> writes:

> I agree that there are nuances, and that adding a key to an already
> bound prefix key is less aggressive than binding a top-level key by
> default.
>
> Good point.  But let's at least start with a first-level
> approximation.  The problem is not so much the kind of thing you
> describe there.  The problem is things like Emacs suddenly deciding to
> bind `C-x p', `C-x x', `C-x /' etc. by default.
>
> Details about possibly binding _any_ more keys by default should be
> discussed generally, widely.  That's not been done.  A general
> convention that Emacs should not do this is in order, IMHO.  And I
> made clear that exceptions can always be handled by good, general
> discussion followed by maintainer decision.
>
> It's not black & white.  There is a serious problem, and I think there
> we should establish a general convention/rule/guideline/understanding
> that Emacs should keep its mitts off keys not already bound.

I see your points and I mostly agree.  I definitely agree that there
should be wider discussion before binding more keys by default.

But I still think it would be useful to have one key that is gauranteed
as Gregory Heyting suggests.  Even if it were only gauranteed for a few
years.

Preferably, we should have both...  Firstly, a general consensus to
discuss new keybindings and not to introduce lots of them at once.
Secondly, a single prefix-key specifically reserved for third-party
packages.

Also, there's still the issue of beginners.  I still think that asking
people to map keys themselves is unfriendly to new users.

BR,
Robert Thorpe

Re: Proposal: "C-z <letter>" reserved for users

[Colin Baxter]

>>>>> S Boucher via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> writes:

    > C-z is bound to a low frequency use function
    > (suspend-frame)... and speaking for myself, I probably can count
    > on one hand the number of times I've used it in the last 25years
    > :-)

    > I would suggest:1) move suspend-frame to "C-c C-z" (that is still
    > a quick shortcut) 2) reserve C-z <letter> for users That still
    > leaves a whole lot with C-z C-... C-z M-...

As way of an illustration of the legion of different emacs usages, I use
C-z to suspend the frame several times a day. This is because I have an
emacs always open in a terminal and C-z is a simple way of getting back
to the terminal - easier, I find, than opening a shell in the already
terminal-running emacs. C-c C-z is not as convenient.

Best wishes,

Re: Proposal: "C-z <letter>" reserved for users

[Leo Butler]

Colin Baxter <m43cap@yandex.com> writes:

>>>>>> S Boucher via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> writes:
>
>     > C-z is bound to a low frequency use function
>     > (suspend-frame)... and speaking for myself, I probably can count
>     > on one hand the number of times I've used it in the last 25years
>     > :-)
>
>     > I would suggest:1) move suspend-frame to "C-c C-z" (that is still
>     > a quick shortcut) 2) reserve C-z <letter> for users That still
>     > leaves a whole lot with C-z C-... C-z M-...
>
> As way of an illustration of the legion of different emacs usages, I use
> C-z to suspend the frame several times a day. This is because I have an
> emacs always open in a terminal and C-z is a simple way of getting back
> to the terminal - easier, I find, than opening a shell in the already
> terminal-running emacs. C-c C-z is not as convenient.
>
> Best wishes,

To pile on:

elscreen.el uses C-z 0, C-z 1, etc. for jumping to screen 0, 1,
etc. Since I use emacs -nw --daemon, I am happy to have C-z co-opted by
elscreen.el.

Leo

Re: Proposal: "C-z <letter>" reserved for users

[Marcin Borkowski]

On 2021-02-08, at 11:03, Colin Baxter <m43cap@yandex.com> wrote:

>>>>>> S Boucher via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> writes:
>
>     > C-z is bound to a low frequency use function
>     > (suspend-frame)... and speaking for myself, I probably can count
>     > on one hand the number of times I've used it in the last 25years
>     > :-)
>
>     > I would suggest:1) move suspend-frame to "C-c C-z" (that is still
>     > a quick shortcut) 2) reserve C-z <letter> for users That still
>     > leaves a whole lot with C-z C-... C-z M-...
>
> As way of an illustration of the legion of different emacs usages, I use
> C-z to suspend the frame several times a day. This is because I have an
> emacs always open in a terminal and C-z is a simple way of getting back
> to the terminal - easier, I find, than opening a shell in the already
> terminal-running emacs. C-c C-z is not as convenient.

But I think nobody is arguing to put anything to C-z by default - only
to make it unbound and free for the user to do whatever s/he wishes.
Many of us have bound C-z to our custom keymaps, nothing prevents you to
bind it to `suspend-frame' - at least if it is free.  Even if it were
not, you can still do it, of course.  (I have C-0 bound to something
else than the default - but if I accidentally hit it on someone else's
Emacs, nothing terrible happens, it's just a minor inconvenience then.)

The main argument here, I guess, is "people sometimes use other people's
Emacsen, and in such a case having C-z bound to `suspend-frame' is not
only inconvenient, but also dangerous".  I don't think anyone can argue
with that.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 09.02.2021 08:02, Marcin Borkowski wrote:
> But I think nobody is arguing to put anything to C-z by default

We do: put 'undo' on it, so that we stop hiding that feature from new 
users who're just trying Emacs for the first time.

But making it unbound would be a good step either way: I will finally 
stop tripping over frame suspend in 'emacs -Q'.

Re: Proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

[It is regrettable that this thread has hijacked the proposal under 
discussion in the "PROPOSAL: Repurpose one key..." thread.]

>
> We do: put 'undo' on [C-z], so that we stop hiding that feature from new 
> users who're just trying Emacs for the first time.
>

Users who are trying Emacs for the first time have a direct access to 
"Undo": it's in the tool bar, labeled "Undo".  If you put the mouse there, 
it says "Undo last edits (C-x u)".  Moreover the bindings for "undo" are 
not more exotic than those of copy (M-w), cut (C-w) and paste (C-y).

Re: Proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 09.02.2021 14:41, Gregory Heytings wrote:
> Users who are trying Emacs for the first time have a direct access to 
> "Undo": it's in the tool bar, labeled "Undo".  If you put the mouse 
> there, it says "Undo last edits (C-x u)".

That still requires extra research on the part of the user. As well as 
subsequent adaptation.

> Moreover the bindings for 
> "undo" are not more exotic than those of copy (M-w), cut (C-w) and paste 
> (C-y).

True, even though it is a bit more exotic (the advertised binding is a 
whole key sequence rather than a plain modifier+key). But at least we 
have arrow keys for navigation.

Re: Proposal: "C-z <letter>" reserved for users

[Gregory Heytings]

>
> That still requires extra research on the part of the user. As well as 
> subsequent adaptation.
>

I fear everything requires adaptation in Emacs ;-)

>> Moreover the bindings for "undo" are not more exotic than those of copy 
>> (M-w), cut (C-w) and paste (C-y).
>
> True, even though it is a bit more exotic (the advertised binding is a 
> whole key sequence rather than a plain modifier+key).
>

If you think this is a problem, I would suggest to change the advertised 
binding to "C-/" instead of "C-x u".

Re: Proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-09 16:05]:
> 
> > 
> > That still requires extra research on the part of the user. As well as
> > subsequent adaptation.
> > 
> 
> I fear everything requires adaptation in Emacs ;-)
> 
> > > Moreover the bindings for "undo" are not more exotic than those of
> > > copy (M-w), cut (C-w) and paste (C-y).
> > 
> > True, even though it is a bit more exotic (the advertised binding is a
> > whole key sequence rather than a plain modifier+key).
> > 
> 
> If you think this is a problem, I would suggest to change the advertised
> binding to "C-/" instead of "C-x u".

Isn't it already undo on C-/ as alternative to C-x u?

But please don't change C-x u as that is what I expect to work
always.

I use my personal Emacs with configuration and plethora of other
Emacses on other VPS-es and other computers and in those cases muscle
memory remembers defaults. On those Emacses there are no personal
configurations, so automatically I use C-x u or to change window C-x o
while in personal configuration I use s-arrows to change windows.

It is better not breaking habits.

Re: Proposal: "C-z <letter>" reserved for users

[Bastian Beranek]

On Tue, Feb 9, 2021 at 1:56 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 09.02.2021 14:41, Gregory Heytings wrote:
> > Users who are trying Emacs for the first time have a direct access to
> > "Undo": it's in the tool bar, labeled "Undo".  If you put the mouse
> > there, it says "Undo last edits (C-x u)".
>
> That still requires extra research on the part of the user. As well as
> subsequent adaptation.
>
> > Moreover the bindings for
> > "undo" are not more exotic than those of copy (M-w), cut (C-w) and paste
> > (C-y).
>
> True, even though it is a bit more exotic (the advertised binding is a
> whole key sequence rather than a plain modifier+key).

By the way, why doesn't the menu suggest C-/ or C-_ for undo? I use
the former, it is particularly easy to type on english keyboards. I
personally find C-x u inacceptable for undo because repeated
operations are painful with that binding (have to press and release
control in rhythm with x, but not with u).

Re: Proposal: "C-z <letter>" reserved for users

[Skip Montanaro]

On Tue, Feb 9, 2021 at 6:56 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 09.02.2021 14:41, Gregory Heytings wrote:
> > Users who are trying Emacs for the first time have a direct access to
> > "Undo": it's in the tool bar, labeled "Undo".  If you put the mouse
> > there, it says "Undo last edits (C-x u)".
>
> That still requires extra research on the part of the user. As well as
> subsequent adaptation.
>

(Apologies, a bit of a rant. I will shut up after this.)

New users are going to be comfortable with the menu bar concept, especially
the first two menus, File and Edit. They will want to undo something, go to
the Edit menu and select "Undo." They might well wonder what C-x u is, but
they will be able to undo without much drama. Maybe someday they will get
curious enough to poke Help in the menu bar and notice the "Emacs Tutorial"
entry.

I get there is a mismatch between the way Emacs operates and how largely
GUI systems like Windows and MacOS operate. Emacs is waaay older than
either of those systems, so it's reasonable that there not be a perfect
match. For a long while after Emacs began to grow GUI capabilities, I
actively disabled the menu bar. I leave it up now, but still don't use it
much. There are a bazillion other GUI-based editors and IDEs out there for
people who don't like the way Emacs operates or prefer the familiarity of
largely GUI-based systems. Some of them even have "Emacs key bindings." If
people want to harness Emacs's strengths, they should realize that it
differs a significant amount from current GUI system design and be willing
to work a bit to understand how to use it efficiently. I wish there was an
Emacs Biography entry in the Help menu. Maybe it's buried in there
somewhere or as a section in the Emacs documentation. Maybe a link to
Wikipedia named Emacs History <https://en.wikipedia.org/wiki/Emacs> would
be sufficient.

Not being a graphic artist, I never had a need to use Photoshop. I simply
don't understand its model of image editing. The most image editing I ever
did was with simple tools like early versions of MacPaint. While I have no
proof, I suspect a semi-competent Photoshop user could pick up the basics
of GIMP pretty quickly. Every once in a while I think, "I'll just fire up
GIMP for this one little thing." I stumble around for a while, accomplish
nothing and eventually run screaming out of the room. I then go back to
kolourpaint. It's not a big deal. If it was really that important I would
spend the time to figure out GIMP, read a book or find a tutorial. I don't
bitch that GIMP doesn't work like kolourpaint. I think Emacs is similar in
that respect. It has a ton of power. Users have to realize that and be
willing to spend some time learning. If all people want to do is enter some
text, they can run Notepad.

Skip

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Skip Montanaro wrote:

> (Apologies, a bit of a rant. I will shut up after this.)

No, no.

> Not being a graphic artist, I never had a need to use
> Photoshop. I simply don't understand its model of image
> editing. The most image editing I ever did was with simple
> tools like early versions of MacPaint. While I have no
> proof, I suspect a semi-competent Photoshop user could pick
> up the basics of GIMP pretty quickly. Every once in a while
> I think, "I'll just fire up GIMP for this one little thing."
> I stumble around for a while, accomplish nothing and
> eventually run screaming out of the room. I then go back
> to kolourpaint.

Thank you for mentioning MacPaint! 1984 software.

I have the exact same GIMP experience BTW, only I didn't know
of kolourpaint. So that is the equivalent of MacPaint? It is
in the Debian repos ... installing.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

> I have the exact same GIMP experience BTW, only I didn't
> know of kolourpaint. So that is the equivalent of MacPaint?
> It is in the Debian repos ... installing.

But no man page! Not a good sign.

What about the hu-man pages?

Water (35 L), Carbon (20 kg), Ammonia (4 L), Lime (1.5 kg),
Phosphorus (800 g), Salt (250 g), Saltpeter (100 g), Sulfur
(80 g), Fluorine (7.5 g), Iron (5 g), Silicon (3 g) [1]

(I think my personality is mostly in the Phosphorus BTW.)

[1] https://fma.fandom.com/wiki/Human

also:

@book{human-pages-unix-desk-reference,
  author     = {Peter Dyson},
  title      = {The human Pages: The Unix Desk Reference},
  publisher  = {SYBEX},
  year       = {1996},
  isbn       = {0-7821-1658-2}
}

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Dmitry Gutov]

On 09.02.2021 17:59, Skip Montanaro wrote:

> New users are going to be comfortable with the menu bar concept, 
> especially the first two menus, File and Edit. They will want to undo 
> something, go to the Edit menu and select "Undo." They might well wonder 
> what C-x u is, but they will be able to undo without much drama. Maybe 
> someday they will get curious enough to poke Help in the menu bar and 
> notice the "Emacs Tutorial" entry.

And they'll go away with an impression that Emacs is clunky and baroque.

Especially combined with its peculiar 'redo' mechanics. Which is not 
productive compared to modern counterparts, no matter how many years you 
spend with Emacs.

> I get there is a mismatch between the way Emacs operates and how largely 
> GUI systems like Windows and MacOS operate. Emacs is waaay older than 
> either of those systems, so it's reasonable that there not be a perfect 
> match.

It's a good explanation for why things can be what they are now, but not 
why we wouldn't want to ever change them.

> Not being a graphic artist, I never had a need to use Photoshop. I 
> simply don't understand its model of image editing. The most image 
> editing I ever did was with simple tools like early versions of 
> MacPaint. While I have no proof, I suspect a semi-competent Photoshop 
> user could pick up the basics of GIMP pretty quickly. Every once in a 
> while I think, "I'll just fire up GIMP for this one little thing." I 
> stumble around for a while, accomplish nothing and eventually run 
> screaming out of the room. I then go back to kolourpaint. It's not a big 
> deal. If it was really that important I would spend the time to figure 
> out GIMP, read a book or find a tutorial. I don't bitch that GIMP 
> doesn't work like kolourpaint. I think Emacs is similar in that respect. 
> It has a ton of power. Users have to realize that and be willing to 
> spend some time learning. If all people want to do is enter some text, 
> they can run Notepad.

Unlike GIMP or Photoshop, Emacs is not a special-purpose program. We 
expect it to be useful to a wide range of professions. Nor is it a 
console editor. So it should make sense to make an effort to accommodate 
all different kinds of people.

If it were just a niche old-style editor, I would have left long ago, 
and some of the people here might have missed the improvements I have 
contributed over the years.

Re: Proposal: "C-z <letter>" reserved for users

[Emanuel Berg via Users list for the GNU Emacs text editor]

Dmitry Gutov wrote:

> Especially combined with its peculiar 'redo' mechanics.
> Which is not productive compared to modern counterparts, no
> matter how many years you spend with Emacs.

OK, what's the difference?

> Unlike GIMP or Photoshop, Emacs is not a special-purpose
> program. We expect it to be useful to a wide range of
> professions.

Well, maybe the GIMP and Photoshop people say the same thing
about their software with all scripts, plugins add-ons and
whatever that I suspect exist for them as well...

> If it were just a niche old-style editor, I would have left
> long ago, and some of the people here might have missed the
> improvements I have contributed over the years.

That's right! Can't have that.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Proposal: "C-z <letter>" reserved for users

[Joost Kremers]

On Tue, Feb 09 2021, Skip Montanaro wrote:
> For a long while after Emacs began to grow GUI capabilities, I
> actively disabled the menu bar. I leave it up now, but still don't use it
> much.

You know, <f10> works even if the menu bar is disabled. (I disable the menu bar
and use <f10> on the rare occasion that I want to look at the menu bar menu.)


-- 
Joost Kremers
Life has its moments

Re: Proposal: "C-z <letter>" reserved for users

[Jean Louis]

* Skip Montanaro <skip.montanaro@gmail.com> [2021-02-09 18:59]:
> Not being a graphic artist, I never had a need to use Photoshop. I simply
> don't understand its model of image editing. The most image editing I ever
> did was with simple tools like early versions of MacPaint. While I have no
> proof, I suspect a semi-competent Photoshop user could pick up the basics
> of GIMP pretty quickly. Every once in a while I think, "I'll just fire up
> GIMP for this one little thing." I stumble around for a while, accomplish
> nothing and eventually run screaming out of the room. I then go back to
> kolourpaint. It's not a big deal. If it was really that important I would
> spend the time to figure out GIMP, read a book or find a tutorial. I don't
> bitch that GIMP doesn't work like kolourpaint. I think Emacs is similar in
> that respect. It has a ton of power. Users have to realize that and be
> willing to spend some time learning. If all people want to do is enter some
> text, they can run Notepad.

Off-topic:

Yesterday I have seen Adobe Photoshop on computer of business card
producer in Kampala, Uganda. Because I know various Gimp functions, I
could explain to the operator how to resize layers, move and copy them
and make it right. Operator seemed to have same problems like you with
the exception that there was no escape to the kolourpaint.