This is the I way do it in my .vimrc file:
nmap <C-L> o<SPACE><BS><ESC>
So if you are in normal mode, type <C-L> a couple of times. You end up staying in normal mode, allowing you other commands like 'p', 'a', etc.
I avoid 'o' + <CR> because they don't preserve autoindent space after you hit <ESC> or <CTRL-O>. I also could not get <CTRL-\ CTRL-O> to work the way I wanted to.
/SELECT$^Mj:.,/DROM~@kb~@kb~@kb~@kbFROM$/ yank m^M?spooo~@kbl^Mmp"mp/SELECT$^Mj/spool SYS^M:.+1,/SELECT/-1 s: .* \([A-Za-z0-9_]\1~@kb+\) *,\?~@kb~@kb:\1|^M?spool^M:.,/SELEX~@kbCT/-1 s:^ ^*~@kb~@kb-~@kb*::^M/spool SYS^M:.+1,/SELECT/-1 join^M:s: ::g^M:s:.*:select '&' from dual ;^M
Ez egy sor. A w regiszter tartalma per pillanat. És most: 2500@w. OMG, működik. Elsőre.
„Huh?“ you ask. Yes, it is actually possible to do functional programming in Vim. Of course this is not as convenient as in a language which is actually designed for functional programming like Haskell or Clojure. But nevertheless: it is possible
A main building block for functional programming are closures. Consider for example this clojure snippet.
(let [x 5
y 6]
(future
(+ x y)))Under the hood, Clojure creates a thunk containing the body of the future call, that is (+ x y). This thunk is passed to a freshly created Future object, which sets up a new thread and calls the thunk in the new thread. Since the thunk is a closure it remembers the environment where it was defined. So although the thunk is executed in a different thread, it has access to the locals x and y.
Now Vim doesn't have closures. You can define function objects, but they don't remember their environment. However we can manually set up a poor man's closure by virtue of Vim's maps and 1st order functions.
That means, that we have to manually close over all values from the environment, which we later on need, when executing the function. To do that, we simply set up a map containing the required values. Plus the function.
function CounterBump() dict
let cnt = self.counter
let self.counter += 1
return cnt
endfunction
function MakeCounter(initial)
let closure = { counter: a:initial }
let closure.bump = function("MakeCounterBump")
return closure
endfunctionMakeCounter returns a closure, which „closes over the local counter variable“. It should pretty obvious what happens. The function CounterBump accesses a well defined set of key in the map to do its work. The MakeCounter constructor sets up the required keys and adds the function to the map.
Let's use our new counter.
let counter1 = MakeCounter(5)
counter1.bump() " gives 5
counter1.bump() " gives 6
let counter2 = MakeCounter(0)
counter2.bump() " gives 0
counter1.bump() " gives 7This different calls to MakeCounter give different maps. Hence the CounterBump function sees different counter locals.
Suppose you want to move some text from one buffer to another. This could be done be yanking the text into a register and paste into the target buffer. However, what happens in that case with the register content? Maybe the user saved already something there?
So we have to protect the register's content. This adds a lot of annoying boilerplate. Save the content, do things, restore the register.
This can be hidden away in with the above technique. Consider the following helper.
function WithSavedRegister(register, closure)
let savedReg = getreg(a:register)
let result = closure.f()
call setreg(a:register, savedReg)
return result
endfunctionThe usage should be fairly obvious by now. We first define a worker function. Then create our „closure“ map with a well defined f key and all other necessary things. Finally we pass everything to our WithSavedRegister utility to actually do the work.
function Worker() dict
" do stuff here
return "something useful"
endfunction
let closure = { f: function("Worker") }
let somethingUseful = WithSavedRegister("x", closure)Ooops. But what happens if an exception is thrown in our Worker? The register will not be restored. If we had sprinkled our code with such boilerplate, we would now be in trouble. We'd have to go to each and everyplace and add the protection. But with our utility it is sufficient to fix WithSavedRegister.
function WithSavedRegister(register, closure)
let savedReg = getreg(a:register)
try
let result = closure.f()
finally
call setreg(a:register, savedReg)
endtry
return result
endfunctionFunctional programming in Vim is possible, although it is not really supported out of the box. Lightweight objects in form of maps and function pointers make this possible.
Voici quelques options pour contourner cet affreux beep système qui nous agace lors des complétions ou erreurs en console.
1) Afficher les complétions possibles plutôt que biper Cette option diminue fortement les beep système en ne sonnant que sur de vraies erreurs (comme un mauvais nom de fichier tapé) et permet en plus de n'appuyer qu'une seule fois sur <TAB> pour les auto-complétions.Use this little thingie:
hdknr@debian:~$ sudo update-alternatives --config editor
`editor' を提供する 3 個の alternatives があります。 選択肢 alternativeI like writing in Vim! It is one of those things that I am so used to
that every other text editor feels unnatural and going against the
grain. So I thought I'd write a small plugin to post to Posterous. Add
the following code to your .vimrc. Also make sure you have python
enabled in vim as well as have markdown2 for python installed.
curl -u my@email.com:mYpA$$W0RD http://posterous.com/api/getsites
This is the title of the post This is the body of the post.This code is pretty straightforward and sparse because I am using this
vi・vimビジュアルモード
他Windows用エディタの[Shift]を押しながら文字を選択するように 文字単位で選択したい場合は、ビジュアルモードを使用します。 ビジュアルモードで文字を選択したすれば、削除コマンドや ヤンクコマンド等がより便利につかえることになります。 ノーマルモードからビジュアルモードに移るコマンドを紹介します。
キー 動作 v ビジュアルモードになる。文字列選択の開始、終了。 V 行単位で選択のビジュアルモードになる。文字列の選択開始、終了。 Ctrl + v 矩形選択（ボックス選択）のビジュアルモードになる。文字列の選択開始、終了。 ビジュアルモードにより、文字列を選択し選択範囲に、削除やコピー（ヤンク）等の命令を実行することが出来ます。 下記に例を示します。
キー 動作 d ビジュアルモードで範囲選択後、実行で、選択範囲を削除する。 c ビジュアルモードで範囲選択後、実行で、選択範囲を削除して、インサートモードになる。 y ビジュアルモードで範囲選択後、実行で、選択範囲をコピー（ヤンク）する。
