*********************************************************
* I found it ! The reason why and the solution. *
*********************************************************
Sorry for all these messages, i was really thinking that i'd never make it, and finally...
So.
What was happening, was that $CURRENT_FILE_TO_RUN was being set to the right value. BUT makeprg wasn't (yes, it's quite obvious if you're not in the process of "trying to debug").
Apparently, splitting the window transferred the value from $CURRENT_FILE_TO_RUN to makeprg. I'm guessing that .vimrc is run each time a new buffer is opened. I didn't know that.
The solution to my problem, is thus to update makeprg directly each time that i choose the current file to run with ;f , rather than using $CURRENT_FILE_TO_RUN.
Here is my final solution, for those who would want to use it. It is very dirty (lots of redunduncy), you are also very welcome to make it nicer. It's 4:30 in the morning, i'm struggling with the Vim scripting language, i won't bother =)
Ah, and i've also added a shortcut for compile+running the file from the current buffer, rather than the one that we chose as a file_to_run
"""""""""""""""""""""""""""
" Compile+run Perl code
"current file to compile+run must be the current one...
let $CURRENT_FILE_TO_RUN="%"
autocmd FileType perl set makeprg=perl\ -cIlib\ $CURRENT_FILE_TO_RUN\ $*
echo "MAKEPRG:"
:set makeprg
"...unless we choose the file that we are reading, as the "current file to run"
map ;f :call SetCurrentFileToRun()<CR>
function SetCurrentFileToRun()
let $CURRENT_FILE_TO_RUN=bufname("%")
"let $MY_MAKEPRG="perl\ -cIlib\ $CURRENT_FILE_TO_RUN\ $*"
set makeprg=perl\ -cIlib\ $CURRENT_FILE_TO_RUN\ $*
endfunction
"run the file from the active buffer, not the "current_file_to_make"
map ;R :call MakeTheCurrentFile()<CR>
function MakeTheCurrentFile()
"copy the "current_file_to_make" to a buffer
let $BUF=$CURRENT_FILE_TO_RUN
"make the current file
let $CURRENT_FILE_TO_RUN=bufname('%')
set makeprg=perl\ -cIlib\ $CURRENT_FILE_TO_RUN\ $*
call MakeWithCopenAndCfileInNewTab()
"retrieve the "current_file_to_make" path (from the buffer)
let $CURRENT_FILE_TO_RUN=$BUF
set makeprg=perl\ -cIlib\ $CURRENT_FILE_TO_RUN\ $*
endfunction
"From Marc Jessome, by email, 14th July 2012.
"I modified the
"for e in qflist
"if !e.valid
"by replacing it with
"if len(qflist)>1
" because the elements of my qflist were not valid until i used :cfile
function MakeWithCopenAndCfileInNewTab()
make
let qflist = getqflist()
if len(qflist)>1
tabnew
copen
cfile $ERROR_FILE
else
call TellSyntaxOk()
endif
endfunction
function TellSyntaxOk()
call inputsave()
let name = input("SYNTAX OK ! \npress Enter...")
call inputrestore()
endfunction
" END Compile+run Perl code
""""""""""""""""""""""""""""""""""""
That's it.
I'd like to run the code instead of using TellSyntaxOk(),
but this line won't work :
!perl\ -Ilib\ $CURRENT_FILE_TO_RUN
as it doesn't take the value of $CURRENT_FILE_TO_RUN, but directly tries to do in the console
perl -Ilib $CURRENT_FILE_TO_RUN
On 17 July 2012 03:53, mascip <mascip@gmail.com> wrote:
I've tried different combinations :bufname("%") instead of bufname('%')bufname(1) instead of bufname('%')and got exactly the same results, for Scenario 1 and 2, and for Scenario 3 (which is even more strange to me).*Scenario 3:if i first use ;f to set $CURRENT_FILE_TO_RUN to C:/test.t,and ONLY THEN open module.pm with:vsplit C:/module.pmand put my cursor there, to make it the current buffer.Then i get the result what i want :when i type :make it is the test.t file which is compiled and run.BUT as is said before, if i FIRST split the window:vsplit C:/module.pmand then set the $CURRENT_FILE_TO_RUN with;fThen, i get that the current file is compiled and run.This would mean that when i have more than one buffer,the change of $CURRENT_FILE_TO_RUN is not really taken into account.But when i "echo" it, it says what it should say.I really don't understand why this order matters :first :vsplit => it doesn't workORfirst :let $CURRENT_FILE_TO_RUN=bufname("%") => it worksbut in both case, $CURRENT_FILE_TO_RUN is equal to C:/test.t before i use :make.I tried to set makrprg=echo\ $CURRENT_FILE_TO_RUNbut it didn't work : when i typed :make, it just printed echo\ $CURRENT_FILE_TO_RUN, not its value.I don't have a clue what's going on...--On 17 July 2012 02:20, mascip <mascip@gmail.com> wrote:
Hi all,i'm trying to set a "current file to set and run" :when i use :make, i want this file to be compiled and run, instead of the file that i'm in.For this, i've first used this which seems to work :"current file to compile and run must be the current one...let $CURRENT_FILE_TO_RUN="%""...unless we choose the file that we are reading as the current file to compile and runmap ;f :let $CURRENT_FILE_TO_RUN=bufname('%')<CR>This works well. The $CURRENT_FILE_TO_RUN variable echos what i want.Then, i've used this, to effectively use this file name when i :makeautocmd FileType perl set makeprg=perl\ -cIlib\ $CURRENT_FILE_TO_RUN\ $*I obtain a strange result.Let's say i have a these two files :C:/module.pmC:/test.t* Scenario 1 (the one that works) :First, i open test.t in Vim.at this moment, $CURRENT_FILE_TO_RUN is equal to %, and :make compiles test.tThen, i press ;fthis works well : now, i have $CURRENT_FILE_TO_RUN equal to C:/test.tThen, i open C:/module.pm in the current buffer, with:e C:/module.pmwhich closes test.tNow, i still have $CURRENT_FILE_TO_RUN equal to C:/test.tFinally, i press:makeand things do what they should :perl -cIlib C:/test.tis executed, everything is how it should be.* Scenario 2 (the one that doesn't work) :in this scenario, instead of opening C:/module.pm in the same buffer as C:/test.t,i open it with:vsplit C:/module.pmwhich splits the window in two, and open C:/module.pm in the new opened buffer.Now, whether i'm in the module.pm buffer, or in the test.t buffer,$CURRENT_FILE_TO_RUN is equal to C:/test.t, which is good !BUT then, when i type:makeit's module.pm which get compiled ! Withperl -cIlib C:/module.pmI really don't understand why, as my environment variable $CURRENT_FILE_TO_RUN is equal to C:/test.t,and it worked in the first Scenario.It looks extremely strange to me, but the answer might be obvious to someone who is more used to Vim, its variables and their scope.Any idea ?If someone had another implementation (or plugin) to achieve the same goal, i'd be interested too.Cheers =)pierre / mascip
mascip@gmail.com
http://lesrikikibians.fr
mascip@gmail.com
http://lesrikikibians.fr
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment