Consider lines containing a tab a paragraph boundary

[Marco]

Hi,

can I configure vim to consider a line containing a tab a paragraph
boundary for the { and } commands? I find it rather irritating that
{ and } don't consider a tab a paragraph boundary but the ip motion
does. Example:

struct acpi_blacklist_item {
char oem_id[7];
char oem_table_id[9];

u32 oem_revision; <= CURSOR IS HERE
char *table;

enum acpi_blacklist;
char *reason;
u32 is_critical_error;
};

Hitting { jumps to the beginning of the struct, whereas yip only
yanks the two lines

u32 oem_revision; <= CURSOR IS HERE
char *table;


Marco

[Ben Fritz]

On Friday, April 12, 2013 9:45:34 AM UTC-5, Marco wrote:
> Hi,
>
>
>
> can I configure vim to consider a line containing a tab a paragraph
>
> boundary for the { and } commands? I find it rather irritating that
>
> { and } don't consider a tab a paragraph boundary but the ip motion
>
> does. Example:
>

It's not configurable.

{ and } strictly use paragraph boundaries, defined as empty lines or lines using nroff macros specified in the 'paragraphs' option.

ip uses these but also has an exception for lines containing nothing but whitespace.

See :help paragraph and :help ip

This behavior annoys me too but it is what it is.

[Marco]

On 2013–04–12 Ben Fritz wrote:

> It's not configurable.
>
> { and } strictly use paragraph boundaries, defined as empty lines
> or lines using nroff macros specified in the 'paragraphs' option.
>
> ip uses these but also has an exception for lines containing
> nothing but whitespace.
>
> See :help paragraph and :help ip

I did read those sections. The 'paragraphs' option with the default
setting "IPLPPPQPP TPHPLIPpLpItpplpipbp" is one of the weirdest vim
options I encountered in a while. Why is it restricted to nroff
macros? It could better take a regex or anything more general than
nroff macros.

> This behavior annoys me too but it is what it is.

Good to hear that it's not just me. If there is interest, maybe a
second variable, e.g. 'paragraphsregex' could be implemented and set
to an arbitrary regex as paragraph delimiter. If it's undefined, the
old behaviour takes precedence to remain backwards compatible.

Marco

[zappat...@free.fr]

Marco <net...@lavabit.com> a écrit:

That behavior annoys a lot of people; it's even #46 in the wish list:
http://www.vim.org/sponsor/vote_results.php

Best,
Paul

[Ben Fritz]

I don't see it in the wishlist.

But I do see a patch: https://groups.google.com/d/topic/vim_dev/8HShAdoMUSw/discussion

And another request: https://groups.google.com/d/topic/vim_dev/AFAK_k1kHvo/discussion

Both of these went nowhere.

[Christian Brabandt]

Hi zappathustra!

Some time ago¹, I made a patch. Please test. Here is the updated patch
again (which I seemed to have forgotten to attach in a later message).

¹) https://groups.google.com/d/msg/vim_dev/6r6qX8W6I_Y/pQPexgLWI6UJ

regards,
Christian
--
Es gibt keine Lauer auf der ich nicht liege.

[Marco]

On 2013–04–12 Ben Fritz wrote:

> > That behavior annoys a lot of people; it's even #46 in the wish list:
> >
> > http://www.vim.org/sponsor/vote_results.php
> >
>
> I don't see it in the wishlist.

Search for "{", it's item 47 at the moment.

> But I do see a patch:
> https://groups.google.com/d/topic/vim_dev/8HShAdoMUSw/discussion
>
> And another request:
> https://groups.google.com/d/topic/vim_dev/AFAK_k1kHvo/discussion
>
> Both of these went nowhere.

It seems like Christian is on it, I keep my fingers crossed.


Marco

[zappat...@free.fr]

Hello Christian,

Christian Brabandt <cbl...@256bit.org> a écrit:
> Hi zappathustra!

(Actually, it should be ``Paul Isambert'' as usual, but for the moment
I'm stuck with the Google interface, and I'm registered with my email
address only.)

> On Fr, 12 Apr 2013, zappat...@free.Fr wrote:
>
> > Marco <net...@lavabit.com> a écrit:

> > > On 2013–04–12 Ben Fritz wrote:
> > >

> > > > It's not configurable.
> > > >
> > > > { and } strictly use paragraph boundaries, defined as empty lines
> > > > or lines using nroff macros specified in the 'paragraphs' option.
> > > >
> > > > ip uses these but also has an exception for lines containing
> > > > nothing but whitespace.
> > > >
> > > > See :help paragraph and :help ip
> > >
> > > I did read those sections. The 'paragraphs' option with the default
> > > setting "IPLPPPQPP TPHPLIPpLpItpplpipbp" is one of the weirdest vim
> > > options I encountered in a while. Why is it restricted to nroff
> > > macros? It could better take a regex or anything more general than
> > > nroff macros.
> > >
> > > > This behavior annoys me too but it is what it is.
> > >
> > > Good to hear that it's not just me. If there is interest, maybe a
> > > second variable, e.g. 'paragraphsregex' could be implemented and set
> > > to an arbitrary regex as paragraph delimiter. If it's undefined, the
> > > old behaviour takes precedence to remain backwards compatible.
> >

> > That behavior annoys a lot of people; it's even #46 in the wish list:
> > http://www.vim.org/sponsor/vote_results.php
>

> Some time ago¹, I made a patch. Please test. Here is the updated patch
> again (which I seemed to have forgotten to attach in a later message).
>
> ¹) https://groups.google.com/d/msg/vim_dev/6r6qX8W6I_Y/pQPexgLWI6UJ

Ah, nice! (I remember that issue had come up recently.)

I've applied the patch and it's quite good; too bad I'm quite lame
with building Vim myself (I've only recently succeeded in building
the GUI...) and I prefer to use the Debian package. I'll have to wait
until the patch is official!

Anyway I've already found two buglets :) (unless your patch was just a
proof of concept): first, branches won't work:

set paragraphs=/^\s*$\|whatever

doesn't find anything; second (but that's actually inherited from the
original option), it'd be nice if the option were global-local.

Thank you,
Paul

[Gary Johnson]

On 2013-04-12, zappat...@free.Fr wrote:
> Hello Christian,

> Anyway I've already found two buglets :) (unless your patch was just a
> proof of concept): first, branches won't work:
>
> set paragraphs=/^\s*$\|whatever
>

> doesn't find anything; ...

I haven't installed the patch, so I can't test this, but your branch
is probably not working because of

:help :set-args
:help option-backslash

You should use either

set paragraphs=/^\\s*$\\|whatever

or

let &paragraphs = '/^\s*$\|whatever'

See

:help :let-option

Regards,
Gary

[zappat...@free.fr]

Gary Johnson <gary...@spocom.com> a écrit:

> On 2013-04-12, zappat...@free.Fr wrote:
> > Hello Christian,
>
> > Anyway I've already found two buglets :) (unless your patch was just a
> > proof of concept): first, branches won't work:
> >
> > set paragraphs=/^\s*$\|whatever
> >
> > doesn't find anything; ...
>
> I haven't installed the patch, so I can't test this, but your branch
> is probably not working because of
>
> :help :set-args
> :help option-backslash
>
> You should use either
>
> set paragraphs=/^\\s*$\\|whatever

Indeed. Actually, the bar should be preceded by three backslashes, if
I'm not mistaken (two denote a single one, and the last escapes the
bar).

In the meanwhile I've found that if you're on a paragraph line, you
can't jump to paragraph lines just below if you're one the first
character. E.g.:

set paragraphs=foo

with file:

foo
foo

foo

If you're on the first "f", you'll jump to the last line; if you're on
the first "o", you'll jump to the second line... With file:

foo
foo
foo

you won't jump anywhere from the first "f". Normally, "}" with the
usual 'paragraphs':

- jumps to the next blank line when on a non-blank line;
- jumps to the next blank line following a non-blank line when on a
blank line;
- jumps to the end of the file if there is no blank line below the
current one.

(``Blank line'' here of course means a real blank lines or the nroff
macros.)

With Christian's patch, I think that behavior should be mimicked by
simply replacing ``(non-)blank line'' with ``line (not) matching the
option''.


Best,
Paul

[Christian Brabandt]

Hi

On Fr, 12 Apr 2013, zappat...@free.Fr wrote:

> Hello Christian,
>
> Christian Brabandt <cbl...@256bit.org> a écrit:
> > Hi zappathustra!
>
> (Actually, it should be ``Paul Isambert'' as usual, but for the moment
> I'm stuck with the Google interface, and I'm registered with my email
> address only.)

Sorry, that is being added by mutt automatically and I usually don't
check it, because it usually just works ;)

> Anyway I've already found two buglets :) (unless your patch was just a
> proof of concept): first, branches won't work:
>
> set paragraphs=/^\s*$\|whatever

The patch in fact was just a proof of concept. But if there is interest,
I can work on it further. Please let me know any problems you found and
the settings of the paragraphs/section setting.

> doesn't find anything; second (but that's actually inherited from the
> original option), it'd be nice if the option were global-local.

That indeed is a nice extension. I can change this as well.

Mit freundlichen Grüßen
Christian
--
F: Was hat vier Beine und kann fliegen?
A: Zwei Vögel

[Christian Brabandt]

Hi zappathustra!

On Fr, 12 Apr 2013, zappat...@free.Fr wrote:

> Gary Johnson <gary...@spocom.com> a �crit:

I'll look into it.

regards,
Christian
--
Je kaputter die Welt drau�en, desto heiler mu� sie zu Hause sein.
-- Reinhard Mey

[Christian Brabandt]

On Fr, 12 Apr 2013, zappat...@free.Fr wrote:

Here is an updated toy patch. I also made the 'section' and 'para'
settings global-local.

Note, there is one problem and I don't know how to approach it.

Consider this file
,----
|
| foo
| foo
| foo
|
`----

If the cursor is on the first foo and you have set para=/foo pressing }
will jump after the whole 'foo' block. If the cursor is on the first o
and you press '}' it will first move to the second 'foo' line and on
next press of '}' it will move over the whole block.

I have no clue, how to detect, whether the cursor is on a block of
consecutive lines matching the 'para' or 'section' pattern and in that
case jump over the complete block. Perhaps, when using a regular
expression for 'para' and 'sections', we shouldn't jump over consecutive
matching lines at all?

Apart from that inconsistency, the patch seems to work for me.

regards,
Christian

[Bram Moolenaar]

Thanks.

I wonder if changing 'paragraphs' and 'sections' into a regexp that
matches at what's between paragraphs is sufficient. How about this
style with two paragraphs:

Blah blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah
Blah blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah

The examples with "foo" are a bit misleading, can't we use some
real-world examples?

--
Some of the well known MS-Windows errors:
ESLEEP Operator fell asleep
ENOERR No error yet
EDOLLAR OS too expensive
EWINDOWS MS-Windows loaded, system in danger

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

Hi Bram!

On Sa, 20 Apr 2013, Bram Moolenaar wrote:

> I wonder if changing 'paragraphs' and 'sections' into a regexp that
> matches at what's between paragraphs is sufficient. How about this
> style with two paragraphs:

Did this and updated the example. Would this be acceptable?

regards,
Christian
--
Jeder verheiratete Mann sollte seine Fehler vergessen -
es brauchen ja nicht zwei Personen das gleiche zu merken!

[Bram Moolenaar]

Christian Brabandt wrote:

> On Sa, 20 Apr 2013, Bram Moolenaar wrote:
>
> > I wonder if changing 'paragraphs' and 'sections' into a regexp that
> > matches at what's between paragraphs is sufficient. How about this
> > style with two paragraphs:
>
> Did this and updated the example. Would this be acceptable?

Hmm, I think what we really want is to match the text from the end of
one paragraph until the start of the next one. The example with "/^$"
would still work to have empty-line separated paragraphs. Paragraphs
that start with an indent would be found with "/^\s\+".

You could then also allow more than one empty line between paragraphs
with "/^\n*$".

I haven't tried the code, perhaps it already works like that?


--
I noticed my daughter's Disney-net password on a sticky note:
"MickeyMinnieGoofyPluto". I asked her why it was so long.
"Because they say it has to have at least four characters."

[Christian Brabandt]

On Wed, April 24, 2013 11:38, Bram Moolenaar wrote:
> Christian Brabandt wrote:
>> On Sa, 20 Apr 2013, Bram Moolenaar wrote:
>> > I wonder if changing 'paragraphs' and 'sections' into a regexp that
matches at what's between paragraphs is sufficient. How about this
style with two paragraphs:
>> Did this and updated the example. Would this be acceptable?
> Hmm, I think what we really want is to match the text from the end of
one paragraph until the start of the next one. The example with "/^$"
would still work to have empty-line separated paragraphs. Paragraphs
that start with an indent would be found with "/^\s\+".

correct.

> You could then also allow more than one empty line between paragraphs
with "/^\n*$".

That would be possible, but doesn't really change the cursor motion. Take
the example from the patch:
----------------------------
1 Lorem ipsum dolor sit amet,
2 consetetur sadipscing elitr,
3 sed diam
4
5
6 Lorem ipsum dolor sit amet,
7 consetetur sadipscing elitr,
8 sed diam

If the 'para' option is set to '/^$' moving using '}' will first move to
line 4, the next paragraph motion will move to line 5. Typing '}' again
will then move the cursor at the end of the last line.
--------------------------

Even is you use the /^\n\+$ as regular expression, the cursor will still
jump to the exact same positions, as line 4 and line 5 match
that regular expression. We could make it jump to the end of the match
using the SEARCH_END flag and then advance the cursor one more position,
but this would only work on forward searches, this doesn't seem to work
for backward searches:
https://groups.google.com/group/vim_use/msg/d82897dd34010e93?hl=de

regards,
Christian

[Bram Moolenaar]

The } motion is a bit strange in that it stops before a paragraph. I
never understood why it's like that and not jumping to the first line of
the paragraph.

Anyway, using ]] and [[ you do jump to the start or end of a section, so
there it's easier to see what the pattern does.

> Even is you use the /^\n\+$ as regular expression, the cursor will still
> jump to the exact same positions, as line 4 and line 5 match
> that regular expression. We could make it jump to the end of the match
> using the SEARCH_END flag and then advance the cursor one more position,
> but this would only work on forward searches, this doesn't seem to work
> for backward searches:
> https://groups.google.com/group/vim_use/msg/d82897dd34010e93?hl=de

How about using the pattern /^\n\+\zs ? The \zs marks where the cursor
ends up. This also allows moving to the first line of the paragraph.

Question remains how to handle {, where the cursor ends up then.
An alternative is to use flags after // to specify where the cursor is
positioned for { and }, e.g. /^\n\+/{s}e would mean { moves to the
start of the match and } to the end of the match.


--
hundred-and-one symptoms of being an internet addict:
217. Your sex life has drastically improved...so what if it's only cyber-sex!