BASH script: Indent with tabs, align with spaces

[Steven H.]

Hi,

I am not very experience with Vim, still learning.

After lots of searching, I found that the only way to indent with tabs and align with spaces is to use the Smart Tabs plugin, so I installed it.

Unfortunately, what this gives me is:

--------------------
#!/bin/bash

f()
{
[tab]local a=1 \
[tab][tab]b=2

[tab]cmd1 --option1 "one" \
[tab][tab]--option2 "two" \
[tab][tab]arg1 \
[tab][tab]arg2 \
[tab][tab]| cmd2 --option3 "three" \
[tab][tab]--option4 "four" \
[tab][tab]arg3 \
[tab][tab]arg4 \
[tab][tab]arg5 \
[tab][tab]| cmd3 --option5 "five" \
[tab][tab]--option6 "six" \
[tab][tab]arg6 \
[tab][tab]arg7
[tab]}
--------------------

What I would like is:

--------------------
#!/bin/bash

f()
{
[tab]local a=1 \
[tab] b=2

[tab]cmd1 --option1 "one" \
[tab] --option2 "two" \
[tab] arg1 \
[tab] arg2 \
[tab] | cmd2 --option3 "three" \
[tab] --option4 "four" \
[tab] arg3 \
[tab] arg4 \
[tab] arg5 \
[tab] | cmd3 --option5 "five" \
[tab] --option6 "six" \
[tab] arg6 \
[tab] arg7
}
--------------------

My ~/.vimrc:

--------------------
filetype indent plugin on
colorscheme desert

syntax on
set hlsearch

set cursorline

highlight CursorLine ctermbg=Black ctermfg=none

set cursorcolumn
highlight CursorColumn ctermbg=Black ctermfg=none

highlight ColorColumn ctermbg=Black

set noexpandtab
set copyindent
set preserveindent
set softtabstop=0
set shiftwidth=8
set tabstop=8
set cindent
set cinoptions=(0,u0,U0

autocmd FileType json setlocal sts=2 sw=2

set list
set listchars=tab:\ \ ,trail:-,extends:>,precedes:<,nbsp:+
highlight SpecialKey ctermfg=grey ctermbg=black
--------------------

Another problem which I am facing after installing the Smart Tabs plugin:

If I use '==' to auto-format a line and then try to repeat it using '.', vim does not do what I want but shows an error message:

E774: 'operatorfunc' is empty


What is the solution to these 2 problems?

[Anton Shepelev]

Steven H.:

> After lots of searching, I found that the only way to
> indent with tabs and align with spaces is to use the Smart
> Tabs plugin, so I installed it.

No, you do not need any plugins for that. I have been
indenting with tabs and alighning with spaces for years,
with just copyindent:

<https://vimdoc.sourceforge.net/htmldoc/options.html#'copyindent'>

[D. Ben Knoble]

On Tuesday, March 18, 2025 at 10:07:25 AM UTC-4 Steven H. wrote:

Hi,

I am not very experience with Vim, still learning.

After lots of searching, I found that the only way to indent with tabs and align with spaces is to use the Smart Tabs plugin, so I installed it.

This was cross-posted at https://vi.stackexchange.com/q/46614/10604

 

[D. Ben Knoble]

Anton, perhaps you care to explain how you make things work as an answer on https://vi.stackexchange.com/q/46614/10604? 

[Steven H.]

On Wed, 19 Mar 2025 13:58:50 +0300 Anton Shepelev wrote:

> No, you do not need any plugins for that. I have been
> indenting with tabs and alighning with spaces for years,
> with just copyindent:

How exactly do you do this?
Could you please share your setup (relevant .vimrc lines)?

[Marc Chantreux]

On Wed, Mar 19, 2025 at 11:20:00AM -0700, D. Ben Knoble wrote:
> On Tuesday, March 18, 2025 at 10:07:25 AM UTC-4 Steven H. wrote:
> This was cross-posted at https://vi.stackexchange.com/q/46614/10604

which is genuinely disrespectful because the thread goes on in another place.

Steven: the way I read you, the only thing you miss is 'ai (:h 'ai)

I have

set noet ai ci pi

which is enough to get the behavior you need (at least the way I read your post).
You can also add an insert mode mapping to indent when you double the final \:

command ArgIndent y | put | s!\v^\s+\zs(\S+\s+).*!\=repeat(' ',1+len(submatch(1)))!
inoremap \\<cr> <c-o>:ArgIndent<cr>

regards,
Marc

[Steven H.]

Thank you, Marc.

So, I removed the Smart Tabs plugin and added this to my .vimrc:

set listchars=eol:⏎,tab:>·,trail:-,space:␣,extends:>,precedes:<,nbsp:+
set ai

command ArgIndent y | put | s!\v^\s+\zs(\S+\s+).*!\=repeat(' ',1+len(submatch(1)))!
inoremap \\<cr> <c-o>:ArgIndent<cr>

Then I opened a BASH script an started typing:

#!/bin/bash⏎
⏎
f()⏎
{⏎
>·······something⏎
>·······another_thing⏎
⏎
>·······local␣one␣two␣three␣four␣\\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣five␣\\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣six⏎
⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣foo⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣bar⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣}⏎
>·······------------⏎

The only spaces I have typed manually are those before 'five'.
Everything else is just the result of pressing Enter.

As you see, 'foo' and 'bar' are not indented with just a tab (as they
should be) but align with 'six'.

Also, the closing brace of the function appears in some strange place,
instead of the first column. Pressing Enter after it does not send the
cursor to the first column, as it should.

The double backslash is somewhat laggy (and adds unnecessary characters).


I tried using the regular single backslash and the result is correct.
After pressing Enter after 'four', I had to delete the automatic second
tab and align with spaces, then everything worked correctly:

#!/bin/bash⏎
⏎
f()⏎
{⏎
>·······something⏎
>·······another_thing⏎
⏎
>·······local␣one␣two␣three␣four␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣five␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣six⏎
⏎
>·······foo⏎
>·······bar⏎
}⏎
⏎

However, when testing with the initial example I get this (again, I
manually delete the auto-inserted tabs and replace them with alignment):

#!/bin/bash⏎
⏎
f()⏎
{⏎
>·······local␣a=1␣\⏎
>·······␣␣␣␣␣␣b=2⏎
⏎
>·······cmd␣--option1␣"one"␣\⏎
>·······␣␣␣␣--option2␣"two"␣\⏎
>·······␣␣␣␣arg1␣\⏎
>·······␣␣␣␣arg2␣\⏎
>·······␣␣␣␣|␣cmd2␣--option3␣"three"␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣--option4␣"four"␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣arg3␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣arg4␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣arg5␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣|␣cmd3␣--option5␣"five"␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣--option6␣"six"␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣arg6␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣arg7⏎
>·······>·······␣␣}⏎
>·······>·······--⏎

Everything works fine till 'arg7'. Pressing Enter after it results in
misaligned closing brace and the Enter after the brace positions the
cursor incorrectly.


Is there a way to define such behaviour (pseudo code in layman terms):

if (Enter is pressed after a single backslash); then
go to new line
preserve the indentation and alignment of the previous line
add spaces to align to the second word in the previous line
# word: anything that is not white space
fi

How can I do this?

[Marc Chantreux]

Hi Steven,

answering the last question seems to be a good way to put all together
in a simpler way so let's back on your clever pseudocode, I'll add
comments on this.

Short anwser is:

* ArgIndent does exactly what your pseudocode expects
* you need *both* 'ci and 'ai to be turned on
* CTRL_D and CTRL_T is the way to increment/decrement manually
in insert mode. >> and << in normal mode.

Long anwser: inoremap \<cr> to ArgIndent does exactly what your
pseudocode want but in a different way

> if (Enter is pressed after a single backslash)

=> inoremap \<cr>

> preserve the indentation and alignment of the previous line

=> 'ai and 'ci must be set

> * go to new line
> * add spaces to align to the second word in the previous line

> # word: anything that is not white space

let's rewrite ArgIndent in vim9script and add comments

command -nargs=0 ArgIndent {
y | put # yyp in normal mode # stage 1

s!\v^\s+\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!
}

at the end of the stage 1, we have

this --example \
this --example \

and we want to remove 'this' which is a substitution from
this

\v^\s+\zs(\S+\s+).*

to this

\=repeat(' ', 1 + len(submatch(1)))

in details:

\v # use "perlish/extended" regexp syntax
^ # the begin of the line
\s+ # at least one space|tab|nbsp
\zs # start matching there
# so previous chars will remain untouched
(\S+\s+) # capture a word "\S+" and the spaces after "\s+"
. # then the rest of the line

so in
this --example \

* 'this' is the word (submatch(1))
* '--example \' is the rest of the line

so the matched section is 'this --example \' and we replace it by
as many spaces as chars in in the word + 1

1 + len(submatch(1))
=> 1 + len("this")
=> 1 + 4
=> 5

repeat(' ', 5 )
=> ' '

so

this --example \

becomes

--example \

don't hesitate to ask if I wasn't clear.

regards


--
Marc Chantreux
Pôle CESAR (Calcul et services avancés à la recherche)
Université de Strasbourg
14 rue René Descartes,
BP 80010, 67084 STRASBOURG CEDEX
03.68.85.60.79

[Steven H.]

Thank you.

OK, in my .vimrc I added:

set listchars=eol:⏎,tab:>·,trail:-,space:␣,extends:>,precedes:<,nbsp:+

set ai ci

command -nargs=0 ArgIndent {
y | put # yyp in normal mode # stage 1
s!\v^\s+\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!
}

Unfortunately it doesn't seem to work as expected:

#!/bin/bash⏎
⏎
this␣--example␣\⏎
>·······--example␣\⏎
>·······⏎

The correct result should be:

#!/bin/bash⏎
⏎
this␣--example␣\⏎
␣␣␣␣␣--example␣\⏎
-----⏎

Am I doing something wrong?

[Marc Chantreux]

On Fri, Mar 21, 2025 at 08:15:37AM -0000, Steven H. wrote:
>
> #!/bin/bash⏎
> ⏎
> this␣--example␣\⏎
> >·······--example␣\⏎
> >·······⏎
>
> The correct result should be:
>
> #!/bin/bash⏎
> ⏎
> this␣--example␣\⏎
> ␣␣␣␣␣--example␣\⏎
> -----⏎

thank you for:
* spotting this bug
* providing me a very interesting case of macro debugging for my vim training

> Am I doing something wrong?

nope! I'm the one who did because in

s!\v^\s+\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!

\v^\s+ means "at least one space at the begin of the line"
\v^\s* means "optional spaces at the begin of the line"

so you can fix the macro by yourself :)

regards

[Steven H.]

I changed the trail symbol for better visibility below.

This:

set listchars=eol:⏎,tab:>·,trail:▪,space:␣,extends:>,precedes:<,nbsp:+

set ai ci
command -nargs=0 ArgIndent {
y | put

s!\v^\s*\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!

}
inoremap \<cr> <c-o>:ArgIndent<cr>

gives me:

#!/bin/bash⏎
⏎
this␣--example▪⏎
␣␣␣␣␣--example▪▪⏎
␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣--example▪▪⏎
␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣--example▪▪⏎
▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪⏎

As you see, pressing Enter makes the backslash disappear. Also, as soon
as Enter is pressed, all 'this' and '--example' strings appear on a
different background (light gray in my case with 'colorscheme desert'
which I use).

Please advise how to fix it.
Thanks.

[Marc Chantreux]

> As you see, pressing Enter makes the backslash disappear. Also, as soon
> as Enter is pressed, all 'this' and '--example' strings appear on a
> different background (light gray in my case with 'colorscheme desert'
> which I use).
>
> Please advise how to fix it.

go from inoremap \<cr> <c-o>:ArgIndent<cr>
to inoremap \<cr> \<c-o>:ArgIndent<cr>

I also made some changes to leave/restore original values of @" and @/.
the final version is:

command -nargs=0 ArgIndent {
y y | put y
var s = @/

s!\v^\s*\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!

@/ = s

}
inoremap \<cr> \<c-o>:ArgIndent<cr>

> Thanks.

I thank you too: I never went to this level of detail and just used only
spaces. If it's ok for shell scripting, it can be anoying in C for
example so you came with the request but we both come with a solution
I'll reuse.

regards

--
Marc Chantreux

[Steven H.]

I am glad you find this mutually beneficial!

Here is the result with the latest changes you proposed:

#!/bin/bash⏎
⏎
this␣--something␣\⏎
>·······-anotherthing␣\⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣-third␣\▪⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣-andsoon⏎
⏎


#!/bin/bash⏎
⏎
this␣--example␣\⏎
␣␣␣␣␣--anotherthing␣\▪⏎
␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣--foo␣\⏎
␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣--bar␣\⏎
␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣--notalignedagain⏎
⏎

Still not aligning correctly according to the algorithm.
Have you tested it? Does it work for you?

[Marc Chantreux]

On Fri, Mar 21, 2025 at 07:24:29PM -0000, Steven H. wrote:
> Here is the result with the latest changes you proposed:

> #!/bin/bash⏎
> ⏎
> this␣--something␣\⏎
> >·······-anotherthing␣\⏎
> >·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣-third␣\▪⏎
> >·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣-andsoon

yes! that's because it fully complies the pseudocode we
agreed on and that's why I suggested the \\<cr> map in the
first place: if you come back to the

inoremap \\<cr>

you can type 2 \ to say "that's the beginin of an indent.so to have

this --is \
--a \
--good \
--example

you type

this --is \\
--a \
--good \
--example

this is one extra caracter. don't you think that's fair enough?

regards

Marc

[Anton Shepelev]

Steven H. to Anton Shepelev:

> > No, you do not need any plugins for that. I have been
> > indenting with tabs and alighning with spaces for years,
> > with just copyindent:
>
> How exactly do you do this? Could you please share your
> setup (relevant .vimrc lines)?

Beg pardon for the misinformation, folks. I had not used
Vim to program in tabs+spaces mode in a long time, and now I
see that I cannot make it respect my indentation and
alignment with any standard settings.

The correct action for indent/unindent should affect the
initial tab on the line, leaving intact whatever spaces may
occur furher to the right. Vim's < and > do not seem able to
do that by default. I don't understand why `preserveindent'
adds tabs /after/ my spaces, and wish Vim would support this
simply and natural indentation mechanism without custom
scripting.

[Gary Johnson]

I don't think it's obvious that using < or > should remove or add
white space at the beginning of the line. My mental model has
always been that the white space was deleted or inserted immediately
to the left of the first non-blank character in the line. That also
agrees with the Vim help description of those commands, which is to
shift lines leftwards or rightwards, not to decrease or increase the
indent.

Also see the description of 'shiftround'. There again the viewpoint
is of moving the first non-blank character rather than decreasing or
increasing the indentation.

Both viewpoints are useful.

I agree that adding tabs after spaces seems wrong, even considering
this note in ":help 'preserveindent'":

NOTE: When using ">>" multiple times the resulting indent is
a mix of tabs and spaces. You might not like this.

Regards,
Gary

[Marc Chantreux]

On Sat, Mar 22, 2025 at 01:10:22AM +0300, Anton Shepelev wrote:
> Beg pardon for the misinformation, folks.

You didn't:

* 'ci was indeed required to preserve the structure of
the indentation.
* SmartTab was indeed overkill for the job
* Steven pushed the thing further wich pushed me to try to solve the
problème which is cool

> do that by default. I don't understand why `preserveindent'
> adds tabs /after/ my spaces

same here. I really wonder if it's worth a patch because I see no
case were the current behavior could be interesting.

regards

[Steven H.]

On Fri, 21 Mar 2025 22:03:58 +0100 Marc Chantreux wrote:

> On Fri, Mar 21, 2025 at 07:24:29PM -0000, Steven H. wrote:
> > Here is the result with the latest changes you proposed:
>
> > #!/bin/bash⏎
> > ⏎
> > this␣--something␣\⏎
> > >·······-anotherthing␣\⏎
> > >·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣-third␣\▪⏎
> > >·······␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣-andsoon
>
> yes! that's because it fully complies the pseudocode we
> agreed on and that's why I suggested the \\<cr> map in the
> first place:

The algorithm is to preserve indentation and alignment of the previous line, then align with spaces to the second word of the previous line.

The result is not that: pressing Enter after a backslash inserts a
tab-indent.

> if you come back to the
>
> inoremap \\<cr>
>
> you can type 2 \ to say "that's the beginin of an indent.so to have
>

> [...]

> this is one extra caracter. don't you think that's fair enough?

Well, the whole point of arranging code nicely is to avoid clutter,
thus improving readability. Adding unnecessary characters not only
adds clutter, but also results in erroneous code, because '\' is also
used for escaping. Example:

#!bin/bash

grep --extended-regexp \\
--only-matching \
-- \
'a' \
<<< 'abc'

Running that results in:

grep: Trailing backslash
example: line 5: --only-matching: command not found

So, double backslashes are problematic.

P.S. Speaking of duplication: I don't know why but I always receive
each of your messages twice. :)

[Steven H.]

Marc,

I think some correction of the implementation of the algorithm may be
necessary, otherwise editing existing code does not auto-align next
line.

Perhaps:

> if (Enter is pressed after a single backslash); then

^^ Currently that condition is checked through be the key mapping of
'\<cr>' but when editing existing code, pressing Enter after an
*existing* backslash does not run your function.

I don't know if it is possible to map the function to '<cr>', then
(considering how it currently works by copying the line) make it:

> go to new line

> preserve the indentation and alignment of the previous line

delete trailing backslash

> add spaces to align to the second word in the previous line
> # word: anything that is not white space

> fi

What do you think?

On Sat, 22 Mar 2025 06:35:08 -0000 Steven H. wrote:

> P.S. Speaking of duplication: I don't know why but I always receive
> each of your messages twice. :)

I think the reason is that (I see that in your messages only):

To: vim...@googlegroups.com
Cc: v...@vim.org

[Steven H.]

Marc,

If checking for trailing backslash is difficult, here is a simpler idea:

go to new line

preserve the indentation and alignment of the previous line

if (there is a second word in the previous line)

add spaces to align to the second word in the previous line

fi

# word: anything that is not white space

Map all that to Ctrl+Enter (or Shift+Enter).

Is that possible?

[Marc Chantreux]

hello,

On Sat, Mar 22, 2025 at 04:24:16PM -0000, Steven H. wrote:
> If checking for trailing backslash is difficult, here is a simpler idea:

this isn't difficult: it's useless the way the macro actually works.

to be sure we're talking about the same thing: my last proposal was:

vim9script
set ai ci noet

command -nargs=0 ArgIndent {
y y | put y
var s = @/
s!\v^\s*\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!
@/ = s
}

so when i write

this --example \\<cr>--works \<cr>--fine

I got

this --example \
--works \
--fine

which is what you ask if we forget the fact (and to me it's
a feature, not a bug) that you indent just by doubling the \
(which respect the huffman principle: most used is shorter).

> Map all that to Ctrl+Enter (or Shift+Enter).
> Is that possible?

AFAIK no because all of them act the same (^M)
maybe I'm wrong but I'll not investigate this point.

regards

--
Marc Chantreux

[Steven H.]

This:

set listchars=eol:⏎,tab:>·,trail:▪,space:␣,extends:>,precedes:<,nbsp:+

set ai ci noet
command -nargs=0 ArgIndent {
y y | put y
var s = @/
s!\v^\s*\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!
@/ = s
}

inoremap \<cr> \<c-o>:ArgIndent<cr>

and typing your example gives me:


this␣--example␣\\⏎
--works␣\⏎
␣␣␣␣␣␣␣␣--fine▪⏎


However, if I type the '\\<cr>' fast, I get this:


this␣--example␣\\⏎
␣␣␣␣␣--works␣\▪⏎
␣␣␣␣␣␣␣␣␣␣␣␣␣--fine▪⏎


I wonder why it works for you and not for me.

I am running VIM on Debian 12:


$ vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Feb 16 2025 05:23:41)
Included patches: 1-1378, 1499, 1532, 1848, 1858, 1873, 1969, 2142
Modified by team...@tracker.debian.org
Compiled by team...@tracker.debian.org
...

[Marc Chantreux]

hello,

On Mon, Mar 24, 2025 at 09:39:54AM -0000, Steven H. wrote:
> set listchars=eol:⏎,tab:>·,trail:▪,space:␣,extends:>,precedes:<,nbsp:+
> set ai ci noet
> command -nargs=0 ArgIndent {
> y y | put y
> var s = @/
> s!\v^\s*\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!
> @/ = s
> }
> inoremap \<cr> \<c-o>:ArgIndent<cr>
>
>
> and typing your example gives me:
>
> this␣--example␣\\⏎
> --works␣\⏎
> ␣␣␣␣␣␣␣␣--fine▪⏎
>
> However, if I type the '\\<cr>' fast, I get this:
>
>
> this␣--example␣\\⏎
> ␣␣␣␣␣--works␣\▪⏎
> ␣␣␣␣␣␣␣␣␣␣␣␣␣--fine▪⏎
>
> I wonder why it works for you and not for me.

well … I remember something about a mapping timout but I have to admit
I just don't know anymore.

regards

--
Marc Chantreux

[Steven H.]

What about the rest? I mean - the output is incorrect in both cases.

Slow typing: unaligned.
Fast typing: trailing whitespace.

[Anton Shepelev]

Marc Chantreux:

> same here. I really wonder if it's worth a patch because I
> see no case were the current behavior could be
> interesting.

IMHO, it is certainly worth a patch. The safest and
cleanest operation of < and > with `preserveindent' is to
add/remove tabs/spaces (depending on expandtab) strictly
at the beginning of a line, leaving the rest of it intact.
If I typed it, I need it that way. Otherwise, let me
handle my own errors, instead of silently changing the
not-readily-visible structure of my horisontal whitepace.
This is matter of peace of mind and non-intrusion.

[Steven H.]

I don't know if that is related but when I have this situation:

>·······>·······one␣two␣three␣\⏎
>·······>·······␣␣␣␣␣␣␣␣four⏎
hello⏎

and the cursor is on the 'hello' in normal mode, and I press '==', I get:

>·······>·······one␣two␣three␣\⏎
>·······>·······␣␣␣␣␣␣␣␣four⏎
>·······>·······>·······>·······>·······hello⏎

which is wrong because 'hello' must have the same indentation as 'one.

[Marc Chantreux]

On Mon, Mar 24, 2025 at 10:56:05AM -0000, Steven H. wrote:
> What about the rest? I mean - the output is incorrect in both cases.

I was trying to reply with the timeout thing:

I typed

this --example \\
--helps \
--you

and got

this --example \
--helps \
--you

I tried other bugs you previously spotted and everything works like a
charm here (and I finally started using it for myself).

as your answer suggested that the mappings were not even executed. I see
3 possible reasons:

* maybe you enabled 'paste
:set nopaste
* maybe you didn't reach the end of the macro before the timeout.
(I don't remember how to fix it)
* maybe you didn't load the mapping at all
:imap \\<cr> # should echo you the content of the mapping

--
Marc Chantreux

[Steven H.]

On Mon, 24 Mar 2025 20:53:47 +0100 Marc Chantreux wrote:

> I tried other bugs you previously spotted and everything works like a
> charm here (and I finally started using it for myself).

Are you using my .vimrc which I provided initially? Or a different one?
If it is a different one, could you please share it? (or at least the
relevant lines which apply to the current discussion). Also what VIM
version are you using?

[Marc Chantreux]

hello,

On Tue, Mar 25, 2025 at 09:03:48AM -0000, Steven H. wrote:
> Are you using my .vimrc which I provided initially?

no because

* I didn't understand that was your actual and entire .vimrc
* I expected from you to read instructions and ask when you didn't
know (that's how learing works). especially:
* I mention this is a vim9script and put the keyword in some examples
* I told you you should get back to the original mapping

I copied the whole thing in ~/stevenrc:

vim9script

set listchars=eol:⏎,tab:>·,trail:▪,space:␣,extends:>,precedes:<,nbsp:+
set ai ci noet
command -nargs=0 ArgIndent {
y y | put y
var s = @/
s!\v^\s*\zs(\S+\s+).*!\=repeat(' ', 1 + len(submatch(1)))!
@/ = s
}
inoremap \\<cr> \<c-o>:ArgIndent<cr>

then invoked vim -u ~/stevenrc

and it works.

> If it is a different one, could you please share it?

I'm in the middle of the process of publication of my dotiles. you can
pick some files here:

https://git.unistra.fr/mc/dot/-/tree/main/vim/

the best of all is already there:

https://git.unistra.fr/mc/dot/-/blob/main/vim/r/parentheses.vim
https://git.unistra.fr/mc/dot/-/blob/main/vim/r/buffer_navigation.vim

I wrote the first version of those in the '90 and will never turn back.

--
Marc Chantreux

[Steven H.]

Thank you! I think it works now.

[Marc Chantreux]

On Tue, Mar 25, 2025 at 12:18:01PM -0000, Steven H. wrote:
> Thank you! I think it works now.

Cool! this way you have something much simpler than the smarttabs
plugin and you learned stuff in the process.

that's what vim once was and should remain and that's the reason I
really neovim as a very sad thing that happenned to our community.

regards

--
Marc Chantreux

[Steven H.]

Marc,

Is it possible to fix this when editing existing code.

Say, we start with:

this␣--one␣--two␣--three⏎

and the cursor is on the space right after '--one'.

Type <Space>\\<Enter> (thus running your function). The result is:

this␣--one␣\␣--two⏎
▪▪▪▪▪▪⏎

but it would be good to have it as:

this␣--one␣\⏎
␣␣␣␣␣--two⏎

Is there a way to do this?

[Marc Chantreux]

Steven,

On Tue, Mar 25, 2025 at 04:14:16PM -0000, Steven H. wrote:
> Say, we start with:
>
> this␣--one␣--two␣--three⏎
>
> and the cursor is on the space right after '--one'.

Indeed an interesting question! I had use a new approach to do that

regards


vim9script

# We want to travel from this
#
# 1 2 3 4
# ( I W B ) # E
#
# to this
#
# 1 \r
# I w E
#
# I(dent) W(ord, the 1st one and its trailing space)
# B(egin) and E(nd) of the content split by the
# #(cursor) so the capture here is:
# w is the result of repeat(' ', len(W))
#
# KNOWN BUG:
# * at least one space is required at the end of line.
# (TODO fix with an alternative? like %#$?)
# NOTE:
# * If you want ArgIndentRhs to stay generic, all extra chars
# like \\ should be appended from the imap

var ArgIndentRhs = () => submatch(1) .. "\r"
.. submatch(2)
.. repeat(' ', len(submatch(3)))
.. submatch(4)

command -nargs=0 ArgIndent s!\v^((\s*)(\S+\s*).*%#)(.*)!\=ArgIndentRhs()!

inoremap \\<cr> \<c-o>:ArgIndent<cr>

set ai ci noet


--
Marc Chantreux

[BPJ]

The relevant options are

-  'timeout'

-  'ttimeout'

-  'timeoutlen'

-  'ttimeoutlen'

and you can/may need to tweak any or all of them. I have set them up so as to allow rather slow typing, especially when typing multi-key commands, which suits me because of my disability.

/bpj

regards

--
Marc Chantreux

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/Z-Eranw0GHR65W7n%40prometheus.

[Marc Chantreux]

Hi,

On Wed, Mar 26, 2025 at 12:29:54PM +0100, BPJ wrote:
> Den mån 24 mars 2025 10:53Marc Chantreux <m...@unistra.fr> skrev:

> The relevant options are
>
> -  'timeout'
> -  'ttimeout'
> -  'timeoutlen'
> -  'ttimeoutlen'
>
> and you can/may need to tweak any or all of them. I have set them up so as to
> allow rather slow typing, especially when typing multi-key commands, which
> suits me because of my disability.

thanks for helping. it happened that timeout wasn't involved at all but
I'm keep this message close so I can take a look for my own usage.

regards


--
Marc Chantreux

[Paolo Bolzoni]

On Tue, 25 Mar 2025 at 12:37, Marc Chantreux <m...@unistra.fr> wrote:
> that's what vim once was and should remain and that's the reason I
> really neovim as a very sad thing that happenned to our community.

Can you elaborate? I always thought that in addition of its age,
projects like neovim the proof how the vim idea is good.

Cheers,
Paolo

[Marc Chantreux]

hello Paolo,

On Thu, Mar 27, 2025 at 03:01:54AM +0000, Paolo Bolzoni wrote:
> On Tue, 25 Mar 2025 at 12:37, Marc Chantreux <m...@unistra.fr> wrote:

> > Cool! this way you have something much simpler than the smarttabs
> > plugin and you learned stuff in the process.
> >

> > that's what vim once was and should remain and that's the reason I

> > really see neovim as a very sad thing that happenned to our community.

>
> Can you elaborate? I always thought that in addition of its age,
> projects like neovim the proof how the vim idea is good.

I wish I had time to elaborate right now but I don't (I will at some point
because I more or less promise a talk at a local tech conference). But
let's try to pitch it a very concise way.

As introduction, I have to say I love the unix and convivialist
cultures: we help each others to make things possible with the most
simple, clean and maintainable way so we could share, explain, maintain,
drop easily.

* I started using vi (vim among other implementations) in the 90. At
this time it wasn't clear to me wich one was the best because I was
learning the very basics anyway. What hooked me is the way vi was
concise and consistent, yet powerful. For that and because it was
considered as "the default unix editor" at the time, I chose vi
then vim over emacs.
* When I started to master the basics, I became exigeant so I started to
tweak my .vimrc more and more. I asked so many questions on this list
and the irc channel and I realized two things that helped me to be so
confortable not only with vim but with the whole unix system as an
IDE: vi was just a visual ed so:
* so the langage you use to extend is the one you use every day.
* the concepts you use are available in unix at large including the
regexp, substitution syntax, pipes and filters
(https://github.com/eiro/talk-acme-changed-my-life).
then you realize sed works the same, then you realize that awk is a
verbose sed with line split and math, then you realize sometimes
you need both together + more "scripting langages" abilities and you
discover perl, then you discover perl regexps and PCRE and you
realize that regexps are so much more than what you previously
thought and you "nnoremap / /\v" (discovering \M in the process).
you *can't* waste your time trying to tune something this way
because you just practice the vim as a window to an amazing world
with a very rich culture
See https://git.unistra.fr/mc/dot/-/blob/main/vim/r/buffer_navigation.vim
* the first line is something I wrote once and forget forever
* all the others are made of things I use all the time

Of course, it is also a social journey: meet people, share about
problems and Ideas …

I wasn't aware of how vim will be the key to the whole unix culture when
I started my journey and I really think neovim put a distance to this
world using lua as default langage and insisting on plugins.

neovim users are actually emacs+viper users that are ignoring
themselves (and most of the time terrible vim users). there was no point
to split a community, its plugin ecosystem, its support effort,
its culture (to be honnest: yes, at some point there
were one good reason: async which only was added in vim8 but nowadays
I chat with many neovim users but none of them were able to show me
*one* thing I can envy mostly because vim already does it another way).

I'm really sorry I have no time to push more details and examples here
and I'll come back here to share more materials when it will be ready.

regards

--
Marc Chantreux
Pôle CESAR (Calcul et services avancés à la recherche)
Université de Strasbourg
14 rue René Descartes,
BP 80010, 67084 STRASBOURG CEDEX
03.68.85.60.79

[Steven H.]

Thanks. This is what I get when I type 'asdf asdf asdf \\<Enter>"


asdf␣asdf␣asdf▪⏎
␣␣␣␣␣\⏎


and if I continue typing on the second line, that line gets highlighted
with a different background.

This:


one␣two␣three␣four⏎


and placing the cursor on 'f' gives:


one␣two␣three␣\⏎

␣␣␣␣four⏎


however when I try 'u'(ndo) the restored initial line is also
highlighted.

Question:

On Wed, 26 Mar 2025 11:18:46 +0100 Marc Chantreux wrote:

> vim9script

This seems necessary, otherwise vim complains about the new code.
However, vim requires it to be the first line in .vimrc.

Since I am not experienced, I don't know how (or if) that would affect
the rest of my .vimrc. So, what is correct the way to do it? I.e. how
do I make sure the rest of my .vimrc will work if I place it on the
first line?

[Marc Chantreux]

On Thu, Mar 27, 2025 at 08:36:28AM -0000, Steven H. wrote:
> and if I continue typing on the second line, that line gets highlighted
> with a different background.

because hlsearch is on which is a good thing. update:

command -nargs=0 ArgIndent {
var s = @/

s!\v^((\s*)(\S+\s*).*%#)(.*)!\=ArgIndentRhs()!

@/ = s

}
inoremap \\<cr> \<c-o>:ArgIndent<cr>
set ai ci noet

> and placing the cursor on 'f' gives:

> one␣two␣three␣\⏎
>
> ␣␣␣␣four⏎

here I have

one two three f\
our

which works as expected. And for now your output makes no sense to me.
I'll came back on it later.

regards.

--
Marc Chantreux

[Igbanam Ogbuluijah]

There was once I was on the Neovim bandwagon; because I had some difficulty getting started with Vimscript before Vim 9. When Vim 9 came with vim9script, it no longer made sense to invest in Lua as a language to script the editor.

I can empathize with people who lean into Neovim. I am only eight years into my Vim journey. There's a certain passion and curiosity required to main a thing; in this case, "to being a Vim-main", or a "purist" in certain terms. That passion and curiosity is less prevalent these days because the industry has created many comfort™ abstractions to aid the engineer / developer in getting work done. I see these comfort abstractions in your journey through sed, awk, scripting, and beyond; with the next thing incrementally expanding affordance, by somewhat abstracting away the complexity of its predecessor. It's in this same light that Neovim's popularity has taken flight. However Vim and Neovim aren't as static as the unix tools. The boon of opensource software is democratization; its bane is fragmentation (in product, and in community).

I see plugins as training wheels. Over time, I've realized I need less of them. But in a world fraught with so much GUI apps, that blank screen Vim starts with is daunting to the today engineer / developer. This, I think, is the allure for plugins: to get the blank workable without investing much time in reading the Vim docs. Another pattern emerging in recent years which, I think, is an extension to plugins-culture is the so-called "distros": AstroVim, LazyVim, SpaceVim, and so on. All these are along the line of making adoption easier. — something in my mind is telling me this adoption is also the reason for Evil and Viper in Emacs; but I wouldn't know cos I haven't used Emacs. — Once adopted, an advanced user would seek optimizations in the editor. At that point, most of these training wheels usually fall off naturally.

I wouldn't say Neovim as a sad thing per se; but there sure is a sadness. The sadness is that there is so much abstraction now that it seems we're abstracting away the thing itself. So new Vim users have less of a chance of being Vim users, they're further removed from the Unix philosophy. On one hand (the developer's hand), this is amazing because the barrier of entry is reduced. On one hand (the community's hand), this is preferred because adoption increases. On one hand (the culture's hand), this is scary cos this is an evolution which may leave the original culture behind.

I'm keen to hear your thoughts when you develop it more. Also, when you give / publish that talk, please remember to share on this thread as well. Thank you!

Igbanam

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vim_use/Z-ULoGHHTFj-HNOm%40prometheus.

[Marc Chantreux]

Hi Igbanam and thanks for sharing,

On Thu, Mar 27, 2025 at 09:59:09AM +0000, Igbanam Ogbuluijah wrote:
> I'm keen to hear your thoughts when you develop it more. Also, when you give /
> publish that talk, please remember to share on this thread as well. Thank you!

which can be enriched by more testimonials. For example:

* I would be really happy to know at least one thing you can't do in vim9
* even I really don't like the vim9script syntax, I saw the improvements
(and understood it was a matter of efficiency) but cool stuff like
lambdas, hashes and lists were in vim since 8.0. I never realized viml
was so problematic.
* Did you (ask for|help) help from the community to level up?

regards

marc

--
Marc Chantreux

[Igbanam Ogbuluijah]

Sure thing, Marc.

I run into things I can't do in Vim 9 during Advent of Code; but I realize I am using the language for something it was not built for primarily, so I don't raise too many issues. The issues I raise are mainly bugs, and the Vim team is quick in getting these fixed.

Some plugins make quality of life better; mostly interfacing with tooling outside the editor. Off the top of my head…

• vim-test/vim-test is a good abstraction on testing anything in the editor
• puremourning/vimspector allows me debug with a familiar interface
• tpope/fugitive has replaced how I use Git, alongside git-gutter and friends
• vim-airline/vim-airline supercharges :h 'statusline',
• preservim/nerdtree + webdevicons is the :Ex I didn't know I needed, and
• I've become rather dependent on welle/targets for working with text objects

The community has always helped leveling up. By the time I got confident enough to be active in the community, Vim 9 was out with a more relatable syntax.

Igbanam

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vim_use/Z-Ux-piDsDJg-t_W%40prometheus.

[Riza Dindir]

Hello All,

I can not say neovim is a bad thing. I do not have bad feelings towards emacs, neovim or other editors. These are just tools. I happen to like vim and am using it continuously for development. I tried neovim, but the pipe command (!) did not work as expected. I do think vi/vim's way of being able to run filters via pipes is awesome. I use fzf in vim and, as I remember, I could not get this to run with my macros.

I started using vi (elvis, then vim) in the late 90's. What I do like is the regexp (which I used to convert or process lines, csv files, etc), and pipes and filters. Pipes and filters basically do open up the door to writing extensions in any language (python, C, bash, ...). It is maybe restricting, but it is the one feature that struck me when I started out. ! commands also make it easy for me to run commands from within vim.

Acme editor is something that I am fond of too, but have no use for, since I am not on Plan9. But having text and being able to run that text is nice. There are ports of acme, but vim is sufficient for all my development, and editing requirements.

The video that Mark Chantreux has given a link to is really helpful and nice. Thank you for the link.

Regards

Riza Dindir

[Steven H.]

On Thu, 27 Mar 2025 09:53:42 +0100 Marc Chantreux wrote:

> I'll came back on it later.

I appreciate that and look forward to it.

[Marc Chantreux]

hello Steven,

On Thu, Mar 27, 2025 at 02:52:18PM -0000, Steven H. wrote:
> On Thu, 27 Mar 2025 09:53:42 +0100 Marc Chantreux wrote:

> > I'll come back on it later.

> I appreciate that and look forward to it.

As far as I know vim, I'm pretty sure that the unexpected line
in the middle of the result of the substitution is related to
something else. before investing it, can you test a very minimal
alternative vimrc file like this:

vim9script

var ArgIndentRhs = () => submatch(1) .. "\r"
.. submatch(2)
.. repeat(' ', len(submatch(3)))
.. submatch(4)

command -nargs=0 ArgIndent {
var s = @/
s!\v^((\s*)(\S+\s*).*%#)(.*)!\=ArgIndentRhs()!
@/ = s
}
inoremap \\<cr> \<c-o>:ArgIndent<cr>
set ai ci noet

to do so:
* save this content in, say, ~/stevendebugrc
* open vim with -u ~/stevendebugrc

regards

--
Marc Chantreux

[Marc Chantreux]

hi Igbanam,

I'm pretty sure those are useless or conterproductive for me
(because of my DIY attitude):

> • vim-test/vim-test is a good abstraction on testing anything in the editor

* sometimes it's not as easy as "just start prove"
* sometimes I run test from another tmux split
* sometimes 1 want to run only some test files with some env variables
* ...

so I just use 'mp to run the tests:

https://git.unistra.fr/mc/dot/-/blob/main/vim/r/cmd_makeprg.vim

> • vim-airline/vim-airline supercharges :h 'statusline',

I personnally use the dwm bar so I don't waste lines for my code :)

https://git.unistra.fr/mc/dot/-/blob/main/vim/r/dwm.vim

and use different cursor colors instead of showmode

https://git.unistra.fr/mc/dot/-/blob/main/vim/r/colors.vim?ref_type=heads#L16

> • preservim/nerdtree + webdevicons is the :Ex I didn't know I needed

I use arrows to do really fast buffer navigation

https://git.unistra.fr/mc/dot/-/blob/main/vim/r/buffer_navigation.vim

and to navigate in files, I use many vim things like ctags, gF , path+=**

In my .zshenv, I have:

n () grep -Hn "$@"

it's really convenient to combine gF +

:r!n -RF functionname

want to navigate in files provided by a debian pacakge?

:r!dpkg -L mypackage

and here we go.

On Thu, Mar 27, 2025 at 11:46:08AM +0000, Igbanam Ogbuluijah wrote:
> • puremourning/vimspector allows me debug with a familiar interface

I wish I had those tools when I started. now I'm cool with cli debuggers
so termdebug LGTM.

> • tpope/fugitive has replaced how I use Git, alongside git-gutter and friends

same here!!!

:Gcommit|Gwrite

never goes away from my history. git gutter is awesome too.

> • I've become rather dependent on welle/targets for working with text objects

I'm not sure I need it but I will at least test it. thank you for
sharing.

> The community has always helped leveling up. By the time I got confident enough
> to be active in the community, Vim 9 was out with a more relatable syntax.

this is weird people remaining silent when they need help the most.

regards.

marc

[Marc Chantreux]

On Thu, Mar 27, 2025 at 05:28:47PM +0300, Riza Dindir wrote:
> I can not say neovim is a bad thing. I do not have bad feelings towards emacs,

emacs is great if you're found of their point of view (I'm not but I
fully understand). I really think *neovim* is a bad thing in a long run
because it's just vim incompatible with vim because of bad decisions
(Or please someone prove me wrong by showing me at least 1 thing worth
enough to split the community into 2 separated things which is the
most notable change neovim came with).

> Acme editor is something that I am fond of too, but have no use for, since I am
> not on Plan9. But having text and being able to run that text is nice. There
> are ports of acme, but vim is sufficient for all my development, and editing
> requirements.

same here: I love the idea but I'm so used to vim and I really think
mouse gestures doesn't compete a 105 bullets machine gun magazine.

> The video that Mark Chantreux has given a link to is really helpful and nice.
> Thank you for the link.

glad you liked! thanks for this feedback. An improved version (then a
french one) is scheduled too.

regards.

--
Marc Chantreux

[Steven H.]

Thanks Marc.

Doing what you suggested and it seems to work correctly. However, there
is something new that is weird: while in 'Insert' mode, pressing arrow
keys results in typing letters:

Up -> 'A'
Down -> 'B'
Right -> 'C'
Left -> 'D'

and after each letter is typed, a <CR> is inserted too.

[Steven H.]

<Home> -> 'H'
<End> -> 'F'

[Marc Chantreux]

On Sat, Mar 29, 2025 at 05:10:42PM -0000, Steven H. wrote:
> Doing what you suggested and it seems to work correctly. However, there
> is something new that is weird: while in 'Insert' mode, pressing arrow
> keys results in typing letters

something in the process removed the CSI (https://en.wikipedia.org/wiki/ANSI_escape_code).
I have no clue what's going on for the moment.

this happens only using the mapping?

regards

[Steven H.]

On Sat, 29 Mar 2025 20:31:40 +0100 Marc Chantreux wrote:

> this happens only using the mapping?

It seems to happen even with a completely empty stevendebugrc, e.g.

vim -u /dev/null

[Marc Chantreux]

On Sun, Mar 30, 2025 at 06:19:22AM -0000, Steven H. wrote:
> It seems to happen even with a completely empty stevendebugrc, e.g.
> vim -u /dev/null

OK. please consider using a new thread to ask the community about this.
I have no idea what's going on and maybe your terminal is involved.

the problem is: vim seems to remove the CSI.

You can also mention the main goal (maybe there was a simpler way):
* say a macro works for me and not for you
* how to get the minimal setting we can agree about

Aside: that's why my ~/.vimrc looks like this so I can
easily spot the problematic parts:

regards

vim9script
run r/defaults.vim
run r/colors.vim

run r/sublime.vim
nnoremap <c-p> :SublimeCtrlP<cr>
run ftplugin/man.vim
nnoremap <expr> K
\ &kp == "man" ? ":Man \<cword>\<cr>"
\ : &kp == ":help" ? "K"
\ : ":KP\<cr>"
run r/iab.vim
run r/ezfold.vim
run r/math.vim
run r/buffer_navigation.vim
run r/setvts.vim
run r/parentheses.vim
run r/cmd_makeprg.vim
set aw ar
nnoremap <c-s> :make!<cr>
imap <c-s> <c-o><c-s>
run r/mail-to.vim | noremap <space>t :To<cr>
run r/was_fzy.vim
run r/dwm.vim

[Steven H.]

Thanks.
I will try harder to find the reason first.

[D. Ben Knoble]

On Sun, Mar 30, 2025 at 3:05 AM Marc Chantreux <m...@unistra.fr> wrote:
>
> Aside: that's why my ~/.vimrc looks like this so I can
> easily spot the problematic parts:

I also frequently point folks towards [How to debug my
vimrc](https://vi.stackexchange.com/q/2003/10604) and [How to debug a
mapping](https://vi.stackexchange.com/q/7722/10604).

> vim9script
> run r/defaults.vim
> run r/colors.vim
>
> run r/sublime.vim
> nnoremap <c-p> :SublimeCtrlP<cr>
> run ftplugin/man.vim
> nnoremap <expr> K
> \ &kp == "man" ? ":Man \<cword>\<cr>"
> \ : &kp == ":help" ? "K"
> \ : ":KP\<cr>"
> run r/iab.vim
> run r/ezfold.vim
> run r/math.vim
> run r/buffer_navigation.vim
> run r/setvts.vim
> run r/parentheses.vim
> run r/cmd_makeprg.vim
> set aw ar
> nnoremap <c-s> :make!<cr>
> imap <c-s> <c-o><c-s>
> run r/mail-to.vim | noremap <space>t :To<cr>
> run r/was_fzy.vim
> run r/dwm.vim

What an interesting structure. Have you considered using
`~/.vim/plugin` to have these load automatically? (You could control
the order using sorted names, I believe.)

--
D. Ben Knoble

[Marc Chantreux]

hello,

On Sun, Mar 30, 2025 at 10:41:59AM -0400, D. Ben Knoble wrote:
> > Aside: that's why my ~/.vimrc looks like this so I can
> > easily spot the problematic parts:
>
> I also frequently point folks towards [How to debug my
> vimrc](https://vi.stackexchange.com/q/2003/10604) and [How to debug a
> mapping](https://vi.stackexchange.com/q/7722/10604).

thanks for this pointer. so sad those questions arise in stack* as we have a
user mailing list.

this was the way I started back in the 90's because it was the
idiomatic way. also when packs came around, I had a most of the stuff
in ~/.vim/pack/*/start.

Nowadays, the only things I kepts in ~/.vim/pack/*/start are the
ftplugins and every addition comes as late as possible.

as example

┌─ /home/mc/.vim/after/ftplugin/python.vim ───
│ vim9script
│ set noet
│ packadd indent-object
│ run indent/python.vim
│ packadd lsp
│ call LspAddServer([{
│ name: 'python',
│ filetype: ['python'],
│ path: 'pylsp',
│ args: [],
│ syncInit: true,
│ }])
│
│ inoremap <buffer> (fn def :<cr>……<cr>return ……<esc>2k$i
│ inoremap <buffer> (wh while :<cr>……<esc>k$i
│ inoremap <buffer> (wi with :<cr>……<esc>k$i
│ inoremap <buffer> (aw async with :<cr>……<esc>k$i
│ inoremap <buffer> (if if :<cr>……<esc>k$i
│ inoremap <buffer> (ie if :<cr>……<cr>else:<cr>……<esc>3k$i
│ inoremap <buffer> (fo for X in …… :<cr>……<esc>k^fXs
│ inoremap <buffer> (af async for X in …… :<cr>……<esc>k^fXs
│

when I start to chase a bug, comment all the ~/.vimrc lines
and decomment it line by line.

in the process, I have

inoremap <c-s>:w\|!tmux split vim /tmp/test<cr>

so I can easily see what changed.

regards

--
Marc Chantreux

[BPJ]

Den sön 30 mars 2025 21:53Marc Chantreux <m...@unistra.fr> skrev:

hello,

On Sun, Mar 30, 2025 at 10:41:59AM -0400, D. Ben Knoble wrote:
> > Aside: that's why my ~/.vimrc looks like this so I can
> > easily spot the problematic parts:
>
> I also frequently point folks towards [How to debug my
> vimrc](https://vi.stackexchange.com/q/2003/10604) and [How to debug a
> mapping](https://vi.stackexchange.com/q/7722/10604).

thanks for this pointer. so sad those questions arise in stack* as we have a
user mailing list.

I keep meaning to clean up my .vimrc my ~/.vim/after and my ~/.vim/autoload/bpj/, or at least comment them properly. In practice I just add everything at the bottom or near the top, depending on which works most like intended. The exception is my "text cleanup" function, the various commands which use that function and their config tables where I keep making those tables bigger and more numerous![1]

[1]: An uggly hack really: basically the function takes a possibly empty string of letters and a list of lists where each sublist has three items: an "id" letter which is uppercase for on by default and lowercase for off by default, a string with an ex statement — almost always an `%s///gce` of some complexity and a "description". For example

    ['I', '%s/\v⟮(\_.{-})⟯/_\1_/gce', '⟮...⟯ → _..._']

    or

    ['C', '%s/\v⌈(\_.{-})⌉/\L[\1]{.smallcaps}/gce', '⌈...⌉ → lc .smallcaps']

    or

    ['C', '%s/\v^\s*\zs%(local\s+)?_\s*=\s*\ze\[\=*\[/--/ce', 'void long string to comment']

    (Where ⟮⟯ is a pair of Unicode brackets. Don't ask what I need this for when I have Pandoc!)

    Each command passes its optional argument on to the function as the string of letters for turning an item on/off, whereafter the function executes each enabled item. A bit silly but beats typing all those substitutions every time. I try to keep the choice of letters mnemonic, but when all else files the function 'prints out' some or all lines of the table to a temporary buffer in a new window if it gets a non-empty third argument, which it does if the command was called with a bang. That's how I waste my time...

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vim_use/Z-mhAKeSOEEv9NQI%40prometheus.

[D. Ben Knoble]

On Sun, Mar 30, 2025 at 3:52 PM Marc Chantreux <m...@unistra.fr> wrote:
>
> hello,
>
> On Sun, Mar 30, 2025 at 10:41:59AM -0400, D. Ben Knoble wrote:
> > > Aside: that's why my ~/.vimrc looks like this so I can
> > > easily spot the problematic parts:
> >
> > I also frequently point folks towards [How to debug my
> > vimrc](https://vi.stackexchange.com/q/2003/10604) and [How to debug a
> > mapping](https://vi.stackexchange.com/q/7722/10604).
>
> thanks for this pointer. so sad those questions arise in stack* as we have a
> user mailing list.

I'm sorry to hear you feel that way; the goal of the StackExchange
project was to create a commons of high-quality resources (much like
Wikipedia has). I think the linked examples are good examples of this
(though if you visit the home page you will find more sand than pearls
these days, at the cost of having helped a great number of people).

Mailing lists are great, and they serve a different purpose for me
(cf. the recent extended discussion which might ultimately be boiled
down to a high-quality Q&A pair if desired).

Cheers,
Ben

[Marc Chantreux]

I Ben and thanks for sharing this feeling,

On Mon, Mar 31, 2025 at 08:24:16PM -0400, D. Ben Knoble wrote:
> > thanks for this pointer. so sad those questions arise in stack* as we have a
> > user mailing list.
>
> I'm sorry to hear you feel that way; the goal of the StackExchange
> project was to create a commons of high-quality resources (much like
> Wikipedia has).

Wikipedia came out to fill the gap of collaborative places to edit
articles.

StackExchange just split communities because previous tools (mailing
lists, newsgroups, archives and FAQ) were so much more convenient but
in the early years of this millenium, lot of people came to internet
with no idea of habits and customs of the technical communities.

If it was ignorance, that's very sad. If not, I'll be happy to learn
abou arguments that was worth splitting communities.

> I think the linked examples are good examples of this
> (though if you visit the home page you will find more sand than pearls
> these days, at the cost of having helped a great number of people).

Did you try newsgroups or mail archives? did you enjoy having your own
local workflow with mbox mirrors indexed so you can use mutt of
maildir-utils to query them, add copies of posts or threads in your
notes and things like that?

StackExchange will never reach this level of convenience. Not to mention
it's so painful to have a decent conversation through html text ereas.
especilly for vim or emacs users.

I don't know if StackExchange has an API (I'll be happy to learn about
it) so I can include it in my workflow but nevertheless: It's extra work
for same result :(

> Mailing lists are great, and they serve a different purpose for me
> (cf. the recent extended discussion which might ultimately be boiled
> down to a high-quality Q&A pair if desired).

So how do you set the cursor between mailing lists and StackExchange?

We all know the story of questions that looks insignifiant at start
being the root of a giant threads with very interesting perspectives.

Another point against StackExchange: those kind of threads are so
painful to follow in a web page.

I couldn't imagine that people could be found of StackExchange
so I'm really grateful you shared about it.

regards.

--
Marc Chantreux

[Eric Marceau]

Without wanting to continue participating in this topic's interchange of points/arguments, beyond this contribution, I just want to say that I fully agree with what Marc offered in his reply regarding the advantages of older technologies that have become disused, likely because people, being people, are generally lazy and want a SPOC for all things, and only to willing and eager to leave it to others to "take care of my backups", hence the explosive adoption of things like Facebook, Twitter, etc. ... which are not desktop-based, leaving everyone at the mercy of "them" in remote places.  Just another facet of what can only be described as a long game-for destroying physical (i.e. neighbourhood) communities of like minds by eventually pulling the plug on those centralized services.

Such blind mass-adoption that I feel can only be characterized as behaviour similar to lemmings or dodos, and we know what happened to the latter!  Hence why I keep my email client, and all such personal information, in my own hands at the desktop.

I will still have ALL my resources when the internet fails, as long as a nuke hasn't fried my computer.  🙂

Eric

P.S.  This is my email setting for all things. Thank you for understanding.

[Steven H.]

Marc,

I am trying the following:

>·······some_array=('one'⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣'two'⏎
'three'⏎
'four'⏎
'five')⏎

The cursor is on the line containing 'three', normal mode.
I press '==' to auto align and the result is:

>·······some_array=('one'⏎
>·······␣␣␣␣␣␣␣␣␣␣␣␣'two'⏎
>·······>·······␣␣␣␣'three'⏎
'four'⏎
'five')⏎

i.e. VIM aligns with as many tabs as possible and fills the rest with spaces instead of repeating the indentation and alignment of the previous line.

Is there a fix for that?

[Dr. David A.D. Morano, PE, PhD]

Hi Marc and others,

Just to jump in here (maybe without knowing anything about the topic
or even what I am talking about):
My problem with NeoVim is that (according to what I have been led to
believe) is that NeoVim will not run on terminals that do not support
a UTF-8 character set. This is a problem for me for at least a couple
of reasons.

On the other hand, Vim runs just fine on a non-UTF-8 terminal (emulated or not).

Thank you Vim.
To repeat, thank you Vim.

Maybe someday I will have to face up to a completely UTF-8 world, but
happily that world has not yet fully come.

Thank you Vim.

----
Dave

[D. Ben Knoble]

On Tue, Apr 1, 2025 at 5:31 AM Marc Chantreux <m...@unistra.fr> wrote:
>
> I Ben and thanks for sharing this feeling,
>
> On Mon, Mar 31, 2025 at 08:24:16PM -0400, D. Ben Knoble wrote:
> > > thanks for this pointer. so sad those questions arise in stack* as we have a
> > > user mailing list.
> >
> > I'm sorry to hear you feel that way; the goal of the StackExchange
> > project was to create a commons of high-quality resources (much like
> > Wikipedia has).
>
> Wikipedia came out to fill the gap of collaborative places to edit
> articles.
>
> StackExchange just split communities because previous tools (mailing
> lists, newsgroups, archives and FAQ) were so much more convenient but
> in the early years of this millenium, lot of people came to internet
> with no idea of habits and customs of the technical communities.
>
> If it was ignorance, that's very sad. If not, I'll be happy to learn
> abou arguments that was worth splitting communities.

Again, I don't think StackExchange intended to split communities: see
some of the initial posts about it [1]:

> > Stackoverflow is sort of like the anti-experts-exchange (minus the nausea-inducing sleaze and quasi-legal search engine gaming) meets wikipedia meets programming reddit. It is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

Rather, I'm glad that StackExchange created new communities.

> > I think the linked examples are good examples of this
> > (though if you visit the home page you will find more sand than pearls
> > these days, at the cost of having helped a great number of people).
>
> Did you try newsgroups or mail archives? did you enjoy having your own
> local workflow with mbox mirrors indexed so you can use mutt of
> maildir-utils to query them, add copies of posts or threads in your
> notes and things like that?

Rather, I came to the Vim mailing list as a reader (and much later,
writer) only after having spent almost a decade on StackExchange. When
I "came into tech," I didn't have many guides. Sophisticated mailing
programs weren't (then) on my list of things to learn and master,
though as I'll return to in a moment are part of my recent search for
digital control.

So, while there are probably differences in StackExchange and other
things: perhaps we ought celebrate those differences and communities
rather than be sad and angry about them? Indeed, StackExchange proved
a _gateway_ to more personal, in-control computing for me. Isn't that
wonderful?

To reply to some of Eric's points (not CC'd based on how I understood
their request): I think it's true that older technologies such as
email have become disused—at least in terms of competent power users
and the joy that is personalized email clients. I disagree that it's
due to sheer laziness, and I think that argument is destructive
(because it ascribes a moral failing to others rather than asking how
we might empower ourselves or others to change something).

One example of the disuse: I've been using email since I was a child,
but I didn't learn that I could set up my own client to work how I
wanted until I was a recent adult. (For the curious and technical:
https://git-am.io/ is a decent starting point.)

Another example: I taught my elderly grandmother how to use a computer
(and another how to use a tablet). Email was foreign to one, let alone
learning how to use a sophisticated "power user" program. Still think
laziness is the problem? I think it's a combination of power tools
having different tradeoffs (Vim is a power tool and is a surprisingly
different way to edit, making it a challenge for some learners) and
the lack of free material that spells out, slowly and painfully, how
to get from "what is email" to "digital control."

I frankly believe in and wish for you all to have control over your
digital lives. Situated software, retaining control of your data,
etc., are all great things.

Do what you can to make that easier for the rest of the world, please.

--
D. Ben Knoble