Re: [PATCH] Determining whether a window used :lcd
On 4/26/07, Nikolai Weibull [EMAIL PROTECTED] wrote:
Either way, wouldn't it be more useful to alter getcwd() to take an
optional argument stating whether we want the local or global cwd?
The problem is that my plugin needs to change the current working
directory, perform an action, and then restore the previous working
directory. I need to know whether to use :lcd or :cd to do that. If
I use :cd in a window that had previously used :lcd, then I clobbered
the :lcd usage and that window is now stuck to the global directory;
additionally, the global directory is changed to whatever the prior
value. If I instead use :lcd always, and the window wasn't previously
using a local directory, it now is.
let saved_cwd = getcwd('local')
let cd_cmd = (saved_cwd != getcwd('global')) ? 'lcd' : 'cd'
exec cd_cmd '…'
⋮
exec cd_cmd saved_cwd
(assuming getcwd('local') returns the local directory, if there is
one, or whatever getcwd('global') would, if not.)
While, again, that functionality would suit my plugin's need, I can't
help but feel that that's a pretty inefficient way of checking
compared to:
let cd_cmd = haslocaldir() ? 'lcd' : 'cd'
In the larger picture, I don't know why you'd want to distinguish
between local and global directory normally, other than to determine
the correct ':l?cd' to use, so I don't think that specifying a
parameter to getcwd() to be very useful. haslocaldir() has the
advantage of (imo) being simpler.
Thank you,
bob
Re: [PATCH] Determining whether a window used :lcd
On 4/25/07, Nikolai Weibull [EMAIL PROTECTED] wrote: Not at all. This patch merely exposes some information about the current cd/lcd functionality. It does not provide new directory changing stack capability. You misunderstand. Isn't the functionality requested in your todo entry just a subset of the one above? I mean, can't the functionality that your todo entry adds be made available with the addition of a directory stack? No, I understand your question, but I don't see any relationship, at all, between the two items. Adding current directory stacks has nothing to do with allowing introspection of the state of a window variable. The two changes are completely orthogonal. That said, for the purpose of my needs, I would be happy if I could temporarily override the current directory of a window without having to worry whether the directory was local or global. An implementation of either todo would be therefore sufficient for my plugin; I chose to address the more obvious lacking functionality instead of adding entirely new functionality. Thank you, bob
Re: [PATCH] Determining whether a window used :lcd
On 4/25/07, Nikolai Weibull [EMAIL PROTECTED] wrote: OK, I guess then I don't understand your todo entry and Yakov's need for it. I should clarify, it is my need, and I have no idea who added the todo. I found it while trying to discern if the functionality I needed was provided already. The todo entry is There is no way to change directory and go back without changing the local and/or global directory. Add a way to find out if the current window uses a local directory. Add cdcmd() that returns :cd or :lcd? I guess I'm just confused about how the first two sentences relate. Ah, the first sentence is simply a statement that really has very little to do with the actual todo entry. True. Either way, wouldn't it be more useful to alter getcwd() to take an optional argument stating whether we want the local or global cwd? The problem is that my plugin needs to change the current working directory, perform an action, and then restore the previous working directory. I need to know whether to use :lcd or :cd to do that. If I use :cd in a window that had previously used :lcd, then I clobbered the :lcd usage and that window is now stuck to the global directory; additionally, the global directory is changed to whatever the prior value. If I instead use :lcd always, and the window wasn't previously using a local directory, it now is. In either case, I have adversely and unexpectedly altered the environment. The patch as it stands lets me check to see if the current window has a local directory, and therefore which version of the change directory command to use. Thank you, bob
Re: [PATCH] Determining whether a window used :lcd
On 4/23/07, Nikolai Weibull [EMAIL PROTECTED] wrote: The attached patch very simply implements the following from the todo: Wait! I have a comment! Isn't this todo just a subset of 6 Add :cdprev: go back to the previous directory. Need to remember a stack of previous directories. We also need :cdnext. Not at all. This patch merely exposes some information about the current cd/lcd functionality. It does not provide new directory changing stack capability. Thank you, bob
Re: [PATCH] Determining whether a window used :lcd
On 4/11/07, Bob Hiestand [EMAIL PROTECTED] wrote: The attached patch very simply implements the following from the todo: 7 There is no way to change directory and go back without changing the local and/or global directory. Add a way to find out if the current window uses a local directory. Add cdcmd() that returns :cd or :lcd? I personally would prefer the function be called something like 'isdirlocal()'. I need this feature for my vcscommand.vim plugin, which changes directory a fair amount, and can screw up the user environment if the user makes use of :lcd. Does anyone have any feedback on this? Thank you, bob cdcmd.patch Description: Binary data
[PATCH] Fwd: Determining whether a window used :lcd
The attached patch very simply implements the following from the todo: 7 There is no way to change directory and go back without changing the local and/or global directory. Add a way to find out if the current window uses a local directory. Add cdcmd() that returns :cd or :lcd? I personally would prefer the function be called something like 'isdirlocal()'. I need this feature for my vcscommand.vim plugin, which changes directory a fair amount, and can screw up the user environment if the user makes use of :lcd. Thank you, bob -- Forwarded message -- From: Bob Hiestand [EMAIL PROTECTED] Date: Apr 11, 2007 4:06 PM Subject: Re: Determining whether a window used :lcd To: Yakov Lerner [EMAIL PROTECTED] Cc: vim@vim.org vim@vim.org On 4/11/07, Yakov Lerner [EMAIL PROTECTED] wrote: I needed this once in of my script. I ended with some rude simplification/workaround, lackng the direct simple solution. I don't know your specific case, but you might find simlpistic workaround. One weird attempt to determine this would be to (I did not do it): (1) get getcwd() in the window in quiestion (2) create temp new window with :new (3) get getcwd() in the new temp window (4) compare cwd from step (3) against cwd from step(1) (5) :bw the temp window This has lots of drawcacks: - I am not sure this sequence works in the presence of :acd thought. - I am not sure this sequence works at all, but I can't think of other method either. - This sequence won't detect one subtle case: case the :lcd is set, but is set to directory X where X is same as current directory. (This case behaves differently that case without :lcd, but this difference might not matter to you). I don't think it works. When you use :new, you inherit the :lcd, if it was used. Maybe vim needs new functions getlcwd(), hetgcwd(), or additional 2nd param to getcwd() to return global/local dir. After looking in the :help todo, it appears that others have requested it. I've thrown together a quick patch to implement the described 'cdcmd()' (I prefer a more direct 'isdirlocal()'), but that's fine. I'll try submitting it. Thank you, bob cdcmd.patch Description: Binary data
Determining whether a window used :lcd
Hello, all. Is there any way to determine whether a particular window has its path set with :lcd? Thank you, Bob
Re: Determining whether a window used :lcd
On 4/11/07, Yakov Lerner [EMAIL PROTECTED] wrote: I needed this once in of my script. I ended with some rude simplification/workaround, lackng the direct simple solution. I don't know your specific case, but you might find simlpistic workaround. One weird attempt to determine this would be to (I did not do it): (1) get getcwd() in the window in quiestion (2) create temp new window with :new (3) get getcwd() in the new temp window (4) compare cwd from step (3) against cwd from step(1) (5) :bw the temp window This has lots of drawcacks: - I am not sure this sequence works in the presence of :acd thought. - I am not sure this sequence works at all, but I can't think of other method either. - This sequence won't detect one subtle case: case the :lcd is set, but is set to directory X where X is same as current directory. (This case behaves differently that case without :lcd, but this difference might not matter to you). I don't think it works. When you use :new, you inherit the :lcd, if it was used. Maybe vim needs new functions getlcwd(), hetgcwd(), or additional 2nd param to getcwd() to return global/local dir. After looking in the :help todo, it appears that others have requested it. I've thrown together a quick patch to implement the described 'cdcmd()' (I prefer a more direct 'isdirlocal()'), but that's fine. I'll try submitting it. Thank you, bob
Re: repeat replace many time on each line
On 4/2/07, Tobia [EMAIL PROTECTED] wrote:
Arnaud Bourree wrote:
I've Xml document with attribute likes:
foo=00 12 AF
I want to replace with:
foo=0x00 0x12 0xAF
%s/\%(\%(foo=\\)\@=\%(0x[0-9A-F]\{2\}\s\)*\)\@=\([0-9A-F]\{2\}\)/0x\1/g
this works:
%s/\%(\%(foo=\\)\@=\%([0-9A-F]\{2\}\s\)*\)\@=\([0-9A-F]\{2\}\)/0x\1/g
In using :s with the /g flag, I take it the potential changes are
marked first, and then executed, per line?
Somewhat more generally, the pattern above could be:
%s/\%(\%(foo=\\)\@=\%(\%(0x\)\?[0-9A-F]\{2\}\s\)*\)\@=\([0-9A-F]\{2\}\)/0x\1/g
which works both with and (repeatedly) without the /g flag.
I prefer when dealing with that many special characters to use the
very-magic form:
%s/\v%(%(foo\=)@=%(%(0x)?[0-9A-F]{2}\s)*)@=([0-9A-F]{2})/0x\1/g
... but that's obviously a matter of personal preference.
Thank you,
bob
Re: Problem with VCSCommand
On 11/30/06, Joakim Olsson [EMAIL PROTECTED] wrote: I solved the problem by setting shell to cmd.exe in my .vimrc. The problem stems from the fact that I set the SHELL environment variable to /usr/bin/bash to make rxvt work for Cygwin. Vim sees that and set shell to the same value of course. Is this something that should generally be set for VIM under cygwin, or something that only really impacts vcscommand under cygwin? I know some folks have had issues with cygwin before, and I'd like to prevent that if possible. Thank you, bob
Re: Open multiple files (when there are spaces in the pathname)
On 8/24/06, Bulgrien, Kevin [EMAIL PROTECTED] wrote:
At various times it is useful to launch vim with a file list that has been
generated by a command so that buffers and macros written on the fly are
able to be used on a number of files. A trivial, though questionably useful,
example that normally works might be:
$ vim $(find . -iname readme.txt)
The above command fails when spaces occur in path and file names, and the
following variation has been found to work in the BASH shell.
$ eval $(echo vi $(find . -iname readme.txt | sed -e s/^/\/ -e
s/$/\/))
This seems clunky, especially since it seems that the eval $(echo $())
indirection should not be necessary Perhaps there is a better way that does
not rely on those shell commands?
Tip 1212 http://www.vim.org/tips/tip.php?tip_id=1212 seemed like it might
apply (using isfname), but initial attempts to use vim --cmd did not seem to
work. Variations like the following all seemed to fail, and may indicate
that isfname is not used to process command line arguments that are file
names, but it also could mean I just don't know what I am doing ;-)
$ vi --cmd :set isfname+=32 $(find . -name Entries | sed -e s/ /\\\ /)
$ vi --cmd set isfname+=32 $(find . -name readme.txt | sed -e s/^/\/
-e s/$/\/)
It might be helpful to see what, exactly, you want to do with the
files. However, to answer the direct question (that of opening files
with spaces in them), you could do something like this from within VIM
itself:
:for file in split(globpath('.', '**/*.txt'), \n)|argadd `=file`|endfor|rewind
That command will search for all *.txt files under the current
directory (and all its subdirectories) and add them to the arg list,
regardless of spaces in the path names.
Hope that helps,
Bob
Re: Allow only one instance of vim on Windows
On 8/22/06, Bob Hiestand [EMAIL PROTECTED] wrote: On 8/22/06, Stelian Iancu [EMAIL PROTECTED] wrote: Hello there, I've been using vim on and off for about 5 years now but now I've decided to switch entirely to vim. Up until now I've used UltraEdit and this one can be configured that every file that I open with it is opened in another tab of the existing instance. Can vim 7.x be configured to behave the same? Thanks and regards, Stelian Stelian, You may wish to look into the '--remote-silent' option. I've used it in the past to achieve a similar situation on Linux; I haven't tried it on Windows. If you follow this route, you may want to create a batch command to call instead the executable to massage the parameters so that, for instance, if no parameters are supplied, it may just bring the existing instance to the foreground or open a new buffer (with --remote-send). Additionally, you may wish to look into the 'foreground()' and 'remote-foreground()' functions.
Re: Allow only one instance of vim on Windows
On 8/22/06, Stelian Iancu [EMAIL PROTECTED] wrote: Hello there, I've been using vim on and off for about 5 years now but now I've decided to switch entirely to vim. Up until now I've used UltraEdit and this one can be configured that every file that I open with it is opened in another tab of the existing instance. Can vim 7.x be configured to behave the same? Thanks and regards, Stelian Stelian, You may wish to look into the '--remote-silent' option. I've used it in the past to achieve a similar situation on Linux; I haven't tried it on Windows. If you follow this route, you may want to create a batch command to call instead the executable to massage the parameters so that, for instance, if no parameters are supplied, it may just bring the existing instance to the foreground or open a new buffer (with --remote-send).
Re: renaming unnamed buffer at creation
On 8/21/06, Jürgen Krämer [EMAIL PROTECTED] wrote:
Hi,
Yakov Lerner wrote:
Now that my attempt to write unnamed buffer under
name /tmp/N failed, I want to autoname empty buffer.
My first attempt does not work. Autoevent is ot invoked.
function! TempName()
let x=1
while filereadable(/tmp/.x)
let x = x + 1
endwhile
return /tmp/.x
endfun
au BufNew * if(expand('afile') == '') | call input(AAA) | endif
au BufNew * if(expand('afile') == '') | exe file .TempName() | endif
I checked it with this autocommand
au! BufNew *
\ if expand('afile') == '' |
\ exe 'file ' . input('Enter file name: ') |
\ else |
\ echomsg 'File already has a name' |
\ endif
It seems to be triggered, but when the 'file' command is executed, VIM
is still in the original buffer thus renaming this one instead of the
new one. One way to circumvent this problem I can think of is to use the
BufNew event to store the new file name in a variable and to use this
variable in a BufEnter event. The following code should do this, but it
is untested:
au! BufNew *
\ if expand('afile') == '' |
\ let new_file_name = input('Enter file name: ') |
\ else |
\ echomsg 'File already has a name' |
\ endif
au! BufEnter *
\ if expand('afile') == '' exists('new_file_name') |
\ exe 'file ' . new_file_name |
\ unlet new_file_name |
\ endif
Regards,
Jürgen
Why not change to the new buffer? Something like:
:au BufAdd * if expand('afile')==''|execute 'buffer' expand('abuf')|execute
'file' tempname()|endif
Re: ANN: vcscommand beta 4 (supercedes cvscommand)
On 8/18/06, Alan G Isaac [EMAIL PROTECTED] wrote: On Wed, 9 Aug 2006, Bob Hiestand apparently wrote: http://vim.sourceforge.net/scripts/script.php?script_id=90 I see that many people are liking this plugin. Could you please add a few details about how it works and why it is better than just using the SVN executables. Thank you, Alan Isaac The basic idea is that it performs CVS/SVN commands on the current file within VIM, opening new windows that contain the output of the commands. This is, to me, a great deal more convenient than directly using the command-line executables because I don't have to leave the editor to, for instance, commit changes to the current file or obtain information on it. I myself primarily use it for investigation of changes during merges. For instance, I might look at the diff on two different branches, within VIM, and determine the correct code for the merge. For this, :VCSDiff and :VCSLog (with branch arguments) are typically quite helpful. :VCSVimDiff is often convenient for moving selected changes across to a different branch, as it uses the native VIM vimdiff facility for comparing the relevant versions of the file. Generally, I suppose the advantages are that you don't have to leave your text editor (which for me is key, as most of my time at a computer is spent using VIM. Also, by capturing the output of version control commands within VIM, it is much easier to navigate long log messages and the like than it would be in a command-line environment. Please feel let me know if you have specific questions. Thank you, Bob
Re: changed-yet-not-saved-lines highlighting feature
On 8/10/06, Marc Weber [EMAIL PROTECTED] wrote:
On Thu, Aug 10, 2006 at 11:02:50PM +0800, Eddy Zhao wrote:
Hi,
Very often, I open a lot of files to edit. When I exiting vim, vim
prompt me to save every file which contain changes not saved yet. So,
- Is there plugin that could highlight the
changed-yet-not-saved-lines (possibly with yellow background), so that
I could easily locate and check those changes and decide whether to
save it or not.
- Furthermore, is there plugin that could highlight the
changed-and-saved-lines in a vim session in the file (possibly with
green background), so that I could easily audit all changes of a file
in a vim edit session.
BTW, this feature is borrowed from a commercial editor I tried
sometime ago, and find very useful when editing a lot of source code
files.
I would have proposed using the diff commands, too..
(See DiffWithFileOnDisk in my privious post.)
Perhaps it would be better to save to tempname() because those files
will be deleted automatically..
I think Tim's method is better in that it doesn't require a file at
all. Depending on personal preference, it might be better to
explicitly make the diff buffer a scratch buffer, in something like
the following:
command! -nargs=0 ShowDifferences
\ let ShowDifferencesOriginalBuffer=bufnr('%')
\|execute 'bufdo diffoff'
\|execute 'buffer' ShowDifferencesOriginalBuffer
\|diffthis
\|unlet ShowDifferencesOriginalBuffer
\|below vert new
\|set buftype=nofile noswapfile bufhidden=wipe
\|r #
\|1d
\|diffthis
There's a little extra there to clear diff mode from other buffers to
avoid including more than the two intended buffers in the diff mode.
Re: Viewing CVS diff with vim
On 8/7/06, Fabio Rotondo [EMAIL PROTECTED] wrote: Hi, I am trying the vcscommand plugin, but I have a problem: I'd like to CVS diff a file with an older version, I have tried this: :VCSDiff 1.2 this opens up a new buffer with the diff output, but without using the vimdiff feature, as I'd liked to. Am I missing anything or just the plugin is not able to do that? Thanks, Fabio Use: :VCSVimDiff 1.2
Re: Help with unwanted shell character expansion
On 8/3/06, Bob Hiestand [EMAIL PROTECTED] wrote: On 8/3/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 8/3/06, Bob Hiestand [EMAIL PROTECTED] wrote: As is too often the case, I didn't read enough documentation. I think this is not a well-known feature. On 7/31/06, Bob Hiestand [EMAIL PROTECTED] wrote: Question two: Is there a way to set the buffer name without the name being subject to shell metacharacter expansion? As far as I know, only :edit, :split, :new, :write, and :file allow setting the buffer name, and those all apply shell expansion. I know that characters can be escaped, but that involved knowledge of which characters are significant on each platform and again leads to unportable code (or highly complex code that attempts to be portable by taking each system into account). I would like a function to set the buffer name (potentially for a buffer specified by number) or for the '%' register to be writable. Yes, by using backtick notation along with the '=' expression prefix, non-expansion is possible. For example, :e `=unescapedFileName` Does this really work fo you ? First, many characters are interpreted specially inside `=...`, Those are (,),+,- and all vim operators (see val.txt). Second, if I try your examlpe, I get: :e `=unescapedFileName` E121: Undefined variable: unescapedFIleName `=unescapedFileName` [New File] And then filename is set to `=unescapedFileName` Note how filename includes backticks and equal sign. Or did you possibly mean :e `='unescapedFileName'` ? Yakov Sorry, to be clear, unescapedFileName is a variable. Another way to do this appears to be using the 'bufnr' function with the 'create' optional parameter set. I have not extensively tested it, but it seems to be a useful alternative.
Re: get only basesname from bufname()
On 8/7/06, Kim Schulz [EMAIL PROTECTED] wrote: hi Is there an easy way to get only the basename (filename) without the path when using bufname()?? I am using it for a guitablabel and have tried with let label = bufname(i-1); let filename = expand(.label.:h) but that does not work. so what is the correct way ? -- Kim Schulz| Private : http://www.schulz.dk [EMAIL PROTECTED] | Business: http://www.devteam.dk +45 5190 4262 | Sparetime: http://www.fundanemt.com :help fnamemodify()
ANN: vcscommand beta 3 (supercedes cvscommand)
Hello, I have released a beta version of vcscommand, which updates cvscommand to VIM 7 (required) and adds support for Subversion (SVN) as well as providing a framework for incorporating additional similar source control systems. The plugin is available at: http://vim.sourceforge.net/scripts/script.php?script_id=90 (it replaces the cvscommand plugin). If you are a current cvscommand user, the primary difference is that the keybindings have changed. You can provide your own keybindings, however, if you wish to retain the old ones. Thank you, Bob
Re: can vim do this?
On 8/3/06, Lev Lvovsky [EMAIL PROTECTED] wrote: I recently started work at a company where the predominant text editor happens to be emacs. I've been using vim for a while now, though only recently started getting into the more advanced functionality beyond simple editing (highlighting, folding, tags etc...). Watching one of my co-workers with emacs is pretty fun, as he does things fairly quickly - I asked him what his most common emacs actions were, to see how I could do them in vim: * autocomplete - say that I've declared a constant variable in Perl named MY_CONSTANT, later, to have the editor fill it in, I type in MY_, and some other key-stroke, and CONSTANT gets typed in for you :help ins-completion * goto when compiling - when compiling with make for example, and there is a problem in the code identified by a line, can vim somehow know to go to that line? this would be especially useful with 'make' :help quickfix * rectangular cut/pastes - if I have a column (multi-row) of text that I'd like to paste on several lines, can I do this without a regex? :help visual-use :help visual-block * ctags variable name references - assuming I'm using ctags, how can I replace the name of a variable throughout my code base? I don't know. However, :help tags can give you enough information to automate this to your taste. * regional undo - can I select a region, and perform an undo for all of the changes only in that region? I don't know. This is a neat idea, though. * cvs/diff mode - what support does vim offer for these two apps, internal to the editor. :help diff There are several available plugins that provide integration. In general, you can find plugins at http://vim.sf.net . (obnoxious plug: You can get my cvs integration plugin at http://vim.sourceforge.net/scripts/script.php?script_id=90 . Shortly you'll be able to get a new version for VIM 7 that includes subversion integration as well).
Re: Help with unwanted shell character expansion
On 7/31/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: Bob Hiestand wrote: Question one: Is there a way to achieve execution of system commands without using the shell? Here I'm thinking (for example) of, in perl, the difference between using a single argument to exec() and using multiple arguments. In the first version, shell characters are expanded, in the second, they are not. If there is no such functionality currently, is this a planned feature? I believe that such a feature would make writing portable plugins easier. AFAIK, the only way to execute an external program from Vim with no shell wrapping is to set the 'shell' option itself to the program name. There may be drawbacks and pitfalls to that approach, though. Question two: Is there a way to set the buffer name without the name being subject to shell metacharacter expansion? As far as I know, only :edit, :split, :new, :write, and :file allow setting the buffer name, and those all apply shell expansion. I know that characters can be escaped, but that involved knowledge of which characters are significant on each platform and again leads to unportable code (or highly complex code that attempts to be portable by taking each system into account). I would like a function to set the buffer name (potentially for a buffer specified by number) or for the '%' register to be writable. Thank you, bob A buffer name is usually a (potential) file name. Which characters are allowed in a filename is system-dependent. On Dos and on 16-bit Windows, only 8+3 names are allowed (with no embedded spaces). On Unix, case is usually significant while on Windows it usually isn't. And so on. Also, Windows versions of Vim expand wildcards, while Unix versions leave the expansion (except for ** which is a Vim-specific extension) to the shell. The buffer name can also be set by :saveas, :view, :sview... I'm not sure I got them all. I expect all of these to also expand, for instance, environment variables. :saveas is (IIUC) equivalent to altering the current buffer's name then writing it under the new name. If the new name already exists, :saveas filename will fail but :saveas! filename will succeed (unless of course there is a further write-error, such as a disk full condition). IIUC, all Vim's internal file-related commands accept a unix-like filename syntax, and Vim translates it if necessary to the OS's syntax: e.g., when Vim for Windows receives the command :view $VIMRUNTIME/vimrc_example.vim (with an environment variable and using a forward slash as separator) the string it passes to the Windows file open function will be something like C:\Program Files\vim\vim70\vimrc_example.vim (without the quotes and with a terminating null byte IIUC, but also with the environment variable resolved and, most important, with backslashes as separators). Similarly, in Vim for Windows embedded spaces are backslash-escaped (as in Unix), even though the Windows syntax is not to use any embedded escaping but to wrap the whole name in double quotes. If you want to build portable names for newly-created files, then (assuming you can disregard pre-Win32 Dos-like systems) I suggest limiting yourself to lowercase letters, digits, underscore and period. Some systems allow more than that (and some OS versions accept Unicode non-ASCII characters in filenames) but I believe that with [0-9a-z_.] you can be fairly certain that your filename will be legal almost everywhere, and that different names will refer to different files. Best regards, Tony. Thanks, Tony. I should provide context for my request. For my cvscommand plugin, which opens new buffers containing the results of CVS operations performed on the file associated with the current buffer, I need to be able to name the resulting scratch buffers. These buffers will be explicitly not associated with files. I used to have these as nameless files, and used the statusline to pull up custom variables set by the plugin to create a suitable display name (something like [CVS log originalFileName]). The problem with this solution is that the buffer list commands just show the nameless scratch buffers, of course, making navigation difficult. As an alternative, in the new version of the plugin, I explicitly name the buffers. However, that means that the original file name appears in the buffer name, and is subject to shell expansion. While it is indeed possible to do as Yakov suggests and try to escape the shell meta-characters, I've experienced some difficulty in making that work across multiple platforms consistently (primarily Linux, Windows (various flavors), Windows + cygwin (my personal terror)). I actually already use the escape command, and ran into issues when Windows interpreted the resulting escaped character as a backslash + original character. While the help mentions a work-around for this in the case of the '[' character, I frankly don't want to have to worry with this particular
Help with unwanted shell character expansion
Question one: Is there a way to achieve execution of system commands without using the shell? Here I'm thinking (for example) of, in perl, the difference between using a single argument to exec() and using multiple arguments. In the first version, shell characters are expanded, in the second, they are not. If there is no such functionality currently, is this a planned feature? I believe that such a feature would make writing portable plugins easier. Question two: Is there a way to set the buffer name without the name being subject to shell metacharacter expansion? As far as I know, only :edit, :split, :new, :write, and :file allow setting the buffer name, and those all apply shell expansion. I know that characters can be escaped, but that involved knowledge of which characters are significant on each platform and again leads to unportable code (or highly complex code that attempts to be portable by taking each system into account). I would like a function to set the buffer name (potentially for a buffer specified by number) or for the '%' register to be writable. Thank you, bob
Re: How to Override Backup Control to Implement File Versioning?
On 7/13/06, Robert Ingraham [EMAIL PROTECTED] wrote: What I'd like to do is mimic the VMS file versioning feature wherein if you edit a file (say, file.txt) , the original is saved as file.txt.1. Subsequent backups of the same file are saved as file.txt.2, file.txt.3 and so forth. In this case, the most recent backup would be file.txt.3 and second oldest backup would be file.txt.2 and the original file would be file.txt.1. Of course, if there are no changes to the file, then no incremental backup file is created. I looked into writing a script to do this but, being new to Vim scripting, I didn't see a way to hook into the internal backup logic, or if that's even the right way to accomplish this. I'd like it to be automatic, so the user doesn't have to do anything different when saving a file (like having to run a script before saving.) Any pointers would be greatly appreciated. A quick search on vim.sf.net reveals: http://vim.sourceforge.net/scripts/script.php?script_id=89 which sounds very much like what you describe.
Re: Calling through a function reference with a variable argument list
On 6/12/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
On Mon, 12 Jun 2006 at 4:07pm, Charles E Campbell Jr wrote:
Bob Hiestand wrote:
On 6/2/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
Bob Hiestand wrote:
My question is whether there is a simpler way to pass an unknown
number of arguments from the current function to a function which
accepts a variable-length list of arguments.
...snip...
I don't think that does what I wanted, though I may have misunderstood
the implications. That converts the arguments into a string
representation of a list, which then becomes the single argument to
the second function.
Looks like I made a mistake. Here's one that does illustrate passing a
variable number of arguments along:
--
fun! AFunc(...)
let args = string(a:000)
let len = strlen(args)
let args = strpart(args,1,len-2)
echomsg call BFunc(.args.) a:0=.a:0
exe call BFunc(.args.)
endfun
--
fun! BFunc(...)
echomsg BFunc sees: a:0=.a:0
echomsg a:000.string(a:000).
endfun
--
echomsg 'AFunc(1):'
call AFunc(1)
echomsg 'AFunc(1,a):'
call AFunc(1,a)
echomsg 'AFunc(1,a,b):'
let b=BBB
call AFunc(1,a,b)
The idea is to have a string hold just the arguments, not the list
delimiters.
The exe squeezes the string together and then executes it. Consequently,
the output is:
AFunc(1):
call BFunc(1) a:0=1
BFunc sees: a:0=1
a:000[1]
AFunc(1,a):
call BFunc(1, 'a') a:0=2
BFunc sees: a:0=2
a:000[1, 'a']
AFunc(1,a,b):
call BFunc(1, 'a', 'BBB') a:0=3
BFunc sees: a:0=3
a:000[1, 'a', 'BBB']
P
So you can see that BFunc is being called with a variable number of
arguments depending on whatever AFunc received (look at the
BFunc sees: lines)
I don't know if the OP can use a Vim7.0 only solution, but the genutils
plugin has a utility to make this possible for prior versions. I have
been using this in several places of one of my plugins with no issues.
However, if Vim7.0 only solution is acceptable, Vim supports this
already with the call() function.
--
fun! AFunc(...)
echomsg call BFunc(.string(a:000).) a:0=.a:0
call call('BFunc', a:000)
endfun
--
fun! BFunc(...)
echomsg BFunc sees: a:0=.a:0
echomsg a:000.string(a:000).
endfun
--
HTH,
Hari
My intention was to create a passthrough function that could call any
other function after determining the function to which it would
dispatch control (the application here is a general source integration
script that would dispatch to the appropriate function specific to the
version control system controlling the current file).
As it turns out, I was a victim of narrow thinking because I was
trying to modify as little as possible of an existing plugin. The
correct change was to simply make the dispatch function and the end
functions accept a list as the parameter, in which case pass-through
becomes trivial.
Thank you for looking at this,
You're welcome!
Chip Campbell
Thanks, Hari, that was exactly the functionality I wanted.
Re: How do I get list of directory + how do I show them
On 6/6/06, Mueller Stefan [EMAIL PROTECTED] wrote:
Hello,
thank you for you help. But to be more precious I want to have a list of that
directory like
mylist[0] = file1.cpp,v
mylist[1] = file2.cpp,v
...
I want to feed that list to my own vim function, which displays the log, check
out by,...
Perhaps something like:
let mylist = split(glob('/path/to/directory/*'), '\n')
I'm sure there's something simpler.
Re: Has Plug Changed?
On 5/30/06, Vigil [EMAIL PROTECTED] wrote: I try to use cvscommit.vim with NERD_comments, but they both use some \c mappings. The blurb in cvscommit.vim says I can use something like nnoremap ,ca PlugCVSAdd instead. I put all the cvscommit mappings in my ~/.vimrc, formatted in this new way, but it does not seem to recognise any of the ,c maps, neither does it give an error. I can use the \c maps as normal NERD_comments maps. Looks like a bug in the cvscommand documentation. Don't use the 'noremap' portion of that command, as that kills the functionality. Instead just do something like: nmap ,ca PlugCVSAdd Thank you, bob
Re: Calling through a function reference with a variable argument list
On 5/16/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
On Tue, 16 May 2006 at 2:43pm, Bob Hiestand wrote:
Hi all,
I'm re-writing my cvscommand.vim plugin to handle both CVS and
Subversion version control systems. I'm currently implementing some
of the functionality through function references that define common
operations for each source control system in a dictionary specfic to
that system. I have a situation where I have a generic dispatch
function that identifies which dictionary to dereference to obtain the
function reference.
The problem is that the function eventually called behind the
function reference may have any number of arguments. Therefore, the
dispatch function takes any number of arguments to pass through. This
leads to the actual call, which looks like this (all on one line):
function! s:ExecuteVCSCommand(command, ...)
find the proper functionMap dictionary, and then:
execute return functionMap[a:command]( . join(map(copy(a:000),
'\' . v:val . '\'), ,) . )
My question is whether there is a simpler way to pass an unknown
number of arguments from the current function to a function which
accepts a variable-length list of arguments.
Thank you,
Bob
My suggestion would be to have the underlying methods always accept a
list of arguments, then you can just pass a:000 straight-through.
Yes, I've changed the implementation functions in this way per Yakov. Thanks.
BTW, your approach to enclose the arguments in double-quotes is a
bad-idea, especially if you are handling paths on windows with
back-slashes in them (among various others). Imagine what would happen
if the argument is c:\dev\tst\newfile, both \t and \n will result
in getting expanded to tab and newline. What you should do is to use
single-quotes to avoid accidental transformations, but then escape the
existing single-quotes themselves (if any). Take a look at the
MakeArgumentString() function in my genutils.vim.
--
HTH,
Hari
Yes, I've changed the implementation functions in this way per Yakov. Thanks.
With your heads-up about the double quote in mind, I'm glad that I'm
not using execute now, as the equivalent expression looks to be:
execute 'return functionMap[a:command](' . join(map(copy(b:alist),
' . v:val . ')), ',') . ')'
which is fairly difficult for me to read.
Thank you,
Bob
Calling through a function reference with a variable argument list
Hi all, I'm re-writing my cvscommand.vim plugin to handle both CVS and Subversion version control systems. I'm currently implementing some of the functionality through function references that define common operations for each source control system in a dictionary specfic to that system. I have a situation where I have a generic dispatch function that identifies which dictionary to dereference to obtain the function reference. The problem is that the function eventually called behind the function reference may have any number of arguments. Therefore, the dispatch function takes any number of arguments to pass through. This leads to the actual call, which looks like this (all on one line): function! s:ExecuteVCSCommand(command, ...) find the proper functionMap dictionary, and then: execute return functionMap[a:command]( . join(map(copy(a:000), '\' . v:val . '\'), ,) . ) My question is whether there is a simpler way to pass an unknown number of arguments from the current function to a function which accepts a variable-length list of arguments. Thank you, Bob
