Re: doc suggestion
On Sun, 05 Apr 2009 11:38:18 +0200, Tony Mechelynck wrote: On 05/04/09 04:33, George V. Reilly wrote: On Sat, Apr 4, 2009 at 5:31 PM, Tony Mechelynck antoine.mechely...@gmail.com wrote: VimL scripting was introduced in Vim 5.0, eleven years ago, according to http://en.wikipedia.org/wiki/Vim_(text_editor)#History. Personally, I wouldn't expend more than a few minutes ensuring compatibility with Vim 6.0 (2001), especially if you need dictionaries and other 7.0 features. Didn't legacy Vi have exrc files? And how were they written if it wasn't in what could be recognizably seen as what evolved to become vimscript? IIRC, Vi's exrc files were just lists of Ex commands. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: doc suggestion
On Sun, Apr 5, 2009 at 11:12 PM, Spencer Collyer spen...@lasermount.plus.com wrote: On Sun, 05 Apr 2009 11:38:18 +0200, Tony Mechelynck wrote: On 05/04/09 04:33, George V. Reilly wrote: On Sat, Apr 4, 2009 at 5:31 PM, Tony Mechelynck antoine.mechely...@gmail.com wrote: VimL scripting was introduced in Vim 5.0, eleven years ago, according to http://en.wikipedia.org/wiki/Vim_(text_editor)#History. Personally, I wouldn't expend more than a few minutes ensuring compatibility with Vim 6.0 (2001), especially if you need dictionaries and other 7.0 features. Didn't legacy Vi have exrc files? And how were they written if it wasn't in what could be recognizably seen as what evolved to become vimscript? IIRC, Vi's exrc files were just lists of Ex commands. Pretty much just :map and :set. Look at the code in $VIMRUNTIME/macros and shudder. -- /George V. Reilly geo...@reilly.org http://www.georgevreilly.com/blog http://blogs.cozi.com/tech --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Strange behavior of 'wincmd'
On 05/04/09 17:54 +0200, Bram Moolenaar wrote:
In your Test() function there is no redraw. So even though you use zb
it doesn't take effect. If you then later change something that
triggers a redraw, the relative cursor position hasn't been set yet.
Try the same operation by hand, I didn't see this problem then.
Hi Bram,
I may not fully understand your point, sorry.
To demonstrate it step by step, I added a breakpoint and two :redraw!s
around the trigger point. This time it can be triggered to display the
difference before and after the 'wincmd J' by hand for you.
$ vim -u NONE -S test.vim
$ cat test.vim
fun! BuildLines(prefix)
let a = []
for i in range(1, 100)
call add(a, a:prefix . : This is line . i)
endfor
return a
endfun
breakadd func 24 Test
fun! Test()
set equalalways
set scrolloff=0
Create a Log window
new Log
set bt=nofile
only!
Create Main Window, then write some lines into it and
display the 50th line in the bottom of the window
top new Main
set bt=nofile
let a=BuildLines(Main)
call append(0, a)
normal 50G
normal zb
Add some lines to another window (that is, the Log window)
let win_no = bufwinnr(Log)
if win_no != -1
Found the Log window
exe win_no . wincmd w
redraw! We can see 'zb' has effects (50th lines at bottom)
wincmd J Trigger the problem, use 'redraw' to see it
redraw! After this, we'll see the 50th line got moved.
call append('$', Log: Where is the 50th line? )
exe normal G
endif
endfun
call Test()
--
Dasn
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
BUG: Cannot jump to helptag containing a dash (in some helpfiles)
Cannot jump to a helptag containing a dash. Example: version5.txt defines *new-script*. But if you hit Ctrl-] on |new-script|, Vim will either give an error (if the cursor is on new) or take you to *script* in usr41.txt (if the cursor is on -script). Using Huge 7.2.148 on Linux. When displaying version5.txt, 'iskeyword' is at its Unix default, @,48-57,_,192-255 I haven't (yet) tested what would happen with a $VIM/vimfiles/after/ftplugin/help.vim defining the dash as part of 'isk'. Maybe other characters should be included too? Hm., I guess the paragraph For a help file it is set to all non-blank printable characters except '*', '' and '|' (so that CTRL-] on a command finds the help for that command). (under 'iskeyword') ought to be implemented via a filetype-plugin rather than a modeline. I guess this would mean setl isk=33-127,161-255,^*,^\,^\| wouldn't it? (i.e., excluding control characters 0-0x1F and 0x80-0x9F, plus space, no-break space, star, double-quote and bar, and including the rest). Best regards, Tony. -- ARTHUR: You are indeed brave Sir knight, but the fight is mine. BLACK KNIGHT: Had enough? ARTHUR: You stupid bastard. You havn't got any arms left. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: doc suggestion
On 06/04/09 09:09, George V. Reilly wrote: On Sun, Apr 5, 2009 at 11:12 PM, Spencer Collyer spen...@lasermount.plus.com wrote: [...] IIRC, Vi's exrc files were just lists of Ex commands. Pretty much just :map and :set. Look at the code in $VIMRUNTIME/macros and shudder. :-) Depends what in $VIMRUNTIME/macros. matchit.vim is a real work of art, except of course that it rightly belongs in $VIMRUNTIME/plugin. Best regards, Tony. -- This fortune intentionally not included. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: BUG: Cannot jump to helptag containing a dash (in some helpfiles) (OOPS)
On 06/04/09 19:06, Tony Mechelynck wrote: On 06/04/09 18:51, Tony Mechelynck wrote: [...] setl isk=33-127,161-255,^*,^\,^\| wouldn't it? (i.e., excluding control characters 0-0x1F and 0x80-0x9F, plus space, no-break space, star, double-quote and bar, and including the rest). Best regards, Tony. P.S. The above :setlocal command in a filetype-plugin for help does indeed solve my problem. I suggest that the line be added to $VIMRUNTIME/ftplugin/help.vim Best regards, Tony. Oops! 0x7F is a control character too. Change that to setl isk=33-126,161-255,^*,^\,^\| Best regards, Tony. -- A student, in hopes of understanding the Lambda-nature, came to Greenblatt. As they spoke a Multics system hacker walked by. Is it true, asked the student, that PL-1 has many of the same data types as Lisp? Almost before the student had finished his question, Greenblatt shouted, FOO!, and hit the student with a stick. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Suggestion: Redefine \Uxxxxx in double-quoted strings
Vim is now capable of displaying any Unicode codepoint for which the installed 'guifont' has a glyph, even outside the BMP (i.e., even above U+), but there's no easy way to represent those high codepoints by Unicode value in strings: I mean, \u and \U still accept no more than four hex digits. I propose to keep \u at its present meaning, but extend \U to allow additional hex digits (either up to a total of 8 hex digits, in line with ^VU as opposed to ^Vu in Insert mode, or at least up to the value \U10, above which the Unicode Consortium has decided that there never shall be a valid Unicode codepoint at any future time. I'm aware that this is an incompatible change, but I believe the risk is low compared with the advantages (as a sidenote, many rare CJK characters lie in plane 2, in the CJK Unified Extension B range U+2-U+2A6DF). The notation \Char-0x2 or \Char-131072 doesn't work: here (in my GTK2/Gnome2 gvim with 'encoding' set to UTF-8), :echoing such a string displays f0a080feX80feX instead of just the one CJK character (and, yes, I've set my mailer to send this post as UTF-8 so if yours is well-behaved it should display that character properly). Best regards, Tony. -- Although the moon is smaller than the earth, it is farther away. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Suggestion: Redefine \Uxxxxx in double-quoted strings
Tony Mechelynck wrote: Vim is now capable of displaying any Unicode codepoint for which the installed 'guifont' has a glyph, even outside the BMP (i.e., even above U+), but there's no easy way to represent those high codepoints by Unicode value in strings: I mean, \u and \U still accept no more than four hex digits. I propose to keep \u at its present meaning, but extend \U to allow additional hex digits (either up to a total of 8 hex digits, in line with ^VU as opposed to ^Vu in Insert mode, or at least up to the value \U10, above which the Unicode Consortium has decided that there never shall be a valid Unicode codepoint at any future time. I'm aware that this is an incompatible change, but I believe the risk is low compared with the advantages (as a sidenote, many rare CJK characters lie in plane 2, in the CJK Unified Extension B range U+2-U+2A6DF). The notation \Char-0x2 or \Char-131072 doesn't work: here (in my GTK2/Gnome2 gvim with 'encoding' set to UTF-8), :echoing such a string displays f0a080feX80feX instead of just the one CJK character (and, yes, I've set my mailer to send this post as UTF-8 so if yours is well-behaved it should display that character properly). It does cause problems for something like \U12345 which would now be the character 0x1234 followed by the character 5. After the change it would become one character 0x12345. I don't see a convenient alternative though. Anyone? -- Even got a Datapoint 3600(?) with a DD50 connector instead of the usual DB25... what a nightmare trying to figure out the pinout for *that* with no spex... /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Strange behavior of 'wincmd'
Dasn wrote: On 05/04/09 17:54 +0200, Bram Moolenaar wrote: In your Test() function there is no redraw. So even though you use zb it doesn't take effect. If you then later change something that triggers a redraw, the relative cursor position hasn't been set yet. Try the same operation by hand, I didn't see this problem then. Hi Bram, I may not fully understand your point, sorry. To demonstrate it step by step, I added a breakpoint and two :redraw!s around the trigger point. This time it can be triggered to display the difference before and after the 'wincmd J' by hand for you. I'll try this later. With the redraw commands it should indeed work. However, if it works OK when executing the commands by hand, and it's not OK when doing the same in a function or script, it's probably because Vim skips quite a bit of redrawing stuff when not working interactively. Can you still reproduce the problem when removing some of the lines? E.g., is the set bt=nofile required? -- Just think of all the things we haven't thought of yet. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: BUG: Cannot jump to helptag containing a dash (in some helpfiles)
Tony Mechelynck wrote: Cannot jump to a helptag containing a dash. Example: version5.txt defines *new-script*. But if you hit Ctrl-] on |new-script|, Vim will either give an error (if the cursor is on new) or take you to *script* in usr41.txt (if the cursor is on -script). Using Huge 7.2.148 on Linux. When displaying version5.txt, 'iskeyword' is at its Unix default, @,48-57,_,192-255 I haven't (yet) tested what would happen with a $VIM/vimfiles/after/ftplugin/help.vim defining the dash as part of 'isk'. Maybe other characters should be included too? Hm., I guess the paragraph For a help file it is set to all non-blank printable characters except '*', '' and '|' (so that CTRL-] on a command finds the help for that command). (under 'iskeyword') ought to be implemented via a filetype-plugin rather than a modeline. I guess this would mean setl isk=33-127,161-255,^*,^\,^\| wouldn't it? (i.e., excluding control characters 0-0x1F and 0x80-0x9F, plus space, no-break space, star, double-quote and bar, and including the rest). The idea is that you open the help file with :help and then all the options are set properly. If you edit the help file in another way the 'iskeyword' value indeed is not the right one for help files. But then CTRL-] also doesn't use the tags file for help. I suppose setting 'iskeyword' in the help filetype plugin makes sense. Note that it does make editing a bit different, especially for word movements. That's why punctuation sometimes goes missing when I'm not careful about this. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Suggestion: Redefine \Uxxxxx in double-quoted strings
Bram Moolenaar wrote: Tony Mechelynck wrote: Vim is now capable of displaying any Unicode codepoint for which the installed 'guifont' has a glyph, even outside the BMP (i.e., even above U+), but there's no easy way to represent those high codepoints by Unicode value in strings: I mean, \u and \U still accept no more than four hex digits. I propose to keep \u at its present meaning, but extend \U to allow additional hex digits (either up to a total of 8 hex digits, in line with ^VU as opposed to ^Vu in Insert mode, or at least up to the value \U10, above which the Unicode Consortium has decided that there never shall be a valid Unicode codepoint at any future time. It does cause problems for something like \U12345 which would now be the character 0x1234 followed by the character 5. After the change it would become one character 0x12345. I don't see a convenient alternative though. Anyone? Well, I don't know about *convenient*, but one option would be to continue allowing \u to use 1-to-4 hex digits, and require that \U use exactly 8 (or exactly 6, if we only support up to \U10) hex digits. On the one hand, it will break just about every existing place where someone used \U instead of \u. On the other hand, the fix is trivial, and it gives an actual reason for supporting both \u and \U. I think it's better than the alternative you propose, since changing the definition from 1-to-4 hex digits to 1-to-8 hex digits will cause things to fail in non-obvious ways, and changing the defiintion to exactly 8 hex digits should usually cause a more obvious failure that we could assign a helpful error number to. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: BUG: Cannot jump to helptag containing a dash (in some helpfiles)
On 06/04/09 22:15, Bram Moolenaar wrote: Tony Mechelynck wrote: Cannot jump to a helptag containing a dash. Example: version5.txt defines *new-script*. But if you hit Ctrl-] on |new-script|, Vim will either give an error (if the cursor is on new) or take you to *script* in usr41.txt (if the cursor is on -script). Using Huge 7.2.148 on Linux. When displaying version5.txt, 'iskeyword' is at its Unix default, @,48-57,_,192-255 I haven't (yet) tested what would happen with a $VIM/vimfiles/after/ftplugin/help.vim defining the dash as part of 'isk'. Maybe other characters should be included too? Hm., I guess the paragraph For a help file it is set to all non-blank printable characters except '*', '' and '|' (so that CTRL-] on a command finds the help for that command). (under 'iskeyword') ought to be implemented via a filetype-plugin rather than a modeline. I guess this would mean setl isk=33-127,161-255,^*,^\,^\| wouldn't it? (i.e., excluding control characters 0-0x1F and 0x80-0x9F, plus space, no-break space, star, double-quote and bar, and including the rest). The idea is that you open the help file with :help and then all the options are set properly. If you edit the help file in another way the 'iskeyword' value indeed is not the right one for help files. But then CTRL-] also doesn't use the tags file for help. Ah, that's what happened. I opened it with :0verbose vimgrep /\func\%[tion]\/g $VIMRUNTIME/doc/version*.txt, hoping to both reduce processing time and eliminate spurious quickfix entries compared to seaching for the same pattern with :helpgrep. I suppose setting 'iskeyword' in the help filetype plugin makes sense. Note that it does make editing a bit different, especially for word movements. That's why punctuation sometimes goes missing when I'm not careful about this. Hm., in case of doubt we can either use visual mode (and double-check what gets highlighted), or check afterwards that the result of the edit jibes with what we expected. Yes, you said it: carelessness can give problems, and not only in this case. Best regards, Tony. -- Velilind's Laws of Experimentation: (1) If reproducibility may be a problem, conduct the test only once. (2) If a straight line fit is required, obtain only two data points. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
