Sourcing a visual selection

15 views
Skip to first unread message

Ed Kostas

unread,
Nov 15, 2012, 10:09:36 PM11/15/12
to vim...@googlegroups.com
I need to execute a visual selection of text. What I want is something similar to C-x C-e in Emacs. Then, there is no need to create a VIM source file for a short calculation. However, I don't know very well the machinery of VIM. Therefore, all I was able to do is something like this:

function! SourceRange() range
let tmp = tempname()
call writefile(getline(a:firstline,
\ a:lastline), l:tmp)
execute "source " . l:tmp
call delete(l:tmp)
endfunction
command! -range Source
\ <line1>,<line2>call SourceRange()

I found this solution somewhere in the Internet. I don't like it, because I don't want to write a temp file. I would appreciate if a fellow from this group could point out a solution that does without a temporary file. I want to visual select a region of my text and source it. Thus

:'<,'>Source

The above program works, but it requires a temp file. As far as I know, Emacs does not require a temp file. VIM probably does not either.

The other thing I need is to write scripts in Common Lisp, instead of Vimscript. When I work with Emacs, I almost never use elisp for scripting. I have created a function based on call-process-region to transfer the duty to sbcl, that is very fast compared to elisp. I want to do the same thing in VIM, and I think that I succeeded. However, my solution needs a temp file, which I think is something very unpleasant. Here is my ugly solution:

function! LispRange() range
let tmp = tempname()
execute "w !sbcl --script > " . l:tmp
execute "r " . l:tmp
call delete(l:tmp)
endfunction
command! -range Lisp silent
\ <line1>,<line2> call LispRange()

From the first execute, you can see that I was able to send data to sbcl without a temp file. However much I tried, I couldn't bring the output from Lisp to my file without a temp file. Again I would be very pleased if someone could point out an elegant solution to the problem.

Ed Kostas

unread,
Nov 15, 2012, 11:02:29 PM11/15/12
to vim...@googlegroups.com
By the way, I also tried to use the :@ command. In few words, I performed a visual selection, and pressed y. Then I tried to evaluate the " register. Thus:

:@"

Of course, I did it at the command line. By command line I mean that entry field at the bottom of the page. The :@ operator works when there aren't long expressions, that one needs to break in many lines with the \ char. I believe that a knowledgeable VIM programmer has a simple method of cleaning the \ char, and concatenate the parts of expressions that occupy more than one line. I also would like to have a command with a range argument, so I don't need to perform the sourcing operation in two phases, copy with y, and evaluate the register (that is what I am doing now).

In fewer words, I want to use the :@ operator in a program with the behaviour of the Source command that I posted in the previous article.

Ed Kostas

unread,
Nov 16, 2012, 12:08:48 AM11/16/12
to vim...@googlegroups.com
Here is a program that does not work:

function! SourceRange() range
let @r= join(map(getline(a:firstline, a:lastline),'v:val . "|"') )
@r
endfunction

command! -range Lop <line1>,<line2> call SourceRange()

Salman Halim

unread,
Nov 16, 2012, 12:30:47 AM11/16/12
to vim...@googlegroups.com
From what I understand, the problem is that a large number of statements that go together to form a contiguous block, such as a function definition, must be executed in one shot. You can't execute them one line at a time. They have to be executed as one block. The only way I know of doing that is to put them in a separate file and source the file.

While you may create a mapping to concatenate multiple lines into a long line separated by the bar or pipe, I don't know if this will work in all situations.

The personal mappings I use do create a temporary file and then source it. Alternatively, I find it preferable to sometimes create a dummy file myself and just repeatedly source it whenever I need to. Occasionally, some of the functions I write end up being part of my permanent part of my library. 

I also have mappings to delete the currently edited file, which frequently goes hand-in-hand with the above operation.

I realize that I'm not offering any new insight, but at least you know that there is one other person who does it the way you do, more or less. 

Hope this helps,

Salman


--
سلمان حلیم

Reply all
Reply to author
Forward
0 new messages