Re: Suggested experimental test

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-23 17:17]:
> 
> > > > > > I use C-o (usually followed by C-n) many times a day,
> > > > > > instead of <Enter>, in order to suppress re-indentation
> > > > > > of the current line in cases where that re-indentation
> > > > > > will be incorrect for my purposes**.
> > > > > 
> > > > > Oh, I see -- it's useful as an alternative to `RET' exactly
> > > > > when re-indentation does the wrong thing?
> > > > 
> > > > Yes, but not only that -- it doesn't move point to the next
> > > > line, unlike RET.
> > > 
> > > Why should a control key must be reserved forever for that very
> > > specific purpose, and for that very specific purpose only, in the
> > > default Emacs bindings?
> > 
> > Opening an empty line is a very useful editing primitive, not unlike
> > going to the next line with RET.
> > 
> 
> I'd bet it is useful, as it is, only for 0.5% of Emacs users, perhaps even
> less.  No other editor I know has that feature.

It cannot be argument here that other editors don't have features
built-in into Emacs. Those are known facts. Emacs is advanced
editor. Other editors simply don't have features of Emacs, unless they
are Emacs-like. But there are several Emacs-like editors: Edwin in MIT
Scheme, mg in OpenBSD, e3em, Zile, Zile on Guile, Emacs on Guile,
those are once that I use from time to time here, including as a
replacement for emacsclient (when something goes wrong). I have used
those multiple times during last month. More references:
https://wiki.gentoo.org/wiki/Project:Emacs/Emacs-like_editors

Now when you bet, I also bet you don't use Emacs-like editors, and I
am unsure how much you use Emacs beside those other editors you use. 

Another feature that many editors don't have is macro feature, editors
that do have macro features are always more advanced than
others. Because other editors do not have that feature, should we
disable macros in Emacs?

And then which other editors do you mention? Can we get the
disclosure? Your personal experiences should or could be reasoned to
understand those features you are referring to.

> And I'd bet that 90% of those 0.5% would be happier with a better
> open-line primitive, for example one which can be called when point
> is in the middle of a line, like "o" and "O" in vi.

I have mentioned my personal case and I said I would not like changing
default of C-o or getting habit with my personal customizations to
have C-o behave like O in vi. In relation to "o" in vi, I do not open
new line below the current one, but I agree that quicker key binding
would be nice. "o" from vi in Emacs is easily replaced with C-o as
instead of using the current line, then I would be simply using one
line below.

- "o" in vi -- frequently used, it opens new line after current line,
  regardless where is cursors located. In Emacs: go to one line below,
  beginning of line, press C-o

- "O" in vi - frequently used, opens new line before current line and
  places cursor at beginning of the line for writing, in Emacs, C-a
  C-o does the same.

Again, I would not like changing Emacs default behavior as for me who
works on various Emacs versions, including some older like few years
(OS never get updated on those computers) -- including using
Emacs-like editors frequently on remote VPS-es or remote computers,
sometimes on personal computer.

> The discussion showed that those who use it use it at BOL, and that
> it wasn't used alone, but as part of a sequence, for example C-a C-o
> or C-o C-n.  Nobody even mentioned the fact that open-line uses the
> fill-prefix and the left-margin.
> 
> As I said, an improved version of that command could for example be put on
> M-RET.  Here's an attempt:
> 
> (defun smart-open-line (&optional arg)
>   (interactive "*p")
>   (when (> arg 0)
>     (beginning-of-line)
>     (let ((p (point-marker)))
>       (dotimes (_ arg) (insert "\n"))
>       (goto-char p)))
>   (when (< arg 0)
>     (setq arg (abs arg))
>     (beginning-of-line)
>     (forward-fine 1)
>     (dotimes (_ arg) (insert "\n"))
>     (forward-line -1)))
> (global-set-key (kbd "M-RET") 'smart-open-line)

I have tried that version, it may be better than this one below that I
have ready -- but remember, I am not using it and do not want to
depend on it, that it does not change my finger work when I am working
on un-customized Emacs versions.

(defun my-C-o ()
  "Opens new line regardless where is cursor positioned."
  (interactive)
  (move-beginning-of-line nil)
  (open-line 1))

but I would like to ask not to bind M-RET to something by default in
Emacs, as it is used very efficiently in the package Hyperbole, and I
recommend that you try using Hyperbole to understand M-RET

> And even assuming that it is useful as it is, that doesn't answer
> the main question: why should a control character key be reserved
> forever for that very specific purpose, and for that very specific
> purpose only?

Because it is default for many years, learned and used by people and
adopted by other Emacs-like editors.

You can make then same question like why should C-a be used to jump to
beginning of the line or C-f to move one char forward. 

Nothing is forever.