I have been using vim for past 2,3 years, but there are still some issues i am not able to come over.
I find it really convenient to have windows managed manually. I tried buffkill for some time,
but it doesn't work always as expected.
To be more precise, lets say i am working on something, and i have 2 splits, one for editing source file,
and one for editing test file. Often i have to open something else so i override whichever split window with new one, and when i delete that buffer i loose windows split, this is what i didn't want, i know to close window, but why does deleting a buffer has to close a window? and i haven't found how to overcome elegantly. Anyone could suggest me a good approach?
Ideally i would delete that new buffer and get a previous buffer i was working on.
This weird behavior also occurs to me using Nerdtree, I open new vim instance, i toggle nerdtree open a file, i bd, i still have window from that deleted buffer, but when i open file again and bd, i loose that window. And i am left with nerdtree window only.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Tuesday, December 31, 2013
Re: Can not paste with Shift-Insert with gvim
On 12/31/2013 02:44 PM, Tony Mechelynck wrote:
> Instead of these mappings, you can of course just insert register +
> (which is the clipboard) in the normal way, either with the keyboard
> (using key sequences similar to the {rhs}es above) or with the "Edit →
> Paste" menu.
Maybe it's about time to press <C-r>+ more. :)
> I suppose that the fact that it still works in a terminal means that
> your terminal is handling it.
You're right.
--
PHAM Van Diep
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> Instead of these mappings, you can of course just insert register +
> (which is the clipboard) in the normal way, either with the keyboard
> (using key sequences similar to the {rhs}es above) or with the "Edit →
> Paste" menu.
Maybe it's about time to press <C-r>+ more. :)
> I suppose that the fact that it still works in a terminal means that
> your terminal is handling it.
You're right.
--
PHAM Van Diep
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Where is my system-wide init file?
On 31/12/13 12:40, Erik Christiansen wrote:
> On 31.12.13 10:18, Tony Mechelynck wrote:
>> On 31/12/13 09:34, Erik Christiansen wrote:
>>> $ grep which .bashrc
>>> alias which='type -a' # Checks aliases & functions also.
>>
>> The problem with this alias, IIUC, is when one tries to use
>>
>> vim `which somecommand`
>>
>> to edit an executable script, since the output of "type" is in a different
>> format.
>
> Sort of. Making "which" a helpful tool and convenient mnemonic for the
> vast majority of general use cases, makes it unsuited to that one, but
> not merely due to format. On this host, without looking further than
> "which" itself, it finds several (prioritised) alternatives:
>
> $ which which
> which is aliased to `type -a'
> which is /usr/bin/which
> which is /bin/which
>
> I'm not too sure how a command should mind-read which of several
> alternatives we'd prefer to examine, now that we know what's there. OK,
> sometimes picking the one which has path priority will be the right one.
Without -a (aka --all) it gives only the first one in the $PATH.
> So I'd have to go with your second strategy:
>
>> I suppose you would have to do
>>
>> vim `/usr/bin/which somecommand`
>>
>> instead (at least on my system, which is in /usr/bin, not in plain /bin) to
>> bypass the alias, or else do it manually:
>>
>> which somecommand # aliased to type -a
>> vim ~/bin/somecommand
>
> If we want to tweak the command with path priority, then we'd need to
> vim .bashrc, to get at the alias. But if we wanted to examine the
> underlying shell script which constitutes "which", then it'd be
> vim /bin/which, since /usr/bin/which is just a link to that anyway.
Not here:
linux:~ # type -a which
which is /usr/bin/which
which is /usr/bin/X11/which
linux:~ # ls -l /usr/bin/X11
lrwxrwxrwx 1 root root 1 Jul 13 17:13 /usr/bin/X11 -> ./
linux:~ # ls -l /usr/bin/which
-rwxr-xr-x 1 root root 23144 Nov 5 2012 /usr/bin/which*
linux:~ # ls -l /bin/which
ls: cannot access /bin/which: No such file or directory
>
> Finding stuff in the filesystem is, at least here, a greater challenge
> than invoking vim on a specific file, so maximising transparency has the
> greater payoff, I find. Making an informed choice on which alternative
> to edit seems to beat a tiny bit of automation, I figure. But needs
> differ, I'll accept.
>
> Here's wishing a happy new year to all Vimmers. (Under an hour and a half
> away here.)
>
> Erik
>
Sure, happy new year to you all, though on _my_ clock it's only about
13:02 on the 31 as I type this.
Best regards,
Tony.
--
The makers may make
and the users may use,
but the fixers must fix
with but minimal clues
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On 31.12.13 10:18, Tony Mechelynck wrote:
>> On 31/12/13 09:34, Erik Christiansen wrote:
>>> $ grep which .bashrc
>>> alias which='type -a' # Checks aliases & functions also.
>>
>> The problem with this alias, IIUC, is when one tries to use
>>
>> vim `which somecommand`
>>
>> to edit an executable script, since the output of "type" is in a different
>> format.
>
> Sort of. Making "which" a helpful tool and convenient mnemonic for the
> vast majority of general use cases, makes it unsuited to that one, but
> not merely due to format. On this host, without looking further than
> "which" itself, it finds several (prioritised) alternatives:
>
> $ which which
> which is aliased to `type -a'
> which is /usr/bin/which
> which is /bin/which
>
> I'm not too sure how a command should mind-read which of several
> alternatives we'd prefer to examine, now that we know what's there. OK,
> sometimes picking the one which has path priority will be the right one.
Without -a (aka --all) it gives only the first one in the $PATH.
> So I'd have to go with your second strategy:
>
>> I suppose you would have to do
>>
>> vim `/usr/bin/which somecommand`
>>
>> instead (at least on my system, which is in /usr/bin, not in plain /bin) to
>> bypass the alias, or else do it manually:
>>
>> which somecommand # aliased to type -a
>> vim ~/bin/somecommand
>
> If we want to tweak the command with path priority, then we'd need to
> vim .bashrc, to get at the alias. But if we wanted to examine the
> underlying shell script which constitutes "which", then it'd be
> vim /bin/which, since /usr/bin/which is just a link to that anyway.
Not here:
linux:~ # type -a which
which is /usr/bin/which
which is /usr/bin/X11/which
linux:~ # ls -l /usr/bin/X11
lrwxrwxrwx 1 root root 1 Jul 13 17:13 /usr/bin/X11 -> ./
linux:~ # ls -l /usr/bin/which
-rwxr-xr-x 1 root root 23144 Nov 5 2012 /usr/bin/which*
linux:~ # ls -l /bin/which
ls: cannot access /bin/which: No such file or directory
>
> Finding stuff in the filesystem is, at least here, a greater challenge
> than invoking vim on a specific file, so maximising transparency has the
> greater payoff, I find. Making an informed choice on which alternative
> to edit seems to beat a tiny bit of automation, I figure. But needs
> differ, I'll accept.
>
> Here's wishing a happy new year to all Vimmers. (Under an hour and a half
> away here.)
>
> Erik
>
Sure, happy new year to you all, though on _my_ clock it's only about
13:02 on the 31 as I type this.
Best regards,
Tony.
--
The makers may make
and the users may use,
but the fixers must fix
with but minimal clues
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Where is my system-wide init file?
On 31.12.13 10:18, Tony Mechelynck wrote:
> On 31/12/13 09:34, Erik Christiansen wrote:
> >$ grep which .bashrc
> >alias which='type -a' # Checks aliases & functions also.
>
> The problem with this alias, IIUC, is when one tries to use
>
> vim `which somecommand`
>
> to edit an executable script, since the output of "type" is in a different
> format.
Sort of. Making "which" a helpful tool and convenient mnemonic for the
vast majority of general use cases, makes it unsuited to that one, but
not merely due to format. On this host, without looking further than
"which" itself, it finds several (prioritised) alternatives:
$ which which
which is aliased to `type -a'
which is /usr/bin/which
which is /bin/which
I'm not too sure how a command should mind-read which of several
alternatives we'd prefer to examine, now that we know what's there. OK,
sometimes picking the one which has path priority will be the right one.
So I'd have to go with your second strategy:
> I suppose you would have to do
>
> vim `/usr/bin/which somecommand`
>
> instead (at least on my system, which is in /usr/bin, not in plain /bin) to
> bypass the alias, or else do it manually:
>
> which somecommand # aliased to type -a
> vim ~/bin/somecommand
If we want to tweak the command with path priority, then we'd need to
vim .bashrc, to get at the alias. But if we wanted to examine the
underlying shell script which constitutes "which", then it'd be
vim /bin/which, since /usr/bin/which is just a link to that anyway.
Finding stuff in the filesystem is, at least here, a greater challenge
than invoking vim on a specific file, so maximising transparency has the
greater payoff, I find. Making an informed choice on which alternative
to edit seems to beat a tiny bit of automation, I figure. But needs
differ, I'll accept.
Here's wishing a happy new year to all Vimmers. (Under an hour and a half
away here.)
Erik
--
GNU's not Unix, but Unix is a beast; its plural form is Unixen.
- GNU grep 2.5.1-cvs manpage
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On 31/12/13 09:34, Erik Christiansen wrote:
> >$ grep which .bashrc
> >alias which='type -a' # Checks aliases & functions also.
>
> The problem with this alias, IIUC, is when one tries to use
>
> vim `which somecommand`
>
> to edit an executable script, since the output of "type" is in a different
> format.
Sort of. Making "which" a helpful tool and convenient mnemonic for the
vast majority of general use cases, makes it unsuited to that one, but
not merely due to format. On this host, without looking further than
"which" itself, it finds several (prioritised) alternatives:
$ which which
which is aliased to `type -a'
which is /usr/bin/which
which is /bin/which
I'm not too sure how a command should mind-read which of several
alternatives we'd prefer to examine, now that we know what's there. OK,
sometimes picking the one which has path priority will be the right one.
So I'd have to go with your second strategy:
> I suppose you would have to do
>
> vim `/usr/bin/which somecommand`
>
> instead (at least on my system, which is in /usr/bin, not in plain /bin) to
> bypass the alias, or else do it manually:
>
> which somecommand # aliased to type -a
> vim ~/bin/somecommand
If we want to tweak the command with path priority, then we'd need to
vim .bashrc, to get at the alias. But if we wanted to examine the
underlying shell script which constitutes "which", then it'd be
vim /bin/which, since /usr/bin/which is just a link to that anyway.
Finding stuff in the filesystem is, at least here, a greater challenge
than invoking vim on a specific file, so maximising transparency has the
greater payoff, I find. Making an informed choice on which alternative
to edit seems to beat a tiny bit of automation, I figure. But needs
differ, I'll accept.
Here's wishing a happy new year to all Vimmers. (Under an hour and a half
away here.)
Erik
--
GNU's not Unix, but Unix is a beast; its plural form is Unixen.
- GNU grep 2.5.1-cvs manpage
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Where is my system-wide init file?
On 31/12/13 09:34, Erik Christiansen wrote:
> On 30.12.13 08:32, Gary Johnson wrote:
>> On 2013-12-30, Tony Mechelynck wrote:
>>> On 29/12/13 21:15, Elena Garrulo wrote:
>>
>>>> Thank you for making me learn the "type" command. Cool! :-)
>>>
>>> There is also "which" which is a separate program (and thus works for
>>> all shells) but it doesn't know about shell aliases.
>>
>> The which(1) v2.20 man page recommends using a shell function
>> wrapper around which that finds aliases and functions as well.
>
> Remarkable how much good sense can be found in manpages. For the last
> quarter century or more, I've had (on every machine I touch¹):
>
> $ grep which .bashrc
> alias which='type -a' # Checks aliases & functions also.
The problem with this alias, IIUC, is when one tries to use
vim `which somecommand`
to edit an executable script, since the output of "type" is in a
different format. I suppose you would have to do
vim `/usr/bin/which somecommand`
instead (at least on my system, which is in /usr/bin, not in plain /bin)
to bypass the alias, or else do it manually:
which somecommand # aliased to type -a
vim ~/bin/somecommand
>
> (Never could understand why I should ask the shell to type thingy,
> then expect it to answer with which thingy it'd use, instead.)
>
> Alas, the 2009 Debian manpage in my Ubuntu distro lacks the wisdom
> you've found.
>
> Erik
>
> ¹ First HP-UX, then Solaris, now linux - all had "type" AFAIR.
>
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
60. As your car crashes through the guardrail on a mountain road, your first
instinct is to search for the "back" button.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On 30.12.13 08:32, Gary Johnson wrote:
>> On 2013-12-30, Tony Mechelynck wrote:
>>> On 29/12/13 21:15, Elena Garrulo wrote:
>>
>>>> Thank you for making me learn the "type" command. Cool! :-)
>>>
>>> There is also "which" which is a separate program (and thus works for
>>> all shells) but it doesn't know about shell aliases.
>>
>> The which(1) v2.20 man page recommends using a shell function
>> wrapper around which that finds aliases and functions as well.
>
> Remarkable how much good sense can be found in manpages. For the last
> quarter century or more, I've had (on every machine I touch¹):
>
> $ grep which .bashrc
> alias which='type -a' # Checks aliases & functions also.
The problem with this alias, IIUC, is when one tries to use
vim `which somecommand`
to edit an executable script, since the output of "type" is in a
different format. I suppose you would have to do
vim `/usr/bin/which somecommand`
instead (at least on my system, which is in /usr/bin, not in plain /bin)
to bypass the alias, or else do it manually:
which somecommand # aliased to type -a
vim ~/bin/somecommand
>
> (Never could understand why I should ask the shell to type thingy,
> then expect it to answer with which thingy it'd use, instead.)
>
> Alas, the 2009 Debian manpage in my Ubuntu distro lacks the wisdom
> you've found.
>
> Erik
>
> ¹ First HP-UX, then Solaris, now linux - all had "type" AFAIR.
>
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
60. As your car crashes through the guardrail on a mountain road, your first
instinct is to search for the "back" button.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: funcrefs forms
On Tue, Dec 31, 2013 at 11:28:25AM +0400, Nikolay Pavlov wrote:
> On Dec 31, 2013 11:24 AM, "Alexandre Hoïde" <alexandre.hoide@gmail.com>
> wrote:
> >
> > On Mon, Dec 30, 2013 at 10:18:21PM +0400, Nikolay Pavlov wrote:
> > > On Dec 30, 2013 5:58 PM, "Alexandre Hoïde" <alexandre.hoide@gmail.com>
> > > wrote:
> > > >
> > > > On Mon, Dec 30, 2013 at 08:55:17AM +0100, Alexandre Hoïde wrote:
> > > > > .vim <--
> > > > > function! s:SID()
> > > > > return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
> > > > > endfunction
> > > > >
> > > > > function! s:objectConstructor(name)
> > > > > let obj = {}
> > > > > let obj.name = a:name
> > > > > let obj.form1 = s:objFuncs.form1
> > > > > let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > > > > return obj
> > > > > endfunction
> > > > >
> > > > > let s:objFuncs = {}
> > > > >
> > > > > function! s:objFuncs.form1()
> > > > > echo self.name
> > > > > endfunction
> > > > >
> > > > > function! <SID>s:objFuncs_form2() dict
> > > > > echo self.name
> > > > > endfunction
> > > > >
> > > > > let otst = s:objectConstructor('test')
> > > > > call otst.form1()
> > > > > call otst.form2()
> > > > > -->
> > > >
> > > > … to be more specific, on the sample code above, the following :
> > > > <--
> > > > echo function('s:objFuncs.form1')
> > >
> > > Now please try calling this (i.e. just append ()). *function() is not a
> > > replacement for eval*. You have found function() bug, nothing more. To
> get
> > > *real* results *echo actual funcref*. As I said if you define function
> > > inside a dictionary *you already get funcref*. Thus what you need is
> just
> > > echo s:objFuncs.form1.
> > >
> > Hi and thanks again for taking some time to help. Although I allready
> > knew how to get the *real* result… thanks to your answer to my first
> > thread.
> >
> > Here, I did not put this "echo function('s:objFuncs.form1/2)" to get
> > the real result, but just to illustrate the fact that, to me, form1 and
> > form2 seems to be equivalent :
> > > > <SNR>36_objFuncs.form1
> > > > <SNR>36_s:objFuncs_form2
>
> Again, ***try calling funcref in the first form***. Funcrefs are not for
> echoing, they are for calling. First form **does not exist**. It is a
> function() bug and nothing else.
>
Ah ok ^^ Like this you mean ? :
<--
call function('s:objFuncs.form1')()
-->
E117: Unknown function: <SNR>32_objFuncs.form1
<--
call function('<SNR>' . s:SID() . '_s:objFuncs_form2')()
-->
E725: Calling dict function without Dictionary: <SNR>32_s:objFuns_form2
Ok, this function() bug increased my confusion and form1 is *not*
equivalent to form2. 's:objFuncs.form1' *is* the funcref, and
'function('s:objFuns.form1') is a non-sense (would be the funcref of a
funcref). Thanks for that clarification.
Now : in this particular context of an object constructor function,
are there any "use-case" where form2 should be used rather than form1 ?
Riml guys and you are a million years ahead of me in term of
programing. So, if they use form2 instead of form1, it means there's
something I still fail to understand. ^^ Why use a named dict function
and get a funcref later on (at the cost of verbosity), rather than
directly obtaining this funcref using form1 ?
Best regards, and thanks again for your patience ;)
> >
> > So I (still) wonder why some real developpers would use form2 (the non
> > anonymous version) rather than form1 ? I hope this claryfies my question
> > and that I understood your answer correctly. ^^
> >
> > Best regards.
> >
> > > > echo function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > > > --> Gives <--
> > > > <SNR>36_objFuncs.form1
> > > > <SNR>36_s:objFuncs_form2
> > > > -->
> > > >
> > > > Except form1 being {anonymous,numbered}-function and form2 beeing
> > > > just a dictionary-function, I don't see much difference between the 2
> > > > forms.
> > > >
> > > > The 1st form being more concise, I was wondering
> > > > a) why would someone use form2 (which I came accross on riml¹
> README).
> > > > b) what makes the anonymous form1 preferable (besides conciseness)
> > > >
> > > > ¹ https://github.com/luke-gru/riml
> > > >
> >
> > --
> > ___________________
> > | $ post_tenebras ↲ | waouh !
> > | GNU \ / | /
> > | -- * -- | o
> > | $ who ↲ / \ |_-- ~_|
> > | Alexandre Hoïde | _/| |
> > -------------------
> >
> > --
> > --
> > You received this message from the "vim_use" maillist.
> > Do not top-post! Type your reply below the text you are replying to.
> > For more information, visit http://www.vim.org/maillist.php
> >
> > ---
> > You received this message because you are subscribed to the Google Groups
> "vim_use" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_use+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
___________________
| $ post_tenebras ↲ | waouh !
| GNU \ / | /
| -- * -- | o
| $ who ↲ / \ |_-- ~_|
| Alexandre Hoïde | _/| |
-------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On Dec 31, 2013 11:24 AM, "Alexandre Hoïde" <alexandre.hoide@gmail.com>
> wrote:
> >
> > On Mon, Dec 30, 2013 at 10:18:21PM +0400, Nikolay Pavlov wrote:
> > > On Dec 30, 2013 5:58 PM, "Alexandre Hoïde" <alexandre.hoide@gmail.com>
> > > wrote:
> > > >
> > > > On Mon, Dec 30, 2013 at 08:55:17AM +0100, Alexandre Hoïde wrote:
> > > > > .vim <--
> > > > > function! s:SID()
> > > > > return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
> > > > > endfunction
> > > > >
> > > > > function! s:objectConstructor(name)
> > > > > let obj = {}
> > > > > let obj.name = a:name
> > > > > let obj.form1 = s:objFuncs.form1
> > > > > let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > > > > return obj
> > > > > endfunction
> > > > >
> > > > > let s:objFuncs = {}
> > > > >
> > > > > function! s:objFuncs.form1()
> > > > > echo self.name
> > > > > endfunction
> > > > >
> > > > > function! <SID>s:objFuncs_form2() dict
> > > > > echo self.name
> > > > > endfunction
> > > > >
> > > > > let otst = s:objectConstructor('test')
> > > > > call otst.form1()
> > > > > call otst.form2()
> > > > > -->
> > > >
> > > > … to be more specific, on the sample code above, the following :
> > > > <--
> > > > echo function('s:objFuncs.form1')
> > >
> > > Now please try calling this (i.e. just append ()). *function() is not a
> > > replacement for eval*. You have found function() bug, nothing more. To
> get
> > > *real* results *echo actual funcref*. As I said if you define function
> > > inside a dictionary *you already get funcref*. Thus what you need is
> just
> > > echo s:objFuncs.form1.
> > >
> > Hi and thanks again for taking some time to help. Although I allready
> > knew how to get the *real* result… thanks to your answer to my first
> > thread.
> >
> > Here, I did not put this "echo function('s:objFuncs.form1/2)" to get
> > the real result, but just to illustrate the fact that, to me, form1 and
> > form2 seems to be equivalent :
> > > > <SNR>36_objFuncs.form1
> > > > <SNR>36_s:objFuncs_form2
>
> Again, ***try calling funcref in the first form***. Funcrefs are not for
> echoing, they are for calling. First form **does not exist**. It is a
> function() bug and nothing else.
>
Ah ok ^^ Like this you mean ? :
<--
call function('s:objFuncs.form1')()
-->
E117: Unknown function: <SNR>32_objFuncs.form1
<--
call function('<SNR>' . s:SID() . '_s:objFuncs_form2')()
-->
E725: Calling dict function without Dictionary: <SNR>32_s:objFuns_form2
Ok, this function() bug increased my confusion and form1 is *not*
equivalent to form2. 's:objFuncs.form1' *is* the funcref, and
'function('s:objFuns.form1') is a non-sense (would be the funcref of a
funcref). Thanks for that clarification.
Now : in this particular context of an object constructor function,
are there any "use-case" where form2 should be used rather than form1 ?
Riml guys and you are a million years ahead of me in term of
programing. So, if they use form2 instead of form1, it means there's
something I still fail to understand. ^^ Why use a named dict function
and get a funcref later on (at the cost of verbosity), rather than
directly obtaining this funcref using form1 ?
Best regards, and thanks again for your patience ;)
> >
> > So I (still) wonder why some real developpers would use form2 (the non
> > anonymous version) rather than form1 ? I hope this claryfies my question
> > and that I understood your answer correctly. ^^
> >
> > Best regards.
> >
> > > > echo function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > > > --> Gives <--
> > > > <SNR>36_objFuncs.form1
> > > > <SNR>36_s:objFuncs_form2
> > > > -->
> > > >
> > > > Except form1 being {anonymous,numbered}-function and form2 beeing
> > > > just a dictionary-function, I don't see much difference between the 2
> > > > forms.
> > > >
> > > > The 1st form being more concise, I was wondering
> > > > a) why would someone use form2 (which I came accross on riml¹
> README).
> > > > b) what makes the anonymous form1 preferable (besides conciseness)
> > > >
> > > > ¹ https://github.com/luke-gru/riml
> > > >
> >
> > --
> > ___________________
> > | $ post_tenebras ↲ | waouh !
> > | GNU \ / | /
> > | -- * -- | o
> > | $ who ↲ / \ |_-- ~_|
> > | Alexandre Hoïde | _/| |
> > -------------------
> >
> > --
> > --
> > You received this message from the "vim_use" maillist.
> > Do not top-post! Type your reply below the text you are replying to.
> > For more information, visit http://www.vim.org/maillist.php
> >
> > ---
> > You received this message because you are subscribed to the Google Groups
> "vim_use" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_use+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
___________________
| $ post_tenebras ↲ | waouh !
| GNU \ / | /
| -- * -- | o
| $ who ↲ / \ |_-- ~_|
| Alexandre Hoïde | _/| |
-------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Where is my system-wide init file?
On 30.12.13 08:32, Gary Johnson wrote:
> On 2013-12-30, Tony Mechelynck wrote:
> > On 29/12/13 21:15, Elena Garrulo wrote:
>
> > >Thank you for making me learn the "type" command. Cool! :-)
> >
> > There is also "which" which is a separate program (and thus works for
> > all shells) but it doesn't know about shell aliases.
>
> The which(1) v2.20 man page recommends using a shell function
> wrapper around which that finds aliases and functions as well.
Remarkable how much good sense can be found in manpages. For the last
quarter century or more, I've had (on every machine I touch¹):
$ grep which .bashrc
alias which='type -a' # Checks aliases & functions also.
(Never could understand why I should ask the shell to type thingy,
then expect it to answer with which thingy it'd use, instead.)
Alas, the 2009 Debian manpage in my Ubuntu distro lacks the wisdom
you've found.
Erik
¹ First HP-UX, then Solaris, now linux - all had "type" AFAIR.
--
Leibowitz's Rule:
When hammering a nail, you will never hit your finger if you hold the
hammer with both hands.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On 2013-12-30, Tony Mechelynck wrote:
> > On 29/12/13 21:15, Elena Garrulo wrote:
>
> > >Thank you for making me learn the "type" command. Cool! :-)
> >
> > There is also "which" which is a separate program (and thus works for
> > all shells) but it doesn't know about shell aliases.
>
> The which(1) v2.20 man page recommends using a shell function
> wrapper around which that finds aliases and functions as well.
Remarkable how much good sense can be found in manpages. For the last
quarter century or more, I've had (on every machine I touch¹):
$ grep which .bashrc
alias which='type -a' # Checks aliases & functions also.
(Never could understand why I should ask the shell to type thingy,
then expect it to answer with which thingy it'd use, instead.)
Alas, the 2009 Debian manpage in my Ubuntu distro lacks the wisdom
you've found.
Erik
¹ First HP-UX, then Solaris, now linux - all had "type" AFAIR.
--
Leibowitz's Rule:
When hammering a nail, you will never hit your finger if you hold the
hammer with both hands.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Monday, December 30, 2013
Re: Can not paste with Shift-Insert with gvim
On 31/12/13 07:55, Diep Pham Van wrote:
> I'm having unexpected result when press Shift-Insert to paste in gvim.
> Instead of paste, gvim inserts '<S-Insert>', vim in a terminal work fine.
>
> I'm using vim 7.4, this is my compile option:
> http://pastebin.com/BJbiuiTL
>
> I've already try with '-u NONE'. If I remember correctly, the
> Shift-Insert paste used to work in the past.
> So, any one has this problem? And how to fix it?
>
Your mailer's User-Agent line (Icedove 17.0.10 for linux x86_64) seems
to imply that, like me, you're on Linux; and indeed, when I hit
Shift-Insert in gvim (Huge GTK2/GNOME2 version) in Insert mode, it
inserts <S-Insert>. In Normal mode I get a beep (which I have customized
to a visual beep).
The help about this key seems to indicate that it is specific to MS-DOS
and Windows versions of Vim. You can get it back, though, with the
following mappings (untested, and this assumes Vim 7.0 or later):
noremap! <S-Insert> <C-R>+
nnoremap <S-Insert> "+gP
snoremap <S-Insert> <Esc>gvc<C-R>+
xnoremap <S-Insert> c<C-R>+<Esc>
These mappings intentionally leave you in Normal mode after using
Shift-Insert in Visual but in Insert mode after using it in Select mode.
If I didn't goof, they all leave the cursor after the inserted text.
There could be an off-by-one error in the xnoremap (Visual but not
Select) mapping. Append an l or a <Right> if it upsets you, but this
might produce an unwanted advance to the next line if you're in
blockwise- or characterwise-visual at the end of a line.
Instead of these mappings, you can of course just insert register +
(which is the clipboard) in the normal way, either with the keyboard
(using key sequences similar to the {rhs}es above) or with the "Edit →
Paste" menu.
I suppose that the fact that it still works in a terminal means that
your terminal is handling it.
Best regards,
Tony.
--
Put another password in,
Bomb it out, then try again.
Try to get past logging in,
We're hacking, hacking, hacking.
Try his first wife's maiden name,
This is more than just a game.
It's real fun, but just the same,
It's hacking, hacking, hacking.
-- To the tune of "Music, Music, Music?"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> I'm having unexpected result when press Shift-Insert to paste in gvim.
> Instead of paste, gvim inserts '<S-Insert>', vim in a terminal work fine.
>
> I'm using vim 7.4, this is my compile option:
> http://pastebin.com/BJbiuiTL
>
> I've already try with '-u NONE'. If I remember correctly, the
> Shift-Insert paste used to work in the past.
> So, any one has this problem? And how to fix it?
>
Your mailer's User-Agent line (Icedove 17.0.10 for linux x86_64) seems
to imply that, like me, you're on Linux; and indeed, when I hit
Shift-Insert in gvim (Huge GTK2/GNOME2 version) in Insert mode, it
inserts <S-Insert>. In Normal mode I get a beep (which I have customized
to a visual beep).
The help about this key seems to indicate that it is specific to MS-DOS
and Windows versions of Vim. You can get it back, though, with the
following mappings (untested, and this assumes Vim 7.0 or later):
noremap! <S-Insert> <C-R>+
nnoremap <S-Insert> "+gP
snoremap <S-Insert> <Esc>gvc<C-R>+
xnoremap <S-Insert> c<C-R>+<Esc>
These mappings intentionally leave you in Normal mode after using
Shift-Insert in Visual but in Insert mode after using it in Select mode.
If I didn't goof, they all leave the cursor after the inserted text.
There could be an off-by-one error in the xnoremap (Visual but not
Select) mapping. Append an l or a <Right> if it upsets you, but this
might produce an unwanted advance to the next line if you're in
blockwise- or characterwise-visual at the end of a line.
Instead of these mappings, you can of course just insert register +
(which is the clipboard) in the normal way, either with the keyboard
(using key sequences similar to the {rhs}es above) or with the "Edit →
Paste" menu.
I suppose that the fact that it still works in a terminal means that
your terminal is handling it.
Best regards,
Tony.
--
Put another password in,
Bomb it out, then try again.
Try to get past logging in,
We're hacking, hacking, hacking.
Try his first wife's maiden name,
This is more than just a game.
It's real fun, but just the same,
It's hacking, hacking, hacking.
-- To the tune of "Music, Music, Music?"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: funcrefs forms
On Dec 31, 2013 11:24 AM, "Alexandre Hoïde" <alexandre.hoide@gmail.com> wrote:
>
> On Mon, Dec 30, 2013 at 10:18:21PM +0400, Nikolay Pavlov wrote:
> > On Dec 30, 2013 5:58 PM, "Alexandre Hoïde" <alexandre.hoide@gmail.com>
> > wrote:
> > >
> > > On Mon, Dec 30, 2013 at 08:55:17AM +0100, Alexandre Hoïde wrote:
> > > > .vim <--
> > > > function! s:SID()
> > > > return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
> > > > endfunction
> > > >
> > > > function! s:objectConstructor(name)
> > > > let obj = {}
> > > > let obj.name = a:name
> > > > let obj.form1 = s:objFuncs.form1
> > > > let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > > > return obj
> > > > endfunction
> > > >
> > > > let s:objFuncs = {}
> > > >
> > > > function! s:objFuncs.form1()
> > > > echo self.name
> > > > endfunction
> > > >
> > > > function! <SID>s:objFuncs_form2() dict
> > > > echo self.name
> > > > endfunction
> > > >
> > > > let otst = s:objectConstructor('test')
> > > > call otst.form1()
> > > > call otst.form2()
> > > > -->
> > >
> > > … to be more specific, on the sample code above, the following :
> > > <--
> > > echo function('s:objFuncs.form1')
> >
> > Now please try calling this (i.e. just append ()). *function() is not a
> > replacement for eval*. You have found function() bug, nothing more. To get
> > *real* results *echo actual funcref*. As I said if you define function
> > inside a dictionary *you already get funcref*. Thus what you need is just
> > echo s:objFuncs.form1.
> >
> Hi and thanks again for taking some time to help. Although I allready
> knew how to get the *real* result… thanks to your answer to my first
> thread.
>
> Here, I did not put this "echo function('s:objFuncs.form1/2)" to get
> the real result, but just to illustrate the fact that, to me, form1 and
> form2 seems to be equivalent :
> > > <SNR>36_objFuncs.form1
> > > <SNR>36_s:objFuncs_form2
Again, ***try calling funcref in the first form***. Funcrefs are not for echoing, they are for calling. First form **does not exist**. It is a function() bug and nothing else.
>
> So I (still) wonder why some real developpers would use form2 (the non
> anonymous version) rather than form1 ? I hope this claryfies my question
> and that I understood your answer correctly. ^^
>
> Best regards.
>
> > > echo function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > > --> Gives <--
> > > <SNR>36_objFuncs.form1
> > > <SNR>36_s:objFuncs_form2
> > > -->
> > >
> > > Except form1 being {anonymous,numbered}-function and form2 beeing
> > > just a dictionary-function, I don't see much difference between the 2
> > > forms.
> > >
> > > The 1st form being more concise, I was wondering
> > > a) why would someone use form2 (which I came accross on riml¹ README).
> > > b) what makes the anonymous form1 preferable (besides conciseness)
> > >
> > > ¹ https://github.com/luke-gru/riml
> > >
>
> --
> ___________________
> | $ post_tenebras ↲ | waouh !
> | GNU \ / | /
> | -- * -- | o
> | $ who ↲ / \ |_-- ~_|
> | Alexandre Hoïde | _/| |
> -------------------
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: funcrefs forms
On Mon, Dec 30, 2013 at 10:18:21PM +0400, Nikolay Pavlov wrote:
> On Dec 30, 2013 5:58 PM, "Alexandre Hoïde" <alexandre.hoide@gmail.com>
> wrote:
> >
> > On Mon, Dec 30, 2013 at 08:55:17AM +0100, Alexandre Hoïde wrote:
> > > .vim <--
> > > function! s:SID()
> > > return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
> > > endfunction
> > >
> > > function! s:objectConstructor(name)
> > > let obj = {}
> > > let obj.name = a:name
> > > let obj.form1 = s:objFuncs.form1
> > > let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > > return obj
> > > endfunction
> > >
> > > let s:objFuncs = {}
> > >
> > > function! s:objFuncs.form1()
> > > echo self.name
> > > endfunction
> > >
> > > function! <SID>s:objFuncs_form2() dict
> > > echo self.name
> > > endfunction
> > >
> > > let otst = s:objectConstructor('test')
> > > call otst.form1()
> > > call otst.form2()
> > > -->
> >
> > … to be more specific, on the sample code above, the following :
> > <--
> > echo function('s:objFuncs.form1')
>
> Now please try calling this (i.e. just append ()). *function() is not a
> replacement for eval*. You have found function() bug, nothing more. To get
> *real* results *echo actual funcref*. As I said if you define function
> inside a dictionary *you already get funcref*. Thus what you need is just
> echo s:objFuncs.form1.
>
Hi and thanks again for taking some time to help. Although I allready
knew how to get the *real* result… thanks to your answer to my first
thread.
Here, I did not put this "echo function('s:objFuncs.form1/2)" to get
the real result, but just to illustrate the fact that, to me, form1 and
form2 seems to be equivalent :
> > <SNR>36_objFuncs.form1
> > <SNR>36_s:objFuncs_form2
So I (still) wonder why some real developpers would use form2 (the non
anonymous version) rather than form1 ? I hope this claryfies my question
and that I understood your answer correctly. ^^
Best regards.
> > echo function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > --> Gives <--
> > <SNR>36_objFuncs.form1
> > <SNR>36_s:objFuncs_form2
> > -->
> >
> > Except form1 being {anonymous,numbered}-function and form2 beeing
> > just a dictionary-function, I don't see much difference between the 2
> > forms.
> >
> > The 1st form being more concise, I was wondering
> > a) why would someone use form2 (which I came accross on riml¹ README).
> > b) what makes the anonymous form1 preferable (besides conciseness)
> >
> > ¹ https://github.com/luke-gru/riml
> >
--
___________________
| $ post_tenebras ↲ | waouh !
| GNU \ / | /
| -- * -- | o
| $ who ↲ / \ |_-- ~_|
| Alexandre Hoïde | _/| |
-------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On Dec 30, 2013 5:58 PM, "Alexandre Hoïde" <alexandre.hoide@gmail.com>
> wrote:
> >
> > On Mon, Dec 30, 2013 at 08:55:17AM +0100, Alexandre Hoïde wrote:
> > > .vim <--
> > > function! s:SID()
> > > return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
> > > endfunction
> > >
> > > function! s:objectConstructor(name)
> > > let obj = {}
> > > let obj.name = a:name
> > > let obj.form1 = s:objFuncs.form1
> > > let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > > return obj
> > > endfunction
> > >
> > > let s:objFuncs = {}
> > >
> > > function! s:objFuncs.form1()
> > > echo self.name
> > > endfunction
> > >
> > > function! <SID>s:objFuncs_form2() dict
> > > echo self.name
> > > endfunction
> > >
> > > let otst = s:objectConstructor('test')
> > > call otst.form1()
> > > call otst.form2()
> > > -->
> >
> > … to be more specific, on the sample code above, the following :
> > <--
> > echo function('s:objFuncs.form1')
>
> Now please try calling this (i.e. just append ()). *function() is not a
> replacement for eval*. You have found function() bug, nothing more. To get
> *real* results *echo actual funcref*. As I said if you define function
> inside a dictionary *you already get funcref*. Thus what you need is just
> echo s:objFuncs.form1.
>
Hi and thanks again for taking some time to help. Although I allready
knew how to get the *real* result… thanks to your answer to my first
thread.
Here, I did not put this "echo function('s:objFuncs.form1/2)" to get
the real result, but just to illustrate the fact that, to me, form1 and
form2 seems to be equivalent :
> > <SNR>36_objFuncs.form1
> > <SNR>36_s:objFuncs_form2
So I (still) wonder why some real developpers would use form2 (the non
anonymous version) rather than form1 ? I hope this claryfies my question
and that I understood your answer correctly. ^^
Best regards.
> > echo function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > --> Gives <--
> > <SNR>36_objFuncs.form1
> > <SNR>36_s:objFuncs_form2
> > -->
> >
> > Except form1 being {anonymous,numbered}-function and form2 beeing
> > just a dictionary-function, I don't see much difference between the 2
> > forms.
> >
> > The 1st form being more concise, I was wondering
> > a) why would someone use form2 (which I came accross on riml¹ README).
> > b) what makes the anonymous form1 preferable (besides conciseness)
> >
> > ¹ https://github.com/luke-gru/riml
> >
--
___________________
| $ post_tenebras ↲ | waouh !
| GNU \ / | /
| -- * -- | o
| $ who ↲ / \ |_-- ~_|
| Alexandre Hoïde | _/| |
-------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Can not paste with Shift-Insert with gvim
I'm having unexpected result when press Shift-Insert to paste in gvim.
Instead of paste, gvim inserts '<S-Insert>', vim in a terminal work fine.
I'm using vim 7.4, this is my compile option:
http://pastebin.com/BJbiuiTL
I've already try with '-u NONE'. If I remember correctly, the
Shift-Insert paste used to work in the past.
So, any one has this problem? And how to fix it?
--
PHAM Van Diep
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Instead of paste, gvim inserts '<S-Insert>', vim in a terminal work fine.
I'm using vim 7.4, this is my compile option:
http://pastebin.com/BJbiuiTL
I've already try with '-u NONE'. If I remember correctly, the
Shift-Insert paste used to work in the past.
So, any one has this problem? And how to fix it?
--
PHAM Van Diep
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Help getting Vundle to include a plugin I'm writing
Never mind, restarting Vim fixed this. I tried commenting out some other plugins from my vimrc and :BundleClean wasn't removing them, so I knew something was up. Thanks for helping me out with the file structure.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Help getting Vundle to include a plugin I'm writing
Excerpts from Ivan's message of Tue Dec 31 00:34:09 +0100 2013:
> You need to put the file into plugin/syntax/autolad/color/filetype... depending
> on what you need. In your case its plugin/* which get sourced by Vim.
I thought that might be the case, looking at other plugin repos, but I tried that and it didn't help. I just tried it again, but still no action (maybe I'm missing something else). I put the file into plugin/ but Vundle still doesn't pick it up.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> You need to put the file into plugin/syntax/autolad/color/filetype... depending
> on what you need. In your case its plugin/* which get sourced by Vim.
I thought that might be the case, looking at other plugin repos, but I tried that and it didn't help. I just tried it again, but still no action (maybe I'm missing something else). I put the file into plugin/ but Vundle still doesn't pick it up.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Help getting Vundle to include a plugin I'm writing
Excerpts from Ivan's message of Tue Dec 31 00:34:09 +0100 2013:
> I'm writing a plugin and trying to figure out how to get Vundle to include it. Nothing doing so far. I created a Github repo for the plugin and referenced it in my .vimrc as follows:
> Bundle 'ivanbrennan/grep-operator'
You need to put the file into plugin/syntax/autolad/color/filetype... depending
on what you need. In your case its plugin/* which get sourced by Vim.
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html
Explains the basic plugin layout and additional options
Marc Weber
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> I'm writing a plugin and trying to figure out how to get Vundle to include it. Nothing doing so far. I created a Github repo for the plugin and referenced it in my .vimrc as follows:
> Bundle 'ivanbrennan/grep-operator'
You need to put the file into plugin/syntax/autolad/color/filetype... depending
on what you need. In your case its plugin/* which get sourced by Vim.
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html
Explains the basic plugin layout and additional options
Marc Weber
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Help getting Vundle to include a plugin I'm writing
I'm writing a plugin and trying to figure out how to get Vundle to include it. Nothing doing so far. I created a Github repo for the plugin and referenced it in my .vimrc as follows:
Bundle 'ivanbrennan/grep-operator'
Running :BundleInstall doesn't pick up the new plugin though. I'd be grateful for any advice. Any ideas?
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Bundle 'ivanbrennan/grep-operator'
Running :BundleInstall doesn't pick up the new plugin though. I'd be grateful for any advice. Any ideas?
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Encoding Issues on Windows
On Monday, December 30, 2013 4:12:16 PM UTC-6, Tony Mechelynck wrote:
> On 30/12/13 22:15, Ben Fritz wrote:
> > codepage 437 contains very few Unicode characters beyond the basic ASCII range. Try a different codepage. Unfortunately I don't know enough about how the terminal works to know for certain whether any will work.
> >
>
> IIRC, cp437, which used to be the default MS-DOS ROM codepage for United
> States, contains a number of characters for ASCII art (single, double
> and mixed frame borders and corners, several shades of grey dithering,
> and dark blocks: full, vertical-split and horizontal-split) which aren't
> in Latin1. All of them are in the upper half of the table, i.e.
> somewhere in the range 0x80-0xFF.
>
Completely true, but also completely useless for the current problem. Most people won't be trying to draw fancy ASCII art with special characters in Vim, they'll be trying to type Russian or Greek or adding a few special quotes or punctuation here and there.
I suspect the solution will either be:
1. Use chcp to set a codepage containing the desired glyphs (Russian, Greek, whatever) in the upper half of the table
2. Use chcp to set a unicode codepage
I'm not sure which will work best, or frankly whether either will work.
And I cannot possibly recommend a codepage since I don't know what characters are desired. Some googling should tell you what's available...here's a list I've used before:
http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx
Maybe try the UTF-8 codepage first.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On 30/12/13 22:15, Ben Fritz wrote:
> > codepage 437 contains very few Unicode characters beyond the basic ASCII range. Try a different codepage. Unfortunately I don't know enough about how the terminal works to know for certain whether any will work.
> >
>
> IIRC, cp437, which used to be the default MS-DOS ROM codepage for United
> States, contains a number of characters for ASCII art (single, double
> and mixed frame borders and corners, several shades of grey dithering,
> and dark blocks: full, vertical-split and horizontal-split) which aren't
> in Latin1. All of them are in the upper half of the table, i.e.
> somewhere in the range 0x80-0xFF.
>
Completely true, but also completely useless for the current problem. Most people won't be trying to draw fancy ASCII art with special characters in Vim, they'll be trying to type Russian or Greek or adding a few special quotes or punctuation here and there.
I suspect the solution will either be:
1. Use chcp to set a codepage containing the desired glyphs (Russian, Greek, whatever) in the upper half of the table
2. Use chcp to set a unicode codepage
I'm not sure which will work best, or frankly whether either will work.
And I cannot possibly recommend a codepage since I don't know what characters are desired. Some googling should tell you what's available...here's a list I've used before:
http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx
Maybe try the UTF-8 codepage first.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Encoding Issues on Windows
On 30/12/13 22:15, Ben Fritz wrote:
> On Monday, December 30, 2013 11:32:07 AM UTC-6, Jarrod Hermer wrote:
>> Hi Alex,
>>
>> I have the exact same problem. Have you been able to resolve it?
>>
>> On Friday, November 29, 2013 9:05:46 AM UTC+2, Alexander Shukaev wrote:
>>> First of all, could you type `chcp` in terminal and tell me what is your default codepage? Thanks.
>>
>> On my system chcp returns 437.
>
> codepage 437 contains very few Unicode characters beyond the basic ASCII range. Try a different codepage. Unfortunately I don't know enough about how the terminal works to know for certain whether any will work.
>
IIRC, cp437, which used to be the default MS-DOS ROM codepage for United
States, contains a number of characters for ASCII art (single, double
and mixed frame borders and corners, several shades of grey dithering,
and dark blocks: full, vertical-split and horizontal-split) which aren't
in Latin1. All of them are in the upper half of the table, i.e.
somewhere in the range 0x80-0xFF.
Best regards,
Tony.
--
The best laid plans of mice and men are usually about equal.
-- Blair
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On Monday, December 30, 2013 11:32:07 AM UTC-6, Jarrod Hermer wrote:
>> Hi Alex,
>>
>> I have the exact same problem. Have you been able to resolve it?
>>
>> On Friday, November 29, 2013 9:05:46 AM UTC+2, Alexander Shukaev wrote:
>>> First of all, could you type `chcp` in terminal and tell me what is your default codepage? Thanks.
>>
>> On my system chcp returns 437.
>
> codepage 437 contains very few Unicode characters beyond the basic ASCII range. Try a different codepage. Unfortunately I don't know enough about how the terminal works to know for certain whether any will work.
>
IIRC, cp437, which used to be the default MS-DOS ROM codepage for United
States, contains a number of characters for ASCII art (single, double
and mixed frame borders and corners, several shades of grey dithering,
and dark blocks: full, vertical-split and horizontal-split) which aren't
in Latin1. All of them are in the upper half of the table, i.e.
somewhere in the range 0x80-0xFF.
Best regards,
Tony.
--
The best laid plans of mice and men are usually about equal.
-- Blair
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Vim redraw issue in Xubuntu 13.10 (running inside VMWare Workstation 10)
On 30/12/2013 16:34, Ken Takata wrote:
> Hi,
>
> 2013/12/30 Mon 11:26:45 UTC+9 Some Developer wrote:
>> It still happens when using "gvim -u NONE".
>>
>> Steps to reproduce are easy. Load an HTML file with gvim, enter insert
>> mode and press return a few times in the middle of the file to add new
>> lines. After 2 or 3 new lines have been added the cursor starts
>> overwriting text underneath rather than adding new lines. Exiting out of
>> insert mode and pressing Ctrl-R to refresh the screen redraws everything
>> and the file looks correct again. Do some more editing in insert mode
>> and it screws up again until Ctrl-R is pressed again.
>>
>> I have a feeling this has something to do with GTK+ rather than Vim
>> since the command line version works perfectly with the same file.
>
> I think this is related to the following item from the todo.txt:
>
> Problem caused by patch 7.3.638: window->open does not update window
> correctly. Issue 91.
>
> How about reverting the patch 7.3.638?
>
> Regards,
> Ken Takata
>
Ah, good catch. Thanks. I'll have a go when I next have some free time
to play around with this.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> Hi,
>
> 2013/12/30 Mon 11:26:45 UTC+9 Some Developer wrote:
>> It still happens when using "gvim -u NONE".
>>
>> Steps to reproduce are easy. Load an HTML file with gvim, enter insert
>> mode and press return a few times in the middle of the file to add new
>> lines. After 2 or 3 new lines have been added the cursor starts
>> overwriting text underneath rather than adding new lines. Exiting out of
>> insert mode and pressing Ctrl-R to refresh the screen redraws everything
>> and the file looks correct again. Do some more editing in insert mode
>> and it screws up again until Ctrl-R is pressed again.
>>
>> I have a feeling this has something to do with GTK+ rather than Vim
>> since the command line version works perfectly with the same file.
>
> I think this is related to the following item from the todo.txt:
>
> Problem caused by patch 7.3.638: window->open does not update window
> correctly. Issue 91.
>
> How about reverting the patch 7.3.638?
>
> Regards,
> Ken Takata
>
Ah, good catch. Thanks. I'll have a go when I next have some free time
to play around with this.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Encoding Issues on Windows
On Monday, December 30, 2013 11:32:07 AM UTC-6, Jarrod Hermer wrote:
> Hi Alex,
>
> I have the exact same problem. Have you been able to resolve it?
>
> On Friday, November 29, 2013 9:05:46 AM UTC+2, Alexander Shukaev wrote:
> > First of all, could you type `chcp` in terminal and tell me what is your default codepage? Thanks.
>
> On my system chcp returns 437.
codepage 437 contains very few Unicode characters beyond the basic ASCII range. Try a different codepage. Unfortunately I don't know enough about how the terminal works to know for certain whether any will work.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> Hi Alex,
>
> I have the exact same problem. Have you been able to resolve it?
>
> On Friday, November 29, 2013 9:05:46 AM UTC+2, Alexander Shukaev wrote:
> > First of all, could you type `chcp` in terminal and tell me what is your default codepage? Thanks.
>
> On my system chcp returns 437.
codepage 437 contains very few Unicode characters beyond the basic ASCII range. Try a different codepage. Unfortunately I don't know enough about how the terminal works to know for certain whether any will work.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: funcrefs forms
On Dec 30, 2013 5:58 PM, "Alexandre Hoïde" <alexandre.hoide@gmail.com> wrote:
>
> On Mon, Dec 30, 2013 at 08:55:17AM +0100, Alexandre Hoïde wrote:
> > .vim <--
> > function! s:SID()
> > return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
> > endfunction
> >
> > function! s:objectConstructor(name)
> > let obj = {}
> > let obj.name = a:name
> > let obj.form1 = s:objFuncs.form1
> > let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> > return obj
> > endfunction
> >
> > let s:objFuncs = {}
> >
> > function! s:objFuncs.form1()
> > echo self.name
> > endfunction
> >
> > function! <SID>s:objFuncs_form2() dict
> > echo self.name
> > endfunction
> >
> > let otst = s:objectConstructor('test')
> > call otst.form1()
> > call otst.form2()
> > -->
>
> … to be more specific, on the sample code above, the following :
> <--
> echo function('s:objFuncs.form1')
Now please try calling this (i.e. just append ()). *function() is not a replacement for eval*. You have found function() bug, nothing more. To get *real* results *echo actual funcref*. As I said if you define function inside a dictionary *you already get funcref*. Thus what you need is just echo s:objFuncs.form1.
> echo function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> --> Gives <--
> <SNR>36_objFuncs.form1
> <SNR>36_s:objFuncs_form2
> -->
>
> Except form1 being {anonymous,numbered}-function and form2 beeing
> just a dictionary-function, I don't see much difference between the 2
> forms.
>
> The 1st form being more concise, I was wondering
> a) why would someone use form2 (which I came accross on riml¹ README).
> b) what makes the anonymous form1 preferable (besides conciseness)
>
> ¹ https://github.com/luke-gru/riml
>
> --
> ___________________
> | $ post_tenebras ↲ | waouh !
> | GNU \ / | /
> | -- * -- | o
> | $ who ↲ / \ |_-- ~_|
> | Alexandre Hoïde | _/| |
> -------------------
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Encoding Issues on Windows
Hi Alex,
I have the exact same problem. Have you been able to resolve it?
On Friday, November 29, 2013 9:05:46 AM UTC+2, Alexander Shukaev wrote:
> First of all, could you type `chcp` in terminal and tell me what is your default codepage? Thanks.
On my system chcp returns 437.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I have the exact same problem. Have you been able to resolve it?
On Friday, November 29, 2013 9:05:46 AM UTC+2, Alexander Shukaev wrote:
> First of all, could you type `chcp` in terminal and tell me what is your default codepage? Thanks.
On my system chcp returns 437.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Netrw issues with tempfiles under gVim + Cygwin
Charles E Campbell wrote:
> esquifit wrote:
>> On Sunday, December 22, 2013 10:45:01 AM UTC+1, esquifit wrote:
>>> One of the issues is
>>> that Netrw isn't able to download files through http.
>> To be more precise:
>>
>> :e http://host.com/foo
>>
>> is working fine, while
>>
>> :Nread http://host.com/foo
>>
>> gives an error:
>>
>> **warning** (netrw)
>> delete(/cygdrive/C/Users/esquifit/AppData/Local/Temp/VIBEFC.tmp) failed!
>>
>> The current buffer is set to read-only and no content is loaded into
>> it, even if the content has actually been downloaded and available in
>> the above file.
>>
> Please try v150m - there's a new setting-variable, g:netrw_cygdrive
> (default value: "/cygdrive").
>
> g:netrw_http_cmd is set by default to one of the following:
>
> elinks
> links
> curl
> wget
> fetch
>
> Each is tested in the order given, and the first one that
> executable("...") returns a 1 on is used. Your problem with
> g:netrw_http_cmd is, in fact, because executable() is not returning a
> 1. Look into paths, or manually set the variable.
>
> The Nread http://host.com/foo issue --- well, I'm getting a different
> problem, so I'll look into it.
>
I've figured out what my "different problem" was caused by, and am now
issuing a new warning. I'd opened the a directory using netrw, then
tried using :Nread ... and that was, of course, attempting to read the
file into the netrw buffer (which is not modifiable). I don't believe
that the problem I just fixed is pertinent to the problem you're having.
Regards,
Chip Campbell
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> esquifit wrote:
>> On Sunday, December 22, 2013 10:45:01 AM UTC+1, esquifit wrote:
>>> One of the issues is
>>> that Netrw isn't able to download files through http.
>> To be more precise:
>>
>> :e http://host.com/foo
>>
>> is working fine, while
>>
>> :Nread http://host.com/foo
>>
>> gives an error:
>>
>> **warning** (netrw)
>> delete(/cygdrive/C/Users/esquifit/AppData/Local/Temp/VIBEFC.tmp) failed!
>>
>> The current buffer is set to read-only and no content is loaded into
>> it, even if the content has actually been downloaded and available in
>> the above file.
>>
> Please try v150m - there's a new setting-variable, g:netrw_cygdrive
> (default value: "/cygdrive").
>
> g:netrw_http_cmd is set by default to one of the following:
>
> elinks
> links
> curl
> wget
> fetch
>
> Each is tested in the order given, and the first one that
> executable("...") returns a 1 on is used. Your problem with
> g:netrw_http_cmd is, in fact, because executable() is not returning a
> 1. Look into paths, or manually set the variable.
>
> The Nread http://host.com/foo issue --- well, I'm getting a different
> problem, so I'll look into it.
>
I've figured out what my "different problem" was caused by, and am now
issuing a new warning. I'd opened the a directory using netrw, then
tried using :Nread ... and that was, of course, attempting to read the
file into the netrw buffer (which is not modifiable). I don't believe
that the problem I just fixed is pertinent to the problem you're having.
Regards,
Chip Campbell
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Vim redraw issue in Xubuntu 13.10 (running inside VMWare Workstation 10)
Hi,
2013/12/30 Mon 11:26:45 UTC+9 Some Developer wrote:
> It still happens when using "gvim -u NONE".
>
> Steps to reproduce are easy. Load an HTML file with gvim, enter insert
> mode and press return a few times in the middle of the file to add new
> lines. After 2 or 3 new lines have been added the cursor starts
> overwriting text underneath rather than adding new lines. Exiting out of
> insert mode and pressing Ctrl-R to refresh the screen redraws everything
> and the file looks correct again. Do some more editing in insert mode
> and it screws up again until Ctrl-R is pressed again.
>
> I have a feeling this has something to do with GTK+ rather than Vim
> since the command line version works perfectly with the same file.
I think this is related to the following item from the todo.txt:
Problem caused by patch 7.3.638: window->open does not update window
correctly. Issue 91.
How about reverting the patch 7.3.638?
Regards,
Ken Takata
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
2013/12/30 Mon 11:26:45 UTC+9 Some Developer wrote:
> It still happens when using "gvim -u NONE".
>
> Steps to reproduce are easy. Load an HTML file with gvim, enter insert
> mode and press return a few times in the middle of the file to add new
> lines. After 2 or 3 new lines have been added the cursor starts
> overwriting text underneath rather than adding new lines. Exiting out of
> insert mode and pressing Ctrl-R to refresh the screen redraws everything
> and the file looks correct again. Do some more editing in insert mode
> and it screws up again until Ctrl-R is pressed again.
>
> I have a feeling this has something to do with GTK+ rather than Vim
> since the command line version works perfectly with the same file.
I think this is related to the following item from the todo.txt:
Problem caused by patch 7.3.638: window->open does not update window
correctly. Issue 91.
How about reverting the patch 7.3.638?
Regards,
Ken Takata
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Where is my system-wide init file?
On 2013-12-30, Tony Mechelynck wrote:
> On 29/12/13 21:15, Elena Garrulo wrote:
> >Thank you for making me learn the "type" command. Cool! :-)
>
> There is also "which" which is a separate program (and thus works for
> all shells) but it doesn't know about shell aliases.
The which(1) v2.20 man page recommends using a shell function
wrapper around which that finds aliases and functions as well.
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> On 29/12/13 21:15, Elena Garrulo wrote:
> >Thank you for making me learn the "type" command. Cool! :-)
>
> There is also "which" which is a separate program (and thus works for
> all shells) but it doesn't know about shell aliases.
The which(1) v2.20 man page recommends using a shell function
wrapper around which that finds aliases and functions as well.
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: funcrefs forms
On Mon, Dec 30, 2013 at 08:55:17AM +0100, Alexandre Hoïde wrote:
> .vim <--
> function! s:SID()
> return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
> endfunction
>
> function! s:objectConstructor(name)
> let obj = {}
> let obj.name = a:name
> let obj.form1 = s:objFuncs.form1
> let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> return obj
> endfunction
>
> let s:objFuncs = {}
>
> function! s:objFuncs.form1()
> echo self.name
> endfunction
>
> function! <SID>s:objFuncs_form2() dict
> echo self.name
> endfunction
>
> let otst = s:objectConstructor('test')
> call otst.form1()
> call otst.form2()
> -->
… to be more specific, on the sample code above, the following :
<--
echo function('s:objFuncs.form1')
echo function('<SNR>' . s:SID() . '_s:objFuncs_form2')
--> Gives <--
<SNR>36_objFuncs.form1
<SNR>36_s:objFuncs_form2
-->
Except form1 being {anonymous,numbered}-function and form2 beeing
just a dictionary-function, I don't see much difference between the 2
forms.
The 1st form being more concise, I was wondering
a) why would someone use form2 (which I came accross on riml¹ README).
b) what makes the anonymous form1 preferable (besides conciseness)
¹ https://github.com/luke-gru/riml
--
___________________
| $ post_tenebras ↲ | waouh !
| GNU \ / | /
| -- * -- | o
| $ who ↲ / \ |_-- ~_|
| Alexandre Hoïde | _/| |
-------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> .vim <--
> function! s:SID()
> return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
> endfunction
>
> function! s:objectConstructor(name)
> let obj = {}
> let obj.name = a:name
> let obj.form1 = s:objFuncs.form1
> let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
> return obj
> endfunction
>
> let s:objFuncs = {}
>
> function! s:objFuncs.form1()
> echo self.name
> endfunction
>
> function! <SID>s:objFuncs_form2() dict
> echo self.name
> endfunction
>
> let otst = s:objectConstructor('test')
> call otst.form1()
> call otst.form2()
> -->
… to be more specific, on the sample code above, the following :
<--
echo function('s:objFuncs.form1')
echo function('<SNR>' . s:SID() . '_s:objFuncs_form2')
--> Gives <--
<SNR>36_objFuncs.form1
<SNR>36_s:objFuncs_form2
-->
Except form1 being {anonymous,numbered}-function and form2 beeing
just a dictionary-function, I don't see much difference between the 2
forms.
The 1st form being more concise, I was wondering
a) why would someone use form2 (which I came accross on riml¹ README).
b) what makes the anonymous form1 preferable (besides conciseness)
¹ https://github.com/luke-gru/riml
--
___________________
| $ post_tenebras ↲ | waouh !
| GNU \ / | /
| -- * -- | o
| $ who ↲ / \ |_-- ~_|
| Alexandre Hoïde | _/| |
-------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: display the title of current fold in the statusline
... modified to show the full "fold-tree" like here:
http://s13.postimg.org/9tql8bpzb/statusline.png
highlight link StatFname StatusLine
highlight link StatFenc StatusLineNC
highlight link StatPath LineNr
highlight link StatLnum StatusLineNC
highlight link StatFnameINS StatusLine
highlight link StatFencINS StatPath
highlight link StatPathINS ModeMsg
highlight link StatLnumINS StatPath
highlight link StatFnameNC StatusLineNC
highlight link StatFencNC StatFnameNC
highlight link StatPathNC StatFnameNC
highlight link StatLnumNC StatFnameNC
set laststatus=2
set lazyredraw
set foldenable
set foldmethod=marker
let &statusline = "%!StatusLine( '' )"
function StatusLine( mode )
let statusline = '%#StatFname' . a:mode . '#'
let statusline .= '%w%t%r%m '
let statusline .= '%#StatFenc' . a:mode . '# '
let statusline .= '[' . (&binary ? 'binary' : (&fenc . (&bomb ? '-bom' : ''))) . ' ' . &ff . '] '
let statusline .= '%#StatPath' . a:mode . '# '
let statusline .= '%<'
let path = expand( '%:p:h' ) . (has( 'win32' ) ? '\' : '/')
let level = foldlevel( '.' )
let closed = foldclosed( '.' )
if (a:mode == 'INS') && (level > 0)
let save_foldtext = &foldtext
set foldtext=StatFoldText()
foldclose!
let i = 0
let delim = ''
while i < level
let statusline .= delim . foldtextresult( foldclosed( '.' ) )
foldopen
let i += 1
let delim = ' >> '
endwhile
if closed >= 0
foldclose
endif
let &foldtext = save_foldtext
else
let statusline .= path
endif
let statusline .= '%='
let statusline .= '%#StatLnum' . a:mode . '# '
let statusline .= '%3v | %5l/%L (%3p%%)'
return statusline
endfunction
function StatFoldText()
return substitute( foldtext(), '^.\{-}: \|\s\+$', '', 'g' )
endfunction
autocmd WinEnter,InsertLeave * let &l:statusline = "%!StatusLine( '' )"
autocmd InsertEnter,InsertChange * let &l:statusline = "%!StatusLine( 'INS' )"
autocmd WinLeave * let &l:statusline = "%!StatusLine( 'NC' )"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
http://s13.postimg.org/9tql8bpzb/statusline.png
highlight link StatFname StatusLine
highlight link StatFenc StatusLineNC
highlight link StatPath LineNr
highlight link StatLnum StatusLineNC
highlight link StatFnameINS StatusLine
highlight link StatFencINS StatPath
highlight link StatPathINS ModeMsg
highlight link StatLnumINS StatPath
highlight link StatFnameNC StatusLineNC
highlight link StatFencNC StatFnameNC
highlight link StatPathNC StatFnameNC
highlight link StatLnumNC StatFnameNC
set laststatus=2
set lazyredraw
set foldenable
set foldmethod=marker
let &statusline = "%!StatusLine( '' )"
function StatusLine( mode )
let statusline = '%#StatFname' . a:mode . '#'
let statusline .= '%w%t%r%m '
let statusline .= '%#StatFenc' . a:mode . '# '
let statusline .= '[' . (&binary ? 'binary' : (&fenc . (&bomb ? '-bom' : ''))) . ' ' . &ff . '] '
let statusline .= '%#StatPath' . a:mode . '# '
let statusline .= '%<'
let path = expand( '%:p:h' ) . (has( 'win32' ) ? '\' : '/')
let level = foldlevel( '.' )
let closed = foldclosed( '.' )
if (a:mode == 'INS') && (level > 0)
let save_foldtext = &foldtext
set foldtext=StatFoldText()
foldclose!
let i = 0
let delim = ''
while i < level
let statusline .= delim . foldtextresult( foldclosed( '.' ) )
foldopen
let i += 1
let delim = ' >> '
endwhile
if closed >= 0
foldclose
endif
let &foldtext = save_foldtext
else
let statusline .= path
endif
let statusline .= '%='
let statusline .= '%#StatLnum' . a:mode . '# '
let statusline .= '%3v | %5l/%L (%3p%%)'
return statusline
endfunction
function StatFoldText()
return substitute( foldtext(), '^.\{-}: \|\s\+$', '', 'g' )
endfunction
autocmd WinEnter,InsertLeave * let &l:statusline = "%!StatusLine( '' )"
autocmd InsertEnter,InsertChange * let &l:statusline = "%!StatusLine( 'INS' )"
autocmd WinLeave * let &l:statusline = "%!StatusLine( 'NC' )"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: has 7.4 changed behaviour chdir-ing to current file's dir by default?
ok, I finally found out the issue. Apparently renaming the top directory that contains all stuff (vim74) to vim/, causes my issue. Leaving it as vim74/ works fine, vim-rooter now does the only chdir, no additional chdir.
This works with vim without cream and also the vim I was using from tux. I will keep that as I need lua.
I saw another thread or issue asking for the installation dir not to contain the version name, this makes sense to me too.
thanks
On Mon, Dec 30, 2013 at 12:27 PM, jmlucjav <jmlucjav@gmail.com> wrote:
ok, I installed vim without cream, and starting:"c:\Program Files (x86)\vim\vim74\gvim.exe" -u NONE -U NONE -V9vimlog.txtI run :scriptnames and also get only1: c:\Program Files (x86)\vim\vim74\menu.vim2: c:\Program Files (x86)\vim\vim74\autoload\paste.vimso I guess this was not a problem to begin with, and I should focus again on the chdir being done...?With this versiosn of vim, I dont see the chdir in the logs...I am going to investigate moreOn Sun, Dec 29, 2013 at 8:35 PM, Tony Mechelynck <antoine.mechelynck@gmail.com> wrote:On 29/12/13 19:39, jmlucjav wrote:It shouldn't.
I am calling 'gvim.exe -u NONE -U NONE -V9 vimlog.txt' not vim.exe...I
always use gvim, not vim.exe. Tried to run vim.exe in a cmd but
somethings does not work, I get no output to :scriptnames.
Could that be the issue? calling gvim?
Not that I know of. Yes it's an installer, for ease of use, but AFAIK it's rather clean as installers go. If Steve Hall, who makes it, is reading this, he could give you more explanations than I can; but maybe he's on holiday until after New Year's Day. If you want, you might take a backup of what you care about, then cross your fingers (or touch wood) while it installs.
I tried another gvim.exe, the one I used to use before, from,
http://wyw.dcweb.cn/#download, but this is just the exe put in my
current vim dir, overriting the original gvim.exe. Same behaviour.
I was going to test with vim without cream, but it's an installer, I am
afraid it will polute my HOME etc, is there somewhere an oficial vim zip
distrib for win I could try?
Or you could compile your own, but why reinvent the wheel when Steve Hall's "Vim without Cream" is such a nice product? Any Vim old-timer here that still is on Windows (or, like me, has been for a long time) will tell you the same. Well, once upon a time when I was still on Windows (I think it was between Vim 6.4 and 7.0) Steve had gone AWOL and I did some compiling. Vim wasn't yet on Mercurial by then, the part about getting the sources in my HowTo pages linked below is more recent.
Getting the sources:
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
Compiling on Windows (may be out-of-date):
http://users.skynet.be/antoine.mechelynck/vim/compile.htm
Best regards,
Tony.
--
While away at a convention, an executive happened to meet a young woman who
was pretty, chic, and intelligent. When he persuaded her to disrobe in his
hotel room, he found out she had a superb body as well. Unfortunately, as
will happen, the executive sadly found himself unable to perform.
On his first night home, the executive padded naked from the shower
into the bedroom to find his wife swathed in a rumpled bathrobe, her hair
curled, her face creamed, munching candy loudly as she pored through a movie
magazine. And then, without warning, he felt the onset of a magnificent
erection.
Looking down at his throbbing member, he snarled, "Why you ungrateful,
mixed-up, son-of-a-bitch! Now I know why they call you a prick!"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
--- You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: has 7.4 changed behaviour chdir-ing to current file's dir by default?
ok, I installed vim without cream, and starting:
"c:\Program Files (x86)\vim\vim74\gvim.exe" -u NONE -U NONE -V9vimlog.txt
I run :scriptnames and also get only
1: c:\Program Files (x86)\vim\vim74\menu.vim
2: c:\Program Files (x86)\vim\vim74\autoload\paste.vim
so I guess this was not a problem to begin with, and I should focus again on the chdir being done...?
With this versiosn of vim, I dont see the chdir in the logs...I am going to investigate more
On Sun, Dec 29, 2013 at 8:35 PM, Tony Mechelynck <antoine.mechelynck@gmail.com> wrote:
On 29/12/13 19:39, jmlucjav wrote:It shouldn't.
I am calling 'gvim.exe -u NONE -U NONE -V9 vimlog.txt' not vim.exe...I
always use gvim, not vim.exe. Tried to run vim.exe in a cmd but
somethings does not work, I get no output to :scriptnames.
Could that be the issue? calling gvim?
Not that I know of. Yes it's an installer, for ease of use, but AFAIK it's rather clean as installers go. If Steve Hall, who makes it, is reading this, he could give you more explanations than I can; but maybe he's on holiday until after New Year's Day. If you want, you might take a backup of what you care about, then cross your fingers (or touch wood) while it installs.
I tried another gvim.exe, the one I used to use before, from,
http://wyw.dcweb.cn/#download, but this is just the exe put in my
current vim dir, overriting the original gvim.exe. Same behaviour.
I was going to test with vim without cream, but it's an installer, I am
afraid it will polute my HOME etc, is there somewhere an oficial vim zip
distrib for win I could try?
Or you could compile your own, but why reinvent the wheel when Steve Hall's "Vim without Cream" is such a nice product? Any Vim old-timer here that still is on Windows (or, like me, has been for a long time) will tell you the same. Well, once upon a time when I was still on Windows (I think it was between Vim 6.4 and 7.0) Steve had gone AWOL and I did some compiling. Vim wasn't yet on Mercurial by then, the part about getting the sources in my HowTo pages linked below is more recent.
Getting the sources:
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
Compiling on Windows (may be out-of-date):
http://users.skynet.be/antoine.mechelynck/vim/compile.htm
Best regards,
Tony.
--
While away at a convention, an executive happened to meet a young woman who
was pretty, chic, and intelligent. When he persuaded her to disrobe in his
hotel room, he found out she had a superb body as well. Unfortunately, as
will happen, the executive sadly found himself unable to perform.
On his first night home, the executive padded naked from the shower
into the bedroom to find his wife swathed in a rumpled bathrobe, her hair
curled, her face creamed, munching candy loudly as she pored through a movie
magazine. And then, without warning, he felt the onset of a magnificent
erection.
Looking down at his throbbing member, he snarled, "Why you ungrateful,
mixed-up, son-of-a-bitch! Now I know why they call you a prick!"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
--- You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: display the title of current fold in the statusline
I just did it! :) A big thanks for the tips again!
highlight link StatFname StatusLine
highlight link StatFenc StatusLineNC
highlight link StatPath LineNr
highlight link StatLnum StatusLineNC
highlight link StatFnameINS StatusLine
highlight link StatFencINS StatPath
highlight link StatPathINS ModeMsg
highlight link StatLnumINS StatPath
highlight link StatFnameNC StatusLineNC
highlight link StatFencNC StatFnameNC
highlight link StatPathNC StatFnameNC
highlight link StatLnumNC StatFnameNC
let &statusline = "%!StatusLine( '' )"
function StatusLine( mode )
let statusline = '%#StatFname' . a:mode . '#'
let statusline .= '%w%t%r%m '
let statusline .= '%#StatFenc' . a:mode . '# '
let statusline .= '[' . (&binary ? 'binary' : (&fenc . (&bomb ? '-bom' : ''))) . ' ' . &ff . '] '
let statusline .= '%#StatPath' . a:mode . '# '
let statusline .= '%<'
let path = expand( '%:p:h' ) . (has( 'win32' ) ? '\' : '/')
if (a:mode == 'INS') && (foldlevel( '.' ) > 0)
let save_foldtext = &foldtext
set foldtext=StatFoldText()
if foldclosed( '.' ) < 0
foldclose
let statusline .= foldtextresult( foldclosed( '.' ) )
foldopen
else
let statusline .= foldtextresult( '.' )
endif
let &foldtext = save_foldtext
else
let statusline .= path
endif
let statusline .= '%='
let statusline .= '%#StatLnum' . a:mode . '# '
let statusline .= '%3v | %5l/%L (%3p%%)'
return statusline
endfunction
function StatFoldText()
return substitute( foldtext(), '^.\{-}: \|\s\+$', '', 'g' )
endfunction
autocmd WinEnter,InsertLeave * let &l:statusline = "%!StatusLine( '' )"
autocmd InsertEnter,InsertChange * let &l:statusline = "%!StatusLine( 'INS' )"
autocmd WinLeave * let &l:statusline = "%!StatusLine( 'NC' )"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
highlight link StatFname StatusLine
highlight link StatFenc StatusLineNC
highlight link StatPath LineNr
highlight link StatLnum StatusLineNC
highlight link StatFnameINS StatusLine
highlight link StatFencINS StatPath
highlight link StatPathINS ModeMsg
highlight link StatLnumINS StatPath
highlight link StatFnameNC StatusLineNC
highlight link StatFencNC StatFnameNC
highlight link StatPathNC StatFnameNC
highlight link StatLnumNC StatFnameNC
let &statusline = "%!StatusLine( '' )"
function StatusLine( mode )
let statusline = '%#StatFname' . a:mode . '#'
let statusline .= '%w%t%r%m '
let statusline .= '%#StatFenc' . a:mode . '# '
let statusline .= '[' . (&binary ? 'binary' : (&fenc . (&bomb ? '-bom' : ''))) . ' ' . &ff . '] '
let statusline .= '%#StatPath' . a:mode . '# '
let statusline .= '%<'
let path = expand( '%:p:h' ) . (has( 'win32' ) ? '\' : '/')
if (a:mode == 'INS') && (foldlevel( '.' ) > 0)
let save_foldtext = &foldtext
set foldtext=StatFoldText()
if foldclosed( '.' ) < 0
foldclose
let statusline .= foldtextresult( foldclosed( '.' ) )
foldopen
else
let statusline .= foldtextresult( '.' )
endif
let &foldtext = save_foldtext
else
let statusline .= path
endif
let statusline .= '%='
let statusline .= '%#StatLnum' . a:mode . '# '
let statusline .= '%3v | %5l/%L (%3p%%)'
return statusline
endfunction
function StatFoldText()
return substitute( foldtext(), '^.\{-}: \|\s\+$', '', 'g' )
endfunction
autocmd WinEnter,InsertLeave * let &l:statusline = "%!StatusLine( '' )"
autocmd InsertEnter,InsertChange * let &l:statusline = "%!StatusLine( 'INS' )"
autocmd WinLeave * let &l:statusline = "%!StatusLine( 'NC' )"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: \@= doesn't seem to be working in very magic mode
On Mon, Dec 30, 2013 at 12:02 AM, Paul Isambert <zappathustra@free.fr> wrote:
Mohit Sharma <mohit.sharma0690@gmail.com> a écrit:
@ shouldn't be escaped with \v, because only [0-9A-Za-z_] have their> Hey guys,
>
> Are \@* (\@=, \@! etc.) supported in vim's "very magic" mode? It doesn't
> seem to be working for me e.g.
>
> for text "foobar" when I do
>
> >>/\vfoo(bar)\@= matches foobar
> >>/foo\(bar\)\@= matches foo correctly
>
> it matches the entire foobar instead of just foo. Is this expected?
usual (unescaped) meaning; the correct pattern is:
\vfoo(bar)@=
Ahh I knew I was doing something stupid, my bad. Thanks
Best,
Paul
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: \@= doesn't seem to be working in very magic mode
Mohit Sharma <mohit.sharma0690@gmail.com> a écrit:
> Hey guys,
>
> Are \@* (\@=, \@! etc.) supported in vim's "very magic" mode? It doesn't
> seem to be working for me e.g.
>
> for text "foobar" when I do
>
> >>/\vfoo(bar)\@= matches foobar
> >>/foo\(bar\)\@= matches foo correctly
>
> it matches the entire foobar instead of just foo. Is this expected?
@ shouldn't be escaped with \v, because only [0-9A-Za-z_] have their
usual (unescaped) meaning; the correct pattern is:
\vfoo(bar)@=
Best,
Paul
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> Hey guys,
>
> Are \@* (\@=, \@! etc.) supported in vim's "very magic" mode? It doesn't
> seem to be working for me e.g.
>
> for text "foobar" when I do
>
> >>/\vfoo(bar)\@= matches foobar
> >>/foo\(bar\)\@= matches foo correctly
>
> it matches the entire foobar instead of just foo. Is this expected?
@ shouldn't be escaped with \v, because only [0-9A-Za-z_] have their
usual (unescaped) meaning; the correct pattern is:
\vfoo(bar)@=
Best,
Paul
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Sunday, December 29, 2013
funcrefs forms
Hello,
Trying to understand the difference (and pros/cons) between the form1
and form2 funcref usage in the following sample code. In a previous
discussion, Nikolay Pavlov said : "[…] I tend to use anonymous functions
(and only them as far as I can)", now I'm wondering why.
Regards,
.vim <--
function! s:SID()
return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
endfunction
function! s:objectConstructor(name)
let obj = {}
let obj.name = a:name
let obj.form1 = s:objFuncs.form1
let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
return obj
endfunction
let s:objFuncs = {}
function! s:objFuncs.form1()
echo self.name
endfunction
function! <SID>s:objFuncs_form2() dict
echo self.name
endfunction
let otst = s:objectConstructor('test')
call otst.form1()
call otst.form2()
-->
--
___________________
| $ post_tenebras ↲ | waouh !
| GNU \ / | /
| -- * -- | o
| $ who ↲ / \ |_-- ~_|
| Alexandre Hoïde | _/| |
-------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Trying to understand the difference (and pros/cons) between the form1
and form2 funcref usage in the following sample code. In a previous
discussion, Nikolay Pavlov said : "[…] I tend to use anonymous functions
(and only them as far as I can)", now I'm wondering why.
Regards,
.vim <--
function! s:SID()
return matchstr(expand('<sfile>'), '<SNR>\zs\d\+\ze_SID$')
endfunction
function! s:objectConstructor(name)
let obj = {}
let obj.name = a:name
let obj.form1 = s:objFuncs.form1
let obj.form2 = function('<SNR>' . s:SID() . '_s:objFuncs_form2')
return obj
endfunction
let s:objFuncs = {}
function! s:objFuncs.form1()
echo self.name
endfunction
function! <SID>s:objFuncs_form2() dict
echo self.name
endfunction
let otst = s:objectConstructor('test')
call otst.form1()
call otst.form2()
-->
--
___________________
| $ post_tenebras ↲ | waouh !
| GNU \ / | /
| -- * -- | o
| $ who ↲ / \ |_-- ~_|
| Alexandre Hoïde | _/| |
-------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Where is my system-wide init file?
On 29/12/13 21:15, Elena Garrulo wrote:
> Tony, thank you for your detailed answer. By following your advice, I
> have tracked down where Vim looks for its system-wide init file. It
> is either in /etc/vim/ or in /usr/share/vim/, but I still don't
> understand why Vim looks there, considering that no Vim-related
> environment variable points there.
>
> Also, could it be that I'm experiencing frequent GVim crashes because
> my installation is not configured properly? There are no environment
> variable that are related to Vim. Should I create any?
>
> I'm answering your probing questions in case there are other things
> that I'm missing.
>
> On Sunday, December 29, 2013 12:43:43 PM UTC+1,
> Tony Mechelynck wrote: > 1. Try "ls -l" on some of these files (in
> subfolders of /etc and of > > /usr/share) to see if any of them is a
> soft link. (Seeing if it's a hard > > link is less obvious). Or maybe
> /home/egarrulo or > > /home/egarrulo/bin/vim/vim-7.4.280/share are
> soft links?
>
> Yes, the init files in /usr/share link to the same files in /etc.
>
> /home/egarrulo/bin/vim/vim-7.4.280 is the folder where I have
> installed Vim, after building it with:
>
> ./configure --prefix=/home/egarrulo/bin/vim/vim-7.4.280
>
> I did so to avoid clashing with the Vim version that comes with my
> distro.
Well, without any --prefix=, vim would have been built so as to install
into subdirectories of /usr/local/ (as is does on my system: the
executable as /usr/local/bin/vim, the runtime files in
/usr/local/share/vim/vim74/, and looking for your $VIM at
/usr/local/share/vim/) and that wouldn't have overwritten your distro's
Vim either. It would also, with no further ado, have put the newly
compiled version before your distro's in the $PATH (since /usr/local/bin
comes before /usr/bin) so invoking "vim" with no path at the shell
prompt would have got your Vim and not the distro's.
That location is "visible" to everyone but you may need to run "make
install" from a root login (after login to root or su root). "make
config" and "make" can still be run from any desired login.
>
>> 2. Maybe there is another Vim (later in the $PATH) on your system?
>
> Yes, there is: /usr/bin/vim. It is the build that comes with my distro.
>
> Thank you for making me learn the "type" command. Cool! :-)
There is also "which" which is a separate program (and thus works for
all shells) but it doesn't know about shell aliases.
>
>> The system-wide vimrc for that copy of Vim, sourced before the user's
>>
>> vimrc, is $VIM/vimrc — with whatever $VIM may be when that user runs
>>
>> Vim.
>
> $VIM is empty.
>
>
>> You seem to find that $VIM is $HOME/vim/vim-7.4.280/share/vim, for
>>
>> another user it would probably not be a subfolder of _your_ $HOME.
>>
>>
>>
>
>> Also, I wonder why you have a "vim-7.4.280" link in that path. Do you
>>
>> change that at every patchlevel? Also, where did you get that "280"
>>
>> from? The current patchlevel is only 7.4.131.
>
> Indeed, at startup, Vim says it is version 7.4.131.
>
> I didn't know about the patchlevel when I compiled Vim. I got the
> version from the "version.h" file:
>
> #define VIM_VERSION_MAJOR 7
> #define VIM_VERSION_MINOR 4
> #define VIM_VERSION_BUILD 280
I wonder what that VIM_VERSION_BUILD means.
>
>>
>>
>>
>> For the Vim that I compile for my home computer, I use Vim's defaults,
>>
>> namely:
>>
>>
>>
>> $VIM = /usr/local/share/vim
>>
>> $VIMRUNTIME = $VIM/vim74 (at version 7.4)
>
> I did the same. I only used the "--prefix" option with "./configure".
>
Well, that is where you overrode Vim's defaults. As I said above, it was
not necessary.
Best regards,
Tony.
--
You will be the victim of a bizarre joke.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> Tony, thank you for your detailed answer. By following your advice, I
> have tracked down where Vim looks for its system-wide init file. It
> is either in /etc/vim/ or in /usr/share/vim/, but I still don't
> understand why Vim looks there, considering that no Vim-related
> environment variable points there.
>
> Also, could it be that I'm experiencing frequent GVim crashes because
> my installation is not configured properly? There are no environment
> variable that are related to Vim. Should I create any?
>
> I'm answering your probing questions in case there are other things
> that I'm missing.
>
> On Sunday, December 29, 2013 12:43:43 PM UTC+1,
> Tony Mechelynck wrote: > 1. Try "ls -l" on some of these files (in
> subfolders of /etc and of > > /usr/share) to see if any of them is a
> soft link. (Seeing if it's a hard > > link is less obvious). Or maybe
> /home/egarrulo or > > /home/egarrulo/bin/vim/vim-7.4.280/share are
> soft links?
>
> Yes, the init files in /usr/share link to the same files in /etc.
>
> /home/egarrulo/bin/vim/vim-7.4.280 is the folder where I have
> installed Vim, after building it with:
>
> ./configure --prefix=/home/egarrulo/bin/vim/vim-7.4.280
>
> I did so to avoid clashing with the Vim version that comes with my
> distro.
Well, without any --prefix=, vim would have been built so as to install
into subdirectories of /usr/local/ (as is does on my system: the
executable as /usr/local/bin/vim, the runtime files in
/usr/local/share/vim/vim74/, and looking for your $VIM at
/usr/local/share/vim/) and that wouldn't have overwritten your distro's
Vim either. It would also, with no further ado, have put the newly
compiled version before your distro's in the $PATH (since /usr/local/bin
comes before /usr/bin) so invoking "vim" with no path at the shell
prompt would have got your Vim and not the distro's.
That location is "visible" to everyone but you may need to run "make
install" from a root login (after login to root or su root). "make
config" and "make" can still be run from any desired login.
>
>> 2. Maybe there is another Vim (later in the $PATH) on your system?
>
> Yes, there is: /usr/bin/vim. It is the build that comes with my distro.
>
> Thank you for making me learn the "type" command. Cool! :-)
There is also "which" which is a separate program (and thus works for
all shells) but it doesn't know about shell aliases.
>
>> The system-wide vimrc for that copy of Vim, sourced before the user's
>>
>> vimrc, is $VIM/vimrc — with whatever $VIM may be when that user runs
>>
>> Vim.
>
> $VIM is empty.
>
>
>> You seem to find that $VIM is $HOME/vim/vim-7.4.280/share/vim, for
>>
>> another user it would probably not be a subfolder of _your_ $HOME.
>>
>>
>>
>
>> Also, I wonder why you have a "vim-7.4.280" link in that path. Do you
>>
>> change that at every patchlevel? Also, where did you get that "280"
>>
>> from? The current patchlevel is only 7.4.131.
>
> Indeed, at startup, Vim says it is version 7.4.131.
>
> I didn't know about the patchlevel when I compiled Vim. I got the
> version from the "version.h" file:
>
> #define VIM_VERSION_MAJOR 7
> #define VIM_VERSION_MINOR 4
> #define VIM_VERSION_BUILD 280
I wonder what that VIM_VERSION_BUILD means.
>
>>
>>
>>
>> For the Vim that I compile for my home computer, I use Vim's defaults,
>>
>> namely:
>>
>>
>>
>> $VIM = /usr/local/share/vim
>>
>> $VIMRUNTIME = $VIM/vim74 (at version 7.4)
>
> I did the same. I only used the "--prefix" option with "./configure".
>
Well, that is where you overrode Vim's defaults. As I said above, it was
not necessary.
Best regards,
Tony.
--
You will be the victim of a bizarre joke.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Subscribe to:
Posts (Atom)