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
