VIM autondent on C++ source-code
Hello,
Could someone help me with the following issue,
please?
autoindent in Vim works great for most of the
source-code. However, when I try it on the following,
for example,
string
GetHelloWorld()
{
return string("Hello, world!");
}
, the indentation becomes
string
GetHelloWorld()
{
return string("Hello, world!");
}
where the periods specify spaces. Notice that return
type of the function is indented in the result, which
is *not* what I want. The desired result is,
string
GetHelloWorld()
{
return string("Hello, world!");
}
What configuration change can fix this?
Many thanks in advance!
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel
bargains.
http://farechase.yahoo.com/promo-generic-14795097
Re: Breaking long lines
On 1/31/07, Jack Tucker <[EMAIL PROTECTED]> wrote: Christopher Hever <[EMAIL PROTECTED]> replied: > Well, it seems you're making it a bit to difficult. All you have to do > is :set textwidth=n in your .vimrc, and then you can use facilities > like gq to break lines; e.g., gq} will wrap to the > end of the paragraph. Thank you sir ... works on all versions. gq$ is what I needed. I used to read through the :help as a kind of technological catechism. I've forgotten most of it, but gq, >>, and Ctrl-N are some the handiest things I've learned. c.f. also the tags features.
Re: Breaking long lines
Christopher Hever <[EMAIL PROTECTED]> replied: > Well, it seems you're making it a bit to difficult. All you have to do > is :set textwidth=n in your .vimrc, and then you can use facilities > like gq to break lines; e.g., gq} will wrap to the > end of the paragraph. Thank you sir ... works on all versions. gq$ is what I needed. Jack Tucker [EMAIL PROTECTED]
Breaking long lines
Hello: I'm an old Unix user that converted to SuSE Linux five or six years ago. I have a rather simple problem that's giving me trouble so I joined the mailing list hoping to find some help. I moved many vi .exrc set and map commands onto my SuSE 6.4 system unchanged and they worked fine, VIM version 5.6. In particular, I had a map command to break long ( > 80 char) lines at the first space in the line less than 80 chars from the beginning of the line. It looked like this: map g $80|F r This worked in Unix ond on the SuSe system. I have another box with SuSE 8.1 and VIM 6.1.150. The above incantation did not work when put into .exrc. I modified it to: map g 080 F r This almost works ... but has the peculiar "feature" of counting off the first 80 characters, over multiple lines, in a file and then inserting a NL at the first space prior when editing a file ... without my invoking 'g'! In other words, when .exrc is read, it automatically invokes the command 'g'. The command does work correctly thereafter. This same map command does work correctly using vim in Knoppix 5.01 (vim 6.4.7) Anyone have an idea of what I'm doing wrong on SuSE 8.1? Thanks in advance. Jack Tucker [EMAIL PROTECTED]
Re: Weird problem with helpgrep
[DervishD] [Bram Moolenaar] Only a few things might need to be spread to other directories, using symlinks when possible (binary in /usr/local/bin, libs in /usr/local/lib, header files in /usr/local/include). Well, I know about a packaging system that does exactly that (I don't remember its name). The problem is that maintaining that lot of symlinks is a mess, usually. It's easier (and IMHO more convenient) to use the installation system of the package to put the files where they belong (again, IMHO) in the first place. Hi, people. Just perusing email in ultra-fast mode :-). I did not read the previous exchanges, so I apologize if I'm out of context. I used two installation systems which were extremely fond on symbolic links: LUDE (from Université de Montréal) and Stow (from GNU). Both have been used in various places. LUDE was a bit gigantic for my own needs, I've never really been comfortable with it. Stow was OK and clean (not so messy). Even if I was careful to be stow-compatible for a few packages I maintained in another life, I nowadays prefer installations to be plain straight. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Editing during compiling
Is there any possibility of editing during compiling like in Visual
Studio, also seeing the errorlist growing during compiling?
Hi Peter.
I'd like this too. I started looking into it, but the partial solution
I have is ugly, and can't find a way around not being able to
programmatically update the quickfix list from inside vim. Hopefully
I'm missing something obvious. This response is to see if anyone else
on the list can turn me around in the right direction.
split test
sil !python test.py > test &
call setbufvar('test', '&autoread', 1)
au CursorMoved,CursorMovedI * checktime test
au CursorHold,CursorHoldI * checktime test
It seems to update the test buffer every 2-3 seconds on my machine,
with heavy cursor movement to keep the autocommands running.
The test python script just prints an integer every second for 5
seconds, flushing stdout regularly.
I just had a thought: we could add:
call setbufvar('test', '&makeprg', 'cat %')
au FileChangedShell test make
But that won't work, because it'll refresh the quick fix list in the
middle of using it, in theory, and it's ugly as sin.
After all that, I'm not sure I want it anymore - too much like real
work, and way too ugly - I don't want to think about the performance
implications of these autocommands. :(
Re: replace with a number sequence
"Tim Chase" wrote,
Using a simple change to Tim Chase' original substitution response, you
have:
[snip]
if you don't want to type it in every time,
:vmap :s/\d\+/\=line('.')-line("'<")
which adds ctrl-i as a key in visual mode to do the job.
Ok, one last question on this. :-)
Is there a way to start this from where the cursor is and end with the
first
non-matched instance? For example,
char[] str = null;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
int i = 0;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
So, if the cursor is on the first bla.* the first 6 lines will be
numbered
sequentially and stop there. Is this possible?
Well, if you have the above mapping, you can then map
:nmap vip
which will visualize the block in question and then reduce the problem to
the previously solved problem.
If you plan to then expand this to auto-numbering blocks throughout your
your document, you might try something like (broken into multiple lines
for easy reading, but would be all one mappable line)
:g/bla\.blah\.blahh\[\d/if getline(line('.')-1)=~'blah\.blah\.blahh\['
| let counter = 0
| endif
| s/blahh\[\zs\d\+/\=counter/
| let counter = counter + 1
I haven't tested it (so there's likely some escaping I got wrong), but it
should do similar to my previous mapping, only when the previous line
doesn't match the target pattern, it resets the counter to zero. It might
be reducable to something like
:g/.../if getline(line('.')-1) =~ @/
which might be a little easier to read/understand, as it uses the search
register.
Just a few ideas.
Thanks. vim rocks!
f4
What a beautiful world is this we live on!
thanks,
josé
Re: replace with a number sequence
Using a simple change to Tim Chase' original substitution response, you
have:
[snip]
if you don't want to type it in every time,
:vmap :s/\d\+/\=line('.')-line("'<")
which adds ctrl-i as a key in visual mode to do the job.
Ok, one last question on this. :-)
Is there a way to start this from where the cursor is and end with the first
non-matched instance? For example,
char[] str = null;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
int i = 0;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
So, if the cursor is on the first bla.* the first 6 lines will be numbered
sequentially and stop there. Is this possible?
Well, if you have the above mapping, you can then map
:nmap vip
which will visualize the block in question and then reduce the
problem to the previously solved problem.
If you plan to then expand this to auto-numbering blocks
throughout your your document, you might try something like
(broken into multiple lines for easy reading, but would be all
one mappable line)
:g/bla\.blah\.blahh\[\d/if
getline(line('.')-1)=~'blah\.blah\.blahh\['
| let counter = 0
| endif
| s/blahh\[\zs\d\+/\=counter/
| let counter = counter + 1
I haven't tested it (so there's likely some escaping I got
wrong), but it should do similar to my previous mapping, only
when the previous line doesn't match the target pattern, it
resets the counter to zero. It might be reducable to something like
:g/.../if getline(line('.')-1) =~ @/
which might be a little easier to read/understand, as it uses the
search register.
Just a few ideas.
-tim
Re: replace with a number sequence
"Tom Whittock" wrote,
but it kept going to the same spot as before. I will not change the [#].
Where is the match for (? I can't figure it out.
Using a simple change to Tim Chase' original substitution response, you
have:
:'<,'>s/\d\+/\=line('.')-line("'<")
which replaces the *first number* on every line in the visual
selection. look at the difference between the two to see that the
responses have all used opIndex as a marker to know what number is to
be operated on.
this modification doesn't really allow for any fine degree of control
(like selecting which number on a given line to increment), but it
works for the examples you've given.
if you don't want to type it in every time,
:vmap :s/\d\+/\=line('.')-line("'<")
which adds ctrl-i as a key in visual mode to do the job.
the ex (colon) commands are one of the major parts of vim - I would
highly recommend learning them a bit more, if you want to get the most
out of the program. For me, without ex there would be very little
point in using vim at all - I couldn't even write to a file ;)
Ok, one last question on this. :-)
Is there a way to start this from where the cursor is and end with the first
non-matched instance? For example,
char[] str = null;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
int i = 0;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
bla.blah.blahh[0].text;
So, if the cursor is on the first bla.* the first 6 lines will be numbered
sequentially and stop there. Is this possible?
Re: Conditional autocmd question
On 2007-01-29, Evan Klitzke <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> I have the F2 key mapped as a "compile" function for the programs I
> write, e.g. if I am editing a .tex file I have an autocmd to execute
> pdflatex, if I am editing a .py file I have an autocmd to execute
> python. The case of .c files is somewhat trickier: I want to use autocmd
> to map F2 to :make if a Makefile exists in the current directory,
> otherwise it should try to compile the file with gcc. For example, if I
> am editing foo.c, hitting F2 should execute "gcc -o foo foo.c". Do you
> have any recommendations on how to do this?
See:
:help filereadable()
Example:
if filereadable("Makefile")
let &makeprg = "make"
else
let &makeprg = "gcc -o foo foo.c"
endif
See also:
help let-option
help make
help makeprg
help 30.1
> Particularly I am confused on how to have a conditional autocmd,
> and how to extract a substring from the current buffer/file name.
See:
:help
:help fnamemodify()
:help expand()
:help filename-modifiers
:help extension-removal
Example 1:
let basename = expand(":t:r")
Example 2:
:set makeprg=make\ -o\ %<\ %
HTH,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Editing during compiling
Hi, if I compile something in vim (WinXP), vim is blocked during the compile process. If compiling is finished, I can edit my files again. Is there any possibility of editing during compiling like in Visual Studio, also seeing the errorlist growing during compiling? thanks a lot! Peter
Re: replace with a number sequence
but it kept going to the same spot as before. I will not change the [#].
Where is the match for (? I can't figure it out.
Using a simple change to Tim Chase' original substitution response, you have:
:'<,'>s/\d\+/\=line('.')-line("'<")
which replaces the *first number* on every line in the visual
selection. look at the difference between the two to see that the
responses have all used opIndex as a marker to know what number is to
be operated on.
this modification doesn't really allow for any fine degree of control
(like selecting which number on a given line to increment), but it
works for the examples you've given.
if you don't want to type it in every time,
:vmap :s/\d\+/\=line('.')-line("'<")
which adds ctrl-i as a key in visual mode to do the job.
the ex (colon) commands are one of the major parts of vim - I would
highly recommend learning them a bit more, if you want to get the most
out of the program. For me, without ex there would be very little
point in using vim at all - I couldn't even write to a file ;)
Cheers.
netwr problem
Hi, I am getting two errors in two Dr. Chip VIM plugins. 1) This error when editting via scp: Error detected while processing function netrw#NetRead..42_NetOptionRestore: line 43: E354: Invalid register name: '*' line 44: E354: Invalid register name: '*' I have the last netrw.vim (6577) updated via GetLatest. 2) This (minor message) error when opening a vimball file (.vba): ***vimball*** Source this file to extract it! (:so %) Error detected while processing BufEnter Auto commands for "*.vba": E119: Not enough arguments for function: vimball#ShowMesg I have vimballPlugin.vim version 6578 just downloaded. Thanks, Luis.
Re: replace with a number sequence
"Mark Woodward" wrote, On Mon, 2007-01-29 at 21:57 +1300, John Little wrote: Hi IMHO simpler and more flexible (works if there are lines not matching the pattern) is: :let n=0 | g/opIndex(\zs\d\+/s//\=n/|let n+=1 A useful idiom I learned here. Usually I muck around with ordinary searches until the search highlighting shows I've got it right, then :let n=0|g//s//\=n/|let n+=1 is what I have to remember, and it's obvious what the start and increment are. John Just as additional info this method also lets you perform this sort of incremental substitution on letters. UniqueID2 = lview.focusedItem.subItems.opIndex(0).text; Parent = lview.focusedItem.subItems.opIndex(0).text; Children= lview.focusedItem.subItems.opIndex(0).text; login = lview.focusedItem.subItems.opIndex(1).text; let i=97|g/opIndex(\zs\d\+/s//\=nr2char(i)/|let i=i+1 UniqueID2 = lview.focusedItem.subItems.opIndex(a).text; Parent = lview.focusedItem.subItems.opIndex(b).text; Children= lview.focusedItem.subItems.opIndex(c).text; login = lview.focusedItem.subItems.opIndex(d).text; let i=65|g/opIndex(\zs\d\+/s//\=nr2char(i)/|let i=i+1 UniqueID2 = lview.focusedItem.subItems.opIndex(A).text; Parent = lview.focusedItem.subItems.opIndex(B).text; Children= lview.focusedItem.subItems.opIndex(C).text; login = lview.focusedItem.subItems.opIndex(D).text; :h nr2char Since you brought it up, I also have this other situation, bla.blah.blahh[0].text; bla.blah.blahh[0].text; bla.blah.blahh[0].text; bla.blah.blahh[0].text; bla.blah.blahh[0].text; bla.blah.blahh[0].text; I tried using the original solution you gave me, :let n=0 | g/opIndex(\zs\d\+/s//\=n/|let n+=1 but it kept going to the same spot as before. I will not change the [#]. Where is the match for (? I can't figure it out. The next version of vim should have an easier way of doing this. I constantly have to copy from vim and paste to TextPad and doing it there and then copy from TextPad back to vim. Yes, I know I could make a function and assign a key to it, but these kind of things should be just built in. I know, I am a picky guy, aren't I? :-) thanks.
Re: replace with a number sequence
On Mon, 2007-01-29 at 21:57 +1300, John Little wrote: > Hi > > IMHO simpler and more flexible (works if there are lines not matching > the pattern) is: > > :let n=0 | g/opIndex(\zs\d\+/s//\=n/|let n+=1 > > A useful idiom I learned here. Usually I muck around with ordinary > searches until the search highlighting shows I've got it right, then > > :let n=0|g//s//\=n/|let n+=1 > > is what I have to remember, and it's obvious what the start and increment are. > > John Just as additional info this method also lets you perform this sort of incremental substitution on letters. UniqueID2 = lview.focusedItem.subItems.opIndex(0).text; Parent = lview.focusedItem.subItems.opIndex(0).text; Children= lview.focusedItem.subItems.opIndex(0).text; login = lview.focusedItem.subItems.opIndex(1).text; let i=97|g/opIndex(\zs\d\+/s//\=nr2char(i)/|let i=i+1 UniqueID2 = lview.focusedItem.subItems.opIndex(a).text; Parent = lview.focusedItem.subItems.opIndex(b).text; Children= lview.focusedItem.subItems.opIndex(c).text; login = lview.focusedItem.subItems.opIndex(d).text; let i=65|g/opIndex(\zs\d\+/s//\=nr2char(i)/|let i=i+1 UniqueID2 = lview.focusedItem.subItems.opIndex(A).text; Parent = lview.focusedItem.subItems.opIndex(B).text; Children= lview.focusedItem.subItems.opIndex(C).text; login = lview.focusedItem.subItems.opIndex(D).text; :h nr2char cheers, -- Mark
Re: A suggestion about runtime files and documentation
Hi Tony :) * A.J.Mechelynck <[EMAIL PROTECTED]> dixit: > Bram Moolenaar wrote: > [...] > >>I don't see how getting rid of hardcoded directories in the source > >>code is going to cause problems for users ;) In fact, hardcoded > >>directories may cause problems: if you modify "src/Makefile" and don't > >>reflect those changes in the source, for example. Of course, end users > >>shouldn't modify things under "src/Makefile" if they're marked as "DON'T > >>MODIFY THIS", but they don't have to work hard to do that and it will > >>cause problems. > > > >The warning is there: > > > >### Location of Vim files (should not need to be changed, and > >### some things might not work when they are changed!) > [...] > > Even though the README mentions it (recommends it?), personally I don't > believe in modifying the Makefile. I don't do it, because I think the same. I just pass the variables to make, and I must confess that it is risky, because the Makefile can ignore or even replace command line arguments (Vim's makefile doesn't). > I also believe in installing programs in their standard locations, even if > installing elsewhere might cause no trouble: if a standard install doesn't > work in the standard location, it's probably a bug; in a nonstandard > location, it could quite well be a false maneuver. I would call it "default locations" and not "standard locations". I think that a "standard location" is where the sysadmin feels a file belongs, following his system policies. And under UNIX, this can be a bit tricky, because some sysadmins will place some files in certain dirs so an app they have to perform some admin task will do its work easily, or things like that. Vim, being an editor with a big runtime, is a very special case, but on the average, any application using autoconf doesn't care about where its files are, as long as you have told it through configure at build time. Not a big deal using symlinks, of course (e.g., so the backup tool finds the files in the system's standard locations), but I prefer the autoconf way instead of having to tell things to "make" ;) I can live with all this, anyway ;) I'll try my best to prepare the patches but fortunately this is by no means urgent. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: A suggestion about runtime files and documentation
Hi Bram :) * Bram Moolenaar <[EMAIL PROTECTED]> dixit: > DervishD wrote: > > > I mean, that's not the point. The point is that the source code is > > using hardcoded directories, and that is not a good practice, even if > > you force to have all runtime files under the same directory, because > > someone could change one of the many variables under "src/Makefile" and > > have the files installed in a place where the source code (which doesn't > > use those variables) won't be able to find them. > > OK, so we should remove the variables from Makefile, so that nobody is > tempted to change them. Yes. Avoiding the risk, so to say. > It's mostly OK to hardcode the directory names in the source code, since > they can't be changed without causing lots of trouble. Well, in Vim's case, yes. Otherwise, hardcoding thing is, IMHO, not a very good practice. I've modified other's code a couple of times and hardcoded paths were a pain in the a*s. > > > If you really want to do it differently you are on your own. It's > > > good that this is difficult, so that people who are causing problems > > > for users will have to work hard to do that. > > > > I don't see how getting rid of hardcoded directories in the source > > code is going to cause problems for users ;) In fact, hardcoded > > directories may cause problems: if you modify "src/Makefile" and don't > > reflect those changes in the source, for example. Of course, end users > > shouldn't modify things under "src/Makefile" if they're marked as "DON'T > > MODIFY THIS", but they don't have to work hard to do that and it will > > cause problems. > > The warning is there: > > ### Location of Vim files (should not need to be changed, and > ### some things might not work when they are changed!) My first though when I saw that warning was "well, I'm supposed not to change this to fit files in my hierarchy, but the fact is that I can, and the Makefile is organized so changing these kind of variables move files around, like VIMRTLOC, so...". Given that you *must* change some of these variables in order to place runtime files in a non-default place, changing the rest is tempting if you need to move files around, and looking at the code to see which ones you can touch and which ones must remain intact is the hard job. Changing them is the non-hard job, and the errors that will appear not always are easy to connect to the modifications in the Makefile. > > If you don't want the hardcoded dirs removed (and that's your > > design, so I respect that), then how about getting rid of variables in > > the "*SUBDIR" and "*SUBLOC" families? This way is not hard, but > > IMPOSSIBLE to break things even using the hardcoded directories :) > > > > The change is amazingly simple and makes sense: SUBDIR variables are > > only used by SUBLOC variables, and those in turn are only used in the > > DEST_ variables, which make use of DESTDIR. A simple substitution will > > avoid risks and then users will *really* have to work harder to break > > things. And that includes annoying users like me ;))) > > > > I think this is a good idea (much less intrusive than that of > > modifying the source code) but hey, I'm not going to argue with you > > because I *really* love vim like it is now and I consider your work an > > amazing piece of code: elegant, easy to follow and does its job > > amazingly good. I'm not licking your arse ;), it's really what I think > > of vim. Consider the issue just a suggestion from a fan ;) > > Mostly this can be done. Cleans it up quite a bit. Only reason I can > think of to keep the variables is to avoid confusion about using the > name for something else than the subdirectory name. If you want me to, I can prepare a patch (agains 7.0.188) for the Makefile, and you can see if you like it. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: Weird problem with helpgrep
Hi Bram :) * Bram Moolenaar <[EMAIL PROTECTED]> dixit: > DervishD wrote: > > > > Generally I find it quite strange to order application-specific files > > > by their type instead of by the application. > > > > But that's a very sensible thing to do. This way you can partition > > the hiearchy much more efficiently. For example, I have my /usr "zone" > > backup recorded on a DVD, and the rest of my system is on a CD and a USB > > pendrive. This way, if my hard disk decides to break, I can have my > > system up and running again in less than 10 minutes, booting from the > > CD, putting the read-write portion of my system in a ramdisk (under > > Linux, I mean) and mounting my backup DVD as /usr. By dividing by type > > and not by app, all read-only files are placed under the same mount > > point. Take a look at the FHS standard for a much deeper rationale > > (e.g., the division between /var and /usr, for example). > > > > I know, it is weird outside UNIX, and when I started to use Linux, > > almost a decade ago, I found it very strange and mind boggling, but in > > the end, that kind of filesystem structure has been a bless ;)) > > There is a big difference between placing files by their properties > (e.g. being static or dynamic) or by their filetype. Not really, frequently the "filetype" is a property (for example, libraries, binaries, etc.). > In my opinion all > static files of a certain version of a certain program can be put > together. Only a few things might need to be spread to other > directories, using symlinks when possible (binary in /usr/local/bin, > libs in /usr/local/lib, header files in /usr/local/include). Well, I know about a packaging system that does exactly that (I don't remember its name). The problem is that maintaining that lot of symlinks is a mess, usually. It's easier (and IMHO more convenient) to use the installation system of the package to put the files where they belong (again, IMHO) in the first place. > > Of course, those kind of files should go under /usr/lib/vim: they > > are static data needed for the program to run. If you modify them > > frequently (and you shouldn't, because you have all the "/after" dirs > > for modifying the vim runtime behaviour), you can place them under > > /etc/vim, for example. I have my own runtime under /etc/vim because I > > consider them configuration files and not exactly a runtime. Having the > > documentation under /etc/vim is weird in that case. > > /etc is really a bad place for these files. Only files that contain > configuration options should go there. Some systems do have a > /etc/vimrc, but having system-wide editor defaults is not good. All the > default option values, as documented in the help file, might actually > be overwritten with different defaults then. I understand your point: the machine users end up with a vim whose default behaviour is not that of the documentation. > > The point is: I should be able to put the application files, > > separated by type, where they fit under my hierarchy, always under > > common sense (for example, doesn't put help files under /var/lib/). > > Things like autoconf or mobs do these kind of duties (amongs others). > > Autoconf only knows about generic things like man pages. You can't use > that for Vim help files or other application-specific things. But currently, with Vim, you can't use it either to set the runtime (you must give "VIMRUNTIMEDIR" and "VIMRTLOC" to "make"), which should be considered to go in "datadir". > > And, BTW, I have my own vim runtime under /etc/vim, with no subdirs, > > it is very small (only handles the filetypes I use, and indentation, > > syntax and the like are fully adapted to my likings) and I have it > > mirrored on a SVN server so I can go back and forth between revisions of > > the files ;) It's weird, but I can do it because vim is flexible enough > > to allow it (except for helpgrep, but that can be fixed without touching > > the source code at all). > > It sounds very much like you actually have your personal things in > system-wide directories. Oh, not at all, it's only that all the users in my machine want more or less the same set of defaults, so for me it's easier to put them in the system wide vimrc instead of maintaining changes in every home directory. > > > Anyway, using the directory from 'helpfile' for ":helpgrep" should indeed > > > be done. Otherwise it's not consistent with ":help". > > > > I think the same. > > > > > > I'm not familiar enough with the source to be able to add support > > > > for "helpfile" path to "ex_helpgrep" without resorting to a dirty > > > > hack, but I can try... "ex_helpgrep" looks like it is tailored to > > > > only process "runtimepath/doc" in the main loop, so any nonintrusive > > > > modification is almost impossible. > > > > > > I think that changing the source code would be the right thing to do. > > > > If you want, I can try to
