On Mo, 05 Jul 2021, 'Jürgen Krämer' via vim_use wrote:
> Hi,
>
> Chris Jones schrieb am 03.07.2021 um 21:50:
> > Something that's been bugging me for some time.
> >
> > I am working on an anthology of French literature and I need to xhtml
> > this renowned piece from the late 18th century:
> >
> > | 000 ...
> > | 001 En tous lieux le cul nous appelle, <br />$
> > | 002 Le cul met tous les vits en rut,$
> > | 003 Le cul du bonheur est la voie,$
> > | 004 Dans le cul gît toute la joie,$
> > | 005 Mais, hors du cul point de salut.
> > | 006 ... etc. ^
> > | col. 60 ____________.
> >
> > To start off with the cursor is at the beginning of line 001 and I need
> > to append html linebreaks to lines 002-004. Since I'd rather the source
> > of the document remain somewhat legible I much prefer having the <br />
> > tags well-separated from the actual text & neatly aligned in col. 60.
> >
> > Clarification: the dollar sign at the end of l. 002--004 is NOT part of
> > the text: lacking a better solution it's only there to represent the
> > end-of-line: everything beyond in the vim buffer is a NUL character!
> >
> > To save me some typing (and typos) this is the way I handle it:
> >
> > 1. f< " move cursor to the opening '<'
> > 2. :set virtualedit=all " enable editing beyond end-of-line
> > 3. j " move cursor l. 001 -> l 002
> > 4. CTRL+V " switch to blockwise visual mode
> > 5. 3j " select 1 column × 3 line block
> > 6. I " (upper case) switch to 'block insert'
> > 7. CTRL+Y (6 times) " 'clone' l. 001's <br /> on line 002
> > 8. <ESC> " escape back to normal mode
> > 9. :set virtualedit= " optional - depends on what follows
> >
> > After hitting <ESC> I'd expect vim to 'magically' clone the '<br />'
> > already duplicated on l. 002 on lines 003-004. But nothing happens!
> > I end up with my html linebreak duplicated on l. 002 and nought on l.
> > 003 & 004.
> >
> > After tinkering with this for a little while I found that if I select
> > a one-column block on col. 60 (e.g.) including all lines where I need to
> > add my line breaks and then insert a space there, thus replacing the NUL
> > character there by a space (but also replacing all NUL characters
> > -so-to-speak- up to col. 60 by spaces the 1-8 sequence of keystrokes
> > does what I intend. But that's a LOT of extra work...
> >
> > Is this to be expected or is it a 'feature'?
>
> from ":help v_b_I" I guess it is the documented behaviour:
>
> | Visual-block Insert *v_b_I*
> | With a blockwise selection, I{string}<ESC> will insert {string} at the start
> | of block on every line of the block, provided that the line extends into the
> | block. Thus lines that are short will remain unmodified. TABs are split to
> | retain visual columns. Works only for adding text to a line, not for
> | deletions. See |v_b_I_example|.
>
>
> > Is there a better way (excluding mouse'ing and plugin'ing) to achieve
> > this?
>
> "A" in visual block mode is expected to first extend a line if 'virtualedit'
> is set to "block" or "all" and the cursor is placed beyond the end of line,
> so you might want to change the first step to "t<" and the sixth one to "A".
See also the documentation at :h v_b_I and :h v_b_A and see the `Note:`
section.
Best,
Christian
--
Kleine Bosheiten erhalten die Feindschaft.
--
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210705072818.GA283422%40256bit.org.
No comments:
Post a Comment