PATCH: new option: alternate whitespace handling in paragraph search
Mark Lundquist
Hi,
I've been a Vim user for many years... this is my first post to this
dev list and my first contribution to Vim :-)
I love to use '{' and '}' to move between sections separated by blank
lines... and, accordingly I make sure that all my blank lines are
really *empty* (i.e., no whitespace), and if I need any help from Vim
for that I must have configured it long ago.
However, I have lowbrow colleagues who would not even know the
difference between an empty line and a blank line and for whom it
would be (really) a lot of trouble to try to keep all their blank
lines empty, so I can't really even try to make them do it. Sometimes
I would edit a file they've worked on and do this (in annoyance!):
:%s/^[ ^I]*$//
but that's a pain (and it introduces spurious diffs in our Subversion
change logs).
So... I just checked out the Vim source code, and added this option:
:set wspara
and now... happiness! I can now '{' and '}' through their non-empty
blank lines just as though they were empty.
Here's the patch, I hope y'all will commit it:
-------------------------------------------------------------------------------------------------------------------------------------------------
Index: src/option.c
===================================================================
--- src/option.c (revision 1114)
+++ src/option.c (working copy)
@@ -2751,6 +2751,9 @@
(char_u *)&p_wd, PV_NONE,
{(char_u *)0L, (char_u *)0L}},
+ {"wspara", "wsp", P_BOOL,
+ (char_u *)&p_wsp, PV_NONE,
+ {(char_u *)0L, (char_u *)0L}},
/* terminal output codes */
#define p_term(sss, vvv) {sss, NULL, P_STRING|P_VI_DEF|P_RALL|
P_SECURE, \
(char_u *)&vvv, PV_NONE, \
Index: src/option.h
===================================================================
--- src/option.h (revision 1114)
+++ src/option.h (working copy)
@@ -869,6 +869,7 @@
EXTERN int p_wa; /* 'writeany' */
EXTERN int p_wb; /* 'writebackup' */
EXTERN long p_wd; /* 'writedelay' */
+EXTERN long p_wsp; /* 'wspara' */
/*
* "indir" values for buffer-local opions.
Index: src/search.c
===================================================================
--- src/search.c (revision 1114)
+++ src/search.c (working copy)
@@ -2742,6 +2742,13 @@
if (*s == '.' && (inmacro(p_sections, s + 1) ||
(!para && inmacro(p_para, s + 1))))
return TRUE;
+ if (p_wsp) {
+ while (
+ *s != NUL
+ && (*s == ' ' || *s == '\t')
+ ) ++s;
+ return *s == NUL;
+ }
return FALSE;
}
Markus Heidelberg
>
> However, I have lowbrow colleagues who would not even know the
> difference between an empty line and a blank line and for whom it
> would be (really) a lot of trouble to try to keep all their blank
> lines empty, so I can't really even try to make them do it. Sometimes
> I would edit a file they've worked on and do this (in annoyance!):
I had a similar experience this week. I used a blank line to separate blocks
of code in a Makefile and a colleague replaced them with more visible lines of
comments:
#
#-----------------
#
I think I have to revert it :)
> So... I just checked out the Vim source code, and added this option:
>
> :set wspara
>
> and now... happiness! I can now '{' and '}' through their non-empty
> blank lines just as though they were empty.
>
> Here's the patch, I hope y'all will commit it:
Your patch is malformed.
- wrapped long line
- tabs are spaces
- wrong line numbers (why? I'm on svn revision 1114, too)
To have the chance to get the feature included at all, please read :help
design-documented
Consider these files:
runtime/doc/quickref.txt (:h option-list)
runtime/doc/tags (not sure if necessary)
runtime/doc/options.txt (:h option-summary)
runtime/doc/motion.txt (:h paragraph)
runtime/syntax/vim.vim (search for vimOptions)
runtime/optwin.vim
I stumbled over ap and ip at the text-objects (:h ap), where lines with
whitespace are also handled as a paragraph boundary. Isn't this a little bit
inconsistent with } and { and the description at :h paragraph?
While replying to this mail, I noticed that it would be useful to define own
paragraph boundaries, not only an option for whitespace. I use Gvim as
external editor for KMail and want to delete some paragraphs of quoted text
from Mark, but the > quote sign forbids it. I saw 'paragraphs' in the help,
but I think that's a bit of another thing. Or is it already possible with this
option?
Markus
Mark Lundquist
On Jul 19, 2008, at 9:55 AM, Markus Heidelberg wrote:
> Your patch is malformed.
> - wrapped long line
No way. My patch didn't contain any long lines!
> - tabs are spaces
bah... okay, I'll retab it.
> - wrong line numbers (why? I'm on svn revision 1114, too)
Weird... that patch is just from "svn diff".
> To have the chance to get the feature included at all, please
> read :help
> design-documented
okay
> Consider these files:
> runtime/doc/quickref.txt (:h option-list)
> runtime/doc/tags (not sure if necessary)
> runtime/doc/options.txt (:h option-summary)
> runtime/doc/motion.txt (:h paragraph)
> runtime/syntax/vim.vim (search for vimOptions)
> runtime/optwin.vim
Thx... yeah, I meant to do that :-/... but forgot.
> I stumbled over ap and ip at the text-objects (:h ap), where lines
> with
> whitespace are also handled as a paragraph boundary. Isn't this a
> little bit
> inconsistent with } and { and the description at :h paragraph?
I agree. ":h paragraph" and ":h text-objects" are not in agreement.
"h:paragraph" describes the current behavior ("empty line" as
boundary), "h: text-objects" does not.
You *could* actually view this as a (non-doc) bug; i.e., decide that
":h text-objects" is normative, implement my change to the startPS()
logic but without the new option, and correct "h:paragraph".
So let me know what you want to do here, as long as I'm revising my
patch. If you want to "fix" Vim so that the current :h text-objects
does not lie, then I will remove the option, fix startPS(), and
correct ":h paragraph" in my patch.
> While replying to this mail, I noticed that it would be useful to
> define own
> paragraph boundaries, not only an option for whitespace. I use Gvim as
> external editor for KMail and want to delete some paragraphs of
> quoted text
> from Mark, but the > quote sign forbids it. I saw 'paragraphs' in
> the help,
> but I think that's a bit of another thing. Or is it already possible
> with this
> option?
No... it isn't.
cheers,
—ml—
Markus Heidelberg
>
> On Jul 19, 2008, at 9:55 AM, Markus Heidelberg wrote:
>
> > Your patch is malformed.
> > - wrapped long line
>
> No way. My patch didn't contain any long lines!
Sure! Please try applying the patch yourself, before claiming the opposite.
Your changes didn't contain long lines, but your patch did. At least long
enough for your mail program to split it into two:
#define p_term(sss, vvv) {sss, NULL, P_STRING|P_VI_DEF|P_RALL|
P_SECURE, \
> > I stumbled over ap and ip at the text-objects (:h ap), where lines
> > with
> > whitespace are also handled as a paragraph boundary. Isn't this a
> > little bit
> > inconsistent with } and { and the description at :h paragraph?
>
> I agree. ":h paragraph" and ":h text-objects" are not in agreement.
> "h:paragraph" describes the current behavior ("empty line" as
> boundary), "h: text-objects" does not.
>
> You *could* actually view this as a (non-doc) bug; i.e., decide that
> ":h text-objects" is normative, implement my change to the startPS()
> logic but without the new option, and correct "h:paragraph".
>
> So let me know what you want to do here, as long as I'm revising my
> patch. If you want to "fix" Vim so that the current :h text-objects
> does not lie, then I will remove the option, fix startPS(), and
> correct ":h paragraph" in my patch.
I don't know if it's a bug, I rather think it is intended to behave so. Let's
wait for someone who knows it. By the way, this suggested change would break
backwards compatibility.
Markus
Mark Lundquist
On Jul 19, 2008, at 1:01 PM, Markus Heidelberg wrote:
>> So let me know what you want to do here, as long as I'm revising my
>> patch. If you want to "fix" Vim so that the current :h text-objects
>> does not lie, then I will remove the option, fix startPS(), and
>> correct ":h paragraph" in my patch.
>
> I don't know if it's a bug, I rather think it is intended to behave
> so.
Maybe so... OTOH, whoever wrote ":h text-objects" probably intended
that it be true as well :-)
> Let's
> wait for someone who knows it.
Sounds good.
> By the way, this suggested change would break
> backwards compatibility.
Me knows... That's actually why I did it as a new option; it was
really a "don't break back-compatibility" reflex action on my part.
But now that I think of it... it really seems like a stretch to
imagine that anybody would find fault with the "new" behavior if it
were done this way ("Hey! Paragraph motions are now stopping at all
my whitespace-only lines!!!"), but... who knows...? ;-)
If you want to wait and see WOT, that's great. In the meantime, I
have my reasonable paragraphs now so I'm happy. I was just trying to
maybe contribute something useful while I was at it, and help make the
world a (admittedly ever so slightly) better place. If someone ever
asks me to redo this patch in either one of the two ways discussed,
I'm happy to do it.
cheers,
—ml—
Matthew Winn
<markus.h...@web.de> wrote:
> While replying to this mail, I noticed that it would be useful to define own
> paragraph boundaries, not only an option for whitespace. I use Gvim as
> external editor for KMail and want to delete some paragraphs of quoted text
> from Mark, but the > quote sign forbids it. I saw 'paragraphs' in the help,
> but I think that's a bit of another thing. Or is it already possible with this
> option?
If a new option is being added I think it would be better to have it
provide a general way of defining paragraphs rather than dealing with
one specific special case.
--
Matthew Winn
Ben Schmidt
> that I think of it... it really seems like a stretch to imagine that
> anybody would find fault with the "new" behavior if it were done this
> way ("Hey! Paragraph motions are now stopping at all my whitespace-only
> lines!!!"), but... who knows...? ;-)
Yes, I would consider that behaviour a bug. IMHO whitespace only lines
are different to empty lines and should not break paragraphs. Indeed, I
use folding that relies on a distinction between empty lines and
whitespace-only lines.
Ben.
Richard Hartmann
<markus.h...@web.de> wrote:
> While replying to this mail, I noticed that it would be useful to define own
> paragraph boundaries, not only an option for whitespace.
Yes, if this is done, a generic option would be best.
Richard
Mark Lundquist
Well... there we go, now I don't have to "imagine" it... :-) Duly
noted.
So far nobody wants a special option for whitespace handling in
paragraph search... there have been a few 'yeahs' for a general
paragraph delimiter configuration setting. What would that look
like? Unfortunately, the "paragraphs" ("para") option is already used
for the special case of nroff macros. Also, is there a need to be
able to specify paragraph open and close patterns, or just a single
delimiter?
—ml—
Gary Johnson
I think such an option should specify a paragraph separator, or set
of separators, and not make any distinction between the opening and
the closing of a paragraph.
Considering only separators is consistent with vim's current
behavior, whether the separator is an empty line, a blank line, a
non-white-space/new-line sequence (as specified by the
'formatoptions' 'w' flag), or a 'paragraphs' string.
Specifying separate paragraph-open and paragraph-close patterns
would introduce issues such as the possibility of regions of text
not in any paragraph. This would unnecessarily complicate the
solution and the use of vim.
It seems to me that a pattern would work well. If empty, you get
the current schizophrenic behavior for backward compatibility. To
use empty lines as delimiters, set it to "\n\n\+". To use blank
lines, set it to "\n\(\s*\n\)\+". If the 'formatoptions' 'w' flag
is set, the delimiter pattern would be overridden (not overwritten)
but be effectively "\S\n\+".
Regards,
Gary