Re: Funcref and script local functions
On 7/3/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 7/3/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> On 7/3/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > On 7/3/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > > On 6/30/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> > > > ... The Funcref obtained via function('s:T') can't be
> > > > called from outside the script ... [unexpectedly]
> > >
> > > I agree, Hari. I'd expect funcref function('s:T') to be callable
> > > outside of the script, too.
> >
> > To make myself more clear. I expect g:Xxx() to be callable
> > from global scope of from another script in this example:
> >
> > " --- scritp x.vim
> > function! s:XXX()
> > echo "func XXX"
> > endfunction
> >
> > let g:Xxx=function('s:XXX')
> >
> > Yakov
> >
>
>
> The problem with this is that you can no longer have private object
> function refs.
Of course you can .:
No. These are variables where you have managed their scopes, but the
underlying func ref *contained* would lose it's ability to maintain
it's scope, i.e. .
let s:Xxx=function('s:XXX') " script-private funcref
You could do
let g:Xxx = s:Xxx
and now the private/script-local function s:XXX() can be called
globally throughg:Xxx . I'm not sure whether this would be a
good or bad thing. It's sort of an ease-of-use vs strict scoping
rules.
Also, I think there might be a semantics problem here about the term
"function reference". It seems to be concurrently the variable name,
which can be called as a function directly, vs the underlying
reference itself. I *think* that the func ref var actually does
contain a reference, rather than *being* a reference, especially since
you can pass it around, and maintain the original function name
Anyway, I think there are, or should be two terms to talk about this
kind of issue:
- function reference
- function reference variable
let l:Xxx=function('s:XXX') " function-private funcref
let g:Xxx=function('s:XXX') " globally-accessible funcref
Yakov
I'm still not sure that I understand the utility of this. If you want
to create a global func ref variable which can call its content, which
is a script-local function ref, then why not just make the function
global in the first place? Are you worried about a global namespace
conflict of the global function [ref] name? I guess the proposed
change/request would allow creating an alias in the form of a global
func ref var, bypass a global namespace conflict.
Detouring away from the namespace question, here are two examples to consider:
let s:obj = {}
function s:obj.tstfunc() dict
return 'here'
endfunction
echo s:obj.tstfunc()
let g:Ref = s:obj
" Yank and put this into the command line to test global scope:
echo g:Ref.tstfunc()
or
function! s:tstfunc2()
return 'here2'
endfunction
let s:ref = function( 's:tstfunc2' )
echo s:ref()
let g:Global_ref = s:ref
" Yank and put this into the command line to test global scope, it should fail:
echo g:Global_ref()
So, my question is: Why should this be allowed? In the above test
script, if you made function('s:XXX') global, then it is true in
your examples, that you can create local function ref variables which
hold that ref. However, in your example,
let g:Xxx=function('s:XXX') " globally-accessible funcref
here you have violated the explicit scope set on the function s:XXX
. Actually, I personally don't care which happens, since I use
scoping in Vim only for namespace separation, not data hiding (where I
think the violation might cause some problem that I can't think of
:-).
Lastly, we've got an inconsistency: dict functions created as
numbered function refs which are always global, vs the above which
maintains scope.
Re: Funcref and script local functions
On 7/3/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 7/3/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 6/30/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> > ... The Funcref obtained via function('s:T') can't be
> > called from outside the script ... [unexpectedly]
>
> I agree, Hari. I'd expect funcref function('s:T') to be callable
> outside of the script, too.
To make myself more clear. I expect g:Xxx() to be callable
from global scope of from another script in this example:
" --- scritp x.vim
function! s:XXX()
echo "func XXX"
endfunction
let g:Xxx=function('s:XXX')
Yakov
The problem with this is that you can no longer have private object
function refs.
I'd be interested to hear from Bram about what the intent was here.
I think I can see some method in the maddness.
1) let ref = function('s:XXX')
This mains the standard scope rules for the func ref, and so it
stays local even if the variable holding it is global. I can image
situations where this could be useful.
2) let ref = function('66_XXX')
This forces the function to be available globally because it is
explicitely defined, and there is little chance of mistakes about
that.
3) function obj.funcref() dict
Again, I think the intent for having the object function in the global
scope is unknown (to me at least). I think it left global because you
don't really need specific scoping for it, as when it is used, it
*should* be used via the object name, which is scoped by the user.
function s:obj.funcref() dict
Hari, can you give an example of why function('s:T') should be
globally scoped? I can't see a need for it, given all the
possibilites for obtaining a ref.
Re: Funcref and script local functions
On 7/2/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
On Thu, 29 Jun 2006 at 10:50pm, Eric Arnold wrote:
> Ok. For starters, it seems that you *can* call a numbered function
> from anywhere:
>
>
>
> function! s:T()
> echomsg "here"
> echomsg 'SID=' . expand( '' )
> endfunction
>
> let F=function('s:T')
> echomsg F()
>
> let F1 = function( '66_T' )
> echomsg F1()
>
> echomsg string( F )
>
> let s:dict = {}
> function s:dict.init() dict
> echomsg "in dict function"
> endfunction
>
> unlet! F2
> let F2 = s:dict.init
>
> call call(F2,[],{})
> " Note: F2 is a global, so the numbered function declared for a local dict
> " is available to call globally.
Right, and that is what I intended by saying the Funcref's are behaving
as the original functions. Since numbered functions are accessible
globally, their Fucrefs are too (for that matter, I don't think you can
even call numbered functions directly, so this situation is not
completely same).
I'm still not getting it, I think. Do you have a case where the
numbered function scheme will break down, or is it about the
callbacks, described below?
>
>
> On 6/29/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> >
> > When Funcref's were introduced in Vim7, I expected them to work for
> > script-local functions, across scripts. The documentation didn't say
> > that, but it didn't say that it wouldn't either, and I thought that that
> > is one of its biggest uses (other than the actual intended
> > functionality, which is for implementing numbered functions). However, I
I'm not sure that there is a problem. As with C code, if you have
the option of declaring a function global/local, public/private, etc.
I think Vim script is allowing these options.
Are you saying that you want to override the private script
declarations by declaring a function reference to a low enough level
pointer that it goes under the scope checker?
> > found that the Funcref references for such functions can't actually be
> > passed out to other scripts. This reduces the usefulness of this feature
> > as we can't register private functions to receive callbacks from other
> > scripts.
I think this is probably a request that it be more object oriented
than it is, ie. you really want object-scoped functions, not
script-scoped. You seem to want the script localized, so it can't be
access generally, but then be public for registering callbacks. This
seems like an object-scope problem.
I think that the numbered functions are allowed globally, probably
because they are intended to be used as you describe, for callbacks
from other scripts, since they are only created for the 'dict'
"object" functions, as far as I can tell.
> >
> > What is weird is that the the Funcref() actually behaves exactly like
> > the function name itself. Say you have a function called s:T() and say
> > the script id is 60. The Funcref obtained via function('s:T') can't be
> > called from outside the script, but if the Funcref is obtained using
> > function('60_T'), then it will be fine. Also, a Funcref obtained
Both of these examples seem reasonable to me. If you declare a
function reference to a script-local object, s:T then you don't
want it being accessed outside the script. If you declare a
'60_T'reference, then you probably wanted to use it outside
the script, otherwise you wouldn't have gone through the trouble of
finding the script id.
> > using these two methods will not be to the same object, though you would
> > expect them to be. The below echoes 0:
How did you test what the object was? Actually, I wouldn't expect it
to be the same object in any case, since each reference to it should
crease a new instance. They both might refer to the same function
definition stored internally, but I don't know.
Also, we aren't talking about true "objects", just to be clear, but an
enhancment that allows object-oriented-like functional access. This
limits the expectations we can have.
> >
> > echomsg function('s:T') is function('60_T')
> >
> > where as the below echoes 1:
> >
> > echomsg function('s:T') is function('s:T')
>
>
> In this case you are *not* creating numbered functions, so the string
> value you use is what gets stored.
I think you misunderstood me, I didn't mean this.
>
> > The above two facts make Funcref counter-intuitive to understand. I
> > actually wonder why even a special function called function() was
>
Re: s?
I can't remember why or when (it was so long ago), but I've always used 's' and 'S' in 'vi'. It never really occured to me to use 'cl' instead. It was just another command in the list. It was part of the original 'vi', but I'm not sure if you meant that by 'put in to be complete'. It is no more enigmatic then a lot of things in 'vi' which are there just to make editing incrementally better. There's 'C' vs 'c$', 'D', 'G', 'Y', etc., all of which are redundant with combinations of other commands. On 6/30/06, Wim R. Crols <[EMAIL PROTECTED]> wrote: Hi, Not really a request for help, but I was wondering if you guys ever use the 's' command. It's just a shortcut for 'cl', which I almost never need. Since I don't assume it was put in to be complete or something, I'm intrigued by it's enigmatic purpose. :) Thanks, Wim
Re: Funcref and script local functions
Ok. For starters, it seems that you *can* call a numbered function
from anywhere:
function! s:T()
echomsg "here"
echomsg 'SID=' . expand( '' )
endfunction
let F=function('s:T')
echomsg F()
let F1 = function( '66_T' )
echomsg F1()
echomsg string( F )
let s:dict = {}
function s:dict.init() dict
echomsg "in dict function"
endfunction
unlet! F2
let F2 = s:dict.init
call call(F2,[],{})
" Note: F2 is a global, so the numbered function declared for a local dict
" is available to call globally.
On 6/29/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
When Funcref's were introduced in Vim7, I expected them to work for
script-local functions, across scripts. The documentation didn't say
that, but it didn't say that it wouldn't either, and I thought that that
is one of its biggest uses (other than the actual intended
functionality, which is for implementing numbered functions). However, I
found that the Funcref references for such functions can't actually be
passed out to other scripts. This reduces the usefulness of this feature
as we can't register private functions to receive callbacks from other
scripts.
What is weird is that the the Funcref() actually behaves exactly like
the function name itself. Say you have a function called s:T() and say
the script id is 60. The Funcref obtained via function('s:T') can't be
called from outside the script, but if the Funcref is obtained using
function('60_T'), then it will be fine. Also, a Funcref obtained
using these two methods will not be to the same object, though you would
expect them to be. The below echoes 0:
echomsg function('s:T') is function('60_T')
where as the below echoes 1:
echomsg function('s:T') is function('s:T')
In this case you are *not* creating numbered functions, so the string
value you use is what gets stored.
The above two facts make Funcref counter-intuitive to understand. I
actually wonder why even a special function called function() was
required to obtain the Funcref in the first place (unlike in Python).
There are other aspects of the new features that are very
counter-intuitive to me, whether I think in terms of Python or generic
"objects" in any language. The one which gets me the most is the
implicit typing of variables based on the initializer. For basic types
prior to Vim7 (integer and string), you could easily switch the value of
the variable from integer to string or vice versa, and the type() of the
variable would change, suggesting that it behaves like "duck typing" (as
per (wikipedia). But this observation can't be extended to the newer
object types, as the below will fail:
The whole auto-initialize thing is a sticky wicket as far as I see it.
I'd love to have it initialize *all* cases where a name is
references, either on RHS or LHS.
However, I don't know whether this was intended by Bram as a way to
implement type checking.
let a = {}
let a = []
If the type of value determines the type of the variable, and if we are
merely dealing with references (assigning references instead of copying
objects), then why should the second statement above generate the below
error?
E706: Variable type mismatch for: a
Is there a standard for this type of language behavior? I didn't find
anything at this page: http://en.wikipedia.org/wiki/Dynamically_typed
I declare all my script variables before they are used, and it hurts me
for the fact that you have to create an empty array or hash such that
these variable types are established correctly. But when it comes to a
Funcref type, it is lousy that you have to initialize the variable with
the Funcref of some random function so that the type of variable gets
established as Funcref.
I'm not sure I see the problem in practice. The only time you'd have
to pre-define a funcref variable would be if you intended to try to
use it when it was empty. Are you really doing this?
I don't know if what I say above makes sense to anyone (I never studied
computer science, so these are based on what you could call as common
sense of a software developer :), or if anything can be done about them
now, but at least I thought I will give some feedback on what has been
bothering me.
--
Thank you,
Hari
Re: How to replace CR with LF
See Vim tip #1266: http://www.vim.org/tips/tip.php?tip_id=1266 Note that Vim isn't replaced 'wrong' \r with 'correct' \r. It is replacing it with a linebreak, which is then interpreted as a \n for unix and a \r\n for dos by the s/// command. It is just one of many odd cases. On 6/27/06, Kai Weber <[EMAIL PROTECTED]> wrote: * Michael Naumann <[EMAIL PROTECTED]>: >> I'm curious though - is there any way to substitute CR with LF using >> regexp's? > > Yes there is, strange as it may seem: > > s/\r/\r/ > > does it Can somebody enlighten me why this works? Does vim replace "wrong" \r with corrent \r? Kai -- * http://www.glorybox.de/ PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC D9C2 E6B5 448C 594D 4132
Re: Man command not working with Vim 7
This $ vim -u NONE :runtime ftplugin/man.vim :Man cvs worked for me, and :r! man cvs | col -b failed with my normal .vimrc , so I tracked it down to needing: set shellxquote=\" The backslash is required. I had shellxquote=' for other situations. I seems like I've got some shell commands which require different settings :-(
Re: Man command not working with Vim 7
On 6/26/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: Eric Arnold wrote: > I was having some problems getting manpageview to work on Windows: Thank you for the feedback! I'll look into it (I hope) later on my WinXP machine. Do you use cygwin? Yes.
Re: Man command not working with Vim 7
I was having some problems getting manpageview to work on Windows: For :Man cat I got: Error detected while processing function 29_ManPageView: line 282: E485: Can't read file c:/DOCUME~1/Owner/LOCALS~1/Temp/VIo20F.tmp Error detected while processing C:/cygwin/home/Owner/vimfiles/syntax/man.vim: line 71: E174: Command already exists: add ! to replace it ***warning*** no manpage exists for I then found that a lot of the default runtime syntax scripts started failing also (i.e. ruby.vim, tcl,vim, etc.) when trying to open any .vim file. So I changed syntax/man.vim line 71 to be command! temporarily Looking at C:/tmp I see: /home/Owner/vimfiles $ ls C:/tmp/V* C:/tmp/VIo21B.tmp' C:/tmp/VIo21D.tmp' C:/tmp/VIo21F.tmp' C:/tmp/VIo21C.tmp' C:/tmp/VIo21E.tmp' C:/tmp/VIo220.tmp' I turns out I had 'shellxquote' set to ' which is causing a problem somewhere. It seems to be related to 'tempname()', but when I tried creating a file this way manually, it didn't have the problem with the trailing quote chars in the filename. Anyway, setting shellxquote to empty, I got: shell returned 1 Error detected while processing C:/cygwin/home/Owner/vimfiles/syntax/man.vim: line 87: E254: Cannot allocate color navyblue E254: Cannot allocate color navyblue I changed 'navyblue' to 'blue'. I don't know why navyblue isn't on Windows. This also fixed the above problem where errors were occuring in all the syntax files, since the delcommand Hilink wasn't getting executed because of the 'navyblue' failure. It also fixed another error when running :Man date again while the new display window was still open gave: Error detected while processing function 6_BMRemove: line9: E329: No menu "[No file] (50) " Error detected while processing C:/cygwin/home/Owner/vimfiles/syntax/man.vim: line 71: E174: Command already exists: add ! to replace it Error detected while processing function 29_ManPageView: line 338: E95: Buffer with this name already exists On 6/26/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: Trent Michael Gamblin wrote: > I'm having trouble getting the Man command working with Vim. May I suggest trying out manpageview, which implements (IMHO) an improved :Man command. Its available at: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs (see "Man Page Viewer") and at: http://vim.sourceforge.net/scripts/script.php?script_id=489 Regards, Chip Campbell
Re: search '/' command
Sorry, when I said I'd put in a "plug" it was kinda pun (i.e.
plug==advertisement) :-)
It is actually a source patch (not a Vim script plugin), which is the
only real way to intercept character events.
You can get it on sourceforge,
http://www.vim.org/scripts/script.php?script_id=1541
but you'll have to be able to compile your own copy of Vim.
If you do decide to try it out, please send or post your comments, so that
1) I can improve on it,
2) third party feedback is one element for such source patches ever
becoming part of the released Vim version.
P.S. Instead of unsubscribing, you might see if your mail system has
the option of filtering all the vim@vim.org mail into a subfolder.
On 6/26/06, Jason Frerich <[EMAIL PROTECTED]> wrote:
Eric and Hari,
Thanks for the help. I was taking this on as a side project and this is
my first experience programming vim. Hari, I haven't had time to
implement your method and Eric, I'll be awaiting your plug. Could
either of you email me directly with any updates? I just subscribed to
vim.org and I am getting way too much mail for my taste! I am going to
unsubscribe until I have further questions.
Thank you very much,
Jason
Eric Arnold wrote:
> I'll put in a plug for my GetChar event patch, which would allow this :-)
>
>
>
> On 6/22/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
>
>>
>> On Thu, 22 Jun 2006 at 5:36pm, Jason Frerich wrote:
>>
>> > How can I tell the search '/' command to perform a task after typing
>> > each letter on the pattern line.
>> >
>> > For Example:
>> > /g0ee
>> > I would like the above to execute as the following:
>> > /g - sendcommand(g)
>> > 0 - sendcommand(g0)
>> > e - sendcommand(g0e)
>> > e - sendcommand(g0ee)
>> >
>> > After each letter is typed, I would like to send that letter(s) to a
>> > function call "sendcommand".
>> >
>> > Jason
>>
>> I can't think of a simple way to capture all keys without mapping all
>> possible keys, something like:
>>
>> for ch in range(32, 126)
>> exec 'nnoremap ' nr2char(ch) 'sendcommand('.nr2char(ch).')'
>> endfor
>>
>> Inside sendcommand() you should check the mode, something like:
>>
>> function sendcommand(ch)
>> if getcmdtype() == '/'
>> " do something
>> endif
>> return a:ch
>> endfunction
>>
>> If this is not acceptable to you, you can map / to trigger your function
>> which will read the keys using getchar(). You will have to implement at
>> least a sub set of editing mode keys. Take a look at my execmap.vim
>> plugin that does this.
>>
>> --
>> HTH,
>> Hari
>>
>> __
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>
Re: search '/' command
I'll put in a plug for my GetChar event patch, which would allow this :-)
On 6/22/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
On Thu, 22 Jun 2006 at 5:36pm, Jason Frerich wrote:
> How can I tell the search '/' command to perform a task after typing
> each letter on the pattern line.
>
> For Example:
> /g0ee
> I would like the above to execute as the following:
> /g - sendcommand(g)
> 0 - sendcommand(g0)
> e - sendcommand(g0e)
> e - sendcommand(g0ee)
>
> After each letter is typed, I would like to send that letter(s) to a
> function call "sendcommand".
>
> Jason
I can't think of a simple way to capture all keys without mapping all
possible keys, something like:
for ch in range(32, 126)
exec 'nnoremap ' nr2char(ch) 'sendcommand('.nr2char(ch).')'
endfor
Inside sendcommand() you should check the mode, something like:
function sendcommand(ch)
if getcmdtype() == '/'
" do something
endif
return a:ch
endfunction
If this is not acceptable to you, you can map / to trigger your function
which will read the keys using getchar(). You will have to implement at
least a sub set of editing mode keys. Take a look at my execmap.vim
plugin that does this.
--
HTH,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Undo Branches
The main thing to understand is that it isn't really a true tree. What it does is allow you to add in new undo sequences from a given point. You will notice that if you press g- or g+ until it stops, you will always see all changes, in the order that you made them, not necessarily in some order that relates to a hierarchy. On 6/22/06, Vigil <[EMAIL PROTECTED]> wrote: Please help me understand the new undo branches in vim 7. As I understand it, you can make some changes to a file, undo half of them, make a minor change, then redo the recently undone changes, in effect, rewriting history. Firstly, I don't understand g-. I know it is meant to take you back to the previous text state, but from the example in undo.txt, pressing g- three times ends in " two three", even though the third last text state was "one two three" - 'You are now back in the first undo branch, after deleting "one".'. Well, as I remember it, the last thing I did before pressing g- for the first time was bring back that "one" into existance, so I would be expecting to be back at the state I was in before pressing the first g-, which would be "one two three", so why has g- pretended I didn't do that? Secondly, in section 32.2, and the first use of g-. Immediately beforehand, I changed "one two" to "not two". I'm told to press g- and I'm expecting to see the last state my text was in, which to me ought to be "one two", but instead it has jumped to another branch and shows "me too". It seems that subsequent presses of g- jump back and forth from one branch to the other. So, I open a 10-line file that just has "e" on each line. I go to the first line and "r0", "r1" on the second line, etc. so that the file looks like line numbers beginning at zero. If I want to undo five of the last changes, change line six from "e" to "d", then redo those undone changes, how to? I guess I just need a way to visualise how undo branches work. I couldn't find any other tutorials on this. I guess it's either too new or nobody else understands it :) -- .
Re: Bug in chaining dictionary function calls
On 6/21/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
Just wanted to add to the below that the problem is not just chaining
functions, but using the return value of the function itself. If the
function returns a dictionary (and probably a list), you can't use it to
access its members, so something like this will also fail:
let t.T()['abc'] = 'xyz'
However, using it in an expression works fine, e.g.,:
return t.T()['abc']
--
Thanks,
Hari
On Wed, 21 Jun 2006 at 3:38pm, Hari Krishna Dara wrote:
>
> I found a problem with chaining function calls through the new
> dictionary functions. Here is some code demonstrate the problem, if you
> execute this code, the last line generates an E488 error, where as the
> previous lines combines (they are equivalent) works fine.
>
> let tt = {}
> function! tt.TT()
> echomsg 'This is TT'
> endfunction
>
> let t = {'tt': tt}
> function t.T()
> return self.tt
> endfunction
>
> let tmptt = t.T()
> call tmptt.TT()
> call t.T().TT()
>
>
From: Richard Emberson <[EMAIL PROTECTED]>
To: vim-dev@vim.org
Date: May 18, 2006 4:42 PM
Subject: vim patch: fixing resetting dictionary function
Try this without the fix and you get:
ADD
n=9
Error detected while processing /home/emberson/vim/foo.vim:
line 14:
E475: Invalid argument: 1
ADD
n=9
Note that "1" is the index of the function in the dictionary.
Try it with the fix you get:
ADD
n=9
MULTIPLY
n=20
script:
let x = {}
function x.foo(a,b) dict
echo "ADD"
return a:a + a:b
endfunction
let n = x.foo(4,5)
echo "n=" . n
function! x.foo(a,b) dict
echo "MULTIPLY"
return a:a * a:b
endfunction
let n = x.foo(4,5)
echo "n=" . n
*** eval.c 2006-06-15 11:05:16.0 -0700
--- eval.c.original 2006-06-15 11:02:59.0 -0700
***
*** 18407,18435
j = 3;
else
j = 0;
- /* The name can be an index into a dictionary. */
- /* There maybe a better way, this demonstrates a fix. */
- while (arg[j] != NUL && VIM_ISDIGIT(arg[j]))
- ++j;
- if (arg[j] != NUL)
- {
- if (*arg == K_SPECIAL)
- j = 3;
- else
- j = 0;
- while (arg[j] != NUL && (j == 0 ? eval_isnamec1(arg[j])
- : eval_isnamec(arg[j])))
- ++j;
- if (arg[j] != NUL)
- emsg_funcname(_(e_invarg2), arg);
- }
- /*
while (arg[j] != NUL && (j == 0 ? eval_isnamec1(arg[j])
: eval_isnamec(arg[j])))
++j;
if (arg[j] != NUL)
emsg_funcname(_(e_invarg2), arg);
- */
}
}
--- 18407,18417
Re: Register size
On 6/21/06, Anatoli Sakhnik <[EMAIL PROTECTED]> wrote: Hello, vim users! Can anyone tell me how big a vim register is? It's very unpleasant, when I yank some piece of text in the source and can paste only part of it. Is there a restriction? No word about the subject neither in the documentation nor in the web. -- Anatoli Sakhnik I don't know of a limit within normal uses (i.e. 100K or so). How long is the text you are trying to yank?
Re: File browsing in Vim
To further stretch the use of the Ex prompt for this, try CD_Plus.vim. On 6/20/06, Nick Lo <[EMAIL PROTECTED]> wrote: Thanks Matt, I did have the feeling that I could bend Vim to my old ways, but this revelation was more about realising that I wasn't using features that make Vim different from other editors. I like the fact that it's now simpler both in terms of visual clutter and use. Also, after playing with the new tabs I found a bug where the 4 window split would disappear if I opened a few tabs and came back to the 4 windowed one. This was in fact the point where I asked ...well do I actually NEED the static file browser. Cheers, Nick > Nick, > > The article is good and illustrates a good point. However, I would > like > to point out that what you were origionally trying to do is very > possible. > > The simplest way (and there are probably others) is to make a simple > mapping that does all the stuff you describe (jump to the correct > window, jump back to the file explorer pane, and then hit "P"). You > could bind something like Alt-p () to do all that. This way you > would never have to worry about the file being opened in the wrong > window, because it's your own logic that decides the target window. > > --Matt > > On Wed, Jun 21, 2006 at 11:17:20AM +1000, Nick Lo wrote: >> After spending a frustrating evening that stretched into the night, I >> had one of those moments of revelation that I have a feeling all Vim >> users get now and again. >> >> In this case it was breaking from my previous text editor way of >> thinking to suddenly "get" the vim way of file browsing. Hardened Vim >> users will not see it as anything new as it's really about the >> using :Ex while editing rather than assigning specific windows the >> role of file browser. >> >> Anyway, since it really needed an image or two, I wrote it up here... >> >> http://www.ingredients.com.au/nick/2006/06/21/file-browsing-in-vim/ >> >> I hope that it will help others in the same boat. >> >> Comments welcome, >> >> Nick > >
Re: tabline-menu
Oh, and BTW, is :set showtabline=-0 not working?
Re: tabline-menu
On 6/20/06, Steve Hall <[EMAIL PROTECTED]> wrote: On Tue, 2006-06-20 at 07:38 -0700, Yegappan Lakshmanan wrote: > On 6/20/06, Steve Hall <[EMAIL PROTECTED]> wrote: > > > > I can't figure out how to turn off or customize the tabline menu. > > The items in the tabline menu are hard-coded in the Vim source code. > You cannot add or remove items from this menu without modifying the > source. It would be nice to be able to turn it off if it can't be customized. I don't understand. It can be completely customized via the 'tabline' option. (The issue is it bypasses buffer/window/tab management schemes that run off of autocmd events.) Please explain.
Re: vim7: redir not working inside -complete=custom function
> > If UserFileExpand() is called from custom completion function, it no > longer captures any output (this works fine in 6.3), but it works fine > if you call from command line or scripts. ... My guess is this is what he means by "broken". Well, you do give more information, but you have not explained what you mean with "is broken". What error message do you get? You may have to set the 'verbose' option to see something. You can change the commands to figure out where it goes wrong.
Re: tabline-menu
I don't think that you can remove the tabline completely, but you can change whatever you want, including returning blanks. TabLineSet.vim contains examples of how to customize it. On 6/20/06, Yegappan Lakshmanan <[EMAIL PROTECTED]> wrote: Hi Steve, On 6/20/06, Steve Hall <[EMAIL PROTECTED]> wrote: > On Thu, 2006-06-01 at 21:57 -0400, Steve Hall wrote: > > Is there a way to edit/turn off :tabline-menu? > > A re-send of this on my part, I can't figure out how to turn off or > customize the tabline menu. > The items in the tabline menu are hard-coded in the Vim source code. You cannot add or remove items from this menu without modifying the source. - Yegappan
Re: Comments/Additional Notes for scripts
I get almost zero emails on the scripts I've added. This means 1) They work perfectly 2) They are getting downloaded, but not used 3) There isn't enough immediacy to the feedback options, i.e. people more likely to respond in a forum, than take the trouble to do individual correspondance. From looking at the sourceforge help links, it looks like nothing has been done to the functionality for years. Is it true that it has gone static? On 6/18/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Jochen Baier wrote: > hi, > > > would it be possible to make a "Commments/Additional > Notes" functionallty for scripts ? Similiar to the > Additional Notes in the tips section. > > with this the feedback from the user would be better. and > the developer of the script can improve the script and would > be more motivated. > > regards jochen > > The "comments" section for vimtips is not very reliable (who goes back every day to see if his tips have got a new comment added to them?). Since vim-online scripts (unlike tips) require logging in, if you have a comment you can email the maintainer. Best regards, Tony.
Re: echon space ?
It works. Thanks. On 6/18/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Eric Arnold wrote: > Does anybody understand why trailing spaces in an "echon" string don't > actually show up? > > echon "\ngimme " > let inp = getchar() > echon nr2char(inp) It appears this is because getchar() doesn't flush the output and position the cursor. Try this patch: *** ../../vim-7.0.017/src/eval.cSat May 13 13:36:47 2006 --- eval.c Sat Jun 17 15:28:15 2006 *** *** 9792,9797 --- 9792,9801 varnumber_T n; int error = FALSE; + /* Flush any pending messages and position cursor. */ + out_flush(); + windgoto(msg_row, msg_col); + ++no_mapping; ++allow_keys; if (argvars[0].v_type == VAR_UNKNOWN) -- Why doesn't Tarzan have a beard? /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Makefile indentation with spaces for line continuation
If you want to flag errors, why not use highlighting? Actually, the makefile syntax I'm seeing already highlights correct backslashes. So, in general, you know there is an error if the code/text isn't colored right. I don't see a way to tell Vim to indent with tabs sometimes and not others. On 6/15/06, John Orr <[EMAIL PROTECTED]> wrote: Hi, I'm currently implementing a make system with GNU Make and have been trying for a while to work out how to get the indentation working as I would like it to. I believe it is reasonably standard when editing makefiles to set noexpandtab such that tabs are inserted when you start the commands under a rule, and that's great. My problem is when you have long command lines and wish to use line continuation, with the following formatting: foo.o : foo.c the command to build foo.o starts here but \ because the command is long it uses \ line continuation for readability \ and it finally ends here Note - the command starts with a tab as it must, but the continuation lines are instead indented with spaces. Why? Because if you forget a backslash requesting line continuation - or if you accidentally get a space after one (which also breaks line continuation), then by using spaces for indentation, both make, and vim, will draw your attention to it. My problem - how does one get vim to do this kind of indentation? Admittedly I'm only using vim 6.3, but the return value of the indentexpr is a number, representing a number of spaces. Your 'expandtab' setting, in combination with shiftwidths etc, seems to dictate whether that number of spaces is inserted as spaces or tabs (or tabs plus spaces). Any suggestions on how to achieve my goal? (Or, alternatively, any reasons why my goal is illogical and shouldn't be the standard way that vim works with Makefiles?) The simplest I could imagine would be if the indentexpr function could return either a number of spaces as today, or a string consisting of the actual indentation characters required - but I'd rather not go hacking vim. Thanks very much, John
Re: ***SPAM*** Problem with regexp in macro
On 6/15/06, Sylvain <[EMAIL PROTECTED]> wrote:
...
> I get a line break at the front. You don't say if you're using
> setline() or what. Both setline() and append() will use the literal
> values for \r and \n. As far as I know, the only way to get it to use
> them as line breaks is to use some form of "put" (after deleting the
> existing text, of course).
> If there's a better way, I'd like to hear it, as this has always been
> an annoyance for me also.
Yes !! You found my problem :-)
I'm using setline() function to replace the line..so I will delete it before
I add mine, it's not very elegant so if anyone has a better way, I will take
it also :-)
I'm now using lists, everywhere I can, in preference to concatinated
strings with newline separators. I usually will split() any such
strings I find into a list for easier manipulation. I think this is
satisfactorily elegant, and it sidesteps all the usual pitfalls trying
to handle line breaks manually.
> In Vim7 you have the option of giving a list to setline() and
> append() , which solves the line break ambiguity:
>
> call setline(".", [ '"", lineString ] )
>
...
Re: ***SPAM*** Problem with regexp in macro
On 6/15/06, Sylvain <[EMAIL PROTECTED]> wrote:
>
> Also, keep in mind that \n is stored as a NULL (which is the ^@) you are
> seeing.
What ? \n stored as a NULL ? I don't understand.. For me \n is 0x0A so what
you mean ?
Yes, \n when stored in a Vim variable/register/etc, is stored as a
NULL, and then translated back to a real newline under circumstances
such as "put". It's a confusing magical thing that Vim does for
legacy reasons, I think.
Try inserting a newline in insert mode, i.e. ^V^J (or ^Q^J if
you're using the mswin behavior). You will see a <00> show up.
Now do
let @a = "a" . "\n" . "b"
or
let @a = "a" . "\x0a" . "b"
and put it into the buffer using "ap or :put aYou should see
a
b
Now do:
call setline(".", @a)
you should see:
a<00>b
It's not a happy reality, but there you go :-)
Re: Bug 1492165 - Dictionary function chaining
Your example produces the result shown for me,
gt6 = {'cylinder': 6, 'manufacture': 'Triumph'}
without installing the patch. What is happening for you?
On 5/20/06, Richard Emberson <[EMAIL PROTECTED]> wrote:
Just an FYI, I've just submitted a demonstration patch
that allows one to do dictionary function chaining.
Some of you might be interested in extending the
patch to include value access via applying a key
to the results of a function (if the function returns
a dictionary).
RME
Text to bug report:
This concerns functions and dictionaries
While bug: 1491613 is a true error in the existing
code, this bug is more of an enhancement.
Currently if a function returns a dictionary, one
can not call a function on that returned dictionary
(or access a value via a key) inline:
let v = dict1.getDict2().getValue()
(
Note: the include patch does not address the following:
let v = dict1.getDict2().somekey
let v = dict1.getDict2()[somekey]
)
With this patch the following code:
XXX
"
" example of function chaining
"
let gt6 = {'cylinder': 6, 'manufacture': "Triumph" }
let twodoor = {'sunbeam': "sunbeam", 'gt6': gt6 }
function twodoor.getGt6() dict
return self.gt6
endfunction
let fourdoor = {'stationwagon': "stationwagon", 'sedan': "sedan" }
let cars = {'twodoor': twodoor, 'fourdoor': fourdoor }
function cars.getTwodoor() dict
return self.twodoor
endfunction
function cars.getFourdoor() dict
return self.fourdoor
endfunction
let pickup = {'ford': "Ford", "toyota": "Toyota" }
let van = {'ford': "Ford", "gm": "GM" }
let trucks = {'pickup': pickup, "van": van }
function trucks.getPickup() dict
return self.pickup
endfunction
function trucks.getVan() dict
return self.van
endfunction
let vehicles = {'cars': cars, "trucks": trucks }
function vehicles.getCars() dict
return self.cars
endfunction
function vehicles.getTrucks() dict
return self.trucks
endfunction
echo "gt6 = " . string(vehicles.getCars().getTwodoor().getGt6())
XXX
produces the the following:
gt6 = {'cylinder': 6, 'manufacture': 'Triumph'}
The included patch is more of a demonstration of what
can be done (it also includes the patch associated with
bug 1491613). It only allows for mult-level function
chaining. In addition, I am certain that its not the
correct way to implement this feature.
--
This email message is for the sole use of the intended recipient(s) and
may contain confidential information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.
Re: ***SPAM*** Problem with regexp in macro
Vim's line endings are a bit complicated. Whether a or is
treated as a literal character or a line break depends on context.
First, what is the value of "fileformat"? This will determine whether
\n or \r\n is the standard line break.
Secondly, how are you using the "lineString" value? When I use
let lineString="\r".substitute(lineString,
let @a = lineString
put a
I get a line break at the front. You don't say if you're using
setline() or what. Both setline() and append() will use the literal
values for \r and \n. As far as I know, the only way to get it to use
them as line breaks is to use some form of "put" (after deleting the
existing text, of course).
If there's a better way, I'd like to hear it, as this has always been
an annoyance for me also.
In Vim7 you have the option of giving a list to setline() and
append() , which solves the line break ambiguity:
call setline(".", [ '"", lineString ] )
Also, keep in mind that \n is stored as a NULL (which is the ^@) you are seeing.
On 6/15/06, Sylvain <[EMAIL PROTECTED]> wrote:
Ok, thank you very much, it's works now :-)
But I have another little problem, if, always for example, I put let
lineString="\r".substitute(lineString, '\(\w\+\)\(\s\+\)\(\w\+\)','\3\2\1',
'g') or change the \r by \n or \r\n or \n\r (always between double quote
;-)) Vim add ^M or ^@
Note : always in a function, not a map with a single line
Thanks
- Original Message -
From: "Yakov Lerner" <[EMAIL PROTECTED]>
To: "Sylvain" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, June 15, 2006 3:39 PM
Subject: Re: ***SPAM*** Problem with regexp in macro
> On 6/15/06, Sylvain <[EMAIL PROTECTED]> wrote:
>> For example, consider this regexp :
>>
>> s:\(\w\+\)\(\s\+\)\(\w\+\):\3\2\1:
>>
>> It swap 2 first words on a line, if we test it, it's works..
>>
>> Now I want to make a function to do this job so I put in my .vimrc :
>>
>> map :call Swap2Words()
>>
>> function! Swap2Words()
>> let lineNumber=line(".")
>> let lineString=getline(lineNumber)
>> let lineString=substitute(lineString, "\(\w\+\)\(\s\+\)\(\w\+\)",
>> "\3\2\1", "g")
>
> You need single quotes here (apostrophes '...') not double quotes.
> Double quotes srew the backslashes inside. SIngle quotes
> preserve backslashes which is what you want.
>
> Yakov
>
Re: ***SPAM*** Problem with regexp in macro
> let lineString=substitute(lineString, "\(\w\+\)\(\s\+\)\(\w\+\)", > "\3\2\1", "g") BTW, here's another trick (I've become a \v convert :-) let lineString=substitute(lineString, '\v(\w+)(\s+)(\w+)',
reltime() low part incorrect in win32?
I'm trying to understand what I'm seeing with the msec timing on win32
(cygwin). Inside the debugger, I'm seeing:
(gdb) p tm_delta
$1 = {u = {LowPart = 2434313347, HighPart = 896}, {LowPart = 2434313347,
HighPart = 896}, QuadPart = 3850725010563}
(gdb) n
180 n1 = tm_delta.HighPart;
(gdb)
181 n2 = tm_delta.LowPart;
(gdb) p n1
$4 = 895
(gdb) p n2
$2 = -1860653949
And in Vim:
:echo reltime()
[895, -162159878]
So is this a bug? Internally, the low part of theproftime_T
structure is positive, and it shows up externally as negative. I
checked, and as far as I can tell, the LowPart is a win32
LARGE_INTEGER, which is 8 bytes, which is trying to be stuffed into a
"long" which is 4 bytes. I think the right answer is a "double", but
I'm not real sure about how win32 stuff works (since WhyTF has it
defined a special LARGE_INTEGER type?).
I don't know about unix, but it might have the same problem if
tv_usec is a double.
P.S. "profile_cmp()" is returning an "int" instead of a "double",
so it's wonky also.
Re: syntax region question
Just a suggestion: the C syntax knows enough to color
#if 0
...
#endif
as a comment. You can look at how it does that.
It's easy to do if you don't have anything nested inside the if block.
I.e. something like
syntax match comment /if\s*(\s*0\s*)\s*{[^}]\_*}/
Otherwise, it gets more complicated, and I haven't figured that out yet.
On 6/7/06, Robert Hicks <[EMAIL PROTECTED]> wrote:
In Tcl if you do this:
if {0} {
Other code you want to comment
out is in here.
}
That if statement works just like a multi-line comment (i.e. /* */ ) in
other languages.
Is it possible to color that the same way as a comment?
:Robert
Re: any way to keep buffers confined to a tab?
It would be possible to create a buffer variable holding the tab number, and an autocommand+func could keep it from showing by immediately closing it, but I think you've got more difficulties if you want :bn to work. If you know that it's what you want, you could do the autocommand so that it does a :bn instead of closing. On 6/4/06, Denis Perelyubskiy <[EMAIL PROTECTED]> wrote: Hello, Is there any way to configure tabs so that any buffer you open in it is only visible in that particular tab? This would imply that when one cycles through buffers with :bn/:bp only the buffers that are 'tied' to the tab you are in show up? Thanks, denis -- // mailto: Denis Perelyubskiy // icq : 12359698
Re: problem (expanded): undo/redo messages often immediately hidden
On 6/2/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Eric Arnold wrote: > Have you tried resizing your command line: > > :set cmdheight=10 > I have, and I still see the problem. Have you tried reproducing it? I could, with no problem. Yes, I see it now. It only seems to happen with 'O", not 'i', etc. I see a little flash on the command line, so it seems that it does write it to the command line, and then something overwrites/clears it. I also am having problems with the 'u' and '^R' undo/redo. It isn't doing what I expected. If I enter a b c and replace 'c' with 'x', and undo, and replace 'a' with 'x', and try to undo/redo/undo/redo, and I sometimes get 'a' and 'x' switching, but sometimes I get a when I type 'u', kinda like it did 2 undo's, instead of the expected x b c Maybe I don't understand undo/redo, but it doesn't happen in my usual 'gvim' without -u NONE P.S. :set report=0 doesn't seem to change anything.
Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)
On 6/2/06, Mun Johl <[EMAIL PROTECTED]> wrote: Hi Eric, Please see my comments below. On Fri, Jun 02, 2006 at 03:22 PM PDT, Eric Arnold wrote: EA> Ok. So we know three things: EA> EA> The incremental search feature EA> + the gvim/gui input method EA> + the statusline EA> EA> It would be interesting to try: EA> EA> :feedkeys( "/3\", "t") I'll look into this further over the weekend, but when I tried to execute the :feedkeys command you suggested, I receive E492: E492: Not an editor command: feedkeys(...) EA> ^R=some expression I don't understand what you want me to try with the ^R command above. Sorry. I meant :call feedkeys( "/3\", "t") About ^R, you can type ^R in search/etc mode, and there are several things you can do from that point. See :h i_CTRL-R In the above case, ^R= should put you into "expression evaluation" mode, and you can type any expression, or your test string: aabbccddeeff
Re: problem (expanded): undo/redo messages often immediately hidden
Have you tried resizing your command line: :set cmdheight=10 On 6/2/06, Maciej Kalisiak <[EMAIL PROTECTED]> wrote: I've created a seperate thread for this issue, even though I discussed it briefly earlier, as I've done some testing and it seems this may be a Vim bug. NOTES - using Vim 7.0, downloaded and installed about 2 days ago - running under WinXP SP2 STEPS TO REPRODUCE - fire up "gvim -u NONE -U NONE" - :e foo.txt (actually any file seems to work, regardless of filetype) - press O to open a new line at top of file - type in a single line of gibberish without Enter - hit Esc - press u to undo At this point I should be seeing a diagnostic message in the message line at the bottom, something of the sort "1 more line; after #1 15:17:56", yet I see none. But if I do :messages, it is present. This has been a general problem I've been seeing, undo/redo messages which are not being displayed, or what is more likely, they are being displayed for a split second and then immediately being cleared or over-written (I do occasionally see the message briefly blink before disappearing). This seems to plague predominently single-line changes, like in case above, but it is possible I've seen it at other times too. It is hard to nail down when this does and does not happen. Any fixes or workarounds for this? Can others reproduce this? It's really a minor issue, but it's one of those that, once you notice it happening, it starts driving you mad...
Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)
Ok. So we know three things: The incremental search feature + the gvim/gui input method + the statusline It would be interesting to try: :feedkeys( "/3\", "t") ^R=some expression this will tell us if the problem is in the "get char from use" vs the "process char with incsearch". On 6/2/06, Mun Johl <[EMAIL PROTECTED]> wrote: Hi Eric, Please see my comments below. On Fri, Jun 02, 2006 at 10:42 AM PDT, Eric Arnold wrote: EA> On 6/2/06, Mun Johl <[EMAIL PROTECTED]> wrote: EA> >Hi, EA> > EA> >After taking a couple of helpful hints from Eric, and doing a bunch of EA> >experiments, I have isolated some odd behavior to 'laststatus'. EA> > EA> >As a reminder, this issue only shows up when I compile vim7 using GTK-1; EA> >it does not occur when I compile with Motif or GTK-2. My system is a EA> >Sun workstation running Solaris 8 and I use gcc 3.3.2 for compilation. EA> EA> Have you tried both gvim and vim via an xterm? Note that I am no longer going through Exceed; rather I'm running right on my Sun box. So on my Sun box I have tried running vim within my dtterm. As expected, there is no problem when running vim within the dtterm. EA> >The problem is that when I compile vim7 using GTK-1, certain characters EA> >need to be typed twice on the _search_ line. Note that it only appears EA> >as if the search line is affected. Text entry and command entry don't EA> >appear to be affected. EA> EA> I forgot, are you now testing with gvim -u NONE -U NONE ? You EA> need to be sure that there aren't any plugins or mappings involved. I did try that, and I didn't see the issue after doing so. After that, I started homing in on whether it was the loading .gvimrc or .vimrc that caused the problem; and then which line(s) until I finally landed on my laststatus setting. EA> >If I set laststatus to 0 or 1, the problem goes away. If I set it to 2 EA> >again, the problem re-appears. EA> EA> Does the problem correlate to the presence or absence of the displayed EA> statusline? Yes. If 'laststatus' is 1 and I split the window, the problem shows up. But depending on what file is in the new split window, that window my not experience the problem. But if I have a "problematic" file in both split windows, they will both experience the problem. Also, the same file will not _always_ have the problem. It seems that if I set 'laststatus' to 0 or 1 and then exit and re-open the file with 'laststatus' == 2, I don't see the problem. So I guess that implies that the .viminfo file has some influence. But setting 'laststatus' to 2 and exiting/re-entering doesn't always bring the problem back. Sigh. EA> I.e. can you have 'laststatus' at '1', and have two or more windows EA> split so that a statusline is displayed. EA> EA> Do you have anything interesting in the 'statusline' option? I commented out my specific 'statusline' settings for most of the testing; so that does not seem to make a difference. EA> >This doesn't always occur either; some files edit just fine. So there EA> >is some other dependency as well it seems--but I haven't discovered that EA> >yet. But, when it does occur, changing laststatus to 0 or 1 always EA> >corrects the issue. EA> EA> EA> Is incremental search on? Yes. But, if I turn it off the problem disappears! If I turn it on again, the problem reappears. EA> Also, you could do a binary search (i.e. chop it up into chunks) on an EA> affected file to try to find out what text is triggering it. Heh, wait until you hear this... I took a file that at the time was experiencing the problem. I finally got it to the point that if the file contained the single character "3", then no problem. But if the file had two characters "3.", I'd hit the problem. Other experiments showing file contents and whether or not I saw a problem: "33" : No problem "33." : Problem "33.3" : Problem "333" : No Problem I realize there are MANY other combinations to try; but I don't have that kind of time :) EA> >Here's a sample of what I get when I type each letter in the English EA> >alphabet twice in a row (e.g.: aabbccddeeff...): EA> > EA> >abbcdeffgghijjkklmmnopqqrßtuvvww×yzz EA> > ^ EA> > | EA> > this is the greek Beta character (in case it EA> > got lost in the transmission) EA> > EA> >Notice how some characters only show up once, and the one greek EA> >character. EA> EA> EA> Too weird. Agreed. -- Mun
Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)
On 6/2/06, Karl Guertin <[EMAIL PROTECTED]> wrote: On 6/2/06, Mun Johl <[EMAIL PROTECTED]> wrote: > abbcdeffgghijjkklmmnopqqrßtuvvww×yzz > ^ > | > this is the greek Beta character (in case it > got lost in the transmission) > That's not a beta, that's a german double s (forget what it's called). scharfes s
Re: timestamp shown after undo/redo: more info?
On 6/2/06, Maciej Kalisiak <[EMAIL PROTECTED]> wrote: On 02/06/06, Eric Arnold <[EMAIL PROTECTED]> wrote: > :help undo.txt > > :help undolist > > It's just how long ago that particular change was recorded. Alas, these don't answer my conundrum: it is unclear to me whether this is a relative or absolute time stamp (i.e., is "12:00:00" referring to twelve hours ago, or to noon?). It seems to be absolute usually, but sometimes it is relative... I think I've seen "5 seconds ago" once. How can I tell? It's wall clock time when it reaches the hh:mm:ss format. Try it. Make a change, and watch it (i.e keep typing :undolist). The other problem I'm trying to debug is that I only get the undo/redo diagnostic message (i.e., "1 change; before #121 12:37:40") sometimes... other times the status line stays blank. Or I suspect it does show the message but then immediately erases it, as occasionally if I do "undo"/"redo" back and forth quickly a whole bunch of times, I can see the message appearing faintly for a split second, between the blank status line conditions. Hence I was hoping to find some documentation on when this diagnostic is *supposed* to appear... :h messages Those messages should be in the message cache.
Re: timestamp shown after undo/redo: more info?
:help undo.txt :help undolist It's just how long ago that particular change was recorded. On 6/2/06, Maciej Kalisiak <[EMAIL PROTECTED]> wrote: Could someone point me towards any documentation on the meaning of the timestamp/text shown after some undos/redos in Vim 7? I mean the stuff in the statusline, such as 1 change; before #121 12:37:40
Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)
On 6/2/06, Mun Johl <[EMAIL PROTECTED]> wrote: Hi, After taking a couple of helpful hints from Eric, and doing a bunch of experiments, I have isolated some odd behavior to 'laststatus'. As a reminder, this issue only shows up when I compile vim7 using GTK-1; it does not occur when I compile with Motif or GTK-2. My system is a Sun workstation running Solaris 8 and I use gcc 3.3.2 for compilation. Have you tried both gvim and vim via an xterm? The problem is that when I compile vim7 using GTK-1, certain characters need to be typed twice on the _search_ line. Note that it only appears as if the search line is affected. Text entry and command entry don't appear to be affected. I forgot, are you now testing with gvim -u NONE -U NONE ? You need to be sure that there aren't any plugins or mappings involved. If I set laststatus to 0 or 1, the problem goes away. If I set it to 2 again, the problem re-appears. Does the problem correlate to the presence or absence of the displayed statusline? I.e. can you have 'laststatus' at '1', and have two or more windows split so that a statusline is displayed. Do you have anything interesting in the 'statusline' option? This doesn't always occur either; some files edit just fine. So there is some other dependency as well it seems--but I haven't discovered that yet. But, when it does occur, changing laststatus to 0 or 1 always corrects the issue. Is incremental search on? Also, you could do a binary search (i.e. chop it up into chunks) on an affected file to try to find out what text is triggering it. Here's a sample of what I get when I type each letter in the English alphabet twice in a row (e.g.: aabbccddeeff...): abbcdeffgghijjkklmmnopqqrßtuvvww×yzz ^ | this is the greek Beta character (in case it got lost in the transmission) Notice how some characters only show up once, and the one greek character. Too weird. Any insights would be appreciated. Regards, -- Mun
Re: Reassigning F keys in eVim
Try importing via a file sourced by -S On 6/1/06, John R. Culleton <[EMAIL PROTECTED]> wrote: I want to create a special application for MSWin machines that works somewhat as follows: When clicked a .bat file calls evim with a script or whatever that adds certain F key functions, e.g., F3 activates an external program. The equivalent map command would be imap :!pdftex book.texa ..or something like that. When F3 is pressed we drop out of insert mode temporarily and then execute an external command, returning to insert mode thereafter. When I try to import such a string it just gets added to the file as text. A special _gvimrc file is not an attractive option because of difficulties in placement on someone else's computer. Unfortunately Vim does not look in the current directory for a _gvimrc file. -- John Culleton
Re: Inevitable VIM plug-in for eclipse?
I don't know much about eclipse. Does it allow you to embed your own editor as the default editing window? On 6/1/06, Furash Gary <[EMAIL PROTECTED]> wrote: As much as I love vim (write school papers, do meeting notes, program), in the software side of the world everything seems to be going eclipse. Particularly as you have these complex software "frameworks," and eclipse does stuff to modify them. Are there any plans as part of the main VIM project to integrate it with Eclipse? Gary Furash, MBA, PMP, Applications Manager Maricopa County Attorney's Office
Re: Loop through all lines in a file
On 6/1/06, Benji Fisher <[EMAIL PROTECTED]> wrote:
...
> let line=getline(".")
> while (strlen(line)!=0)
> "do sth. here -- construct the external command and so on
> j
> let line=getline(".")
> endwhile
Remember that a vim script (including a plugin) is a list of
commands in Command-Line (Ex) mode, not Normal mode. So that j means
:j[oin], not "move the cursor down one line." If you change "j" to "+"
it will be a step in the right direction.
D'oh. For some reason I though 'j' was a variable and jumped to a
wishful[wrong] conclusion that it was really:
exe j
which would set the line number to an incrementing index. This is
useful if you are going to use :ex commands in addition to
function calls.
let linenr = 0
while linenr < line("$")
let linenr += 1 " The += construction requires vim 7.0 .
let line = getline(linenr)
" ...
exe linenr
endwhile
Re: regex question
Sorry I wasn't clear, I wanted it to match any substring of
'directory'. I think \%[] does this (courtesy of Benji).
On 6/1/06, Cory Echols <[EMAIL PROTECTED]> wrote:
On 6/1/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> Sorry if I've got brain lock on this, but is it possible to match a
> substring like
>
> match wildmenu ;\(directory\)\{3,};
>
> such that it will match three or more substring chars of the pattern
> to match "dir" as well as "directory"? (I know the above format isn't
> this.) I know I could do it if I could use an expression, but syntax
> highlighting doesn't allow that, so I'm wondering if I can do it with
> regex alone.
>
Enclose "ectory" in another group that matches zero or one times. The
"\v" enables "very magic" mode, and the "%()" construct causes the
group to not be counted as a sub-expression:
\v(dir%(ectory)?)
Re: regex question
On 6/1/06, Benji Fisher <[EMAIL PROTECTED]> wrote:
On Thu, Jun 01, 2006 at 05:05:00AM -0600, Eric Arnold wrote:
> Sorry if I've got brain lock on this, but is it possible to match a
> substring like
>
> match wildmenu ;\(directory\)\{3,};
>
> such that it will match three or more substring chars of the pattern
> to match "dir" as well as "directory"? (I know the above format isn't
> this.) I know I could do it if I could use an expression, but syntax
> highlighting doesn't allow that, so I'm wondering if I can do it with
> regex alone.
Do you mean like /\
Real close. Turns out I think I want:
/\<\%[directory]\{1,}\>/
but it doesn't seem to recognize \{1,} and without the \< it seems to
be matching white space. The problem with \< is that it doesn't
seem to allow \<\%[.directory]
What I'm actually trying to do is walk through a list of displayed
files, highlighting each file individually (full length) (I.e via
key). The regex is because the file names are truncated to a
given length, and the remainder is wrapped down onto the next column
./ >8.3 >oaded
../TabLineSet.vim.2.0 WinWalker.zip.upl>
TabLineSet.vim.1.> WinWalker.1.2.1.zip >oaded2
>7.1.vimWinWalker.1.2.zip doc/
TabLineSet.vim.1.8 WinWalker.2.0.zip plugin/
TabLineSet.vim.1.> WinWalker.2.1.zip
>8.1 WinWalker.2.2.zip
TabLineSet.vim.1.> WinWalker.zip.upl>
After I solve the \%[ problem, I then have to see if I can deal with
the continuation segments.
Re: Loop through all lines in a file
On 6/1/06, Johannes Schwarz <[EMAIL PROTECTED]> wrote:
Hello,
I'm trying to write my first vim-plugin, but I got stucked.
I managed to execute an external command, which gives me back a list of
filenames.
You need to say exactly how you executed the command, since that will
define how the lines were acquired, whether they went from the file
into a buffer correctly, etc.
One filename per line.
For each of the filenames I want to execute another command.
I tried it with code:
let j = 1
1
let line=getline(".")
while (strlen(line)!=0)
This loop is best done comparing line(".") <= line("$")
"do sth. here -- construct the external command and so on
j
'j' is incrementing, right?
let line=getline(".")
endwhile
When I execute the code, it runns into an infinite loop, because the
lines are joined together with each loop
The infinite loop is probably due to other reasons, ie. above.
file:
text1.txt
text2.txt
text3.txt
Is the file (disk) or file loaded into a Vim buffer window?
after interrupting the loop the looks like
text1.txt text2.txt text3.txt
Not enough code examples to understand why it would be like this.
it seems j is interpreted as a J (join line) here.
And by the way, I think this is a bad solution anyway.
Can someone give me a hint how to do it in a clean way?
If it's simple enough, you can use global commands
:g/.*/commands
regex question
Sorry if I've got brain lock on this, but is it possible to match a
substring like
match wildmenu ;\(directory\)\{3,};
such that it will match three or more substring chars of the pattern
to match "dir" as well as "directory"? (I know the above format isn't
this.) I know I could do it if I could use an expression, but syntax
highlighting doesn't allow that, so I'm wondering if I can do it with
regex alone.
Re: Filter :map output
On 6/1/06, Eric Leenman <[EMAIL PROTECTED]> wrote: Hi, Is it possible to filter the :map output? For example to only show the mappings that have CTRL or I don't think so, but you can :redir into a register, put into a buffer, or use split(), filter(), etc. I don't see a way to loop through the mappings list directly from script.
Re: :vimgrep on all buffers
On 5/31/06, Yegappan Lakshmanan <[EMAIL PROTECTED]> wrote:
Hi,
On 5/31/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> How about
>
> set errorformat+=%f,%f:%m,%f:%l:%m
>
> command! -nargs=* Bufgrep silent! bufdo! g//caddexpr expand("%")
> . ":" . line(".") . ":" . getline(".")
>
> It does have a problem where it tries to open the first entry
> automatically, but it opens the line contents instead of the buffer
> name, but it does the right thing otherwise. Hmm, weird.
>
The ":caddexpr" command will not jump to the first entry.
The ":bufdo" command loads all the buffers and runs the specified
command. When the ":bufdo" command completes, the last buffer will
be displayed in the current window.
When the ":g" command completes the cursor will be positioned on the
last matching pattern.
So when you execute the ":Bufgrep" command, the cursor will be
positioned on the last matching pattern position in the last buffer.
- Yegappan
Unfortunately, what it was doing was not leaving at the last buffer,
but trying to open buffers with the names comprised of the matched
line contents.
However, I've quit that gvim process, and it won't happen in the new
gvim process, so I guess I'll deal with it if it comes back.
Re: execute macro in bufdo command
On 5/31/06, Eric Arnold <[EMAIL PROTECTED]> wrote: On 5/31/06, Johannes Schwarz <[EMAIL PROTECTED]> wrote: > Hi all, > > I recorded a macro (search for line and paste 3 lines out of the > clipboard"*p ) > > I want to execute the macro in 15 different buffers and tried it with > the bufdo - Command, without success > > :bufdo @a | update Try bufdo normal @a @a in :ex doesn't mean 'execute'. Hmm. Well, I don't think it means 'execute keystrokes', correct if wrong. > Vim prints 30 lines (every first line the filename and every second > line the search-criterium), then it waits for me pressing a key. > But nothing changed in the files. > > Does someone can give me a hint? >
Re: execute macro in bufdo command
On 5/31/06, Johannes Schwarz <[EMAIL PROTECTED]> wrote: Hi all, I recorded a macro (search for line and paste 3 lines out of the clipboard"*p ) I want to execute the macro in 15 different buffers and tried it with the bufdo - Command, without success :bufdo @a | update Try bufdo normal @a @a in :ex doesn't mean 'execute'. Vim prints 30 lines (every first line the filename and every second line the search-criterium), then it waits for me pressing a key. But nothing changed in the files. Does someone can give me a hint?
Re: :vimgrep on all buffers
On 5/31/06, Cory Echols <[EMAIL PROTECTED]> wrote:
On 5/31/06, Bernhard Leiner <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm looking for a good soultion to to search for a keyword in all open
buffers.
>
> Using the :bufdo command to search in all buffers basically does what
> I want but the output isn't very useable. Using :vimgrep on multiple
> _files_ with its output in the quickfix window is much better but
> works only on files.
>
> Sombody has an idea?
Like most vim commands, if you use '%' as the file name argument to a
vimgrep command, it will expand to the filename of the current buffer.
This means you can use:
:bufdo vimgrepadd /pattern/ %
The catch is that 'vimgrepadd' *adds* matches to the current match
list. If there's already entries in it, they'll be added to instead
of replaced. I couldn't find any command that would clear the current
:cex ''
works.
quickfix list, so I suppose you'd have to search for an unmatchable
pattern to clear it. Try 200 x's anchored at the beginning of a line
in the current buffer. Another catch is that I couldn't get :vimgrep
to accept a '|' command separator, so you have to do them in two
steps.
:vimgrep /\v^x{200}/ %
:bufdo vimgrepadd /pattern/ %
I guess you'll have to make a function instead of using "|" for
commands like this.
Re: :vimgrep on all buffers
How about
set errorformat+=%f,%f:%m,%f:%l:%m
command! -nargs=* Bufgrep silent! bufdo! g//caddexpr expand("%")
. ":" . line(".") . ":" . getline(".")
It does have a problem where it tries to open the first entry
automatically, but it opens the line contents instead of the buffer
name, but it does the right thing otherwise. Hmm, weird.
On 5/31/06, Bernhard Leiner <[EMAIL PROTECTED]> wrote:
Hi!
I'm looking for a good soultion to to search for a keyword in all open buffers.
Using the :bufdo command to search in all buffers basically does what
I want but the output isn't very useable. Using :vimgrep on multiple
_files_ with its output in the quickfix window is much better but
works only on files.
Sombody has an idea?
regards,
bernhard
Re: Detecting if I am on Windows
On 5/30/06, Robert Hicks <[EMAIL PROTECTED]> wrote:
let MSWIN = has("win16") || has("win32") || has("win64") || has("win95")
|| has("win32unix")
Is there a "windows" variable that has all these in it?
:Robert
I don't see one, but here's the invidivual ones I found in the "f_has()" code:
#ifdef WIN16
"win16",
#endif
#ifdef WIN32
"win32",
#endif
#if defined(UNIX) && (defined(__CYGWIN32__) || defined(__CYGWIN__))
"win32unix",
#endif
#ifdef WIN64
"win64",
#endif
"gui_win16",
#endif
#ifdef FEAT_GUI_W32
"gui_win32",
# ifdef FEAT_GUI_W32
else if (STRICMP(name, "gui_win32s") == 0)
n = gui_is_win32s();
#if defined(WIN3264)
else if (STRICMP(name, "win95") == 0)
n = mch_windows95();
Re: Per document dictionay modifications?
You could store the associations in a global dict variable, and use it
in the BufWinEnter. You could then store the dict var in your .vimrc,
a separate file, or let viminfo handle it.
On 5/28/06, Geoffrey Alan Washburn <[EMAIL PROTECTED]> wrote:
Gerald Lai wrote:
> Since 'spellfile' cannot be set from a modeline for security reasons,
> you can try placing something like this in your vimrc:
>
> autocmd BufWinEnter *
> \ if expand("%:t") == "myfile1.txt" |
> \ set spellfile=myspell1.latin1.add |
> \ elseif expand("%:t") == "myfile2.txt" |
> \ set spellfile=myspell2.utf-8.add|
> \ else |
> \ set spellfile= |
> \ endif |
>
Ah, this is actually a bit too heavyweight, as it would mean keeping a
rather complicated switching block in my .vimrc, that includes the full
path of every LaTeX file for which I have a dictionary. Regardless,
your suggestion reminded me that I can set a per directory .vimrc, so I
just placed one in my project directory and I seem to be set. This
isn't quite as nice as my original proposal because it means it only
works if I start vim from within that directory.
Somehow I don't see how this is any less of a security risk than
allowing what I proposed.
Re: Vim takes up to 7 seconds to run
This is often due to trying and failing to connect to the X server. Try the -X startup option. On 5/28/06, Andrea Spadaccini <[EMAIL PROTECTED]> wrote: Hello everyone, In the last two days I've been experiencing an odd problem: vim takes A LOT of time to start. My notebook is a Core Duo T2300 with 1GB RAM, I think it's enough to run vim ;) I'm using gentoo linux, and Vim 7.0: how can I try to find the problem? Please help me: it's frustrating!! Thanks in advance, -- [ Andrea Spadaccini - a.k.a. Lupino - from Catania - ICQ #: 91528290 ] [ GPG ID: 5D41ABF0 - key on keyservers - Gentoo GNU / Linux - 2.6.16 ] [ Linux Registered User 313388 - @: a.spadaccini(at)catania.linux.it ]
Re: how will a plugin know if Vim is currently starting?
You could check:
if bufnr("$") == 1 && !bufloaded(1)
this seems to be the case when it's first sourcing .vimrc, anyway.
On 5/26/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
One of my plugins was using the VimEnter autocommand to initialize some
of the values. The autocommand is added while the plugin is sourced, and
is removed when the autocommand is triggered. The problem with this
approach is that if the script is manually sourced *after* the vim
session is completely started, the autocommand will never fire. My
question is, is there a way for the plugin to detect if Vim is currently
in startup mode? I haven't found any v: variable to do this (like
v:dying), any there is no built-in function either.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: --remote-expr stdout?
Nevermind. I don't know why I thought I had to use gvim everywhere instead of a mix of gvim and vim. On 5/26/06, Eric Arnold <[EMAIL PROTECTED]> wrote: Does anybody know how to get gvim to really print the expression result from --remote-expr to stdout, as it says in the docs. I always get an "error" popup with the results (although the expression wasn't a failure, the error popup just seems to be the default).
--remote-expr stdout?
Does anybody know how to get gvim to really print the expression result from --remote-expr to stdout, as it says in the docs. I always get an "error" popup with the results (although the expression wasn't a failure, the error popup just seems to be the default).
Re: Remembering 'Fold State' across buffers
(I missed part of this thread, so sorry if this has already been mentioned). Have you checked for mode lines at the top or bottom of the files which set fold options? If there aren't any which might be confusing you, you could consider adding your own mode lines to have the folding appropriate for your different files. On 5/26/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Mark Woodward wrote: > Hi all, > > The problem I'm having is I'll open all folds in a buffer, switch > buffers, go back to the original and all folds are closed again. Is > there a way to stop this? ie Vim remembers the 'fold state' of the > buffer when I return to it? So if folds were open when I left they'll > be open when I return? Conversely if they were closed when I left > they'll be closed when I return? > > > Vim 7 > Ubuntu Dapper > > thanks, > > Well, it should be possible, but I don't know how. Recently I saw the following: Viewed one file with folds in gvim (FWIW, it was Vim 7.0.017, "huge" version with GTK2 GUI, running on SuSE Linux 9.3). Opened one fold. ":q" the file. Then came back to it. The one fold was still open. I source the vimrc_example.vim in my vimrc. (Do you?) Then if you do, maybe we have different settings or autocommands? (AFAIK, I have nothing folds-related in my vimrc, other than what might be set by the vimrc_example.vim) Best regards, Tony.
Re: Working directory problems
Try something like this:
set noshellslash
let f = 'c:\topdir\main\source\ai\somefile'
let f = expand(f)
let f =fnamemodify( f, escape( ':p:s?c:\topdir\main\source\??', '\\' ) )
This will give you the relative path, providing that the path head
remains consistent. This should strip off any pathnames it detects
from &path:
function! GetPathRelative( f )
let f = expand( a:f )
let f =fnamemodify( f, ':p', )
let longest = ''
for dir in split( &path, ',' )
let dir = expand( dir )
if stridx( f, dir ) == 0 && f != dir
if strlen( dir ) > strlen( longest )
let longest = dir
endif
endif
endfor
if longest != ''
let f = strpart( f, strlen( longest ) )
let f = substitute( f, '^[/\\]*', '', '' )
endif
return f
endfunction
let f = GetPathRelative( 'c:\topdir\main\source\ai\somefile')
echomsg f
let f = expand("%:p")
echomsg f
let f = GetPathRelative( f )
echomsg f
On 5/25/06, Max Dyckhoff <[EMAIL PROTECTED]> wrote:
I'm sorry, the script which I call basically just makes a system call:
function! SDCheckout()
let file = expand("%")
if (confirm("Checkout from Source Depot?\n\n" . file,
"&Yes\n&No", 1) == 1)
call system("sd edit " . file . " > /dev/null")
if v:shell_error == 0
set noreadonly
edit!
else
if (confirm("An error occured!", "Oh no!", 1) ==
1)
endif
endif
endif
endfunction
Sorry for the wrapping problems.
I'm not entirely sure what you are suggesting doing with :h and :s??,
but would I not suffer the problem of not knowing which subdirectory the
file was in? Surely this isn't something that should need to be fixed,
rather it should Just Work?
Thanks!
Max
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 8:10 PM
To: Max Dyckhoff
Cc: vim@vim.org
Subject: Re: Working directory problems
I'm not sure how your bound function works. Have you tried using
fnamemodify() to manipulate the filename? You can use the :h option
to strip the path, and :s?? to substitute the relative path.
On 5/24/06, Max Dyckhoff <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have some issues with the working directory in vim that I really
> cannot get to the bottom of. I have tried looking through the help,
and
> I've searched the Interweb too, to no avail, so I thought I would turn
> to this trusty mailing list!
>
> I operate a single vim instance with multiple files open in multiple
> splits. The common working directory for my code files is
> c:\\main\source\, and the majority of the files therein lie
in
> ai\. Normally the vim split status line shows the file as
> being ai\, namely the relative path from the working
directory
> of c:\\main\source\.
>
> When I open a new file - which I invariably do using "sf ",
as
> I have all the appropriate directories in my path - occasionally the
> statusline shows as the absolute path, namely
> c:\\main\source\ai\. If I perform the command "cd
> c:\\main\source", then the status line fixes itself. It
should
> be noted that the status line is only incorrect for the new file;
> existing files are still fine.
>
> Now I wouldn't normally be bothered by this, but I have a function in
> vim which I have bound to F6 that will check the current source file
out
> of our source depot, and if the status line is showing the absolute
path
> then it will fail, because the information about the source depot lies
> only within the c:\\main directories.
>
> God, I hope that makes sense. It seems like such a trivial problem,
but
> it really irks me, and I wonder if anyone could give me a hand!
>
> Cheers,
>
> Max
>
> --
> Max Dyckhoff
> AI Engineer
> Bungie Studios
>
Re: Working directory problems
I'm not sure how your bound function works. Have you tried using fnamemodify() to manipulate the filename? You can use the :h option to strip the path, and :s?? to substitute the relative path. On 5/24/06, Max Dyckhoff <[EMAIL PROTECTED]> wrote: Hi, I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\\main\source\, and the majority of the files therein lie in ai\. Normally the vim split status line shows the file as being ai\, namely the relative path from the working directory of c:\\main\source\. When I open a new file - which I invariably do using "sf ", as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\\main\source\ai\. If I perform the command "cd c:\\main\source", then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. Now I wouldn't normally be bothered by this, but I have a function in vim which I have bound to F6 that will check the current source file out of our source depot, and if the status line is showing the absolute path then it will fail, because the information about the source depot lies only within the c:\\main directories. God, I hope that makes sense. It seems like such a trivial problem, but it really irks me, and I wonder if anyone could give me a hand! Cheers, Max -- Max Dyckhoff AI Engineer Bungie Studios
Re: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed
On 5/24/06, Mun Johl <[EMAIL PROTECTED]> wrote:
Hi Eric, et al.,
Thanks for your reply.
I'm sorry for the delay in my response. I was not ignoring your reply;
rather I was trying to gather data to better answer your questions.
Please see my comments below.
On Wed, May 17, 2006 at 11:29 PM PDT, Eric Arnold wrote:
EA> It would be helpful to know more about whether any particular keys are
EA> problematic, and when you are having the trouble.
It "seems" kind of random; and because it's intermittent it's kind of
hard to isolate. Here's some new data though, I am now seeing the same
issue once in a while on my Solaris 8 system--that is, without even
running Exceed. I'm suspecting that something may be wrong with my gtk
installation or something. BTW, my GTK version is 1.2.10 .
In any case, I just saw this problem on one of my files. And it seems
to be more prevalent on the search line then when actually entering text
into the file. For example, on the search line I typed the alphabet and
here's what was echoed:
abdfgijkmoqsuvwyz
But when I inserted the alphabet into the body of the file, all
characters were present. Also, on the search line, if 'a' is not
entered as the first character, then it won't display either.
I asked the question because it sounds like the problem is either
1) something is not transmitting the key
2) something is eating the key
First of all, I'll assume that you've checked that your keyboard isn't wonky.
If the case is 2), the main culprits are usually mappings or
abbreviations which are grabbing the key for something.
If the "a" key is consistently not received except in the first
column, then you have something non-intermittent to play with.
Interestingly, I just noticed that I typically see this behavior when
the filetype is not set ("filetype="). I set the filetype=mail on the
problematic file, and the problem went away. I did not close and reopen
the file either. So I guess it's not an Exceed or GTK issue after all.
Possibly, if the problem is consistently fixed by changing the
filetype. It would be good to know what the filetype is when you are
having the problem. If it is a specific filetype, then you have a
clue. If it isn't specific, and all that's required is to switch from
any filetype to any filetype, then it's not as helpful. Though it
would indicate that something is amiss with
syntax/autocommands/mappings.
EA> Also, it isn't clear exactly how you are starting gvim, maybe because
EA> it's been a while since I've tried this. Are you starting the Win32
EA> version, and asking it to connect to the Sun X server via the Exceed X
EA> server? Or visa versa? I.e. remotely logging into one, and setting
EA> the DISPLAY to other.
In that scenario, I'd be logged in on my PC and start the Exceed X
server. Then, I'd open a terminal on my Sun box and export the terminal
to my PC. From that terminal I'd issue a vim -g command and export the
vim window to my PC.
Try starting an Xterm on the Sun, displayed to the pc, and running the
non-gui vim through the Xterm.
But--as mentioned above--I no longer believe Exceed or GTK are possible
suspects. Maybe I should be looking at my plugins or something. I'll
I still hold out the possibility that you have a flow control problem
somewhere in the stream. Since ^S / ^Q are flow control characters
for some schemes, and ^Q in Vim will eat characters (if exchanged with
^V with the mswin behavior), it is a suspect.
You could try mapping all of ^S/^Q/^V/^K to something like , and
see if that helps. (^K is the compose command).
Also, if you are using a multibyte setup, you have to consider whether
th InputManager is a problem.
at least check the filetype every time I see this issue to see if I can
find a correlation.
One thing you should try if you haven't already is
gvim -u NONE -U NONE --noplugin
which should give you a clean process to play with (annoying clean,
actually...you probably want to set nocp at least).
--
Mun
EA> In any case, it's going to be helpful to know which binary type is
EA> running where and how.
EA>
EA> Are there any other applications running at the same time? Especially gtk?
EA>
EA> If it takes it as a multi-byte character, it also suggests that
EA> something might be adding some characters into the stream, i.e. the
EA> compose ^K or literal ^V or ^Q characters. Often, ^Q is part of a
EA> stream start/stop flow control sequence.
EA>
EA> If you can try any other gtk applications to see if they work, and a
EA> different X server than Exceed, it would help you narrow the problem
EA> down.
EA>
EA>
EA> On 5/17/06, Mun Johl <[EMAIL PROTECTED]> wrote:
EA> >Hi,
EA> >
EA> >This probably isn't a gvim issue, bu
Re: rdfinable boudaries of sections, paragraphs
I haven't used them, but Vim has options for 'paragraphs' , 'options', etc. They are global, but could be set by file type. They accept NROFF syntax instead of regex, so I don't know whether that's good enough or not. On 5/24/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: vim still doesn't have redefinable (per filetype) boundaries (like, regexp) for sections, paragraphs (and other text objects and motions), correct ? Yakov
Re: Fwd: <[EMAIL PROTECTED]>
Did you see whether it was addressed to me or was sent by me? I'm having problems with my address being used in reply-to by spammers. On 5/23/06, Georg Dahn <[EMAIL PROTECTED]> wrote: Hi! This has always worked for me until now. I have tried your example and got the email. You have not missed anything, because it was just a mail with an attachment containing a virus identified as I-Worm/Mytob.C. Best wishes, Georg Eric Arnold wrote: > I can't seem to get the mailer daemon to retrieve the message number > it told me that it bounced. Has this worked for anybody? > > -- Forwarded message -- > From: Eric Arnold <[EMAIL PROTECTED]> > Date: May 23, 2006 2:07 PM > Subject: <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: How to get cygwin command line to know where it is
Try this: set shell=C:/cygwin/bin/bash let $BASH_ENV = '~/.bashrc' let &shellcmdflag='-c' On 5/23/06, Eric Arnold <[EMAIL PROTECTED]> wrote: Off hand, I can't remember the exact name, but I think that there is a special rc filename that is executed even when it isn't a login shell. On 5/23/06, Furash Gary <[EMAIL PROTECTED]> wrote: > Just tried it and ran into the problem I thought I would. Removing > login eliminates the problem of it not knowing "where it is", but it no > longer runs .profile and so on, so as a result it's missing my changes > to the path, aliases, etc. > > Hmm... > > -Original Message- > From: Gary Johnson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 23, 2006 3:14 PM > To: vim@vim.org > Subject: Re: How to get cygwin command line to know where it is > > On 2006-05-23, Furash Gary <[EMAIL PROTECTED]> wrote: > > I'm using VIM on windows with cygwin. In my _vimrc I've got the > > following > > > > " automatically swithc directories > > set autochdir > > > > " For cygwin shell > > set shell=C:/cygwin/bin/bash > > set shellcmdflag=--login\ -c > > set shellxquote=\" > > > > When I try to use cygwin stuff with the "!" command or similar things > > from vim, it doesn't seem to know where it is. > > > > That is, if I open up a file on the desktop with gvim, and do > > > > :pwd > > > > It prints out the path of the desktop (thanks to autochdir I think). > > However, if I do > > > > :! pwd > > > > It prints out the location of my windows home directory. Is there > > anyway I could automatically pass to the shell the location it should > > start in? > > The problem is the "--login" option that you included in 'shellcmdflag'. > Every shell that you execute from vim is executed as a login shell, > which means it starts in your home directory. If you just > > set shellcmdflag=-c > > instead, it should work fine. > > Why did you include "--login"? > > Gary > > -- > Gary Johnson | Agilent Technologies > [EMAIL PROTECTED] | Wireless Division > | Spokane, Washington, USA >
Re: How to get cygwin command line to know where it is
Off hand, I can't remember the exact name, but I think that there is a special rc filename that is executed even when it isn't a login shell. On 5/23/06, Furash Gary <[EMAIL PROTECTED]> wrote: Just tried it and ran into the problem I thought I would. Removing login eliminates the problem of it not knowing "where it is", but it no longer runs .profile and so on, so as a result it's missing my changes to the path, aliases, etc. Hmm... -Original Message- From: Gary Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 3:14 PM To: vim@vim.org Subject: Re: How to get cygwin command line to know where it is On 2006-05-23, Furash Gary <[EMAIL PROTECTED]> wrote: > I'm using VIM on windows with cygwin. In my _vimrc I've got the > following > > " automatically swithc directories > set autochdir > > " For cygwin shell > set shell=C:/cygwin/bin/bash > set shellcmdflag=--login\ -c > set shellxquote=\" > > When I try to use cygwin stuff with the "!" command or similar things > from vim, it doesn't seem to know where it is. > > That is, if I open up a file on the desktop with gvim, and do > > :pwd > > It prints out the path of the desktop (thanks to autochdir I think). > However, if I do > > :! pwd > > It prints out the location of my windows home directory. Is there > anyway I could automatically pass to the shell the location it should > start in? The problem is the "--login" option that you included in 'shellcmdflag'. Every shell that you execute from vim is executed as a login shell, which means it starts in your home directory. If you just set shellcmdflag=-c instead, it should work fine. Why did you include "--login"? Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: How to get cygwin command line to know where it is
This is partly due to the use of --login , which causes it to act as if it's a fresh login shell, so of course, it goes to your home directory. Try it with just -c . Without setting that, zsh and bash seem to honor $PWD, probably, which I suspect is exported by Vim.. I'm having trouble getting my rc file to print it out when started from Vim. On 5/23/06, Furash Gary <[EMAIL PROTECTED]> wrote: I'm using VIM on windows with cygwin. In my _vimrc I've got the following " automatically swithc directories set autochdir " For cygwin shell set shell=C:/cygwin/bin/bash set shellcmdflag=--login\ -c set shellxquote=\" When I try to use cygwin stuff with the "!" command or similar things from vim, it doesn't seem to know where it is. That is, if I open up a file on the desktop with gvim, and do :pwd It prints out the path of the desktop (thanks to autochdir I think). However, if I do :! pwd It prints out the location of my windows home directory. Is there anyway I could automatically pass to the shell the location it should start in?
Fwd: <[EMAIL PROTECTED]>
I can't seem to get the mailer daemon to retrieve the message number it told me that it bounced. Has this worked for anybody? -- Forwarded message -- From: Eric Arnold <[EMAIL PROTECTED]> Date: May 23, 2006 2:07 PM Subject: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
Re: Always display full path in tab?
I've just uploaded a version of TabLineSet.vim which handles the GUI tabs. On 5/18/06, Mark Volkmann <[EMAIL PROTECTED]> wrote: On 5/18/06, Scot P. Floess <[EMAIL PROTECTED]> wrote: > I have been looking through the documentation on vim (yes I even tried > using :h tabline) in an attempt to always list the full path in my > tabs. I can't see what option I need to enable so that the full path > displays. Presently if I edit a file that exists in a rather long path, > I see abbreviations in the path names (like /h/v/s/foo.bar). > > What do I need to do to enable? > > Thanks...and if this is in the documentation and I overlooked it...sorry > - I will deserve the RTFM comments ;) In all seriousness I probably > spent a good hour looking...just want the answer now :) I've also failed to find that, but I want the opposite. I only want to see file names, no abbreviated directory paths. I've been there's a plug-in to let you do this, but it only works if you use the non-GUI version. I prefer to use the GUI version. -- R. Mark Volkmann Object Computing, Inc.
Re: cmapping woes
On 5/22/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 5/22/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
Eric, this works for me:
--
cnoremap xx =getcmdpos()==1?MyFunc():'xx'
function! MyFunc()
call feedkeys(":call DoIt()\", 't')
return ''
endfu
And DoIt() is executed not in sandbox.
Does this work for you ?
Yakov
Yes, this is a better version of :
cnoremap cd =getcmdpos()==1 && getcmdtype() == ':' ? feedkeys(
"call Cd_plus()",'t' ) :'cd'
Having a in the mapping is pretty nasty :-)
I was hoping would work like that, but no go:
cnoremap cd ( getcmdpos() == 1 && getcmdtype() == ':' ?
Cd_plus_start() : 'cd' )
...which I think is due to that old issue where won't allow
nested getchar() input. However this form works:
function! Cd_plus_start()
return ":call Cd_plus()\"
endfunction
cnoremap cd ( getcmdpos() == 1 && getcmdtype() == ':' ?
Cd_plus_start() : 'cd' )
And the embedded in the return string isn't treated as a literal
in the expression, so all seems well. Go figure.
Thanks! And for your effort you've won:
One 'cd' accelerator script!:-)
CD_Plus.vim
Description: application/octetstream
Re: cmapping woes
On 5/22/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 5/22/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> On 5/21/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > On 5/22/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> > > I've been trying to map "cd" if it's the first two characters on the
> > > :ex line. I've tried all the combinations I can think of. On
> > > several of them, I seem to be getting errors as if is run in
> > > the sandbox (that dog won't hunt). The only one that works at all is
> > > the first simple mapping, but that gets painful, of course, when you
> > > want to use "cd" in a search, etc.
> > >
> > > Anybody know any good tricks?
> > >
> > >
> > > silent! cunmap cd
> > >
> > > cnoremap cd call Cd_plus()
> > >
> > > "cnoremap cd echo getcmdpos()
> > > "cnoremap cd if getcmdpos() < 3 call Cd_plus()
> > > else call feedkeys('cd','n') call setcmdpos(1) end
> > >
> > > "cnoremap cd ( getcmdpos() == 1 ? Cd_plus() : 'cd' )
> > > "cnoremap cd Cd_plus()
> > > "abbr cd Cd_plus()
> > > "silent! unabbr cd
> >
> > The following works for me:
> >
> > cnoremap cd =getcmdpos()==1?"MYCD ":'cd'
>
> This is nearly it. I'm actually trying to start a script from the
> mapping.
Can you start a script from a
function in rhs ? Like this;
No. This runs in the sandbox, and all sorts of things will fail in MyFunc().
cnoremap cd =getcmdpos()==1?MyFunc():'cd'
func! MyFunc()
... start script here ...
return ""
endfun
Yakov
Re: cmapping woes
On 5/21/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
On Sun, 21 May 2006 at 3:12pm, Eric Arnold wrote:
> I've been trying to map "cd" if it's the first two characters on the
> :ex line. I've tried all the combinations I can think of. On
> several of them, I seem to be getting errors as if is run in
> the sandbox (that dog won't hunt). The only one that works at all is
> the first simple mapping, but that gets painful, of course, when you
> want to use "cd" in a search, etc.
>
> Anybody know any good tricks?
>
>
> silent! cunmap cd
>
> cnoremap cd call Cd_plus()
>
> "cnoremap cd echo getcmdpos()
> "cnoremap cd if getcmdpos() < 3 call Cd_plus()
> else call feedkeys('cd','n') call setcmdpos(1) end
>
> "cnoremap cd ( getcmdpos() == 1 ? Cd_plus() : 'cd' )
> "cnoremap cd Cd_plus()
> "abbr cd Cd_plus()
> "silent! unabbr cd
You should use the new option and check if you are in the start
seems to be evaluated in the sandbox as with =, I report
with sadness...
of the command from the function. You can then return "cd" or whatever
else you want. I have actually needed this same functionality for
myself, and created a plugin called cmdalias.vim. This was very
complicated to do prior to 7.0, but with the new feature in 7.0,
it became a very simple plugin. Never the less, it is available at:
http://www.vim.org/script.php?script_id=745
--
HTH,
Hari
Re: cmapping woes
On 5/21/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 5/22/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> I've been trying to map "cd" if it's the first two characters on the
> :ex line. I've tried all the combinations I can think of. On
> several of them, I seem to be getting errors as if is run in
> the sandbox (that dog won't hunt). The only one that works at all is
> the first simple mapping, but that gets painful, of course, when you
> want to use "cd" in a search, etc.
>
> Anybody know any good tricks?
>
>
> silent! cunmap cd
>
> cnoremap cd call Cd_plus()
>
> "cnoremap cd echo getcmdpos()
> "cnoremap cd if getcmdpos() < 3 call Cd_plus()
> else call feedkeys('cd','n') call setcmdpos(1) end
>
> "cnoremap cd ( getcmdpos() == 1 ? Cd_plus() : 'cd' )
> "cnoremap cd Cd_plus()
> "abbr cd Cd_plus()
> "silent! unabbr cd
The following works for me:
cnoremap cd =getcmdpos()==1?"MYCD ":'cd'
This is nearly it. I'm actually trying to start a script from the
mapping. This starts "MYCD", but interfers with 'cd'
cnoremap cd =getcmdpos()==1 ? "MYCD " :'cd'
I tried adding a CR inside the = expression after MYCD, but it
seems that any control chars returned from an expression are escaped
as literals i.e. you see
:MYCD<0d>
show up as the result.
I can't run the script directly from inside the = expression
because of the sandbox restrictions.
This seems to be the only thing that works:
cnoremap cd =getcmdpos()==1 && getcmdtype() == ':' ? feedkeys(
"call Cd_plus()",'t' ) :'cd'
Oddly, "feedkeys()" doesn't seem to work if is used instead of =
This would all be s much simpler without the sandbox. There
should be a way to bypass it.
Notes
1. Don't use on cabbrev (doesn't work, documented somewhere).
on cmap sometimes doesn't work, too.
Yeh, I noticed it seems to inhibit the display of the replaced string.
2. I think you're better off making your
own cd :command not just function.
Yakov
cmapping woes
I've been trying to map "cd" if it's the first two characters on the
:ex line. I've tried all the combinations I can think of. On
several of them, I seem to be getting errors as if is run in
the sandbox (that dog won't hunt). The only one that works at all is
the first simple mapping, but that gets painful, of course, when you
want to use "cd" in a search, etc.
Anybody know any good tricks?
silent! cunmap cd
cnoremap cd call Cd_plus()
"cnoremap cd echo getcmdpos()
"cnoremap cd if getcmdpos() < 3 call Cd_plus()
else call feedkeys('cd','n') call setcmdpos(1) end
"cnoremap cd ( getcmdpos() == 1 ? Cd_plus() : 'cd' )
"cnoremap cd Cd_plus()
"abbr cd Cd_plus()
"silent! unabbr cd
Re: folding lines at the top of file
On 5/21/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: I want to fold lines grouped at the top of file and matching some pattern. I use foldmethod=expr. But vim does not behave as expected. In the testcase, /a/. In the testfile (2) below, I want first 3 lines (a\na\na\n) folded, and nothing else folded. But vim also folds the last a\na\n lines. I think this is vim bug. Yakov - (1) the code :set foldmethod=expr foldenable foldexpr=Foo() function! Foo() echomsg '>>'.v:lnum.(v:lnum>1 ? ' prev='.foldlevel(v:lnum-1) : '') if v:lnum>1 && foldlevel(v:lnum-1) == 0 return 0 else return getline(v:lnum) =~ 'a' endif endfun (2) the testfile is --- a a a b b b a a --- Well, I'm not entirely sure what is supposed to be happening from looking at the docs, but this works: function! Foo() echomsg '>>'.v:lnum.(v:lnum>1 ? ' prev='.foldlevel(v:lnum-1) : '') . ', foldlevel=' . foldlevel(v:lnum - 1 ) if (v:lnum>1 )&& (foldlevel(v:lnum-1) == -1) echomsg 'returning 0' return 0 else echomsg 'returing ' . (getline(v:lnum) =~ 'a') return getline(v:lnum) =~ 'a' endif endfun If you just print out the value of foldlevel(v:lnum-1), you'll find it's always -1 for unfolded lines in your test case. It seems that the foldlevel isn't 0 when you think it is, and I'm not sure whether that is right or wrong. The docs say As a special case the level of the previous line is usually available. "usually available" is kinda hard to deal with.
Re: search next, prev while in /pattern editing
On 5/18/06, Eric Arnold <[EMAIL PROTECTED]> wrote: I think this does what you want. You only need to use "/", though, since you can now go up and down while in "/" : cmap N:redraw/ cmap n:redraw/ Rats. This works only if you set the @/ variable first by hitting return normally, which will highlight the pattern, then subsequence ^X or ^Y will move to the right pattern. Benji's simple example has the same problem if you start with These come close, but the first time you use them, they do something slightly different than subsequent times. ^R go up *2* matches, and ^S just goes to what looks like the current match (i.e. it doesn't appear to move). It's all a problem of where the cursor actually is v.s. where the highlighting is for incsearch. cmap NN:redraw/ cmap :redraw/
Re: search next, prev while in /pattern editing
I think this does what you want. You only need to use "/", though, since you can now go up and down while in "/" : cmap N:redraw/ cmap n:redraw/
Re: clearing the command line
On 5/18/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 5/18/06, Eric Arnold <[EMAIL PROTECTED]> wrote: > I''ve been chasing this for a while, so I might as well ask, even > though it seems like a stupid question. What's the right way to clear > the command line between echo blocks in a script, without causing a > full screen redraw? > > Everything I try eventually fails when the command line has been > scrolled/grown upwards by output longer than cmdheight. I can't see > the exact rule, since some things like: > > echo : > > normal : > > etc., come close, but no cigar. When output was longer than cmdheight, if you look at the sceen contents and the statusline in this situation, you'll see it's shifted upward in a manner that never happens during editing, essentially screen is corrupted. That's why I think redraw is the only way out of this. Yakov That's true in some, but not all cases, which is what gives me any hope. For example, let &cmdheight = 1 exe "normal :echo\" let &cmdheight = s:tmp_cmdheight works when the statusbar has been pushed up a small number of lines. It seems to know how to recover without a full redraw. If it gets pushed up even more, then it fails to clear. The command also doesn't reflect the pushed position of the statusline, so there's no way to put a case for it in the script that way.
clearing the command line
I''ve been chasing this for a while, so I might as well ask, even though it seems like a stupid question. What's the right way to clear the command line between echo blocks in a script, without causing a full screen redraw? Everything I try eventually fails when the command line has been scrolled/grown upwards by output longer than cmdheight. I can't see the exact rule, since some things like: echo : normal : etc., come close, but no cigar.
Re: search next, prev while in /pattern editing
cmap n/ On 5/18/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: I am using incsearch. I wanted to define 2 mappings that act while I am in /search pattern editing mode, and that take me to next/prev match while leaving the cursor in /pattern commandline. Is it possible ? Yakov
Re: ctrl+shift key mappings
Thanks. Now I've got some good multi-bytes to multi-chew on :-) On 5/18/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Eric Arnold wrote: > Hey. Do you know any simple key sequence to test whether code I'm > adding to Vim is handling mbytes correctly? Unfortunately, even if I > got Japanese installed, I've forgotten the few Kanji I knew :-P > > > if &termencoding == "" let &termencoding = &encoding endif set encoding=utf-8 setglobal bomb enew then set Insert mode and start adding characters. See :help i_CTRL-V_digit :help ga :help g8 If you want a sample UTF-8 file with various multibyte characters in it, you may download my front page http://users.skynet.be/antoine.mechelynck/index.htm (browse to it with any browser then "File -> Save As" or similar). Best regards, Tony. P.S. For that kind of questions, it is usually better to send them to the list (so everyone can reply) rather than privately to one person.
Re: Indentations - possible Vim7 bug
What's the value of your 'paste' option? On 5/18/06, Dan Clarke <[EMAIL PROTECTED]> wrote: Hi. I've just installed Vim 7. l use MS Windows. I've found a problems with the indentations. You can replicate it by doing the following ... - Copy a whole word into the clipboard. - In a C/C++ file, position the cursor on a line of text that is indented. - Press the 'o' key to go onto the next line in insert mode. - (The next line should automatically be indented to match the previous line). - Now press control-v to paste the word from the clipboard. In previous versions of Vim this pasted word would of appeared indented. In Vim7, for some reason the auto indentation seems to of been deleted. Thanks, - Dan
Re: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed
It would be helpful to know more about whether any particular keys are problematic, and when you are having the trouble. Also, it isn't clear exactly how you are starting gvim, maybe because it's been a while since I've tried this. Are you starting the Win32 version, and asking it to connect to the Sun X server via the Exceed X server? Or visa versa? I.e. remotely logging into one, and setting the DISPLAY to other. In any case, it's going to be helpful to know which binary type is running where and how. Are there any other applications running at the same time? Especially gtk? If it takes it as a multi-byte character, it also suggests that something might be adding some characters into the stream, i.e. the compose ^K or literal ^V or ^Q characters. Often, ^Q is part of a stream start/stop flow control sequence. If you can try any other gtk applications to see if they work, and a different X server than Exceed, it would help you narrow the problem down. On 5/17/06, Mun Johl <[EMAIL PROTECTED]> wrote: Hi, This probably isn't a gvim issue, but I thought I'd ask the community for input since other avenues have not yet yielded positive results. Here's the issue: I am using Hummingbird Exceed 2006 to log into my Sun Sparc Solaris 8 system. From there, I am opening a gvim window which was compiled using the gtk libraries. On the Solaris system, it works fine. But when using gvim through exceed, I get an odd behavior: I often have to enter each character twice in order for it to show up in the window. And sometimes gvim will take that as a multi-bye character. I don't know if this is a gvim issue, Exceed issue, gtk issue, or what; but since the application works fine on the Solaris system itself, I thought blaming Exceed would be the logical choice. But I have not yet been able to give Hummingbird sufficient data to track down the problem. Also note that if I compile gvim using Motif libraries instead of gtk, then a gvim window opened through Exceed works correctly. Anyone ever see anything like this? Or have any ideas towards a solution? Thanks in advance. Best regards, -- Mun
Re: is there any method to input chinese under cygwin console window?
On 5/17/06, hj <[EMAIL PROTECTED]> wrote:
I find that the only method to input chinese in vim on a windows box is using
gvim. And after pressing the ESCAPE switch to command mode, I must switch the
input method into English. It is not so convenient. Is there any method to
solve these problems?
I was going to suggest you first find out whether your
console/terminal Vim has been compiled the same as your GUI gvim. I
thought you should be able to use
:has("mbyte")
but though I've compiled with MBYTE on, and the above fails for me. I
guess you can use
:version
instead.
I'm trying to learn a little about multi-byte functionality myself to
test some of the stuff I'm doing. I found this in the help doc:
7. Input on X11*mbyte-XIM*
X INPUT METHOD (XIM) BACKGROUND *XIM* *xim* *x-input-method*
...
For Chinese, there's a great XIM server named "xcin", you can input both
Traditional and Simplified Chinese characters. And it can accept other
locale if you make a correct input table. Xcin can be found at:
http://xcin.linux.org.tw/
Others are scim: http://scim.freedesktop.org/ and fcitx:
http://www.fcitx.org/
And a lot more. Unfortunately, this would suggest it's only useful
for the X11 or MsWIN GUI capable programs. Hopefully, you are using
an Xterminal which will communicate like this. (In general, it would
be a good idea to find out about the abilities of the terminal/console
you are using.)
I'm trying to learn about this myself, so I hope I don't add any confusion.
P.S. Before I get too far into this, am I going to be able to test
out Japanese or Chinese entry on a WinXp english-based OS?
Re: using variables in ! command
This might have failed because of context. If you used g:isshelp, then it would probably be recognized, though I don't know the rest of the situation. On 5/17/06, Jared <[EMAIL PROTECTED]> wrote: On 5/18/2006 12:08 AM, Yakov Lerner wrote: > Try > > map :exe ":silent! start ".isshelp Thanks for the reply, Yakov. However, that gives me an error message: E121: Undefined variable: isshelp E15: Invalid expression":silent! start ".isshelp Any other ideas? -- Jared
Re: ctrl+shift key mappings
On 5/17/06, Jared <[EMAIL PROTECTED]> wrote: Ok, this will be my last question for the night (promise!). I'd like to map separate commands to Ctrl-C and Ctrl-Shift-C. I've tried a couple different ways to do it, but this one seems like it should be most "correct": vnoremap "+y vnoremap ^Gol"+y Sorry, but I don't think there is a shift-control-c. This is [partly] because control chars are treated as a single byte, whereas other keyboard keys, like arrows, etc, are treated as 3-6 byte strings where the extra modifiers like shit/control/meta are in another byte. What's happening, though, is that the C-S-c map overwrites the C-c map. If I were to place C-c below C-S-c in .vimrc, the it'd be the other way around. So, two questions: 1) Am I defining the mapping correctly? I believe that's how it's done, but I couldn't find a specific example in the docs. 2) How do I make Vim distinguish between the two commands? Actually, I also have a 3rd, pseudo-related question: How do I include a control key sequence in a map? I'm using ^G in the above example, but that seems to be completely ignored when I hit . I also tried , but that's also ignored. is the correct method. Something else must be happening. Thanks once again. Believe me when I say that I'm most appreciative of the help that's constantly offered on this mailing list. -- Jared
Re: right-to-left text selection
While the visual mode selection is active, hitting "o" moves to the opposite corner. If it isn't doing that for you, I'd check for vmap interference. 3. Changing the Visual area *visual-change* *v_o* o Go to Other end of highlighted text: The current cursor position becomes the start of the highlighted text and the cursor is moved to the other end of the highlighted text. The highlighted area remains the same. Keep in mind that it doesn't work the same with a selection made by the mouse, since that leaves it in "select" mode not visual mode, which has some properties like insert mode, but in general has to be treated differently. Use ^G to switch visual/select modes. On 5/17/06, Jared <[EMAIL PROTECTED]> wrote: On 5/17/2006 12:52 AM, Gerald Lai wrote: >> So, my question: is it somehow possible to be able to select the last >> character of a line when selecting from right-to-left while using >> selection=exclusive? > > The simplest work around is to hit "ol" (that's oh-el) to select that > last character. How exactly does this work? When I hit o in command mode, it adds a newline below and moves the cursor down. If I hit o in select mode, it overtypes my selection. Hitting l does move the character to the right, but not if it's on the last line. Sorry, must've just misunderstood you. Would you mind explaining again? Thanks. -- Jared
Re: echon space ?
redrawing doesn't help. In this case with getchar(), echon'ed trailing spaces are only shown after a non-space character is echon'ed afterwards. It's not a big deal, but I'm going to cc: [EMAIL PROTECTED] since I can't find any way to create a getchar() + prompt with trailing spaces. I'm writing mappings like: cnoremap cd call Cd_plus() such that I want the user to see ":cd " as the prompt in the command line. On 5/16/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Eric Arnold wrote: > On 5/16/06, Gerald Lai <[EMAIL PROTECTED]> wrote: >> On Tue, 16 May 2006, Eric Arnold wrote: >> >> > Does anybody understand why trailing spaces in an "echon" string don't >> > actually show up? >> > >> > echon "\ngimme " >> > let inp = getchar() >> > echon nr2char(inp) >> >> I think echo/echon is doing fine. It's getchar() that's eating up >> trailing spaces. Compare @a's for: >> >>:redir @a | echon " 123" | call getchar() | redir END >>:redir @a | echon "\n123" | call getchar() | redir END >>:redir @a || echon " 123" | call getchar() | redir END > > Not sure what the last example is supposed to do. > >> The "\n" or previous ex command "|" has something to do with it. >> >> (tested on Vim 6.3) >> -- >> Gerald >> > > It's odd that it remembers all the trailing spaces, and prints them > out as soon as the echon following the getchar() prints a > non-space char. > > I'm thinking that it could also be the rendering in the command window > that is causing it, as if it truncates trailing spaces when writing to > the screen, but not when actually building the strings internally. > > It's probably a combination of this, and that getchar() isn't in > the list of things that triggers printing the trailing spaces. > > I can't tell whether to call this a bug yet. > > > (Just guessing in the dark) Could it be a redraw problem? Best regards, Tony.
Re: right-to-left text selection
Nevermind. Mail maddness. On 5/17/06, Eric Arnold <[EMAIL PROTECTED]> wrote: Use the "o" command to switch positions of the cursor, and then move to the left. On 5/16/06, Gerald Lai <[EMAIL PROTECTED]> wrote: > On Tue, 16 May 2006, Jared wrote: > > [snip] > > So, my question: is it somehow possible to be able to select the last > > character of a line when selecting from right-to-left while using > > selection=exclusive? > [snip] > > The simplest work around is to hit "ol" (that's oh-el) to select that > last character. > > You should know that the behavior of selection=exclusive has been shown > to been inconsistent. IMO, it's better to have selection=inclusive and > work around to removing the newline if it exists. > > HTH. > -- > Gerald >
Re: right-to-left text selection
Use the "o" command to switch positions of the cursor, and then move to the left. On 5/16/06, Gerald Lai <[EMAIL PROTECTED]> wrote: On Tue, 16 May 2006, Jared wrote: [snip] > So, my question: is it somehow possible to be able to select the last > character of a line when selecting from right-to-left while using > selection=exclusive? [snip] The simplest work around is to hit "ol" (that's oh-el) to select that last character. You should know that the behavior of selection=exclusive has been shown to been inconsistent. IMO, it's better to have selection=inclusive and work around to removing the newline if it exists. HTH. -- Gerald
Re: echon space ?
On 5/16/06, Gerald Lai <[EMAIL PROTECTED]> wrote: On Tue, 16 May 2006, Eric Arnold wrote: > Does anybody understand why trailing spaces in an "echon" string don't > actually show up? > > echon "\ngimme " > let inp = getchar() > echon nr2char(inp) I think echo/echon is doing fine. It's getchar() that's eating up trailing spaces. Compare @a's for: :redir @a | echon " 123" | call getchar() | redir END :redir @a | echon "\n123" | call getchar() | redir END :redir @a || echon " 123" | call getchar() | redir END Not sure what the last example is supposed to do. The "\n" or previous ex command "|" has something to do with it. (tested on Vim 6.3) -- Gerald It's odd that it remembers all the trailing spaces, and prints them out as soon as the echon following the getchar() prints a non-space char. I'm thinking that it could also be the rendering in the command window that is causing it, as if it truncates trailing spaces when writing to the screen, but not when actually building the strings internally. It's probably a combination of this, and that getchar() isn't in the list of things that triggers printing the trailing spaces. I can't tell whether to call this a bug yet.
echon space ?
Does anybody understand why trailing spaces in an "echon" string don't actually show up? echon "\ngimme " let inp = getchar() echon nr2char(inp)
Re: Calling through a function reference with a variable argument list
On 5/16/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
Have you thought about making it a dict function, and passing in and
out via the self dict?
function Mylen() dict
let self['newkey'] = 'newvalue'
return len(self.data)
endfunction
let mydict = {'data': [0, 1, 2, 3], 'len': function("Mylen")}
echo mydict.len()
echo mydict.newkey
You can then pass in the type meta data in one key, and the actual
data(num,string,list,dict) in another.
On 5/16/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 5/16/06, Bob Hiestand <[EMAIL PROTECTED]> wrote:
> > 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.
>
> The only thing I can think of is rewriting target functions
> into accepting 1 argument which is a list. I don't find
> vim vararg mechanism easy to use in general.
>
> Yakov
>
Re: Calling through a function reference with a variable argument list
Have you thought about making it a dict function, and passing in and
out via the self dict?
On 5/16/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 5/16/06, Bob Hiestand <[EMAIL PROTECTED]> wrote:
> 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.
The only thing I can think of is rewriting target functions
into accepting 1 argument which is a list. I don't find
vim vararg mechanism easy to use in general.
Yakov
Re: Key Mapping for spellcheck.
If you mean the right-shift key, I don't think shift/control/alt/meta are delivered by themselves to Vim. You'll have to pick shift-somekey. On 5/16/06, Baha-Eddine MOKADEM <[EMAIL PROTECTED]> wrote: Hi, I would like to map the right-clic-key (to make myself clear it's the one between Win flag and Ctrl key) so I can have the suggestion when I'm spellchecking a file. How is it named under vim ? Thank you for your help Eddine.
Re: Associating files with Vim 7
First make a backup copy of your registry with File/Export.
I'm not an expert with the registry, but it usually works to delete
entries for obsolete packages. If you change the entries from one
string to another, you can still end up with duplicates.
Re-install Vim7 afterwards if it isn't already fixed.
If you have a registry cleaner, use that too.
On 5/16/06, James Eibisch <[EMAIL PROTECTED]> wrote:
I wrote:
> In Windows 2000 I'm having problems associating file extensions
> with Vim 7.
-
Eric replied:
> Search your registry (with regedit or something better) for any
> conflicting entries for Vim6 and Vim7.
-
I've not done much with the registry before but below are some of the
related keys. There are some 6.2 keys left in there (numbers 4, 8, 12 plus
some others I didn't list).
Do you think it would be safe just to change all instances in the registry
of 'vim62' with 'vim70' as a try-it-and-see solution?
1. HKEY_CLASSES_ROOT\*\OpenWithList\gvim.exe\(value not set)
2. HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\gvim\a hex string
3.
HKEY_CLASSES_ROOT\Applications\gvim.exe\shell\edit\command\"..\vim\vim70\gvim.exe
"%1"
4.
HKEY_CLASSES_ROOT\Applications\gvim.exe\open\edit\command\"..\vim\vim62\gvim.exe
"%1"
5. HKEY_CLASSES_ROOT\CLSID\{long hex
string}\LocalServer32\"..\vim\vim70\gvim.exe"
6. HKEY_CLASSES_ROOT\CLSID\{long hex
string}\InProcServer32\"..\vim\vim70\gvimext.dl"
7. HKEY_CLASSES_ROOT\TypeLib\{long hex
string}\1.1\0\win32\"..\vim\vim70\gvim.exe"
8. HKEY_CLASSES_ROOT\Unknown\shell\open\command\"..\vim\vim62\gvim.exe
"%1"
9.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Exploreer\FileExts\.C\gvim.exe
10. HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\OpenWithList\gvim.exe
11.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\gvim.exe\shell\edit\command\"..\vim\vim70\gvim.exe
"%1"
12.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\gvim.exe\shell\open\command\"..\vim\vim62\gvim.exe
"%1"
13.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\vim.exe\shell\open\command\"..\vim\vim70\vim.exe
"%1"
Re: Shell support in Vim?
On 5/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I haven't seen much discussion of the intermediate solution: have a > command shell that *isn't* a terminal emulator. > > There have been several attempts at this, with varying degrees of > success. A command shell window which does good, solid handling of > command line utilities would be terrific. It would require none of > the morass of issues of terminal emulation, but still allow me/you to > do many of the things that would be so useful. > > I'm currently switching around between plugins like vimsh.vim which > uses Python, and my own home grown version which uses more primitive > interaction with Cygwin OS. They come close, but aren't fully > fledged, and seemingly aren't well known or used. I think with a few small additions to vim I could make vimsh a very good substitute. The big sticking point right now is async I/O. I've tried just about every trick in the book with none providing a good solution. I'm interested in seeing what you've done w/ cygwin. It's pretty bad with Windows. Even with Cygwin, all you have are pipes, not pseduo-ttys. I ended up with something fairly primative: communicating through the existence of files, checking every 200-300 ms. It responds as well as pipes without all the deadlock problems, though eats more cpu. The shell seems to be the inefficient side. I'm wondering if anybody has done a shared memory implementation for Windows? I personally like vimsh better than the possibility of an intergrated terminal because I like being able to move around it like a buffer with all the benefits of that, like the movement keys, yanking, etc, etc. Agreed.
Re: Highlighting in Vim 7
Did you try putting these at the bottom of your vimrc? If so, then it might be a plugin or script you are using which is causing them to reset. Try --noplugin. On 5/15/06, Antun Karlovac <[EMAIL PROTECTED]> wrote: I just upgraded from GVIM 6.3 to GVIM 7, and my highlight colors no longer work. I'm on Windows. In my _vimrc file I had the following settings: highlight Comment guifg=#5F5F5F highlight Constant guifg=#AA highlight Type gui=NONE guifg=#990011 highlight Searchguibg=#AA These colors are ignored altogether. If I run the above lines manually in command mode, the colors are set. My original _vimrc file is still getting sourced correctly (other commands are still being read). Is there something that I need to run to apply the above colors? Thanks and take care, Antun
Re: Associating files with Vim 7
Search your registry (with regedit or something better) for any conflicting entries for Vim6 and Vim7. On 5/16/06, James Eibisch <[EMAIL PROTECTED]> wrote: In Windows 2000 I'm having problems associating file extensions with Vim 7. I've been using Vim 6.2 (GUI version) for a while, and had associated C and TXT file extensions with it. In both Windows Explorer and a third-party file manager (WinNavigator 1.96), double-clicking a C or TXT file launched Vim as it should. Yesterday I upgraded to Vim 7 (the full, self-installing gvim70.exe). The installer uninstalled 6.2 before installing 7. 6.2 was installed in ...\vim\vim62 and 7 was installed in ...\vim\vim70. After installing 7, double-clicking a C file didn't launch Vim. No surprises there, as the path to gvim.exe had changed. I tried to associate the C extension with Vim 7 via Explorer | Tools | Folder Options | File Types, but Vim wasn't listed in the available programs - it was as if Vim hadn't registered itself with Windows while installing. I chose "Other" and navigated to vim70\gvim.exe, but when I clicked OK, the association hadn't stuck. In the 'Registered file types' box, the C extension said "Opens with:" but then a blank space - no program name. And Vim still wasn't listed in the available programs. However, double-clicking a C file in Windows Explorer did then launch Vim, but clicking a C file in WinNavigator didn't launch Vim - nothing happened. I associated C files with another editor, EditPlus, and that did stick, and did work in Explorer and WinNavigator. Tried associating with gvim again, and the same problem. Then I associated C files with the console version, vim70\vim.exe, and that did work - the association stuck, Vim was listed in the available programs, and files launched in console Vim in both file managers. Tried gvim again and still no joy. Has anyone got any ideas? I'm not sure if it's a Vim, Windows, or WinNavigator problem :-\ Thanks.
Re: Tab autocommand inconsistencies?
I'm not sure I fully get what's going on, but I think is has to do
with the window that is automatically cloned to start the tab, which
is then converted to an empty buffer window.
On 5/15/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
Just wanted to send the script that I used, in case anyone is interested
to repeat:
let g:auCount = 0
aug TT
au!
au WinEnter * :call Au('WinEnter')
au WinLeave * :call Au('WinLeave')
au TabEnter * :call Au('TabEnter')
au TabLeave * :call Au('TabLeave')
au BufEnter * :call Au('BufEnter')
au BufLeave * :call Au('BufLeave')
aug END
function! Au(autype)
let g:auCount = g:auCount + 1
echomsg a:autype.' '.g:auCount
call input(a:autype)
endfunction
--
Thanks,
Hari
On Mon, 15 May 2006 at 5:08pm, Hari Krishna Dara wrote:
>
> I am observing what might be inconsistency in the order in which vim
> fires autocommands. First, ovserving the order of buffer and window events,
>
> - Using :new:
>
> WinLeave
> WinEnter
> BufLeave
> BufEnter
>
> - Using :wincmd w
>
> BufLeave
> WinLeave
> WinEnter
> BufEnter
>
>
> When combined with tab operations,
>
> - Using, :tabe:
>
> WinLeave
> TabLeave
> TabEnter
> WinEnter
> BufLeave
> BufEnter
>
> - Using :tabnext:
>
> BufLeave
> WinLeave
> TabLeave
> WinEnter
> TabEnter
> BufEnter
>
> Extrapolating the first two, I was expecting these to be
>
> - For tabe:
>
> TabLeave
> TabEnter
> WinLeave
> WinEnter
> BufLeave
> BufEnter
>
> - For :tabnext:
>
> BufLeave
> WinLeave
> TabLeave
> TabEnter
> WinEnter
> BufEnter
>
> Is the existing behavior expected? Does anyone agree that it is
> inconsistent? I am even surprised that they should differ between
> switching between the existing windows/tabs and creating new ones.
>
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Moving windows horizontally from col to col
Have a look at WinWalker.vim. It does this sort of thing. On 5/16/06, Marc Weber <[EMAIL PROTECTED]> wrote: On Mon, May 15, 2006 at 03:43:40PM -0700, Gerald Lai wrote: > On Tue, 16 May 2006, Marc Weber wrote: > > >I like the way you can move windows in wmii. > > > >1 | 2 > >--+-- > >3 | 4 > > > >if your cursor is in window 1 and you move the window to the right you > >get > > > > | 1 > >3 | 2 > > | 4 > > [improved illustrations] and back eg. putting cursor into 4 and moving it to the left should result in 4 | 1 --+-- 3 | 2 Wether 4 is above 3 or not isn't that important.. I don't know how to do this with wincmd HJKL > Not going as far as writing a full script to move windows around, what > I'd do to achieve the above are the following commands: > > :windo wincmd K > :3wincmd w > :wincmd H Using one mapping is much faster than typing 3 commands ;) > http://www.vim.org/scripts/script.php?script_id=1522 I know it, but does too much much and not the way I like it. Perhaps source my script, do some :vsplit|enew and try it... (and remove the /tmp/.. file afterwards) Marc
