Re: good keys for mappings
Hi Arn :) * Arn [EMAIL PROTECTED] dixit: Any suggestions on keys/key combos that are good candidates for custom mappings etc? Maybe a dumb question but I hate having to unlearn something, I'd like to create a fair number of mappings that use a consistent convention and won't conflict with anything existing. I think Bram mentioned he's found prefixing with _ works well.. I think that, apart from '\' (backslash) and probably '_' (underscore) there aren't many keys available for everyone to use as mapleader. This said, depending on your keyboard layout, you may find interesting candidates: for example, my spanish keyboard comes with ç, which is just under my right little finger and that I almost never use. So, I've remapped some combos to 'çç', 'ç+', 'ç-', etc. That is, the key I don't use and the keys that are near to it. This is very useful to me, but this works only on spanish keyboards. Which layout do you use? 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: good keys for mappings
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: But I'd say the F keys are the safest in general, especially when taking portability into account. Of course: if you plan to use more than one vim or more than one keyboard type, the F keys are the best choice. In fact, for complex commands I think that they are the only option, because that way you will be able to do these complex commands in any keyboard. But for simple things (like my 'çç', which is just a shorcut for gqip more or less) I prefer a key which is near to my blind typing position. 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: OT: Apparently I work for Bram...
Hi Tim :) * Tim Chase [EMAIL PROTECTED] dixit: Well, a year or so later, somehow that combination of my name and Bram as a business found their way together and I just got a magazine addressed to me at my company, Bram Moolenaar. Holy *... That's just incredible XDDD Usually, when asked for a company name, I use Probably I'm doing something highly delictive, or something like that. Not that the computer gets the funny message, but... 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!
Is this normal?
Hi all :) This is not a bug report, it's just I'm curious about a behaviour I've observed in vim, and I would like to know if this is the correct behaviour or if some of my mappings may be causing the effect. Let's say I have these two lines in a file: this is one line this is another line, longer If I'm in insert mode and I put the cursor in the first line and then I hit End, the cursor is placed after the e in line. Then, if I press Down, the cursor goes after the r in longer (I wanted to put it on the l in line, in the second line). If instead of End I use C-O$, this doesn't happen, and in normal mode, it doesn't happen even using End. Is this normal? Is it caused by 'virtualedit'? I've observed this behaviour in my own compiled version of Vim and in the packaged one in Debian, at least, and I'm just curious. Thanks! 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: Is this normal?
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: Is this normal? Is it caused by 'virtualedit'? I've observed this behaviour in my own compiled version of Vim and in the packaged one in Debian, at least, and I'm just curious. It is normal and it has nothing to do with 'virtualedit'. If you place the cursor intentionally at the end of a line, using End in Insert mode, End or $ in Normal mode, etc., then moving the cursor up and down keeps it at the end of the line. See at the end of the :help up-down-motions section: I was looking at :help end, in 'motion.txt' instead... My bad O:)) Thanks a lot for pointing to the explanation :)) 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!
Problem when formatting commented text
Hi all :) Probably you've noticed that I'm used to indent the first line of the paragraphs I write. I'm sooo used to do this that I'm not doing it conciously, so I do it on comments, too. The thing is that I've set 'fo+=2' to use the intentation from the second line of a para, not the first, and it works perfectly... as long as there are no comment leader on the line. If there are a comment leader, and even though I have 'fo+=c', the comment leader is properly placed but all lines have the same indentation: that of the FIRST line. Moreover, sometimes only the first line is reformatted (using the indent) while the rest are not (that happens in mail filetype, for example). I can post examples here if I haven't explained all this properly. Can I fix this tweaking 'fo', or 'comments', etc., or should I use 'formatexpr' or even an external formatter (like par)? Thanks a lot in advance : 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: Insert mode and arrow keys philosophy
Hi Laurent :) * vim [EMAIL PROTECTED] dixit: About the wrist movement that's just as bad when you hit ESC as when you use the arrow keys: just do the movement in slow motion for yourself: Yes, I've done it: the distance (in my keyboard at least) from touch typing position to ESC and arrows is more or less the same (measured from little finger to key). I have to move the same set of parts and muscles, only in different directions (northwest for ESC, southeast for arrows). Having the ESC key remapped DOES make a difference. I've tested a bit and I move a bit faster (not counting errors due to insist that 'j' is left instead of 'h') mapping ESC to 'jj' and using hjkl. Unfortunately, I still have problems using 'h' :( If it is true that at first some of the shortcuts are a bit 'unnatural' and could feel like you type twice more to reach the same results as with using the keyboard-provided keys, in the long term, once you've mastered motion in Vim, you'll realise that it's tuely priceless and it does speed up your typing. You must take into account another thing: in any other program you end up moving using the arrows and movement keys. So, doing movement without thinking in vim is difficult to me, because a whole lot other programs I use force me to use the arrows (no problem, because I don't type as much text there, so I can keep my hand on the arrows). Learning two sets of movements are not that difficult, but anyway *is* difficult. And of course, I'm not discussing that having the hand at touch typing position really improves performance at the keyboard: that's true. And blind typing does, too. The point I try to make is that ESC is a very bad key to switch modes, but a simple mapping solves that, really. Good luck with it! Thanks ;)) I'm still learning motion commands appart from hjkl, and probably I will make a plan: learn to move by chars (done), after that do it by words and later go to more sophisticated commands like 'f'. 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: Insert mode and arrow k eys philosophyç
Hi Yakov :) * Yakov Lerner [EMAIL PROTECTED] dixit: On 2/20/07, DervishD [EMAIL PROTECTED] wrote: I suspect that the main reason behind the hjkl (which is very unnatural for me, the arrows have a much better design with the inverted T at least IMHO) was that the first keyboards used to develop/use vi probably hadn't arrow keys, or they were very far at the right of the keyboard. The keyboard on which the original author of vi (Bill Joy) worked indeed did not have the arrow keys. See http://en.wikipedia.org/wiki/Vi for the layout and the name of the keyboard. Oh, my loved Wikipedia ;) I forgot to take a look to see if the Vi entry had this kind of trivia data. Thanks for the link! 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: Insert mode and arrow keys philosophy
Hi Pavel :) * Pavel Shevaev [EMAIL PROTECTED] dixit: On 2/21/07, DervishD [EMAIL PROTECTED] wrote: Unfortunately, I still have problems using 'h' :( That's my biggest problem at the moment as well, as a blind typer i can't get used to it...oh, i think i just should stop whining and exercise more ;) Me too! ;)) My problem is not really blind typing or touch typing, I can do it. My problem is that my brain doesn't associate movement one key at the left. I have my fingers over jklñ (a spanish keyboard), so moving around with those four keys is OK to me, but hjkl is a bit more difficult. I suppose I can map them, but if I learn moving around using hjkl I want to learn it to be able to use it in any vim or vi I use. As you very intelligently said: I should stop whining and exercise more! ;))) 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: Insert mode and arrow keys philosophy
Hi Laurent :) * vim [EMAIL PROTECTED] dixit: The idea behind using h/j/k/l is to avoid moving your hand/wrist too often while going back and forth between your keyboard and the arrow set (although the use of h/j/k/l might have originated for other reasons back in the old 'vi' days). Hitting ESC doesn't make your wrist move? I may have a very small hand, but I have to move my left hand for hitting ESC. I suspect that the main reason behind the hjkl (which is very unnatural for me, the arrows have a much better design with the inverted T at least IMHO) was that the first keyboards used to develop/use vi probably hadn't arrow keys, or they were very far at the right of the keyboard. Of course I may be wrong here, I wasn't there ;)) but at least in my case, the most moving I do is *when inserting text* (well, when modifying existing text, to be more precise), and using ESC and the different motion commands slows down my editing a lot. Using the arrow keys and the Home/End, PgUp/PgDn keys makes my editing much faster. I'm a touch typer, and I can find my position again in the keyboard pretty fast, but I find more difficult to do it after hitting ESC than after using the arrow keys. In addition to this, my touch typing position is with my index finger on the 'j', and not the 'h'. To hit 'h' I must displace my index finger and that's slower for motion than having my fingers on the inverted T. Weren't for the ESC key to go to normal mode, I will never use the arrows, just because having the hands in touch typing position is much faster, period. But hitting the ESC key to go to normal mode, hit a couple of keys for doing the movement and hitting 'i' again is slower than keeping in insert mode and using the arrows, at least for me. Probably if I had learnt to use an editor with vi, I will get used to hit the ESC and change modes fast, but I hadn't and now hitting ESC is very unnatural to me, even though I use it in my shell to clean the command line!. It's just a mental attitude, I know, but... What I try to mean with this message is that hjkl is not necessarily faster even if you touch type. 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: Insert mode and arrow keys philosophy
Hi Gene :) * Gene Kwiecinski [EMAIL PROTECTED] dixit: I suspect that the main reason behind the hjkl (which is very unnatural for me, the arrows have a much better design with the inverted T at least IMHO) was that the first keyboards used to develop/use vi probably hadn't arrow keys, or they were very far at the right of the keyboard. Pretty much so. Early dumbterminals (think ADM-3a and similar critters) didn't have arrow keys, but they *did* go so far as to have little arrow marks on the keycaps themselves, underneath the letters, on -- you guessed it -- h/j/k/l. I did see this in an old Ultrix terminal. Don't ask me which model, because this was back in the university and I don't remember. I just remember vi from that machine and was very painful. I was used to boxer, a DOS editor (very powerful for 1992, I must say), so original vi didn't fit my expectations ;)) Hit *control* instead, for ^H (backspace), ^J (linefeed), ^K (vertical tab), and ^L (formfeed), and you get the cursor motions left/down/up/right, respectively. Thanks! I always wondered why those letters where control chars for movements (or quasi-movements) :)) Gawd, I feel old... Me too XDD Nice answer, you've provided a couple of very useful information, at least for me (I'm *very* curious) ;) 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: [Fwd: Re: Insert mode and arrow keys philosophy]
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: to hit the ESC and change modes fast, but I hadn't and now hitting ESC is very unnatural to me, even though I use it in my shell to clean the command line!. If the Esc key is too far, you may try using Ctrl-[ instead -- Vim sees it as Esc. Worst for me: I have to move both hands: Ctrl is... well, Ctrl, too low, and my [ key is on the far right and, normally, it would need Alt-Gr to be pressed. I prefer the mappings you've posted below ;))) One of my most precious maps is imap jk esc imap jj esc provided you don't have any other imap that starts with jj or jk (you will have to wait for the timeout), and you don't type words with that two letters next to other (I doubt spanish has any) it's very handy. I don't use any language with something like 'jk' or 'jj' (although I've written that combination some times in *this* thread!), so they fit pretty well and avoids me hitting ESC. Sometimes I just forget how powerful are vim mappings. It doesn't seem natural to me to map letters in insert mode O:))) Thanks for your help, as always! 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!
setlocal enc=utf8 and mappings
Hi all :) I'm having a problem that I know how to solve, but I wonder if I'm doing the right thing... Some weeks ago I asked a couple of things about encodings on the list, and based on the answers, I finally did a proper setup to edit UTF-8 files from time to time in my latin1 terminal, while at the same time treating new ASCII files as latin1 and not utf-8. This works OK. But now my problem is the following. I've chosen ç as my mapleader. This is due its position in my keyboard. BUT, its code in latin1 is 0xe7 and, in utf8 it's 0xc3+0xa7. This means (and this is my problem) that if I set setlocal enc=utf8, I'm no longer able to use it as my mapleader as-is. I still generate ç when I press it, of course, and vim translates it onto something my terminal understands as ç. I assumed that it was doing the same for mappings, but it is not. Am I doing anything wrong? Should I set another thing so even with enc=utf8 my high-bit-set-mapleader still works? Should I set mapleader to the utf8 value? Thanks a lot in advance :) 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 question about syntax file and vim regexps
Hi Kib :) * kib2 [EMAIL PROTECTED] dixit: I wonder if I can highlight more things in Python, I would like to highlight functions call , i.e in a Python source, in the following line: os.popen(...) be able to highlight the word popen. is it possible ? Yes, it is. First, check the Python syntax file: if it already has a syntax group for such constructs, you just need to do: hi def TheSyntaxGroup ... See :help highlight for that. If the syntax file doesn't have such construct, you will need to do something like this (UNTESTED!): syntax match PythonFunCall \I\i\+.\zs\I\i\+\ze( hi def PythonFunCall ... The regex means: \I Identifier character except numbers \i Identifier character including numbers \+ One or more of the last atom .A literal dot \zs Here starts the match (so, the coloring) \I Id \i Id \+ Id \ze Here ends the match (so, the coloring) (A literal open parentheses Please note that I'm not sure about \zs and \ze being legal in a syntax match command. If they aren't, use [EMAIL PROTECTED] and family instead (see :help zero-width for that). 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: CTRL-S functionality to a letter combo like i.e. cs
Hi Eric :) * Eric Leenman [EMAIL PROTECTED] dixit: When using vim on Linux these don't work anymore because of linux windows managers. Well, that's not exact: the window manager may have its key mappings for internal use, but it's X which is managing the keyboard. If the window manager is using Ctrl-S, for example, you won't be able to use it in your gvim, unfortunately. Well behaved window managers should allow you to change the mappings (the Gnome window manager *is* well behaved, for example). Is it possible to put the same functionality of the CTRL-key (and/or ALT) to a key which is not linux windows manager sensitive? Of course, use the mapping commands. See below for an example. In other words: Is it possible to remap the ctrl key to for example the letter c? Not a good idea in insert mode ;) but you can do it. For example, even in insert mode, I've mapped çç to gqip, but I'm still able to type a ç or even a double ç. Vim allows that :) So that when you are in insert-mode you can press cs as a replacement for CTRL-S? Let's say you don't use so much cs, so you can afford to wait a bit between c and s when you *actually* have to type that in insert mode. Then, you can do this (for saving): imap cs C-O:w But I suggest you to use the Vim keys for the task unless you're very used to the C-S, C-X, C-V and C-C, because the vim keys work everywhere and because things like C-S and C-C usually have other meanings under Linux (namely, stop the character flow to the terminal, and the keyboard interrupt, respectively). Vim keys and the vim way of doing things is easy to learn. Believe it or not, after using vim for only a month in my entire life, I'm so used to it that most of the time I hit :q to exit from elinks or Mutt! 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: Question on highlighting
Hi Sean :)
* Sean Hubbell [EMAIL PROTECTED] dixit:
I would like to be able to shade (use the same background color, but
make it lighter) the text between two braces (spanning multiple lines
and possibly nested). What is the best way to accomplish this?
If you're already using a syntax file (e.g. the vim runtime provides
a syntax file for the language you're interested in), you may dare to
modify it, or to write your own modifications in some ~/.vim/after/.*
syntax file.
If exists a syntax file suitable for you in the vim runtime *and* it
already provides some syntax group for the text between two braces,
then you're lucky, because you just need to add something like:
hi Shaded ...
hi link NameOfTheGroup Shaded
To know what to put in the ..., see :help highlight.
If you need to add your own group (or if no syntax file exists for
that language), I think that your best bet is using a region:
syntax region TextInBrackets start={ end=}
hi TextInBrackets ...
Again, see :help highlight and :help syntax. If you could
ellaborate a bit on your problem (language you're using, which terminal
do you use, for example), I may give you more precise help regarding
colors, and the like.
I hope that helps :
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 François :) * François Pinard [EMAIL PROTECTED] dixit: [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). [...] 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. Stow!, that's the name I didn't remember :) Thanks for pointing! 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: Hi, Can I register for the right to post in the mail-list?
Hi Jiang :) * Jiang Ting [EMAIL PROTECTED] dixit: I am a plain vim user, mostly working on latex, C++ and fortran programming. I began to use vim for 4 months and there are always some technical problems around. The suggestions from the mail group may be very helpful for me. Given that you've already post to the list, then you're subscribed ;) so you can post here freely. You're going to find very nice, kind and helpful people here, this list is really great. For my own part, I'll try to help you as much as I can, although I'm a newbie in Vim (I've been only using it for a month). Welcome to the Vim list :)) 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: 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: 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: Weird problem with helpgrep
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: I've discovered that :helpgrep pattern doesn't work for me, always returning E480 (BTW, :help E480 shows help about argdelete, as if E numbers in source code and docs weren't synchronized). But that's not the weird part. If I search for a very common word (let's say most, for example), helpgrep returns the E480 error and it does *lightning fast!*. That's the weird problem it is not doing the search at all, and the E480 error is probably masking the real problem, which I couldn't isolate. Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set helpfile so :help finds the docs. BUT :helpgrep doesn't use helpfile, but only runtimepath/doc. This is a problem for me, because no matter which value I assign to runtimepath, the documentation is not going to be found in any /doc subdir! 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? [...] Any suggestion instead of modifying the sources *and* moving the documentation? I would like to use :helpgrep O:) Here, :help E480 shows help about :argdelete, and the help tags :argd :argdelete and E480 are on a single line. It should show help about the No match, am I wrong? Maybe you are using wrong syntax? To use your own example, the syntax to search for most as a separate word is :helpgrep \most\ I've tried that, too. The problem is that :helpgrep doesn't find any help file because it is not searching for where the help is really installed. 1) Use :vimgrep instead of :helpgrep. The syntax is different but you ought to get access to the same results, albeit not in a help window but in the current window (use :new before :vimgrep to do it in a new window). To use the same example again (and an imaginary directory location): :vimgrep /\most\/g ~/mydocs/vim/doc/*.txt As a variation of this, you could use the following: command -nargs=1 -bar HelpGrep vimgrep /args/g ~/mydocs/vim/docs/*.txt cabbrev HG HelpGrep You could then use :HelpGrep (or :HG) instead of :helpgrep. If you don't need the abbreviation, then of course you can skip the cabbrev definition. I think that's the better idea, thanks a lot :) I never thought about using :vimgrep :)) 2) Don't set 'helpfile' but create softlinks from the standard location to the actual location. (This requires the ability to create softlinks, which is easily available in Unix/Linux and Cygwin, but is absent, undocumented or esoteric on most native-Windows systems, unless shortcuts provide the same functionality.) 3) Bite the bullet and move the docs to their standard location. This ought not to require a recompilation. I don't like either solution: while I respect Bram's decision about where to put Vim files, Vim is breaking the standard here under Linux, and it can be easily fixed by, instead of hardcoding /doc/ in the source code and look in runtimepath, it used something like HELPSUBDOC and HELPSUBDIR (which, btw, are already in the file src/Makefile). Thus, by changing a couple of building options, things will work seamlessly. By now I'll use your suggestion about a new command, but if Bram wants, I can prepare a patch to replace the hardcoded directories by build-time constants or even run-time variables. That will take some time, but it can be done one-dir-at-a-time. I'll post this on the list just in case Bram doesn't read this message. Thanks a lot, Tony : 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!
A suggestion about runtime files and documentation
Hi all, specially Bram :) The source code for vim is full of hardcoded directories, rendering useless the constants defined in src/Makefile. Moreover, it doesn't use configure values to establish locations, but that's a minor problem. The major problem is that this scheme breaks LSB for example (which is not a big deal anyway), but the real problem is that the code has dirs hardcoded, and that's not a good idea, usually. 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. Thanks a lot in advance :) 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 Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: That won't work, because docs are not in /usr/doc/vim/doc, but in /usr/doc/vim. Otherwise it would work. On my system, documentation is under /usr/share/doc/packagename (the share part is variable, since I maintain two different systems, one with shareable data and other withouth share). Well, you could, rather than setting 'helpfile', use the following then (in your friendly *sh shell): cd /usr/share/vim/vim70 ln -sv ../../doc/vim doc [...] Well, usually I don't like to have the system full of symlinks to fix this kind of problems. Using symlinks, you can have your apps installed using a Windows-like scheme (you know, that crap called Program Files) while having an UNIX compliant hierarchy, but that's not a good idea. But... You could even leave everything as-is, and use cd /usr/doc/vim ln -sv . doc ...this is how I have set it right now to avoid problems and to avoid modifying the source. Even though, I still think that this is not the way: hardcoded patchs are, generally, not a good idea. Soft links are powerful! Yes!, but they can become a mess ;)) But you're right, they're very handy, specially for fixing this kind of situations :))) 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!
Weird problem with helpgrep
Hi all :) I've discovered that :helpgrep pattern doesn't work for me, always returning E480 (BTW, :help E480 shows help about argdelete, as if E numbers in source code and docs weren't synchronized). But that's not the weird part. If I search for a very common word (let's say most, for example), helpgrep returns the E480 error and it does *lightning fast!*. That's the weird problem it is not doing the search at all, and the E480 error is probably masking the real problem, which I couldn't isolate. Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set helpfile so :help finds the docs. BUT :helpgrep doesn't use helpfile, but only runtimepath/doc. This is a problem for me, because no matter which value I assign to runtimepath, the documentation is not going to be found in any /doc subdir! 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? 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. Any suggestion instead of modifying the sources *and* moving the documentation? I would like to use :helpgrep O:) Thanks a lot in advance :) 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 doubt with syntax region
Hi Andy :)
* Andy Wokula [EMAIL PROTECTED] dixit:
DervishD schrieb:
That is, the contained item is swallowing part of the start
match!. I thought that when the match for start was performed, the
matched test wasn't tried for any other match, including contained
items. Obviously, I was wrong (or I misunderstood the entire issue), and
I don't know if, just using regions, I can have a match like this:
example{{weird} and some mor{}e text}
^
that is, that the first opening brace is not swallowed by the
contained syntax item. As you can see, the contained item must be
allowed to start with {.
:h :syn-matchgroup
| In a start or end pattern that is highlighted with matchgroup the
| contained items of the region are not used. This can be used to avoid
e.g.
syntax region SomeRegion matchgroup=SomeRegion start=\I\i*{ ...
I thought that you cannot use matchgroup with the same group as
the region group. That is, that the only use of matchgroup was to
have a region highlighted the region color and the separators
highlighted in a *different* color. I didn't carry a test for this!
Moreover, I considered that if you used the same group both for the
region and for matchgroup, you will end up with the entire region
highlighted with the group color: the text withing the region because
you issued a syntax region Group and the separators because you did
the matchgroup thing. So, I didn't even consider that the *inside* of
the region won't be colored at all.
This is for sure my fault, I misunderstood this because I didn't
noticed this paragraph:
In a start or end pattern that is highlighted with matchgroup the
contained items of the region are not used. This can be used to avoid
that a contained item matches in the start or end pattern match. When
using transparent, this does not apply to a start or end pattern
match that is highlighted with matchgroup.
Sorry for the inconvenience, I really thought I had read all the
relevant help for this issue, I'm embarrased O:
Thanks a lot, Andy, for your kind answer with the solution :)
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!
Maintaining patterns
Hi all :) Another weird question O:) Let's suppose that I search frequently for a very complex pattern. This is easy to do using a keymap, for example. But let's assume that I also search frequently using the same pattern preceded by an arbitrary char *AND* followed by the same char. The char varies from search to search. In Perl I would store the complex pattern in some scalar, but I don't know how to do it in VimL. Probably it can be done with let and eval, but it won't work for syntax highlighting, AFAIC. Moreover, if I'm writing a syntax file and have a lot of syntax items that contains the same complex pattern preceded and followed by a character (this is only an example), that's difficult to maintain because each time I have to change the complex pattern I have to change it everywhere. Please note that this cannot be fixed modifying the pattern adding an whatever\? atom at the front and end of it, because the whatever MUST be present at BOTH ends. For the syntax highlighting, using contains solves the issue, but again, this doesn't work for searches. In the end, the problem is to be able to reuse a pattern, no matter if in a search, substitute, syntax highlighting, etc. And not, \z(\) is not a solution because it only works in start= in syntax regions. Is there a way of storing a pattern and reusing it in searchs, substitutions, syntax highlighting, etc? Thanks a lot in advance :) 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: Maintaining patterns
Hi Tony :) Once more, Antoine came to the rescue :)) You're great, dude :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: In Perl I would store the complex pattern in some scalar, but I don't know how to do it in VimL. Probably it can be done with let and eval, but it won't work for syntax highlighting, AFAIC. In Vim you can store the pattern in a variable or in a register. At the keyboard, you can recall a register in Command-line or Insert/Replace modes by hitting Ctrl-R followed by the register name (e.g. ^R/ to recall the latest search pattern, ^Rw to recall register w, ^R= followed by an expression then Enter to evaluate that expression, etc.) Yes, I knew this, but I thought that patterns were special in the sense that they couldn't be stored in a register (well, really I thought that only buffer text could be stored in a register). When interacting with Vim at the keyboard, you can also recall the previously used pattern from search history (using Up and Down after hitting / or ? ) and modify it on the command-line before hitting Enter (or Esc to abord) on the modified pattern. Cool! Or you can use :let to set @/ (the search register) and immediately do searches based on the new value. For instance, to repeat the latest search but as a self-standing word: :let @/ = '\' . @/ . '\' And I just forgot completely about the search register. My fault :( Moreover, if I'm writing a syntax file and have a lot of syntax items that contains the same complex pattern preceded and followed by a character (this is only an example), that's difficult to maintain because each time I have to change the complex pattern I have to change it everywhere. Please note that this cannot be fixed modifying the pattern adding an whatever\? atom at the front and end of it, because the whatever MUST be present at BOTH ends. Any ex-command (including the :syntax command) can be constructed as a string expression, argument of the :exe command. Again, I thought that syntax could be used in eval but not with exe. I definitely must study the VimL syntax in the structural level as shown in :help expression-syntax and think of any ex-command as an ex-command and not as syntax command, text manipulation commands, etc. Being vim an editor and not a programming language, I find sometimes difficult not to categorize its capabilities. I just tend to forget that VimL is a real programming language. Tony, again you've not only solved my doubt, but gave me an important lesson about VimL. I owe you yet another one. I just hope someday I will be able to return at least part of your kindness with me. 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: Maintaining patterns
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: [...] Tony, again you've not only solved my doubt, but gave me an important lesson about VimL. I owe you yet another one. I just hope someday I will be able to return at least part of your kindness with me. I used to be a teacher, and I don't believe that the best teacher is the one who gives the most students a failing note. To me, the greatest reward for a teacher lies in watching his students' successes. :-) I think exactly the same :) In fact, the thing I regret the most regarding vim is that I'm not proficient enough in VimL to help people in the list, and since vim is an editor and not a programming language, and so it has commands to deal with text etc. ,learning VimL won't be as easy as learning the other languages I already know. It took a month to really master Perl, studying and practicing intensively, which, in hours, was much more than the time I took to master C, for example. VimL will take much longer, I'm afraid, but I'll try my best to do it, in return for all the help I'm receiving from you and the other people in the list (Tim Chase comes to mind, but I won't give more names because I'm going to forget someone). Again, thanks a lot :) 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!
A doubt with syntax region
Hi all :))
I'm trying to fully understand the syntax commands, and when doing
tests a question popped up in my mind: let's say I have a region which
starts with something like \I\i*{ and ends with }. For example, the
example below will match:
strange{contents}
BUT, the below is valid for the filetype, too:
morestrange{content with words and {}, surprise!}
Of course, with something like this:
syntax region SomeRegion start=\I\i*{ skip={[^}]*} end=}
I'm able to highlight the example above, without having {} end the
region. The problem here comes when I want to highlight the part between
the braces in a different color. I've tried this, to (by the moment)
only highlight *braces* within those braces:
syntax region SomeRegion start=\I\i*{ skip={[^}]*} end=}
\ contains=Inner
syntax match Inner {[^}]*} contained
But this performs the following highlighting:
example{with some contents}
^^^
example{with another pair of braces {}}
^^^+++^
That is, the contained item is swallowing part of the start
match!. I thought that when the match for start was performed, the
matched test wasn't tried for any other match, including contained
items. Obviously, I was wrong (or I misunderstood the entire issue), and
I don't know if, just using regions, I can have a match like this:
example{{weird} and some mor{}e text}
^
that is, that the first opening brace is not swallowed by the
contained syntax item. As you can see, the contained item must be
allowed to start with {.
Thanks a lot in advance and sorry for the weird question O:)))
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 doubt with syntax region (addendum)
Hi all :)
* DervishD [EMAIL PROTECTED] dixit:
That is, the contained item is swallowing part of the start
match!. I thought that when the match for start was performed, the
matched test wasn't tried for any other match, including contained
items. Obviously, I was wrong (or I misunderstood the entire issue), and
I don't know if, just using regions, I can have a match like this:
example{{weird} and some mor{}e text}
^
that is, that the first opening brace is not swallowed by the
contained syntax item. As you can see, the contained item must be
allowed to start with {.
Of course, this can be achieved by something like this:
syntax region SomeRegion start=\I\i*{ end=} contains=Inner
syntax match Inner \(\I\i*{\)\@={[^}]*} contained
but it seems overkill to me: is there any simpler way of doing the
same without having to repeat the start pattern and ignore it using a
zero-width assertion?
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: hlsearch question
Hi Ralf :) * Ralf Schmitt [EMAIL PROTECTED] dixit: I'm a bit confused about the hlsearch feature of v7. In my .vimrc I set set nohlsearch to disable highlighting of search results on startup. This way, you've effectively turned off search highlighting, no matter of :nohl command. :help nohlsearch says Stop the highlighting for the 'hlsearch' option. It is automatically turned back on when using a search command, or setting the 'hlsearch' option. Unfortunately, both the setting and the command have almost the same name. The *command* :nohlsearch turns off search highlighting temporarily, so it doesn't clutter your display. It is turned on again if you do any new search. If you do set nohlsearch, you will never get search highlighting. 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!
About colors in t_Co=8 terminals: IncSearch hi group
Hi all :)) I've noticed something weird regarding IncSearch and I don't know if the problem is that I've set up my colors badly or that just I don't understand how the highlight command works. My terminal is 8 colors. If I set my IncSearch highlight group to something like this: highlight IncSearch cterm=NONE colorfg=0 colorbg=1 and then I do an incremental search for a word that is already highlighted with a bold color in foreground (e.g. for a word that is highlighted like a group with cterm=bolg, colorfg=6, colorbg=6, which is an example I've used and tested to reproduce this), then the background color of that work is changed to the background color of IncSearch, but the foreground color is changed to the foreground color bolded!. Looks like the bold attribute for the searched word is not replaced by the NONE attribute, so the incremental search shows weird colors when used over bolded words. I've tested the other way around (IncSearch being bold and the searched word being cterm=NONE) and that works perfectly, the bold attribute replaces correctly the NONE attribute. Am I doing something wrong, my terminal definitions are screwed or is this just a feature of IncSearch? Thanks a lot in advance :) 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: Question about indent/, syntax/ and ftplugin/
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: I don't want such cluttering, either. My idea is to have the following: - A 'vimrc' that just sources 'modules' (right now my vimrc does little except sourcing 'options.vim', 'mappings.vim' and a couple more things). - The framework for filetypes, ftplugins, syntax highlighting and indentation. - Filetypes. This is the most important part. My idea is having something like c_f.vim c_s.vim and c_i.vim for the c filetype, containing ftplugin things, syntax things and indentation things, instead of having ftplugin/c.vim, syntax/c.vim and indent/c.vim. I haven't decided if I will put the c_?.vim files under /etc/vim or in a subdir. For me is much more comfortable to manage all this if the three files are in the same directory and not in three separate subdirs. What about leaving the files where they are, and also do (in the shell) cd ~/.vim/after/ftplugin ln -sv ../../c_f.vim c.vim cd ../syntax ln -sv ../../c_s.vim c.vim cd ../indent ln -sv ../../c_i.vim c.vim Then you can edit the files in ~/.vim, and Vim will find them as if they were in their respective after-directories. Yes, that's an option, but I prefer to build a new scheme instead of using /after and symlinks. It's much easier for me if the entire structure is in my head instead of having to take into account the existing runtime *and* my changes in /after. ...and, why reinvent the wheel when the source is open? First, for fun. Second, because being the source open I can investigate, learn and do a good job. Third, for the same reason I've written my own window manager, my own sysvinit replacement, my own syslogd replacement, my own system for building software, etc. :just because I like it and I can. I have the urge of doing this kind of things ;)) If I were you, I would study the existing runtime files but not change them in-place. If you try to re-create everything from the ground up, you're bound to introduce bugs (Errare humanum est). Yes, I know, but I don't mind to take the risk. Moreover, by keeping the runtime simple, the chance for errors is minor. In addition to this, the default runtime has bugs or at least weird behaviours. For example, the keyword mapclear in vim scripts is not highlighted properly, and sourced files are highlighted, so if you do source perl.vim, the perl word is highlighted as a keyword. The problem is that I'm not sure if this is a bug or some strange interaction between my options settings and the runtime syntax file, that's very difficult to spot and difficult to investigate. OTOH, if by studying the existing scripts you _find_ bugs, then after making sure of your facts you could send a patch to the maintainer. That's a good reason to keep things as they are, but while I write my own runtime I will test thoroughly the default one and may spot some bug. I think I'll take the risk and of course I'll try my best not to bother the list with my self-induced problems in doing so O:)) Again, thanks :) 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: Question about indent/, syntax/ and ftplugin/
Hi Tony :))) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: I would like to have configuration data, syntax rules and indent functions for a filetype together in just one file because this way is much more easy to maintain for me (long story). Apart from the obvious disadvantage that having all together in a file makes impossible to deactivate only syntax, only plugin and only indent for that given filetype (it becomes an all or nothing thing), is there any problem in not having the files in three separate directories? In fact, is there any problem in having ALL that data in the corresponding ftplugin? The scripts in the indent/ syntax/ and ftplugin/ subdirectories of the directories in 'runtimepath' are not run at the same time, therefore it is logical to keep them separate: Yes, that I know, and I have no doubt it's better to have all three things separate, specially if you use the shipped runtime system. The default vim runtime has to be flexible, powerful and general purpose. What I want in my system is a small, fixed purpose runtime, with only those bits I actually use. The reason behind this is the same reason behind my entire system: I enjoy doing things on my own. The least I do is to build the software myself (I use no package system), but if I have the chance, I program the software myself. In fact, until I tried Vim 7.0, I was decided to write my own editor, and I have a preliminar design: most data structures are already written or fully designed. This said, what I'm doing now, just for fun, is to write my own runtime for vim. So far I've replaced 'filetype.vim', and I'm on the way of writing my own indent.vim. Syntax will be the last part, because it is the biggest, too. I have nothing against the default runtime, in fact is VERY good and powerful, but I can't help rewriting some parts just for fun. It may not be very intelligent, but having fun is important IMHO ;) The problem with this is that, in the past, I've faced some problems when doing the same (e.g. with Lout) because the things I rewrote were using undocumented dirty tricks, or assuming things hardcoded in the source code, etc. So I wanted to make sure that, after working a couple of weeks writing VimL code, I will be able to use the results and I won't get stuck. Your explanation below is very good, because although I knew most of the things from the documentation, you've made clear what kind of things should be put in every one of the three files. That kind of help is invaluable (as most of the help you give in this list, by the way). Now what should these files contain? [...] If you want to keep everything together, you can set autocommands for the Filetype and Syntax events in your vimrc, but as what you want to do becomes more involved, you'll find that your vimrc becomes more and more cluttered and that you need to put things into different files just to keep order. Been there done that. I don't want such cluttering, either. My idea is to have the following: - A 'vimrc' that just sources 'modules' (right now my vimrc does little except sourcing 'options.vim', 'mappings.vim' and a couple more things). - The framework for filetypes, ftplugins, syntax highlighting and indentation. - Filetypes. This is the most important part. My idea is having something like c_f.vim c_s.vim and c_i.vim for the c filetype, containing ftplugin things, syntax things and indentation things, instead of having ftplugin/c.vim, syntax/c.vim and indent/c.vim. I haven't decided if I will put the c_?.vim files under /etc/vim or in a subdir. For me is much more comfortable to manage all this if the three files are in the same directory and not in three separate subdirs. This last part is what was worrying me. I know that the default runtime needs those three dirs, but I don't know if getting rid of them and organizating things differently is going to buy me problems in the future. Your message has been inspiring, and I may consider things differently. Writing my own runtime is, for me, very fun, so I will be doing it, but how I do it may be different. Thanks a lot for your help, as always :) 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!
'syntax spell default' results in E390
Hi all :)) I've found a bug in Vim 7.0 (doesn't seem to be mentioned in any patch up and including 188. When I issue syntax spell default, it results in the following error: E390: Illegal argument: default. I've took a look at the help for E390 and it seems to be an error for syntax case, not syntax spell. So I looked at the sources and I found this at src/spell.c, line 3190 (as Vim 7.0 unpatched): ...STRNICMP(arg, default, 4) == 0 next - arg == 4... Yes, syntax spell defa is successfull. That 4 should be replaced by 7. 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!
Question about indent/, syntax/ and ftplugin/
Hi all :) I would like to have configuration data, syntax rules and indent functions for a filetype together in just one file because this way is much more easy to maintain for me (long story). Apart from the obvious disadvantage that having all together in a file makes impossible to deactivate only syntax, only plugin and only indent for that given filetype (it becomes an all or nothing thing), is there any problem in not having the files in three separate directories? In fact, is there any problem in having ALL that data in the corresponding ftplugin? I'm just curious... 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: Spam in Tips in Vim's website
Hi Guido :) * Guido Van Hoecke [EMAIL PROTECTED] dixit: I think I'll follow the advices from Salman Halim and Kim Schulz and I'll subscribe to vim tips using the RSS feed and will report the number I have no problems to add the vim scripts rss feed to my firefox live bookmarks by clicking the orange icon in the address bar. But the tips feed does not work with firefox. When I click the orange icon at the right hand of the url in the address field, the page is added (as http://www.vim.org/tips/rss2.php) but results in an error message stating that it failed to load the live bookmark. I managed to subscribe to the tips feed using liferea but would like to stick to firefox. I've had the same problem in the past with other feeds and firefox. Finally I got tired and, since I was lazy enough to avoid installing a feed reader, I used Google Reader. Maybe not the best reader out there, but does the job and I can use it from any computer with Internet access. 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: Spam in Tips in Vim's website
Hi Salman :) * Halim, Salman [EMAIL PROTECTED] dixit: Spam in comments can also be addressed by moderators as of fairly recently. When you come across such a comment, you can mark the comment as spam, leaving the rest of the tip and comments alone. While you are correct that you may not be able to catch them all, they're only a problem if someone stumbles across them -- in which case, they need only mention it and any moderator (yes, I speak for you, too!) will happily remove it. Cool!. Thanks for the information. 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: latin1 vs utf8
Hi Yongwei :)
* Yongwei Wu [EMAIL PROTECTED] dixit:
On 1/18/07, DervishD [EMAIL PROTECTED] wrote:
Did you set 'fileencodings' to an empty string? Otherwise this would
not work.
Apart from fixing the above (including the last version I posted
here, which has a catch, yes, I have fileencodings set to an empty
string. Why this wouldn't work if 'fencs' is not an empty string? Is
because 'fenc' will get a value *after* the autocommand is invoked?.
'Fileencodings' is the option to detect the file encoding, and
'fileencoding' is the option to set/reflect the encoding of the
current file.
In my _vimrc, I have settings like:
[...]
au BufReadPre *.gb call SetFileEncodings('cp936')
au BufReadPre *.big5 call SetFileEncodings('cp950')
au BufReadPre *.nfo call SetFileEncodings('cp437')
au BufReadPost *.gb,*.big5,*.nfo call RestoreFileEncodings()
You may use a similar way.
Yes, but that won't solve my problem, because I cannot filter by
name. Anyway, setting fileencodings instead of fileencoding looks like
an interesting approach. Which advantages does it have (vs. changing
fenc instead)?
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: latin1 vs utf8
Hi Yongwei :)
* Yongwei Wu [EMAIL PROTECTED] dixit:
* Yongwei Wu [EMAIL PROTECTED] dixit:
On 1/18/07, DervishD [EMAIL PROTECTED] wrote:
Did you set 'fileencodings' to an empty string? Otherwise this would
not work.
Apart from fixing the above (including the last version I posted
here, which has a catch, yes, I have fileencodings set to an empty
string. Why this wouldn't work if 'fencs' is not an empty string? Is
because 'fenc' will get a value *after* the autocommand is invoked?.
'Fileencodings' is the option to detect the file encoding, and
'fileencoding' is the option to set/reflect the encoding of the
current file.
In my _vimrc, I have settings like:
[...]
au BufReadPre *.gb call SetFileEncodings('cp936')
au BufReadPre *.big5 call SetFileEncodings('cp950')
au BufReadPre *.nfo call SetFileEncodings('cp437')
au BufReadPost *.gb,*.big5,*.nfo call RestoreFileEncodings()
You may use a similar way.
Yes, but that won't solve my problem, because I cannot filter by
name. Anyway, setting fileencodings instead of fileencoding looks like
an interesting approach. Which advantages does it have (vs. changing
fenc instead)?
If you ever set fencs, setting fenc before loading a file does not
work at all.
Just what I was afraid of :( Really your method is better, and I'm
going to ste^H^H^Huse it as inspiration ;)))
Thanks a lot for your advice :)
My personal setting of fileencoding is quite complicated. Though my
_vimrc cannot do what you described, it allows me to automatically
detect file encodings utf8, gbk, big5, and latin1. See my home page
below if you are interested.
I'm interested and I'll take a look at your home page right now.
Thanks a lot :))
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: latin1 vs utf8
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: utf-8 is a superset of latin1, thus using utf-8 for 'encoding' should nearly always work. Except that then I have to encode my 'showbreak' option as utf8 and not latin1 :( I prefer to have it encoded as latin1 (as the rest of my files), until I switch to utf8. Yeah, there are small things like this. You might want to put this in your .vimrc: scriptencoding latin1 It's already there but that doesn't fix the problem with 'showbreak'. If I change 'enc', I see 'á', correctly. You should do :edit ++enc=utf-8 filename or include utf-8 in 'fileencodings' before editing the file. Then it will work no matter what 'encoding' is set to. But then my US-ASCII files (and new files) will be considered utf-8, and I don't want that. Or do you mean that if I set (e.g.) 'fencs=ucs-bom,latin1,utf8' things will work even if utf8 is never tried because latin1 always succeeds? What I don't understand is that if I set 'fencs' and let 'fenc' take the value from it, the translation is done correctly because vim converts the characters. Once the file is loaded, this doesn't happen and setting 'enc' by hand seems the only choice. Am I doing anything wrong? Yes. 'fenc' is set by Vim when it reads the file. Setting it to another value doesn't cause the file to be reread or conversion to be done. OK, now I understand, thanks : Any way of forcing a conversion? Again, thanks a lot :) 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: latin1 vs utf8
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: If I change 'enc', I see 'á', correctly. You should do :edit ++enc=utf-8 filename or include utf-8 in 'fileencodings' before editing the file. Then it will work no matter what 'encoding' is set to. But then my US-ASCII files (and new files) will be considered utf-8, and I don't want that. Or do you mean that if I set (e.g.) 'fencs=ucs-bom,latin1,utf8' things will work even if utf8 is never tried because latin1 always succeeds? In :set fencs=ucs-bom,latin1,utf8, UTF-8 is indeed never tried because Latin1 always succeeds. And that means *never*. IOW, that setting is logically equivalent to just :set fencs=ucs-bom,latin1. There is _nothing_ that Vim will do in one case and not in the other. So, and if I understand everything correctly, if my locale is latin1, my terminal is latin1 (that is, enc=latin1 and tenc=latin1) and I want to edit/view utf8 files *and* I don't want new files or US-ASCII files to be considered utf8, my best bet is to use BufReadPre to detect utf8 files using file -i or something similar, thus forcing the conversion, am I wrong? I assume that when BufReadPos is invoked, any conversion has already been carried, am I wrong? Well, all of the above is easy to test, so if I can afford the time later, I'll do and post here my results. Thanks, Tony :) 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: latin1 vs utf8
Hi all, and sorry for self-replying... * DervishD [EMAIL PROTECTED] dixit: I want to edit/view utf8 files *and* I don't want new files or US-ASCII files to be considered utf8, my best bet is to use BufReadPre to detect utf8 files using file -i or something similar, thus forcing the conversion, am I wrong? I've done the following autocommand to perform the detection: autocmd BufReadPre * \ if system(file -i . expand(amatch)) =~ utf8 | \ setlocal fenc=utf8 | \ endif I'm sure that it could be much more simpler and powerful, but I'm a newbie programming in VimL, so... It works for me, at least, but any suggestion is welcome. 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: Reformatting text after setting tw
Hi Stavros :)
* Stavros Tsolakos [EMAIL PROTECTED] dixit:
I am editing a text file with vim7. I set tw=80 and it works for any
text I write AFTER setting it. But how could I force vim reformat my
whole text file so that all lines obey to the new textwidth?
There is probably a better way, but I would do:
gggqG
This means:
ggGo to beginning of file
gqFormat the following (well, really is format the text
specified by {motion})
G Go to end of file
If I recall correctly, gq doesn't work with ranges, only with
motions.
Perhaps it is a dumb question, but I still haven't found a way to do it.
Take a look at :help gq and :help navigation.
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: latin1 vs utf8
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: Notice the dash between utf and 8. My bad, I typed carelessly. It succeeded on my system because I did my first test with a file *named* 'utf8'. I've noticed the problem a moment ago, and it's already fixed. Hoho... Then maybe you should use file -bi rather than file -i in order to avoid detecting UTF-8 for: /home/raul/utf-8_to_latin.txt: text/plain; charset=ISO-8859-1 I've done that and more: if system(file -bi . expand(amatch)) =~# ; charset=utf-8$ I was too lazy to ellaborate the regex correctly. It is still unellaborated, but works better. 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: latin1 vs utf8
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: * A.J.Mechelynck [EMAIL PROTECTED] dixit: Notice the dash between utf and 8. My bad, I typed carelessly. It succeeded on my system because I did my first test with a file *named* 'utf8'. I've noticed the problem a moment ago, and it's already fixed. Hoho... Then maybe you should use file -bi rather than file -i in order to avoid detecting UTF-8 for: /home/raul/utf-8_to_latin.txt: text/plain; charset=ISO-8859-1 I've done that and more: if system(file -bi . expand(amatch)) =~# ; charset=utf-8$ I was too lazy to ellaborate the regex correctly. It is still unellaborated, but works better. regexp matches with matching case, ; charset=utf-8 at end of string. Redundant with -b but ought to work, unless a text file can have something after the charset, which I haven't seen yet in the experiments I've done. Well, in fact using the output from file -i is not a good idea, but finding the charset of a file is not easy anyway, so the redundance doesn't worry me. In fact I prefer that redundance, just in case I change file -bi for anything else in the future (thing that I plan to do, by the way). The problem is that the conversion in vim is done before charset can be set by hand :(, otherwise, a simple :setlocal fenc=utf8 will do. A human is the perfect tool to discriminate between charsets :D One thing I just noticed: shell scripts (which are text) get application/x-shellscript and no charset, at least on my system; IMHO that's a bug in the file program. I don't know if it is a bug or not, but IMHO it is because the output has a different structure from one mimetype to other. It should always output the charset or never, but not only for text. I don't know if any standard mandates that charset is only meaningful for text/plain, but... If tomorrow morning I have some spare time I'll try to get a better solution, preferably using VimL only. Thanks for your help :) 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!
Spam in Tips in Vim's website
Hi all :) I've noticed that there are still spam in the Tips comments at the vim website. Bram, do you need help with that? If you want, I can take a look at the comments and delete any spam I catch. I don't know how much spare time I'll have, but even with ~1500 tips, it shouldn't take more than a week or so. I've read your post in the Vim page saying that with the help of moderators, the spam had been eliminated, so probably the spam I've seen today is new. That's bad :((( 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: latin1 vs utf8
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: DervishD wrote: I've done the following autocommand to perform the detection: autocmd BufReadPre * \ if system(file -i . expand(amatch)) =~ utf8 | \ setlocal fenc=utf8 | \ endif I'm sure that it could be much more simpler and powerful, but I'm a newbie programming in VimL, so... It works for me, at least, but any suggestion is welcome. Did you set 'fileencodings' to an empty string? Otherwise this would not work. Apart from fixing the above (including the last version I posted here, which has a catch, yes, I have fileencodings set to an empty string. Why this wouldn't work if 'fencs' is not an empty string? Is because 'fenc' will get a value *after* the autocommand is invoked?. 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: Spam in Tips in Vim's website
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: DervishD wrote: I've noticed that there are still spam in the Tips comments at the vim website. Bram, do you need help with that? If you want, I can take a look at the comments and delete any spam I catch. I don't know how much spare time I'll have, but even with ~1500 tips, it shouldn't take more than a week or so. I've read your post in the Vim page saying that with the help of moderators, the spam had been eliminated, so probably the spam I've seen today is new. That's bad :((( Well, the most obvious spam has been deleted, but it takes time to check all the tips. We have a group of moderators working on it. If you want to be a moderator let me know your www.vim.org login. I think I'll follow the advices from Salman Halim and Kim Schulz and I'll subscribe to vim tips using the RSS feed and will report the number of the affected tips. If things get worse and the feed works for me (by now I'm using Google Reader), I'll happily join vim.org as moderator to delete the spam. Thanks a lot :) 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: Spam in Tips in Vim's website
Hi Salman :) * Halim, Salman [EMAIL PROTECTED] dixit: While I'm not in a position to determine who gets to moderate tips, I would like to request that if anybody sees spam while looking through a tip and decides to mention it, please include the tip number(s) so a moderator can go in and address the issue. I'll follow your advice and will subscribe to the RSS feed. This way I'll get a list with any new spam that appears in the tips section. Thanks :) 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: Spam in Tips in Vim's website
Hi Kim :) * Kim Schulz [EMAIL PROTECTED] dixit: On Wed, 17 Jan 2007 20:46:30 +0100 DervishD [EMAIL PROTECTED] wrote: I've noticed that there are still spam in the Tips comments at the vim website. Bram, do you need help with that? If you want, I can take a look at the comments and delete any spam I catch. I don't know how much spare time I'll have, but even with ~1500 tips, it shouldn't take more than a week or so. having RSS feeds of the tips being added makes it easy to catch the spam just after it has been added without having to go to the homepage all the time. I've subscribed and I've already picked some of the spam. Unfortunately, this only solves tips that *are* spam, not spam in comments (at least I can't catch that from reader without looking at every tip). 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!
Tips which are spam
Hi all :)) So far I've picked: 1473,1471,1461,1460,1459,1457,1452. At least some of them have been already deleted. About the spam in tips' comments, that's another issue. 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: latin1 vs utf8
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: DervishD wrote: After that, I've set up this mappings to switch manually from one encoding to other: noremap silent Leader+ :setlocal fenc=utf8 enc=utf8CR noremap silent Leader- :setlocal fenc=latin1 enc=latin1CR OK, this is not a perfect solution, and it's a bit crappy and can be automated (for example, using file -i) but it works for me and I find it very comfortable to use. Keep in mind that when you change 'encoding' in a running Vim then all text in loaded buffers, registers, variables, etc. will become invalid. It's better to only set 'encoding' when starting up and then leave it alone. Yes, I supposed that something like that would happen, but if I don't set 'encoding' I'm not able to see the characters correctly. I mean, they will be correctly written to the file in utf8 but I won't be able to see them on the screen. I know that this is risky, but the alternative will consider all my US-ASCII files (and any newly created one) as utf8 and I don't want that right now. For me is easier to do the above and take the risk because I seldom edit utf8 files. If I run into trouble, I'll probably use some BufReadPost autocommand to properly set both 'encoding' and 'fileencoding'. Thanks for the information, Bram, and thanks a lot for Vim :) 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: latin1 vs utf8
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: DervishD wrote: Keep in mind that when you change 'encoding' in a running Vim then all text in loaded buffers, registers, variables, etc. will become invalid. It's better to only set 'encoding' when starting up and then leave it alone. Yes, I supposed that something like that would happen, but if I don't set 'encoding' I'm not able to see the characters correctly. I mean, they will be correctly written to the file in utf8 but I won't be able to see them on the screen. I know that this is risky, but the alternative will consider all my US-ASCII files (and any newly created one) as utf8 and I don't want that right now. For me is easier to do the above and take the risk because I seldom edit utf8 files. If I run into trouble, I'll probably use some BufReadPost autocommand to properly set both 'encoding' and 'fileencoding'. Did you try setting 'termencoding'? My terminal is latin1 and only understands latin1, unfortunately, so changing termencoding to any different of latin1 just causes more harm. BTW, I use vim always on the virtual console, text mode. utf-8 is a superset of latin1, thus using utf-8 for 'encoding' should nearly always work. Except that then I have to encode my 'showbreak' option as utf8 and not latin1 :( I prefer to have it encoded as latin1 (as the rest of my files), until I switch to utf8. So far, the only combination that does what I want is setting 'tenc' to latin1 (which is the correct one for my virtual terminal under Linux), and setting 'enc' by hand, leaving 'fenc' empty so it is in sync with 'encoding'. Of course, this is dangerous because changing 'encoding' is never a good idea, and I shouldn't been changing it, buf if I only change 'fenc', I still see 'á' instead of 'á'. If I change 'enc', I see 'á', correctly. What I don't understand is that if I set 'fencs' and let 'fenc' take the value from it, the translation is done correctly because vim converts the characters. Once the file is loaded, this doesn't happen and setting 'enc' by hand seems the only choice. Am I doing anything wrong? Thanks again for your help :) 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: latin1 vs utf8
Hi Klaus :) * Klaus Ethgen [EMAIL PROTECTED] dixit: I think that question was asked many time before but with differed direction but maybe there is someone having a answer. (I found some for the other direction not for mine.) I asked more or less the same a few days ago, you can see the thread in the mailing list archive. Is there any way to only use utf8 if there are utf8 characters in the file (or explicite set)? Like the unix command file -i can choose? You can use 'file -i' in a BufReadPost autocommand and set the appropriate variables from it, but that won't work for empty files, so if you edit a new file and put latin1 characters on it, they will be encoded as utf8 if you set fileencodings=ucs-bom,utf8,latin1. So, I've chosen a different approach. Since 99% of the files I work with are latin1, I've set my vimrc like this: set encoding=default set fileencoding= set fileencodings= You can set the last one to ucs-bom,latin1 if you want, that makes no difference for me because I don't use files with 'bom'. After that, I've set up this mappings to switch manually from one encoding to other: noremap silent Leader+ :setlocal fenc=utf8 enc=utf8CR noremap silent Leader- :setlocal fenc=latin1 enc=latin1CR OK, this is not a perfect solution, and it's a bit crappy and can be automated (for example, using file -i) but it works for me and I find it very comfortable to use. 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: Reformat in visual area - vmap question
Hi Jean Rene :) * Jean-Rene David [EMAIL PROTECTED] dixit: * DervishD [2007.01.12 07:45]: * A.J.Mechelynck [EMAIL PROTECTED] dixit: [...] Beware of ' and ` though: they are used in Normal mode for mark movements. Yes, but both keys do the same, so I'm on the safe side if I choose only one of them, am I wrong? They are similar but not quite the same. :h mark-motions Yes, I knew it: one of them is exclusive and the other one just puts you in the first non-blank character, but since I always think about go to the exact place where I did set the mark, I considered them equal. My bad, sorry O:) 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: Reformat in visual area - vmap question
Hi Tim :) * Tim Chase [EMAIL PROTECTED] dixit: Yes, ñ or ç would be good. Beware of ' and ` though: they are used in Normal mode for mark movements. Yes, but both keys do the same, so I'm on the safe side if I choose only one of them, am I wrong? They do similar, but not identical actions. The regular tick/apostrophe jumps to the beginning of the marked line, and the back-tick jumps to the character position where the mark was dropped. I exclusively use backtick when going to a mark, so using the single-quote may be a good choice for me, because it is very handy in my spanish keyboard. Thanks :) 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: Encoding problem
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: :scriptencoding applies no farther than the end of the current script. And does it affect sourced scripts or should I put that line in all scripts? It doesn't affect sourced scripts. Each script should include or not include a :scriptencoding statement according to what bytes are found in that script itself. OK, I thought it was more like a flag, meaning from now on, everything you source is latin1. Of course, it wouldn't make much sense that way, I should have noticed O:) OK, let's try the opposite: edit options.vim, remove the sriptencoding statement, then save it with :setlocal bomb fenc=utf-8 :x Then restart Vim and see if it works. No, it doesn't work, but the strange thing is that vim barfs *only* with 'showbreak'. I have latin1 (well, utf-8 now) characters in the script, namely in 'foldtext' and 'listchars' at least, and they are processed correctly. Maybe the codes I'm using are considered printable in latin1 and nonprintable in utf8? What characters are seen as printable in Vim depends on the 'isprint' option. Oh, I didn't remember that, I assumed that Vim was using the isprint() functions in ctype for that. That option's default is OS-dependent, but apparently not locale-dependent. ASCII characters from 0x20 (space) to 0x7E (tilde), including all digits and letters, are always printable, even if the option doesn't mention them. Anyway, I have that option set to @,161-255, so probably if I set my encoding to utf8, the multibyte characters (division and left guillemot) should be printable, but in this case looks like Vim doesn't like them (it likes them on 'listchars', so the problem is not the encoding, definitely). Oops, I think I know what's happening. I don't have an utf8 locale, and I don't mean active, I mean *installed*, so if vim is trying to use an utf-8 locale to see if a character is printable or not, it won't work unless vim itself knows if some character is printable or not under utf8. That's why the error is E595 and only shows with 'showbreak'. Vim is considering the division sign and the left guillemot non printable under utf8 encoding (which, BTW, is not right). Probably if I install an utf8 locale, things will work OK. By now I'll leave 'encoding' as default, 'fenc' and 'fencs' empty and will set utf-8 by hand when needed (which is not very frequently for me). There used to be a limitation on 'listchars', and possibly it still applies to 'showbreak': the characters in that option had to be valid in the current 'encoding'. If you change the 'encoding', the option may become invalid in the new 'encoding'. If you use 7-bit characters in 'showbreak' it should be OK in all 'encoding's. Yes, but if I set the encoding to utf8 and save the file *as* utf8, then Vim should handle it, am I wrong?. Those characters will be valid utf8 and will be printable :? Problem solved! Thanks a lot for everything, Tony :) De nada, hombre. Do you know that with that kind of expressions you would pass as a spanish native? Your spanish is much better than you think ;))) I'll try to learn a bit of esperanto to correspond to your kindness :) 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: Encoding problem
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: * A.J.Mechelynck [EMAIL PROTECTED] dixit: [...] As long as your vimrc includes only 7-bit ASCII, there's no problem. But in the particular case of your vimrc, you could add the following lines at top, do :setlocal fenc=latin1, and (IIUC) it will always be _read_ as Latin1 in the future, because of the accented letters in your name: Won't scriptencoding work? I have latin1 characters in my vimrc and setting encoding=utf8 now causes vim to spill an error when reading it :((( I'm afraid I will have to keep it at the default value. Maybe I didn't express myself clearly enough. Unless your vimrc includes codepoints higher than U+00FF, it can be represented in Latin1. Any Latin1 file which includes the words Raúl Núñez will cause the UTF-8 heuristic to fail in 'fileencodings', and Vim will see it as Latin1. Which doesn't work if 'encoding' is utf8, I've tested :(( Vim barfs in some latin1 characters I use in 'showbreak' (I don't know the Unicode code point of the characters, but in latin1 they're 0xf7 and 0xbb). :scriptencoding is used to tell Vim's sourcing engine in which 'fileencoding' the script was written. There are two cases where it is not necessary: - the same as 'encoding', or - UTF-8 with BOM. IOW, yes, if you set 'encoding' to UTF-8 you may have to also issue :scriptencoding latin1. I have this line as the first line of my options.vim, but it doesn't seem to work. Probably because I do the following: my /etc/vimrc sources /etc/vim/options.vim, which is the problematic script and the only one that has scriptencoding on it. Probably when vim is parsing the file, it already has decided that the rc files are utf-8, since /etc/vimrc has no latin1 characters on it. I'll make a test... OK, it still fails. I've put scriptencoding at the top of my vimrc file, and vim barfs in the same latin1 characters. Again, thanks a lot for your help, you're great : 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: keys available for mapping/leader (was Reformat in visual area - vmap question)
Hi Tim :) * Tim Chase [EMAIL PROTECTED] dixit: \ is hard to type in my keyboard (spanish) because I'm forced to press Alt-Gr plus the top left key in the keyboard (just below ESC), so I'm looking for a good substitute for the leader: do you know where could I find free characters to use? Looks like every key is already a vim command and I must confess (full of embarrasment here...) that I don't know even 10% of them O:))) Getting the list from the help is a bit tedious and error prone, so... [...] If you don't use more than 10% of the keys, you can look at it from both sides...you've got plenty of keys you can remap...but if you remap them, it will be harder to learn the other 90%. :) That's a great idea: instead of trying to discover an unused key, it's better to use a command key whose command I don't want/need. This way, I will be sure about the command that I will be overriding. Thanks :)) 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: Reformat in visual area - vmap question
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: * Matthew Winn [EMAIL PROTECTED] dixit: The Leader defaults to \ on some installations, I believe. \ is the default value, and that's the value used if mapleader is empty. It's a bad idea to set mapleader to , unless you have a keyboard where \ is hard to type, as , is already a Vim command. \ is hard to type in my keyboard (spanish) because I'm forced to press Alt-Gr plus the top left key in the keyboard (just below ESC), so I'm looking for a good substitute for the leader: do you know where could I find free characters to use? Looks like every key is already a vim command and I must confess (full of embarrasment here...) that I don't know even 10% of them O:))) Getting the list from the help is a bit tedious and error prone, so... You can at least remap it to something which can be produced by hitting only one key, for instance: :map F12 Bslash :map! F12 Bslash That's great! I always forget that one of the best features of key mapping in vim is that you can translate keys! will make the F12 key an alias for \ in all modes. Or instead of F12, you can use some key for some character with the high bit set, if you have some: I have the 'ñ' at the tip of my right little finger ;) That's a perfect candidate for a leader or as a substitute for backslash :) I have 'ç' too (its a bit farther on the right, but still reachable with the little finger without having to actually look at the keyboard). In addition to this, both ' and ` are good candidates because they do the same. Thanks A LOT for your invaluable help. 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: Encoding problem
Hi Scot :) * Scot Becker [EMAIL PROTECTED] dixit: Try removing both the set encoding and set fileencoding lines. And see if it does what you want. It should do latin1 still by default (based on your system settings), and still let you see utf files. If that fails, leave the 'set encoding', but leave out the 'set fileencoding'. I think that you only need a fileencoding line when you want to force conversion. Otherwise 'set encoding' does the trick. I had this problem too, when I WANTED to set everything to utf-8. The problem is still the same, because ucs-bom and utf8 are tried before latin1 for ascii-7 files. I want latin1 by default for ascii-7 files. Thanks anyway! :))) 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: Encoding problem
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: My system is latin-1, so I want my files written using latin-1 encoding. But sometimes I get files in utf8 encoding, so I set up my vim like this: set encoding =latin1 set fileencoding =latin1 set fileencodings =ucs-bom,utf-8,latin1 This last line is causing big problems to me. Everytime I edit one of MY files, not the utf8 imported files, vim converts it to utf-8, because while ucs-bom may fail as an encoding, utf-8 not. My problem will be gone if I set fileencodings to just latin1, but then I won't get utf-8 files automagically converted and presented to me in a readable form. Is there any way to get what I want, that is, to have ALL my files edited as latin1 but convert utf-8 files properly without using the ++enc thing? Your problem lies in the relation between UTF-8, Latin1 and US-ASCII. Characters 0x00 to 0x7F are represented identically in all three, therefore if a file contains only 7-bit ASCII characters, it won't make any difference whether it is interpreted as US-ASCII, Latin1 or UTF-8 -- the data will be the same, *represented the same way*, in all three cases. I know that, ucs-bom and utf-8 are tried before latin1 and utf-8 always succeeds for US-ASCII files :((( You can do it in advance by intentionally placing some upper-ASCII in the file, for instance by underlining the top title with ÷ (a line of divide-by signs, 0xF7), then saving the file as Latin1. Yes, I thought about that solution, but it's messy and not always applicable (I cannot place upper latin1 characters in some files at the beginning, or remember to save it as latin1). Note that in order to edit Unicode files properly, it is more prudent to set 'encoding' to UTF-8, otherwise if you happen to edit a file containing anything which your current 'encoding' cannot represent, it will get garbled, and Vim won't be able to restore the original value when saving the file. You can do it as follows (in your vimrc): if encoding !~? ^u if termencoding == let termencoding = encoding endif set encoding=utf-8 fileencodings=ucs-bom,utf-8,latin1 setglobal bomb fileencoding=latin1 endif So, there is no way of solving my problem unless I put latin1 before utf8 in fileencodings, but then nothing will work because latin1 will always succeed :((( A partial solution for me would be to force latin1 when saving a file, but then I take the risk of messing the encoding of a couple of projects where I may add code which are utf-8 :(( Probably my best bet is to map save as latin1 and do this manually. BTW, and regarding your suggestion above, I just forgot to do it back when I wrote my vimrc while reading the documentation. I missed the prominent note, sorry O: Thanks for your help :) 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: Reformat in visual area - vmap question
Hi Matthew :) * Matthew Winn [EMAIL PROTECTED] dixit: The Leader defaults to \ on some installations, I believe. \ is the default value, and that's the value used if mapleader is empty. It's a bad idea to set mapleader to , unless you have a keyboard where \ is hard to type, as , is already a Vim command. \ is hard to type in my keyboard (spanish) because I'm forced to press Alt-Gr plus the top left key in the keyboard (just below ESC), so I'm looking for a good substitute for the leader: do you know where could I find free characters to use? Looks like every key is already a vim command and I must confess (full of embarrasment here...) that I don't know even 10% of them O:))) Getting the list from the help is a bit tedious and error prone, so... Thanks a lot in advance! 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: Encoding problem
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: Your problem lies in the relation between UTF-8, Latin1 and US-ASCII. Characters 0x00 to 0x7F are represented identically in all three, therefore if a file contains only 7-bit ASCII characters, it won't make any difference whether it is interpreted as US-ASCII, Latin1 or UTF-8 -- the data will be the same, *represented the same way*, in all three cases. I know that, ucs-bom and utf-8 are tried before latin1 and utf-8 always succeeds for US-ASCII files :((( No need to frown: US-ASCII is UTF-8 (but the reciprocal is not always true): or if you prefer, a UTF-8 file containing only codepoints below U+0080 can be read correctly, with no errors or misreadings, by any program accepting US-ASCII. Sorry, I'm afraid I didn't use the proper smiley O:) I wasn't frowning, what I wanted to express was more in the lines of how unfortunate am I, or something like that. Sorry for the mistake... A partial solution for me would be to force latin1 when saving a file, but then I take the risk of messing the encoding of a couple of projects where I may add code which are utf-8 :(( Probably my best bet is to map save as latin1 and do this manually. Rather than map :w ++enc=latin1 I would map :setlocal fenc=latin1, because with the latter (but not with the former) all saves of the file will be in latin1 until you :quit the file Nice idea :)) Thanks a lot :)) BTW, and regarding your suggestion above, I just forgot to do it back when I wrote my vimrc while reading the documentation. I missed the prominent note, sorry O: As long as your vimrc includes only 7-bit ASCII, there's no problem. But in the particular case of your vimrc, you could add the following lines at top, do :setlocal fenc=latin1, and (IIUC) it will always be _read_ as Latin1 in the future, because of the accented letters in your name: Won't scriptencoding work? I have latin1 characters in my vimrc and setting encoding=utf8 now causes vim to spill an error when reading it :((( I'm afraid I will have to keep it at the default value. Thanks for all the help :) 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!
Encoding problem
Hi all :) My system is latin-1, so I want my files written using latin-1 encoding. But sometimes I get files in utf8 encoding, so I set up my vim like this: set encoding =latin1 set fileencoding =latin1 set fileencodings =ucs-bom,utf-8,latin1 This last line is causing big problems to me. Everytime I edit one of MY files, not the utf8 imported files, vim converts it to utf-8, because while ucs-bom may fail as an encoding, utf-8 not. My problem will be gone if I set fileencodings to just latin1, but then I won't get utf-8 files automagically converted and presented to me in a readable form. Is there any way to get what I want, that is, to have ALL my files edited as latin1 but convert utf-8 files properly without using the ++enc thing? Thanks a lot in advance :)) 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: Any way of getting statusline=%B in insert mode?
Hi Redoute :)
* Redoute [EMAIL PROTECTED] dixit:
DervishD wrote:
Any way of working around this problem?
%{char2nr(getline('.')[col('.')-1])}
works for me.
Thanks! I've modified it a bit, because I wanted the number as hexa
and always with the same width, using printf:
set statusline=%y%m%r\ %t%=[%L]\ %05l,%03c\
%{printf('x%02x',char2nr(getline('.')[col('.')-1]))}
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: Any way of getting statusline=%B in insert mode?
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: Hi Tony :) :-) Olá Raúl It's Hola, but thanks for the nice gesture :) So really it is a bug and not a feature. Again, thanks :) IMHO, I said. Bram has the final say, not me. Of course, but given that even in the GUI version the problem happens (I thought that the bar was in between characters, and not at the 25% leftmost position), I'm inclined to think it is a bug and not a feature. Specially because it is a bit annoying, when moving around in insert mode, not being able to know the byte value of a character when I need to. Of course, I can switch to normal mode or map something to g8 in insert mode, but... Thanks for all and à bientôt :)) 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: Insert mode navigation with the arrow keys
Hi Viktor :) * Viktor Kojouharov [EMAIL PROTECTED] dixit: With the upgrade to vim 7, I am no longer able to navigate in insert mode with the arrow keys. This happens in any terminal. In gvim, they work fine. Instead of moving the cursor, the arrow keys do something like pressing O in normal mode, and then inserting A, B, C or D depending on the key pressed. They broke when I migrated to vim 7, and no other changes were made. The TERM variable hasn't changed, and neither did the ncurses library. Could it be related with key timeouts? What you report looks like the ESC + '[' at the beginning of the escape sequence for the arrow keys is interpreted separated from the 'A', 'B', 'C' and 'D' (which is the last part of the escape sequence for arrow keys at least under Linux). If so, tweak the timeout options. I have: set timeout set timoutlen=1000 set nottimeout set ttimeoutlen=100 Just in case... This works for me. 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: Any way of getting statusline=%B in insert mode?
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: Of course, but given that even in the GUI version the problem happens (I thought that the bar was in between characters, and not at the 25% leftmost position), I'm inclined to think it is a bug and not a feature. Specially because it is a bit annoying, when moving around in insert mode, not being able to know the byte value of a character when I need to. Of course, I can switch to normal mode or map something to g8 in insert mode, but... ga (or in Insert mode Ctrl-O ga) is what you want: g8 is used in UTF-8 to show the actual bytes which represent the character: e.g. on the letter é (small e with acute accent), ga shows é 233, Hex 00e9, Octal 351 while g8 shows c3 a9. I just didn't remember about ga, and I was using g8 most of the time O: Thanks a lot for the tip :)) Thanks for all and à bientôt :)) De nada, y hasta luego, amigo. Do you speak spanish? I studied french a long time ago, and I'm afraid I'm no longer able to maintain a conversation in french, although I still understand it a bit. Your spanish is for sure much better than my french O:))) Again, thanks for the nice gesture, you're very kind :) 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: Insert mode navigation with the arrow keys
Hi Viktor :) * Viktor Kojouharov [EMAIL PROTECTED] dixit: On 1/3/07, DervishD [EMAIL PROTECTED] wrote: * Viktor Kojouharov [EMAIL PROTECTED] dixit: With the upgrade to vim 7, I am no longer able to navigate in insert mode with the arrow keys. This happens in any terminal. In gvim, they work fine. Instead of moving the cursor, the arrow keys do something like pressing O in normal mode, and then inserting A, B, C or D depending on the key pressed. They broke when I migrated to vim 7, and no other changes were made. The TERM variable hasn't changed, and neither did the ncurses library. Could it be related with key timeouts? What you report looks like the ESC + '[' at the beginning of the escape sequence for the arrow keys is interpreted separated from the 'A', 'B', 'C' and 'D' (which is the last part of the escape sequence for arrow keys at least under Linux). I just tried you suggestion, but unfortunately, it didn't work. It still exhibits the same behavior. Then the problem is probably the mapping. Are you able to check what the arrow keys spill when pressed? Under linux, a way of checking that is, in showkey -a. In my system, for example, it says that my up arrow spills ^[[A, or 0x1b 0x5b 0x41. Check your arrows, although it's weird that it worked back in your old vim and not in 7.0 :??? 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!
Any way of getting statusline=%B in insert mode?
Hi all, and happy new year! I have %B in my status line, but it doesn't work in insert mode, only on normal and visual mode. At first I thought that the status line wasn't being evaluated while in insert mode, but the line and column numbers change correctly, so it *is* being evaluated, it's just that %B doesn't seems to work. Any way of working around this problem? Is this a feature? Thanks a lot in advance :) 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: Any way of getting statusline=%B in insert mode?
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: I have %B in my status line, but it doesn't work in insert mode, only on normal and visual mode. At first I thought that the status line wasn't being evaluated while in insert mode, but the line and column numbers change correctly, so it *is* being evaluated, it's just that %B doesn't seems to work. I confirm that in Insert/Replace mode %B gives a single digit zero. In Select mode it works OK, even in Select (insert) i.e. when triggered by hitting shift-arrow in Insert mode. OK, thanks for the confirmation. Even in Insert mode, the display is OK in non-current windows (e.g. clicking a status line or using Ctrl-O Ctrl-W w to change windows, gives a correct display on the status line of the window which we just left). So really it is a bug and not a feature. Again, thanks :) 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: c-wc-s on *nix vim
Hi Manu :) * Manu Hack [EMAIL PROTECTED] dixit: It works in Vim7 on WinXP but not on *nix (I tried solaris and linux). On *nix, it just stopped until I press c-q. Why was it happened? Usually, under UNIX, the c-s combination stops the TTY and c-q resumes it. For example, under Linux c-s has the same effect of pressing Scroll-Lock, and c-q does the opposite. If you want to use c-wc-s (split current window in two), use c-ws instead, it has the same effect. See :help :sp and you will see the note saying more or less what I'm explaining above. 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: Disabling *system-wide* plugins
Hi Bill :)) * Bill McCarthy [EMAIL PROTECTED] dixit: On Thu 30-Nov-06 2:26pm -0600, DervishD wrote: I want to be able to NOT load the plugins in my system-wide runtime directory, and instead loading my own set of plugins, and only those. So far, I know that set noloadplugins will do the job, partially. This won't load the default plugins in the $VIMRUNTIME/plugins directory, ok, but then my own plugins won't be loaded from ~/.vim/plugins. Apart from sourcing them manually from my .vimrc (which is not difficult), is there any other way of avoiding the loading of the plugins in the runtime directory but load the ~/.vim/plugins ones? Of course, a good way would be not installing the default plugins in the first place, but I want them available for the rest of users in my system (a fellow programmer, specially). The simplest is to modify your vimrc. Add something like this: se nolpl This seemed obvious to me, but... let x = rtp se rtp-=$VIMRUNTIME ru! plugin/**/*.vim let rtp = x ...not this! This is a simple and elegant solution to my problem, THANKS A LOT! Gosh, I'm really amazed with the people in this list :) 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!
Knowing the name vim was invoked under
Hi all :) I would like to share the same .vimrc for vim and view, so I can use view as a pager without having to use -u in the command line. So far, I've thought that the only way of knowing if I'm under vim or view mode is to check the value of readonly. Not perfect, but it will do. The problem is that I would like to use vim with other personalities (different sets of options) depending on its invocation name. Can this be done? I haven't found in the documentation any function to retrieve the full command line, just the file argument list. Any suggestion about how to discriminate in the .vimrc file depending on the invocation name for vim? Thanks a lot in advance :) 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!
Disabling *system-wide* plugins
Sorry for resending, I have had problems with email and I'm not sure if this message made its way into the list. If it is repeated, please ignore O: Hi all :) I want to be able to NOT load the plugins in my system-wide runtime directory, and instead loading my own set of plugins, and only those. So far, I know that set noloadplugins will do the job, partially. This won't load the default plugins in the $VIMRUNTIME/plugins directory, ok, but then my own plugins won't be loaded from ~/.vim/plugins. Apart from sourcing them manually from my .vimrc (which is not difficult), is there any other way of avoiding the loading of the plugins in the runtime directory but load the ~/.vim/plugins ones? Of course, a good way would be not installing the default plugins in the first place, but I want them available for the rest of users in my system (a fellow programmer, specially). Any help or suggestion is welcome, and thanks a lot in advance. If the answer is in the user manual (which I haven't read entirely, I'm in usr_40.txt right now), feel free to ignore me, I'll hit it sooner or later. 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: Key timeouts
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: [...] I'm pretty sure that my keyboard driver will feed keys faster than 1 per 100 milliseconds (that's my ttimeoutlen setting right now), and although I'm a fast typer, probably 100 will be too fast for me. [...] Then ttimeoutlen=100 is right for you: it should be slower than your keyboard driver's speed (when entering several bytes for one keypress) but faster than your own typing speed. OTOH, 'timeoutlen' should be longer I currently have timeoutlen=1000 and ttimeoutlen=100, which are the values I feel comfortable with. BTW, I think that my last message won't make into the list because of a problem in my mail setup and the mailing list setup. It should be fixed by now. Thanks :) 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!
Using TAB to jump thru help tags
Hi all :) First of all, please excuse if what I'm going to ask sounds stupid, but I have been using vim for less than a week, so I'm afraid I'm not very proficient with it ;) Well, I've done this mapping to be able to jump to the next tag in the help file using TAB: :nnoremap silent buffer TAB /\|\S\+\|CR:nohlCRl The problem is that when I hit TAB, the tags flash a bit, because the search command highlight them and the :nohl turns hl off. Moreover, this interferes with my searchs, if any. What I want is to be able to do the above without interfering with searches. I've been looking for a way of jumping into a pattern without using search() or /, but I haven't found any. I've tried :tag and friends, too, with no success :( I want to do this because I'm spending a lot of time in the help right now, so I want a fast way of jumping thru help tags. Do anybody has any suggestion? Thanks a lot in advance :) 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: Dangerous keybindings
Hi Benji :) * Benji Fisher [EMAIL PROTECTED] dixit: On Wed, Nov 22, 2006 at 02:04:29PM +0100, A.J.Mechelynck wrote: DervishD wrote: [snip] I want to do something like that in my vimrc. delete_all_keys if at all possible map i i yes, I want to go to insert mode ... ... map C-kx wWeird, but just an example So, if I don't have map'ed C-w+ and I hit it, the window size won't change, but I still will be able to do this: map C-+ C-w+ - There is no simple command to unbind all keys. You can have one particular key have no effect by mapping it to Nop -- but beware of the risk of breaking the :normal command in scripts. I agree that this is not necessarily a good idea, but there are a few ways to map keys to Nop in bulk. let letter = a while letter = z execute map letter Nop let letter = nr2char(char2nr(letter) + 1) endwhile Vim 7.0 only for char in split(@!#$%, '.\zs') execute map char Nop endfor Vim 7.0 only for word in ['C-W', 'C-X', 'C-A'] execute map word Nop endfor Thanks a lot :) This is what we was looking for, except, as you say, this is not a good idea unless I don't use any script (or plugin, etc.) which uses :normal :( A better solution might be to stay out of Normal mode. :set insertmode :help 'insertmode' :help evim-keys That's another idea I had: set permanent Insert mode and bind the keys I'm used to type, together with a couple of keybindings for setting noinsertmode if I need to. The naked truth is that I should learn the vim keybindings, but it is going to be pretty hard... Thanks a lot for your answer, you've been very helpful :)) 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!
