Re: Built-in Maps
On 27/08/08 06:05, Bill McCarthy wrote:
> On Tue 26-Aug-08 7:25pm -0600, Tony Mechelynck wrote:
>
>> --
>> Ah! I found them !
>> --
>> see ":help dos-standard-mappings"
>
> Thanks Tony! I've revised my _vimrc correction to work fine
> for Vim as well as Gvim:
>
> " Remove the not useful select mode versions
> sunmap
> if has("GUI")
>sunmap
>sunmap
>sunmap
>sunmap
> else
>sunmap
>sunmap
>sunmap
>sunmap
>" and these strange mappings
>unmap!
>unmap!
>unmap
>unmap
> endif
>
For Windows this is OK (I think), but remember (just in case) that on
Unix/Linux a single executable can work either in Console mode or GUI
mode. There, has('gui') and has('gui_running') are different:
has('gui')
GUI capability is compiled-in
has('gui_running')
we are in the GUI, or about to start it
In addition, on Unix/Linux you can start a GUI-enabled Vim in Console
mode and later start the GUI with ":gui". In that case your vimrc will
already have been sourced with !has('gui_running'), but sourcing the
gvimrc, triggering the GUIEnter event starting the GUI, and possibly
forking from the console terminal, will all happen as a result of the
":gui" command (and with has('gui_running') on). (Personally I don't use
that copmmand, but some other people sometimes do.)
In all GUI versions, the 'term' setting is set to builtin_gui when
starting the GUI. The termcap settings (including e.g. the visualbell
screen code) are then changed and maybe also the "default Dos/Windows
mappings". In that case undoing the default GUI mappings in the vimrc
could be too soon, in that case you can use either a gvimrc or a
GUIEnter autocommand.
Best regards,
Tony.
--
This is for all ill-treated fellows
Unborn and unbegot,
For them to read when they're in trouble
And I am not.
-- A. E. Housman
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
Markus Heidelberg wrote: > Tony Mechelynck, 24.08.2008: > > > > OTOH, I would have nothing against both above-mentioned patches being > > incorporated into the mainline sources, Bill's patch as part of the > > +float feature, and your relative-numbers patch either as standard or as > > another optional feature (I suppose the latter would imply bracketing > > all its changes in #ifdef directives but it might be the better choice). > > But of course Bram has the final say on this matter. > > If encapsulating the feature in #ifdef directives would be required > for mainline, I would do it. But I don't think it's the better choice. > It is a small feature and by using #ifdef the source code would be > split up even though much of the environment already exists because of > the 'number' option. I think it's a good idea to have a central place to find Vim patches. www.vim.org would be the right place for them. I don't want to add the actual source code there (unless it's a relatively small patch file). It's better for each modification to have their own site, with CVS/Subversion, docs, etc. The central place would be listing the available patches, description and a link to the site where it can be downloaded. Perhaps it's sufficient to add them to the scripts, with a special type. And instead of a download you would have a link to the external site. -- hundred-and-one symptoms of being an internet addict: 10. And even your night dreams are in HTML. /// 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/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Built-in Maps
On Tue 26-Aug-08 7:25pm -0600, Tony Mechelynck wrote:
> --
> Ah! I found them !
> --
> see ":help dos-standard-mappings"
Thanks Tony! I've revised my _vimrc correction to work fine
for Vim as well as Gvim:
" Remove the not useful select mode versions
sunmap
if has("GUI")
sunmap
sunmap
sunmap
sunmap
else
sunmap
sunmap
sunmap
sunmap
" and these strange mappings
unmap!
unmap!
unmap
unmap
endif
--
Best regards,
Bill
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: String comparing
Oh, I did not know that ignorecase will effect operator. Thank you, Ben & Matt, in fact ==# is what I need. -Xiaoyu On Wed, Aug 27, 2008 at 12:45 AM, Matt Wozniski <[EMAIL PROTECTED]> wrote: > > On Tue, Aug 26, 2008 at 7:47 AM, Xiaoyu ZHANG wrote: >> >> Here is a simple script >> >> >> $ cat x.vim >> if 'a' == 'A' >> echoe "equal." >> endif >> >> >> When i try source it (v7.2), i got this >> >> :so x.vim >> Error detected while processing x.vim: >> line2: >> equal. >> Press ENTER or type command to continue >> >> >> So comparison of string variable is not caps-sensitive? Is this okay? > > A simpler test case: > ~> vim -u NONE -N --cmd "echo 'a' == 'A'" --cmd q > 0 > ~> vim -u NONE -N --cmd "set ignorecase" --cmd "echo 'a' == 'A'" --cmd q > 1 > > This behavior isn't really expected, I'll grant you, but it is > documented - see :help expr-== > > ~Matt > > > > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Built-in Maps
On 27/08/08 01:43, Bill McCarthy wrote:
> On Tue 26-Aug-08 6:26pm -0600, Tony Mechelynck wrote:
>
>> On 27/08/08 01:07, Bill McCarthy wrote:
>>> Hello Vim Developers,
>>>
>>> I've noticed that some mappings are built into Gvim and Vim.
>>> Here are the ones built into Gvim (from the output of:
>>> :map|map!) - if it matters, I'm running under Windows XP:
>>>
>>> v "*d
>>> v "*d
>>> v "*d
>>> v "*y
>>> v "-d"*P
>>> n "*P
>>> ! *
>>>
>>> The following are the built-in maps for Vim:
>>>
>>> v "-d
>>> nv
>>> nv
>>> v ÎØ"*d
>>> v Î×"*d
>>> v ÎÕ"*y
>>> v ÎÔ"-d"*P
>>> n ÎÔ"*P
>>> !
>>> !
>>> i ÎÔ*
>>>
>>> The Gvim maps remind of some Windows shortcuts that have
>>> apparently been borrowed by Bram. Those 5 vmaps are quite
>>> odd. They should work fine as xmaps but we'll not behave as
>>> intended as smaps. To fix this problem, I've added to my
>>> _vimrc:
>>>
>>> sunmap
>>> if has("gui")
>>> sunmap
>>> sunmap
>>> sunmap
>>> sunmap
>>> endif
>>>
>>> The maps in the has("gui") can't be unmapped that way in
>>> Vim. Also, what is being accomplished by mapping
>>> and to themselves?
>>>
>> I suspect they are set by some script; maybe mswin.vim or maybe some
>> "system vimrc":
>>
>> 1. Try starting Vim by typing
>>
>> vim -N -u NONE
>> or
>> gvim -N -u NONE
>
> That's how I started to capture only the maps I show above
> (and yes I used redir with "verb map" and "verb map!" to do
> it). There are no script files involved.
>
>> This will tell you where all these mappings came from. The strange
>> two-character {lhs}es might represent Alt-key chords.
>
> Yes they are. I can see them with:
>
> vmap
>
> which is a bit strange for,, and
> .
I agree.
>
> sunmap
>
> gives: E31: No such mapping
If several mappings' {lhs}es _begin_ with Alt-N, you'll see them with
:map
or
:map!
but to undo them you'll have to give the exact {lhs}es. Or else, you
should be able to undo _all_ mappings by adding
silent mapclear
silent mapclear!
at the top of your vimrc and again of your gvimrc if you have one (or at
the GUIEnter event if you don't). However ":help :mapclear" says
"Warning: This also removes the default mappings." I suppose those
"default mappings" are, on Windows, the ones you found, and that my vim
for Linuw/X11/GTK2 doesn't have any (see below).
Here's what I see on Linux:
vim -N -u NONE
:map
No mapping found
:map!
No mapping found
gvim -N -u NONE
:map
No mapping found
:map!
No mapping found
--
Ah! I found them !
--
see ":help dos-standard-mappings"
Best regards,
Tony.
--
If entropy is increasing, where is it coming from?
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Built-in Maps
On Tue 26-Aug-08 6:26pm -0600, Tony Mechelynck wrote:
>
> On 27/08/08 01:07, Bill McCarthy wrote:
>> Hello Vim Developers,
>>
>> I've noticed that some mappings are built into Gvim and Vim.
>> Here are the ones built into Gvim (from the output of:
>> :map|map!) - if it matters, I'm running under Windows XP:
>>
>> v "*d
>> v"*d
>> v"*d
>> v "*y
>> v "-d"*P
>> n "*P
>> ! *
>>
>> The following are the built-in maps for Vim:
>>
>> v "-d
>> nv
>> nv
>> v ÎØ"*d
>> v Î×"*d
>> v ÎÕ"*y
>> v ÎÔ"-d"*P
>> n ÎÔ"*P
>> !
>> !
>> i ÎÔ*
>>
>> The Gvim maps remind of some Windows shortcuts that have
>> apparently been borrowed by Bram. Those 5 vmaps are quite
>> odd. They should work fine as xmaps but we'll not behave as
>> intended as smaps. To fix this problem, I've added to my
>> _vimrc:
>>
>> sunmap
>> if has("gui")
>>sunmap
>>sunmap
>>sunmap
>>sunmap
>> endif
>>
>> The maps in the has("gui") can't be unmapped that way in
>> Vim. Also, what is being accomplished by mapping
>> and to themselves?
>>
>
> I suspect they are set by some script; maybe mswin.vim or maybe some
> "system vimrc":
>
> 1. Try starting Vim by typing
>
> vim -N -u NONE
> or
> gvim -N -u NONE
That's how I started to capture only the maps I show above
(and yes I used redir with "verb map" and "verb map!" to do
it). There are no script files involved.
> This will tell you where all these mappings came from. The strange
> two-character {lhs}es might represent Alt-key chords.
Yes they are. I can see them with:
vmap
which is a bit strange for , , and
.
sunmap
gives: E31: No such mapping
--
Best regards,
Bill
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Built-in Maps
On 27/08/08 01:07, Bill McCarthy wrote:
> Hello Vim Developers,
>
> I've noticed that some mappings are built into Gvim and Vim.
> Here are the ones built into Gvim (from the output of:
> :map|map!) - if it matters, I'm running under Windows XP:
>
> v "*d
> v"*d
> v"*d
> v "*y
> v "-d"*P
> n "*P
> ! *
>
> The following are the built-in maps for Vim:
>
> v "-d
> nv
> nv
> v ÎØ"*d
> v Î×"*d
> v ÎÕ"*y
> v ÎÔ"-d"*P
> n ÎÔ"*P
> !
> !
> i ÎÔ*
>
> The Gvim maps remind of some Windows shortcuts that have
> apparently been borrowed by Bram. Those 5 vmaps are quite
> odd. They should work fine as xmaps but we'll not behave as
> intended as smaps. To fix this problem, I've added to my
> _vimrc:
>
> sunmap
> if has("gui")
>sunmap
>sunmap
>sunmap
>sunmap
> endif
>
> The maps in the has("gui") can't be unmapped that way in
> Vim. Also, what is being accomplished by mapping
> and to themselves?
>
I suspect they are set by some script; maybe mswin.vim or maybe some
"system vimrc":
1. Try starting Vim by typing
vim -N -u NONE
or
gvim -N -u NONE
at the cmd.exe prompt (you may have to cd first to the directory
containing the executable). I expect you won't find any of those maps
after (g)vim starts this way, showing that none of those maps are
"built-in".
2. After starting your (g)vim normally (i.e. the way you usually do), type
:redir @"
:set nomore
:verbose map
:redir END
:set more
:new
:0put
This will tell you where all these mappings came from. The strange
two-character {lhs}es might represent Alt-key chords.
Best regards,
Tony.
--
There was a young fellow named Bliss
Whose sex life was strangely amiss,
For even with Venus
His recalcitrant penis
Would never do better than t
h
i
s
.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: reverse recursive .vimrc
On 26/08/08 15:11, Paul LeoNerd Evans wrote: [...] > Similarly, I like to allow the possibility of arbitrary code in > such .vimrc files. Perhaps my company's style guides require 4 space > indents in code written on Tuesday, and 3 every other day? Silly I know; > but if you can allow that sort of behaviour, then you should be able to > account for any -sensible- one :) > Yeah, what about code rush-written by night, started on Monday at about 22:00 and ended on Tuesday at 4 a.m.? ;-) Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 148. You find it easier to dial-up the National Weather Service Weather/your_town/now.html than to simply look out the window. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Built-in Maps
Hello Vim Developers,
I've noticed that some mappings are built into Gvim and Vim.
Here are the ones built into Gvim (from the output of:
:map|map!) - if it matters, I'm running under Windows XP:
v "*d
v "*d
v "*d
v "*y
v "-d"*P
n "*P
! *
The following are the built-in maps for Vim:
v "-d
nv
nv
v ÎØ"*d
v Î×"*d
v ÎÕ"*y
v ÎÔ"-d"*P
n ÎÔ"*P
!
!
i ÎÔ*
The Gvim maps remind of some Windows shortcuts that have
apparently been borrowed by Bram. Those 5 vmaps are quite
odd. They should work fine as xmaps but we'll not behave as
intended as smaps. To fix this problem, I've added to my
_vimrc:
sunmap
if has("gui")
sunmap
sunmap
sunmap
sunmap
endif
The maps in the has("gui") can't be unmapped that way in
Vim. Also, what is being accomplished by mapping
and to themselves?
--
Best regards,
Bill
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
Tony Mechelynck, 26.08.2008:
>
> On 26/08/08 23:38, Markus Heidelberg wrote:
> > Tony Mechelynck, 24.08.2008:
> >> OTOH, I would have nothing against both above-mentioned patches being
> >> incorporated into the mainline sources, Bill's patch as part of the
> >> +float feature, and your relative-numbers patch either as standard or as
> >> another optional feature (I suppose the latter would imply bracketing
> >> all its changes in #ifdef directives but it might be the better choice).
> >> But of course Bram has the final say on this matter.
> >
> > If encapsulating the feature in #ifdef directives would be required for
> > mainline, I would do it. But I don't think it's the better choice. It is a
> > small feature and by using #ifdef the source code would be split up even
> > though much of the environment already exists because of the 'number'
> > option.
> >
> > Markus
>
> Well, #ifdef's would be needed if this feature is included as optional
> (meaning you can include or exclude it at compile-time and test for it
> with has()). If the fature is included as standard they aren't
> necessary, but maybe Bram won't want to include as standard, or maybe
> not at all, we'll see. In any case, the availability can still be tested
> with exists('+relativenumber') or something (name of the option with a
> plus sign) and anyone using the feature should test it this way until
> any builds without it are hopelessly obsolete (if ever).
>
> Best regards,
> Tony.
Yes, I've already understand you in your last mail.
optional feature -> #ifdef FEAT_RELATIVENUMBER -> +-relativenumber
But I think that wouldn't beautify the source code and would be overhead for
just a single option.
Currently I use exists("&rnu") to be able to use the self-compiled and the
distribution (well, Gentoo, also self-compiled) Vim.
Markus
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
Ben Fritz, 25.08.2008: > > I have not tried the patch, because it is too much trouble for me to > compile my own Vim on Windows. Yes, I'm on vim-dev, but a lot of > vimscript stuff and discussion of features/bugs happens that does not > require me to compile my own Vim or try out 3rd-party patches. Yes, of course, vim-dev is not restricted to C source development. > All this being said, I would certainly _prefer_ if this feature were a > built-in option rather than a vimscript plugin. It would be faster (I > have some speed issues when using it on large files with as many lines > as possible showing on my rotated monitor), Only then? It seems as if I had a really old machine (from 2002). For me it's not usable for example in gvim, even if syntax highlighting is off. But why the big performance difference between vim and gvim? > it would allow you to > easily detect whether it was active (with &relnu or something), and I > wouldn't need to bother checking yet another thing for updates on a > regular basis. So, keep the patch around and keep it updated, in the > hopes that someday, somehow, it gets integrated into the main line. I will do that. Markus --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
On 26/08/08 23:38, Markus Heidelberg wrote:
> Tony Mechelynck, 24.08.2008:
>> OTOH, I would have nothing against both above-mentioned patches being
>> incorporated into the mainline sources, Bill's patch as part of the
>> +float feature, and your relative-numbers patch either as standard or as
>> another optional feature (I suppose the latter would imply bracketing
>> all its changes in #ifdef directives but it might be the better choice).
>> But of course Bram has the final say on this matter.
>
> If encapsulating the feature in #ifdef directives would be required for
> mainline, I would do it. But I don't think it's the better choice. It is a
> small feature and by using #ifdef the source code would be split up even
> though much of the environment already exists because of the 'number' option.
>
> Markus
Well, #ifdef's would be needed if this feature is included as optional
(meaning you can include or exclude it at compile-time and test for it
with has()). If the fature is included as standard they aren't
necessary, but maybe Bram won't want to include as standard, or maybe
not at all, we'll see. In any case, the availability can still be tested
with exists('+relativenumber') or something (name of the option with a
plus sign) and anyone using the feature should test it this way until
any builds without it are hopelessly obsolete (if ever).
Best regards,
Tony.
--
Winter is the season in which people try to keep the house as warm as
it was in the summer, when they complained about the heat.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
Charles Campbell, 24.08.2008: > > I'll update the link to your patch (when I get a chance -- I'm still > updating vim on this machine+o/s). I hope you don't consider my plugin > a competitor, I thought of it as more of a step towards your patch (whet > folks' appetites, as it were) -- and maybe even as justification for > your patch given enough interest. Anyway, that's why I included the > link to your patch. Yes, the interest increased indeed. Thanks for your plugin and for linking to the patch. Markus --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
Tony Mechelynck, 24.08.2008: > > OTOH, I would have nothing against both above-mentioned patches being > incorporated into the mainline sources, Bill's patch as part of the > +float feature, and your relative-numbers patch either as standard or as > another optional feature (I suppose the latter would imply bracketing > all its changes in #ifdef directives but it might be the better choice). > But of course Bram has the final say on this matter. If encapsulating the feature in #ifdef directives would be required for mainline, I would do it. But I don't think it's the better choice. It is a small feature and by using #ifdef the source code would be split up even though much of the environment already exists because of the 'number' option. Markus --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: reverse recursive .vimrc
On Aug 26, 1:45 pm, Paul LeoNerd Evans <[EMAIL PROTECTED]> wrote: > On Mon, 25 Aug 2008 14:45:24 -0700 (PDT) > > fnegroni <[EMAIL PROTECTED]> wrote: > > I am about to embark in developing such feature for vim and will make > > it available as a patch, if there isn't one already available. > > I wrote one: > > http://www.leonerd.org.uk/hacks/vim/additionalrc.html > Brilliant! I will try out your patch and let you know how I get on with it. Is there a place on the vim website where all these patches are advertised? --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] missing parenthesis in runtime/doc/pattern.txt
Attached patch fixes a missing parenthesis in runtime/doc/pattern.txt in Vim-7.2. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: pattern.txt === RCS file: /cvsroot/vim/vim7/runtime/doc/pattern.txt,v retrieving revision 1.38 diff -c -r1.38 pattern.txt *** pattern.txt 9 Aug 2008 17:43:14 - 1.38 --- pattern.txt 26 Aug 2008 20:32:20 - *** *** 507,513 |/\Z| \Z \Z ignore differences in Unicode "combining characters". Useful when searching voweled Hebrew or Arabic text. ! |/\%d| \%d \%d match specified decimal character (eg \%d123 |/\%x| \%x \%x match specified hex character (eg \%x2a) |/\%o| \%o \%o match specified octal character (eg \%o040) |/\%u| \%u \%u match specified multibyte character (eg \%u20ac) --- 507,513 |/\Z| \Z \Z ignore differences in Unicode "combining characters". Useful when searching voweled Hebrew or Arabic text. ! |/\%d| \%d \%d match specified decimal character (eg \%d123) |/\%x| \%x \%x match specified hex character (eg \%x2a) |/\%o| \%o \%o match specified octal character (eg \%o040) |/\%u| \%u \%u match specified multibyte character (eg \%u20ac)
Re: ANNC: Relative Numbering plugin
On Aug 25, 11:05 am, Ben Fritz <[EMAIL PROTECTED]> wrote: > On Aug 25, 10:29 am, Charles Campbell <[EMAIL PROTECTED]> > wrote: > > > OK -- I've made a reporting-only variable, g:rltvnmbrmode (=1 enabled, > > =0 disabled) for this purpose (v3b). > > Hey, thanks! > > Should that be b:rltvnmbrmode, since signs (and therefore the plugin) > work local to a buffer? > > As you've stated, the best implementation would be window-local, but > limitations in signs prevent that. I noticed that v3e on your website does this. I downloaded it this morning, but it appears to have a problem in that b:rltvnmbrmode does not exist before calling :RltvNmbr (meaning that :RN fails unless you call RltvNmbr first). Unless you uploaded a new 3e without changing the version number.. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Comparing file names
On Mon, 25 Aug 2008 16:39:12 -0400, "James Vega" <[EMAIL PROTECTED]> wrote: > On Mon, Aug 25, 2008 at 4:21 PM, Tony Mechelynck > <[EMAIL PROTECTED]> wrote: > > > > The question is not to determine which other files, if any, are > > hardlinked to a specific file (which might require scanning all > > directories on the whole partition the way some disk integrity checking > > programs do), it is just to determine whether two given pathfilenames > > point to the same disk area (which ought to require only a comparison of > > "where their directory entries point to"). > > Which is simply a subset of my general statement in my previous email. > There is no way to determine this simply from pathnames. In fact, the > only way to determine this, at least under Linux, is to check whether > they have the same inode. I'm not sure how you would do so for other > OSes. The same device number and inode number, to be precise. -- Matthew Winn --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: String comparing
On Aug 26, 6:47 am, "Xiaoyu ZHANG" <[EMAIL PROTECTED]> wrote: > Here is a simple script > > > $ cat x.vim > if 'a' == 'A' > echoe "equal." > endif > > > When i try source it (v7.2), i got this > > :so x.vim > Error detected while processing x.vim: > line 2: > equal. > Press ENTER or type command to continue > > > So comparison of string variable is not caps-sensitive? Is this okay? > > Regards, > Xiaoyu You should read through the table just under :help expr-== There you will see that == uses the value of 'ignorecase', ==# is case- sensitive, and ==? ignores case. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: String comparing
On Tue, Aug 26, 2008 at 7:47 AM, Xiaoyu ZHANG wrote: > > Here is a simple script > > > $ cat x.vim > if 'a' == 'A' > echoe "equal." > endif > > > When i try source it (v7.2), i got this > > :so x.vim > Error detected while processing x.vim: > line2: > equal. > Press ENTER or type command to continue > > > So comparison of string variable is not caps-sensitive? Is this okay? A simpler test case: ~> vim -u NONE -N --cmd "echo 'a' == 'A'" --cmd q 0 ~> vim -u NONE -N --cmd "set ignorecase" --cmd "echo 'a' == 'A'" --cmd q 1 This behavior isn't really expected, I'll grant you, but it is documented - see :help expr-== ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Moving cursor to start of current word
Robert Webb schrieb:
>>>:silent! normal! heb
>> Won't work if the word is a single character.
>
> Also won't work at the start of this text: "== blah".
> The idea is to put the cursor at the start of the word that
> expand("") would return.
>
> This works quite well:
>
> func! Sow()
> if (getline(".")[col(".") - 1] =~ '\k')
> normal wb
> else
> call search('\<', 'sW')
> endif
> endfunc
>
> Except that it may search onto the next line if there are no more words,
> and won't find a non-word sequence at the end of the line if no words exist.
This will find a non-word sequence at the end of the line if no words exist
(improvement of my first function):
func! Sow(vmode)
if a:vmode
normal! gv
endif
let xw = expand("")
if xw != ""
if xw =~ '\k'
call search('\k\>','cW')
else
call search('[EMAIL PROTECTED]','cW')
endif
if strlen(xw) > 1
normal! b
endif
endif
endfunc
>
> Rob.
--
Andy
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: String comparing (2)
Hi, On 26.08.2008, at 13:58, Xiaoyu ZHANG wrote: > Here is a simple script > > > $ cat x.vim > if 'a' == 'A' > echoe "equal." > endif > > > When i try source it (v7.2), i got this > > :so x.vim > Error detected while processing x.vim: > line2: > equal. > Press ENTER or type command to continue > > > So comparison of string variable is not caps-sensitive? Is this okay? == acts according to 'ignorecase'. Use ==# to always compare case- sensitively. See `:h ==#` for more information. HTH, Nico --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
String comparing
Here is a simple script $ cat x.vim if 'a' == 'A' echoe "equal." endif When i try source it (v7.2), i got this :so x.vim Error detected while processing x.vim: line2: equal. Press ENTER or type command to continue So comparison of string variable is not caps-sensitive? Is this okay? Regards, Xiaoyu --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
String comparing (2)
I'm afraid I mistake the mail-alias in last mail. :( Here is a simple script $ cat x.vim if 'a' == 'A' echoe "equal." endif When i try source it (v7.2), i got this :so x.vim Error detected while processing x.vim: line2: equal. Press ENTER or type command to continue So comparison of string variable is not caps-sensitive? Is this okay? P.S. anyone could tell me the difference between vim_dev@googlegroups.com & [EMAIL PROTECTED] ? Regards, Xiaoyu --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: reverse recursive .vimrc
fnegroni wrote:
> There is a feature in Perforce, which allows the command line client
> (p4) to find its configuration file (.p4rc) by looking up the current
> directory and any directory above it in recursive order, stopping at
> the first one that has a .p4rc file in it. If that fails, it falls
> back to the one in the user's home directory (if there is one).
>
> It is a feature that I implemented in one of my applications recently
> (Kelp).
>
> It is a feature that I would absolutely love to have: I develop for
> several projects following different indentation styles and
> visualisation rules.
>
>
Here's some vim script to do it (loads .vimrc and tags): (unix only)
if has("unix") && getcwd() != topdir && strlen(getcwd()) > strlen(topdir)
" source any local .vimrc at the current directory or above, not
including $HOME
let vimrc=
findfile('.vimrc',getcwd().';'.substitute(getcwd(),'\('.topdir.'/[^/]\+/\).\{-}$','\1',''))
if vimrc != ""
exe "so ".vimrc
endif
" set up tags to include any and all tags files in the current
directory up to and including $HOME
" exe "set tags=".getcwd().";".expand("$HOME").",".expand("$HDR")."/tags"
let tagfiles= findfile('tags',getcwd().';'.expand("$HOME"),-1)
set tags=
for tagfile in tagfiles
exe "set tags+=".tagfile
endfor
exe "set tags+=".expand("$HDR")."/tags,".expand("$HDR")."/SYSTEM/tags"
endif
Regards,
Chip Campbell
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: reverse recursive .vimrc
On Tue, 26 Aug 2008 14:01:12 +0100 "Jan Minář" <[EMAIL PROTECTED]> wrote: > Let me ask: What are the commands you (would) > put in that .vimrc? What are the problems you are trying to fix? I find it's usually stylistic issues. Quite often I'll be changing things like shiftwidth, expandtabs, some of the comment/formatting options. I did consider some stripped-down way of specifying just a few known-safe settings. But I'm not sure I like that as a solution. I'm a big fan of the /etc/default/ way of configuring system services, where the settings are the environment variables left by "source"ing a shell script. This gives full Turing-completeness to any settings. There was a time I ran a mixed Linux 2.4 / 2.6 setup, where sometimes I'd boot different kernels. I had a weird bug in a service that needed different config on each kernel. This made it trivial source /etc/default/fooservice.`uname -r` Similarly, I like to allow the possibility of arbitrary code in such .vimrc files. Perhaps my company's style guides require 4 space indents in code written on Tuesday, and 3 every other day? Silly I know; but if you can allow that sort of behaviour, then you should be able to account for any -sensible- one :) -- Paul "LeoNerd" Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: reverse recursive .vimrc
On Tue, 26 Aug 2008 14:01:12 +0100 "Jan Minář" <[EMAIL PROTECTED]> wrote: > This is inherently insecure. I am aware of this; I make it very clear. Drop a .vimrc saying let g:additionalrc_stop = 1 in the innermost-nested place you can that's still safe, and all is OK. Fail to do that, and On Your Head Be It. E.g. $ bzr checkout http://some.dodgy.hacker.com/weird/code $ cat >.vimrc let g:additionalrc_stop = 1 ^D I can now be sure that none of dodgy hacker's .vimrc files will take any effect, because the one I wrote as a sibling of his checked out directory tells it to stop. I realise you can easily forget to do this. I realise you can easily forget to lock your front door at night, and have gun-wielding drunken drug-dealers wander in off the street. As long as you know this and are happy to take that risk, is that good enough? -- Paul "LeoNerd" Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: reverse recursive .vimrc
On Tue, Aug 26, 2008 at 1:45 PM, Paul LeoNerd Evans <[EMAIL PROTECTED]> wrote: > On Mon, 25 Aug 2008 14:45:24 -0700 (PDT) > fnegroni <[EMAIL PROTECTED]> wrote: > >> I am about to embark in developing such feature for vim and will make >> it available as a patch, if there isn't one already available. > > I wrote one: > > http://www.leonerd.org.uk/hacks/vim/additionalrc.html This is inherently insecure. Doesn't really matter how hard you try to make it less insecure, it still make Vim vulnerable to executing Ex commands guised as a helpful .vimrc. However. This seems like a useful feature. It may be that there is no way to implement it without compromising security, but I'd rather think there is one. Let me ask: What are the commands you (would) put in that .vimrc? What are the problems you are trying to fix? Cheers, Jan. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Moving cursor to start of current word
I wrote:
> This works quite well:
>
> func! Sow()
> if (getline(".")[col(".") - 1] =~ '\k')
> normal wb
> else
> call search('\<', 'sW')
> endif
> endfunc
Or even better:
func! StartOfWord()
call search('.\>', 'cWs')
call search('\<', 'cWb')
endfunc
Rob.
--
Robert Webb <[EMAIL PROTECTED]>,
Want to make polyhedra?
http://www.software3d.com/Stella.php
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: reverse recursive .vimrc
On Mon, 25 Aug 2008 14:45:24 -0700 (PDT) fnegroni <[EMAIL PROTECTED]> wrote: > I am about to embark in developing such feature for vim and will make > it available as a patch, if there isn't one already available. I wrote one: http://www.leonerd.org.uk/hacks/vim/additionalrc.html -- Paul "LeoNerd" Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
