Re: Vim 8.0 Suggestion
Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). Martin -- Martin Krischik mailto://[EMAIL PROTECTED] pgpfEiBREWv3r.pgp Description: PGP signature
Re: Vim 8.0 Suggestion
On 1/30/07, Martin Krischik [EMAIL PROTECTED] wrote: Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). How do you mean? A lot of editors work like this. The Atari Editor is hardly the first, or last, editor to work this way. Sam works this way, Wily works this way, my editor ned works this way, James Brown's example editor Neatpad [1] works this way. It's usually down to the data structure used to manage buffer contents that defines whether it's possible to implement this feature or not. It's can also be down to support for various encodings that can require preprocessing of the files. I'm not sure to what degree Vim requires the whole file to be read before editing can commence. I'm, however, sure that it can be made to load files without too much preprocessing, but I'm also pretty sure that it would require a lot of work and I don't think it's worth the kind of time that Bram would have to invest in such a feature. Vim is, when it all comes down to it, designed to be a programmers editor, and that means that it'll mostly work with files smaller, mostly much smaller, than a megabyte, for which preprocessing works fine. nikolai nikolai [1] http://www.catch22.net/
Re: Vim 8.0 Suggestion
Nikolai Weibull wrote: On 1/30/07, Martin Krischik [EMAIL PROTECTED] wrote: Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). How do you mean? A lot of editors work like this. The Atari Editor is hardly the first, or last, editor to work this way. Sam works this way, Wily works this way, my editor ned works this way, James Brown's example editor Neatpad [1] works this way. It's usually down to the data structure used to manage buffer contents that defines whether it's possible to implement this feature or not. It's can also be down to support for various encodings that can require preprocessing of the files. I'm not sure to what degree Vim requires the whole file to be read before editing can commence. I'm, however, sure that it can be made to load files without too much preprocessing, but I'm also pretty sure that it would require a lot of work and I don't think it's worth the kind of time that Bram would have to invest in such a feature. Vim is, when it all comes down to it, designed to be a programmers editor, and that means that it'll mostly work with files smaller, mostly much smaller, than a megabyte, for which preprocessing works fine. nikolai nikolai [1] http://www.catch22.net/ IIUC, Vim loads the whole file in memory before starting to edit. It might be possible (but not necessarily worth the trouble on modern computers with their large memory and their huge virtual-memory addressing ranges) to only keep parts of the file in memory; but: - depending on the syn-sync setting, it may be necessary to scan part or all of the file in front of the edit point, even repeatedly, in order to synchronize the syntax highlighting properly. - if many scattered changes are made without saving the file, they may have to be written to the (Vim) swapfile, then later read from swap, causing a performance degradation over time. (I realize that for files which are larger than the available RAM, reading the whole file in memory actually always includes some virtual memory, which is OS swap, and not necessarily better managed than Vim swap.) - A command such as :$ or G (goto last line) can be implemented by seeking to EOF then scanning backwards; but for :8752 or 8752G (go to line 8752) I see no other possibility than counting the 8751 first ends-of-lines (if there are that many, of course), which means scanning the whole file until there. Of course, any search also requires scanning from the current location to the next match in the search direction (and the whole file if there is no match and wraparound is set). Loading the whole file in memory at the start allows building an index (or something) which will later allow lightning-fast access to any line given by number. I see this as an advantage when line numbers are known, e.g. when trying to evaluate a patch by looking at the parts of the source that it will change if applied, or when using a tagfile with line numbers (as opposed to a tagfile with search patterns). (And, yes, the index could be built incrementally as later parts of the file are accessed, but then a forward seek might seem to hang just because it goes to a part of the file not yet read from disk.) Vim is not only a programmer's editor (in the sense of an editor which can be used to edit source programs: even Notepad can do that). It can do any kind of editing, and it is particularly useful for complex editing tasks. If it is a programmer's editor, it is most importantly an editor which can be programmed (in five programming languages [six in version 7] including vimscript, which is a full structured-programming language for text, string, and integer processing). Unlike many other editors, it can handle any kind of text, including Unicode text, even if the underlying OS has no input method usable for arbitrary Unicode codepoints. The biggest file I'm currently using it for is 33.8 million bytes long. That file does take some time to load, and searching when there is no match, or no nearby match, does take a measurable time; but IMHO it remains bearable. Best regards, Tony.
Re: Vim 8.0 Suggestion
Dominique Pelle wrote: My wishlist for vim-8.0: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. This could perhaps have been useful ten years ago, but computers are now fast enough not having to do this. Lazy file loading causes quite a few problems: - You don't know how many lines there are, the CTRL-G command would not work. - If the file changes after starting to read it you get a big mess. - If the file is deleted after starting to edit it the user may be very surprised he lost the text. Recovery will also be impossible. - You quickly end up loading the whole file anyway if you search for a pattern without a match, do G, etc. - define spelling checker language for different part of the file (probably using syntax file). In the following example, I would like to let the spelling checker know that msgid strings are be English and msgstr are in French. msgid Any authenticated user msgstr Tout utilisateur authentifié This is in the todo list somewhere. It's not difficult to implement, mostly a question of how to define what language applies where. - option to ignore accent differences when searching for strings (a bit like :set ignorecase) ex: searching for cafe could find café /caf[[=e=]] I don't think we want yet another option to change the meaning of patterns. It's difficult enough as it is. -- Proof techniques #2: Proof by Oddity. SAMPLE: To prove that horses have an infinite number of legs. (1) Horses have an even number of legs. (2) They have two legs in back and fore legs in front. (3) This makes a total of six legs, which certainly is an odd number of legs for a horse. (4) But the only number that is both odd and even is infinity. (5) Therefore, horses must have an infinite number of legs. /// 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: Vim 8.0 Suggestion
On 1/31/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: On 1/30/07, Martin Krischik [EMAIL PROTECTED] wrote: Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). How do you mean? A lot of editors work like this. The Atari Editor is hardly the first, or last, editor to work this way. Sam works this way, Wily works this way, my editor ned works this way, James Brown's example editor Neatpad [1] works this way. It's usually down to the data structure used to manage buffer contents that defines whether it's possible to implement this feature or not. It's can also be down to support for various encodings that can require preprocessing of the files. I'm not sure to what degree Vim requires the whole file to be read before editing can commence. I'm, however, sure that it can be made to load files without too much preprocessing, but I'm also pretty sure that it would require a lot of work and I don't think it's worth the kind of time that Bram would have to invest in such a feature. Vim is, when it all comes down to it, designed to be a programmers editor, and that means that it'll mostly work with files smaller, mostly much smaller, than a megabyte, for which preprocessing works fine. nikolai [1] http://www.catch22.net/ IIUC, Vim loads the whole file in memory before starting to edit. It might be possible (but not necessarily worth the trouble on modern computers with their large memory and their huge virtual-memory addressing ranges) to only keep parts of the file in memory; but: [a list of reasons why preprocessing may be a hidden cost of commands being run on the file at around load-time anyway.] That is all true, but under certain conditions it may still be the case that pre-loading the whole file is unnecessary. Loading the whole file in memory at the start allows building an index (or something) which will later allow lightning-fast access to any line given by number. Considering that lightning travels at the speed of light, I'd say that this is an overestimation of the line-lookup routines. Vim is not only a programmer's editor (in the sense of an editor which can be used to edit source programs: even Notepad can do that). My statement was more about the size of a typical file loaded into Vim than its specific uses. I consider(ed) that to be obvious. nikolai
jump from word to word
Hi all, w jumps from word to word. However, it considers German umlauts (äöüÄÖÜ) and German sz (ß) as word end. For example, w stops at the indicated positions: Schwämme überall. ^ ^^ ^^ ^ However, I would desire instead: Schwämme überall. ^^ ^ Any idea how to teach Vim to consider special characters as mentioned above as normal letters? Thanks for any hint. Claus
Re: jump from word to word
Hi, Claus Atzenbeck wrote: w jumps from word to word. However, it considers German umlauts (äöüÄÖÜ) and German sz (ß) as word end. For example, w stops at the indicated positions: Schwämme überall. ^ ^^ ^^ ^ However, I would desire instead: Schwämme überall. ^^ ^ Any idea how to teach Vim to consider special characters as mentioned above as normal letters? :help word :help 'iskeyword' Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)
RE: jump from word to word
Try using capital W instead. Roy Fulbright From: Claus Atzenbeck [EMAIL PROTECTED] To: vim vim@vim.org Subject: jump from word to word Date: Tue, 30 Jan 2007 09:30:42 +0100 (CET) Hi all, w jumps from word to word. However, it considers German umlauts (äöüÄÖÜ) and German sz (ß) as word end. For example, w stops at the indicated positions: Schwämme überall. ^ ^^ ^^ ^ However, I would desire instead: Schwämme überall. ^^ ^ Any idea how to teach Vim to consider special characters as mentioned above as normal letters? Thanks for any hint. Claus _ Valentines Day -- Shop for gifts that spell L-O-V-E at MSN Shopping http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095tcode=wlmtagline
RE: jump from word to word
On Tue, 30 Jan 2007, Roy Fulbright wrote: Try using capital W instead. Thanks, this helps. I read about it when I started using Vim, however, apparently I forgot that. Claus
Deleting control line feed in string
Hello, quite simple question: How can I delete a control line feed in a string I tried: Let value = substitute(string,\\n,,g) But doesn't work. In vim7, I used Let list = split(string) Let Value = list[0] But this doesn't work on vim6.3 on older machine, where we have installed that version. Thank you for your help Best Regards Stefan Mueller
Re: Weird problem with helpgrep
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: DervishD wrote: Given that /usr/doc or /usr/share/doc are pretty standard when it comes to install documentation, shouldn't ex_helpgrep use the directory from helpfile too, just like :help does? Vim documentation must be in the runtime directory. It doesn't make any sense to put it below /usr/doc. These are help files, not generic documentation files. I hadn't seen this from that point of view. For me they were documentation (as things you put under /usr/doc) rather than help files (as things you probably should place under /usr/lib). 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 ;)) You scatter files all over the system and are left with files that you don't know where to put (there is no /usr/syntax, /usr/indent or /usr/vimplugins). 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. But that's not the point. The point is that I may not want to use the default runtime. Then, where should I put the documentation for Vim? OK, they may count as help files, and so they should go under /usr/lib/vim/doc, no problem with that. But imagine I have a system which indexes ALL documentation in my system. Then I'll prefer to have all the documentation under /usr/doc. 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). 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). 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 make the modification, but since I'm not familiar with the code, I cannot make promises about the code quality O:) Thanks for your answer :) 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: Don't take me wrong: I'm not critisizing Bram's amazing work with Vim, and I'm not asking for this to be fixed. What I really mean is that Vim will be more flexible if it doesn't have that hardcoded paths and that I'm ready to prepare patches to modify this, one dir per patch, if Bram will accept them. So, Bram, if you could tell me where the limits are for the patches you will accept, or if you could tell me a good reason for not doing this (and I don't want this done is a perfectly good reason for me, Vim is yours and not mine, and it's good enough for me as it is), I will prepare as many patches as needed to fix this situation, at least for things like documentation, the runtime subdirs can be fixed after that. I recommend putting the files below the $VIMRUNTIME directory. Thus keep all Vim runtime files together. I don't see how this can break any recommendation. How can the LSB define something that goes against how Vim uses subdirectories in $VIMRUNTIME? This is not about policy, under LSB all vim files fit together under /usr/share/lib/vim, for example. That's not the point. In fact, even considering that help files are documentation (and you've stated clearly that they are not, in other message), a simple symlink will do the job for tools that handle documentation automatically. 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. 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. 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 ;) Again, thanks for your answer and for taking the time :) 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: jump from word to word
Claus Atzenbeck wrote: Hi all, w jumps from word to word. However, it considers German umlauts (äöüÄÖÜ) and German sz (ß) as word end. For example, w stops at the indicated positions: Schwämme überall. ^ ^^ ^^ ^ However, I would desire instead: Schwämme überall. ^^ ^ Any idea how to teach Vim to consider special characters as mentioned above as normal letters? Thanks for any hint. Claus :help 'iskeyword' Best regards, Tony.
Re: jump from word to word
On Tue, 30 Jan 2007, Jürgen Krämer wrote: note that W uses Vim's definition of WORD, i.e., any sequence of non-blank characters separated by white space is considered to be a WORD. In practice this means that W will not stop at commas, dots, exclamation marks, quotes, etc. It might be better to :set iskeyword=@,48-57,_,192-255 which considers all characters where the C runtime function isalpa() returns TRUE, all digits, the underscore, and all characters in the range from 192 to 255 to be part of a word. Then w should work as wanted. Perfect. This is exactly what I wanted. Thanks! Claus
Re: Deleting control line feed in string
* Mueller Stefan [2007.01.30 07:56]: How can I delete a control line feed in a string :s/\\n// Should do what you want. Insert range as appropriate. Or :let value = substitute(string, n,,g) :h substitute() Discusses this specific case. HTH, -- JR
Re: Deleting control line feed in string
Jean-Rene David wrote: * Mueller Stefan [2007.01.30 07:56]: How can I delete a control line feed in a string :s/\\n// Should do what you want. Insert range as appropriate. Or :let value = substitute(string, n,,g) :h substitute() Discusses this specific case. HTH, Jean-René, I think you and I don't understand Stefan's question the same way, so let's ask: Stefan: Does your string contain backslash-n (two characters), in which case Jean-René's solution should work, or does it contain ^J (0x0A aka linefeed, one control character) in which case we should try \n instead, and try to find something else if it doesn't work? Best regards, Tony.
Re: Structure of runtime directory on ftp.vim.org
Bill McCarthy wrote: I don't know why, but the spell directory is missing for dos/. Because the files in the spell directory are exactly the same for Unix and DOS. They are quite big too, thus saving the space is worth the effort. Thanks for the explanation. Comparing the ftp site's spell directory to the one in my $VIMRUNTIME\spell, I see only these files in common: README.txt README_en.txt en.ascii.spl en.ascii.sug en.latin1.spl en.latin1.sug en.utf-8.spl en.utf-8.sug These files are in $VIMRUNTIME\spell but missing from the ftp site: cleanadd.vim fixdup he.vim main.aap yi.vim The files in the ftp site that are missing from $VIMRUNTIME\spell appear to be only foreign language files. There are a few differences between what is on the ftp server and what is in the distributed archives. I use separate lists for this. I'll check if this can be turned into one list to avoid future changes to make them grow differently. -- hundred-and-one symptoms of being an internet addict: 73. You give your dog used motherboards instead of bones /// 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: Weird problem with helpgrep
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. 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). Config file goes in /usr/local/etc, dynamic things below /var somewhere. I don't see a reason to move documentation files, unless they are in a standard format and will be found by generic tools. There is a standard place for man pages, of course (well, ignoring language and encoding, there doesn't seem to be a widely used standard for that). You scatter files all over the system and are left with files that you don't know where to put (there is no /usr/syntax, /usr/indent or /usr/vimplugins). 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. But that's not the point. The point is that I may not want to use the default runtime. Then, where should I put the documentation for Vim? OK, they may count as help files, and so they should go under /usr/lib/vim/doc, no problem with that. But imagine I have a system which indexes ALL documentation in my system. Then I'll prefer to have all the documentation under /usr/doc. You could put a copy of the Vim help there, if your indexing system can handle it (never seen that). I would not _move_ it there. Using symlinks would come in handy. Nevertheless, if somehow the format of the Vim runtime files change (e.g., help files are compresed), your system will fall down. 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. 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. 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 make the modification, but
Re: A suggestion about runtime files and documentation
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. It's mostly OK to hardcode the directory names in the source code, since they can't be changed without causing lots of trouble. Of course it would be nicer to put them together somewhere, but since C doesn't support string concatenation this causes inefficient string operations in quite a few places. E.g. to source the syntax/syncolor.vim script you would first need to use sprintf into a buffer. 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!) 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. -- hundred-and-one symptoms of being an internet addict: 70. ISDN lines are added to your house on a hourly basis /// 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///
