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.