Mapping german umlauts
Hi,
I want to remap the german umlauts to "{","[","]" and "}" in normal
mode only.
When I type the umlauts on the commandline of my zsh there is no
problem.
When I type them in insert mode in vim: no problems.
Therefore I /think/ (read: dont no for sure) that there should be no
problem.
In my $HOME/.vimrc I wrote:
nnoremap o [
nnoremap a ]
nnoremap O {
nnoremap A }
(I replaced the umlauts with their corresponding vowels here in this
mail only -- just to make them displayable in any case...)
But this does not work. With the :map command I can see the maps but
the umlauts looks like 8bit-something. Two of them are displayed as
two characters.
Then I tried:
nnoremap <[>
nnoremap <]>
nnoremap <{>
nnoremap <}>
which results in nothing: Now the "corrupted" maps via the :map
command has vanished completly.
Now I got an Error message displayed in front of my inner eye:
"WARNING! Idea stack underflow!"
What can I try else ?
Thank you very much for any help in advance !
Keep hacking!
mcc
Re: bufdo search stop at first match
On Sat 7-Oct-06 5:43am -0600, Eric Smith wrote:
> I am using the following to search all buffers for "foo".
> b1|bufdo exec search("foo" , flags)
>
> This stops at the last match. How do I stop at the first match?
You could do something like:
:bufdo %s/foo//c
and hit 'q' if found.
--
Best regards,
Bill
Question about ColorScheme designing
Hello everyone, I'm the author of the colorscheme 'ps_color', which is used to be fairly sophisticated and have both dark-background and light-background color scheme inside. Recently I'd found that the 'set background' command will automatically source the colorscheme again. So it may be good to read the value of 'background' instead of set it inside the colorscheme. By then user can change the behavior with 'set background=dark' or 'set background=light'. (I had not tested and don't know if it really works this way...) The only issue is: the ps_color has the default 'background=dark', and most Vim distribution has the default 'background=light'. If I release a new version of 'ps_color' which accepts the 'background' value, many user will feel the difference since they will get a light background instead unless they have 'set background=dark' in both .vimrc and .gvimrc. If this 'feature' added, then most users will feel difference (maybe annoyance?), What I should do is to notice all users to have 'set background=xxx' before the 'color ps_color' command after update the ps_color.vim to new version. Is it a good idea to do the change? Thanks all. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: how to remember file offsets?
Hari Krishna Dara wrote: On Sat, 7 Oct 2006 at 8:40pm, A.J.Mechelynck wrote: Hari Krishna Dara wrote: [...] In the vimrc_example.vim, there is a common on this and part of it says: " Don't do it when the position is invalid or when inside an event handler " (happens when dropping a file on gvim). Any idea what it is exactly talking about? Is the "Don't do it" part a comment on how the functionality of the autocommand or an instruction to the user? [snip] "Inside an event handler" means that the autocommand is not defined as "nested", which means that the autocommand will not be triggered from within an autocommand for a different event (as when, IIUC, a file is drag-dropped onto an existing gvim window). I don't use drag-drop for Vim so this doesn't bother me. If you often encounter the problem, you might try adding the "nested" keyword to the autocommand (see ":help autocmd-nested") but there might be side-effects. I suppose Bram didn't lightly choose to add a comment rather than a keyword. I don't know where you got the notion of "nested" in the above comment, but I think you are actually wrong and that it is irrelevant here. When you define an autocommand (call as parent), adding nested keyword allows other autocommands (call as children) to be triggered from the actions performed by the parent autocommand. If BufReadPost got triggered, it means it either triggered as a parent autocommand (as a direct user action), or as a child autocommand of another parent autocommand that allowed nesting. I never really understood whether the "parent", the "child", or either, or both, had to have the "nested" keyword (see ":help autocmd-nested") for nesting to happen. I suspect it's either but I'm not sure; however, that's the only way I can understand the phrase "inside an even handler". Given the above explanation, I still don't understand the comment. Is there a different autocommand that gets triggered while dnding files? If so which one is it? If that autocommand allows nesting, how are we detecting that BufReadPost is being nested (or a child, in my terms) here (I don't see any special condition). Last but not least, why is setting a position in such a situation wrong? In any case, I actually tried doing dnd of files on gvim with this autocommand, and it seems to just work fine, preserving cursor positions. Is the comment not relevant anymore? Would you care to elaborate your earlier explanation? Sorry for being so finicky, I just want to understand that's all. Well, maybe "inside an event handler" is not relevant anymore, maybe it's "(happens when dropping a file on gvim)" or maybe it's OS-dependent; I don't really know -- I just gave you my interpretation, which might be wrong. The part about "when the position is invalid" remains relevant in any case. Best regards, Tony.
Re: bufdo search stop at first match
On Sat, 7 Oct 2006 at 12:43pm, Eric Smith wrote:
> I am using the following to search all buffers for "foo".
> b1|bufdo exec search("foo" , flags)
>
> This stops at the last match. How do I stop at the first match?
>
> thanx
>
The :bufdo and cousines stop when there is an error when the file can't
be |abondon|ed, so the easiest to stop is to generate an error,
something like:
:bufdo g/foo/throw 'Found match'
This generates an ugly error message, but at least it works. There may
be a more graceful way of generating error that someone can suggest.
--
HTH,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: how to remember file offsets?
On Sat, 7 Oct 2006 at 8:40pm, A.J.Mechelynck wrote: > Hari Krishna Dara wrote: > [...] > > In the vimrc_example.vim, there is a common on this and part of it says: > > > > " Don't do it when the position is invalid or when inside an event handler > > " (happens when dropping a file on gvim). > > > > Any idea what it is exactly talking about? Is the "Don't do it" part > > a comment on how the functionality of the autocommand or an instruction > > to the user? > > [snip] > "Inside an event handler" means that the autocommand is not defined as > "nested", which means that the autocommand will not be triggered from within > an autocommand for a different event (as when, IIUC, a file is drag-dropped > onto an existing gvim window). I don't use drag-drop for Vim so this doesn't > bother me. If you often encounter the problem, you might try adding the > "nested" keyword to the autocommand (see ":help autocmd-nested") but there > might be side-effects. I suppose Bram didn't lightly choose to add a comment > rather than a keyword. I don't know where you got the notion of "nested" in the above comment, but I think you are actually wrong and that it is irrelevant here. When you define an autocommand (call as parent), adding nested keyword allows other autocommands (call as children) to be triggered from the actions performed by the parent autocommand. If BufReadPost got triggered, it means it either triggered as a parent autocommand (as a direct user action), or as a child autocommand of another parent autocommand that allowed nesting. Given the above explanation, I still don't understand the comment. Is there a different autocommand that gets triggered while dnding files? If so which one is it? If that autocommand allows nesting, how are we detecting that BufReadPost is being nested (or a child, in my terms) here (I don't see any special condition). Last but not least, why is setting a position in such a situation wrong? In any case, I actually tried doing dnd of files on gvim with this autocommand, and it seems to just work fine, preserving cursor positions. Is the comment not relevant anymore? Would you care to elaborate your earlier explanation? Sorry for being so finicky, I just want to understand that's all. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Bug in :(un)lockvar
On Sat, 7 Oct 2006 at 3:32pm, Bram Moolenaar wrote:
>
> Hari Krishna Dara wrote:
>
> > The :lockvar and :unlockvar commands fail when there is a recursive
> > references. E.g., try the below:
> >
> > :let a = {}
> > :let b = {}
> > :let a.b = b
> > :let b:a = a
> > :lockvar! a
> > E743: variable nested too deep for (un)lock
> >
> > You could of course end up with more complicated indirect recursive
> > references as well, so it should guard against it.
>
> Although it's correct as such, I know a trick to detect the same list or
> dictionary is encountered a second time, and then don't recurse into it.
Does that mean you will provide a patch? Also note that it could be
a self recursion too (:let a.a = a).
> > Also, just noticed that string() fails as well.
> >
> > :echo string(a)
> > E724: variable nested too deep for displaying
>
> This is much harder to avoid. It's very well possible that a list or
> dictionary appears multiple times without a recursive reference. In
> that case it should be listed normally. It's not easy to distinguish a
> normal reference from a recursive reference.
Why is it hard to distinguish a direct reference and indirect reference?
In any case, this functionality is not much of a use unless you really
want to be able to restore the original structure using eval(), but I
doubt if string() has special semantics to preserve identities.
> > There are probably others that would fail as well.
>
> What others?
I just meant there could be others, but I looked at the list there
shouldn't be any others.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: adding first part to input()
Eric Smith wrote:
How do I add a string so that it occurs at the prompt which is spaned
by the input() command? I could potentially delete all or part of this
string or just start typing after it.
My prompt might look like:
Enter item to search for: set_
^
cursor
The "set_" will be added to whatever I type at the cursor.
Thanks
See ":help input()"
The input() function takes (at least in Vim 7) up to three arguments, as
follows:
input({prompt} [, {text} [, {completion}]])
{prompt} is the "question" text Vim will ask the user
{text} if present and not empty, is the default reply. IIUC, this is what you
want.
{completion} (optional) is the kind of completion to use. Valid values (which
must be quoted) are:
augroup
buffer
command
dir
environment
event
expression
file
shellcmd
function
help
highlight
mapping
menu
option
tag
tag_listfiles
var
custom,{func}
customlist,{func}
(see ":help command-complete").
Best regards,
Tony.
adding first part to input()
How do I add a string so that it occurs at the prompt which is spaned by the input() command? I could potentially delete all or part of this string or just start typing after it. My prompt might look like: Enter item to search for: set_ ^ cursor The "set_" will be added to whatever I type at the cursor. Thanks -- Eric Smith
Re: Bug in updating block markers ?
On Sat, 7 Oct 2006 at 10:08pm, Bram Moolenaar wrote: > > > > exec 'normal! '.(s:IsSelectMode() ? "\" : '')."\gv". > > \ (s:IsSelectMode() ? "\" : '') > > > > It is strange that the normal command would not recognize the in > > select mode if I don't first switch to visual mode using . > > I dunno. A did a small test and it seemed to work OK for me. I got the "gv" replacing the selection, as if was never pressed. When I added , it worked fine. No big deal though. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Bug in updating block markers ?
Hari Krishna Dara wrote:
> > > The '> and '< markers identify the start and end position of a selection
> > > block and it seems to be not updated correctly in one particular case.
> > > Say you start selection (visual mode or select mode) on one line, and
> > > use ^E or ^Y to scroll the buffer such that the current line goes past
> > > the window bounds and cursor is forced to move to the next or previous
> > > line respectively. This results in the selection getting expanded, but
> > > the markers still return the old values. Here is a utility map that
> > > you can press on the block to see the latest values for these markers:
> > >
> > > xnoremap T()
> > > snoremap T()
> > > function! T()
> > > echo 'mode: '.mode().' start: '.line("'<").' end: '.line("'>")
> > > return ''
> > > return ''
> > >
> > > Once the selection gets expanded, press on it see that the values
> > > haven't changed (viz., they both will have the same line numbers, for
> > > the original line where the selection started.)
> >
> > The problem is actually the other way around: While Visual mode is
> > active the '< and '> marks should keep the old values, from a previous
> > selection. I discovered the marks get set because of the "autoselect"
> > value in 'clipboard' and the "a" flag in 'guioptions. The patch below
> > will fix that.
>
> I am not clear on what the expected behavior is. Are you saying that
> the marks should be set only after clearing the current selection, and
> until then older marks should be preserved? I am pretty sure many
> maps have been written using this assumption (I might have one or two as
> well) and they will break with your patch.
These maps would already break when autoselect is not enabled.
> If the bug has always been there, why not make it the expected behavior?
> Do you see any problem with that?
It may be useful to be able to get the old start and end of the Visual
area. The current start and end are the two positions that "o" jumps
between. Better to have four positions than two.
> > > Anyone can think of an alternate way to identify the correct line
> > > numbers? The "o" command seems to work fine, but I can't use it as I
> > > need to do the checks from a CursorMoved handler.
> >
> > I don't think you can get the position of the other end of the Visual
> > area directly. Perhaps by stopping Visual mode, using the '< and '>
> > marks and then using "gv" to select the same area? It would be a lot
> > simpler if we have a mark for this.
>
> I first thought this will not a be a valid command to be executed from
> CursorMoved autocommand, but the doc doesn't say anything about
> executing normal mode commands (there is a warning, but seems like
> nothing is explicitly restricted). Anyway, I used the below and it works
> well now:
>
> exec 'normal! '.(s:IsSelectMode() ? "\" : '')."\gv".
> \ (s:IsSelectMode() ? "\" : '')
>
> The s:IsSelectMode() is just a wrapper around a check on three select
> modes.
>
> It is strange that the normal command would not recognize the in
> select mode if I don't first switch to visual mode using .
I dunno. A did a small test and it seemed to work OK for me.
--
hundred-and-one symptoms of being an internet addict:
25. You believe nothing looks sexier than a man in boxer shorts illuminated
only by a 17" inch svga monitor.
/// 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: how to remember file offsets?
Hari Krishna Dara wrote: [...] In the vimrc_example.vim, there is a common on this and part of it says: " Don't do it when the position is invalid or when inside an event handler " (happens when dropping a file on gvim). Any idea what it is exactly talking about? Is the "Don't do it" part a comment on how the functionality of the autocommand or an instruction to the user? The words "Don't do it" are not an order to the user, but a comment on what Vim does: If, for instance, the "remembered" line number is less than one or greater than the number of lines in the now-existing file, no repositioning will be done. This is what "the position is invalid" means. This can happen if the file has been modified or overwritten between closing and reopening Vim, or even between unloading and reloading the file. "Inside an event handler" means that the autocommand is not defined as "nested", which means that the autocommand will not be triggered from within an autocommand for a different event (as when, IIUC, a file is drag-dropped onto an existing gvim window). I don't use drag-drop for Vim so this doesn't bother me. If you often encounter the problem, you might try adding the "nested" keyword to the autocommand (see ":help autocmd-nested") but there might be side-effects. I suppose Bram didn't lightly choose to add a comment rather than a keyword. Best regards, Tony.
Re: Bug in updating block markers ?
On Sat, 7 Oct 2006 at 3:32pm, Bram Moolenaar wrote:
>
> Hari Krishna Dara wrote:
>
> > The '> and '< markers identify the start and end position of a selection
> > block and it seems to be not updated correctly in one particular case.
> > Say you start selection (visual mode or select mode) on one line, and
> > use ^E or ^Y to scroll the buffer such that the current line goes past
> > the window bounds and cursor is forced to move to the next or previous
> > line respectively. This results in the selection getting expanded, but
> > the markers still return the old values. Here is a utility map that
> > you can press on the block to see the latest values for these markers:
> >
> > xnoremap T()
> > snoremap T()
> > function! T()
> > echo 'mode: '.mode().' start: '.line("'<").' end: '.line("'>")
> > return ''
> > return ''
> >
> > Once the selection gets expanded, press on it see that the values
> > haven't changed (viz., they both will have the same line numbers, for
> > the original line where the selection started.)
>
> The problem is actually the other way around: While Visual mode is
> active the '< and '> marks should keep the old values, from a previous
> selection. I discovered the marks get set because of the "autoselect"
> value in 'clipboard' and the "a" flag in 'guioptions. The patch below
> will fix that.
I am not clear on what the expected behavior is. Are you saying that
the marks should be set only after clearing the current selection, and
until then older marks should be preserved? I am pretty sure many
maps have been written using this assumption (I might have one or two as
well) and they will break with your patch.
If the bug has always been there, why not make it the expected behavior?
Do you see any problem with that?
> > Anyone can think of an alternate way to identify the correct line
> > numbers? The "o" command seems to work fine, but I can't use it as I
> > need to do the checks from a CursorMoved handler.
>
> I don't think you can get the position of the other end of the Visual
> area directly. Perhaps by stopping Visual mode, using the '< and '>
> marks and then using "gv" to select the same area? It would be a lot
> simpler if we have a mark for this.
I first thought this will not a be a valid command to be executed from
CursorMoved autocommand, but the doc doesn't say anything about
executing normal mode commands (there is a warning, but seems like
nothing is explicitly restricted). Anyway, I used the below and it works
well now:
exec 'normal! '.(s:IsSelectMode() ? "\" : '')."\gv".
\ (s:IsSelectMode() ? "\" : '')
The s:IsSelectMode() is just a wrapper around a check on three select
modes.
It is strange that the normal command would not recognize the in
select mode if I don't first switch to visual mode using .
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: how to remember file offsets?
On Sat, 7 Oct 2006 at 6:12pm, A.J.Mechelynck wrote:
> Yakov Lerner wrote:
> > Forwarding to the ist
> >
> > -- Forwarded message --
> > From: Fletcher Mattox <[EMAIL PROTECTED]>
> > Date: Oct 7, 2006 3:21 PM
> > Subject: Re: how to remember file offsets?
> > To: Yakov Lerner <[EMAIL PROTECTED]>
> >
> >
> >> On 10/6/06, Fletcher Mattox <[EMAIL PROTECTED]> wrote:
> >> > Hi,
> >> >
> >> > When I edit two files by typing ":e foo" and ":e #", vim remembers
> >> > my current location in each and kindly positions me there when
> >> > I revisit them. However, when I edit three or more files, vim forgets
> >> > where I was and always positions the cursor at the top of the file.
> >> > How do I get vim to remember where I was in an arbitrary number
> >> > of files?
> >>
> >> Check that you have option 'viminfo properly set
> >> (:help 'vimnifo') in your vimrc; and check that you have
> >> following in your vimrc:
> >>
> >> autocmd BufReadPost *
> >> \ if line("'\"") > 0 && line("'\"") <= line("$") |
> >> \ exe "normal g`\"" |
> >> \ endif
> >>
> >> Yakov
> >
> > Yakov,
> >
> > Perfect! Thank you so much for spelling this out. One of the other
> > list members
> > alluded to this solution, but I couldn't quite put it all together (I am
> > a new
> > vim user) until your email arrived.
> >
> > Thanks again,
> > Fletcher
> >
>
> Well, the solution to which I alluded includes this implicitly by having the
line
>
> source $VIMRUNTIME/vimrc_example.vim
>
> near the top of your vimrc.
>
>
> Best regards,
> Tony.
In the vimrc_example.vim, there is a common on this and part of it says:
" Don't do it when the position is invalid or when inside an event handler
" (happens when dropping a file on gvim).
Any idea what it is exactly talking about? Is the "Don't do it" part
a comment on how the functionality of the autocommand or an instruction
to the user?
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: how to remember file offsets?
Yakov Lerner wrote:
Forwarding to the ist
-- Forwarded message --
From: Fletcher Mattox <[EMAIL PROTECTED]>
Date: Oct 7, 2006 3:21 PM
Subject: Re: how to remember file offsets?
To: Yakov Lerner <[EMAIL PROTECTED]>
On 10/6/06, Fletcher Mattox <[EMAIL PROTECTED]> wrote:
> Hi,
>
> When I edit two files by typing ":e foo" and ":e #", vim remembers
> my current location in each and kindly positions me there when
> I revisit them. However, when I edit three or more files, vim forgets
> where I was and always positions the cursor at the top of the file.
> How do I get vim to remember where I was in an arbitrary number
> of files?
Check that you have option 'viminfo properly set
(:help 'vimnifo') in your vimrc; and check that you have
following in your vimrc:
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal g`\"" |
\ endif
Yakov
Yakov,
Perfect! Thank you so much for spelling this out. One of the other
list members
alluded to this solution, but I couldn't quite put it all together (I am
a new
vim user) until your email arrived.
Thanks again,
Fletcher
Well, the solution to which I alluded includes this implicitly by having the
line
source $VIMRUNTIME/vimrc_example.vim
near the top of your vimrc.
Best regards,
Tony.
Re: bufdo search stop at first match
Eric Smith wrote:
I am using the following to search all buffers for "foo".
b1|bufdo exec search("foo" , flags)
This stops at the last match. How do I stop at the first match?
thanx
The following works, I think, but it also saves modified buffer. It won't
search [No Name] buffers. It may fail if you have named buffers not
corresponding to a file, like directory-browsing buffers or options-window
buffers. It might be more robust with argdo instead of bufdo.
If you can express the names of the files you want to search as a
space-separated list of file names (possibly with wildcards), the first two
lines below are not necessary.
:let buflist = ""
:bufdo let buflist .= " " . expand("%:p") | silent! update
:exe "vimgrep /pattern/g" buflist
Best regards,
Tony.
Re: how to remember file offsets?
Forwarding to the ist
-- Forwarded message --
From: Fletcher Mattox <[EMAIL PROTECTED]>
Date: Oct 7, 2006 3:21 PM
Subject: Re: how to remember file offsets?
To: Yakov Lerner <[EMAIL PROTECTED]>
On 10/6/06, Fletcher Mattox <[EMAIL PROTECTED]> wrote:
> Hi,
>
> When I edit two files by typing ":e foo" and ":e #", vim remembers
> my current location in each and kindly positions me there when
> I revisit them. However, when I edit three or more files, vim forgets
> where I was and always positions the cursor at the top of the file.
> How do I get vim to remember where I was in an arbitrary number
> of files?
Check that you have option 'viminfo properly set
(:help 'vimnifo') in your vimrc; and check that you have
following in your vimrc:
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal g`\"" |
\ endif
Yakov
Yakov,
Perfect! Thank you so much for spelling this out. One of the other
list members
alluded to this solution, but I couldn't quite put it all together (I am a new
vim user) until your email arrived.
Thanks again,
Fletcher
Re: Cursor movement commands on a german keyboard
I mapped some of those commands to the german umlauts...
That is actually similar to remapping the keys directly with xmodmap,
except that you can still use them.
Example
:nmap รถ {
Regards,
Christian
Stefan Walk wrote:
Meino Christian Cramer wrote:
HI,
There are a lot of specialized curor movement commands, which all
will speed up one vimy life.
...exeption: You are editing on a german keyboard...
There you will "reach" "}" by pressing AltGr-0, "]" by presing
AltGr-9 and so on, which always is at least bad Yoga for your right
hand. Combinations like "[]" or "][" are even more painful
(german-keyboard-wise).
Is there a vim hacker out there, who has made good
experiences with a certain remapping of those keys/function to other
keys (without loosing other important vim features) and would like to
share those mappings ?
Thank you very much in advance for any help !
Keep hacking!
mcc
Well, the obvious solution is using an US keymap, that's what I am
doing. To be exact, I'm using a modified version with the german umlauts
on AltGr+Umlaut key and some other modifications ... xmodmap is a nice tool.
Regards,
Stefan
Re: Win32 build of updated gvim
Yongwei Wu wrote: Hi List, I am keeping an updated version of gvim.exe on my Web site now. I still feel it is convenient to have one installation of Vim and overwrite the main executable now and then. Antoine used to do that, and I am doing that too ;-). It is built with MSVC 8 (the free Visual C++ 2005 Express Edition), with mostly the same configuration as the official Win32 build. The deviation is that Tcl 8.4 instead of 8.3 is used--ActivateState no longer provides the 8.3 download, so I think it should be OK. The link is here: http://wyw.dcweb.cn/#download or directly http://wyw.dcweb.cn/download.asp?path=vim&file=gvim70.zip Best regards, Yongwei A word of caution to anyone using this approach: the runtime files need to be updated periodically, as discussed yesterday (plus-minus one day, depending on your time zone) in a thread named "Bug in map and complete()" on this mailing list. An alternative is to use Steve Hall's "Vim" (not to be confused with "Cream for Vim") installers from time to time, at least when a patch published on the vim-dev list includes a change to some file with extension .vim .txt or .po (meaning vim-script, helpfile, or language-translations respectively). Steve Hall's Vim can be downloaded (with runtime files as of build date) from https://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721 -- the latest patchlevel as of this writing is 7.0.118 dated Oct. 3, 2006; and as the "release notes" show, it has the following characteristics: Big version with MS-Windows 32-bit GUI and OLE support, and also (IIUC) Big MS-Windows 32-bit version without GUI +gettext/dyn +iconv/dyn +multi_byte_ime/dyn +mzscheme/dyn, for libmzsch352.dll and libmzgc352.dll +perl/dyn, for perl58.dll +python/dyn, for python24.dll +ruby/dyn, for msvcrt-ruby18.dll +tcl/dyn, for tcl84.dll As you probably know, /dyn means that the feature will be "present" if the appropriate DLL is found in the PATH, and that Vim will work OK, but without the feature, if the DLL is not found. IIUC, +multi_byte_ime/dyn also means that it will function as +multi_byte but -multi_byte_ime if the Windows IME is not found. This is not to berate Yongwei's efforts, quite the opposite: the runtime files don't really need to be updated as often as the binaries, and downloading only the latter saves bandwidth (both yours and at the download site). Best regards, Tony.
Re: Bug in updating block markers ?
Hari Krishna Dara wrote:
> The '> and '< markers identify the start and end position of a selection
> block and it seems to be not updated correctly in one particular case.
> Say you start selection (visual mode or select mode) on one line, and
> use ^E or ^Y to scroll the buffer such that the current line goes past
> the window bounds and cursor is forced to move to the next or previous
> line respectively. This results in the selection getting expanded, but
> the markers still return the old values. Here is a utility map that
> you can press on the block to see the latest values for these markers:
>
> xnoremap T()
> snoremap T()
> function! T()
> echo 'mode: '.mode().' start: '.line("'<").' end: '.line("'>")
> return ''
> return ''
>
> Once the selection gets expanded, press on it see that the values
> haven't changed (viz., they both will have the same line numbers, for
> the original line where the selection started.)
The problem is actually the other way around: While Visual mode is
active the '< and '> marks should keep the old values, from a previous
selection. I discovered the marks get set because of the "autoselect"
value in 'clipboard' and the "a" flag in 'guioptions. The patch below
will fix that.
> Anyone can think of an alternate way to identify the correct line
> numbers? The "o" command seems to work fine, but I can't use it as I
> need to do the checks from a CursorMoved handler.
I don't think you can get the position of the other end of the Visual
area directly. Perhaps by stopping Visual mode, using the '< and '>
marks and then using "gv" to select the same area? It would be a lot
simpler if we have a mark for this.
*** ../../vim-7.0.120/src/normal.c Tue Aug 29 17:28:56 2006
--- normal.cSat Oct 7 14:11:26 2006
***
*** 1477,1490
}
else if (VIsual_active)
{
! /* Save the current VIsual area for '< and '> marks, and "gv" */
! curbuf->b_visual.vi_start = VIsual;
! curbuf->b_visual.vi_end = curwin->w_cursor;
! curbuf->b_visual.vi_mode = VIsual_mode;
! curbuf->b_visual.vi_curswant = curwin->w_curswant;
# ifdef FEAT_EVAL
! curbuf->b_visual_mode_eval = VIsual_mode;
# endif
/* In Select mode, a linewise selection is operated upon like a
* characterwise selection. */
--- 1477,1493
}
else if (VIsual_active)
{
! if (!gui_yank)
! {
! /* Save the current VIsual area for '< and '> marks, and "gv" */
! curbuf->b_visual.vi_start = VIsual;
! curbuf->b_visual.vi_end = curwin->w_cursor;
! curbuf->b_visual.vi_mode = VIsual_mode;
! curbuf->b_visual.vi_curswant = curwin->w_curswant;
# ifdef FEAT_EVAL
! curbuf->b_visual_mode_eval = VIsual_mode;
# endif
+ }
/* In Select mode, a linewise selection is operated upon like a
* characterwise selection. */
--
hundred-and-one symptoms of being an internet addict:
20. When looking at a pageful of someone else's links, you notice all of them
are already highlighted in purple.
/// 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: Bug in :(un)lockvar
Hari Krishna Dara wrote:
> The :lockvar and :unlockvar commands fail when there is a recursive
> references. E.g., try the below:
>
> :let a = {}
> :let b = {}
> :let a.b = b
> :let b:a = a
> :lockvar! a
> E743: variable nested too deep for (un)lock
>
> You could of course end up with more complicated indirect recursive
> references as well, so it should guard against it.
Although it's correct as such, I know a trick to detect the same list or
dictionary is encountered a second time, and then don't recurse into it.
> Also, just noticed that string() fails as well.
>
> :echo string(a)
> E724: variable nested too deep for displaying
This is much harder to avoid. It's very well possible that a list or
dictionary appears multiple times without a recursive reference. In
that case it should be listed normally. It's not easy to distinguish a
normal reference from a recursive reference.
> There are probably others that would fail as well.
What others?
--
hundred-and-one symptoms of being an internet addict:
19. All of your friends have an @ in their names.
/// 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: how to remember file offsets?
On 10/6/06, Fletcher Mattox <[EMAIL PROTECTED]> wrote:
Hi,
When I edit two files by typing ":e foo" and ":e #", vim remembers
my current location in each and kindly positions me there when
I revisit them. However, when I edit three or more files, vim forgets
where I was and always positions the cursor at the top of the file.
How do I get vim to remember where I was in an arbitrary number
of files?
Check that you have option 'viminfo properly set
(:help 'vimnifo') in your vimrc; and check that you have
following in your vimrc:
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal g`\"" |
\ endif
Yakov
bufdo search stop at first match
I am using the following to search all buffers for "foo".
b1|bufdo exec search("foo" , flags)
This stops at the last match. How do I stop at the first match?
thanx
--
Eric Smith
RE: Forms highlighting
On Thu, 5 Oct 2006 at 9:35am, David Fishburn wrote: > I gave the demo a whirl. > > When you enter the State field the omni completion pops up. > You cannot hit escape to get out of this. > In fact you must choose something, even if you didn't want to. You can press to close the popup, just like for the normal completion popup. Escape restores the old value, but doesn't close the popup. There is a lot of scope for improvements with the combobox, but using the Vim native popup features, it is very hard to do this. I am thinking of using a recursive map in combination of getchar() to make this better, but I don't know if it will work. It is right now usable, though a bit flaky. > Entering the Country field. > If you cursor is on U, press C. I wanted to just type "Canada", but of > course C in normal mode changes to end of line. So this wiped out the rest > of the line. It seems when the > is gone, things get messed up. You can't > actually type anything. I plugged a lot of such holes in the latest release. I encourage to break it in other ways and let me know how you did it. There is no reward for breaking though :) (well, you could consider a more robust form.vim as a reward). > So I restarted the form. > When to USA hit cw, typed in "Canaada". > Realized my mistake, but my cursor on the a and hit x. > Since I was in visual mode this left me with "xada". Now use the left and > right keys to reposition yourself. Very funky behaviour ending up with the > existing characters being repeated many times. Actually it does this with > h,l as well. This is an issue with complete(), you can only specify the start column, and end column is restricted to the current column, so you can't complete an item when the cursor is in the middle of it. I faced this same issue with LookupFile also, and the solution was to just hide the popup if the cursor is not at the end. I did the same thing here, so you shouldn't see this anymore. > That is all I had a chance to try this morning. Thanks for trying, I was actually counting on you :) -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Forms highlighting
There is a new version at:
http://haridara.googlepages.com/forms.vim
Significant changes being:
- Support for disabling fields.
- Validator support.
- Cursor monitoring to prevent accidental editing of readonly parts of
the form.
- Several bug fixes.
- to start edit mode.
- Implemented several TODO items.
- Added some new TODO items :)
Combobox functionality is now less flaky, but I have some ideas to make
it better, especially with the readonly version. I have put in several
guards to make sure editing can be done only in the areas where it is
supposed to be done. Please feel free to break this and let me know so
that I can plug any more holes.
I modified the demo to include both enabling/disabling fields as well as
validation (zip field). The demo could be something useful, e.g., a find
dialog like in MS Word, but that could be a lot of work and I would
rather spend that time in improving the script.
See below for my comments.
On Thu, 5 Oct 2006 at 1:19pm, Mikolaj Machowski wrote:
> , ? It should work everywhere and is quite natural for Vim
> users (IMO).
Now and also work like and .
> I would expect some simplifying in use. For example why explicitly
> declare them? Create listeners automatically.
I am not still clear. How can you create listeners automatically? Can
you give some example?
> Check example I send earlier. Core stuff is quite simple, big part of it
> is overhead dealing with listeners.
Part of it is due to the workarounds you had to put in (which is no
longer needed, I fixed the problem) and the rest is expected if you want
any dynamic nature. If you want to simplify, all that you need is one
listener for the OK button and you are done.
In any case, I have added checks to make callbacks only when the
dict function is defined (with no errors), so there is more flexibility.
You can have all the three callbacks in one dict and use the same dict
for all fields, or split them into different dicts.
> > - Validators.
>
> Local validation (onBlur event) can be already done. Problem is when
> doing after pressing OK. Hmm, in fact it can be also done but is boring
> ;) to do. Some API for that would be good.
How was onBlur event possible? Previously you could do validation in the
valueChanged() callback, but you couldn't constrain the focus, but the
new isValid() callback allows that.
> > - When the focus is moved in, explicitly set the value again, to make
> > sure any fouled up entries are fixed.
>
> Don't understand that. Maybe you were thinking about "moving out" of
> field (onBlur JavaScript event)? It is already possible.
I was just referring to accidentally removing too much (e.g., the {}
bounds of a combobox). Now I am reasonably confident that this is not
possible, so I removed this TODO item.
> > - Recognize no/empty title.
>
> Title may be declared. Make it support for non showing it, like::
>
> let demoform = g:forms#form.new('Address Entry Form', 1)
>
> To show it and 0 for non showing it.
What is the use of declaring it when not showing? Are you thinking of it
as an identifier, like a name for fields?
> One change which would be good to introduce before official beta:
> obligatory fields. As I wrote earlier - full validation if possible but
> laborious. And declaring it in API should allow for some emphasis
> (highlighting?).
Does the new isValid() callback meet your expectations?
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
