It just occurred to me that 'cd -' with its _special behavior_ seems
not well suited for scripting. While 'cd anydir' is just doing its
job and switches to the directory 'cd -' will create spurious output;
the target directory. While that may be desirable in interactive use
I don't see a point to create that spurious output in scripting.
Neither 'cd "$OLDPWD"' nor 'cd ~-' will do that (because they imply
an expansion).

Bash and Ksh always produce that unnecessary output with 'cd -' while
Zsh does that, more sensibly, it seems, only in _interactive mode_.

Is there any sensible application for that inconsistency in scripts?
I mean, say, something like here_I_am=$( cd - )
(which I'd rather explicitly ask for if I want to know the 'pwd').

I am using 'cd -' for decades but now its output got in the way of
other output I create - strange that it didn't occur to me before.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

It just occurred to me that 'cd -' with its _special behavior_ seems
not well suited for scripting. While 'cd anydir' is just doing its
job and switches to the directory 'cd -' will create spurious output;
the target directory. While that may be desirable in interactive use
I don't see a point to create that spurious output in scripting.
Neither 'cd "$OLDPWD"' nor 'cd ~-' will do that (because they imply
an expansion).

Hey look, this is required by POSIX!

When a <hyphen-minus> is used as the operand, this shall be
equivalent to the command:

cd "$OLDPWD" && pwd

which changes to the previous working directory and then writes its
name.

POSIX doesn't say that it may behave differently in a noninteractive
script, so shells which change the behavior are nonconforming.

Basically it seems to be a shortcut for interactive use;
take me back to where I was before and remind me where that is.

It probably suited someone's personal workflows and tastes, and
that person got it into the cd command.

If you don't have the current working directory embedded into
your prompt, and execute "cd -" several times, you might know
know where you are. You can use pwd; but then that's just what is
built-in to the cd - semantics.

Maybe this comes from a time when it wasn't fashionable to adjust the
prompt to include the current directory.


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29.10.2022 03:38, Kaz Kylheku wrote:

On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

It just occurred to me that 'cd -' with its _special behavior_ seems
not well suited for scripting. While 'cd anydir' is just doing its
job and switches to the directory 'cd -' will create spurious output;
the target directory. While that may be desirable in interactive use
I don't see a point to create that spurious output in scripting.
Neither 'cd "$OLDPWD"' nor 'cd ~-' will do that (because they imply
an expansion).

Hey look, this is required by POSIX!

Oh, I haven't looked at POSIX; I was somehow assuming that it's a non-standardized ksh/bash/zsh extension of 'cd' (but confused that
maybe with the 'cd oldstring newstring' extension?). Looking that
up in the portability section of Bolsky/Korn I see both listed in
the "Ksh features not in POSIX" section. So 'cd -' seems to be a
more recent addition to POSIX. We probably have to blame the ksh
paragon for the way this functionality got standardized in POSIX.

When a <hyphen-minus> is used as the operand, this shall be
equivalent to the command:

cd "$OLDPWD" && pwd

which changes to the previous working directory and then writes its
name.

POSIX doesn't say that it may behave differently in a noninteractive
script, so shells which change the behavior are nonconforming.

Basically it seems to be a shortcut for interactive use;
take me back to where I was before and remind me where that is.

Indeed. - Too bad that they didn't differentiate [in ksh] at that
time between interactive mode and scripting in case of 'cd'.

It probably suited someone's personal workflows and tastes, and
that person got it into the cd command.

If you don't have the current working directory embedded into
your prompt, and execute "cd -" several times, you might know
know where you are. You can use pwd; but then that's just what is
built-in to the cd - semantics.

Personally I can't remember what files are actually in a directory,
so every 'cd' should probably imply a 'ls'. :-)

Maybe this comes from a time when it wasn't fashionable to adjust the
prompt to include the current directory.

Even then I wouldn't need it, but as you say, personal workflows
and preferences vary.

I seem to recall that adjusting the prompt was common even in the
late 1980's (my csh times), but memories are faint.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In comp.unix.shell, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 29.10.2022 03:38, Kaz Kylheku wrote:

Hey look, this is required by POSIX!

Really making me want to 'mkdir ./-' and see how things react.

Personally I can't remember what files are actually in a directory,
so every 'cd' should probably imply a 'ls'. :-)

I have some directories where that's painful. Even if using the don't
sort flag.

Maybe this comes from a time when it wasn't fashionable to adjust the
prompt to include the current directory.

I seem to recall that adjusting the prompt was common even in the
late 1980's (my csh times), but memories are faint.

It's behavior I abhor. Prompt changing for 'su', sure; changing with
exit code of last process, okay; putting history line number in, maybe;,
but directories? Ugh, it changes the length of the prompt too much.

But yeah, some people have apparently liked that for a long time.

Elijah
------
PS1=": $USER@$HOST ; "; PS2='^I'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <tjk805$3ndt9$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

[*] Something I consider an issue here is that if I abort editing
with :q! the typed command will still get executed, so it needs
to be deleted before quitting or prefixed by '#'. My expectation
here would be that :w should execute the entered text and :q! not.

Yeah, I find this a little annoying too. But, of course, it makes perfect sense when you think about it. :q!'ing out just reverts the file to what
it was on entry (or at last save, if any).

I've gotten in the habit of doing dd (assuming just a single line in the buffer) before exiting (if I don't want anything to be executed).

--
The whole aim of practical politics is to keep the populace alarmed (and hence clamorous
to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.

H. L. Mencken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29.10.2022 23:27, Eli the Bearded wrote:

On 29.10.2022 03:38, Kaz Kylheku wrote:

[ adjust the prompt to include the current directory ]

It's behavior I abhor. Prompt changing for 'su', sure; changing with
exit code of last process, okay; putting history line number in, maybe;,
but directories? Ugh, it changes the length of the prompt too much.

That's why you occasionally see folks using such prompts with
embedded line breaks, I suppose, having the path on a separate
line, so that you have a complete line available for input.

Myself I haven't changed my prompt definition for decades. It's
still something like user@host:path where the path prefix is
substituted by a '~' for files beneath $HOME. The user@host part
I'd consider less useful in the private context where I solely
work on a single Unix system now. So if I decide to change the
prompt definition I probably start removing that user@host first.

The length of the prompt isn't an issue for me, though. 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 Kornshell with vi editing mode activated.)

What I recently added is a shell-level counter to see whether I
started another (embedded) instance, e.g. from a shell escape of
programs that support that.

Janis

[*] Something I consider an issue here is that if I abort editing
with :q! the typed command will still get executed, so it needs
to be deleted before quitting or prefixed by '#'. My expectation
here would be that :w should execute the entered text and :q! not.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.10.2022 00:11, Kenny McCormack wrote:

In article <tjk805$3ndt9$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

[*] Something I consider an issue here is that if I abort editing
with :q! the typed command will still get executed, so it needs
to be deleted before quitting or prefixed by '#'. My expectation
here would be that :w should execute the entered text and :q! not.

Yeah, I find this a little annoying too. But, of course, it makes perfect sense when you think about it. :q!'ing out just reverts the file to what
it was on entry (or at last save, if any).

Yes, technically you are correct. What I had in mind was that the shell
may have more options to implement something more sensible (read it as: something that I think would be more sensible). It seems that the vi(m) instance will not create exit codes !=0 to differentiate that, though.
So shell might resort to date of "creation" (i.e. first modification)
and modification date after the edit to determine tmp-file changes.

I am aware (OTOH) that some folks may have the expectation to execute
at least the initial text sequence if any other command modification
gets :quited, but to me that appears extremely risky. (Thinking of a
start with rm -rf * then realizing to add a cd command before the rm
and then quitting the editing.)

Besides editing the newly typed command we can use "Esc v" also to
edit (simple or compound) commands from the history. In case of a
complex command (from history or newly typed) deletion is a bit more cumbersome.

Besides command line editing (vi/emacs) in shell there's also the stty
setting 'kill' to allow erasing the input typed on the line; but that
doesn't work in vi mode. There should be *some way* to _abort_ sending
the text as command to the shell. (Explicitly deleting everything seems counter-intuitive to me.)

I've gotten in the habit of doing dd (assuming just a single line in the buffer) before exiting (if I don't want anything to be executed).

Yes, either that, or, (if the typed command will have no bad effects)
just accept the error message.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[*] Something I consider an issue here is that if I abort editing
with :q! the typed command will still get executed, so it needs
to be deleted before quitting or prefixed by '#'. My expectation
here would be that :w should execute the entered text and :q! not.

You get used to that from version control. Whether you're using
old cvs or git, when you find yourself making a commit you don't
want, you blank out the commit log message and save it, and
then quit.

git will not commit if the editor terminates abnormally.

You get a mesage like

error: There was a problem with the editor 'vim'.
Please supply the message using either -m or -F option

Bash has two features for editing a command in an external editor:

- fc (fix command) to edit the previous command (or a range
of commands).

- Ctrl-x e to switch the current command line edit to an
external editor.

Under both of these, the command will be dispatched if you
save and exit.

Like git, they are robust to bad termination. If you suspend
the editor and terminate it with "kill -KILL", Bash will
not execute the command.

If Vim had a way to exit unsuccessfully, as Kenny wishes,
at least git and Bash will do the right thing.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31.10.2022 11:45, Janis Papanagnou wrote:

On 31.10.2022 08:28, Kaz Kylheku wrote:

On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[*] Something I consider an issue here is that if I abort editing
with :q! the typed command will still get executed, so it needs
to be deleted before quitting or prefixed by '#'. My expectation
here would be that :w should execute the entered text and :q! not.

If Vim had a way to exit unsuccessfully, as Kenny wishes,
at least git and Bash will do the right thing.

...or, if an unsuccessful exit is not supported by vim, use a
wrapper - ideally only for shell history edits, so that you can
keep the wrapper simple - like this fragment to create an error
status depending on an actual file change

before=$( stat -c%Y "$1" ) # or %y for higher accuracy?
vim "$1"
after=$( stat -c%Y "$1" )
[[ "$before" != "$after" ]]

and setting 'VISUAL' to such a wrapper.

It just occurred to me that there's also the 'HISTEDIT' (and the
obsolete 'FCEDIT') variable to define the editor. Using one of
these would reduce the risk to be used by other commands.

Do other commands evaluate the 'VISUAL' shell variable?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31.10.2022 08:28, Kaz Kylheku wrote:

On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[*] Something I consider an issue here is that if I abort editing
with :q! the typed command will still get executed, so it needs
to be deleted before quitting or prefixed by '#'. My expectation
here would be that :w should execute the entered text and :q! not.

If Vim had a way to exit unsuccessfully, as Kenny wishes,
at least git and Bash will do the right thing.

...or, if an unsuccessful exit is not supported by vim, use a
wrapper - ideally only for shell history edits, so that you can
keep the wrapper simple - like this fragment to create an error
status depending on an actual file change

before=$( stat -c%Y "$1" ) # or %y for higher accuracy?
vim "$1"
after=$( stat -c%Y "$1" )
[[ "$before" != "$after" ]]

and setting 'VISUAL' to such a wrapper.

Do other commands evaluate the 'VISUAL' shell variable?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31.10.2022 11:51, Janis Papanagnou wrote:

On 31.10.2022 11:45, Janis Papanagnou wrote:

On 31.10.2022 08:28, Kaz Kylheku wrote:

On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>

[*] Something I consider an issue here is that if I abort editing
with :q! the typed command will still get executed, so it needs
to be deleted before quitting or prefixed by '#'. My expectation
here would be that :w should execute the entered text and :q! not.

If Vim had a way to exit unsuccessfully, as Kenny wishes,
at least git and Bash will do the right thing.

...or, if an unsuccessful exit is not supported by vim, use a
wrapper - ideally only for shell history edits, so that you can
keep the wrapper simple - like this fragment to create an error
status depending on an actual file change

before=$( stat -c%Y "$1" ) # or %y for higher accuracy?
vim "$1"
after=$( stat -c%Y "$1" )
[[ "$before" != "$after" ]]

and setting 'VISUAL' to such a wrapper.

It just occurred to me that there's also the 'HISTEDIT' (and the
obsolete 'FCEDIT') variable to define the editor. Using one of
these would reduce the risk to be used by other commands.

Just tested that. The wrapper works with 'VISUAL' but not with the
other two variables.

Do other commands evaluate the 'VISUAL' shell variable?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

If Vim had a way to exit unsuccessfully, [...]
at least git and Bash will do the right thing.

It does.

":cq" or ":cquit" exit with a status of 1. It takes an optional
argument to specify a non-zero status (including 0).

":help cq" to see the documentation.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Watch this space]
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <87v8o0m499.fsf@nosuchdomain.example.com>,

If Vim had a way to exit unsuccessfully, [...]
at least git and Bash will do the right thing.

It does.

":cq" or ":cquit" exit with a status of 1. It takes an optional
argument to specify a non-zero status (including 0).

":help cq" to see the documentation.

That's very useful. Thank you.
I can think of many occasions where this would be useful.

Of course, it has to be used with caution, but when it's right, it's right.

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/CLCtopics

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-31, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

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

If Vim had a way to exit unsuccessfully, [...]
at least git and Bash will do the right thing.

It does.

":cq" or ":cquit" exit with a status of 1.

Wow, that is buried in the functionality.

I've never heard of the use case hinted at by the documentation, with
regard to the compilation scenario: that if you quit with a failed
status, the compiler won't try to compile that file again.

The idea must be that vim is in some kind of external loop
invoked during a build to fix files with errors. To break out of that
loop, you use :cq. Somethingg like:

# while compilation fails, but editing doesn't, repeat:

while ! $(CC) $< -o $@ && vim $@ ; do : ; done

Except with a bit more complexity to invoke vim on the error
output captured from the compiler as a quickfix list. (which is why
this cq is buried in the quickfix command suite).

This seems worth looking into because it has certain obvious advantages
over iterating on "make -k" and fixing batches of errors:

It takes an optional
argument to specify a non-zero status (including 0).

":help cq" to see the documentation.

The argument must be in newer Vim versions; none is documented for Vim
8.0, and it rejects arguments or prefixes.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On 2022-10-31, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

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

If Vim had a way to exit unsuccessfully, [...]
at least git and Bash will do the right thing.

It does.

":cq" or ":cquit" exit with a status of 1.

Wow, that is buried in the functionality.

I've never heard of the use case hinted at by the documentation, with
regard to the compilation scenario: that if you quit with a failed
status, the compiler won't try to compile that file again.

The idea must be that vim is in some kind of external loop
invoked during a build to fix files with errors. To break out of that
loop, you use :cq. Somethingg like:

# while compilation fails, but editing doesn't, repeat:

while ! $(CC) $< -o $@ && vim $@ ; do : ; done

Except with a bit more complexity to invoke vim on the error
output captured from the compiler as a quickfix list. (which is why
this cq is buried in the quickfix command suite).

This seems worth looking into because it has certain obvious advantages
over iterating on "make -k" and fixing batches of errors:

It takes an optional
argument to specify a non-zero status (including 0).

":help cq" to see the documentation.

The argument must be in newer Vim versions; none is documented for Vim
8.0, and it rejects arguments or prefixes.

The numeric argument was added in version 8.2.0095, 2020-01-06.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Watch this space]
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <87h6zeed5g.fsf_-_@axel-reichert.de>,
Axel Reichert <mail@axel-reichert.de> 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.

Not me.

(And, yes, there really is nothing else to say - that won't lead us down
the path to a Holy War...)

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/EternalFlame

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Axel Reichert <mail@axel-reichert.de> writes:

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.

I use C-x C-e, which is bound by default to edit-and-execute-command.
According to the bash documentation, it attempts to invoke $VISUAL,
$EDITOR, and emacs, in that order.

The new vi-edit-and-execute-command (which is not bound by default)
probably does the same thing but falls back to vi rather than emacs
(I haven't verified this). It was added in bash 5.2, but is not
mentioned in the bash documentation.

I use vim as my primary editor ($VISUAL and $EDITOR are both "vim"), but
I use the default emacs-style key bindings in bash.

--
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 */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-11-04, Axel Reichert <mail@axel-reichert.de> 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?

This is not a vi mode; it's just launching an external editor.

In Bash, Ctrl-X Ctrl-E does this, by default.

There are times when command-line editing is not up to snuff,
particularly when you have a multi-line command.

I implemented Ctrl-X Ctrl-E in the TXR Lisp REPL, which is based on a substantially modified Linenoise library.

it's a must-have feature.

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.

I set up vi editing mode in the shell profile of one particular service
account years ago. It keeps tripping me up every time I log into it, but
not enough for me to change it back. :)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In comp.unix.shell, Axel Reichert <mail@axel-reichert.de> 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.

I do this regularly. But I also regularly run long pipelines
and nested loops interactively.

Do you use vi mode for other command line editing stuff as well?

100% yes. For one thing I have vi editing very well memorized, and
even ingrained. <esc>h or <esc>k are things I find myself doing in
very inappropriate places like web text boxes.

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.

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[*]. I use vi mode on my phone (with "Hacker's Keyboard" and Termux shell.)

And even the vi users I know will normally stick to bash's default
emacs editing mode.

Other than arrow keys, I don't know how to use that effectively. I do a
lot of ssh into servers I've never touched before or su into shared
accounts and find myself confronted with the defaults of bash more often
than I'd like. Only one or two cW or rx type things make me reach for
"set -o vi".

[*] Solution ':map * "yyy@y' and then compose commands in the buffer,
hit <esc>* to execute them, then dd or undo the thing and edit it
again. This is how I compose large :g commands or complicated
substitutions.

Elijah
------
mz:'a,'e g/^>/ s/> *>/>>/g |normal 'z

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04.11.2022 20:24, 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?

I'm not sure whether you are asking whether and why I prefer vim to
emacs or why I use the vi-mode of ksh compared to, say, tcsh's edit
features.

What I do is using vim (or vi) wherever some text has to be edited,
since I consider that tool the most flexible and most effective way.
(Only so much for the moment to keep this reply short.)

So, yes, I use it to edit a command line in a ksh session, and to
edit larger shell commands - the shell is a programming language as
other programming languages are, and I do edit programming languages
with vim.

If so, can you comment on the motivation?

Of course I can do that. - I already started to write up something,
but hesitated to continue, because I got unsure whether I understood
the intention of your question correctly...

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.

No holy wars, I am genuinely curious. And even the vi users I know
will normally stick to bash's default emacs editing mode.

(The rest is off-topic and better disputed in comp.editors.)

The good thing is that we can choose whatever we want to use, so there's
also absolutely no need for holy wars. And I certainly don't want to
convince anyone. :-)
For the moment just an anecdote; I experienced (and heard similar
reports from other vi-users) that folks observing some vi-user are often astonished that a) only few keystrokes can transform the whole file
(and I am *not* speaking about hidden complex macros in the background),
and b) that very complex tasks can be invoked that I haven't seen in any
other editor possible.

(I'll elaborate the vi-topic further on request.)

Janis

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 =

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 =

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 =

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, April 12, 2023 at 12:10:51 PM UTC-5, Jalen Q wrote:

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>

saddtdtdtdtdrt rtrtrtrttrt3t3t3t33t3tttttttfttrtrttrtrrt

rtggfgfdffddfdffdfdfdfffdfddfdffddfdffdfdfdfdfdfdfffdfdffddfdffddfdfdfdffddfdffddfggfggfgggfgfgfgfregsssgssr5t5gt55tgt5g5g5ggrtrtrtrrt3rrttrtrtrtrfftfttftfttdftffttftfttftftgfttttffftfvttvgfgtthttttthtthhtthtthtprtrtrtytrttet4yt4t4ty4y4t4t4trereottrrrtrrr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, April 12, 2023 at 12:11:04 PM UTC-5, Jalen Q wrote:

On Wednesday, April 12, 2023 at 12:10:51 PM UTC-5, Jalen Q wrote:

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>

saddtdtdtdtdrt rtrtrtrttrt3t3t3t33t3tttttttfttrtrttrtrrt

rtggfgfdffddfdffdfdfdfffdfddfdffddfdffdfdfdfdfdfdfffdfdffddfdffddfdfdfdffddfdffddfggfggfgggfgfgfgfregsssgssr5t5gt55tgt5g5g5ggrtrtrtrrt3rrttrtrtrtrfftfttftfttdftffttftfttftftgfttttffftfvttvgfgtthttttthtthhtthtthtprtrtrtytrttet4yt4t4ty4y4t4t4trereottrrrtrrr
bvgggyfytyyttytythfhfhghgghbhggjghnhwefgrrgueggtgtgrrgrgrrggrrggr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)