Re: Mac Questions
On 2007-01-12, at 03:45, A.J.Mechelynck wrote: By default, Vim doesn't change directories when you open a file. If you open Vim from the Dock, without a filename, the current dir is your home directory. If you later edit one or more files, the current directory is unchanged. If you want to edit a file which is not in the current dir, you should specify the path as part of the argument to the ":edit" command. (You can use command-line completion repeatedly to complete one subdirectory or file name at a time.) If you type just ":e filename", then if "filename" doesn't exist in the current directory, Vim will assume that you want to create a new file there. If, instead, you click a file in Finder, the OS sets the current directory to that file's directory, then invokes Vim. If Vim is compiled with +netbeans_intg or with +sun_workshop, you can set 'autochdir'. This will change the current directory whenever you edit a new file, switch buffers, etc., so the current directory will follow the current file. Vim will still not "guess" a directory name (how could it?): ":e filename" with no path, still means that you want to edit (or create) a file in the current directory, whatever it is. Alternately, you can use :autocmd BufWinEnter * lcd %:p:h which will set a "local directory" for each buffer. This alternative only requires +autocmd, which is included in "Normal", "Big" and "Huge" builds of Vim. Personally, I've tried it, and I've found that I don't like directory changes happening, so to speak, "behind my back". I prefer that directories only be changed when I use ":cd" or ":lcd" explicitly. (YMMV) In any case, each window's status line (when present) displays the path to the file in that window, relative to the current directory if possible, or otherwise as an absolute path. See :help 'autochdir' :help :autocmd :help BufWinEnter :help :cd :help :lcd :help 'laststatus' Best regards, Tony. Wow, you guys are always very helpful! Thanks a lot for help. I personally prefer a directory changes automatically at least right know, working with one big project in LaTeX2e. Maybe after that I'll change my mind being enough experienced ;-) Thanks a lot once again! stay in touch, -- Pozdrawiam - Krzysztof Maj I'm a Mac now, are you PC? Oh, dear... ;-)
Re: Mac Questions
Alan G Isaac wrote: On Mon, 8 Jan 2007, Brett Calcott apparently wrote: I have just got a Macbook (switching from windows) and have downloaded and compiled the latest version of Vim on it. It all works fine, but I have a few questions. Would you mind outlining the steps you took for someone who is making the same transition but is not used to compiling their own apps? (I have XCode installed.) Thank you, Alan Isaac I would suggest going here: http://macvim.org/OSX/index.php It has a binary and some hints and tips as well. Robert
Re: Encoding problem
A.J.Mechelynck wrote: [...] If you leave 'encoding' set at Latin1, Vim won't be able to represent in memory any Unicode codepoints higher than U+00FF, even if you use ":e ++enc=utf-8 filename". See for instance the Russian and Arabic text in my front page, http://users.skynet.be/antoine.mechelynck/index.htm . If you /don't/ use ++enc, then with 'fencs' empty (which is not the default) there will be no translation, and every codepoint above U+007F in a UTF-8 file will appear as two or more bytes of gibberish. For instance, "Raúl Núñez" would be shown as "Raúl Núñez" which is not very pretty to look at. [...] Oops! That page plays a dirty trick: it sets your 'encoding' to UTF-8. To see the difference, download it on your computer, remove the modeline at line 3, and restart Vim. Best regards, Tony.
Re: Encoding problem
DervishD wrote: Hi Tony :) * A.J.Mechelynck <[EMAIL PROTECTED]> dixit: DervishD wrote: ":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. ":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, 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. 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. Multibyte characters above 256 (but not necessarily Unicode codepoints in the range U+0080 to U+00FF, which are multibyte in all Unicode encodings but are not above 256) are also always "printable"; however, some of them don't display and may be handled specially. 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. If you leave 'encoding' set at Latin1, Vim won't be able to represent in memory any Unicode codepoints higher than U+00FF, even if you use ":e ++enc=utf-8 filename". See for instance the Russian and Arabic text in my front page, http://users.skynet.be/antoine.mechelynck/index.htm . If you /don't/ use ++enc, then with 'fencs' empty (which is not the default) there will be no translation, and every codepoint above U+007F in a UTF-8 file will appear as two or more bytes of gibberish. For instance, "Raúl Núñez" would be shown as "Raúl Núñez" which is not very pretty to look at. Problem solved! Thanks a lot for everything, Tony :) Raúl Núñez de Arenas Coronado De nada, hombre. Best regards, Tony.
Re: Reformat in visual area - vmap question
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. Granted, I tend to use back-tick almost exclusively, so I suppose the forward-tick could be available for use. -tim
Re: Reformat in visual area - vmap question
* 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 -- JR
Re: Encoding problem
Hi Tony :) * A.J.Mechelynck <[EMAIL PROTECTED]> dixit: > DervishD wrote: > >>":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. > > ":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? > 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? 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). Problem solved! Thanks a lot for everything, 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: Reformat in visual area - vmap question
Hi Tony :) * A.J.Mechelynck <[EMAIL PROTECTED]> dixit: > DervishD wrote: > [...] > >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. > 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? 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
DervishD wrote: [...] 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 Yes, ñ or ç would be good. Beware of ' and ` though: they are used in Normal mode for "mark" movements. Best regards, Tony.
Re: Encoding problem
DervishD wrote: 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. ":scriptencoding" applies no farther than the end of the current script. 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. 0xF7 in Lain1, or Unicode U+00F7, is the divide sign (English style, a colon with a dash in the middle). 0xBB, or U+00BB, is the closing French quote (Ctrl-K >>). Again, thanks a lot for your help, you're great : Raúl Núñez de Arenas Coronado 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. Best regards, Tony.
Re: Reformat in visual area - vmap question
Hi Tony :) * A.J.Mechelynck <[EMAIL PROTECTED]> dixit: > > * Matthew Winn <[EMAIL PROTECTED]> dixit: > >>>The 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 > :map! 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: 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: 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!
