Re: Fastest way to append line or char to a buffer
On 8/30/06, Nikolai Weibull [EMAIL PROTECTED] wrote: On 8/29/06, Brad Beveridge [EMAIL PROTECTED] wrote: On 29/08/06, Ilya [EMAIL PROTECTED] wrote: Brad Beveridge wrote: static char string[2] = {0}; Should not you have = {0, 0} here? Second element never get initialized but it could be accessed by ml_append_string. That might be more clear perhaps, but when you initialize an array like that in C, the last element is propagated for the whole array. What C compiler are you using? The last element is /not/ propagated in C. The rest of the array will be initialized to zero, which is the In C89 this is true. In C99, you can initialize values out of order and by index range, and the final value in an array initializer is propogated to the rest of the values. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gcc/designated-inits.html default for variables declared as being static. Actually, the explicit initialization to zero is redundant and actually causes the size of the resulting executable to increase. See http://people.redhat.com/drepper/dsohowto.pdf for a better explanation than I could give here. nikolai Chris
Re: better recognising of tex vs plaintex filetype
On Tue, Aug 29, 2006 at 09:16:41PM +0200, Stefano Zacchiroli wrote: On Tue, Aug 29, 2006 at 03:06:39PM -0400, Benji Fisher wrote: I do not think there is any reliable way to distinguish between plain TeX and LaTeX. After my RFC, I decided to treat plain TeX as the default, since it is the more basic, even though I agree that LaTeX is probably far more common now. I suggest adding let tex_flavor = latex to your vimrc file. Hi Benji, thanks for your feedback. In my mail I was more talking as the maintainer of the vim package (and of the vim-latexsuite add-on), than as a vim user. Since I've been bugged by users asking for more recognition of LaTeX I was wondering if you agree to change the vim-wide default, instead of changing it on a per-user basis. If you maintain a vim package (for Debian, guessing from your sig?), then you can always define g:tex_flavor in a system vimrc if you want. BTW, the documentation for this is under :help ft-tex-plugin Having already made the decision one way after a RFC, I am reluctant to reverse it. If I then get a rash of complaints from plain TeX and conTeXt users, would I have to reverse it again? Since you agree that LaTeX is more common, what is exactly your argument against having it as the default? Plain TeX came first, so it has priority. (Maybe LaTeX 2ε is an independent format, but I remember when LaTeX first came out that it was actually a bunch of \def's made on top of plain TeX.) This is the same logic that leads to keeping vi-compatible regular expressions, despite the persistent suggestions that vim adopt PCRE. Defaults should cater to users who do simple things, and plain TeX is simpler than LaTeX. Writing LaTeX and splitting your document among multiple files (so that most of them do not have the \begin{document} line) is complicated, and anyone doing this should be willing to customize his or her vimrc file appropriately. Please read the thread on this list started Mar 2, 2006, with the subject RFC: filetypes for TeX, LaTeX, ConTeXT (others?) Beside that, I agree with the other proposal in this thread of recognizing as LaTeX files which starts with a sectioning command (after several possible blanks of course), and I'm going to implement it. Any comments on that choice? Do you mean you plan to implement it as a proposed modification to $VIMRUNTIME/filetype.vim in the standard distribution, or a change to your vim package? I agree with the comment that plain TeX users may also define such sectioning commands. Maybe it would be safe if you check for such definitions, using an include-file search ... but of course, that is more convenient after ftplugin/plaintex.vim has been :source'd. HTH --Benji Fisher
vim mailing lists
On Sun, Aug 27, 2006 at 02:40:24PM +0200, Bram Moolenaar wrote: Apparently the sorbs blacklist mechanism is still being used, causing trouble for some people. I have asked the mail server maintainer to remove sorbs a few times now... Twice recently, sorbs has bounced my mails to the list because some server between my ISP and the vim-dev list is on its blacklist. Do you have any plans to move the vim mailing lists to a new server, where you (or someone more responsive) has administrative control? --Benji Fisher
Re: Fastest way to append line or char to a buffer
On 8/30/06, Chris Littell [EMAIL PROTECTED] wrote: On 8/30/06, Nikolai Weibull [EMAIL PROTECTED] wrote: On 8/29/06, Brad Beveridge [EMAIL PROTECTED] wrote: On 29/08/06, Ilya [EMAIL PROTECTED] wrote: Brad Beveridge wrote: static char string[2] = {0}; Should not you have = {0, 0} here? Second element never get initialized but it could be accessed by ml_append_string. That might be more clear perhaps, but when you initialize an array like that in C, the last element is propagated for the whole array. What C compiler are you using? The last element is /not/ propagated in C. The rest of the array will be initialized to zero, which is the In C89 this is true. In C99, you can initialize values out of order and by index range, and the final value in an array initializer is propogated to the rest of the values. In C99 you can initialize values out of order, yes, but you can't do it with ranges. Ranges are a GNU C extension. The propagation neither happens in any of the ANSI standards, nor in the GNU extended version of C. It's simple to test write the following in a.c: #include stdio.h int main(void) { int is[2] = { 1 }; int i; for (i = 0; i 2; i++) printf(%d\n, is[i]); return 0; } And then to actually test it: $ for std in c89 c99 gnu89 gnu99; do gcc -std=$std a.c echo $std: a.out; done c89: 1 0 c99: 1 0 gnu89: 1 0 gnu99: 1 0 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gcc/designated-inits.html Nowhere in that section does it say that the last value is propagated. nikolai
Re: Fastest way to append line or char to a buffer
On 8/30/06, Chris Littell [EMAIL PROTECTED] wrote: On 8/30/06, Nikolai Weibull [EMAIL PROTECTED] wrote: In C99 you can initialize values out of order, yes, but you can't do it with ranges. Ranges are a GNU C extension. The propagation neither happens in any of the ANSI standards, nor in the GNU extended version of C. It's simple to test write the following in a.c: #include stdio.h int main(void) { int is[2] = { 1 }; int i; for (i = 0; i 2; i++) printf(%d\n, is[i]); return 0; } And then to actually test it: $ for std in c89 c99 gnu89 gnu99; do gcc -std=$std a.c echo $std: a.out; done c89: 1 0 c99: 1 0 gnu89: 1 0 gnu99: 1 0 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gcc/designated-inits.html Nowhere in that section does it say that the last value is propagated. Wow, I reread it and you are correct. I'm not sure why I held that assumption... Also thanks for the examples. No worries. nikolai
Re: better recognising of tex vs plaintex filetype
On Wed, Aug 30, 2006 at 08:42:52AM -0400, Benji Fisher wrote: If you maintain a vim package (for Debian, guessing from your sig?), then you can always define g:tex_flavor in a system vimrc if you want. BTW, the documentation for this is under Yes, sure, I was proposing it to you assuming it could have been an improvement for all users. In Debian we try to push upstream changes we think are useful. Of course if you don't agree on this change it is pointless. Since you agree that LaTeX is more common, what is exactly your argument against having it as the default? Plain TeX came first, so it has priority. (Maybe LaTeX 2ε is an independent format, but I remember when LaTeX first came out that it was actually a bunch of \def's made on top of plain TeX.) This is the same logic that leads to keeping vi-compatible regular expressions, despite the persistent suggestions that vim adopt PCRE. Ok, got it, I will then decide whether to change the default in Debian depending on users willingness. Please read the thread on this list started Mar 2, 2006, with the subject RFC: filetypes for TeX, LaTeX, ConTeXT (others?) Thanks for the pointer. Beside that, I agree with the other proposal in this thread of recognizing as LaTeX files which starts with a sectioning command (after several possible blanks of course), and I'm going to implement it. Any comments on that choice? Do you mean you plan to implement it as a proposed modification to $VIMRUNTIME/filetype.vim in the standard distribution, or a change to your vim package? In Debian we usually first implement changes as patches to our packages and then try to push patches upstream, hoping to improve the life of non-Debian users. So yes to both questions: first modifying our package, than proposing the modification for the official $VIMRUNTIME/filetype.vim. I agree with the comment that plain TeX users may also define such sectioning commands. Maybe it would be safe if you check for such definitions, using an include-file search ... but of course, that is more convenient after ftplugin/plaintex.vim has been :source'd. I'm not really fond of plain TeX, but I think it is not really widespread to \input slices of plain TeX. So the idea mentioned in this thread was to implement the policy: if a document starts with a lot of blanks followed by one of the possible LaTeX sectioning commands, then it is (probably) a LaTeX source file. What do you think of this policy? Of course the comment about plain TeX coming first still applies, but maybe you like this or have a better suggestion :-) Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: better recognising of tex vs plaintex filetype
On Wed, Aug 30, 2006 at 07:17:16PM +0200, Stefano Zacchiroli wrote: I agree with the comment that plain TeX users may also define such sectioning commands. Maybe it would be safe if you check for such definitions, using an include-file search ... but of course, that is more convenient after ftplugin/plaintex.vim has been :source'd. I'm not really fond of plain TeX, but I think it is not really widespread to \input slices of plain TeX. So the idea mentioned in this thread was to implement the policy: if a document starts with a lot of blanks followed by one of the possible LaTeX sectioning commands, then it is (probably) a LaTeX source file. What do you think of this policy? I actually like this policy a lot. Most people who break latex files up into tonnes and tonnes of little files, do so based on sections. Odds are, that the little files will begin with a bunch of comments, and a sectioning command. It would make life easier if this made it into filetype.vim. Especially because changing g:tex_flavor means that every time I edit a plain tex file, I need to unlet this variable. GI -- 'Common' Proof Techniques: 13. Proof by wishful citation -- The author cites the negation, converse, or generalization of a theorem from the literature to support his claims.
Re: Unable to use :setf from $VIMRUNTIME/ftdetect/*.vim
* Alexey I. Froloff raorn@ [060830 21:21]: Solution is simple - source ftdetect/*.vim before conf fallback. Also, it would be nice to use StarSetf() from ftdetect/*.vim... -- Regards, Sir Raorn. signature.asc Description: Digital signature
session-file problem in presence of 'set acd'
When 'acd' is set, 'vim -S' open files in wrong directory. To reproduce: 1. make your ~/.vimrc 1-liner 'set acd' (Alternatively, use use vim -u NONE -c 'set acd' instead of vim in commands below). 2. vim ~/xxx# or :he options.txt now you have two files open: (1) ~/xxx (2) $VIMRUNTIME/doc/options.txt :mksession! /tmp/3 :q! 3. vim -S /tmp/3 4. You'll see that buffer 'options.txt' is empty. ':pwd' in window of options.txt shows that current directory is incorrect. The problem is that ':edit' commands in session-file do not contain full paths. Incomplete paths do not work when 'acd' is set. Here are relevant lines from sessionfile, the /tmp/3: cd /usr/local/share/vim/vim70/doc edit ~/xxx edit options.txt This (3rd line)does not work with 'set acd'. I think all filenames must be with full path like edit ~/xxx edit /usr/local/share/vim/vim70/doc/options.txt Yakov
Re: better recognising of tex vs plaintex filetype
Gautam Iyer wrote: On Wed, Aug 30, 2006 at 07:17:16PM +0200, Stefano Zacchiroli wrote: I agree with the comment that plain TeX users may also define such sectioning commands. Maybe it would be safe if you check for such definitions, using an include-file search ... but of course, that is more convenient after ftplugin/plaintex.vim has been :source'd. I'm not really fond of plain TeX, but I think it is not really widespread to \input slices of plain TeX. So the idea mentioned in this thread was to implement the policy: if a document starts with a lot of blanks followed by one of the possible LaTeX sectioning commands, then it is (probably) a LaTeX source file. What do you think of this policy? I actually like this policy a lot. Most people who break latex files up into tonnes and tonnes of little files, do so based on sections. Odds are, that the little files will begin with a bunch of comments, and a sectioning command. It would make life easier if this made it into filetype.vim. Especially because changing g:tex_flavor means that every time I edit a plain tex file, I need to unlet this variable. GI You can already implement that additional check by adding it (IIUC) in ~/.vim/after/filetype.vim (or, if you are a sysadmin, in $VIM/vimfiles/after/filetype.vim if you think all Vim users on your system will profit by it). Best regards, Tony.
Re: Unable to use :setf from $VIMRUNTIME/ftdetect/*.vim
Alexey I. Froloff wrote: filetype.vim looks like: augroup filetypedetect ... Generic configuration file (check this last, it's just guessing!) au BufNewFile,BufRead,StdinReadPost * \ ... some files are being setf'ed to conf Use the plugin-filetype checks last, they may overrule any of the previously detected filetypes. runtime! ftdetect/*.vim augroup END So, if Vim sets filetype to conf, it is not possible to use :setf from ftdetect/*.vim, because of but only if not done yet in a sequence of (nested) autocommands. setf feature. Solution is simple - source ftdetect/*.vim before conf fallback. You can do set filetype=... if you want unconditionally set file type.
Re: Unable to use :setf from $VIMRUNTIME/ftdetect/*.vim
Alexey I. Froloff wrote: filetype.vim looks like: augroup filetypedetect ... Generic configuration file (check this last, it's just guessing!) au BufNewFile,BufRead,StdinReadPost * \ ... some files are being setf'ed to conf Use the plugin-filetype checks last, they may overrule any of the previously detected filetypes. runtime! ftdetect/*.vim augroup END So, if Vim sets filetype to conf, it is not possible to use :setf from ftdetect/*.vim, because of but only if not done yet in a sequence of (nested) autocommands. setf feature. Solution is simple - source ftdetect/*.vim before conf fallback. 1. You should never create, delete or modify any file in the $VIMRUNTIME directory tree, because any upgrade or bugfix may at any time silently overwrite anything there, and a point release (such as 7.1) will certainly re-create everything there from scratch (under another name, such as .../vim/vim71/ instead of .../vim/vim70/). User customizations to Vim should go in the _other_ directory trees mentioned in the 'runtimepath' option, usually as follows: ~/.vim/ single-user full-fledged scripts on Unix ~/vimfiles/ single-user full-fledged scripts on Windows $VIM/vimfiles/ system-wide full-fledged scripts on all platforms $VIM/vimfiles/after/ small system-wide tweaks to scripts under $VIMRUNTIME or any of the above ~/vimfiles/after/ on Windows, small single-user tweaks to any of the above ~/.vim/after/ on Unix, small single-user tweaks to any of the above. 2. The files detected as conf are the following: auto.master anything not yet detected which has a # in column 1 of one or more of the first 5 lines, unless the filepathname has a match in g:ft_ignore_pat (this is done after all other tests except ftdetect/*.vim and any filetype.vim in an |after-directory| ) 3. If you know that a filetype may already have been assigned and you're dead sure you want to change it, use :set filetype=foobar rather than :setfiletype foobar. You may even let Vim do part of the detection for you by using if filetype == conf if ... set filetype=foobar endif endif Using set filetype=something rather than setfiletype something in ftdetect/*vim scripts is what is explicitly shown in the example in paragraph 2 under :help ftdetect. At the end of the same help topic, just above paragraph B, |:setfiletype| is mentioned with the words: if you want to keep a previously detected filetype. I'm not inventing anything. If you want to _override_ a previously detected filetype instead, don't use it. 4. You may also set g:ft_ignore_pat to force non-detection of some files. The default (which will be set by $VIMRUNTIME/filetype.vim the first time it is run, unless the user has already set something before) is '\.\(Z\|gz\|bz2\|zip\|tgz\)$' which means anything ending in one of .Z .gz .bz2 .zip or .tgz. (see :help filetype-ignore). Best regards, Tony.
Re: Unable to use :setf from $VIMRUNTIME/ftdetect/*.vim
Alexey I. Froloff wrote: filetype.vim looks like: augroup filetypedetect ... Generic configuration file (check this last, it's just guessing!) au BufNewFile,BufRead,StdinReadPost * \ ... some files are being setf'ed to conf Use the plugin-filetype checks last, they may overrule any of the previously detected filetypes. runtime! ftdetect/*.vim augroup END So, if Vim sets filetype to conf, it is not possible to use :setf from ftdetect/*.vim, because of but only if not done yet in a sequence of (nested) autocommands. setf feature. Solution is simple - source ftdetect/*.vim before conf fallback. The current method is correct. In the ftdetect scripts you can check for 'filetype' being equal to conf and then do :set ft=anything to overrule it. Use :setf only when you don't want to overrule the default filetype. The idea is that you can also do something like: if ft == 'python' SomeCheck() set ft=notpython elseif ft == 'conf' SomeOtherCheck() set ft=myconf endif -- MAN:Fetchez la vache! GUARD: Quoi? MAN:Fetchez la vache! Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: session-file problem in presence of 'set acd'
Yakov Lerner wrote: When 'acd' is set, 'vim -S' open files in wrong directory. To reproduce: 1. make your ~/.vimrc 1-liner 'set acd' (Alternatively, use use vim -u NONE -c 'set acd' instead of vim in commands below). 2. vim ~/xxx# or :he options.txt now you have two files open: (1) ~/xxx (2) $VIMRUNTIME/doc/options.txt :mksession! /tmp/3 :q! 3. vim -S /tmp/3 4. You'll see that buffer 'options.txt' is empty. ':pwd' in window of options.txt shows that current directory is incorrect. The problem is that ':edit' commands in session-file do not contain full paths. Incomplete paths do not work when 'acd' is set. Here are relevant lines from sessionfile, the /tmp/3: cd /usr/local/share/vim/vim70/doc edit ~/xxx edit options.txt This (3rd line)does not work with 'set acd'. I think all filenames must be with full path like edit ~/xxx edit /usr/local/share/vim/vim70/doc/options.txt Yakov Alternately, when the buffer type is help, :mksession should use :help options.txt followed by a cursor-movement command, rather than :split options.txt or of :new followed at some point by :edit options.txt. Bset regards, Tony.
Re: Unable to use :setf from $VIMRUNTIME/ftdetect/*.vim
* A.J.Mechelynck antoine.mechelynck@ [060830 23:53]: 1. You should never create, delete or modify any file in the $VIMRUNTIME By $VIMRUNTIME I mean rtp. Those file comes modified from vim-* rpm packages and I just want to _package_ system-specific settings in separate file instead of rediff'ing patch for every filetype.vim changes. -- Regards, Sir Raorn. signature.asc Description: Digital signature
Re: vim mailing lists
On 8/30/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Benji Fisher wrote: On Sun, Aug 27, 2006 at 02:40:24PM +0200, Bram Moolenaar wrote: Apparently the sorbs blacklist mechanism is still being used, causing trouble for some people. I have asked the mail server maintainer to remove sorbs a few times now... Twice recently, sorbs has bounced my mails to the list because some server between my ISP and the vim-dev list is on its blacklist. Do you have any plans to move the vim mailing lists to a new server, where you (or someone more responsive) has administrative control? The plan was to move the maillists to the server that is now already the Vim mail server. And the one causing this blacklist trouble... There is no progress in moving the maillists. I suppose it's time to find a better place for the Vim mail server. Instead of a server that just happens to be available and run by someone who doesn't always respond, or some big and anonymous server park like Yahoo, I think we should look for a small site that does have 24 hour support. Maybe vger.kernel.org can host vim mailing list ? I assume fair number of kernel developers use vim. vger.kernel.org already handles dozens of MLs, some of multi-hundred-messages-per-day traffic. Thus couple of vim MLs trafic shall not be problem for it ? Yakov
Re: vim mailing lists
On Wed, Aug 30, 2006 at 10:12:44PM +0200, Bram Moolenaar wrote: Apparently the sorbs blacklist mechanism is still being used, causing trouble for some people. I have asked the mail server maintainer to remove sorbs a few times now... Twice recently, sorbs has bounced my mails to the list because some server between my ISP and the vim-dev list is on its blacklist. Do you have any plans to move the vim mailing lists to a new server, where you (or someone more responsive) has administrative control? The plan was to move the maillists to the server that is now already the Vim mail server. And the one causing this blacklist trouble... There is no progress in moving the maillists. I suppose it's time to find a better place for the Vim mail server. Instead of a server that just happens to be available and run by someone who doesn't always respond, or some big and anonymous server park like Yahoo, I think we should look for a small site that does have 24 hour support. How about the sourceforge mailing lists? I know sourceforge has had numerous failures in the past. But I think their mailing lists might be OK. Plus the vim CVS / subversion repositories are hosted there anyway, GI -- ACTUAL LABEL INSTRUCTIONS ON CONSUMER GOODS: On Marks Spencer Bread Pudding: Product will be hot after heating.
Bad QUOTESED expression in src/Makefile
There is QUOTESED expression for creating auto/pathdef.c: QUOTESED = sed -e 's//\\/g' -e 's/\\//' -e 's/\\;$$/;/' ... @echo 'char_u *default_vim_dir = (char_u *)$(VIMRCLOC);' | $(QUOTESED) $@ However: gcc -c -I. -Iproto -DHAVE_CONFIG_H -pipe -Wall -O2 -march=pentium4 -DSYS_VIMRC_FILE=\/etc/vim/vimrc\ -DSYS_GVIMRC_FILE=\/etc/vim/gvimrc\ -o objects/pathdef.o auto/pathdef.c auto/pathdef.c:7: error: 'etc' undeclared here (not in a function) auto/pathdef.c:7: error: 'vim' undeclared here (not in a function) auto/pathdef.c:7: error: stray '\' in program auto/pathdef.c:7: error: stray '\' in program auto/pathdef.c:7: error: 'vimrc' undeclared here (not in a function) auto/pathdef.c:7: error: expected ',' or ';' before string constant auto/pathdef.c:7: error: stray '\' in program auto/pathdef.c:7: error: stray '\' in program $ grep all_cflags auto/pathdef.c char_u *all_cflags = (char_u *)gcc -c -I. -Iproto -DHAVE_CONFIG_H -pipe -Wall -O2 -march=pentium4 -DSYS_VIMRC_FILE=\\/etc/vim/vimrc\\ -DSYS_GVIMRC_FILE=\\/etc/vim/gvimrc\\ I think QUOTESED should look like: QUOTESED = sed -e 's/[\\]/\\/g' -e 's/\\//' -e 's/\\;$$/;/' -- Regards, Sir Raorn. signature.asc Description: Digital signature
Re: Unable to use :setf from $VIMRUNTIME/ftdetect/*.vim
Alexey I. Froloff wrote: * Bram Moolenaar Bram@ [060831 00:14]: The current method is correct. In the ftdetect scripts you can check for 'filetype' being equal to conf and then do :set ft=anything to overrule it. Use :setf only when you don't want to overrule the default filetype. I want these files act as default and I don't want to patch filetype.vim. Will :setf work after :set filetype ? :setf bar will not work after :set filetype=foo, neither will it work after :setfiletype foo; it will (IIUC) work after :set filetype= (setting it forcibly to empty). But if you want your settings to act as defaults, you can use the :setf command -- anything else will already have been detected. Filetype conf itself is only set after all other tests (except ftdetect/*.vim) have been run, be they defined by Vim in $VIMRUNTIME/filetype.vim, by the sysadmin in $VIM/vimfiles/filetype.vim (which is run before that) or by the individual user in ~/.vim/filetype.vim (which is run before them both). Or you may use the following in ftdetect/*.vim if ft == || ft == conf set filetype=blahblahblah endif if you want to override conf filetype but leave any other nonempty filetype unchanged. If I misunderstood, please be more specific: do you or don't you want to override the filetype detected by filetype.vim ? If you do, use :set filetype=something. If you don't, use the :setf command. If sometimes you do and other times you don't, you must ascertain which is which. You should not patch $VIMRUNTIME/filetype.vim, but you can set up a $VIM/vimfiles/filetype.vim (to be sourced before it) or a $VIM/vimfiles/after/filetype.vim (to be sourced after it, and after ftdetect/*.vim). Don't set did_load_filetypes yourself if you want the default mechanism to run. Best regards, Tony.
Re: Unable to use :setf from $VIMRUNTIME/ftdetect/*.vim
Alexey I. Froloff wrote: * A.J.Mechelynck antoine.mechelynck@ [060831 01:48]: If I misunderstood, please be more specific: do you or don't you want to override the filetype detected by filetype.vim ? No. Not override, but extend as if it was done in filetype.vim. What user scripts can break with this changes? I don't think il will break anything; but you may want to run it and try. :scriptnames gives you at any time the name of all scripts that have been sourced so far in the present Vim session, each of them listed once, in the order they were first sourced. :setf[iletype] sets a filetype if none is set :set filetype=value or :set ft=value set a filetype unconditionally. You can always test the variable ft to see if any filetype (and which one) has already been set. Thus setf foo is equivalent to if ft == set filetype=foo endif or even (IIUC) to let ft = (ft == ? foo : ft) Best regards, Tony.
Fixing cweb.vim
I'm trying to get cweb.vim to work better, and am not sure how to go about this. Most of a cweb file is regular TeX (or LaTeX), with some occasional regions that are C code. The way it is implemented now, works with simple constructs. However, tex.vim frequently will enclose large sections of the document within a region and the cweb.vim which the webCRegion is not part of. I think I can fix this by adding an appropriate containedin=... field to the definition of webCRegion. What I'm having difficulty with is figuring out what to put there. Is there a way of finding out what region a given part of the buffer is in? Thanks, David Brown
Re: Fixing cweb.vim
David Brown wrote: I'm trying to get cweb.vim to work better, and am not sure how to go about this. Most of a cweb file is regular TeX (or LaTeX), with some occasional regions that are C code. The way it is implemented now, works with simple constructs. However, tex.vim frequently will enclose large sections of the document within a region and the cweb.vim which the webCRegion is not part of. I think I can fix this by adding an appropriate containedin=... field to the definition of webCRegion. What I'm having difficulty with is figuring out what to put there. Is there a way of finding out what region a given part of the buffer is in? Thanks, David Brown I'm not a specialist of these matters; but try help completion on synID i.e., (optional) :set wildmenu (then) :help synIDTab (or):help synIDCtrl-D Best regards, Tony.
Re: Fixing cweb.vim
A.J.Mechelynck wrote: David Brown wrote: What I'm having difficulty with is figuring out what to put there. Is there a way of finding out what region a given part of the buffer is in? I'm not a specialist of these matters; but try help completion on synID Well, I did figure out how to get cweb working, by adding the line: syntax cluster texFoldGroup add=webCpart to cweb.tex. I figured this out by tracing through tex.vim by hand and by finding a group that nearly everything included. I still don't know how to debug these, but at least I got things working. Thanks, David
Re: Bad QUOTESED expression in src/Makefile
* A.J.Mechelynck antoine.mechelynck@ [060831 02:48]: Hmmm... it seems you configured a nonstandard location for your system vimrc and gvimrc. I have CFLAGS with escaped quotes. Backslashes should be escaped too. ; compiling pathdef.c gives me no errors or warnings whatsoever. How did you configure yours? CFLAGS=-DSYS_VIMRC_FILE=\/etc/vim/vimrc\ -DSYS_GVIMRC_FILE=\/etc/vim/gvimrc\ -- Regards, Sir Raorn. signature.asc Description: Digital signature
Re: Re [2]: again: % does not work with ' ( '
Hey, Thanks for that important clue. It seems the secret to making it work is in the values of the b:match_skip and b:match_words variables. Thank you, this problem has been bugging me for a while. regards, Peter Addendum: It depends on the 'filetype' and possibly on whether %-jumping is done by Vim C code or by the matchit script: with the same file, if :set filetype=vim % jumps between 1 and 6 (but here the matchit plugin comes into play), and matchparen pairs 1 with 6 too. Best regards, Tony. Do you Yahoo!? Great meals in less than 30 mins - Family Circle Sept out now http://www.familycircle.com.au
Re: Re [2]: again: % does not work with ' ( '
Peter Hodge wrote: Hey, Thanks for that important clue. It seems the secret to making it work is in the values of the b:match_skip and b:match_words variables. Thank you, this problem has been bugging me for a while. regards, Peter Addendum: It depends on the 'filetype' and possibly on whether %-jumping is done by Vim C code or by the matchit script: with the same file, if :set filetype=vim % jumps between 1 and 6 (but here the matchit plugin comes into play), and matchparen pairs 1 with 6 too. Best regards, Tony. Note that with an empty 'filetype', which might mean English (or French or...) plaintext, an apostrophe isn't necessarily a paired string-terminator, so (don't you see) the opening and closing round brackets earlier in this sentence should be paired. In a programming language such as Vim-script or C, there is a filetype-plugin which should be responsible to adjust the relevant options and variables according to the syntax of the language. Double-quotes, on the contrary, can, I think, always be assumed to be string or quotation boundaries. Best regards, Tony.
Re: Re [2]: again: % does not work with ' ( '
Yes, b:match_skip is relevant here. The matchit default is to skip strings and comments (unless you use % starting inside a string or comment). The matchit script relies on the syntax mechanism to recognize strings and comments. HTH --Benji Fisher On Wed, Aug 30, 2006 at 05:37:38PM +1000, Peter Hodge wrote: Hey, Thanks for that important clue. It seems the secret to making it work is in the values of the b:match_skip and b:match_words variables. Thank you, this problem has been bugging me for a while. regards, Peter Addendum: It depends on the 'filetype' and possibly on whether %-jumping is done by Vim C code or by the matchit script: with the same file, if :set filetype=vim % jumps between 1 and 6 (but here the matchit plugin comes into play), and matchparen pairs 1 with 6 too. Best regards, Tony.
Printing in Windows
I'm using vim 7.0.076 on Windows and I'm trying to print the current buffer. Doing a ':ha' doesn't work because it is trying to copy the file to LPT1: C:\WINDOWS\system32\cmd.exe /c copy C:\WINDOWS\TEMP\VIp1C.tmp LPT1: C:\WINDOWS\TEMP\VIo1D.tmp 21 which on my system doesn't work because I use a networked printer. According to ':help ha' a dialog is supposed to be displayed to allow selection of printer, paper size, etc. Unfortunately this isn't happening, is there something I'm missing? Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
Re: Contextual highlighting problem
On 8/28/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: Yongwei Wu wrote: [...] However, it is only a *little* better. Scroll down to make the first comment line disappear on the top of the Vim window, and press Ctrl-L, highlighting will have problems. C comments have not this problem. More clues? Best regards, Yongwei See the various flavours of the :syntax sync command: :help :syn-sync :help :syn-sync-maxlines :help :syn-sync-linebreaks :help :syn-sync-firstfromstart :help :syn-sync-second ccomment :help :syn-sync-thirdminlines :help :syn-sync-fourth patterns: grouphere, groupthere, linecount Thanks! I believe syn sync minlines should work in most of the cases. However, I do find that there is some magic in C. Just save my syntax file as c.vim in vimfiles\syntax, and the test.asm file (renamed as test.c) works perfectly. Check attachment if interested. Anyone knows where the magic is? -- Wu Yongwei URL: http://wyw.dcweb.cn/ c.vim Description: Binary data .386P .MODEL FLAT, C COMMENT * This is some comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment More comment COMMENT * trailing text .CODE mov ax, 1 .DATA warnDB'Can''t find file.' ; Can't find file. END
Re: Printing in Windows
On Wednesday 30 August 2006 07:09, you wrote: I'm using vim 7.0.076 on Windows and I'm trying to print the current buffer. Doing a ':ha' doesn't work because it is trying to copy the file to LPT1: C:\WINDOWS\system32\cmd.exe /c copy C:\WINDOWS\TEMP\VIp1C.tmp LPT1: C:\WINDOWS\TEMP\VIo1D.tmp 21 which on my system doesn't work because I use a networked printer. According to ':help ha' a dialog is supposed to be displayed to allow selection of printer, paper size, etc. Unfortunately this isn't happening, is there something I'm missing? Chris Go to your printer and fax settings. Right-click on the printer and select properties. Click the Ports tab. Click on LPT1 and save your settings. Now it should work just fine. Noel -- Noel Henson www.noels-lab.com Chips, firmware and embedded systems www.vimoutliner.org Work fast. Think well.
Re: [VIM] Re: search/replace from a given column
On Tue, 29 Aug 2006, Tim Chase wrote: :%s/\%15cfoo\%30c/bar/g will substitute foo with bar only between columns 15 and 30 (adjust for the off-by-one that may or not may occur) great this one is doing exactly what I was looking for, thanks a lot. I imagine that regular expression are more complicated and powerful than I was expecting :-D Walter -- Walter Cazzola, PhD - Assistant Professor, DICo, University of Milano E-mail [EMAIL PROTECTED] Ph.: +39 010 353 6637 Fax: +39 010 353 6699 · · · --- · · · --- · · · ... recursive: adjective, see recursive ... · · · --- · · · --- · · ·
Re: Printing in Windows
According to ':help ha' a dialog is supposed to be displayed to allow selection of printer, paper size, etc. Unfortunately this isn't happening, is there something I'm missing? Go to your printer and fax settings. Right-click on the printer and select properties. Click the Ports tab. Click on LPT1 and save your settings. Now it should work just fine. It will work. The problem is I have mulitple network printers and depending on where I am I will have to set the LPT1 port each time. I'm just curious since the help states that the print dialog should be displayed why it is not. Thanx! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
Re: Printing in Windows
It will work. The problem is I have mulitple network printers and depending on where I am I will have to set the LPT1 port each time. I'm just curious since the help states that the print dialog should be displayed why it is not. You are correct...or your expectations are. :) It does work as advertised here on my local Windows box...a dialog comes up prompting me to choose my printer, just as it does in about every other windows app. Though you didn't specify whether you're using vim or gvim, I don't know if using non-gvim would exhibit odd behaviors like you describe. Additionally, are you using the default build, or perhaps something like a cygwin build? Don't know if that has anything to do with it. Additionally helpful information would include the results of :set pdev? popt? pexpr? pfn? pheader? (okay...the last two aren't likely helpful, but one never knows) Just a few ideas to help folks track down the root of the problem. -tim
Re: Printing in Windows
Though you didn't specify whether you're using vim or gvim, I don't know if using non-gvim would exhibit odd behaviors like you describe. Additionally, are you using the default build, or perhaps something like a cygwin build? Don't know if that has anything to do with it. I'm using gvim compiled from source with MinGW. I've tried using 'Print' from the 'File' menu as well as ':ha' and they both behave the same. FWIW, ':browse w' and ':browse e' work fine. Additionally helpful information would include the results of :set pdev? printdevice= popt? printoptions= pexpr? printexpr=system('copy' . ' ' . v:fname_in . (printdevice == '' ? 'LPT1:' : (' ' . printdevice . ''))) . delete(v:fname_in) pfn? printfont=Courier_New:h10 pheader? printheader=%%f%h%m%=Page %N Thanx! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
Re: Printing in Windows
I'm using gvim compiled from source with MinGW. I've tried using 'Print' from the 'File' menu as well as ':ha' and they both behave the same. Under the covers, they should be the same thing, so I'm not surprised you get the same behavior. :) pexpr? printexpr=system('copy' . ' ' . v:fname_in . (printdevice == '' ? 'LPT1:' : (' ' . printdevice . ''))) . delete(v:fname_in) What happens if you reset this option: :set pexpr= and set it to nothing? Additionally, the Compilation section of the output from :version might give further hints. Particularly information about being linked to comdlg32.lib, comctl32.lib, gdi32.lib, shell32.lib, and winspool.lib (though others might be helpful). Just a few more ideas... -tim
Re: Printing in Windows
:set pexpr= I get E15: Invalid expression errors. Additionally, the Compilation section of the output from :version might give further hints. Particularly information about being linked to comdlg32.lib, comctl32.lib, gdi32.lib, shell32.lib, and winspool.lib (though others might be helpful). kernel32, user32, gdi32, advapi32, comdlg32, comctl32, version, wsock32, oleaut32, stdc++, ole32 and uuid. Interestingly enough, winspool is missing, not sure if that's an issue or not. Just as a last-ditch effort, you might try one of the following: :set pexpr :set pexprvi :set pexprvim (see :help :set-default if you've not seen this syntax before...it's not in my active vocabulary, so I had to look it up) and see if it becomes anything other than what it was previously. I suspect that for some reason this isn't a 100% windows build. It may be as simple as a missing build/configure option. Strangely, I get an error about pexpr not being available in my default win32 build (I don't have +postscript built in). Maybe having +postscript precludes the use of the Win32 common print dialog? I'm not one of the masochists who try that little building stunt, so perhaps some of the folks more well-versed in building Vim can point you at what distinguishes a mingw build (or whatever options you may have used) from the official win32 build available for packaged distribution. yet more fuel for your fire... -tim
Re: Printing in Windows
Solved!!! Strangely, I get an error about pexpr not being available in my default win32 build (I don't have +postscript built in). Maybe having +postscript precludes the use of the Win32 common print dialog? That is indeed the issue. I disabled postscript and now the print dialog displays when I do a ':ha'. I'm not sure if this is by design or if this is a bug, anyone? Thanx! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
Re: Latex-Spellchecker and C-s freezes Vi
On 8/30/06, Thomas Unternaehrer [EMAIL PROTECTED] wrote: 2. Every time I hit C-s Vi freezes immediately (have to close the window). I tried to unmap it with map C-s Nop and map! C-s Nop and tried to map it to something different with imap C-s ESC:wCRi but nothing helped. This is issue of your terminal emulator (like xterm) not vim's. In many terminal emulators, Ctrl-S freezes output until Ctrl-Q. vim (or any other program running) won't see neither Ctrl-S nor Ctrl-Q. To disable this behaviour in your terminal, google or read manpage for your terminal emulator. For example, in Konsole, the configuration item is in Menu-Settings-ConfuigureKonsole-General- Use Ctrl-S/Ctrl-Q flow control. Yakov
Re: Printing in Windows
Chris Sutcliffe wrote: Solved!!! Strangely, I get an error about pexpr not being available in my default win32 build (I don't have +postscript built in). Maybe having +postscript precludes the use of the Win32 common print dialog? That is indeed the issue. I disabled postscript and now the print dialog displays when I do a ':ha'. I'm not sure if this is by design or if this is a bug, anyone? Thanx! Chris I think it is by design: 8 *pexpr-option* 'printexpr' 'pexpr' String (default: see below) global Expression that is evaluated to print the PostScript produced with |:hardcopy|. 8 IMHO the :help :hardcopy section should make it more explicit: On MS-Windows, *unless +postscript has been compiled-in, which is usually not the case,* a dialog is displayed (etc.) On other systems, PostScript is written (etc.) and, if 'printexpr' is indeed not present on -postscript systems, :help 'printexpr' should IMHO include {only available when compiled with the |+postscript| feature} Of course, as mentioned at the top of that helpfile (print.txt), nothing that relates to printing is available without +printer compiled-in. Best regards, Tony.
Copy/paste to another console
Hi, I've a little problem, I do remote box A with console A using putty (under MS) then using vim open file A, I do copy a line with yy in file A, so I do remote to box B with console B using putty (under MS), then open file B, the question how to do paste to file B in console B without mouse (I do usually using mouse to block line then copy to another file) Thank You -- budsz
Re: Copy/paste to another console
On 8/30/06, budsz [EMAIL PROTECTED] wrote: Hi, I've a little problem, I do remote box A with console A using putty (under MS) then using vim open file A, I do copy a line with yy in file A, so I do remote to box B with console B using putty (under MS), then open file B, the question how to do paste to file B in console B without mouse (I do usually using mouse to block line then copy to another file) Why without mouse, if you can do it with mouse ? Yakov
Re: Copy/paste to another console
Shift+insert because it's a pain to have to use the mouse. btw, i think the first ctrl+ins, shift+ins, shift+del copy/paste/cut where intended to use with the mouse with the left hand. just a random tought :) On 8/30/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 8/30/06, budsz [EMAIL PROTECTED] wrote: Hi, I've a little problem, I do remote box A with console A using putty (under MS) then using vim open file A, I do copy a line with yy in file A, so I do remote to box B with console B using putty (under MS), then open file B, the question how to do paste to file B in console B without mouse (I do usually using mouse to block line then copy to another file) Why without mouse, if you can do it with mouse ? Yakov -- The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
Re: Copy/paste to another console
I've a little problem, I do remote box A with console A using putty (under MS) then using vim open file A, I do copy a line with yy in file A, so I do remote to box B with console B using putty (under MS), then open file B, the question how to do paste to file B in console B without mouse (I do usually using mouse to block line then copy to another file) Why without mouse, if you can do it with mouse ? for the same reason I use vim... :) Vim users are usually keyboard junkies. It's also a lot easier when using my laptop, to avoid the track-pad altogether. -tim
Re: Copy/paste to another console
Ooops. i don't think you can do that btw. ignore my previous answer, please you are copying from two putty under windows. so you must pass the text to the windows clipboard. i don't have a windows box right now, but i'm pretty sure putty don't gets vim's yanks. but if you manage to pass it to the windows clipboard, shift+insert would work ;) have you tried to do [EMAIL PROTECTED] vim fileA.txt [EMAIL PROTECTED]:/home/you/fileB.txt then just yank and change buffers ;) On 8/30/06, Gabriel B. [EMAIL PROTECTED] wrote: Shift+insert because it's a pain to have to use the mouse. btw, i think the first ctrl+ins, shift+ins, shift+del copy/paste/cut where intended to use with the mouse with the left hand. just a random tought :) On 8/30/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 8/30/06, budsz [EMAIL PROTECTED] wrote: Hi, I've a little problem, I do remote box A with console A using putty (under MS) then using vim open file A, I do copy a line with yy in file A, so I do remote to box B with console B using putty (under MS), then open file B, the question how to do paste to file B in console B without mouse (I do usually using mouse to block line then copy to another file) Why without mouse, if you can do it with mouse ? Yakov -- The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend -- The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
gvim + gnome nautilus
I've used gvim with gnome for some time. Now when i try to open a file with right click in the file nautilus' icon, open with gvim. I get: Erreur détectée en traitant BufReadCmd Auto commandes pour file://*: error detected treating BufReadCmd Auto commandes for file://*: is it something i messed up in vim or in nautilus? a grep for auto|file://|BufRead in my .vimrc show just that of interest: Trim whitespace from python files autocmd BufWritePre *.py normal m`:%s/\s\+$//e `` autocmd BufRead,BufNewFile *.py syntax on autocmd BufRead,BufNewFile *.py set ai Thanks, Gabriel
Re: Copy/paste to another console
budsz wrote: Hi, I've a little problem, I do remote box A with console A using putty (under MS) then using vim open file A, I do copy a line with yy in file A, so I do remote to box B with console B using putty (under MS), then open file B, the question how to do paste to file B in console B without mouse (I do usually using mouse to block line then copy to another file) Thank You If both programs can access a common clipboard, use it. Vim knows it as the + register. So, for instance, to yank three lines to the clipboard: +3yy and to paste the clipboard before the cursor: +P etc. Best regards, Tony
Re: Copy/paste to another console
On 2006-08-31, budsz [EMAIL PROTECTED] wrote: Hi, I've a little problem, I do remote box A with console A using putty (under MS) then using vim open file A, I do copy a line with yy in file A, so I do remote to box B with console B using putty (under MS), then open file B, the question how to do paste to file B in console B without mouse (I do usually using mouse to block line then copy to another file) There is a very nice PuTTY manual at http://the.earth.li/~sgtatham/putty/0.52/htmldoc/ I see nothing there about allowing applications to access the clipboard, as would be necessary for vim users to be able to yank to or put from the clipboard with +y or +p. Further, there appears to be no way to copy, paste or select using the keyboard. From Section 3.1.1: PuTTY's copy and paste works entirely with the mouse. In order to copy text to the clipboard, you just click the left mouse button in the terminal window, and drag to select text. When you let go of the button, the text is automatically copied to the clipboard. You do not need to press Ctrl-C or Ctrl-Ins; in fact, if you do press Ctrl-C, PuTTY will send a Ctrl-C character down your session to the server where it will probably cause a process to be interrupted. So I think you're stuck using the mouse. However, if you could remote to box A from box B, or to box B from box A, you could remote to one of them from Windows, run 'screen' on that box, open a new 'screen' window, remote to the other box, then use 'screen's keyboard-driven copy and paste mechanism. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: gvim + gnome nautilus
Gabriel B. wrote: I've used gvim with gnome for some time. Now when i try to open a file with right click in the file nautilus' icon, open with gvim. I get: Erreur détectée en traitant BufReadCmd Auto commandes pour file://*: error detected treating BufReadCmd Auto commandes for file://*: is it something i messed up in vim or in nautilus? a grep for auto|file://|BufRead in my .vimrc show just that of interest: Trim whitespace from python files autocmd BufWritePre *.py normal m`:%s/\s\+$//e `` autocmd BufRead,BufNewFile *.py syntax on autocmd BufRead,BufNewFile *.py set ai Thanks, Gabriel It may have been defined by another plugin such as netrw. Try :verbose au BufReadCmd For the file:// protocol I see: file://* exe silent doau BufReadPre .netrw#RFC2396(expand(amatch))|exe 'e '.substitute(netrw#RFC2396(expand(amatch)),'file://\(.*\)','\1',)|exe silent doau BufReadPost .netrw#RFC2396(expand(amatch)) Last set from /usr/local/share/vim/vim70/plugin/netrwPlugin.vim file://localhost/* exe silent doau BufReadPre .netrw#RFC2396(expand(amatch))|exe 'e '.substitute(netrw#RFC2396(expand(amatch)),'file://localhost/\(.*\)','\1',)|exe silent doau BufReadPost .netrw#RFC2396(expand(amatch)) Last set from /usr/local/share/vim/vim70/plugin/netrwPlugin.vim Function netrw#RFC2396() is provided by $VIMRUNTIME/autoload/netrw.vim Best regards, Tony
I have got one ml_get error
I have got one error to crash vim. It happened when meet the following condition: A. must in Linux(solaris and winxp is OK) B. vim7.0(6.4 is ok) C. open one huge file(exceed 368710 bytes) then type :sp ./ In general, it will split one window to show the filebrowse. But Vim will crash. I don't know how to avoid this crash. There are two appendixed report file: http://www.nabble.com/user-files/235811/bugreport.txt bugreport.txt http://www.nabble.com/user-files/235812/buginfo.txt buginfo.txt -- View this message in context: http://www.nabble.com/I-have-got-one-%22ml_get%22-error-tf2194557.html#a6073448 Sent from the Vim - General forum at Nabble.com.