Hi Manuel
On 2015-06-14 Sunday at 01:09 -0400 Manuel Ortega wrote: > On Sun, Jun 14, 2015 at 12:09 AM, James McCoy <[email protected]> wrote: > > On Sat, Jun 13, 2015 at 11:55:12PM -0400, Manuel Ortega wrote: > > > Vim 7.4.738 here, Mac OSX 10.10.3. (Not MacVim, although the below is > > > reproducible there too). > > > > > > Either the "\_" regexp construct is broken, or the docs are badly > > > misleading. I don't know which. The following problem seems > > > independent of &re=1 or &re=2. I always use &re=1. > > > > > > Open a new, empty vim buffer. Hit > > > i<CR><CR>noon > > > which should make the first two lines empty and the third contain > > > 'noon'. > > > > > > Now do > > > :echo getline(2) =~ '\_$' > > > You will observe that "1" is echoed, which is correct behavior. > > > > > > Next do > > > :echo getline(2) =~ '\_.' > > > and you will observe that "0" is echoed. > > > > > > This contradicts the docs. The docs say that \_$ matches an end of > > > line, and \_. will match either an end of line or any character. If the > > > latter is true, there should not have been a "0" echoed. > > > > The documentation is correct in the context of searching the buffer. In > > the context of pattern matching against an, in the case of getline(2), > > empty string, then \_$ correctly matches the end of the string while \_. > > doesn't match because there is neither a character or a newline. > > The docs don't seem to distinguish these "contexts" (unless I missed > something). It would be nice if they did. Maybe the following addition to “:help getline()” would have helped you? > Note that the returned strings never include linebreaks, thus > the function name “getline” perhaps is somehow misleading. ─────────────────────────────────────────────────────────────────────────── Convert “eval.txt” encoding from latin1 to utf-8. This patch (not the resulting “eval.txt“) needs to be treated as _binary_ file; reading by vim requires setting the option “binary”, otherwise vim would damage the patch. Luckily after the conversion … • We will have this complication never again. • We avoid any errors caused by the shortcomings of extended latin encodings in the future. --- runtime/doc/eval.txt.latin1 2015-04-13 12:43:06.000000000 +0200 +++ runtime/doc/eval.txt 2015-06-14 16:58:25.000000000 +0200 @@ -2369,8 +2369,8 @@ char2nr({expr}[, {utf8}]) *char2nr() char2nr("ABC") returns 65 < When {utf8} is omitted or zero, the current 'encoding' is used. Example for "utf-8": > - char2nr("�") returns 225 - char2nr("�"[0]) returns 195 + char2nr("á") returns 225 + char2nr("á"[0]) returns 195 < With {utf8} set to 1, always treat as utf-8 characters. A combining character is a separate character. |nr2char()| does the opposite. ─────────────────────────────────────────────────────────────────────────── Improve documentation “:help getline()”. --- runtime/doc/eval.txt~ 2015-06-14 16:58:25.000000000 +0200 +++ runtime/doc/eval.txt 2015-06-14 17:10:41.580255585 +0200 @@ -3480,7 +3480,9 @@ getline({lnum} [, {end}]) :let end = search("^$") - 1 :let lines = getline(start, end) -< To get lines from another buffer see |getbufline()| +< Note that the returned strings never include linebreaks, thus + the function name “getline” perhaps is somehow misleading. + To get lines from another buffer see |getbufline()| getloclist({nr}) *getloclist()* Returns a list with all the entries in the location list for ─────────────────────────────────────────────────────────────────────────── -- Roland Eggner -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
pgp5YyVsORvId.pgp
Description: PGP signature
