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 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=24095&tcode=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
Re: jump from word to word
Hi, Claus Atzenbeck wrote: > 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. 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. 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)
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 woul
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///
Re: A suggestion about runtime files and documentation
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. In my experience, all useful compile-time settings for Vim can be set without modifying the Makefile (or the src/Make_*.mak), by means of environment variables and/or command-line arguments to the "make" program. The former can be set permanently (such as, for W32, the location or version of a certain interpreted language) and both can be set in a shell script wrapper, so they don't have to be re-input at every compile. 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. Best regards, Tony.
Re: Conditional autocmd question
Evan Klitzke 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? Particularly I am confused on how to have a conditional autocmd, and how to extract a substring from the current buffer/file name. I have also thought about modifying my existing auto commands to execute only if the current buffer is unmodified (i.e. has been saved since the last edit). How would I add such a check to my auto commands? Thanks in advance! -- Evan Klitzke autocmd EventName * if ! &mod | DoSomething | endif see :help expr-option :help :bar and possibly :help line-continuation Best regards, Tony.
