On Fri, 04 Nov 2022 20:24:27 +0100
Axel Reichert <mail@axel-reichert.de> wrote:
> Do you use
> vi mode for other command line editing stuff as well? If so, can you
> comment on the motivation? While I am an adherent to the other editor
> religion, I can reasonably work with vi as well, but for command line
> editing a mode-based paradigm seems especially strange. No holy wars, I
> am genuinely curious. And even the vi users I know will normally stick
> to bash's default emacs editing mode.

Yes , I use vi mode for all command line editing because I know it well
and find it natural including the mode model although in command line
it annoys me a bit that I don't get visual confirmation on which mode
I'm in. I can't imagine why one would use one set of keys (combinations)
for file editing and a very different one for command line editing.

Spiros Bousbouras wrote:
> Yes , I use vi mode for all command line editing because I know it
> well and find it natural including the mode model although in command
> line it annoys me a bit that I don't get visual confirmation on which
> mode I'm in. I can't imagine why one would use one set of keys
> (combinations) for file editing and a very different one for command
> line editing.

I edit files with vim (having used vi since the mid '80s), and edit
command lines with emacs mode in zsh. I never gave it much
thought--especially since vi command mode is just a ^X^V away. Each
mode has its upsides. And most anything is better than the rudimentary
(backspace, and retype) editing that we had in sh.

I briefly had a mode indicator set up for vi mode; but it was
unnecessary clutter; and vi didn't have one, so i don't miss it. (I'm
still not used to it being there in vim, and pretty much ignore it.)

On Sat, 5 Nov 2022 01:59:08 -0500
Brian Patrie <bpatrie@bellsouth.spamisicky.net> wrote:
> I briefly had a mode indicator set up for vi mode; but it was
> unnecessary clutter; and vi didn't have one, so i don't miss it. (I'm
> still not used to it being there in vim, and pretty much ignore it.)

You can turn it off in vim with
:let &showmode = 0

On 05.11.2022 03:37, Janis Papanagnou wrote:
> On 04.11.2022 20:24, Axel Reichert wrote:
>> While I am an adherent to the other editor
>> religion, I can reasonably work with vi as well, but for command line
>> editing a mode-based paradigm seems especially strange.
>
> ...so it's probably better if you elaborate on why and what you think
> is "especially strange" so that I can better focus on the information
> you're asking for.

To anticipate...

To repel folks we can start with "modes" :-) What do we have?
Visual mode in Vim/Gvim - I cannot use it in ksh's built-in command
line emulation and don't need/use it in ksh's Esc-V editor call.
Ex-mode - supposed to work on selected/all lines of the input file;
I rarely (or don't ?) use it when editing shell commands.
So what we actually have is Command/Normal-mode and something that
we may call Input-mode and I think we can focus on that.

I think it is helpful if we ignore input as a separate "mode" and
just view it as a method of providing arguments to (vi-)commands!
So that everything you do in Vi/Vim is just issuing (vi-)commands.

For example a simple command is 'x' (it requires no arguments).
To move (adjacent) to a character you specify the target, e.g.
'f'<c> (or 't'<c>), and commands of this sort take an argument.
Other movements have implicit semantics (without argument, like
'w', 'W', '4W', 'e', '$'; may be prefixed with parameters like '4').
And yet other commands have arguments that can have _arbitrary_
amounts of characters, e.g. 'i', 'a'; so the end of the argument
data must be indicated somehow, and the ESC key is used for that.
We have 'i' <input> <ESC>. - We may call that "Input-Mode" if we
like but it's not really necessary, and I think it's probably a
hindrance if we like to understand the vi concept.

So the essence is that it's not so much about modes but about what
constitutes the editing. It is the movement and editing-commands.

Vi supports movements to arbitrary syntactical entities; relative
to characters, words, lines, sentences, paragraphs, bracketed
expressions, screen, file. And Vi supports commands (almost all
characters are commands). You can orthogonally combine movements
with commands and parameterize them in addition.
'w' or '4w' are movements, 'dw' or 'd4w' is a (delete-)command
that works on the range specified my the movement. You can also
parameterize the command operator, '3dw' or '3d4w'.

Simple movements can be mapped to function keys on the keyboard;
<Home>, <Page-Up>, <Arrow-Right>. And simple commands may also be
mapped to function keys; <Delete>, <Backspace>. Some more movements
can be composed by control-keys (<Ctrl>, <Alt>, etc.; e.g. <Ctrl>
<Right-Arrow>).

Vi has far too many movements and commands (parameterized or not)
to use simple (easier to perceive) function keys on the keyboard,
while those that can be mapped [in Vim/Gvim] typically also work as
expected.

The reason why I use vi is the fact that I can address arbitrary
entities in the text with a minimum amount of keystrokes. I think
this is the key-observation. Operations on the data (the editing)
is then only one more key to be typed ('d', 'c', 'y'; to delete,
change, yank/copy). This orthogonality is another reason for using
Vi.

I see folks hammering on <Arrow-Left> keys to navigate, or mark
text and delete it (as I also do in Windows OS contexts) with, say,
<Shift><Ctrl><Arrow><Arrow><Arrow><Delete> function keys. I prefer
the more efficient Vi-commands. They also allow me to a very large
degree to type "blind"; to delete to the second colon I type 'd2f:'
and know it is accurate, because I addressed the syntactical entity
and not moved "manually" there (that I have to control "visually").
Issuing commands also allows simple repetition of commands; I often
have to do the same task in several places. A simple '.' will repeat
the last command; if you typed 'dwdwdw' to delete three words the
'.' will delete another word, and if you typed 'd3w' the '.' will
delete another three words.

With that powerful tool I try to not use simpler and less efficient
methods (if avoidable). That's why I use vi-mode and Esc-V editing
with vim in shell.

Janis

On Sat, 5 Nov 2022 14:55:42 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> I see folks hammering on <Arrow-Left> keys to navigate, or mark
> text and delete it (as I also do in Windows OS contexts) with, say,
> <Shift><Ctrl><Arrow><Arrow><Arrow><Delete> function keys.

Where does this apply ?

> I prefer
> the more efficient Vi-commands. They also allow me to a very large
> degree to type "blind"; to delete to the second colon I type 'd2f:'
> and know it is accurate, because I addressed the syntactical entity
> and not moved "manually" there (that I have to control "visually").

A frustration I have with command line editing is that there is no
search i.e. / and ? don't seem to work. The reason I would find
search useful is that sometimes it is the quickest way to specify a
point in the text because with things like f<some-char> or
t<some-char> there may be too many of <some-char> to see with a
quick look which number I should choose. Whereas with / and ? you
can give a longer sequence. This serves me well with file editing but I
don't know of an analog for command line editing. Obviously I can issue
the edit-and-execute-command command and start an actual vim instance.

--
A specification that has been superseded by a more recent specification or is
for any other reason considered to be obsolete is assigned to the "Historic"
level. (Purists have suggested that the word should be "Historical"; however,
at this point the use of "Historic" is historical.)
RFC 2026

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> This is not a vi mode; it's just launching an external editor.
>
> In Bash, Ctrl-X Ctrl-E does this, by default.

In fact, I never used this. I learned something here, thanks. But at
this point, we are close to eshell or other shell modes in Emacs.

Best regards

Axel

Eli the Bearded <*@eli.users.panix.com> writes:

> Only one or two cW or rx type things make me reach for "set -o vi".

Might be a fun experiment to set up newbie's command line defaults like
this. Perhaps it will look similar to a session with "ed":

https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard_text_editor.html

(-:

Axel

Spiros Bousbouras <spibou@gmail.com> writes:

> Yes , I use vi mode for all command line editing because I know it well
> and find it natural including the mode model although in command line
> it annoys me a bit that I don't get visual confirmation on which mode
> I'm in.

O.K., then my perception was a biased one (not knowing enough hard-core
vi users). Thanks!

Axel

On 05.11.2022 15:21, Spiros Bousbouras wrote:
>
> A frustration I have with command line editing is that there is no
> search i.e. / and ? don't seem to work.

Works for me. To search the shell history (ksh) I 'Esc' '/' <word> and
jump with 'n' and 'N' forward or backward.

> The reason I would find
> search useful is that sometimes it is the quickest way to specify a
> point in the text because with things like f<some-char> or
> t<some-char> there may be too many of <some-char> to see with a
> quick look which number I should choose.

Ah, you mean to place the pattern to the word on the _current_ line?
Yes, that seems to not work in the shell built-in stripped vi-clone.

Usually I work around that in shell by using other appropriate methods;
that may be (for example); '$' and 'F' to search from the end of the
line, and/or combined with multiplicity parameters, e.g., '3f/', or by
moving closer first, e.g. addressing a unique character 'f@' and then
the desired one 'f/', or moving by other syntactical entities first,
say, '3W' then 'f/'. Also the repetition character helps reaching any
point fast, e.g., 'f/;;;'. Or roughly addressing the column where to
continue your refined search, e.g. '130|'. While I understand well
the frustration there's (for me) a lot of efficient options available.

In practice my lines are not that long, though, that I'd have issues
with that [in shell-vi] missing function [on a line]. And I can also
resort to the (real) editor with "Esc V".

> Whereas with / and ? you
> can give a longer sequence. This serves me well with file editing but I
> don't know of an analog for command line editing. Obviously I can issue
> the edit-and-execute-command command and start an actual vim instance.

This is what I am doing most time anyway for the more complex commands
(or for very large lines that I avoid).

Janis

On 05.11.2022 15:44, Axel Reichert wrote:
> Eli the Bearded <*@eli.users.panix.com> writes:
>
>> Only one or two cW or rx type things make me reach for "set -o vi".
>
> Might be a fun experiment to set up newbie's command line defaults like
> this. Perhaps it will look similar to a session with "ed":

Vi is no toy editor! You should never force newbies to use it without
instruction. This sort of "experiment" would only lead to deterrence;
so probably only advisable for supporters of "religious holy editor
wars".

Janis

On 05.11.2022 15:21, Spiros Bousbouras wrote:
> On Sat, 5 Nov 2022 14:55:42 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> I see folks hammering on <Arrow-Left> keys to navigate, or mark
>> text and delete it (as I also do in Windows OS contexts) with, say,
>> <Shift><Ctrl><Arrow><Arrow><Arrow><Delete> function keys.
>
> Where does this apply ?

You find this in many GUI based editing tools, on Windows (as I wrote)
but also, e.g., in the Thunderbird composer I use to write this post
on Linux. - With the <Shift> and <Ctrl> keys pressed you can navigate
with your arrow keys to mark the text, and then hitting the <Delete>
key deletes that text. On Windows I use it with its text editors (is
it called "Notepad+"?) and word processors (MS Word) and other MS
software (Excel, etc.). The <Shift> is actually for marking and the
<Ctrl> is for moving in larger entities than character, word-wise.

Janis

On Fri, 04 Nov 2022 20:24:27 +0100, Axel Reichert wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> Whenever a command gets typed that is getting lengthy (or use an
>> inherently long compound command) I just "Esc v" and get a vi instance
>> where I can continue typing any command with arbitrary complexity.
>
> This is in fact the first time I read of somebody using this. Do you use
> vi mode for other command line editing stuff as well? If so, can you
> comment on the motivation? While I am an adherent to the other editor
> religion, I can reasonably work with vi as well, but for command line
> editing a mode-based paradigm seems especially strange. No holy wars, I
> am genuinely curious. And even the vi users I know will normally stick
> to bash's default emacs editing mode.

What does it matter. User can set VISUAL=editor_of_choice_here
for command line editing and EDITOR=editor_of_choice_here for file
editing.

On 05.11.2022 at 16:45, Janis Papanagnou scribbled:

> On 05.11.2022 15:21, Spiros Bousbouras wrote:
> > On Sat, 5 Nov 2022 14:55:42 +0100
> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> >> I see folks hammering on <Arrow-Left> keys to navigate, or mark
> >> text and delete it (as I also do in Windows OS contexts) with, say,
> >> <Shift><Ctrl><Arrow><Arrow><Arrow><Delete> function keys.
> >
> > Where does this apply ?
>
> You find this in many GUI based editing tools, on Windows (as I wrote)
> but also, e.g., in the Thunderbird composer I use to write this post
> on Linux. - With the <Shift> and <Ctrl> keys pressed you can navigate
> with your arrow keys to mark the text, and then hitting the <Delete>
> key deletes that text. On Windows I use it with its text editors (is
> it called "Notepad+"?) and word processors (MS Word) and other MS
> software (Excel, etc.). The <Shift> is actually for marking and the
> <Ctrl> is for moving in larger entities than character, word-wise.

That's the IBM CUA ("Common User Access") standard, which also includes
Shift+Del and/or Ctrl+C for cutting, Shift+Ins and/or Ctrl+V for
pasting, and Ctrl+Ins and/or Ctrl+C for copying to the clipboard/buffer.

I think it was already introduced in the days of MS-/PC-DOS, but it was
certainly being used all over OS/2, and then of course, MS-Windows
also came to adopt it. It was also meant to be reminiscent of the
shortcuts used on Apple Macintosh machines, where instead of the Ctrl
key you had to use the Command key, I believe — I don't have a lot of
experience with Macs.

Emacs also supports CUA — or at least, up to a certain extent — but it's
not enabled by default because it conflicts with "native" Emacs key
bindings, and Richard Stallman felt that it would throw seasoned Emacs
users off if CUA were enabled on a fresh install.

Konsole, the default terminal emulator in KDE Plasma, also supports
CUA, but there you have to include the Shift key — i.e. Ctrl+Shift+C,
Ctrl+Shift+X and Ctrl+Shift+V — in order not to conflict with the
standard terminal key bindings. I do not know whether other terminal
emulators support it; character-mode virtual consoles in and of
themselves do not of course, by lack of a clipboard buffer.

--
With respect,
= Aragorn

On 05.11.2022 at 11:16, Bit Twister scribbled:

> On Fri, 04 Nov 2022 20:24:27 +0100, Axel Reichert wrote:
> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> >
> >> Whenever a command gets typed that is getting lengthy (or use an
> >> inherently long compound command) I just "Esc v" and get a vi
> >> instance where I can continue typing any command with arbitrary
> >> complexity.
> >
> > This is in fact the first time I read of somebody using this. Do
> > you use vi mode for other command line editing stuff as well? If
> > so, can you comment on the motivation? While I am an adherent to
> > the other editor religion, I can reasonably work with vi as well,
> > but for command line editing a mode-based paradigm seems especially
> > strange. No holy wars, I am genuinely curious. And even the vi
> > users I know will normally stick to bash's default emacs editing
> > mode.
>
> What does it matter. User can set VISUAL=editor_of_choice_here
> for command line editing and EDITOR=editor_of_choice_here for file
> editing.

Um, no. VISUAL sets the editor that will be used for command-line
editing when in X11 — I do not know whether it works on Wayland — and
EDITOR sets the editor for command-line editing and as the default
editor for file editing [*] when working from a character-mode virtual
console.

VISUAL can therefore be set to either a GUI editor (such as Kate) or a
character-mode editor (such as nano, pico, micro, emacs-nox or vi(m)).

[*] I do not know whether the value of VISUAL overrides the XDG settings
or vice versa.

--
With respect,
= Aragorn

Aragorn <telcontar@duck.com> writes:
> On 05.11.2022 at 11:16, Bit Twister scribbled:
>> On Fri, 04 Nov 2022 20:24:27 +0100, Axel Reichert wrote:
>> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> >
>> >> Whenever a command gets typed that is getting lengthy (or use an
>> >> inherently long compound command) I just "Esc v" and get a vi
>> >> instance where I can continue typing any command with arbitrary
>> >> complexity.
>> >
>> > This is in fact the first time I read of somebody using this. Do
>> > you use vi mode for other command line editing stuff as well? If
>> > so, can you comment on the motivation? While I am an adherent to
>> > the other editor religion, I can reasonably work with vi as well,
>> > but for command line editing a mode-based paradigm seems especially
>> > strange. No holy wars, I am genuinely curious. And even the vi
>> > users I know will normally stick to bash's default emacs editing
>> > mode.
>>
>> What does it matter. User can set VISUAL=editor_of_choice_here
>> for command line editing and EDITOR=editor_of_choice_here for file
>> editing.
>
> Um, no. VISUAL sets the editor that will be used for command-line
> editing when in X11 — I do not know whether it works on Wayland — and
> EDITOR sets the editor for command-line editing and as the default
> editor for file editing [*] when working from a character-mode virtual
> console.
>
> VISUAL can therefore be set to either a GUI editor (such as Kate) or a
> character-mode editor (such as nano, pico, micro, emacs-nox or vi(m)).
>
>
> [*] I do not know whether the value of VISUAL overrides the XDG settings
> or vice versa.

As I recall, the original idea was that $VISUAL would be a full-screen
editor like vi, and $EDITOR might be a line editor like ed or ex.
Programs would invoke $VISUAL when running on a "smart" terminal, which
at the time meant a terminal on which the cursor could be moved around
on the (text-only) screen.

I don't know whether any programs invoke $VISUAL if a GUI is available
and fall back to $EDITOR if it isn't. (I have both set to "vim", so I
don't pay much attention to the distinction.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> Vi is no toy editor!

I know. It is one of the two non-toy editors.

> You should never force newbies to use it without instruction.

Hey, that was just some fun on the principle of discoverability.

Best regards

Axel

On 05.11.2022 at 12:31, Keith Thompson scribbled:

> Aragorn <telcontar@duck.com> writes:
> > On 05.11.2022 at 11:16, Bit Twister scribbled:
> >>
> >> What does it matter. User can set VISUAL=editor_of_choice_here
> >> for command line editing and EDITOR=editor_of_choice_here for file
> >> editing.
> >
> > Um, no. VISUAL sets the editor that will be used for command-line
> > editing when in X11 — I do not know whether it works on Wayland —
> > and EDITOR sets the editor for command-line editing and as the
> > default editor for file editing [*] when working from a
> > character-mode virtual console.
> >
> > VISUAL can therefore be set to either a GUI editor (such as Kate)
> > or a character-mode editor (such as nano, pico, micro, emacs-nox or
> > vi(m)).
> >
> >
> > [*] I do not know whether the value of VISUAL overrides the XDG
> > settings or vice versa.
>
> As I recall, the original idea was that $VISUAL would be a full-screen
> editor like vi, and $EDITOR might be a line editor like ed or ex.

That is possible, yes.

> Programs would invoke $VISUAL when running on a "smart" terminal,
> which at the time meant a terminal on which the cursor could be moved
> around on the (text-only) screen.
>
> I don't know whether any programs invoke $VISUAL if a GUI is available
> and fall back to $EDITOR if it isn't. (I have both set to "vim", so I
> don't pay much attention to the distinction.)

I have VISUAL set to /usr/bin/kate and EDITOR to /usr/bin/nano. If I
press Ctrl+X followed by Ctrl+E in a terminal window, then it'll bring
up Kate. I presume it'll bring up nano when I'm in a character-mode
tty, but so far I haven't used any command editing by way of an editor
there yet on this system. On my previous system, VISUAL was unset and
EDITOR was set to emacs, and there I did use the command editing
function in a tty.

--
With respect,
= Aragorn

On 05.11.2022 20:31, Keith Thompson wrote:
> Aragorn <telcontar@duck.com> writes:
>>
>> Um, no. VISUAL sets the editor that will be used for command-line
>> editing when in X11 — I do not know whether it works on Wayland — and
>> EDITOR sets the editor for command-line editing and as the default
>> editor for file editing [*] when working from a character-mode virtual
>> console.
>>
>> VISUAL can therefore be set to either a GUI editor (such as Kate) or a
>> character-mode editor (such as nano, pico, micro, emacs-nox or vi(m)).
>>
>>
>> [*] I do not know whether the value of VISUAL overrides the XDG settings
>> or vice versa.
>
> As I recall, the original idea was that $VISUAL would be a full-screen
> editor like vi, and $EDITOR might be a line editor like ed or ex.
> Programs would invoke $VISUAL when running on a "smart" terminal, which
> at the time meant a terminal on which the cursor could be moved around
> on the (text-only) screen.
>
> I don't know whether any programs invoke $VISUAL if a GUI is available
> and fall back to $EDITOR if it isn't. (I have both set to "vim", so I
> don't pay much attention to the distinction.)

Earlier in this thread I gave an example where I defined this variable
to point to a wrapper script that (non-GUI) ksh obviously invoked, and
in that wrapper were just other (non-GUI) command-line tools like vim.

Janis

Aragorn <telcontar@duck.com> writes:
> On 05.11.2022 at 12:31, Keith Thompson scribbled:
>> Aragorn <telcontar@duck.com> writes:
>> > On 05.11.2022 at 11:16, Bit Twister scribbled:
>> >> What does it matter. User can set VISUAL=editor_of_choice_here
>> >> for command line editing and EDITOR=editor_of_choice_here for file
>> >> editing.
>> >
>> > Um, no. VISUAL sets the editor that will be used for command-line
>> > editing when in X11 — I do not know whether it works on Wayland —
>> > and EDITOR sets the editor for command-line editing and as the
>> > default editor for file editing [*] when working from a
>> > character-mode virtual console.
>> >
>> > VISUAL can therefore be set to either a GUI editor (such as Kate)
>> > or a character-mode editor (such as nano, pico, micro, emacs-nox or
>> > vi(m)).
>> >
>> >
>> > [*] I do not know whether the value of VISUAL overrides the XDG
>> > settings or vice versa.
>>
>> As I recall, the original idea was that $VISUAL would be a full-screen
>> editor like vi, and $EDITOR might be a line editor like ed or ex.
>
> That is possible, yes.
>
>> Programs would invoke $VISUAL when running on a "smart" terminal,
>> which at the time meant a terminal on which the cursor could be moved
>> around on the (text-only) screen.
>>
>> I don't know whether any programs invoke $VISUAL if a GUI is available
>> and fall back to $EDITOR if it isn't. (I have both set to "vim", so I
>> don't pay much attention to the distinction.)
>
> I have VISUAL set to /usr/bin/kate and EDITOR to /usr/bin/nano. If I
> press Ctrl+X followed by Ctrl+E in a terminal window, then it'll bring
> up Kate. I presume it'll bring up nano when I'm in a character-mode
> tty, but so far I haven't used any command editing by way of an editor
> there yet on this system. On my previous system, VISUAL was unset and
> EDITOR was set to emacs, and there I did use the command editing
> function in a tty.

It would be interesting to know if your assuption is correct.

My impression (and I'm not certain of this) is that most programs that
invoke an editor will use $VISUAL, then $EDITOR if it's not set, then
some default (vi, emacs, nano, or something else, depending on the whim
of the developer) if neither is set. The distinction between $VISUAL
and $EDITOR hasn't been relevant in decades, since line-mode terminals
(emulating or actually using paper for output) went out of fashion.

The only thing I found in POSIX is that mailx invokes $VISUAL (falling
back to vi) for the "visual" command, and $EDITOR (falling back to ed
on XSI-conformant systems) for the "edit" command.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 2022-11-05, Spiros Bousbouras <spibou@gmail.com> wrote:

> Yes , I use vi mode for all command line editing because I know it well
> and find it natural including the mode model although in command line
> it annoys me a bit that I don't get visual confirmation on which mode
> I'm in. I can't imagine why one would use one set of keys (combinations)
> for file editing and a very different one for command line editing.

Uhmm... historically grown? When I started with computers,
WordStar-compatible editors were all the rage. For a while I used
(a clone of) the UCSD p-System editor, which btw is a lot more modal
than vi. Eventually I found MicroEmacs. When I gained access to
Unix, shells with Emacs-style command line editing were already
standard, so I used that. Emacs or MicroEmacs themselves however
were less widely available on the university machines, and so I had
to learn vi. Eventually I mostly stayed with vi as text editor:
universally available, good enough for me. For the command line I
never had a reason to switch away from Emacs style. *shrug*

Now that I think about it, one advantage of vi mode is that you
don't need to fight screen(1) or tmux(1) over ^A or ^B or such.

Oddly enough, the latest editor I started using on some occasions
has been... ed(1).

I have never used TECO, or EDT, or strange Lisp editors that were
rumored to exist.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On 2022-11-06, Christian Weisgerber <naddy@mips.inka.de> wrote:
> Now that I think about it, one advantage of vi mode is that you
> don't need to fight screen(1) or tmux(1) over ^A or ^B or such.

Or serial line XON/XOFF over ^S, ^Q.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Christian Weisgerber <naddy@mips.inka.de> writes:
[...]
> Now that I think about it, one advantage of vi mode is that you
> don't need to fight screen(1) or tmux(1) over ^A or ^B or such.

That's why I map my tmux prefix character to the null character:
set -g prefix 'C-@'
or in GNU screen:
escape ^@^@

It can be entered with Ctrl-Space.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Spiros Bousbouras wrote:

> A frustration I have with command line editing is that there is no
> search i.e. / and ? don't seem to work. The reason I would find
> search useful is that sometimes it is the quickest way to specify a
> point in the text because with things like f<some-char> or
> t<some-char> there may be too many of <some-char> to see with a
> quick look which number I should choose. Whereas with / and ? you
> can give a longer sequence. This serves me well with file editing but I
> don't know of an analog for command line editing. Obviously I can issue
> the edit-and-execute-command command and start an actual vim instance.

Within a line it works in ksh93 but not in bash (at least not the way
I would expect). You have to remember that search directions are
reversed for command history.

So, in ksh93 I can move the cursor to some text that occurs later on the
line I'm on by using:

?text

Bash seem to find the text in the line I'm on, but moves the cursor
to the start of the line instead of the found text.

Like you I would normally hit "v" to edit the line with vi when I want
to do this (so that the search directions work normally, and it works
in bash).

--
Geoff Clare <netnews@gclare.org.uk>

Eli the Bearded wrote:

> Once you think in vi, which I fully get that some people neither can nor
> want to, it's not strange at all. Strange is not being able to use vi
> mode edits on the : line within vi

You can in nvi, and I do it quite a lot. One of the extensions over
historical vi that nvi got right and vim got wrong IMO.

--
Geoff Clare <netnews@gclare.org.uk>

On Monday, November 7, 2022 at 8:11:08 AM UTC-6, Geoff Clare wrote:
> Eli the Bearded wrote:
>
> > Once you think in vi, which I fully get that some people neither can nor
> > want to, it's not strange at all. Strange is not being able to use vi
> > mode edits on the : line within vi
> You can in nvi, and I do it quite a lot. One of the extensions over
> historical vi that nvi got right and vim got wrong IMO.
>
> --
> Geoff Clare <net...@gclare.org.uk>
dffffffffdfdfrdr