Re: good keys for mappings
[Arn] Any suggestions on keys/key combos that are good candidates for custom mappings etc? The usual is \ followed by something. I initially fought this convention, because \ is a bit hard to type on my keyboard, and tried other things instead, with various levels of conflicts and displeasure. I finally gave in the convention and overcame the keyboard difficulty. I think Bram mentioned he's found prefixing with _ works well.. The _ key is sometimes suggested as well, and some say it is unused. But this is not true, _ is a very useful command for me (it brings the cursor back at the first non-blank character of the current line). A common approach is to use timeouts for recognizing a single key command when that key is also the prefix of multi-key commands. The timeout is not incurred when you immediately follow the single key command by other commands which are not ambiguous with the multi-key commands, but if you want to see the effect of the single key command, you have to suffer the timeout, which may be a bit irritating at times. -- François Pinard http://pinard.progiciels-bpi.ca
Re: copying text char-by-char from the line above line..
[Andy Wokula] Ajay Gupta schrieb: I saw one of my friends (once!) copying the text from the line right above. :h i_Ctrl-Y At first, I had some difficulty remembering Ctrl-Y, until I decided that "Y" was a picture of what was going on: that is, funneled from above. Now, I use it very often. Ctrl-E copies from the line below, often useful too, yet it is harder to see an upside-down "Y" into "E" :-). -- François Pinard http://pinard.progiciels-bpi.ca
Re: JSVI: Vi implemented in Javascript
[Tobias Klausmann] On Wed, 30 May 2007, A.J.Mechelynck wrote: Hmm... when's the day when Vim will be implemented in Lisp [...] Of course, that has already been done. It's called viper: http://www.delorie.com/gnu/docs/emacs/viper.html Viper Is a Package for Emacs Rebels. It's quite far from "Vim". Only "vi", that is, almost unusable :-). -- François Pinard http://pinard.progiciels-bpi.ca
Re: Describe-key ?
[EMAIL PROTECTED] is there anything like "describe-key" (EMacs)in vim ? The simplest might be the Vim help system. For example: :h ^X describes Ctrl-X. You have to type "^X" as two characters, not one. It is a good idea to get familiar with the help system in Vim (the same as with the Emacs help system for Emacs users). Try both: :h :h help For commands and keybindings, Emacs has a ¹one-line help (corresponding to the first line of a starred doc-string -- if I remember well), ²the full doc-string (which is usually more succinct than the manual, yet in a few cases more complete than the manual, or even, very rarely, contradicting it :-), and the ³automatic display of the manual entry. Vim help mostly corresponds to this later one. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Weird problem with helpgrep
[DervishD] [Bram Moolenaar] Only a few things might need to be spread to other directories, using symlinks when possible (binary in /usr/local/bin, libs in /usr/local/lib, header files in /usr/local/include). Well, I know about a packaging system that does exactly that (I don't remember its name). The problem is that maintaining that lot of symlinks is a mess, usually. It's easier (and IMHO more convenient) to use the installation system of the package to put the files where they belong (again, IMHO) in the first place. Hi, people. Just perusing email in ultra-fast mode :-). I did not read the previous exchanges, so I apologize if I'm out of context. I used two installation systems which were extremely fond on symbolic links: LUDE (from Université de Montréal) and Stow (from GNU). Both have been used in various places. LUDE was a bit gigantic for my own needs, I've never really been comfortable with it. Stow was OK and clean (not so messy). Even if I was careful to be stow-compatible for a few packages I maintained in another life, I nowadays prefer installations to be plain straight. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Smarter Indent (an odd problem)
[Benji Fisher] Let me take this opportunity to try once again to drum up support for an idea that I have proposed before. IMO it is too restrictive to make options (such as syntax highlighting, 'textwidth', and indent-related options) apply to a whole file. There should be a convenient, consistent way to tell vim to treat different sections of a file as having different file types. Examples: * code snippets in an e-mail * PHP in an HTML file (or vice-versa) * perl/python/ruby inside a vim script * comments, text, and math inside LaTeX/plain TeX/conTeXt I quite agree it would be an interesting possibility. For example, it would be nice having reST support in Python doc-strings (for those projects where it makes sense), programming language support within parser generators having their own separate syntax, and such things. But I have realistically no time to offer (being usually rather short on free time), so I'm not sure how I / we could help. -- François Pinard http://pinard.progiciels-bpi.ca
Re: quick math computations
[stri ker] I frequently need to do some basic calculations. [...] Is there a way to do calculations with doubles instead of integers without piping to an external program like bc and then inserting into a buffer? If you are lucky enough to have a Python-enabled Vim, you may use: :py print 3.7 * 4.5 and read the result (16.65) in the echo area. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Shell support in Vim?
[Aaron Griffin] Bram has spoken - vim is an editor. It is not a shell. Quite granted. I see *nothing* that another terminal cannot do. I'm happy with what Vim is. However, here, you could use some more imagination :-). There are a few things another terminal cannot easily do, while these things are more akin to Vim editing in read-only mode than they are to shell operations. For example, a shell buffer could do syntax coloring of shell output, when within a given highly interactive subsystem like Lisp or R, say. As long as this precise subsystem is active, the "file type" could be set to drive the highlighting. Another thing is the ability to use Vim search facilities through some voluminous output. Yet another is the ability to scroll and wander within previous output, or even do clever selections like Vim block, or otherwise, which most terminals just do not offer. However, Vim does not easily allow editing of growing files (at least so far that I know), and a shell buffer essentially holds growing output. Moreover, Vim does not really proxy interactive communication with other programs, while this seems essential to implement shell buffers. Shell buffers also come, sooner or later, with their own complex requirements, like file name completion (and then, the necessary directory tracking that goes with it), following the stty settings (like echo), consequent output cleanup and filtering, more localisation concerns, etc. It is more a can of worm than many might think. I prefer Vim to stay clean and efficient like it is. Yet, I regret not having its syntax highlighting abilities over my shell output... -- François Pinard http://pinard.progiciels-bpi.ca
Re: Vim changelog mode?
[David Woodfall] Just wondered if there was changelog mode for vim as emacs has? I use it all the time! Not exactly like Emacs', but very usable nevertheless. :-) To get it going, I added a file ~/.vim/plugin/changelog.vim with: runtime! ftplugin/changelog.vim let g:changelog_username = 'François Pinard <[EMAIL PROTECTED]>' The first line has the effect of installing the ,o binding, and ,o allows you to initialize a new ChangeLog entry. The second line is personal customisation. I also have customisation within files: ~/.vim/ftplugin/changelog.vim ~/.vim/syntax/changelog.vim For the first of these two (in case you ever make one as well for you own habits), I needed the following lines at start: if &filetype != 'changelog' finish endif so to the rest be inhibited when the "runtime!" line above is run. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Distinguishing Maxima (computer algebra) scripts from assembler files
[Benji Fisher] [Robert Dodier] But Bram tells me that some assembler files also use that same extension. What is a reliable way to distinguish the two? I do not know how reliable it is, but searching for the Maxima assignment operator (I assume that is what := is.) looks like a possibility. The usual assignment operator is ':'. ':=' is used to define functions. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Distinguishing Maxima (computer algebra) scripts from assembler files
On Sat, Apr 22, 2006 at 01:10:56PM -0600, Robert Dodier wrote: I have created a syntax colorization file for scripts written for the Maxima computer algebra system (http://maxima.sf.net). [...] PS. Here is the syntax file I created: http://maxima.sourceforge.net/misc/maxima.vim Wow, good news, thanks for the reference! :-) -- François Pinard http://pinard.progiciels-bpi.ca
Re: vim7 aap config.arg
[Dog Walker] I am assuming that there is one option per line in config.arg with the leading '--', for example: --enable-pythoninterp Exactly. :-) -- François Pinard http://pinard.progiciels-bpi.ca
Re: vim7 aap config.arg
[Dog Walker] I have successfully downloaded, built and installed vim70c on Linux SuSe 9.0 using aap. Now I want to rebuild using different options (gtk+, python,...). How do I do it and persists the change so that subsequent downloads and builds of new versions will incorporate my options. You create a vim7/src/config.arg. It may even pre-exist the initial download, and would be honoured. I did not try this method recently, however. -- François Pinard http://pinard.progiciels-bpi.ca
