Re: some vim syntax fixes for multi-lined commands
Alexey Radkov wrote: Hi Charles. Thank you! You're welcome! 2012/11/14 Charles Campbell charles.e.campb...@nasa.gov mailto:charles.e.campb...@nasa.gov (snipped) BTW, I prefer direct email contact for patches rather than via the mailing list. Ok, sure. But i did not know whom i should address with that. At the top of the syntax files the Maintainers (usually) include their email address. Mine is there, although one has to manually remove the NOSPAM embedded therein. Regards, Charles Campbell -- 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
Re: vim.vim organization
Kartik Agaram wrote: I notice many keywords in runtime/syntax/vim.vim are split across multiple lines. For example, I assume all the lines beginning with syn keyword vimCommand could logically be assumed to be a single (very long) command. Is that accurate? If this is correct, I'm curious if there's some pattern to how they are organized. It seems each line is in alphabetical order. But there's a's in each line. Is there some way to decide which line each keyword goes to? Or am I just over-thinking things? :) You're likely looking at the automatically generated keyword lists; vimCommands are generated automatically. The keywords are sorted in the usual ascending alphabetical order with 100 keywords per line. Regards, C Campbell -- 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
Re: Patch 7.3.633
Bram Moolenaar wrote: Patch 7.3.633 Problem:Selection remains displayed as selected after selecting another text. Solution: Call xterm_update() before select(). (Andrew Pimlott) Files: src/os_unix.c Hello! Patch #633 appears to be missing from ftp://ftp.home.vim.org/ ... Regards, Chip Campbell -- 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
Re: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Ben Fritz wrote: On Thursday, May 17, 2012 1:07:52 PM UTC-5, Thilo Six wrote: To me absolutely yes. Obviously we will need to discuss and decide some more details/workflows but i think the consensus is broad enough to start getting it productive. Are you fine with using vim-dev as our mailinglist for all runtime related questions? One person I'd like to see buy into the idea is Dr. Chip, who has been silent so far on the team maintenance issue. He maintains some of the most complicated plugin files in the runtime. Chip, have you been following this thread? Hello! I've been on vacation this week, attending my daughter's graduation from Emory University. I have several concerns about this proposal: * vim.vim : there's a large block of code that I generate automatically in syntax/vim.vim. Any changes made in that block of code, which is marked in the syntax file, will be wiped out whenever I make an update there. * sh.vim : by default it supports borne shell; most (including myself) use either Korn/Posix or Bash. In my experience there's been a lot of narrowmindedness on this; folks use bash and complain that its not supporting bash by default, and those using Korn/Posix complain that its not supporting Korn/Posix by default. I've left it at Borne to encourage people to make a choice. There is a potential issue with maintainers imposing their view about the default. * tex.vim : I am trying to keep out package support. There are thousands if not tens of thousands of packages supporting various optional features in LaTeX; it is impractical to expect vim's syntax/tex.vim to support them all (and they may not even co-exist properly). syntax/tex.vim is already quite large enough without lots of package support. I've encouraged users to write after/syntax/tex/pkgname.vim files to support their packages, and to post them on vim.sf.net. I can foresee that we'll have maintainers imposing their package support into syntax/tex.vim, which is a potential problem of this approach. Well, I need to get some gas for my lawnmower. See you! Chip Campbell -- 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
Re: [MPF] runtimefiles cpo+=l save
Thilo Six wrote: Hello ,[ :h syn-pattern ]- Syntax patterns are always interpreted like the 'magic' option is set, no matter what the actual value of 'magic' is. And the patterns are interpreted like the 'l' flag is not included in 'cpoptions'. This was done to make syntax files portable and independent of 'compatible' and 'magic' settings. `- -- snip -- Test: :new :put = \abc\tdef\ :set cpo+=l :syn match Test /c[\t]d/ :hi link Test StatusLine I can see highlighted text /c[\t]d E486: Pattern not found: c[\t]d -- snip -- ,[ src/syntax.c ]--- /* Make 'cpoptions' empty, to avoid the 'l' flag */ cpo_save = p_cpo; p_cpo = (char_u *); ci-sp_prog = vim_regcomp(ci-sp_pattern, RE_MAGIC); p_cpo = cpo_save; `- Bram i do not speak any C but to me it seems that something like this should be doable without great afford to cover all runtime files, too. IIRC when we have discussed this topic here last year it had been suggested to use a function to fix it once for all. Can't something like this be used to a broader scope, too? The exceptions for syntax files are (without having tested) likely to apply to the user's syntax files, too ($HOME/.vim/syntax, etc). Applying this exception to plugins would, for consistency, also apply to user-written plugins, and so vim would not behave in the manner to which some users are accustomed. Also, making such a change might break user-written, personal plugins. What I'd like to see is something akin to vimstatepush() vimstdstate() (optional plugin author state modifications (settings) here) vimstatepop() The problem here is when a plugin does something (like return, exit on error, etc) and doesn't do the vimstatepop(). Thus, vimstatepush() and vimstatepop() could be done automatically by vim (instead of explicitly by plugin authors). And, while I'm at it: I'd like beval to be a local rather than global. Regards, Chip Campbell -- 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
Re: cpo-=l full list
Thilo Six wrote:
Taylor Hedberg wrote the following on 25.12.2011 05:20
Hello Charles,
Charles E Campbell Jr, Sat 2011-12-24 @ 22:11:31-0500:
If I may repeat myself, what advantage does
set cpo-=a cpo-=A
have over
set cpo-=aA
???
From `:help :set-=`:
When the option is a list of flags, {value} must be
exactly as they appear in the option. Remove flags
one by one to avoid problems.
Removing the flags individually is guaranteed to work regardless of the
order and position in which the flags appear in the option string. This
is not true if you remove them in combination.
Thank you Taylor that i exactly what i thought of.
Charles here is a example:
:set cpo?
cpoptions=aABceFs
:set cpo-=aA
cpoptions=BceFs
so far so good. Now lets have a crazy user shuffling things around:
:set cpo?
cpoptions=ABFacespretty much default, just different order
:set cpo-=aA
:set cpo?
cpoptions=ABFaces
:set cpo-=a
:set cpo-=A
:set cpo?
cpoptions=BFces
OK, I'll include the change.
Thank you,
Chip Campbell
--
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
Re: cpo-=l full list
Thilo Six wrote: just an status update. ~/build/vim/runtime/autoload/netrw.vim 2011-12-10 s:cpo-=aA:cpo-=a cpo-=A: If I may repeat myself, what advantage does set cpo-=a cpo-=A have over set cpo-=aA ??? Regards, Chip Campbell -- 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
Re: manpageview rating dive
Benjamin R. Haskell wrote: On Wed, 31 Aug 2011, Charles Campbell wrote: Charles Campbell wrote: Hello! I recently checked my plugins' ratings: 08/09/11 script 677/279/10776: Manpageview.vim 08/31/11 script -133/1094/10866: Manpageview.vim This seems like an odd thing -- is this preparation for a general bombing of plugins' ratings? I should explain this a bit more. The rating for Manpageview on August 9, 2011 was 677, with 279 people having rated it, and 10776 having downloaded it. On August 31, 2011, the rating was -133, 1094 people having rated it, and 10866 having downloaded it. It is odd that Manpageview received -810 in karma when there were only 90 additional downloaders over that time period. Did irc have a anti-Chip attack? Is someone testing a bot to destroy multiple plugins' ratings? Can't find it currently, but someone mentioned in the not-so-distant past that some search engine(s) grabbed the down-vote URL when crawling www.vim.org. In this case, googling: site:www.vim.org inurl:unfulfilling (where 'unfulfilling' is the 'rating' value for a down-vote) comes up with exactly one result for me: ManPageView - Viewer for manpages, gnu info, perldoc, and php … With the link: (...'s to prevent clicking) http://.../scripts/script.php?script_id=489rating=unfulfilling And I may have accidentally just downvoted it myself, by hovering over the result (which pops up a preview). Seems like the ratings should only use $_POST (PHP var), but they appear to be using $_GET, too. Nice bit of sleuthing! So perhaps the large downvoting is due to bots such as google, yahoo, bing, etc., and I suppose Manpageview can expect a continuing more-of-the-same. Bram: any chance that this situation can be fixed? Regards, Chip -- 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
Re: a problem with syntax highlighting in regexp.c
Ben Schmidt wrote: I extracted a couple of lines from regexp.c (143,144): (vim 7.3.244) #define BRANCH 3 /* node Match this alternative, or the * next... */ and put them in a file junk.c. Then vim -u NONE -N --noplugin junk.c :syn on shows the comment-ending pair of characters, */, in error highlighting. No problem for me with Vim 7.3.219 and an updated syntax/c.vim which hasn't made it into the official runtimes yet. FYI: I found this due to my looking at line 2045, (2044,2045) No problems around that area for me either. So, if it's a bug, it's a new one! Well, a strange situation (its doing the same thing on my home computer, too, which is 7.3.244, although I'm about to update it) Regards, Chip Campbell -- 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
Re: Syntax highlighting unreasonable lags
Дмитрий Франк wrote: Hi. I very like Vim, thank you, but there's one thing in Vim that i really hate. I often use rather old notebook with processor Pentium M 1.6 GHz, and when i use Vim on it, i can't normally edit files *.vim and *.php : syntax highlighting for these filetypes is VERY SLOW. And i'm sure that 1.6 GHz is pretty enough for syntax highlighting. Some IDEs and just editors i tested works fine: SlickEdit, UltraEdit, PHP Expert Editor. I tested Vim both on Windows and Linux: lags the same. And other editors works fine. And this is Vim! Vim was always positioned as extremely fast editor, when compared with IDEs. But there's fact: IDE works fast, Vim is slow, on the same hardware. I believe that Vim handles syntax highlighting not in the best possible manner. I have to turn syntax off while editing *.vim and *.php files on this machine, and i very don't like this. I have two questions: 1) Do you have plans to improve syntax highlight handling, to make it faster? 2) Is there maybe simplified syntax files for *.vim and/or *.php files? Or any other way to solve this trouble without turning syntax off? You could try simplifying the syntax files yourself. The slowest portion of syntax highlighting involves syn match ... and syn region ...; ie. regular expression handling. To speed things up: a) copy a system version of the syntax file you're interested in to your home directory; ie. to $HOME/.vim/syntax or something like that. b) Remove all lines from your personal copy that have syn match ... and syn region in them, leaving only syn keyword .. lines to do the syntax highlighting. Although this operation will not produce the same highlighting as the unaltered files, and won't support syntax-based folding, I would expect it to produce faster syntax highlighting. As an easier item: look into :help syn-sync . Perhaps you can reduce maxlines. Syntax highlighting is known to be slow for loong lines. Try breaking any long lines up a bit (ie. those 100 characters in the line, as a rough criterion). BTW, your 1.6GHz machine should be fine with syntax highlighting as-is. Is it still too slow if you... vim -u NONE somefile.vim :set nocp :syn on I'm wondering if your slowdown is due to something other than just syntax highlighting. This method of startup is barebones; no plugins, no .vimrc, pretty much just syntax highlighting. Regards, Chip Campbell -- 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
Re: [bug][w32][netrw] doesn't autochange to the current working dir in netrw buffer
Yue Wu wrote: How to reproduce: :e c:/ then enter any subdirectory in netrw buffer withenter, then :pwd print current working directory, vim still says c:/ it is. gvim is got from vim offical site, OS is windows 2000. Hello, See if :he netrw_keepdir helps. (the default behavior follows that of the 6.x explorer) Regards, Chip Campbell -- 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
Re: [bug][w32][netrw] doesn't autochange to the current working dir in netrw buffer
Yue Wu wrote: Thanks, that's it. I think it should be on by default for convenience, what do you think? I do, too, and that option is used in my own .vimrc. While developing netrw's browser capability, that's how I had it. However, I caught grief about it from those wedded to 6.x's explorer's behavior. So, at least there's an option for it! Regards, Chip Campbell -- 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
Re: [patch] match does not Conceal items
Christian Brabandt wrote: Hi Bram! On So, 10 Apr 2011, Bram Moolenaar wrote: Can you explain what the effect is? Basically, I wanted to create a plugin that uses concealing for something like vertical folding. Perhaps you could look into foldcol.vim and see if that does what you want: http://mysite.verizon.net/astronaut/vim/index.html#FOLDCOL. It uses syntax rather than match, with the limitations thereof. Regards, Chip Campbell -- 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
Re: Color Support for :! and :Shell system command execution
Will Gray (graywh) wrote: On Mar 22, 1:27 pm, Charles Campbellcharles.e.campb...@nasa.gov wrote: Perhaps the AnsiEsc plugin which colorizes text according to ansi escape sequences does what you want; you can get the plugin from: http://vim.sourceforge.net/scripts/script.php?script_id=302 (stable) http://mysite.verizon.net/astronaut/vim/index.html#ANSIESC(cutting edge) He's asking about GVim's built-in dumb terminal, not a buffer. He should be able to redirect the output to a buffer. Chip Campbell -- 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
Re: editing DCL
Samuel Ferencik wrote: Hi, DCL is a scripting language for OpenVMS, whose lines of code must all start with a $. Here is a code excerpt (from http://www.eight-cubed.com/articles/dcl_standards.html): |||$ on warning then goto nopriv $ set on $ set process/privilege=(sysnam,sysprv) $!... $nopriv: $ write sys$output Required privs: SYSNAM, SYSPRV $ status = 36 $ goto exit $!... $exit: $ set process/privilege=(nosysnam,nosysprv) $ exit status + (0 * f$verify (old_verify)) | Is there any clever way that the following features could work with this kind of code? 1) dap (delete a paragraph): this currently deletes the whole source file - because there are no empty lines between paragraphs (an empty line must contain at least the $) 2) (indent a line): this indents the leading $ as well as the rest of the line; instead, the dollar should stay in column 1, and only the rest of the line should be indented 3) J (join lines); gqq (format the line): if multiple lines become one line, or vice versa, the dollars are not removed/inserted as they should be What I have come up with so far is using 'comments': :set comments=:$ This at least puts the $ sign on each new line. I suppose you could have a pair of maps; one of which removes all the leading $s, and the other would put them back: map F4 :%s/^\$//e map s-F4 :%s/^/$/e Furthermore, you could automate this if you're confident enough in their effects: au BufRead * if ft =~ dcl | :%s/^\$//e|endif au BufWrite * if ft =~ dcl|:s/^/$/e|endif You might wish to put these into a .vim/ftplugin/dcl.vim file (I'd have to guess at the actual OpenVMS directory, perhaps [wherever.vimfiles.ftplugin]dcl.vim ?). Of course, these are untested. Regards, Chip Campbell -- 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
Re: saveas - loads ft plugin - changes dir - wrong filename problem
frabjous wrote: Hi all, I'm here to report what looks like a bug to me. Hopefully I'm not wasting your time. Here are the conditions. 1. Edit a blank file with no ft set (and hence no filetype plugins loaded). 2. Attempt to save the file with an extension which causes a filetype plugin to be loaded. (It seems to help if the filename chosen has slashes in it for directories.) 3. The plugin in question must be one that changes the active directory (through a command like `lcd %:p:r` or `set autochdir`). 4. Then rather than saving the file with the filename specified in step 2, it saves the file under a seemingly random name, often using what appears to be a line of code from the plugin as if it were the filename (though not the same line as mentioned in line 3). Anyway, I've recorded an animated .gif of the apparent bug in action, which you can view here: http://people.umass.edu/phil592w-klement/vimbug.gif You can see the file is being saved with a very strange filename, and not all the one specified. I'm using 7.3 on Arch Linux (x86_64). I tried creating an empty file via :enew, saving it to /tmp/junk.tex, and that went as one would expect it should. I think that you need to track down which ftplugin is giving you problems. Given that you have what appears to be a line of text from it, perhaps you could do a search for that text and locate where that text came from -- perhaps that ftplugin is the one causing problems. Disable it (mv whatever.vim whatever.vvim) and try it out. If it the process still results in problems, then try disabling more ftplugins until you find your culprit. Alternatively, t may well be an unfortunate interaction with settings you may have, so try using vim -u NONE -N :set nocp :filetype plugin on :w /tmp/junk.tex :q and see if that creates your unwanted filename. Regards, Chip Campbell -- 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
Re: Patch 7.3.050
Bram Moolenaar wrote: Patch 7.3.050 Problem:The link script is clumsy. Solution: Use the --as-needed linker option if available. (Kirill A. Shutemov) Files: src/Makefile, src/auto/configure, src/config.mk.in, src/configure.in, src/link.sh On a Centos 5.2 system at work, patches 48-50 compiled and linked just fine. However, on my home computer with Fedora Core 11, its failing: link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly. gcc -L/usr/local/lib -Wl,--as-needed -o vim objects/buffer.o objects/blowfish.o objects/charset.o objects/diff.o objects/digraph.o objects/edit.o objects/eval.o objects/ex_cmds.o objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o objects/ex_getln.o objects/fileio.o objects/fold.o objects/getchar.o objects/hardcopy.o objects/hashtab.o objects/if_cscope.o objects/if_xcmdsrv.o objects/main.o objects/mark.o objects/memfile.o objects/memline.o objects/menu.o objects/message.o objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o objects/normal.o objects/ops.o objects/option.o objects/os_unix.o objects/pathdef.o objects/popupmnu.o objects/quickfix.o objects/regexp.o objects/screen.o objects/search.o objects/sha256.o objects/spell.o objects/syntax.o objects/tag.o objects/term.o objects/ui.o objects/undo.o objects/window.o objects/gui.o objects/gui_gtk.o objects/gui_gtk_x11.o objects/pty.o objects/gui_gtk_f.o objects/gui_beval.oobjects/if_python.o objects/py_config.o objects/netbeans.o objects/version.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lnsl -lselinux -lacl -lattr -lgpm -L/usr/lib64/python2.6/config -lpython2.6 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic objects/term.o: In function `set_termname': /home/cec/.SW/VIM/vim73/src/term.c:1696: undefined reference to `tgetflag' /home/cec/.SW/VIM/vim73/src/term.c:1699: undefined reference to `tgetflag' /home/cec/.SW/VIM/vim73/src/term.c:1702: undefined reference to `tgetflag' /home/cec/.SW/VIM/vim73/src/term.c:1705: undefined reference to `tgetflag' /home/cec/.SW/VIM/vim73/src/term.c:1708: undefined reference to `tgetflag' /home/cec/.SW/VIM/vim73/src/term.c:1731: undefined reference to `tgetnum' /home/cec/.SW/VIM/vim73/src/term.c:1733: undefined reference to `tgetnum' /home/cec/.SW/VIM/vim73/src/term.c:1740: undefined reference to `tgetnum' /home/cec/.SW/VIM/vim73/src/term.c:1743: undefined reference to `BC' /home/cec/.SW/VIM/vim73/src/term.c:1744: undefined reference to `UP' /home/cec/.SW/VIM/vim73/src/term.c:1747: undefined reference to `PC' objects/term.o: In function `tgetent_error': /home/cec/.SW/VIM/vim73/src/term.c:2158: undefined reference to `tgetent' /home/cec/.SW/VIM/vim73/src/term.c:2168: undefined reference to `tgetent' objects/term.o: In function `vim_tgetstr': /home/cec/.SW/VIM/vim73/src/term.c:2195: undefined reference to `tgetstr' objects/term.o: In function `getlinecol': /home/cec/.SW/VIM/vim73/src/term.c:2219: undefined reference to `tgetnum' /home/cec/.SW/VIM/vim73/src/term.c:2221: undefined reference to `tgetnum' objects/term.o: In function `out_str': /home/cec/.SW/VIM/vim73/src/term.c:2662: undefined reference to `tputs' objects/term.o: In function `term_windgoto': /home/cec/.SW/VIM/vim73/src/term.c:2682: undefined reference to `tgoto' objects/term.o: In function `term_cursor_right': /home/cec/.SW/VIM/vim73/src/term.c:2689: undefined reference to `tgoto' objects/term.o: In function `term_append_lines': /home/cec/.SW/VIM/vim73/src/term.c:2696: undefined reference to `tgoto' objects/term.o: In function `term_delete_lines': /home/cec/.SW/VIM/vim73/src/term.c:2703: undefined reference to `tgoto' objects/term.o: In function `term_set_winpos': /home/cec/.SW/VIM/vim73/src/term.c:2717: undefined reference to `tgoto' objects/term.o:/home/cec/.SW/VIM/vim73/src/term.c:2725: more undefined references to `tgoto' follow objects/term.o: In function `clear_termcodes': /home/cec/.SW/VIM/vim73/src/term.c:3563: undefined reference to `BC' /home/cec/.SW/VIM/vim73/src/term.c:3564: undefined reference to `UP' /home/cec/.SW/VIM/vim73/src/term.c:3565: undefined reference to `PC' /home/cec/.SW/VIM/vim73/src/term.c:3566: undefined reference to `ospeed' collect2: ld returned 1 exit status link.sh: Linking failed gmake: *** [vim] Error 1 Regards, Chip Campbell -- 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
Re: Patch 7.3.024
Bram Moolenaar wrote: Patch 7.3.024 Problem:Named signs do not use a negative number as intended. Solution: Fix the numbering of named signs. (Xavier de Gaye) Files: src/ex_cmds.c Hello, This patch is causing vanishing signs syndrome. Here's a test procedure: When in .../vim73/src, ./vim -g -N -u NONE -S tst.vim where tst.vim is: e! main.c 169 sign define TestSign icon=../pixmaps/tb_close.xpm sign place 1234 line=169 name=TestSign file=main.c With vim 7.3.1-23, the tb_close.xpm icon shows up on line 169 of main.c . With vim 7.3.1-24, a plain block is placed there instead. Regards, Chip Campbell -- 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
Re: sort bug?
Bee wrote: sort bug? vim 7.3.27 Linux vim 7.3.21 Mac 10.4.11 Select the lines between the rules (including the blank lines) and sort: ','sort n 1-2-3-4-5-6 xxx yyy: 0 xxx yyy: 1 xxx yyy: 2 xxx yyy: 3 xxx yyy: 4 xxx yyy: 5 xxx yyy: 6 xxx yyy: 7 xxx yyy: 8 xxx yyy: 9 1-2-3-4-5-6 The result is: 1-2-3-4-5-6 xxx yyy: 0 xxx yyy: 1 xxx yyy: 2 xxx yyy: 3 xxx yyy: 4 xxx yyy: 5 xxx yyy: 6 xxx yyy: 7 xxx yyy: 8 xxx yyy: 9 1-2-3-4-5-6 I would expect this and it is what I get when using the shell: ','!sort -n 1-2-3-4-5-6 xxx yyy: 0 xxx yyy: 1 xxx yyy: 2 xxx yyy: 3 xxx yyy: 4 xxx yyy: 5 xxx yyy: 6 xxx yyy: 7 xxx yyy: 8 xxx yyy: 9 1-2-3-4-5-6 I tried your example and was unable to duplicate the problem. Have you tried putting this in a file, say sort.test: vim -u NONE -N sort.test :%sort I tried that, and I tried using V and selecting all the lines, and each time I got the I would expect this... result. Regards, Chip Campbell -- 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
Re: make -f make_cyg.mak with vim 7.3
Christian J. Robinson wrote: On Fri, 27 Aug 2010, Charles E Campbell Jr wrote: gcc: The -mno_cygwin flag has been removed; use a mingw targeted cross-compiler. on the first file it tries to compile (blowfish.o), and, sad to say, no gvim.exe . I had to edit Make_cyg.mak to use gcc-3 instead of just gcc, plus add -L/lib/w32api to EXTRA_LIBS. I mentioned this on this list during the 7.3 development, and Bram added this to the commentary at the top of Make_cyg.mak. I had to tweak GvimExt/Make_ming.mak more extensively, which is called by Make_cyg.mak. As far as I can tell, Cygwin doesn't come with MinGW. It has some MinGW stuff, but I can't find an actual MinGW compiler. Thank you, Christian! I'd given up and gotten the pre-built Windows version from vim.sf.net that Bram had built. I confess that I didn't even know about gcc-3. Regards, Chip Campbell -- 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
make -f make_cyg.mak with vim 7.3
Hello! I usually build vim myself with cygwin + make -f make_cyg.mak . However, I'm getting a message gcc: The -mno_cygwin flag has been removed; use a mingw targeted cross-compiler. on the first file it tries to compile (blowfish.o), and, sad to say, no gvim.exe . Regards, Chip Campbell -- 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
Re: make -f make_cyg.mak with vim 7.3
Charles E Campbell Jr wrote: Charles E Campbell Jr wrote: Hello! I usually build vim myself with cygwin + make -f make_cyg.mak . However, I'm getting a message gcc: The -mno_cygwin flag has been removed; use a mingw targeted cross-compiler. on the first file it tries to compile (blowfish.o), and, sad to say, no gvim.exe . I read in make_cyg.mak a suggestion to try make_ming.mak, so here's my try: errors about no definition for _MAX_PATH. I added _MAX_PATH=1024 to DEFINES. Next problem: conflicting types for gettimeofday (main.c:3326 vs time.h:74). Interim solution: #if 0 ... #endif around gettimeofday in main.c . Of course, I don't know yet if it'll link. Next problem: netbeans.c:204 storage size of 'server' isn't known . There are more errors, too; attempting disabling netbeans. Next problem: xxd still uses Make_cyg.mak, which in turn complains about -mno_cygwin. Next problem: lots of undefined references. Here's my list of undefined references: (attempted to build gvim.exe) gobj/os_win32.o:os_win32.c:(.text+0x43c): undefined reference to `_wcsicmp' gobj/os_win32.o:os_win32.c:(.text+0x617): undefined reference to `__wfopen' gobj/os_win32.o:os_win32.c:(.text+0x6b5): undefined reference to `__wopen' gobj/os_mswin.o:os_mswin.c:(.text+0x913): undefined reference to `_IID_IPersistFile' gobj/os_mswin.o:os_mswin.c:(.text+0x20af): undefined reference to `__wstat' gobj/os_mswin.o:os_mswin.c:(.text+0x2178): undefined reference to `__wchdir' gobj/os_mswin.o:os_mswin.c:(.text+0x2b83): undefined reference to `__wfullpath' gobj/if_cscope.o:if_cscope.c:(.text+0x1e37): undefined reference to `__open_osfhandle' gobj/if_cscope.o:if_cscope.c:(.text+0x1e7c): undefined reference to `__open_osfhandle' collect2: ld returned 1 exit status make: *** [gvim.exe] Error 1 -- 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
Re: Multiple conceals collapse to single character
Bram Moolenaar wrote:
Charles Campbell wrote:
I tried the following trick:
syn match texGreek '\\alpha\' contained conceal cchar=á nextgroup=texGreek2
syn match texGreek2 '\\alpha\' contained conceal cchar=á nextgroup=texGreek
So $\alpha\alpha$ has the first \alpha as texGreek, and the second one
as texGreek2 . Unfortunately, although the syntax highlighting treated
the two differently, the conceal code still merges the two, using only
the one á instead of what I'd hoped (áá).
Makes sense. We can get the ID of the syntax item, and use a change in
that as a signal to display the conceal character.
I have implemented that, please try it out and let us know.
If this doesn't work as intended, we should roll it back.
Soon we can't make incompatible changes, thus please let's figure out
how this should work very soon!
Hello, Bram!
I've attached a modified syntax/tex.vim which makes a start at
supporting Greek, subscripts, and superscripts. Its not complete:
* I haven't supported a^{b*c} for example; I'll have to try making
regions for superscripts and for subscripts. Probably I can do
something about this.
* Some symbols just aren't available via utf-8; for example, Euler's
equation: e^{i \pi} = -1 ; there's no superscripted or subscripted
Greek available. (AFAIK)
* Subscripts are even more restrictive in utf-8; there's a good set of
superscripted a-zA-W (missing the q and Q, though), but for scripts,
only aeiou and 0-9 are available (again, AFAIK).
* I haven't begun accent support; I think utf-8 does a very good job of
supporting accented characters, and that's next on my expanding list
of things to do for syntax/tex.vim
This trick doubles the amount of syntax rules, of course, so IMHO its
not ideal, but its working! Thank you for the modification.
Regards,
Chip Campbell
--
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
Re: Unsubscrible vim_dev
John Beckett wrote: Simson Liu wrote: I have subscrible the list with new gmail box. But I can't unsubscrible the list with my current work mail box. I have sent the vim-dev-unsubscr...@vim.org the empty mail message many times, but have no any effect. So other managers don't have to look, I have done the unsubscribe. But what if he didn't want to unsubscribe, but wanted to unscribble? :) Chip Campbell -- 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
Re: mail from new wiki pages
John Beckett wrote: John Beckett wrote: You can actually watch pages before they are created, however, that's a bit exotic, so I would recommend creating each relevant Script:xxx page then watching it. On second thoughts, it should be pretty easy to watch the pages that are NOT yet created, if you want that option. In your watchlist, click the link: Edit raw watchlist I believe you could just add lines like the following: Script:123 Script:4321 and then you would be notified if those pages are ever created or edited. Thank you, John! I've done the watchlist thing -- as of now, no pages have been created by anyone, so I did need this ability. Pretty neat. Regards, Chip Campbell -- 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 To unsubscribe from this group, send email to vim_dev+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: copy a map (in order to restore it later)
Hari Krishna Dara wrote: I need to be able to create an imap for Tab when my plugin is toggled on, and unmap it when it is toggled off. What I would prefer is to restore the previous map of Tab rather than simply unmap it, but there is no straight-forward way to capture the existing map such that it can be restored later...[snip] You could see if cecutil's SaveUserMaps() and RestoreUserMaps() functions that I wrote will help you. In particular: SaveUserMaps(n,,tab,hkd) SaveUserMaps(bn,,tab,hkd) will save normal mode mappings for tabs (if any); the first one for ordinary normal-mode maps, and the second one will append buffer-qualified maps for tab. A RestoreUserMaps(hkd) will then restore those maps (again, if any). You can get a copy from my website: http://mysite.verizon.net/astronaut/vim/index.html#CECUTIL . The hkd is a suffix used to differentiate save-map groups (ie. in script space, there's a s:restoreusermaps_hkd variable used). Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: BUG: Vimball: Extra \ in folder names with space under Windows in .VimballRecord
KF Leong wrote: I am testing to use Vimball to package a plugin and when trying the RmVimball command, the installed plugin files are not removed. Looking through the .VimballRecord file, the delete() entries added extra backslash (\) to the folder names, thus making the delete() command to not delete the file. [snip] I'll look into it! Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: scim_bridge_client_imcontext_set_cursor_location -- an annoying error message
Tony Mechelynck wrote: On 10/06/09 21:31, Charles Campbell wrote: Hello! In running a not too trivial script I've written, I keep getting messages of the following sort (even when the script is quiescent, ie. after its opened its 8 windows): (Centos 5.2/Linux/gtk) CALC/ xorn? An IOException occurred at scim_bridge_client_imcontext_set_cursor_location () ...snip... An IOException occurred at I don't remember ever having seen those messages on my system, but scim is one possible XIM; it has settings for a lot of languages (including English (American)!). Are you sure your Input Method settings are correct? Or at least that they won't cause you trouble if you aren't aware that an IM is running? You may want to check the settings by clicking right, then SCIM setup, on the keyboard-like icon in the system tray (or at least that's what it looks like to me on my KDE3 winmanager). In Vim, you may want to :setlocal imi=0 ims=-1 in any window where you want neither IM nor keymap handling at the moment. I'll definitely do that. I probably next-to-never use deliberately scim (mostly its ctrl-space to toggle back to normal because of a typo). Hopefully I won't see those messages again! As far as having the correct settings, I'm afraid that I have no idea -- they're whatever the defaults happen to be. That keyboard icon doesn't look very keyboard-ish on my screen, but it did bring up the SCIM setup you mentioned. Thank you, Tony! Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
building vim with perl support
Hello! I recently got a 64-bit computer; it has perl supported. However, the configure script doesn't appear to be picking up on the location of the header files: (there were about 100 error messages) /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/EXTERN.h /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/perl.h /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/XSUB.h (etc) I then modified vim's Makefile to use -I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE in GUI_INC_LOC; this cleaned up many compiler errors, but I'm now getting /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/proto.h:509: error: expected declaration specifiers or ‘...’ before ‘off64_t’ /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/proto.h:514: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘Perl_do_sysseek’ /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/proto.h:517: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘Perl_do_tell’ /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/proto.h:4248: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘Perl_PerlIO_tell’ /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/proto.h:4249: error: expected declaration specifiers or ‘...’ before ‘off64_t’ Simply including /usr/include/sys/types.h doesn't fix this (that file is where the typedef for off64_t is). I've tried various other things, but still end up with the same set of error messages. Any suggestions? Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
getting dropped from the mailing list
Hello! This is the second time I've stopped receiving emails from vim_dev (its happened to me once on vim_use) this past week, unless there's actually been no activity on this group for two days. The last time I unsubscribed (successfully) from both vim_use and vim_dev and then re-subscribed. That re-activated the email. Is anyone else having these problems, and is there a better solution than unsubscribing and resubscribing? Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Concel and Ownsyntax patch FINALLY updated...
John Beckett wrote: Vince Negri wrote: The page on google groups needs a small update to fix the reference to 7.0.35. Good point, but please tell me exactly what text would be appropriate. It currently reads: Status: works, but only in Vim 6.4.10 and 7.0.35 Will we just mention the most recent patch? How about: Status: works, patch based on Vim 7.2.141 I'm hoping Yakov will update the wiki tip in due course: http://vim.wikia.com/wiki/Patch_to_conceal_parts_of_lines Yakov said something in that tip about AnsiEsc that needs correcting -- AnsiEsc handles ansi escape sequences with conceal if your vim supports it; it uses Ignore highlighting otherwise. Should I correct it or let Yakov do it? Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.2.121
Bram Moolenaar wrote: Patch 7.2.121 Problem:In gvim !grep a *.c spews out a lot of text that can't be stopped with CTRL-C. Solution: When looping to read and show text, do check for typed characters every two seconds. Files: src/os_unix.c snip Patches 1-120 are available via ftp from ftp.nluug.nl (pub/vim/patches/7.2/...), but 121 is missing. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
Gary Johnson wrote: On 2009-02-12, Tony Mechelynck antoine.mechely...@gmail.com wrote: And then there are people like me who can un- .zip files if they have to, but prefer to gunzip them (un- .gz), which is the Unix standard (as opposed to the Microsoft Megabucks LoseDough standard). And note that if the right tools are present (gunzip in the $PATH), a compressed vimball (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily as an ordinary one. Yes, it will, except that when you open the gzipped file with vim someplugin.vba.gz the original file is automatically gunzipped and replaced by the gunzipped version, e.g., somefile.vba. I wish the vimball plugin wouldn't do that. If I'm going to keep the archive around for a while, I'd rather keep it in its gzipped form. Besides, I should be able to use vim to just look at a file without modifying it. The reason why it does that: one can't source a buffer, and one can't source a compressed file. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
Matt Wozniski wrote: But let's not forget that they have significant disadvantages, too... Vimballs made with new versions of the plugin don't work on older vims. There's been one problem with that -- 7.0 vimball doesn't handle the later vimball versions. 7.1 and has been compatible; newer vimballs have largely fixed small problems, not introduced incompatibilities. Vimball was done by request, consequently it didn't have much feedback before it went into 7.0. Considering that those writing and distributing scripts are much more likely to be at the bleeding edge than the users who download those scripts, they're quite likely to wind up distributing something that many of their users can't use. It's also not possible to include binary files in a vimball, or fines with different encodings, or even files with different line endings. I think that I could get vimball to handle binary files, which would mean that zip files could be embedded. However, most plugins don't need binary files (those with icons for signs would be an exception). IMHO, this makes them significantly less useful than zip files, since we could add those 3 nice features (automatic :helptags, extracted to first writable directory, uninstallable) to zip files without having to tolerate the disadvantages that vimball doesn't seem to be able to overcome... Really, it seems that depending on an unzip program being on the computer is far better than implementing our own barely-featured interface-unstable self-extracting-archive-that-wants-to-be-a-zipfile. I think that an effort to nicely encapsulate the platform differences and such of handling zipfiles, or possibly even one day writing a vimscript unzipper, would be a better use of our resources than continuing to maintain vimball. And putting these vim-specific features into zip files would be real popular with the rest of the zip community, I'm sure. At the very least, it'd be bloat for most such users. Then some other applications would want to chime in with their own application specific features. It'd be better to have a plugin that acted as a wrapper around zip to support the additional features that vimball provides. Probably could be a modification to the current zip handling plugin. The same sort of mods could be done with tar and the tar handling plugin, too. I'll consider doing it (after taxes and fafsas). Chip --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Race condition during file saving
Nikolai Weibull wrote: On Sun, Jan 4, 2009 at 16:26, Adam Osuchowski ad...@zonk.pl wrote: Nikolai Weibull wrote: I haven't really understood what the problem is (I don't believe that there actually is one), There is a non-zero time period between open file and write complete content. Because vim truncate file while opening (O_TRUNC), another process which would like to read it can hit in the moment when file will be empty. Yeah, so? That's not a bug. File systems are, generally, not databases with ACID properties. They don't provide transactions (at the level we're discussing). but would opening the file exclusively solve the problem? Do you mean O_EXCL flag to open syscall? It doesn't protect against such a situation. It only guarantee that file doesn't exist prior to call open in atomic manner. No, I mean both O_EXCL (so that a file hasn't been created in between the time the original file has been renamed and the new one opened - a case so far not mentioned (or?)) and flock:ing it (but, as I understand from the man page, this doesn't seem to be very interesting either). If you're talking Unix/Linux/etc -- flock is a cooperative file locking mechanism, and processes which ignore it are not impeded. Look into mandatory file locking (the mand option to mount). Mandatory file locking is kernel enforced, and not even root apparently can force its way through. Mandatory file locking by vim would not be practical, as it generally requires root access to set up, and only involves files on the mandatory-filelocking mounted device. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Race condition during file saving
Nikolai Weibull wrote: On Sun, Jan 4, 2009 at 23:19, Charles E. Campbell, Jr. drc...@campbellfamily.biz wrote: Nikolai Weibull wrote: No, I mean both O_EXCL (so that a file hasn't been created in between the time the original file has been renamed and the new one opened - a case so far not mentioned (or?)) and flock:ing it (but, as I understand from the man page, this doesn't seem to be very interesting either). If you're talking Unix/Linux/etc -- flock is a cooperative file locking mechanism, and processes which ignore it are not impeded. Just to make sure, did you read the part where I wrote [flock] doesn't seem to be very interesting either? I just want to know what your intentions were. Was it simply to fill in extra information about why I wrote that? Or did it seem like I didn't know what I was talking about and you wrote this reply to correct me? I'm finding that I get a lot of replys, especially at work, where I get the feeling that my mail hasn't really been read through. A classic is where you ask someone two questions and you get a reply with an answer for the first one. Or where you answer two questions and they restate the second one in their reply. Either way, I really don't think we have a problem to fix. I /want/ to be able to read what a program is writing to a file, mid-write. Generally, when a long process is executing I want to be able to tell what's being written. If you're writing to a file that another program critically needs /that's/ your problem. Not whether you made sure to set up some intricate locking mechanism or not. Nikolai -- you're getting a bit sensitive here -- it was simply to fill in extra information..., as you hadn't explained why flock wasn't interesting. Plus I added the mandatory kernel-enforced locking information. Likely areas for problems like this concern cooperative editing (ie. multiple people editing the same file) and editing log files (or other files which are potentially being written to by some other program). Vim isn't designed for cooperative editing; I seem to recall it being on a wishlist, though. Editing log files is problematic because they generally aren't using mandatory file locking. Personally, I agree with you that there's not a problem to fix; at most, there's new behavior (that wishlist stuff) that someone may want. To avoid the need for cooperative editing, use cvs/git/etc and use separate copies and repositories. Editing log files is likely to remain problematic and requires more than just vim to change (unless the logging process already uses flock, perhaps I'll look into it sometime). Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: mac-osx and open
Nico Weber wrote: Hi Charles, On 09.11.2008, at 16:32, Charles E. Campbell, Jr. wrote: I was browsing the wiki -- and I noticed the tip Preview current HTML in browser on Mac OS X (well, a comment to it does): let g:netrw_browsex_viewer = 'open' so that the viewer triggered by x in the netrw browser will work on a mac. I'm not a mac user (yet), so for you mac user types: Would it be a good idea to use open if has(gui_mac) is true? This is probably better discussed on vim_mac, but: Yes, it's a good idea to use open, but as far as I understand, that's what's already happening. From the netrw.vim that ships with the latest MacVim snapshot: elseif has(macunix) executable(open) call Decho(exe silent !open .shellescape(fname,1). .redir) exe silent !open .shellescape(fname,1). .redir If I remember correctly, you added that about a year ago after I sent you a patch. So I guess the wiki is just outdated. I was thinking that I'd done something -- but searcing for gui_mac wasn't finding anything. I'm guessing that macunix is likely to be better, anyway. Glad not to need to do anything! and thanks (probably again) for that patch. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
Tony Mechelynck wrote: On 18/08/08 22:15, Charles Campbell wrote: Hello! I've issued a new plugin on my website: http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses the signs capability of huge vim to give relative numbering. After some comment period I expect to release it on vim.sf.net. I'd like to mention the relative numbering patch in my document -- would someone please tell me where that patch is again? [...] It's been sent to the vim_dev and vim_use lists as an attachment to a mail titled Re: 'relativenumber' patch updated for Vim 7.2, by Markus Heidelberg, dated 2008-08-11 23:27:07 +0200. (Beware: The same thread has an earlier 7.2 version of the same patch.) Thank you, Tony -- I found the post attachment, and I now have a link to it in my document. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
sc wrote: On Monday 18 August 2008 15:15, Charles Campbell wrote: Hello! I've issued a new plugin on my website: http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses the signs capability of huge vim to give relative numbering. After some comment period I expect to release it on vim.sf.net. I'd like to mention the relative numbering patch in my document -- would someone please tell me where that patch is again? And, as you may notice, I think I've now got a way to respond again to messages on the mailing list. why is the section labeled Rndm? Whoops! Looks like you caught a cutpaste error. I'll fix it. Thank you, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netrw v126 testing -- need help!
Derek Tattersall wrote: On Jul 7, 11:05 pm, Charles E. Campbell, Jr. [EMAIL PROTECTED] wrote: Hello, I'm just beginning a semi-automated test suite -- I expect that that will help enormously sometime in the misty future. I'll be going through the commands and trying to build the tests, checking netrw as I go. However, for now: Please test netrw v126g! Its available via my website: http://mysite.verizon.net/astronaut/vim/index.html#NETRW Note that v 126 fails when used with vim 7.1.330. The error message disappeared too quickly for me to capture it. Will progression to v 126 cause vim 7.1 to become unusable? Bram would like netrw released so he can release vim 7.2b and I'm going to be gone for two weeks starting next week (and will be nowhere near electricity let alone a computer). The changes have been to put fnameescape()s and shellescape()s in where appropriate -- so you'll need vim 7.2a with patches 1-13 (its up to #16 as of this writing). I'm planning on releasing netrw to Bram at the end of this week. v126g (and later) will require vim 7.2a.13 (or later). v7.1 of vim comes with an earlier version of netrw that works with v7.1. Once a release has been made, that release is no longer modified, so vim v7.1 is not going to be unusable -- its as usable now as ever. It does mean that you can't upgrade v7.1 with plugins that use new features, one of which is improved security functions. The shellescape() function, in particular, was itself upgraded in v7.2a's patch#13. Netrw v126g uses that enhancement, hence to use it requires the upgraded vim. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
netrw v126 testing -- need help!
Hello, I'm just beginning a semi-automated test suite -- I expect that that will help enormously sometime in the misty future. I'll be going through the commands and trying to build the tests, checking netrw as I go. However, for now: Please test netrw v126g! Its available via my website: http://mysite.verizon.net/astronaut/vim/index.html#NETRW Bram would like netrw released so he can release vim 7.2b and I'm going to be gone for two weeks starting next week (and will be nowhere near electricity let alone a computer). The changes have been to put fnameescape()s and shellescape()s in where appropriate -- so you'll need vim 7.2a with patches 1-13 (its up to #16 as of this writing). I'm planning on releasing netrw to Bram at the end of this week. Thank you for helping, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Syntax highlighting through comment hash for sh
Pascal Christoph wrote: Hello you guys-making-the-most-useful-tool-in-VR (of course I am not speaking only of myself), proud to have found a little thing that, be fixed, would improve the improved vi even a nearly unsubstantial-tiny bit more: If you use syntax highlighting, and programm shell scripts, then there is a tiny misinterpretation, an issue with the comment-sign (hash) '#' : v98 of syntax/sh.vim has had this since mid-March; it may have been inserted earlier. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] fix $(..) and $((..)) syntax highlighting for /bin/sh
Pádraig Brady wrote: Currently for /bin/sh scripts, $(command) and $((1+1)) are marked as errors. These constructs are POSIX compliant and supported by dash and bash at least. I contend that erroneously warning users away from these valid constructs is much worse than not flagging them as errors on the dwindling non POSIX compliant shells. Read :help ft-sh-syntax , in particular lines 2419-2435 . FYI -- bash is not dwindling. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
Ben Schmidt wrote: Another that could conceivably be useful would be a random number function. A low quality PRNG would do just fine. This could be used in Vim for editing data files for testing purposes, etc. Not that I object to a built-in PRNG to vim; however, writing a plugin to do it wasn't that difficult. I've provided Rndm.vim (available at my website) and Rndm.vim also accompanies Mines.vim (http://vim.sourceforge.net/scripts/script.php?script_id=551) if you're interested. Of course, Abs() and Sgn() are even easier... Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
Mikołaj Machowski wrote: Dnia 10-06-2008 o godz. 6:04 Gautam Iyer napisał(a): On Tue, Jun 10, 2008 at 01:55:04PM +1000, John Beckett wrote: It would be a pointless waste of development time to do much more with floats in Vim, IMHO. I *strongly* agree! Apart from the basic operations, the rest can be left to vim-perl/python/ruby/etc. Please don't bloat Vim. Strongly agree too. Asked for floor/ceil/trunc/round as *strictly* related to floating point operations, introduction of the rest is waste of precious developer time. And, for variety -- I strongly disagree! Maintaining floating point functions such as sin(), cos(), etc -- well, those are extremely simple function calls to make to library functions that compilers already provide, so it wouldn't surprise me if they were written-once-never-touched-again functions. Extra size would come from the often dynamically loaded shared libraries -- ie. providing such functions would only barely increase the size of vim (although they could increase the runtime image size, but only if the functions were actually invoked). Whereas, requiring a vim to include the interfaces to python/ruby/pick-your-poison ... well, now you're talking real bloat (as in increasing the vim executable size). Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
Tony Mechelynck wrote: On 10/06/08 15:09, Charles E Campbell Jr wrote: [...] Whereas, requiring a vim to include the interfaces to python/ruby/pick-your-poison ... well, now you're talking real bloat (as in increasing the vim executable size). Regards, Chip Campbell Well, like you I think, I believe that vim-script is usually quite enough for most of the things one would want to do with Vim; but I have seen people who apparently cannot think of programming Vim in other than Perl or Python (etc.). As I think you know, for people who think of such interfaces as useless bloat, they can be excluded bodily at compile-time, and compiling Vim is not really difficult. The only bloat then would be in sources which are left out of the executable, either because the modules in question are simply not compiled, or because, in included modules, the instructions in question are in the false branch of some #ifdef; and I believe that such source-only bloat can be tolerated. I agree that vim-script is usually quite enough..., and I understand that there are those who prefer Perl/Python/etc. I probably misstated my point, which I intended to be that worrying about the few extra lines of source to support sin()/cos()/etc in vim is misplaced -- maintenance would be nearly non-existent, the interface code would be tiny, runtime image size would likely be affected only if the functions were invoked, and that the counter-proposal to just use python involves considerably more bytes in the runtime image -- without invoking python. Plus a lot of trouble for anyone who doesn't happen to have python compiled for their system or perhaps doesn't know how to compile python support into vim (or whichever external program is proposed: perl, ruby, ...). I myself happen to have both python and perl on my linux boxes plus generally have perl support compiled into my vim executable, so this isn't a difficulty I'd have myself. Now, the contention that a text editor just shouldn't have sin()/cos()/floating-point support; that's a different matter. Personally, I think it depends on what an individual wants to do. For example, consider someone who wishes to present coordinates in both rectangular and polar forms. Perhaps someone would like to do some fancy textwork and have it justified inside some mathematically defined shape (cirles/ellipses) -- maybe even provide a plugin to do such. I know that in the case of circles/ellipses one could likely do something with the Bresenham integer-only algorithm (I've provided a circle/ellipse drawing tool with DrawIt), but that requires knowledge about that type of algorithm. Perhaps one would like to provide a small spreadsheet capability in vim, to crosscheck or spot-check output to a file... Bram has already mentioned ease of doing something with columns of numbers. However, I'd agree that there shouldn't be any effort devoted to supporting special math functions in vim (ie. Bessel functions, parabolic cylinder functions, elliptical functions, ...) -- just the small interfaces to those functions that come with most compilers (trig, log, exponential). And, as an off-subject item: I'd really like to have Vince Negri's conceal/ownsyntax patch incorporated! Working with LaTeX would be so much better... --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
Mikolaj Machowski wrote: Things works, thanks :) Few things I'd like to see explained (fixed, implemented?): 1. Once a float, always a float. Don't see way to make float other type of data - string, integer. At least one can convert floats to strings: :let x=1.3 :echo type(string(x)) Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vimscript compiled
Milan Vancura wrote:
#include stdio.h
#include stdlib.h
int main()
{
system(gvim -c script.vim);
return 0;
}
:- Thank you for lenghtening my life with 10 minutes of laugh!
It remindes me my favorite IRC citation:
A: Hi all, I'm playing with datetime functions. Can someone help me, please?
I
need a function which converts Mar to 3.
B: try strlen()
Sounds like a good solution to me! :)
Chip
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: vimscript compiled
epanda wrote:
I have done a script but I don't want it to be interpreted.
Is it possible to convert [gvim -c script.vim] into
[oneExeCompiled.exe]
Following provided somewhat facetiously:
#include stdio.h
#include stdlib.h
int main()
{
system(gvim -c script.vim);
return 0;
}
If you're asking for a vim script compiler, as opposed to vim's internal
interpreter, there isn't one. Such a beastie would have to include all
of vim plus the ability to compile vimscript. I haven't looked enough
to figure out if vim's interpreter is even a byte-code interpreter
(which is sort of in-between a compiler and a plain interpreter).
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
syntax handling of continuations (a proposal for an extra syntax item) -- request-for-comment
Hello! It always has seemed to me to be a bit of a battle to handle continued lines. So that you know what I mean: C: code line\ more code to be treated as one line Matlab: code line... more code to be treated as one line Vim: code line \ more code to be treated as one line etc. It would make syntax file writing considerably simpler (and, in the case of vim script, there's still problems) if there was a statement such as: C: syntax continue \\$ Matlab: syntax continue ...$ Vim: syntax continue ^\s*\\ The idea is that if the continue pattern is encountered, then syntax highlighting would proceed as if there was no intervening newline. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
Ben Schmidt wrote:
Charles E Campbell Jr wrote:
Ben Schmidt wrote:
Ben Schmidt wrote:
OTOH, with there is no ambiguity because the various uses of are
strictly separated:
Actually, there still is ambiguity unless one requires a decimal point or
exponent. Without that restriction
123.456
could still mean 123 (or 123.0) concatenated with 456. But with the
restriction
123
is invalid. Not sure whether that's desirable. Probably the lesser of two
evils.
Of course, it needs to be enforced that printf and such functions either
omit the
ampersand for floats which happen to be integers (probably undesirable) or
always
append a '.0' in this case.
Would wrapping floats in braces be a better syntax? I don't think this
would clash
with anything: dictionaries require keys followed by colons which don't
occur in
floats, and a float is also an invalid variable or function name due to
starting
with a digit or sign (+/-) so couldn't be used as part of curly-brace
variable or
function names. E.g.
:let myfloat={12.52}
:let mybig={1234e56}
:let myintegerfloat={123}
To me, this is nicer than a leading , and avoids the nasty restriction of
needing
a decimal point all the time/ambiguity of decimal point vs. concatenation.
Actually, to clarify, my proposal is that a set of curly braces is taken to
represent a float if and only if it is (1) not preceded by a valid variable
name
character and (2) contains a valid float.
I.e. floats:
{+123.456}
{-123}
{123e-4}
{123.456}something_to_concatenate
non-floats:
{dictionary: 'value'}
variable_name_with_number_{123}
variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
variable_name_with_six_digits_here_{123.456}
{variable_name_from_a_variable}
{10x?'variable_1':'variable_2'}
combination!:
variable_name_with_float_expression_giving_{{0.55}some_float?'true':'false'}
variable_name_with_float_that_prints_as_integer_{{123}}
invalid:
variable_name_with_punctuation_due_to_float_{{123.456}}
I think it works unambiguously and sensibly, though, of course, you can
still do
dumb things if you try hard enough! But I don't think it breaks anything
that
currently works (even if what currently works is dumb)!
let x12=3
echo x{1.2}
Works quite nicely -- and is ambiguous with respect to floating point
overloading.
No, it isn't ambiguous. By (1) of my definition, this is not to be
interpreted as
a float. Furthermore, a variable with name 'x1.2' is invalid. A more
confusing
example would be
let e=3
let x132=4
echo x{1e2}
but it still isn't ambiguous by my definition.
A variable with the name 'x1.2' is invalid, but: 1.2 currently - 12,
and x12 is not invalid. But, as you said, the {} in my example is being
preceded by a valid variable name character, so my objection is nullified.
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Bram Moolenaar wrote: Birgi Tamersoy wrote: Hey everybody, Apparently many students (like me) are interested in this project. So, I decided to start a new thread where we can talk about the challenges in the project and how to solve them. I went over previous posts to include all the related ideas in this new thread. Thanks for starting this discussion. Here are a few initial thoughts about the project: I think *speed* is one of the major concerns. Basically, editing speed should not be affected at all by the code checker. Running a compiler in the background with a temporary copy of the code, parsing the error messages and highlighting the related parts is one of the intuitive solutions (which is also implemented in Emacs Flymake). Although this is a to-the-point solution it will be quite slow according to your project size. *Incremental compiling* can be used to enhance this method. Rather than compiling the whole code every time, the checker can compile only the necessary parts. Right now, I don't know if this is supported by the majority of the compilers or the interpreters. Using a *built-in parser* is solution emphasized by Charles E. Campbell Jr in a related post. A parser would be perfect for syntax- checking, but I think the code checker should also detect errors like a misspelled library name. In my opinion the errors and warnings that are highlighted must be 99% correct. It's very annoying if you get an error for something that is not wrong, or compiling fails with an error but the error was not highlighted. I don't think that a built-in parser will be able to reach this accuracy, except perhaps for some simple languages. There are yacc grammars available for several languages, including C, Matlab, and Lisp. The advantage of this approach is similar to the advantage of the syntax highlighting engine; its not particularly tied to any language. I mostly program in C/Matlab myself, but I know there's plenty of other languages and users out there (python, perl, sh/csh/ksh/zsh/tcsh/..., java, lisp, scheme, ada, matlab, ... apologies to those folks for whom I've missed mentioning their favorites) and tying a major feature of vim to one or two languages is probably not going to be universally appreciated. What I was advocating was the ability to use LALR grammars (read: yacc/bison) so that vim isn't tied to a particular language and, in fact, can be extended to cover future languages. The primary disadvantage is that effectively writing a new yacc/bison is not a small task. I have a real thick book about writing a yacc-like parser somewhere; if anyone's interested, I could look up its ISBN. Probably one could set up pipes to an external yacc or bison and avoid that problem, but that introduces the external sort type of problems people have had until vimgrep. If, in fact, a LALR parser is embedded a future GSOC would involve using it to do more accurate syntax highlighting. To support C++ and other object oriented languages would also involve symbol table handling. Sounds like a huge project to me to make it truly generic. I'm not sure I would like it; especially if I got yammered at for incomplete code. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch to try out: floating point
Anoop Thomas Mathew wrote: What's your opinion about a project in VIMas an on the fly code checker. I really think you should consider composing a new email thread instead of piggy backing on another email thread; especially one that has nothing to do with your topic and already is full of entries. Translated: you're missing your target audience. Steps - i.That is VIM text to a temporary file. ii.Compile it with a compiler.(Either use an external compiler ( preferred by Mr. Moolenaar) or to write an independent parser plug-in within VIM) iii.Then re-parse the error messages. This is my proposed idea for Google Summer of Code 2008. Is there any mistake or faults.Please guide me out. If you want speed, you need to do the syntax checking yourself, which probably means a LALR parser (ie. an equivalent of yacc). If speed is of little concern, your approach might work, although o/s's that lack decent multi-tasking would make the use of this unpleasant. When I start coding, I often use a template, so I start off with a valid C/C++ program. However, there are plenty of times that the code is in-development, and not ready for compiling. I think I'd find this annoying, but I'm willing to be pleasantly surprised. I have vim-commands that compile and check code; the checking (called :Chk for some reason!) uses Vim's quickfix so I can relatively cleanly handle compiler errors/warnings without leaving the editor. However, there are projects that I work with that :Chk doesn't work correctly for (largely due to the need for compiler options, special libraries, etc, and the knowledge to compile correctly is embedded in a Makefile). Thus you undoubtedly will have some gotchas in coding this that you're not currently aware of. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch to try out: floating point
Bram Moolenaar wrote: I have been preparing a talk for the upcoming FISL conference in Brazil: http://fisl.softwarelivre.org/9.0/www/ One of the items I planned to discuss is why Vim has no floating point support. Well, this turned into actually implementing it. The main problem with floating point is that the usual notation already has a meaning: echo 123.456 123456 That is because . is the concatenation operator, and numbers are automatically converted to strings. I considered a few alternatives: 123,456 used for function arguments float(123,456)too verbose #123.456has a meaning after == and != $123.456confusion with $ENV The best I could think of was 123.456. It's a bit obscure, you need to get used to it. But it works. echo 123.456e-3 0.123456 Feel free to suggest something better, but make sure it doesn't already mean something in any context in Vim script. Have fun with the patch! snip Thank you, Bram! I've occasionally wishes for some floating point support (such as for Mines in computing the winning percentage). Might be able to handle that LargeFile stuff better (I'll have to think about that), too. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
ANNC: mkvimball
Hello! I've written a small C program, mkvimball, which generates vimballs; use it from the .vim/ directory. You may get a copy of it at: http://mysite.verizon.net/astronaut/src/index.html#MKVIMBALL . Its good for use inside shell scripts, for example. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: mkvimball
Fredrik Gustafsson wrote: On Tue, Apr 01, 2008 at 02:24:58PM -0400, Charles E Campbell Jr wrote: Hello! I've written a small C program, mkvimball, which generates vimballs; use it from the .vim/ directory. You may get a copy of it at: http://mysite.verizon.net/astronaut/src/index.html#MKVIMBALL . Its good for use inside shell scripts, for example. Regards, Chip Campbell The link to http://mysite.verizon.net/astronaut/src/mkvimball.tar.gz is not working Sorry 'bout that; I'd uploaded it as .../mkvimball.tar.bz2 . I've changed it to correspond with the index page; ie. its .../mkvimball.tar.gz . Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSoC: Fixing Bugs
Christopher Berardi wrote: Any advice and/or suggestions would be welcomed. Well, one thing I've always wished for (but never got around to implementing), was the ability to set watchpoints in vimscript (ie. it would be part of the debugging suite). Just in case you don't know what a watchpoint is: basically, its an expression that's evaluated at the end of every line of script. If it becomes true, then the execution is stopped -- just like a breakpoint had been set there. One should be able to continue, etc. Seems like a nice, not too big, GSoC project to me. Of course, I haven't implemented it, so I don't know how much work is involved. On the other hand, breakpoints are already available, so that should be helpful. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Syntax highlighting problem with vim scripts
Dasn wrote: On 17/03/08 20:06 +0800, Dasn wrote: The last parenthesis is highlighted wrong. Language: Vim 7.1 script Last Change: Jan 24, 2008 Version: 7.1-76 $ cat test.vim echo printf(%d, \12) Hello! I'll be looking at your two patches, just wanted to let you know that I've received them. I've put them into my Attn folder... Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: upgrading vim on linux
[EMAIL PROTECTED] wrote: I seem to have a problem where I want to upgrade my version of gvim for linux but am somewhat confused by the site there seems to be a vim-7.1.tar.bz2 but I have no idea what a bz2 file is and the site doesn't explain it (that I can find...). so I tried to use vim-6.4-src1.tar.gz and vim-6.4-src2.tar.gz and untar'ed them. according to the site you need to type make install and everything will work (assuming a c compiler and such...) but unfortunately, I couldn't find a makefile Not sure why this couldn't be setup to be as easy as installing gvim for my windows box... bunzip2 vim-7.1.tar.bz2 tar -xf vim-7.1.tar cd vim71 configure make make install Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: upgrading vim on linux
Tony Mechelynck wrote: snip This configure step also has advantages: you could say that it has the qualities of its defaults: it allows (almost) common treatment for not only various Linux distributions but also Unix and Unix-like systems which have nothing to do with Linux, such as BeOS, FreeBSD, even Mac-OS-X and VAX/VMS. The differences between all these only approximately similar systems...snip Hello, Tony! Good explanation -- but (you knew that was coming!) vax/vms is pretty unlike unix. It falls into the totally dissimilar category (ie. not unix-like). For example, paths: [this.is.a.path]filename.ext ~ /this/is/a/path/filename.ext . The Amiga is another dissimilar o/s, but I'd say its more similar to unix that vax/vms is. Anyway, to continue with Tony's point: the build compile process is sufficiently flexible to handle totally dissimilar-to-unix operating systems such as AmigaDos and Vax/Vms. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Porting vim to NetBSD
gnani wrote: I read this link and your replies. I'm trying to make vim binary for NetBSD-3.0 from CYGWIN_NT-5.0 system. So, i tried cross compiling the vim. It was not successful initially. Then I tried with your patches for configure.in and configure scripts. I get the following error messages while configuring. --- checking for strip... strip... configure: error: failed to compile test program configure: error: cannot compile a simple program, check CC and CFLAGS (cross compiling doesn't work) -- This is what my configure parameters and I executed like below. ./configure --build=i686-pc-cygwin --host=i386-unknown-netbsdelf3.0 -- target=i386-unknown-netbsdelf3.0 --with-tlib=ncurses but I haven't set any other environment variables like you said already. If you could give me some solution to get my expected binary, it will be great helpful? Thanks alot in advance. In reading this thread, it looks like configure is giving you some problems. I haven't delved into it deeply, but it seems to me that what configure does you're basically not going to be able to get it to do on a separate system. Configure creates/touches directories xxd/, testdir/, po/, objects/, and auto/ under vim71/src (assuming vim71, of course). The only one that it makes files in is vim71/src/auto: config.cache config.h config.log config.mk config.status* configure* configure.orig* . So you need to cut configure down to just involve doing things like huge/tiny and whether or not to include perl/tcl/etc support. This cut-down configure won't be able to test whether, for example, perl is available on your target; you'll have to tell it where it is expected to be. I think you'd be better off thinking about writing a new configure to do this and perhaps extracting some pieces of configure rather than thinking of it as a modify configure problem. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: an idea for plugin development: strict mode
Tim Pope wrote:
On Wed, Jan 23, 2008 at 05:11:53PM -0500, Charles E Campbell Jr wrote:
Vim is often quite forgiving of user blunders. However, for plugin
development, I'd rather it be more strict. I have a tendency of trying
bufnr(.), for example, when I should use bufnr(%). The strange
thing is is that it seems to work on occasion (but erratically). I've
found other bugs in the past that vim glides over, but that makes it
difficult to find them.
How about an errorstop option:
'errorstop' 'es' boolean (default: off)
local to window
{not in Vi}
This option makes Vim strict with respect to any errors, warnings,
etc., when running a script.
Vim will immediately terminate the script with E???.
Are you familiar with the abort qualifier to a function definition?
Documented a bit below :help a:firstline . It's applies to a function
rather than a window, though I'm not quite sure how the latter makes
sense.
With regards to the specific example, bufnr() accepts several kinds of
arguments, including partial buffer names. So :e .vimrc|echo bufnr('.')
would return that buffer's number, as the filename starts with a dot.
I'd be changing a lot of function definitions, sometimes scattered
across multiple files, and I don't want to impose that behavior by
distributing them that way.
I think I'll use Thomas's suggestion and have bufnr(.) be highlighted
with WarningMsg highlighting (not Error, as its possible to be correct
in using it as your example shows).
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: (possibly known) bug with visual block and searchreplace
Jürgen Krämer wrote: Hi, James Vega wrote: On Jan 16, 2008 8:39 AM, Jürgen Krämer [EMAIL PROTECTED] wrote: The behaviour you want can be achieved with an additional script by Dr. Chip. You can download it from the following url In Vim7 you can also use the \%V operator as described at :help /\%V. This will limit the match to only the area selected by the visual block. which is a bit awkward to use if you want to make sure that the search text is completely inside the block, e.g., ++ I. this is |foo |text II. this is| foo| text III. this i|s fo|o text ++ with a 4x3 block (marked by lines) ','s/\%Vfoo/bar/ replaces all three occurences of foo. However, my plugin does handle this case, replacing only the two foos: :','B s/foo/bar/ Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Matthew Winn wrote:
(snip)
Also, it uses the same tabstops over an entire file. An extended idea
is to find some way of specifying different tab widths at different
parts of the same file, but that means a heap of empty cans and worms
all over the place.
You'd probably need to use something like folding's markers (ie. {{{1,
etc). Perhaps ( 1,3,10,20 ). Can't say I'd use it, though, myself,
but you never know. That marker suggestion above may conflict with cvs
conflict marks, so it may not be the best choice.
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Exposing line/file/function call stack for debugging
Matt Wozniski wrote: On Jan 16, 2008 3:59 PM, Ben Schmidt wrote: Charles E. Campbell, Jr. wrote: I think it'd be a small thing -- but only Bram knows for sure. I'd like Decho (from my debugging plugin) to be able to report what line/file/function it was called from so I can relate Decho output to where it was generated. Something like the following would do the trick: I personally would think that having a function that returns the call stack as a list would be a better interface for this, but agree it could be handy info to have for plugin writers and for debugging vimscript generally. This should probably have been a new thread. Ben. function C() echo expand(sfile) endfunction function B() echo expand(sfile) call C() endfunction function A() echo expand(sfile) call B() endfunction call A() results in this being printed: function A function A..B function A..B..C So, you can easily make a function yourself returning the callstack, something like: function! CallStack() return split(substitute(expand(sfile), '^\S\+\s', '', ''), '\.\.') endfunction If this is intended to address the topic for debugging ... just what line in the functions are A, B, and C called from? Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.230
Bram Moolenaar wrote: Citizens are not allowed to attend a movie house or theater nor ride in a public streetcar within at least four hours after eating garlic. [real standing law in Indiana, United States of America] This one I figured I might be able to check on -- I mean, how often would garlic show up in the lawbooks? As opposed to something like assault. Anyway, doing a search at Indiana University's virtual law library yielded no hits. Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
I think it'd be a small thing -- but only Bram knows for sure. I'd like Decho (from my debugging plugin) to be able to report what line/file/function it was called from so I can relate Decho output to where it was generated. Something like the following would do the trick: v:call_line -- would hold the line number (either the absolute line number or like echoerr reports, function-relative) of what called the current function v:call_file -- would hold the name of the file (if absolute line number is used for v:call_line) v:call_function -- would hold the name of the calling function (if function-relative line number is used for v:call_line) I'm afraid that I didn't see anything quite like that available. Its like echoerr, but echoerr only need report where *it* was called. The stuff above would probably necessitate recording what echoerr knows but at the point of the call. I suppose these variable values would need to be placed on a stack to maintain validity when function calls a function calls a function, and then the deepest one returns. What'ch'all think? (my famous line before getting shot down) Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: When will 7.2 come out?
Edward L. Fox wrote: There are already more than 200 patches. When will 7.2 come out? Any plans? Well, I'm not Bram, but I believe that the todo list still has over 100 items on it. Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch for Unix filename expansion to try out
Bram Moolenaar wrote: A couple of problems were detected when the Unix shell is used to expand file names containing characters such as a single quote. This applies to completion on the command line and glob(). I made a patch that defines a function to echo each file name separately. Inspired by a patch that Dasn made, but staying on the safe side. The patch for ex_docmd.c changes detecting the end of the file name when doing command line completion. This specifically fixes a file name containing . Please try it out and let me know if there are any new problems. Verhoef sent me a directory structure: a b/ one two a's b's/ three four Netrw works for the first a b, and does so with the new patch. However, it does not work for the second set (a's b's); the glob() for it returns the empty string: ...netrw debugging info.. glob(dirname/home/cec/.vim/VIMSCRIPT/TST/NETRW/Verhoef/a's b's/*)= ...more netrw debugging info I used ksh under Fedora Core Linux and a vim compiled with the patch. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.215
Bram Moolenaar wrote: Patch 7.1.215 Problem:It is difficult to figure out what syntax items are nested at a certain position. Solution: Add the synstack() function. Files: runtime/doc/eval.txt, src/eval.c, src/proto/syntax.pro, src/syntax.c If you'd like to see this patch in operation, you could try hilinks.vim, available at: http://mysite.verizon.net/astronaut/vim/index.html#HILINKS Then :HLT! will turn on highlighting-links-trace on -- and will display the trace as you move your cursor about. Of course, to see synstack() working, you do have to have installed the patch! :) Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in @{reg} together with [EMAIL PROTECTED]
Nikolai Weibull wrote: I have the following mapping: map g: Esc:set operatorfunc=SIDget_command_mode_rangeCRg@ and have recorded g:}j^M into register 'a'. Running @a now does nothing. Why? (It should run :join from the current line to the end of the current paragraph.) It might help folks help you if you included the get_command_mode_range() function. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.193
Bram Moolenaar wrote: The comments in the patch contain non-ASCII characters. I've seen before that these may cause trouble. If you used the path from the e-mail you can first check if it's equal to what is on the ftp site: ftp://ftp.vim.org/pub/vim/patches/7.1/7.1.193 Then check the lines in digraph.c if they match with what's in the patch. Perhaps patch itself can't handle characters with the 8th bit set. Probably depends on the version of patch. My Linux (Centos 5) version of patch worked to do these patches without fuss. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ftp and rsync errors
Kazuo Teramoto wrote: On Jan 1, 2008 6:10 PM, Tony Mechelynck [EMAIL PROTECTED] wrote: Apparently, the fact that I succeeded to connect to a server where /pub/vim was a vailable, and even to downloaded all patches till 7.1.180, was a one-time non-repeatable fluke: I cn't do it again. ftp.vim.org is working for me, I can cd to pub/vim and get patches... I can now get in with my linux box, too! Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Matt Wozniski wrote: Fixing that to use a script-local variable would definitely be a worthwhile change that should be made ASAP, though it still wouldn't protect you from plaintext passwords being in your core files. Yes, I've done that for v116g. While we're at it, what is a reasonable use-case for why someone would need a getpid() function? Why would we need to know our PID? Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Matt Wozniski wrote: On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Sure, I understand that you could use it as a key to encrypt the password, but what I'm really asking is what you gain from that. Is it really more secure to have an encrypted string and its decryption key stored in memory than it is to have an unencrypted string in memory? Particularly on an open-source project where anyone who wants to can view your source code? Where's the part where I said I'd store the session pid in some variable? Something like getpid() would be called during encrypt/decrypt, not stored. Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
thomas wrote: However, I suspect that there's no way to get vim to feed the p-r-b-password to the builtin encryption/decryption facilities. I thought the :X command does little more than setting the key option? At least from running some (i.e. two) tests, I'd say that you could also encrypt a file by setting the key option to a password (setlocal key=foo) before saving. IIRC the encryption is rather weak though (with vim 7.1). Not much I can do about the encryption method, but perhaps its better than plaintext. And, the expected use of the process ID is amenable to searching, anyway. I'm now feeling that the procedure is more likely to work: * ask user for password * place password in its own buffer * specify encryption for the buffer with set key=... using process pid * save the buffer When the user wants to read/write using that password transparently in the future * check if buffer exists * use the process id and set key on a new buffer, read password-containing buffer * use decrypted password to do file transfer I'm not at sure that this complicated process is worth the trouble, though: * the search is limited to potential process IDs, so that's a rather limited search space * a buffer or two is created with the password in the clear, and a file is saved with that (encrypted) password. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Tony Mechelynck wrote: Yakov Lerner wrote: On Nov 29, 2007 12:23 AM, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Hello! I don't see any way to encrypt/decrypt strings in the vim function library, but there is a way to encrypt a file buffer. Netrw tries to make use of ftp, etc and its associated passwords simpler by retaining the password in a variable (which is not normally saved). Thus one reads a file via ftp, say, provides the password to do so, and writing is done without requiring another entry of the password. I thought about making a temporary password automatically using localtime() at first invocation of netrw and the process's pid. Any good way to get the vim process's pid? How about under Windows? On unixes that have /proc, you can get pid of vim examining /proc/self. [...] ...which is a soft link to /proc/ where is your PID. But the difficulty is to do it without starting a different process such as bash, ls, etc. (the subprocess would return its own PID, not yours). However, since Dr. Chip is the author of the netrw plugin, maybe he can find a way to do it. But on Windows it wouldn't work. The pseudo-random number is one thing; the main problem is the lack of functions to encrypt/decrypt an arbitrary string. I suppose I could try to take the pseudo-random-based password, use :X, and save it to a file, and then read that file back in to retrieve the password. However, I suspect that there's no way to get vim to feed the p-r-b-password to the builtin encryption/decryption facilities. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: assign current line under cursor to extern program
[EMAIL PROTECTED] wrote:
Hi,
I want to assign the current line under the cursort to an external
program. Example
Textfile:
1 foo
2 bar
3 calvin
4 hobbes
If the cursor is in line 2, want to assign the line 2 bar to a
script, like foo.sh.
If I want to call a external script from vim I type in the command
modus:
:! foo.sh [and hit enter]
Now I want to assign the line in the file to the script via a function
into the .vimrc.
I know how to get the line, but I dont know how to assign it to the
external script. Or better I dont know how to use the variale to
assign the parameter to the script. Basicly I have this in my .vimrc
function Foo( )
:let start=line( '.' )
:! foo.sh getline(start) this dont work :(
endfunction
command Foo call Foo( )
This returns the errormessage:
/bin/bash: -c: line 0: syntax error near unexpected token `('
/bin/bash: -c: line 0: ` foo.sh getline( start )'
* the :s aren't needed in your Foo function; you're already in Ex mode.
* some reading is in order; read the help on exe, filter, system()
Your Foo function got the current line number, then passed
! foo.sh getline(start)
to the shell. You shell didn't know what to do with getline(start),
which I'm supposing was intended not for the shell to handle but for
vim. Consider
exe !foo.sh '.getline(start).'
or
call system(foo.sh '.getline(start).')
where I'm quoting the entire string received from getline in single quotes.
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Bug with )
Charles E Campbell Jr wrote: Ben Schmidt wrote: [Didn't get any acknowledgement of this; resending. For the to do list perhaps, Bram?] vim -u NONE iA sentence.Esc) The cursor is placed beyond end of line despite virtualedit being blank. I just tried it and saw no problem -- the cursor was atop the . (using either vim or gvim, BTW) as expected. (I'm using FC5 Linux, vim version 7.1 patches 1-162, huge) Sorry -- I do see the problem. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: non-posix compliant shells
gour wrote: I hit the problem in vim yesterday when I wanted to run fish shell (http://fishshell.org) within vim and soon got informed that the problem is Exactly what is the problem? Are you trying to use system(), or filters (:!), or what? Please give an example of something you're trying to do that the choice of shell impacts. Vim has a number of options that are shell related, perhaps you need to find the right set for fish: set shell : name of shell to use for ! and :! commands set shq : shellquote -- how to quote characters about the cmd passed to shell set sxq : shellxquote -- includes redirection (shellquote excludes that) set ssl : shellslash -- when set, forward slash used to expand file names set shcf : shellcmdflag -- flag passed to shell to execute ! and :! commands set sp: shellpipe-- string used to put output of :make into errorfile set srr : shellredir -- string used to put output of filter cmd into temporary file As an example of a shell that's certainly not Posix compliant -- note that vim works under VMS. Its paths aren't '/' separated (ex. [abc.def.ghi]file.c ) Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Fixes to syntax/sh.vim: escaped quotes, case statements
Please try
http://mysite.verizon.net/astronaut/vim/index.html#vimlinks_syntax
(click on sh.vim.gz). I've not submitted this version to Bram because
it needs more checkout for side effects. I wish the start= and end=
patterns in regions could contain groups not in the rest of the region;
you'll notice that the () and {} no longer have separate highlighting
from the rest of the function boundary.
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: is this a bug or a feature??
denis wrote:
Hello,
I am seeing a problem where execution of seemingly unrelated commands
causes a problem with resetting 'lines' variable
here, lines is set to 23
let g:foo = tempname()
call system('touch ' . g:foo)
here it is reset to the height of my xterm - in this case 50
eh? is this a bug or a feature?
Below please find a minimal .vimrc as well as the output when starting
gvim from an xterm on ubuntu.
Further below is my :version information.
---
[20:41:16 [EMAIL PROTECTED] ~
$ cat .vimrc-test
if has(gui_running)
set lines=23
endif
echo lines
let g:foo = tempname()
echo g:foo
echo lines
call system('touch ' . g:foo)
echo lines
[20:41:20 [EMAIL PROTECTED] ~
$ vim -g -u .vimrc-test
23
/tmp/v102439/0
23
50
---
Hello!
Well, I don't see that behavior. Do you have a .gvimrc file, and
what's in it?
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: patch 7.1.120
Bram Moolenaar wrote: Patch 7.1.120 Problem:Can't properly check memory leaks while running tests. Solution: Add an argument to garbagecollect(). Delete functions and variables in the test scripts. Files: runtime/doc/eval.txt, src/eval.c, src/globals.h, src/main.c, src/testdir/Makefile, src/testdir/test14.in, src/testdir/test26.in, src/testdir/test34.in, src/testdir/test45.in, src/testdir/test47.in, src/testdir/test49.in, src/testdir/test55.in, src/testdir/test56.in, src/testdir/test58.in, src/testdir/test59.in, src/testdir/test60.in, src/testdir/test60.vim, src/testdir/test62.in, src/testdir/test63.in, src/testdir/test64.in Hello! I don't seem to have test63.in or test63.ok for some reason. test62.in, test62.ok, test64.in, and test64.ok are there... Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: patch 7.1.120
Bram Moolenaar wrote: Charles Campbell wrote: Hello! I don't seem to have test63.in or test63.ok for some reason. test62.in, test62.ok, test64.in, and test64.ok are there... test63 was added in patch 7.1.040. Hmm -- the vim I've got has a --version with the following initial lines: VIM - Vi IMproved 7.1 (2007 May 12, compiled Sep 25 2007 11:17:55) Included patches: 1-118 Compiled by [EMAIL PROTECTED] Huge version with GTK2 GUI. Features included (+) or not (-): ... I've been including all the patches, so I don't know how #040's test63 got left out. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: how to regenerate runtime/syntax/vim.vim
ap wrote: On Sep 21, 2:53 pm, björn [EMAIL PROTECTED] wrote: Hi, I have added new commands to Vim (i.e. to ex_cmds.h) and I would like them to be properly highlighted when I edit .vim files (e.g. .gvimrc). I looked at runtime/syntax/vim.vim and from a comment therein I gather that this file is automatically generated, so I don't dare to add my commands manually. My question is how do I generate this file? Or can I just add my new commands directly to it? Thanks, Björn One line vim syntax/vim.vim suggests, that it is generated by something called 'mkvimvim'. I am shure the author of the syntax file knows more about this. mkvimvim is a script which extracts a number of functions, commands, and whatnot from the vim documentation and generates about half of syntax/vim.vim. You should place any syntax highlighting additions into ~/.vim/after/syntax/vim.vim . Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: utf-8, strlen(), and virtcol()
Tony Mechelynck wrote: It all depends on what exactly you want to do. (I haven't read the Align.vim docs.) The length of a UTF-8 string can be counted in several nonequivalent ways: - number of bytes (Latin a + combining circumflex is three bytes): strlen(string) - number of codepoints (Latin a + combining circumflex is two codepoints): strlen(substitute(string, '.', 'x', 'g')) - number of spacing codepoints (Latin a + combining circumflex is one spacing codepoint; a hard tab is one; wide and narrow CJK are one each; etc.): (untested) strlen(substitute(string, '.\Z', 'x', 'g')) - virtual length (counting, for instance, tabs as anything between 1 and 'tabstop', wide CJK as 2 rather than 1, Arabic alif as zero when immediately preceded by lam, one otherwise, etc.): I guess something like what you're doing above will be necessary because of the wide range of things that can happen. The first two above are documented at :help strlen(), the third (in addition) at :help patterns-composing. Thank you, Tony, for that explanation! I've modified Align so that the method used is selectable by the user. Align v33d available at my website (http://mysite.verizon.net/astronaut/vim/index.html#ALIGN) with these changes. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: searching through multiple buffers
Mikolaj Machowski wrote:
Dnia wtorek 11 wrzesień 2007, Ed S. Peschko napisał:
hey all,
Is there a way of searching through multiple buffers? ie: I'd like a
derivative of '/' to be able to span files, ie: if it doesn't find it in
one file, it goes to the next in the bufferlist, and so on..
Having the ability to autosave if it exits the buffer would be cool
too..
If files are sharing common element in name you can use:
:vimgrep /re/ {namewithwildcards}
For buffers you can also use
:bufdo vimgrep /re/ %
But it has few downsides: matches for all files will be saved into
separated quickfix lists, Vim will remember only last ten lists.
But you could probably write some simple script to save all data in
external error list and later load it.
:help quickfix
:help location-list
Well, I was going to suggest
:let qlist=[]
:bufdo silent vimgrep /pattern/ % | call add(qlist,getqflist())
:call setqflist(qlist)
:cope
Unfortunately, the formats for what getqflist() delivers and setqflist()
takes are different, and beating them into compatiblity is more than I
want to attempt at the moment.
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Proposal: Modes for Vim
krischik wrote: My proposal (if you have not guessed already) is to merge more separate plug ins into modes. What do you think about the idea? Well, it sounds like a mode is a combination of three plugins (syntax, indent, ftplugin), and you want one person to maintain them all for a specific language as you did for clearcase. In the case of some of the syntax highlighting plugins I'm maintaining (tex, vim, sh, lisp, csh), that would either mean I give up maintaining the syntax highlighting plugins I wrote or taking on a bunch of other folk's plugins. I can't say I'm enthusiastic about taking on maintenance for other's plugins (I have quite enough maintaining already!). In addition, syntax highlighting and indenting are quite different, for example. Consequently, becoming a maintainer of a mode would involve an a steeper learning curve than becoming a maintainer of one of the pieces. Perhaps I misunderstand your proposal; if there's to be several people maintaining a mode, then that's basically what we have now. If you're talking about the organization of the files (syntax/, indent/, ftplugin/vs. mode/language/[with syntax, indent, ftplugins therein] I don't see any real benefit. Not all languages currently have indent or ftplugin portions (syntax highlighting is probably the biggest of the three portions), so one can't require modes without a lot of additional contributions. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Minor fix to a.vim plugin documentation
Michael Henry wrote: The a.vim (alternate) plugin's[1] documentation file begins with a blank line, preventing it from showing up in the local-additions (:help local-additions) section of Vim's help system[2]. Simply removing the line corrects this minor problem. Changes to plugins should be addressed to their maintainers (usually their authors). Generally the authors have placed their email addresses in the script file itself and sometimes in the associated help file. After all, Mike Sharpe may not even read this forum. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: f-args and backslashes
Charles E Campbell Jr wrote:
So, a feature request: how about a p-args that breaks the input
arguments at whitespace (but otherwise leaves the arguments alone). The
p is to be vaguely reminescent of: pattern-arguments (as in regular
expression patterns)?
Hello!
If anyone's interested, here's a patch that implements p-args. No
documentation yet as I'd like to see if Bram likes it first. Also, I've
included a small test source to demonstrate (you'll need Decho.vim with
it, that's at
http://vim.sourceforge.net/scripts/script.php?script_id=120 ).
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
*** old_ex_docmd.c 2007-08-17 11:06:47.0 -0400
--- ex_docmd.c 2007-08-17 11:43:52.0 -0400
***
*** 5658,5663
--- 5658,5729
}
/*
+ * split and quote args for p-args
+ */
+ static char_u *
+ uc_split_pargs(arg, lenp)
+ char_u *arg;
+ size_t *lenp;
+ {
+ char_u *buf;
+ char_u *p;
+ char_u *q;
+ int len;
+
+ /* Precalculate length */
+ p = arg;
+ len = 2; /* Initial and final quotes */
+
+ while (*p)
+ {
+ if (vim_iswhite(*p))
+ {
+ p = skipwhite(p);
+ if (*p == NUL)
+ break;
+ len += 3; /* , */
+ }
+ else
+ {
+ ++len;
+ ++p;
+ }
+ }
+
+ buf = alloc(len + 1);
+ if (buf == NULL)
+ {
+ *lenp = 0;
+ return buf;
+ }
+
+ p = arg;
+ q = buf;
+ *q++ = '\'';
+ while (*p)
+ {
+ if (vim_iswhite(*p))
+ {
+ p = skipwhite(p);
+ if (*p == NUL)
+ break;
+ *q++ = '\'';
+ *q++ = ',';
+ *q++ = '\'';
+ }
+ else
+ {
+ *q++ = *p++;
+ }
+ }
+ *q++ = '\'';
+ *q = 0;
+
+ *lenp = len;
+ return buf;
+ }
+
+ /*
* Check for a code in a user command.
* code points to the ''. len the length of the (inclusive).
* buf is where the result is to be added.
***
*** 5683,5691
enum { ct_ARGS, ct_BANG, ct_COUNT, ct_LINE1, ct_LINE2, ct_REGISTER,
ct_LT, ct_NONE } type = ct_NONE;
! if ((vim_strchr((char_u *)qQfF, *p) != NULL) p[1] == '-')
{
! quote = (*p == 'q' || *p == 'Q') ? 1 : 2;
p += 2;
l -= 2;
}
--- 5749,5758
enum { ct_ARGS, ct_BANG, ct_COUNT, ct_LINE1, ct_LINE2, ct_REGISTER,
ct_LT, ct_NONE } type = ct_NONE;
! if ((vim_strchr((char_u *)pPqQfF, *p) != NULL) p[1] == '-')
{
! quote = (*p == 'q' || *p == 'Q')? 1 :
! (*p == 'p' || *p == 'P')? 2 : 3;
p += 2;
l -= 2;
}
***
*** 5727,5733
/* When specified there is a single argument don't split it.
* Works for :Cmd % when % is a b c. */
! if ((eap-argt NOSPC) quote == 2)
quote = 1;
switch (quote)
--- 5794,5800
/* When specified there is a single argument don't split it.
* Works for :Cmd % when % is a b c. */
! if ((eap-argt NOSPC) (quote == 2 || quote == 3))
quote = 1;
switch (quote)
***
*** 5737,5742
--- 5804,5810
if (buf != NULL)
STRCPY(buf, eap-arg);
break;
+
case 1: /* Quote, but don't split */
result = STRLEN(eap-arg) + 2;
for (p = eap-arg; *p; ++p)
***
*** 5756,5764
}
*buf = '';
}
break;
! case 2: /* Quote and split (f-args) */
/* This is hard, so only do it once, and cache the result */
if (*split_buf == NULL)
*split_buf = uc_split_args(eap-arg, split_len);
--- 5824,5842
}
*buf = '';
}
+ break;
+
+ case 2: /* Quote and split (p-args) */
+ /* This is hard, so only do it once, and cache the result */
+ if (*split_buf == NULL)
+ *split_buf = uc_split_pargs(eap-arg, split_len);
+ result = *split_len;
+ if (buf != NULL result != 0)
+ STRCPY(buf, *split_buf);
break;
!
! case 3: /* Quote and split (f-args) */
/* This is hard, so only do it once, and cache the result */
if (*split_buf == NULL)
*split_buf = uc_split_args(eap-arg, split_len);
com! -nargs=* Testf call Testf(f-args)
com! -nargs=* Testp call Testp(p-args)
fun! Testf(...)
let i= 1
while i = a:0
call Decho(Testf a:.i..a:{i}.)
let i= i + 1
endwhile
call Decho(---)
endfun
fun! Testp(...)
let i= 1
while i = a:0
call Decho(Testp a:.i..a:{i}.)
let i= i + 1
Re: f-args and backslashes
Bram Moolenaar wrote: Charles Campbell wrote: So, a feature request: how about a p-args that breaks the input arguments at whitespace (but otherwise leaves the arguments alone). The p is to be vaguely reminescent of: pattern-arguments (as in regular expression patterns)? I think the last time something changed here was with patch 7.0.214, that's quite a long time ago. It was done because the handling of escaped white space was wrong. I understand that you don't want to escape white space at all, thus a\ b would be split in a\ and b. Why not use q-args and do the splitting at white space in the invoked function? I thought about that -- I'd need to duplicate that (script) function in several places, though, and figured it might be better in vim source. The primary function handling p-args is basically a much shortened version of that used for f-args, so it was fairly straightforward. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
there's undojoin -- how about dotjoin?
Hello! I'd like to do imap ... = ...=c-o:somethingcr however, . no longer repeats the small change. For example: imap = =c-o:echo hello!cr work with the following file contents: abc; def; Place cursor on the semicolon with abc; -- insert =2 Now put the cursor on the semicolon with def; and press . . All you get is def 2; Now, if there was a dotjoin: imap = =c-o:dotjoinbarecho hello!cr just might work! Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: there's undojoin -- how about dotjoin?
Antony Scriven wrote: Maybe. Could you use something like this as a workaround? fun! Echo() echo 'hello!' sleep 1 | just to make the effect visible return '' endfun imap = =c-r=Echo()cr Hmm -- I definitely have a blind spot with c-r= stuff. Thanks, Antony -- I think it just might! Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: patch 7.1.040
Martin Toft wrote: Maybe somebody wonders why it avoided my attention when writing and testing the patch in the firste place. The reason is that, on my development machine, the problem only occurs in gvim and only when debugging information is not compiled in. I assume you mean compiling with the -g flag. In my experience having the presence of debugging information compiled in affecting the output of a program usually means that there's a bad pointer somewhere. May I suggest compiling with efence? It'll run slow but will catch a lot more pointer bugs. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
