Re: Problems when using Windows files on Linux...
On 2011-09-07, wombatvvv wrote: > Hi, > > I find if I use VIM in Windows, save the file and then open it in Linux, I > got a whole heap of errors. It's something to do with the end-of-line > character. In Linux it's detected as ^M and causes errors in .vim scripts. > > How do I get my Windows VIM to play nice with my Linux VIM? Linux Vim doesn't like DOS line endings (CR-LF), but Windows Vim accepts either DOS or Unix (LF) line endings. Therefore, a Vim script or configuration file saved with Unix line endings will work equally well with both Windows and Linux Vim. I use one set of Vim configuration files for both Windows and Linux. To help keep the line endings correct, I have a ~/.vim/after/ftplugin/vim.vim file that contains, among other things, setlocal fileformats=unix,dos That's all I have to do for files that I create myself. Some Vim scripts on vim.org or vim.sf.net are archived with DOS line endings. Those I convert to Unix line endings with d2u or dos2unix on a Unix system. Regards, Gary -- 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
Problems when using Windows files on Linux...
Hi, I find if I use VIM in Windows, save the file and then open it in Linux, I got a whole heap of errors. It's something to do with the end-of-line character. In Linux it's detected as ^M and causes errors in .vim scripts. How do I get my Windows VIM to play nice with my Linux VIM? Thanks. -- View this message in context: http://vim.1045645.n5.nabble.com/Problems-when-using-Windows-files-on-Linux-tp4781290p4781290.html Sent from the Vim - General mailing list archive at Nabble.com. -- 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
Re: The X bug with Gvim
On Sep 5, 12:40 pm, Jacky Liu wrote: > Hi everyone > > I need multi-threading in Vim because I need some work being done > under the desk without turning Vim into a "zombie" What sort of work? Perhaps it's something you could use the client server interface for, to start an external background process and then send the results back into Vim when complete, like this: http://vim.wikia.com/wiki/Execute_external_programs_asynchronously_under_Windows (the tip is for Windows but the techniques should work with minor modifications on Unix). The background process could probably even be another Vim if needed, but that just seems a bit strange. -- 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
Re: CTRL-]/CTRL-T to detect existing windows/buffers when switching to/from tags
On Wed, Sep 7, 2011 at 9:01 PM, Benjamin Fritz wrote:
>
>> Seemingly also, Vim doesn't like this line:
>>
>> let g:last_tag_file = []
>>
>> It seems to take exception to "[]" -- changing it to the empty string
>> "", seems to work, but again, I'm clutching at straws knowing nothing
>> about Vimscript.
>>
>
> This line should be fine, it assigns an empty List to g:last_tag_file.
> I don't know how that could fail.
>
There was an extraneous ';' character on the line somehow.
Here's what I ended up with, but now I'm stuck:
nnoremap :call SmartTagSearch()
let g:last_tag_file = []
function! s:SmartTagSearch()
" get the first tag hit for the word under the cursor
let searchstr = expand("")
let foundtags = taglist(searchstr)
if empty(foundtags)
echohl Error
echomsg "Tag" searchstr "not found!"
echohl None
endif
let firsttag = foundtags[0]
" save off the current file in case we need it again
call add(g:last_tag_file, expand("%:p"))
" jump to the file containing the tag (in existing window if possible)
execute 'drop' fnameescape(firsttag.filename)
" jump to the tag itself
execute 'tag' searchstr
endfunction
nnoremap :call SmartTagReturn()
function! s:SmartTagReturn()
if (empty(g:last_tag_file))
echohl Error
echomsg "Tag file stack empty"
echohl None
return
endif
" jump to the file containing the pre-tag position (in existing
window if possible)
execute 'drop' remove(g:last_tag_file, -1)
" jump to the pre-tag position itself
pop
endfunction
When I use this version, jumping to a tag with CTRL-] works fine. But,
jumping back with CTRL-T or with :pop does nothing. Repeating the
operation gives a "tag stack empty" message. What's going on here?
--
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
Re: CTRL-]/CTRL-T to detect existing windows/buffers when switching to/from tags
On Wed, Sep 7, 2011 at 6:56 PM, David Chanters
wrote:
> Hi,
>
> On 7 September 2011 04:44, Ben Fritz wrote:
>> Here's a more complete script, but I haven't tested it either:
>>
>> nnoremap! :call SmartTagSearch()
>
> Vim seemingly doesn't like this line. In adding your example and
> sourcing it in Vim, I see:
>
> Error detected while processing /tmp/foo.vim:
> line 1:
> E477: No ! allowed: nnoremap! :call SmartTagSearch()
> line 17:
> E477: No ! allowed: nnoremap! :call SmartTagReturn()
>
Oops, that's wrong. I copied and pasted the pseudocode as a starting
point and missed that.
Also Ctrl ought to be just C in these mappings.
> So I removed the "!" from the nnoremap command, and that got rid of
> those messages but then never calls SmartTag{Search,Return}() -- any
> ideas?
>
Probably because is an invalid mapping, it should be .
Sorry about that.
> Seemingly also, Vim doesn't like this line:
>
> let g:last_tag_file = []
>
> It seems to take exception to "[]" -- changing it to the empty string
> "", seems to work, but again, I'm clutching at straws knowing nothing
> about Vimscript.
>
This line should be fine, it assigns an empty List to g:last_tag_file.
I don't know how that could fail.
> For reference:
>
> VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 15 2011 10:46:03)
> Included patches: 1-280
> Modified by pkg-vim-maintain...@lists.alioth.debian.org
>
Can you include a few more lines, for the included features? E.g. mine is:
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jul 4 2011 00:09:21)
Included patches: 1-237
Compiled by ben@LivingRoom
Huge version with GTK2 GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent +clientserver +clipboard +cmdline_compl
+cmdline_hist +cmdline_info +comments +conceal +cryptv +cscope
+cursorbind +cursorshape +dialog_con_gui +diff +digraphs
+dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi
+file_in_path +find_in_path +float +folding -footer +fork()
+gettext -hangul_input +iconv +insert_expand +jumplist +keymap
+langmap +libcall +linebreak +lispindent +listcmds +localmap
-lua +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec
+mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg
+path_extra +perl/dyn +persistent_undo +postscript +printer
+profile +python/dyn -python3 +quickfix +reltime +rightleft -ruby
+scrollbind +signs +smartindent -sniff +startuptime
+statusline -sun_workshop +syntax +tag_binary +tag_old_static
-tag_any_white -tcl +terminfo +termresponse +textobjects
+title +toolbar +user_commands +vertsplit +virtualedit +visual
+visualextra +viminfo +vreplace +wildignore +wildmenu
+windows +writebackup +X11 -xfontset +xim +xsmp_interact
+xterm_clipboard -xterm_save
--
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
Re: Is there a Vim command invocation counter?
On 09/07/11 20:14, Kelly Dean wrote: I'm looking for something to count keyboard command invocations in Vim, like the following for Emacs: http://code.google.com/p/ergoemacs/source/browse/trunk/packages/keyfreq.el The purpose is to record how frequently I use the various commands. I'm interested particularly not only in counting aggregate usage of "d", "c", and "y", but also the individual motions following them, e.g. "dw" vs. "dW" vs. "dt." vs. "d$", and "j" vs. "gj", and particular versions of equivalent commands used, e.g. "d$" vs. "D". Has such a program been published? I've searched but found nothing I don't know of anything that already exists, but if I were to develop something, I'd make use of the "-w" startup parameter: vim -w keystrokes.out some_file.txt :help -w which records every keystroke into the given file. I know that VimGolf.com does something like this to score solutions. -tim -- 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
Is there a Vim command invocation counter?
I'm looking for something to count keyboard command invocations in Vim, like the following for Emacs: http://code.google.com/p/ergoemacs/source/browse/trunk/packages/keyfreq.el The purpose is to record how frequently I use the various commands. I'm interested particularly not only in counting aggregate usage of "d", "c", and "y", but also the individual motions following them, e.g. "dw" vs. "dW" vs. "dt." vs. "d$", and "j" vs. "gj", and particular versions of equivalent commands used, e.g. "d$" vs. "D". Has such a program been published? I've searched but found nothing. Also I'm looking for other people's Vim statistics to compare to my own, like the following for Emacs: http://xahlee.org/emacs/command-frequency.html -- 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
Re: HTML syntax & netrw
Thanks to Dr. Chip for the super-quick update and to Christian for locating the source of the bug! It works beautifully now. I love how responsive and helpful the Vim community is. Greatly appreciated. It fills me with a nice, warm, open source feeling. :) -- 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
Re: Swank Protocol and Async Events
You're lucky: You didn't research hard enough. https://github.com/MarcWeber/ensime Not sure why the ensime manual has no comment anymore. Debugging is not supported yet but completion and background compilation does work. It is build on top of vim-addon-async (requiring client-server thus X on linux) However I hav't had time to update it to make it work with latest scala. 2.8 should be fine though. Unfortunately I'll be unavailable for about 4 days. Ping back on Monday if you want to help merge changes with upstream.. I consider codefellow being dead for several reasons and nobody made eclim work with Scala yet. There is one request on their mailinglist though. Don't forgett that all three big ides Eclipse, IDEA, Netbeans also support Scala to some extend and they all support at least most important Vim keys.. Marc Weber -- 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
Re: CTRL-]/CTRL-T to detect existing windows/buffers when switching to/from tags
Hi,
On 7 September 2011 04:44, Ben Fritz wrote:
> Here's a more complete script, but I haven't tested it either:
>
> nnoremap! :call SmartTagSearch()
Vim seemingly doesn't like this line. In adding your example and
sourcing it in Vim, I see:
Error detected while processing /tmp/foo.vim:
line1:
E477: No ! allowed: nnoremap! :call SmartTagSearch()
line 17:
E477: No ! allowed: nnoremap! :call SmartTagReturn()
So I removed the "!" from the nnoremap command, and that got rid of
those messages but then never calls SmartTag{Search,Return}() -- any
ideas?
Seemingly also, Vim doesn't like this line:
let g:last_tag_file = []
It seems to take exception to "[]" -- changing it to the empty string
"", seems to work, but again, I'm clutching at straws knowing nothing
about Vimscript.
For reference:
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 15 2011 10:46:03)
Included patches: 1-280
Modified by pkg-vim-maintain...@lists.alioth.debian.org
(Running on Debian.)
TIA!
--
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
Re: The X bug with Gvim
On 09/07/2011 07:31 PM, Jacky Liu wrote:
On Sep 6, 1:40 am, Jacky Liu wrote:
Hi everyone
I need multi-threading in Vim because I need some work being done
under the desk without turning Vim into a "zombie", now I know Vim is
single-threaded, so I decided to give Python a try, demonstration:
" x-bug.vim
python3<< EOF
import threading
import time
print('thread 1')
def print_to_vim():
print('thread 2')
threading.Thread(name='test', target=print_to_vim).start()
print('thread 1 again')
time.sleep(3)
EOF
The above code works fine with console Vim as it prints the intended
message while everything else look normal, but it would make Gvim
collapse every time it's been sourced, leaving this message:
gvim: Fatal IO error 11 (Resource temporarily unavailable) on X
server :0.0.
The problem seems to be with the X system. I did some more test and it
seems ok to have multiple Python threads in Gvim, but only one of
these threads is permitted to interact with the GUI (means to cause
any change of display within the Gvim program window)
Since I'm an ordinary user to both Vim and Python and don't know much
about the Unix System, can anyone please tell me:
1. Should this be considered a bug?
2. Is there any way to get around this, thus making it safe to have
several Python threads interacting with Gvim?
Thanks
Please, isn't there anyone interested in this topic?
I think doing multi-threading in Vim would find great use, like in
Conque -- its current implementation is far from optimal. Follow this
way down we may use Vim as an excellent UI for almost any text-based
program there is (or going even further with non-text based programs
if you like), and now this X-bug or whatsoever seems to be the biggest
(if not last) obstacle.
Anyone? Please tell me what you think.
Besides, the vim doc had nothing on this topic, it didn't say that
Python shouldn't go multi-threaded with Gvim. Should I try to post
this in the vim_dev group?
I agree that better integration with Python, including multithreading,
would be the best new feature for Vim. I think the issue is that
it's not easy to do? At least, it ranks #2 in this list:
http://www.vim.org/sponsor/vote_results.php
And so far I don't think much was done in this respect, so here's
hoping for the future...
-ak
--
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
Re: The X bug with Gvim
On Sep 6, 1:40 am, Jacky Liu wrote:
> Hi everyone
>
> I need multi-threading in Vim because I need some work being done
> under the desk without turning Vim into a "zombie", now I know Vim is
> single-threaded, so I decided to give Python a try, demonstration:
>
> " x-bug.vim
>
> python3 << EOF
>
> import threading
> import time
>
> print('thread 1')
>
> def print_to_vim():
> print('thread 2')
>
> threading.Thread(name='test', target=print_to_vim).start()
>
> print('thread 1 again')
>
> time.sleep(3)
>
> EOF
>
> The above code works fine with console Vim as it prints the intended
> message while everything else look normal, but it would make Gvim
> collapse every time it's been sourced, leaving this message:
>
> gvim: Fatal IO error 11 (Resource temporarily unavailable) on X
> server :0.0.
>
> The problem seems to be with the X system. I did some more test and it
> seems ok to have multiple Python threads in Gvim, but only one of
> these threads is permitted to interact with the GUI (means to cause
> any change of display within the Gvim program window)
>
> Since I'm an ordinary user to both Vim and Python and don't know much
> about the Unix System, can anyone please tell me:
>
> 1. Should this be considered a bug?
>
> 2. Is there any way to get around this, thus making it safe to have
> several Python threads interacting with Gvim?
>
> Thanks
Please, isn't there anyone interested in this topic?
I think doing multi-threading in Vim would find great use, like in
Conque -- its current implementation is far from optimal. Follow this
way down we may use Vim as an excellent UI for almost any text-based
program there is (or going even further with non-text based programs
if you like), and now this X-bug or whatsoever seems to be the biggest
(if not last) obstacle.
Anyone? Please tell me what you think.
Besides, the vim doc had nothing on this topic, it didn't say that
Python shouldn't go multi-threaded with Gvim. Should I try to post
this in the vim_dev group?
--
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
Re: order of cterm=?, ctermfg=? in :highlight
On 07/09 11:44, Gary Johnson wrote: > On 2011-09-07, you wrote: > > I've just noticed that > > > > :highlight TablineSel ctermfg=white ctermbg=blue cterm=NONE > > and > > :highlight TablineSel cterm=NONE ctermfg=white ctermbg=blue > > > > does not give the same result. > > > > In the first case, the cterm=NONE works, while in the second it does not > > (after that cterm=bold) > > > > It seems that's because a command such as > > :hi TabLineSel ctermfg=color > > also automatically modify cterm (after that cterm=bold) and thus the > > cterm information has to be precised after the ctermfg information. > > > > Can someone give me more explanation about the exact rule vim use ? > > Do > > :help highlight-cterm > :help highlight-ctermfg > > help explain what you're seeing? I think this sentence describes well the problem: "For an xterm this depends on your resources, and is a bit unpredictable." And actually I didn't notice too that I only had the problem with TERM=xterm-16color (that I don't use anymore). It seems that the problem concerns rather xterm than vim. It's a little strange however that modifying ctermfg also modifies cterm (the contrary is more common). -- 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
Re: making noballooneval "stick"?
On Wed, 7 Sep 2011, Ben Fritz wrote: On Sep 7, 3:00 pm, "Christopher J. Bottaro" wrote: Hello, I have set noballooneval in my vimrc file, but it seems to be getting overwritten (I'm guessing from an autocmd for filetype). :verb set ballooneval? should tell you what's overwriting the setting. When you find it, Ben F's response can be used as appropriate. -- Best, Ben H How can I ensure that noballooneval set in the vimrc isn't overwritten? You can't. But you can find the offending plugin and add an autocmd of your own, remove the autocmd if you made it yourself, or add a file to an appropriate "after directory" to set the value as you prefer. -- 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
Re: making noballooneval "stick"?
On Sep 7, 3:00 pm, "Christopher J. Bottaro" wrote: > Hello, > > I have set noballooneval in my vimrc file, but it seems to be getting > overwritten (I'm guessing from an autocmd for filetype). How can I ensure > that noballooneval set in the vimrc isn't overwritten? > You can't. But you can find the offending plugin and add an autocmd of your own, remove the autocmd if you made it yourself, or add a file to an appropriate "after directory" to set the value as you prefer. -- 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
making noballooneval "stick"?
Hello, I have set noballooneval in my vimrc file, but it seems to be getting overwritten (I'm guessing from an autocmd for filetype). How can I ensure that noballooneval set in the vimrc isn't overwritten? Thanks for the help. -- 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
Re: HTML syntax & netrw
Christian Brabandt wrote: Hi Taylor! On Mi, 07 Sep 2011, Taylor Hedberg wrote: Good to know it's not just me. :) If I can provide any additional information to assist you in tracking down the bug, just let me know. I'd be happy to help. The problem is, netrw sets 'isk' in s:NetrwSafeOptions() to include among others the slash. And then the syntax match htmlTagName doesn't match anymore, since it uses the \< and \> to anchor the tags. It doesn't seem to reset this option in s:NetrwOptionRestore() It should probably also restore the other options it sets locally. Good catch, Christian! I've fixed it by including isk in s:NetrwOptionSave() and s:NetrwOptionRestore(). It seems that isk was the only such option left out that s:NetrwSafeOptions() touches. However, I also went through the body of the code and included addtional options that netrw touches and included them, too. You may get an updated copy of netrw with this issue fixed by downloading netrw at http://drchip.0sites.net/astronaut/vim/index.html#NETRW . Regards, Chip Campbell -- 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
Re: order of cterm=?, ctermfg=? in :highlight
On 2011-09-07, you wrote: > I've just noticed that > > :highlight TablineSel ctermfg=white ctermbg=blue cterm=NONE > and > :highlight TablineSel cterm=NONE ctermfg=white ctermbg=blue > > does not give the same result. > > In the first case, the cterm=NONE works, while in the second it does not > (after that cterm=bold) > > It seems that's because a command such as > :hi TabLineSel ctermfg=color > also automatically modify cterm (after that cterm=bold) and thus the > cterm information has to be precised after the ctermfg information. > > Can someone give me more explanation about the exact rule vim use ? Do :help highlight-cterm :help highlight-ctermfg help explain what you're seeing? Regards, Gary -- 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
Re: HTML syntax & netrw
Hi Taylor! On Mi, 07 Sep 2011, Taylor Hedberg wrote: > Good to know it's not just me. :) > > If I can provide any additional information to assist you in tracking > down the bug, just let me know. I'd be happy to help. The problem is, netrw sets 'isk' in s:NetrwSafeOptions() to include among others the slash. And then the syntax match htmlTagName doesn't match anymore, since it uses the \< and \> to anchor the tags. It doesn't seem to reset this option in s:NetrwOptionRestore() It should probably also restore the other options it sets locally. regards, Christian -- 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
Re: HTML syntax & netrw
Good to know it's not just me. :) If I can provide any additional information to assist you in tracking down the bug, just let me know. I'd be happy to help. Thanks, Taylor Hedberg -- 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
Re: Argdo with shellcommand
On 09/07/11 05:36, Si St wrote:
I am trying something like this to recode several ot many files:
:args ./*
:while
:argdo
:1,$ !recode lat1...utf8
:update
:next
:endwhile
I am familiar with the argdo set ff=unix | update
but I do not know how to make the first example work
I suspect you want something like
:argdo exec "%!recode lat1...utf8" | update
because the ":{range}!" command assumes that a "|" gets passed to
the shell command/pipeline.
:help :range!
:help :bar
-tim
--
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
Argdo with shellcommand
I am trying something like this to recode several ot many files: :args ./* :while :argdo :1,$ !recode lat1...utf8 :update :next :endwhile I am familiar with the argdo set ff=unix | update but I do not know how to make the first example work It will be tested out before I apply it to a production system with many files. Otherwise I am familiar with: :let &termencoding = &encoding :set encoding=utf-8 -- Si St sigbj...@operamail.com -- http://www.fastmail.fm - A no graphics, no pop-ups email service -- 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
order of cterm=?, ctermfg=? in :highlight
I've just noticed that :highlight TablineSel ctermfg=white ctermbg=blue cterm=NONE and :highlight TablineSel cterm=NONE ctermfg=white ctermbg=blue does not give the same result. In the first case, the cterm=NONE works, while in the second it does not (after that cterm=bold) It seems that's because a command such as :hi TabLineSel ctermfg=color also automatically modify cterm (after that cterm=bold) and thus the cterm information has to be precised after the ctermfg information. Can someone give me more explanation about the exact rule vim use ? -- 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
Re: HTML syntax & netrw
On Sep 7, 9:44 am, Taylor Hedberg wrote: > > then the syntax highlighting is fine. The only difference in the output > of `:scriptnames` between these two test cases is the inclusion of > $VIMRUNTIME/plugin/netrwPlugin.vim in the netrw case, so again, it seems > that netrw is somehow the culprit. > Are you sure this is the only difference? stuff in $VIMRUNTIME/plugin is normally sourced automatically whenever you load Vim, regardless of what you do in Vim, unless you've turned plugins off from a command- line option or the 'noloadplugins' option. > One other thing I tried was to edit the file with netrw and then save it > locally with `:saveas`. After doing this, the syntax problems remained, > but once I exited Vim and reopened the local copy of the file, the > problems went away. > How about trying editing the local file with netrw? I would expect it to misbehave in the same way if netrw is the culprit. I don't think you mentioned, did you verify that the correct filetype is set for both methods of editing? Maybe netrw is interfering with filetype detection. What version of netrw are you using (check the header info in the plugin files)? What version of Vim? What compiled feature set? -- 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
Re: Writing only the selected characters
Being unsatisfied with existing solutions, I wrote this:
vmap y y:call Yank()
nmap p :call Paste(0)
nmap P :call Paste(1)
function! Yank()
let response = system("xclip", @")
endfunction
function! Paste(paste_before)
let at_q = @q
let @q = system("xclip -o")
if a:paste_before
normal! "qP
else
normal! "qp
endif
let @q = at_q
endfunction
Sayonara,
--
Bastien
--
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
Re: CTRL-]/CTRL-T to detect existing windows/buffers when switching to/from tags
On Sep 7, 7:32 am, Jacky Liu wrote:
>
> Now I'm thinking that maybe just :drop to the target file and let :tag
> do the rest would be OK, this way the tag stack would be updated too,
> and should make the following indeed the other way round --
> just :drop back and :pop.
>
Oh, good call.
New implementation, still untested:
nnoremap! :call SmartTagSearch()
let g:last_tag_file = [];
function! s:SmartTagSearch()
" get the first tag hit for the word under the cursor
let searchstr = expand("")
let firsttag = taglist(searchstr)[0]
" save off the current file in case we need it again
call add(g:last_tag_file, expand("%:p"))
" jump to the file containing the tag (in existing window
if possible)
execute 'drop' fnameescape(firsttag.filename)
" jump to the tag itself
execute 'tag' searchstr
endfunction
nnoremap! :call SmartTagReturn()
function! s:SmartTagReturn()
if (empty(g:last_tag_file))
return
endif
" jump to the file containing the pre-tag position (in
existing window if possible)
execute 'drop' remove(g:last_tag_file, -1)
" jump to the pre-tag position itself
pop
endfunction
Note these will need an update, to handle a count. Currently they do
not handle a count correctly. In fact, they will fail entirely with a
count due to the auto-insertion of the count when you press (or map) :
in normal mode.
:he v:count and :he v:count1 should be of interest for this.
--
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
Re: CTRL-]/CTRL-T to detect existing windows/buffers when switching to/from tags
Sorry to Ben if you receive this twice~
>
> I'd rather just use the :drop command, which will jump to another
> window if that other window already contains the file in question, re-
> use the current window, or split a new window if the current buffer
> cannot be abandoned.
>
Yea，:drop is interesting, I didn't know this command before, it should
fit best here.
> > 4. :exe + :normal ^W^W to switch to that window
>
> > 5. use the {cmd} got in 1. to locate the tag
>
> That would be in 2. But I'm not sure of the format. Is this something
> you can just use :execute on?
>
Just realized that you mean {cmd} here, I don't know exactly either,
haven't used this taglist() function before, I just ":tab help" to go
to the help interface and gave it a shot to see what it looks like:
:echo taglist('ex')[0]['cmd']
and it was like:
/*ex*
I guess this *can* be :execute-ed, yet I think now there's a better
approach, see below.
> > Taking all tab pages into account is no problem either, just introduce
> > tabpagenr() and :gt
>
> Even better, :tab drop
>
Shouldn't this open new tabs no matter what? I think the OP prefer
switching to an existing file if it contains the tag in question.
> > is just the other way round.
>
> I think CTRL-T would be very different actually, unless I'm missing
> something. You could accomplish it by storing the current buffer
> number, and using the :sbuffer command and the 'switchbuf' option, but
> more likely if the CTRL-] is implemented as desired you can just
> switch back to the previous window and be where you want to be.
>
Now I'm thinking that maybe just :drop to the target file and let :tag
do the rest would be OK, this way the tag stack would be updated too,
and should make the following indeed the other way round --
just :drop back and :pop.
> > This should work, theoretically. But I haven't tried it.
>
> Here's a more complete script, but I haven't tested it either:
>
> nnoremap! :call SmartTagSearch()
>
> function! s:SmartTagSearch()
> " get the first tag hit for the word under the cursor
> let firsttag = taglist(expand(""))[0]
> " jump to the file containing the tag (in existing window
> if possible)
> execute 'drop' fnameescape(firsttag.filename)
> " jump to the tag itself
> execute firsttag.cmd
> endfunction
>
So my version would be just replacing the "execute firsttag.cmd" with
"exe 'tag ' . firsttag.filename"
> > Plus: what does the "CC" mean?
>
> There have been a few answers, I'm not sure if one of them is correct.
> I actually read somewhere that CC meant "courtesy copy". BCC is
> related, meaning "blind courtesy copy". But apparently the actual
> definitions have long been lost since there are so many ideas for it
> now, even if the meanings are clear.
Interesting that widely-used abbreviation seems to have lost its
origin, thanks to all of you :-）
--
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
Swank Protocol and Async Events
hi, i guess you could use python/ruby and fork a process that listens to a connection. since fork probably isn't supported on windows, in order to provide a cross-platform solution you might have to start an app (e.g. a second intance of vim) that knows how to send commands to vim via its server/client interface. there is nothing missing in vim. but you have to take a slightly different approach than with emacs. hth tom -- 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
Re: Windows 7: mysterious behavior using gVim to change file in c:\program files
On 09/05/11 12:58, sbq wrote: Here is my weird experience. I want to modify fzdefaults.xml, a FileZilla config file located in the Windows 7 directory C:\Program Files\FileZilla FTP Client. Here's what happened. [edit file... confirm gVim sees the changes...] [I trimmed too much, probably. An important bit: "Right click » edit with Vim"] gVim is showing me the wrong contents of the file -- not what is on the disk. What kind of gVim are you using? And where did you get it? I was only able to replicate the weirdness by using a Cygwin vim. I couldn't get VirtualStore files to appear using gVim 7.3.46 (latest self-installing), 7.3e (old beta for 7.3), 7.3.106 (Vim with Cream), or the 64-bit 7.3 (from vim-win3264). On 09/06/11 19:34, Benjamin R. Haskell wrote: On Tue, 6 Sep 2011, Tim Chase wrote: I seem to remember Win7 (and Vista?) doing some sort of behind-the-scenes remapping of files so that if you tried to edit something in a protected area like "\Program Files", it would redirect the reads/writes into some user-space area. Windows 7 folder mapping: http://answers.microsoft.com/en-us/windows/forum/windows_7-files/windows-7-folder-mapping/080a50fe-7581-46d1-a85d-126f24604309 Application Compatibility: Junction Points and Backup Applications: http://msdn.microsoft.com/en-us/library/bb756982.aspx Again I've responded with links to a slightly different problem with similar symptoms (frustration with Windows7 folder misdirection). What's described above (and I think is the actual problem) is called User Account Control (UAC) Virtualization. There's a good description of it in the MSDN article "New UAC Technologies for Windows Vista": http://msdn.microsoft.com/en-us/library/bb756960.aspx?ppud=4 Search for "File Virtualization". Tim's summary was pretty good (if you try to edit something in a protected area, it redirects into some user-space area). Specifics: C:\(Path to protected file) becomes: %localappdata%\VirtualStore\(Path to protected file) e.g. for me: C:\Program Files (x86)\Vim\vim73\colors\blue.vim became: C:\Users\bhaskell\AppData\Local\VirtualStore\Program Files (x86)\Vim\vim73\colors\blue.vim If you're browsing a protected folder with Windows's standard folder browser, you can view any of these files by clicking the «Compatibility files» button below the location bar. (Could use that to determine definitively that that's the problem here.) In a long, frustrated thread¹, "How to disable VirtualStore in Windows 7?", one of the workarounds is to "take ownership" of the directory (which makes the VirtualStore unnecessary). Might be useful info. Not sure what a long-term solution for Vim under Windows should look like. As mentioned, I could only get this to happen using a Cygwin vim.exe. Even though I'm running 64-bit Win7, 32-bit gVim.exe's didn't exhibit the behavior (despite the MSDN article indicating they should -- maybe it changed from Vista to 7). -- Best, Ben ¹: http://answers.microsoft.com/en-us/windows/forum/windows_7-security/how-to-disable-virtualstore-in-windows-7/55dce284-0dcd-46af-892e-d2b9cf5bcff6 -- 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
