On 2008-07-20, Mark Lundquist <[EMAIL PROTECTED]> wrote:
>
> On Jul 20, 2008, at 3:38 AM, Ben Schmidt wrote:
>
>>> 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...? ;-)
>>
>> 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.
>
> 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?
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
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---