On Sat, Feb 27, 2016, Brian Feeny wrote:
> I am trying to outdent in visual block mode (Ctrl-V), but when I press < it doesn't outdent. when I press > it properly indents. I am fairly new to VIM. Here is my .vimrc, I am wondering if something could be interfering with <
Does it outdent after a certain timeout? Or not at all? I used to have
the former problem; it turned out I had a mapping starting with < (which
was intended to be a special thing like <CR> or the like; not literally
a less-than sign followed by whatever). I don't see that in your .vimrc,
though.
--
Eric Christopherson
--
--
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/d/optout.
Monday, February 29, 2016
Re: netrw :Explore setting current buffer to hidden
gt.macki@gmail.com wrote:
> hello all,
>
> On Vim 7.4.1401 (OS X 10.11.3), netrw's :Explore is acting very weirdly for me.
>
> My workflow is to usually open some file, use :Explore to search for related documents and switch between buffers as I need. Since at least 7.4.1401 calling :Explore hides the current buffer, even if it has been edited.
>
> Steps to reproduce:
> 1. Start with `vim file1.txt`;
> 2. inside vim use `:Explore`;
> 3. open `file2.txt` and find that `file1.txt` is not available anymore and is not displayed on`:ls` — the only way to access it is to use `:ls!`, check the buffer number and use `b{buffer_number}`.
>
> Since I'm managing vim with homebrew, I reverted to the previous version, 7.4.1345, and it seems to fix the issue at hand. It does not seem to be related to plugins (have disabled most of them before posting this).
>
> any clues on what might be happening? is this an actual issue or was I relying on faulty behaviour (seems unlikely since I've been netrw in this manner for at least 2 years now)?
>
Hello!
I see the problem; I'll look into it.
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/d/optout.
> hello all,
>
> On Vim 7.4.1401 (OS X 10.11.3), netrw's :Explore is acting very weirdly for me.
>
> My workflow is to usually open some file, use :Explore to search for related documents and switch between buffers as I need. Since at least 7.4.1401 calling :Explore hides the current buffer, even if it has been edited.
>
> Steps to reproduce:
> 1. Start with `vim file1.txt`;
> 2. inside vim use `:Explore`;
> 3. open `file2.txt` and find that `file1.txt` is not available anymore and is not displayed on`:ls` — the only way to access it is to use `:ls!`, check the buffer number and use `b{buffer_number}`.
>
> Since I'm managing vim with homebrew, I reverted to the previous version, 7.4.1345, and it seems to fix the issue at hand. It does not seem to be related to plugins (have disabled most of them before posting this).
>
> any clues on what might be happening? is this an actual issue or was I relying on faulty behaviour (seems unlikely since I've been netrw in this manner for at least 2 years now)?
>
Hello!
I see the problem; I'll look into it.
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/d/optout.
Re: netrw :Explore setting current buffer to hidden
thank you both for your replies.
@charles: seeing you're the creator of the plugin, do you believe that the specific issue I'm having is due to one of the "interesting" combinations of settings/system/etc? Have you seen it popping up before? I'm happy to post more specific info regarding my setup if you think this is a real problem you might eventually look into. In any case, thank you for the the time you dedicate to netrw.
--
--
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/d/optout.
@charles: seeing you're the creator of the plugin, do you believe that the specific issue I'm having is due to one of the "interesting" combinations of settings/system/etc? Have you seen it popping up before? I'm happy to post more specific info regarding my setup if you think this is a real problem you might eventually look into. In any case, thank you for the the time you dedicate to netrw.
--
--
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/d/optout.
Re: netrw :Explore setting current buffer to hidden
Justin M. Keyes wrote:
> On Mon, Feb 29, 2016 at 12:31 PM, Charles E Campbell
> <drchip@campbellfamily.biz> wrote:
>> Justin M. Keyes wrote:
>>> netrw is 11,000 (eleven thousand) lines of code without any automated
>>> tests.
>> That, as it turns out, is not the case. I do have automated tests for
>> it. The tests are based on pchk
>> (http://www.drchip.org/astronaut/vim/index.html#PCHK); however, ever
>> since patch#866, there's been a problem with hanging (probalby due to a
>> race condition in vim), so I haven't made the pchk-based test suite for
>> netrw available.
> I mean "automated" in the sense that any Vim regression would be
> immediately caught. How much coverage would you estimate?
>
I currently have 56 test files and am adding more as time goes on, with
over 930 lines in the test files. "Any regression" is overly broad, as
I'm sure that there are cases that I haven't covered. There are four
display types (thin, long, wide, tree). Various patterns may be used to
include/exclude listings. Trees have a lot of differences, as more than
one directory is being shown at a time (unlike thin, long, wide). Users
may have differing settings with "interesting" interactions. I'm going
over old bug reports and making pchk tests from them.
C 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/d/optout.
> On Mon, Feb 29, 2016 at 12:31 PM, Charles E Campbell
> <drchip@campbellfamily.biz> wrote:
>> Justin M. Keyes wrote:
>>> netrw is 11,000 (eleven thousand) lines of code without any automated
>>> tests.
>> That, as it turns out, is not the case. I do have automated tests for
>> it. The tests are based on pchk
>> (http://www.drchip.org/astronaut/vim/index.html#PCHK); however, ever
>> since patch#866, there's been a problem with hanging (probalby due to a
>> race condition in vim), so I haven't made the pchk-based test suite for
>> netrw available.
> I mean "automated" in the sense that any Vim regression would be
> immediately caught. How much coverage would you estimate?
>
I currently have 56 test files and am adding more as time goes on, with
over 930 lines in the test files. "Any regression" is overly broad, as
I'm sure that there are cases that I haven't covered. There are four
display types (thin, long, wide, tree). Various patterns may be used to
include/exclude listings. Trees have a lot of differences, as more than
one directory is being shown at a time (unlike thin, long, wide). Users
may have differing settings with "interesting" interactions. I'm going
over old bug reports and making pchk tests from them.
C 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/d/optout.
Re: netrw :Explore setting current buffer to hidden
On Mon, Feb 29, 2016 at 12:31 PM, Charles E Campbell
<drchip@campbellfamily.biz> wrote:
> Justin M. Keyes wrote:
>> netrw is 11,000 (eleven thousand) lines of code without any automated
>> tests.
> That, as it turns out, is not the case. I do have automated tests for
> it. The tests are based on pchk
> (http://www.drchip.org/astronaut/vim/index.html#PCHK); however, ever
> since patch#866, there's been a problem with hanging (probalby due to a
> race condition in vim), so I haven't made the pchk-based test suite for
> netrw available.
I mean "automated" in the sense that any Vim regression would be
immediately caught. How much coverage would you estimate?
Justin M. Keyes
--
--
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/d/optout.
<drchip@campbellfamily.biz> wrote:
> Justin M. Keyes wrote:
>> netrw is 11,000 (eleven thousand) lines of code without any automated
>> tests.
> That, as it turns out, is not the case. I do have automated tests for
> it. The tests are based on pchk
> (http://www.drchip.org/astronaut/vim/index.html#PCHK); however, ever
> since patch#866, there's been a problem with hanging (probalby due to a
> race condition in vim), so I haven't made the pchk-based test suite for
> netrw available.
I mean "automated" in the sense that any Vim regression would be
immediately caught. How much coverage would you estimate?
Justin M. Keyes
--
--
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/d/optout.
Re: Back reference across range
2016-02-29 20:40 GMT+03:00 Paul <google1241@rainslide.net>:
> To fold a closing brace at the same indentation level as its opening "sub
> {", this doesn't work, because of the back reference:
>
> :g/\v^(\s+)sub \{/,/\v\1\}/fold
>
> This is just an example, I could be matching "foo" and "bar", I'm just
> wondering if there is a way to use a back reference across a range.
You can save indentation in a variable and use :execute to construct a
regular expression which does not use cross-regexp references. The
only place where cross-regexp references actually work is `:syntax
region start`: `:h /\z(`. Documentation though is written like there
were plans to use \z( outside of :syntax.
>
> --
> --
> 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/d/optout.
--
--
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/d/optout.
> To fold a closing brace at the same indentation level as its opening "sub
> {", this doesn't work, because of the back reference:
>
> :g/\v^(\s+)sub \{/,/\v\1\}/fold
>
> This is just an example, I could be matching "foo" and "bar", I'm just
> wondering if there is a way to use a back reference across a range.
You can save indentation in a variable and use :execute to construct a
regular expression which does not use cross-regexp references. The
only place where cross-regexp references actually work is `:syntax
region start`: `:h /\z(`. Documentation though is written like there
were plans to use \z( outside of :syntax.
>
> --
> --
> 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/d/optout.
--
--
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/d/optout.
Back reference across range
To fold a closing brace at the same indentation level as its opening "sub {", this doesn't work, because of the back reference:
:g/\v^(\s+)sub \{/,/\v\1\}/fold
This is just an example, I could be matching "foo" and "bar", I'm just wondering if there is a way to use a back reference across a range.
--
--
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/d/optout.
:g/\v^(\s+)sub \{/,/\v\1\}/fold
This is just an example, I could be matching "foo" and "bar", I'm just wondering if there is a way to use a back reference across a range.
--
--
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/d/optout.
Re: netrw :Explore setting current buffer to hidden
Justin M. Keyes wrote:
> netrw is 11,000 (eleven thousand) lines of code without any automated
> tests.
That, as it turns out, is not the case. I do have automated tests for
it. The tests are based on pchk
(http://www.drchip.org/astronaut/vim/index.html#PCHK); however, ever
since patch#866, there's been a problem with hanging (probalby due to a
race condition in vim), so I haven't made the pchk-based test suite for
netrw available.
C 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/d/optout.
> netrw is 11,000 (eleven thousand) lines of code without any automated
> tests.
That, as it turns out, is not the case. I do have automated tests for
it. The tests are based on pchk
(http://www.drchip.org/astronaut/vim/index.html#PCHK); however, ever
since patch#866, there's been a problem with hanging (probalby due to a
race condition in vim), so I haven't made the pchk-based test suite for
netrw available.
C 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/d/optout.
E137: Viminfo file is not writable ../viminfo
Does anyone have this problem with vi? My files save, but this error message is annoying after a while.
--
--
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/d/optout.
--
--
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/d/optout.
Re: netrw :Explore setting current buffer to hidden
netrw is 11,000 (eleven thousand) lines of code without any automated
tests. You might want to try dirvish.vim[1] (400 lines of code, also
no tests), the first file manager that actually leverages Vim's
built-in features.
https://github.com/justinmk/vim-dirvish
Justin M. Keyes
On Mon, Feb 29, 2016 at 8:45 AM, <gt.macki@gmail.com> wrote:
> hello all,
>
> On Vim 7.4.1401 (OS X 10.11.3), netrw's :Explore is acting very weirdly for me.
>
> My workflow is to usually open some file, use :Explore to search for related documents and switch between buffers as I need. Since at least 7.4.1401 calling :Explore hides the current buffer, even if it has been edited.
>
> Steps to reproduce:
> 1. Start with `vim file1.txt`;
> 2. inside vim use `:Explore`;
> 3. open `file2.txt` and find that `file1.txt` is not available anymore and is not displayed on`:ls` — the only way to access it is to use `:ls!`, check the buffer number and use `b{buffer_number}`.
>
> Since I'm managing vim with homebrew, I reverted to the previous version, 7.4.1345, and it seems to fix the issue at hand. It does not seem to be related to plugins (have disabled most of them before posting this).
>
> any clues on what might be happening? is this an actual issue or was I relying on faulty behaviour (seems unlikely since I've been netrw in this manner for at least 2 years now)?
>
> thanks in advance for any input!
>
> --
> --
> 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/d/optout.
--
--
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/d/optout.
tests. You might want to try dirvish.vim[1] (400 lines of code, also
no tests), the first file manager that actually leverages Vim's
built-in features.
https://github.com/justinmk/vim-dirvish
Justin M. Keyes
On Mon, Feb 29, 2016 at 8:45 AM, <gt.macki@gmail.com> wrote:
> hello all,
>
> On Vim 7.4.1401 (OS X 10.11.3), netrw's :Explore is acting very weirdly for me.
>
> My workflow is to usually open some file, use :Explore to search for related documents and switch between buffers as I need. Since at least 7.4.1401 calling :Explore hides the current buffer, even if it has been edited.
>
> Steps to reproduce:
> 1. Start with `vim file1.txt`;
> 2. inside vim use `:Explore`;
> 3. open `file2.txt` and find that `file1.txt` is not available anymore and is not displayed on`:ls` — the only way to access it is to use `:ls!`, check the buffer number and use `b{buffer_number}`.
>
> Since I'm managing vim with homebrew, I reverted to the previous version, 7.4.1345, and it seems to fix the issue at hand. It does not seem to be related to plugins (have disabled most of them before posting this).
>
> any clues on what might be happening? is this an actual issue or was I relying on faulty behaviour (seems unlikely since I've been netrw in this manner for at least 2 years now)?
>
> thanks in advance for any input!
>
> --
> --
> 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/d/optout.
--
--
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/d/optout.
netrw :Explore setting current buffer to hidden
hello all,
On Vim 7.4.1401 (OS X 10.11.3), netrw's :Explore is acting very weirdly for me.
My workflow is to usually open some file, use :Explore to search for related documents and switch between buffers as I need. Since at least 7.4.1401 calling :Explore hides the current buffer, even if it has been edited.
Steps to reproduce:
1. Start with `vim file1.txt`;
2. inside vim use `:Explore`;
3. open `file2.txt` and find that `file1.txt` is not available anymore and is not displayed on`:ls` — the only way to access it is to use `:ls!`, check the buffer number and use `b{buffer_number}`.
Since I'm managing vim with homebrew, I reverted to the previous version, 7.4.1345, and it seems to fix the issue at hand. It does not seem to be related to plugins (have disabled most of them before posting this).
any clues on what might be happening? is this an actual issue or was I relying on faulty behaviour (seems unlikely since I've been netrw in this manner for at least 2 years now)?
thanks in advance for any input!
--
--
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/d/optout.
On Vim 7.4.1401 (OS X 10.11.3), netrw's :Explore is acting very weirdly for me.
My workflow is to usually open some file, use :Explore to search for related documents and switch between buffers as I need. Since at least 7.4.1401 calling :Explore hides the current buffer, even if it has been edited.
Steps to reproduce:
1. Start with `vim file1.txt`;
2. inside vim use `:Explore`;
3. open `file2.txt` and find that `file1.txt` is not available anymore and is not displayed on`:ls` — the only way to access it is to use `:ls!`, check the buffer number and use `b{buffer_number}`.
Since I'm managing vim with homebrew, I reverted to the previous version, 7.4.1345, and it seems to fix the issue at hand. It does not seem to be related to plugins (have disabled most of them before posting this).
any clues on what might be happening? is this an actual issue or was I relying on faulty behaviour (seems unlikely since I've been netrw in this manner for at least 2 years now)?
thanks in advance for any input!
--
--
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/d/optout.
Sunday, February 28, 2016
Re: Vim compiled for Python but omnisharp fails
On Sun, Feb 28, 2016 at 3:22 PM, Ni Va <nivaemail@gmail.com> wrote:
Hi,
I have just compiled Vim with +Python/dyn feature but when I start my vim own distri that uses omnisharp, this says :
Error Desktop\Vim\awesomeplugins\omnisharp-vim-master\plugin\OmniSharp.vim :
ligne 2 :
Error: OmniSharp requires Vim compiled with +python.
When I call :ver from within Vim it says that I have +python/dyn included.
So I don't see where is problem.
In my windows path I got c:\python27 and c:\python27\include and lib.
Perhaps you are using 64bit Vim with 32bit Python or vice versa?
Additionally if you are using Python-2.7.11, it has problem. You might have
to set PYTHONHOME environment variable or edit registry.
https://github.com/vim/vim/issues/526.
--
to set PYTHONHOME environment variable or edit registry.
https://github.com/vim/vim/issues/526.
--
Yukihiro Nakadaira - yukihiro.nakadaira@gmail.com
--
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/d/optout.
Re: Replace c cast to c++ style cast
Hi Jorge,
> Luc, I did install your library but the mapping provided ,,sc didn't
> do anything for me.
You have to select the C cast expression before hitting ,,sc. Depending on your leaderleader, it could be something else.
> I did have an error when entering a c++ buffer after loading the
> plugin with VAM, something like:
>
> line 39:
> E227: mapping already exists for <80><fc>^D
Unfortunately, I have to idea which key <80><fc> refers to. It's line 39 from which file? Once you identify it you should be able to provide another keybinding in your .vimrc (or may be in a ftplugin with higher priority)
> I am not sure this is the reason I cannot use the mapping provided in
> your plugin.
>
>
> I did write a function and mapping that for now should suit my needs:
It could be simpler:
" From ftplugin/cpp/cpp_snippets.vim
vnoremap <silent> <buffer> <LocalLeader><LocalLeader>sc
\ <c-\><c-n>:'<,'>call <sid>ConvertToCPPCast('static_cast')<cr>
nmap <silent> <buffer> <LocalLeader><LocalLeader>sc viw<LocalLeader><LocalLeader>sc
function! s:ConvertToCPPCast(cast_type) abort
" Extract text to convert
let save_a = @a
silent normal! gv"ay
" Strip the possible brackets around the expression
" matchlist seems to cause an odd error on multiline C cast expressions: it
" have the fucntion called again.
let [all, type, expr ; tail] = matchlist(@a, '\v^\(\_s*(.{-})\_s*\)\_s*(.{-})\_s*$')
let expr = substitute(expr, '\v^\(\s*(.{-})\s*\)$', '\1', '')
"
" Build the C++-casting from the C casting
let new_cast = a:cast_type.'<'.type.'>('.expr.')'
" Do the replacement
silent exe "normal! gvs".new_cast."\<esc>"
let @a = save_a
endfunction
--
Luc Hermitte
--
--
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/d/optout.
> Luc, I did install your library but the mapping provided ,,sc didn't
> do anything for me.
You have to select the C cast expression before hitting ,,sc. Depending on your leaderleader, it could be something else.
> I did have an error when entering a c++ buffer after loading the
> plugin with VAM, something like:
>
> line 39:
> E227: mapping already exists for <80><fc>^D
Unfortunately, I have to idea which key <80><fc> refers to. It's line 39 from which file? Once you identify it you should be able to provide another keybinding in your .vimrc (or may be in a ftplugin with higher priority)
> I am not sure this is the reason I cannot use the mapping provided in
> your plugin.
>
>
> I did write a function and mapping that for now should suit my needs:
It could be simpler:
" From ftplugin/cpp/cpp_snippets.vim
vnoremap <silent> <buffer> <LocalLeader><LocalLeader>sc
\ <c-\><c-n>:'<,'>call <sid>ConvertToCPPCast('static_cast')<cr>
nmap <silent> <buffer> <LocalLeader><LocalLeader>sc viw<LocalLeader><LocalLeader>sc
function! s:ConvertToCPPCast(cast_type) abort
" Extract text to convert
let save_a = @a
silent normal! gv"ay
" Strip the possible brackets around the expression
" matchlist seems to cause an odd error on multiline C cast expressions: it
" have the fucntion called again.
let [all, type, expr ; tail] = matchlist(@a, '\v^\(\_s*(.{-})\_s*\)\_s*(.{-})\_s*$')
let expr = substitute(expr, '\v^\(\s*(.{-})\s*\)$', '\1', '')
"
" Build the C++-casting from the C casting
let new_cast = a:cast_type.'<'.type.'>('.expr.')'
" Do the replacement
silent exe "normal! gvs".new_cast."\<esc>"
let @a = save_a
endfunction
--
Luc Hermitte
--
--
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/d/optout.
Saturday, February 27, 2016
outdenting in visual block mode
I am trying to outdent in visual block mode (Ctrl-V), but when I press < it doesn't outdent. when I press > it properly indents. I am fairly new to VIM. Here is my .vimrc, I am wondering if something could be interfering with <
set nocompatible " be iMproved, required
filetype off " required
" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" alternatively, pass a path where Vundle should install plugins
"call vundle#begin('~/some/path/here')
" let Vundle manage Vundle, required
Plugin 'VundleVim/Vundle.vim'
" Plugin 'Valloric/YouCompleteMe'
Plugin 'scwood/vim-hybrid'
" The following are examples of different formats supported.
" Keep Plugin commands between vundle#begin/end.
" plugin on GitHub repo
" Plugin 'tpope/vim-fugitive'
" plugin from http://vim-scripts.org/vim/scripts.html
" Plugin 'L9'
" Git plugin not hosted on GitHub
" Plugin 'git://git.wincent.com/command-t.git'
" git repos on your local machine (i.e. when working on your own plugin)
" Plugin 'file:///home/gmarik/path/to/plugin'
" The sparkup vim script is in a subdirectory of this repo called vim.
" Pass the path to set the runtimepath properly.
" Plugin 'rstacruz/sparkup', {'rtp': 'vim/'}
" Avoid a name conflict with L9
" Plugin 'user/L9', {'name': 'newL9'}
" All of your Plugins must be added before the following line
call vundle
set nocompatible " be iMproved, required
filetype off " required
" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" alternatively, pass a path where Vundle should install plugins
"call vundle#begin('~/some/path/here')
" let Vundle manage Vundle, required
Plugin 'VundleVim/Vundle.vim'
" Plugin 'Valloric/YouCompleteMe'
Plugin 'scwood/vim-hybrid'
" The following are examples of different formats supported.
" Keep Plugin commands between vundle#begin/end.
" plugin on GitHub repo
" Plugin 'tpope/vim-fugitive'
" plugin from http://vim-scripts.org/vim/scripts.html
" Plugin 'L9'
" Git plugin not hosted on GitHub
" Plugin 'git://git.wincent.com/command-t.git'
" git repos on your local machine (i.e. when working on your own plugin)
" Plugin 'file:///home/gmarik/path/to/plugin'
" The sparkup vim script is in a subdirectory of this repo called vim.
" Pass the path to set the runtimepath properly.
" Plugin 'rstacruz/sparkup', {'rtp': 'vim/'}
" Avoid a name conflict with L9
" Plugin 'user/L9', {'name': 'newL9'}
" All of your Plugins must be added before the following line
call vundle
Re: how to transfer output of ':.w !sh' back to current buffer
On 26.02.16 08:29, Roman wrote:
> I use ':.w !sh' to run some lines with shell commands
> Is any way to transfer output of this commands back to buffer or maybe
> to split buffer window or do something like ':r !sh $current_line'
The easiest way to return the result is not to use ":.w", but the !
command instead. To quickly confirm that the pipe output returns,
perhaps type:
!!echo "No-one expects the Spanish Inquisition"
To confirm the return trip on e.g. a whole paragraph, place the cursor
on its start, and type:
!}gawk '{gsub(/\<the\>/,"FROG"); print}'
If there are any "the" words, the transformation is not hard to spot.
And if the outcome is not what's desired, there's undo.
Now your commands/scripts can be unleashed with confidence.
Erik
--
--
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/d/optout.
> I use ':.w !sh' to run some lines with shell commands
> Is any way to transfer output of this commands back to buffer or maybe
> to split buffer window or do something like ':r !sh $current_line'
The easiest way to return the result is not to use ":.w", but the !
command instead. To quickly confirm that the pipe output returns,
perhaps type:
!!echo "No-one expects the Spanish Inquisition"
To confirm the return trip on e.g. a whole paragraph, place the cursor
on its start, and type:
!}gawk '{gsub(/\<the\>/,"FROG"); print}'
If there are any "the" words, the transformation is not hard to spot.
And if the outcome is not what's desired, there's undo.
Now your commands/scripts can be unleashed with confidence.
Erik
--
--
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/d/optout.
Vim compiled for Python but omnisharp fails
Hi,
I have just compiled Vim with +Python/dyn feature but when I start my vim own distri that uses omnisharp, this says :
Error Desktop\Vim\awesomeplugins\omnisharp-vim-master\plugin\OmniSharp.vim :
ligne 2 :
Error: OmniSharp requires Vim compiled with +python.
When I call :ver from within Vim it says that I have +python/dyn included.
So I don't see where is problem.
In my windows path I got c:\python27 and c:\python27\include and lib.
Thank you
--
--
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/d/optout.
I have just compiled Vim with +Python/dyn feature but when I start my vim own distri that uses omnisharp, this says :
Error Desktop\Vim\awesomeplugins\omnisharp-vim-master\plugin\OmniSharp.vim :
ligne 2 :
Error: OmniSharp requires Vim compiled with +python.
When I call :ver from within Vim it says that I have +python/dyn included.
So I don't see where is problem.
In my windows path I got c:\python27 and c:\python27\include and lib.
Thank you
--
--
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/d/optout.
Re: Replace c cast to c++ style cast
Hi Dominique and Luc,
thanks you for the advice. I agree that it is not a good idea to blindly replace everything. The most common case for me is probably static_cast so I would do that by default.
> In lh-cpp (*), I have 3 mappings that transform C casts into C++ casts -- and 6 more to cast an expression.
>
> This has to be done manually: you'll have to know if you want a const_cast, a static_cast, or a reinterpret_cast. As Dominique said, it can't really be done automatically. May be, clang could automate many things, but it won't be able to know whether you want to downcast with a dynamic_cast or with a static_cast?
>
> (*) https://github.com/LucHermitte/lh-cpp
>
Luc, I did install your library but the mapping provided ,,sc didn't do anything for me.
I did have an error when entering a c++ buffer after loading the plugin with VAM, something like:
line 39:
E227: mapping already exists for <80><fc>^D
I am not sure this is the reason I cannot use the mapping provided in your plugin.
I did write a function and mapping that for now should suit my needs:
function! ToStatic1()
" (type) b -> static_cast<type>(b)
" it is assumed cursor is inside the first cast
let original_keyword = &iskeyword
setlocal iskeyword +=_
setlocal iskeyword +=[
setlocal iskeyword +=]
setlocal iskeyword +=:
normal di(
let @a = @"
normal da(
normal istatic_cast<>
normal h
normal "ap
normal f>l
while 1
"get current char
let c = getline('.')[col('.')-1]
if c == ' '
normal x
else
break
endif
endwhile
echom c
if c != '('
normal i(
normal e
normal a)
endif
let &iskeyword=original_keyword
endfunction
nnoremap <silent> ,a :call ToStatic1()<CR>
Thanks,
Jorge
--
--
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/d/optout.
thanks you for the advice. I agree that it is not a good idea to blindly replace everything. The most common case for me is probably static_cast so I would do that by default.
> In lh-cpp (*), I have 3 mappings that transform C casts into C++ casts -- and 6 more to cast an expression.
>
> This has to be done manually: you'll have to know if you want a const_cast, a static_cast, or a reinterpret_cast. As Dominique said, it can't really be done automatically. May be, clang could automate many things, but it won't be able to know whether you want to downcast with a dynamic_cast or with a static_cast?
>
> (*) https://github.com/LucHermitte/lh-cpp
>
Luc, I did install your library but the mapping provided ,,sc didn't do anything for me.
I did have an error when entering a c++ buffer after loading the plugin with VAM, something like:
line 39:
E227: mapping already exists for <80><fc>^D
I am not sure this is the reason I cannot use the mapping provided in your plugin.
I did write a function and mapping that for now should suit my needs:
function! ToStatic1()
" (type) b -> static_cast<type>(b)
" it is assumed cursor is inside the first cast
let original_keyword = &iskeyword
setlocal iskeyword +=_
setlocal iskeyword +=[
setlocal iskeyword +=]
setlocal iskeyword +=:
normal di(
let @a = @"
normal da(
normal istatic_cast<>
normal h
normal "ap
normal f>l
while 1
"get current char
let c = getline('.')[col('.')-1]
if c == ' '
normal x
else
break
endif
endwhile
echom c
if c != '('
normal i(
normal e
normal a)
endif
let &iskeyword=original_keyword
endfunction
nnoremap <silent> ,a :call ToStatic1()<CR>
Thanks,
Jorge
--
--
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/d/optout.
Re: gvim acts differently when invoked from mingw64 and ms-windows
Hi, Ken, thanks for the reply.
I have no vimrc/.vimrc/_vimrc in both $HOME. Anything in $HOME that connects to vim is _viminfo. This is just a history file.
My gvim is in d:\vim\vim74. And in both cases output of :scriptnames have the same line "d:\vim\_vimrc".
And here's how I start gvim in mingw:
this line in .bahs_profile: alias gvim='/d/vim/vim74/gvim.exe'
then:
$gvim
--
--
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/d/optout.
I have no vimrc/.vimrc/_vimrc in both $HOME. Anything in $HOME that connects to vim is _viminfo. This is just a history file.
My gvim is in d:\vim\vim74. And in both cases output of :scriptnames have the same line "d:\vim\_vimrc".
And here's how I start gvim in mingw:
this line in .bahs_profile: alias gvim='/d/vim/vim74/gvim.exe'
then:
$gvim
--
--
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/d/optout.
Re: gvim acts differently when invoked from mingw64 and ms-windows
Hi,
2016/2/28 Sun 2:18:54 UTC+9 Alexas Chee wrote:
> Yes, the _vimrc is the same one.
>
> $HOME is different, though. The Windows one is C:\user\myname; the mingw64 one is msys2/home/myname.
>
> But does $HOME matter in this case?
Vim will load .vimrc from $HOME. So you might get different results if the
.vimrc are different. (E.g. when you set different value in g:vimsyn_embed.)
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/d/optout.
2016/2/28 Sun 2:18:54 UTC+9 Alexas Chee wrote:
> Yes, the _vimrc is the same one.
>
> $HOME is different, though. The Windows one is C:\user\myname; the mingw64 one is msys2/home/myname.
>
> But does $HOME matter in this case?
Vim will load .vimrc from $HOME. So you might get different results if the
.vimrc are different. (E.g. when you set different value in g:vimsyn_embed.)
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/d/optout.
Re: gvim acts differently when invoked from mingw64 and ms-windows
Hi,
Yes, the _vimrc is the same one.
$HOME is different, though. The Windows one is C:\user\myname; the mingw64 one is msys2/home/myname.
But does $HOME matter in this case?
--
--
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/d/optout.
Yes, the _vimrc is the same one.
$HOME is different, though. The Windows one is C:\user\myname; the mingw64 one is msys2/home/myname.
But does $HOME matter in this case?
--
--
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/d/optout.
Re: cursor jumping in netrw with netrw_liststyle=3
++
Is there already some plans to fix it?
Sorry for being a bit pushy ... ;-)
--
--
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/d/optout.
Is there already some plans to fix it?
Sorry for being a bit pushy ... ;-)
--
--
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/d/optout.
Re: Packages
Ben Fritz wrote:
> On Friday, February 26, 2016 at 12:02:42 PM UTC-6, Bram Moolenaar wrote:
> > Christian Brabandt wrote:
> > >
> > > Really a plugin directory is necessary? That sounds awkward. What about
> > > colorschemes, indent or ftplugins and syntax scripts?
> > >
> > > We could still change it, right?
> > >
> > > > It would be possible to make another command than :loadplugin to find
> > > > any directory with the specified name under 'packpath', but I don't see
> > > > a good reason. Perhaps adding a remark to the documentation is
> > > > sufficient?
> > >
> > > I'd rather prefer it to be fixed instead of adding yet another command
> > > or option.
> >
> > Hmm, so we throw out ":loadplugin" and add ":loadpackitem"?
> > It would then find directories matching "pack/*/opt/{name}"
> >
>
> I agree this needs fixing. I did not realize only things with a "plugin" folder would be loaded, that makes the current implementation next to worthless as a replacement for things like Pathogen.
>
> The naming of the plugin was discussed in the first link from the OP: https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
>
> I think ":loadpackitem" would be a very awkward name, please don't use that. ":loadplugin" is sufficient and matches user expectations even if it isn't pedantically correct. ":loadaddon" might be a little better although we don't use the term "addon" anywhere else that I know of.
>
> TL;DR: just stick with the current name but fix the behavior.
We do have two different pieces of functionality:
- loading a plugin when desired
- adding a directory to 'runtimepath'
When talking about plugins, we expect a file plugin/foobar.vim that gets
loaded. Thus I do think that :loadplugin should do that.
Adding a directory to 'runtimepath', without loading a plugin, is
something else. Perhaps there is a plugin/foobar.vim, but it would only
be loaded if 'runtimepath' is updated early in initialization, so that
the plugin is found in step 4, see ":help load-plugins".
It gets more complicated if a plugin that is loaded in step 4 decides it
needs another plugin. Changing 'runtimepath' is not sufficient then,
the plugin must actually be loaded, it won't happen later. That is what
we need :loadplugin for.
Also, if there are several matching directories in 'packpath', and only
one actually has the plugin, that one must be used. Not one that is
found earlier but perhaps only has a syntax file.
We could add a command to add a directory under "pack" to
'runtimepath'. I believe that is the most straightforward way to allow
a user to do what he wants. We just need a good name.
":addtopath" perhaps? ":packadd"?
--
There are only two hard things in programming: Cache invalidation,
naming things and off-by-one errors.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/d/optout.
> On Friday, February 26, 2016 at 12:02:42 PM UTC-6, Bram Moolenaar wrote:
> > Christian Brabandt wrote:
> > >
> > > Really a plugin directory is necessary? That sounds awkward. What about
> > > colorschemes, indent or ftplugins and syntax scripts?
> > >
> > > We could still change it, right?
> > >
> > > > It would be possible to make another command than :loadplugin to find
> > > > any directory with the specified name under 'packpath', but I don't see
> > > > a good reason. Perhaps adding a remark to the documentation is
> > > > sufficient?
> > >
> > > I'd rather prefer it to be fixed instead of adding yet another command
> > > or option.
> >
> > Hmm, so we throw out ":loadplugin" and add ":loadpackitem"?
> > It would then find directories matching "pack/*/opt/{name}"
> >
>
> I agree this needs fixing. I did not realize only things with a "plugin" folder would be loaded, that makes the current implementation next to worthless as a replacement for things like Pathogen.
>
> The naming of the plugin was discussed in the first link from the OP: https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
>
> I think ":loadpackitem" would be a very awkward name, please don't use that. ":loadplugin" is sufficient and matches user expectations even if it isn't pedantically correct. ":loadaddon" might be a little better although we don't use the term "addon" anywhere else that I know of.
>
> TL;DR: just stick with the current name but fix the behavior.
We do have two different pieces of functionality:
- loading a plugin when desired
- adding a directory to 'runtimepath'
When talking about plugins, we expect a file plugin/foobar.vim that gets
loaded. Thus I do think that :loadplugin should do that.
Adding a directory to 'runtimepath', without loading a plugin, is
something else. Perhaps there is a plugin/foobar.vim, but it would only
be loaded if 'runtimepath' is updated early in initialization, so that
the plugin is found in step 4, see ":help load-plugins".
It gets more complicated if a plugin that is loaded in step 4 decides it
needs another plugin. Changing 'runtimepath' is not sufficient then,
the plugin must actually be loaded, it won't happen later. That is what
we need :loadplugin for.
Also, if there are several matching directories in 'packpath', and only
one actually has the plugin, that one must be used. Not one that is
found earlier but perhaps only has a syntax file.
We could add a command to add a directory under "pack" to
'runtimepath'. I believe that is the most straightforward way to allow
a user to do what he wants. We just need a good name.
":addtopath" perhaps? ":packadd"?
--
There are only two hard things in programming: Cache invalidation,
naming things and off-by-one errors.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/d/optout.
Friday, February 26, 2016
Re: big with windows codepage 65001 (UTF-8)
Hi Ben,
2016/2/27 Sat 9:05:32 UTC+9 Ben Fritz wrote:
> On Friday, February 26, 2016 at 4:29:32 PM UTC-6, Ken Takata wrote:
> > However recent vim.exe doesn't use 'termencoding'.
> >
>
> Woah, when did that happen?
It's 7.4.852.
Now vim.exe uses Unicode API.
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/d/optout.
2016/2/27 Sat 9:05:32 UTC+9 Ben Fritz wrote:
> On Friday, February 26, 2016 at 4:29:32 PM UTC-6, Ken Takata wrote:
> > However recent vim.exe doesn't use 'termencoding'.
> >
>
> Woah, when did that happen?
It's 7.4.852.
Now vim.exe uses Unicode API.
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/d/optout.
Re: big with windows codepage 65001 (UTF-8)
On Friday, February 26, 2016 at 4:29:53 PM UTC+1, Ben Fritz wrote:
>
> Works fine, for me.
>
>
> What is your 'termencoding' setting after launching Vim in this way (if you can see that)? It should match (i.e. it should be cp65001).
Thanks. I've set encoding to utf8 in my vimrc and it is fine now.
--
--
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/d/optout.
>
> Works fine, for me.
>
>
> What is your 'termencoding' setting after launching Vim in this way (if you can see that)? It should match (i.e. it should be cp65001).
Thanks. I've set encoding to utf8 in my vimrc and it is fine now.
--
--
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/d/optout.
Re: Replace c cast to c++ style cast
Hi,
> There is a switch in g++ that warns about c style casts.
> I will try to fix those but there are plenty in the project where I
> am working.
>
> Can someone recommend a function that would allow to do this in vim?
In lh-cpp (*), I have 3 mappings that transform C casts into C++ casts -- and 6 more to cast an expression.
This has to be done manually: you'll have to know if you want a const_cast, a static_cast, or a reinterpret_cast. As Dominique said, it can't really be done automatically. May be, clang could automate many things, but it won't be able to know whether you want to downcast with a dynamic_cast or with a static_cast?
(*) https://github.com/LucHermitte/lh-cpp
HTH,
--
Luc Hermitte
--
--
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/d/optout.
> There is a switch in g++ that warns about c style casts.
> I will try to fix those but there are plenty in the project where I
> am working.
>
> Can someone recommend a function that would allow to do this in vim?
In lh-cpp (*), I have 3 mappings that transform C casts into C++ casts -- and 6 more to cast an expression.
This has to be done manually: you'll have to know if you want a const_cast, a static_cast, or a reinterpret_cast. As Dominique said, it can't really be done automatically. May be, clang could automate many things, but it won't be able to know whether you want to downcast with a dynamic_cast or with a static_cast?
(*) https://github.com/LucHermitte/lh-cpp
HTH,
--
Luc Hermitte
--
--
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/d/optout.
Re: Replace c cast to c++ style cast
skeept <skeept@gmail.com> wrote:
> There is a switch in g++ that warns about c style casts.
> I will try to fix those but there are plenty in the project where I am working.
>
> Can someone recommend a function that would allow to do this in vim?
>
> Or outside vim, can anyone recommend a tool that would be useful in doing this?
>
> Thank you!
Doing it automatically seems more harmful than useful.
Ideally you should change the code to avoid the cast if possible.
And if the cast is really needed, then you need to chose the
correct c++ cast: static_cast, const_cast, reinterpret_case or dynamic_cast.
It requires thoughts to select the proper cast and so it should not
be automated.
Regards
Dominique
--
--
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/d/optout.
> There is a switch in g++ that warns about c style casts.
> I will try to fix those but there are plenty in the project where I am working.
>
> Can someone recommend a function that would allow to do this in vim?
>
> Or outside vim, can anyone recommend a tool that would be useful in doing this?
>
> Thank you!
Doing it automatically seems more harmful than useful.
Ideally you should change the code to avoid the cast if possible.
And if the cast is really needed, then you need to chose the
correct c++ cast: static_cast, const_cast, reinterpret_case or dynamic_cast.
It requires thoughts to select the proper cast and so it should not
be automated.
Regards
Dominique
--
--
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/d/optout.
Re: big with windows codepage 65001 (UTF-8)
On Friday, February 26, 2016 at 4:29:32 PM UTC-6, Ken Takata wrote:
> However recent vim.exe doesn't use 'termencoding'.
>
Woah, when did that happen?
--
--
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/d/optout.
> However recent vim.exe doesn't use 'termencoding'.
>
Woah, when did that happen?
--
--
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/d/optout.
Re: Search for line containing stringB, not preceded by a line containing stringA
On Friday, February 26, 2016 at 4:58:01 PM UTC-5, Ben Fritz wrote:
> On Friday, February 26, 2016 at 3:25:33 PM UTC-6, Paul wrote:
>> On Friday, February 26, 2016 at 12:26:21 PM UTC-5, Ben Fritz wrote:
>>> On Friday, February 26, 2016 at 9:50:50 AM UTC-6, Paul wrote:
>>>>>>
>>>>>> \(stringA.*\n\)\@<!.*stringB
>>>>>> \(stringA.*\n\)\@<!\(.*stringB\)
>>>>>>
>>>>>
>>>>> Move the newline outside of your negative look-behind, then
>>>>> start the match using \zs after the newline if you only want to
>>>>> match the 2nd line.
>>>>>
>>>>> Make it work on the 1st line as well by temporarily inserting a
>>>>> blank line at the top, or checking it manually, if needed.
>>>>>
>>>>> Here's what I mean, if my description isn't clear:
>>>>> \(stringA.*\)\@<!\n\zs.*stringB
>>>>
>>
>> Your expression works as you said. Thanks.
>>
>> I am a bit confused as to *why* it works. If my guess as to why my
>> original expressions failed is correct, it should apply to your
>> expression as well.
>
> Yours is: \(stringA.*\n\)\@<!.*stringB
>
> Translated: match any text followed by "stringB", as long as there
> is not "stringA" and some text followed by a newline, immediately
> before.
>
> As you figured out, this matches where you don't want it to, because
> there are multiple locations in the stringB line where you don't
> have a newline immediately before, so "stringA...followed by a
> newline" will not match.
>
> Now look at the subtle difference in mine:
> \(stringA.*\)\@<!\n\zs.*stringB
>
> I.e. match any text followed by stringB, if it has a line ending
> just before it, as long as there is not "stringA" and some text just
> before the newline.
>
> The key is that I'm forcing the newline to match. Thus your
> .*stringB is forced to match starting at the beginning of the line,
> so you can't just move forward into the line to find a place where
> \n doesn't match as with your pattern.
Actually, your explanation cleared up a misunderstanding that I had.
In my expression, I pictured .* as a spring that was trying to expand
and maximize its length, as long as it was anchored on stringA on the
left end, and by \n on the right end. In fact it doesn't have to be;
it can match text on the stringB line; or, more accurately, text on
the stringB line can fulfill the requirement of not matching, which is
not the intent of the expression. Your expression prevents this
unwanted effect. Thanks for that! There's a reason that regexps have
thrived despite their zany incarnations and hard-to-visualize effects.
--
--
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/d/optout.
> On Friday, February 26, 2016 at 3:25:33 PM UTC-6, Paul wrote:
>> On Friday, February 26, 2016 at 12:26:21 PM UTC-5, Ben Fritz wrote:
>>> On Friday, February 26, 2016 at 9:50:50 AM UTC-6, Paul wrote:
>>>>>>
>>>>>> \(stringA.*\n\)\@<!.*stringB
>>>>>> \(stringA.*\n\)\@<!\(.*stringB\)
>>>>>>
>>>>>
>>>>> Move the newline outside of your negative look-behind, then
>>>>> start the match using \zs after the newline if you only want to
>>>>> match the 2nd line.
>>>>>
>>>>> Make it work on the 1st line as well by temporarily inserting a
>>>>> blank line at the top, or checking it manually, if needed.
>>>>>
>>>>> Here's what I mean, if my description isn't clear:
>>>>> \(stringA.*\)\@<!\n\zs.*stringB
>>>>
>>
>> Your expression works as you said. Thanks.
>>
>> I am a bit confused as to *why* it works. If my guess as to why my
>> original expressions failed is correct, it should apply to your
>> expression as well.
>
> Yours is: \(stringA.*\n\)\@<!.*stringB
>
> Translated: match any text followed by "stringB", as long as there
> is not "stringA" and some text followed by a newline, immediately
> before.
>
> As you figured out, this matches where you don't want it to, because
> there are multiple locations in the stringB line where you don't
> have a newline immediately before, so "stringA...followed by a
> newline" will not match.
>
> Now look at the subtle difference in mine:
> \(stringA.*\)\@<!\n\zs.*stringB
>
> I.e. match any text followed by stringB, if it has a line ending
> just before it, as long as there is not "stringA" and some text just
> before the newline.
>
> The key is that I'm forcing the newline to match. Thus your
> .*stringB is forced to match starting at the beginning of the line,
> so you can't just move forward into the line to find a place where
> \n doesn't match as with your pattern.
Actually, your explanation cleared up a misunderstanding that I had.
In my expression, I pictured .* as a spring that was trying to expand
and maximize its length, as long as it was anchored on stringA on the
left end, and by \n on the right end. In fact it doesn't have to be;
it can match text on the stringB line; or, more accurately, text on
the stringB line can fulfill the requirement of not matching, which is
not the intent of the expression. Your expression prevents this
unwanted effect. Thanks for that! There's a reason that regexps have
thrived despite their zany incarnations and hard-to-visualize effects.
--
--
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/d/optout.
Re: gvim acts differently when invoked from mingw64 and ms-windows
Hi,
2016/2/26 Fri 17:16:41 UTC+9 Alexas Chee wrote:
> I just built gvim (+tcl) with patch 1421 on mingw64.
> I changed file syntax/vim.vim to highlight tcl embeded in vim script (line 621):
> let g:vimsyn_embed= "lmpPrt"
>
> When invoked directly from ms-windows, it acts just as expected;
> but when invoked from mingw bash, it fails to highlight tcl as if vim.vim was unchanged.
>
> So I did :syntax in both case and diffed the outputs. All differences are related to tcl.
Some environment variables might be different.
How about $HOME? Does the same .vimrc loaded?
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/d/optout.
2016/2/26 Fri 17:16:41 UTC+9 Alexas Chee wrote:
> I just built gvim (+tcl) with patch 1421 on mingw64.
> I changed file syntax/vim.vim to highlight tcl embeded in vim script (line 621):
> let g:vimsyn_embed= "lmpPrt"
>
> When invoked directly from ms-windows, it acts just as expected;
> but when invoked from mingw bash, it fails to highlight tcl as if vim.vim was unchanged.
>
> So I did :syntax in both case and diffed the outputs. All differences are related to tcl.
Some environment variables might be different.
How about $HOME? Does the same .vimrc loaded?
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/d/optout.
Re: big with windows codepage 65001 (UTF-8)
Hi,
2016/2/26 Fri 20:45:38 UTC+9 klo uo wrote:
> Hi,
>
>
> on Windows I've set my default code page to 65001 (UTF-8)
>
>
> This is how vim looks like:
>
>
>
>
>
> If I change code page to some other, like `chcp 866` if works as expected.
Your vim.exe seems old.
Try gvim74-1024.exe from http://www.vim.org/download.php#pc .
Old vim.exe needs to be set 'termencoding' properly when you change the codepage
(or 'encoding'). However recent vim.exe doesn't use 'termencoding'.
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/d/optout.
2016/2/26 Fri 20:45:38 UTC+9 klo uo wrote:
> Hi,
>
>
> on Windows I've set my default code page to 65001 (UTF-8)
>
>
> This is how vim looks like:
>
>
>
>
>
> If I change code page to some other, like `chcp 866` if works as expected.
Your vim.exe seems old.
Try gvim74-1024.exe from http://www.vim.org/download.php#pc .
Old vim.exe needs to be set 'termencoding' properly when you change the codepage
(or 'encoding'). However recent vim.exe doesn't use 'termencoding'.
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/d/optout.
Re: Search for line containing stringB, not preceded by a line containing stringA
On Friday, February 26, 2016 at 3:25:33 PM UTC-6, Paul wrote:
> On Friday, February 26, 2016 at 12:26:21 PM UTC-5, Ben Fritz wrote:
> > On Friday, February 26, 2016 at 9:50:50 AM UTC-6, Paul wrote:
> >>>>
> >>>> \(stringA.*\n\)\@<!.*stringB
> >>>> \(stringA.*\n\)\@<!\(.*stringB\)
> >>>>
> >>>
> >>> Move the newline outside of your negative look-behind, then start
> >>> the match using \zs after the newline if you only want to match
> >>> the 2nd line.
> >>>
> >>> Make it work on the 1st line as well by temporarily inserting a
> >>> blank line at the top, or checking it manually, if needed.
> >>>
> >>> Here's what I mean, if my description isn't clear:
> >>> \(stringA.*\)\@<!\n\zs.*stringB
> >>
>
> Your expression works as you said. Thanks.
>
> I am a bit confused as to *why* it works. If my guess as to why my
> original expressions failed is correct, it should apply to your
> expression as well.
Yours is:
\(stringA.*\n\)\@<!.*stringB
Translated: match any text followed by "stringB", as long as there is not "stringA" and some text followed by a newline, immediately before.
As you figured out, this matches where you don't want it to, because there are multiple locations in the stringB line where you don't have a newline immediately before, so "stringA...followed by a newline" will not match.
Now look at the subtle difference in mine: \(stringA.*\)\@<!\n\zs.*stringB
I.e. match any text followed by stringB, if it has a line ending just before it, as long as there is not "stringA" and some text just before the newline.
The key is that I'm forcing the newline to match. Thus your .*stringB is forced to match starting at the beginning of the line, so you can't just move forward into the line to find a place where \n doesn't match as with your pattern.
--
--
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/d/optout.
> On Friday, February 26, 2016 at 12:26:21 PM UTC-5, Ben Fritz wrote:
> > On Friday, February 26, 2016 at 9:50:50 AM UTC-6, Paul wrote:
> >>>>
> >>>> \(stringA.*\n\)\@<!.*stringB
> >>>> \(stringA.*\n\)\@<!\(.*stringB\)
> >>>>
> >>>
> >>> Move the newline outside of your negative look-behind, then start
> >>> the match using \zs after the newline if you only want to match
> >>> the 2nd line.
> >>>
> >>> Make it work on the 1st line as well by temporarily inserting a
> >>> blank line at the top, or checking it manually, if needed.
> >>>
> >>> Here's what I mean, if my description isn't clear:
> >>> \(stringA.*\)\@<!\n\zs.*stringB
> >>
>
> Your expression works as you said. Thanks.
>
> I am a bit confused as to *why* it works. If my guess as to why my
> original expressions failed is correct, it should apply to your
> expression as well.
Yours is:
\(stringA.*\n\)\@<!.*stringB
Translated: match any text followed by "stringB", as long as there is not "stringA" and some text followed by a newline, immediately before.
As you figured out, this matches where you don't want it to, because there are multiple locations in the stringB line where you don't have a newline immediately before, so "stringA...followed by a newline" will not match.
Now look at the subtle difference in mine: \(stringA.*\)\@<!\n\zs.*stringB
I.e. match any text followed by stringB, if it has a line ending just before it, as long as there is not "stringA" and some text just before the newline.
The key is that I'm forcing the newline to match. Thus your .*stringB is forced to match starting at the beginning of the line, so you can't just move forward into the line to find a place where \n doesn't match as with your pattern.
--
--
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/d/optout.
Re: Search for line containing stringB, not preceded by a line containing stringA
On Friday, February 26, 2016 at 12:26:21 PM UTC-5, Ben Fritz wrote:
> On Friday, February 26, 2016 at 9:50:50 AM UTC-6, Paul wrote:
>> On Wednesday, February 24, 2016 at 3:01:24 PM UTC-5, Ben Fritz
>> wrote:
>>> On Wednesday, February 24, 2016 at 12:00:22 PM UTC-6, Paul wrote:
>>>> I have a text file and I would like to compose a regular
>>>> expression that matches lines containing stringB but not preceded
>>>> by a line containing string A. I thought one of these might do
>>>> it:
>>>>
>>>> \(stringA.*\n\)\@<!.*stringB
>>>> \(stringA.*\n\)\@<!\(.*stringB\)
>>>>
>>>> The \@<! was *intended* to ensure a non-match with stringA in the
>>>> preceding line. However, they highlight the same lines that are
>>>> highlighted by the opposite regular expressions:
>>>>
>>>> \(stringA.*\n\)\@<=.*stringB
>>>> \(stringA.*\n\)\@<=\(.*stringB\)
>>>>
>>>> With a little pondering, it is obvious why. The first .* matches
>>>> any set of characters, so even if stringA exists in the preceding
>>>> line, you can always find some portion of the line that doesn't
>>>> match \(stringA.*\n\).
>>>>
>>>> Is there a way to achieve the search described in above?
>>>
>>> Move the newline outside of your negative look-behind, then start
>>> the match using \zs after the newline if you only want to match
>>> the 2nd line.
>>>
>>> Make it work on the 1st line as well by temporarily inserting a
>>> blank line at the top, or checking it manually, if needed.
>>>
>>> Here's what I mean, if my description isn't clear:
>>> \(stringA.*\)\@<!\n\zs.*stringB
>>
>> Thanks, Ben. The problem isn't whether the 1st and/or the 2nd of
>> the two lines are matched. It's whether I can even locate lines
>> containing stringB *only* when the preceding line does not contain
>> stringA. Currently, all expressions locate cases of stringB
>> regardless of whether the preceding contains stringA. The text
>> file I use is:
>>
>> asldkfjals stringA asldkjf
>> asldkfjals stringB asldkjf
>>
>> asldkfjals stringX asldkjf
>> asldkfjals stringB asldkjf
>>
>> asldkfjals stringA asldkjf
>> asldkfjals stringB asldkjf
>>
>> asldkfjals stringX asldkjf
>> asldkfjals stringB asldkjf
>
> Did you try the pattern I sent? Works for me on your test data. The
> key was to move the \n out of the lookbehind to make sure you're
> matching line boundaries.
>
> The part about whether the 1st or 2nd line matches was just the \zs
> to exclude the newline from the matched text itself while forcing it
> to be present just before the match.
Actually, I thought I did, but it was in the middle of the night in my
neck of the woods, when the fire alarm system malfunctioned. I was in
zombie mode, and likely just copy & pasted my own regular expressions
instead. Your expression works as you said. Thanks.
I am a bit confused as to *why* it works. If my guess as to why my
original expressions failed is correct, it should apply to your
expression as well.
--
--
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/d/optout.
> On Friday, February 26, 2016 at 9:50:50 AM UTC-6, Paul wrote:
>> On Wednesday, February 24, 2016 at 3:01:24 PM UTC-5, Ben Fritz
>> wrote:
>>> On Wednesday, February 24, 2016 at 12:00:22 PM UTC-6, Paul wrote:
>>>> I have a text file and I would like to compose a regular
>>>> expression that matches lines containing stringB but not preceded
>>>> by a line containing string A. I thought one of these might do
>>>> it:
>>>>
>>>> \(stringA.*\n\)\@<!.*stringB
>>>> \(stringA.*\n\)\@<!\(.*stringB\)
>>>>
>>>> The \@<! was *intended* to ensure a non-match with stringA in the
>>>> preceding line. However, they highlight the same lines that are
>>>> highlighted by the opposite regular expressions:
>>>>
>>>> \(stringA.*\n\)\@<=.*stringB
>>>> \(stringA.*\n\)\@<=\(.*stringB\)
>>>>
>>>> With a little pondering, it is obvious why. The first .* matches
>>>> any set of characters, so even if stringA exists in the preceding
>>>> line, you can always find some portion of the line that doesn't
>>>> match \(stringA.*\n\).
>>>>
>>>> Is there a way to achieve the search described in above?
>>>
>>> Move the newline outside of your negative look-behind, then start
>>> the match using \zs after the newline if you only want to match
>>> the 2nd line.
>>>
>>> Make it work on the 1st line as well by temporarily inserting a
>>> blank line at the top, or checking it manually, if needed.
>>>
>>> Here's what I mean, if my description isn't clear:
>>> \(stringA.*\)\@<!\n\zs.*stringB
>>
>> Thanks, Ben. The problem isn't whether the 1st and/or the 2nd of
>> the two lines are matched. It's whether I can even locate lines
>> containing stringB *only* when the preceding line does not contain
>> stringA. Currently, all expressions locate cases of stringB
>> regardless of whether the preceding contains stringA. The text
>> file I use is:
>>
>> asldkfjals stringA asldkjf
>> asldkfjals stringB asldkjf
>>
>> asldkfjals stringX asldkjf
>> asldkfjals stringB asldkjf
>>
>> asldkfjals stringA asldkjf
>> asldkfjals stringB asldkjf
>>
>> asldkfjals stringX asldkjf
>> asldkfjals stringB asldkjf
>
> Did you try the pattern I sent? Works for me on your test data. The
> key was to move the \n out of the lookbehind to make sure you're
> matching line boundaries.
>
> The part about whether the 1st or 2nd line matches was just the \zs
> to exclude the newline from the matched text itself while forcing it
> to be present just before the match.
Actually, I thought I did, but it was in the middle of the night in my
neck of the woods, when the fire alarm system malfunctioned. I was in
zombie mode, and likely just copy & pasted my own regular expressions
instead. Your expression works as you said. Thanks.
I am a bit confused as to *why* it works. If my guess as to why my
original expressions failed is correct, it should apply to your
expression as well.
--
--
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/d/optout.
Replace c cast to c++ style cast
There is a switch in g++ that warns about c style casts.
I will try to fix those but there are plenty in the project where I am working.
Can someone recommend a function that would allow to do this in vim?
Or outside vim, can anyone recommend a tool that would be useful in doing this?
Thank you!
--
--
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/d/optout.
I will try to fix those but there are plenty in the project where I am working.
Can someone recommend a function that would allow to do this in vim?
Or outside vim, can anyone recommend a tool that would be useful in doing this?
Thank you!
--
--
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/d/optout.
Re: Packages
On Friday, February 26, 2016 at 12:02:42 PM UTC-6, Bram Moolenaar wrote:
> Christian Brabandt wrote:
> >
> > Really a plugin directory is necessary? That sounds awkward. What about
> > colorschemes, indent or ftplugins and syntax scripts?
> >
> > We could still change it, right?
> >
> > > It would be possible to make another command than :loadplugin to find
> > > any directory with the specified name under 'packpath', but I don't see
> > > a good reason. Perhaps adding a remark to the documentation is
> > > sufficient?
> >
> > I'd rather prefer it to be fixed instead of adding yet another command
> > or option.
>
> Hmm, so we throw out ":loadplugin" and add ":loadpackitem"?
> It would then find directories matching "pack/*/opt/{name}"
>
I agree this needs fixing. I did not realize only things with a "plugin" folder would be loaded, that makes the current implementation next to worthless as a replacement for things like Pathogen.
The naming of the plugin was discussed in the first link from the OP: https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
I think ":loadpackitem" would be a very awkward name, please don't use that. ":loadplugin" is sufficient and matches user expectations even if it isn't pedantically correct. ":loadaddon" might be a little better although we don't use the term "addon" anywhere else that I know of.
TL;DR: just stick with the current name but fix the behavior.
--
--
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/d/optout.
> Christian Brabandt wrote:
> >
> > Really a plugin directory is necessary? That sounds awkward. What about
> > colorschemes, indent or ftplugins and syntax scripts?
> >
> > We could still change it, right?
> >
> > > It would be possible to make another command than :loadplugin to find
> > > any directory with the specified name under 'packpath', but I don't see
> > > a good reason. Perhaps adding a remark to the documentation is
> > > sufficient?
> >
> > I'd rather prefer it to be fixed instead of adding yet another command
> > or option.
>
> Hmm, so we throw out ":loadplugin" and add ":loadpackitem"?
> It would then find directories matching "pack/*/opt/{name}"
>
I agree this needs fixing. I did not realize only things with a "plugin" folder would be loaded, that makes the current implementation next to worthless as a replacement for things like Pathogen.
The naming of the plugin was discussed in the first link from the OP: https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
I think ":loadpackitem" would be a very awkward name, please don't use that. ":loadplugin" is sufficient and matches user expectations even if it isn't pedantically correct. ":loadaddon" might be a little better although we don't use the term "addon" anywhere else that I know of.
TL;DR: just stick with the current name but fix the behavior.
--
--
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/d/optout.
Re: Packages
Christian Brabandt wrote:
> On Fr, 26 Feb 2016, Bram Moolenaar wrote:
>
> >
> > Matthew Desjardins wrote:
> >
> > > There have been a couple of people posting about how the new package
> > > feature can, in its current state, replace Pathogen.
> > >
> > > https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
> > > https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
> > >
> > > Could someone explain how? It doesn't seem to work for plugins that
> > > don't have a "plugin" directory, and as far as I can tell from the
> > > source it's not supposed to, either.
> > >
> > > Why was this decision made to only support plugins with a "plugin"
> > > directory?
> >
> > It's very easy to add an empty plugin/foo.vim file. If you really need
> > to, I would expect nearly every plugin to at least do something, such as
> > defining a user command or mapping. Maybe it's empty if you only want to
> > make a syntax file available.
>
> Really a plugin directory is necessary? That sounds awkward. What about
> colorschemes, indent or ftplugins and syntax scripts?
>
> We could still change it, right?
>
> > It would be possible to make another command than :loadplugin to find
> > any directory with the specified name under 'packpath', but I don't see
> > a good reason. Perhaps adding a remark to the documentation is
> > sufficient?
>
> I'd rather prefer it to be fixed instead of adding yet another command
> or option.
Hmm, so we throw out ":loadplugin" and add ":loadpackitem"?
It would then find directories matching "pack/*/opt/{name}"
--
If an elephant is left tied to a parking meter, the parking fee has to be paid
just as it would for a vehicle.
[real standing law in Florida, United States of America]
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/d/optout.
> On Fr, 26 Feb 2016, Bram Moolenaar wrote:
>
> >
> > Matthew Desjardins wrote:
> >
> > > There have been a couple of people posting about how the new package
> > > feature can, in its current state, replace Pathogen.
> > >
> > > https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
> > > https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
> > >
> > > Could someone explain how? It doesn't seem to work for plugins that
> > > don't have a "plugin" directory, and as far as I can tell from the
> > > source it's not supposed to, either.
> > >
> > > Why was this decision made to only support plugins with a "plugin"
> > > directory?
> >
> > It's very easy to add an empty plugin/foo.vim file. If you really need
> > to, I would expect nearly every plugin to at least do something, such as
> > defining a user command or mapping. Maybe it's empty if you only want to
> > make a syntax file available.
>
> Really a plugin directory is necessary? That sounds awkward. What about
> colorschemes, indent or ftplugins and syntax scripts?
>
> We could still change it, right?
>
> > It would be possible to make another command than :loadplugin to find
> > any directory with the specified name under 'packpath', but I don't see
> > a good reason. Perhaps adding a remark to the documentation is
> > sufficient?
>
> I'd rather prefer it to be fixed instead of adding yet another command
> or option.
Hmm, so we throw out ":loadplugin" and add ":loadpackitem"?
It would then find directories matching "pack/*/opt/{name}"
--
If an elephant is left tied to a parking meter, the parking fee has to be paid
just as it would for a vehicle.
[real standing law in Florida, United States of America]
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/d/optout.
Re: Packages
On Fr, 26 Feb 2016, Bram Moolenaar wrote:
>
> Matthew Desjardins wrote:
>
> > There have been a couple of people posting about how the new package
> > feature can, in its current state, replace Pathogen.
> >
> > https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
> > https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
> >
> > Could someone explain how? It doesn't seem to work for plugins that
> > don't have a "plugin" directory, and as far as I can tell from the
> > source it's not supposed to, either.
> >
> > Why was this decision made to only support plugins with a "plugin"
> > directory?
>
> It's very easy to add an empty plugin/foo.vim file. If you really need
> to, I would expect nearly every plugin to at least do something, such as
> defining a user command or mapping. Maybe it's empty if you only want to
> make a syntax file available.
Really a plugin directory is necessary? That sounds awkward. What about
colorschemes, indent or ftplugins and syntax scripts?
We could still change it, right?
> It would be possible to make another command than :loadplugin to find
> any directory with the specified name under 'packpath', but I don't see
> a good reason. Perhaps adding a remark to the documentation is
> sufficient?
I'd rather prefer it to be fixed instead of adding yet another command
or option.
Best,
Christian
--
Aus einer Menge von unordentlichen Strichen bildet man sich leicht
eine Gegend, aber aus unordentlichen Tönen keine Musik.
-- Georg Christoph Lichtenberg
--
--
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/d/optout.
>
> Matthew Desjardins wrote:
>
> > There have been a couple of people posting about how the new package
> > feature can, in its current state, replace Pathogen.
> >
> > https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
> > https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
> >
> > Could someone explain how? It doesn't seem to work for plugins that
> > don't have a "plugin" directory, and as far as I can tell from the
> > source it's not supposed to, either.
> >
> > Why was this decision made to only support plugins with a "plugin"
> > directory?
>
> It's very easy to add an empty plugin/foo.vim file. If you really need
> to, I would expect nearly every plugin to at least do something, such as
> defining a user command or mapping. Maybe it's empty if you only want to
> make a syntax file available.
Really a plugin directory is necessary? That sounds awkward. What about
colorschemes, indent or ftplugins and syntax scripts?
We could still change it, right?
> It would be possible to make another command than :loadplugin to find
> any directory with the specified name under 'packpath', but I don't see
> a good reason. Perhaps adding a remark to the documentation is
> sufficient?
I'd rather prefer it to be fixed instead of adding yet another command
or option.
Best,
Christian
--
Aus einer Menge von unordentlichen Strichen bildet man sich leicht
eine Gegend, aber aus unordentlichen Tönen keine Musik.
-- Georg Christoph Lichtenberg
--
--
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/d/optout.
Re: Search for line containing stringB, not preceded by a line containing stringA
On Friday, February 26, 2016 at 9:50:50 AM UTC-6, Paul wrote:
> On Wednesday, February 24, 2016 at 3:01:24 PM UTC-5, Ben Fritz wrote:
> > On Wednesday, February 24, 2016 at 12:00:22 PM UTC-6, Paul wrote:
> > > I have a text file and I would like to compose a regular expression
> > > that matches lines containing stringB but not preceded by a line
> > > containing string A. I thought one of these might do it:
> > >
> > > \(stringA.*\n\)\@<!.*stringB
> > > \(stringA.*\n\)\@<!\(.*stringB\)
> > >
> > > The \@<! was *intended* to ensure a non-match with stringA in the
> > > preceding line. However, they highlight the same lines that are
> > > highlighted by the opposite regular expressions:
> > >
> > > \(stringA.*\n\)\@<=.*stringB
> > > \(stringA.*\n\)\@<=\(.*stringB\)
> > >
> > > With a little pondering, it is obvious why. The first .* matches any
> > > set of characters, so even if stringA exists in the preceding line,
> > > you can always find some portion of the line that doesn't match
> > > \(stringA.*\n\).
> > >
> > > Is there a way to achieve the search described in above?
> >
> > Move the newline outside of your negative look-behind, then start the match using \zs after the newline if you only want to match the 2nd line.
> >
> > Make it work on the 1st line as well by temporarily inserting a blank line at the top, or checking it manually, if needed.
> >
> > Here's what I mean, if my description isn't clear: \(stringA.*\)\@<!\n\zs.*stringB
>
> Thanks, Ben. The problem isn't whether the 1st and/or the 2nd of the two lines are matched. It's whether I can even locate lines containing stringB *only* when the preceding line does not contain stringA. Currently, all expressions locate cases of stringB regardless of whether the preceding contains stringA. The text file I use is:
>
> asldkfjals stringA asldkjf
> asldkfjals stringB asldkjf
>
> asldkfjals stringX asldkjf
> asldkfjals stringB asldkjf
>
> asldkfjals stringA asldkjf
> asldkfjals stringB asldkjf
>
> asldkfjals stringX asldkjf
> asldkfjals stringB asldkjf
Did you try the pattern I sent? Works for me on your test data. The key was to move the \n out of the lookbehind to make sure you're matching line boundaries.
The part about whether the 1st or 2nd line matches was just the \zs to exclude the newline from the matched text itself while forcing it to be present just before the match.
--
--
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/d/optout.
> On Wednesday, February 24, 2016 at 3:01:24 PM UTC-5, Ben Fritz wrote:
> > On Wednesday, February 24, 2016 at 12:00:22 PM UTC-6, Paul wrote:
> > > I have a text file and I would like to compose a regular expression
> > > that matches lines containing stringB but not preceded by a line
> > > containing string A. I thought one of these might do it:
> > >
> > > \(stringA.*\n\)\@<!.*stringB
> > > \(stringA.*\n\)\@<!\(.*stringB\)
> > >
> > > The \@<! was *intended* to ensure a non-match with stringA in the
> > > preceding line. However, they highlight the same lines that are
> > > highlighted by the opposite regular expressions:
> > >
> > > \(stringA.*\n\)\@<=.*stringB
> > > \(stringA.*\n\)\@<=\(.*stringB\)
> > >
> > > With a little pondering, it is obvious why. The first .* matches any
> > > set of characters, so even if stringA exists in the preceding line,
> > > you can always find some portion of the line that doesn't match
> > > \(stringA.*\n\).
> > >
> > > Is there a way to achieve the search described in above?
> >
> > Move the newline outside of your negative look-behind, then start the match using \zs after the newline if you only want to match the 2nd line.
> >
> > Make it work on the 1st line as well by temporarily inserting a blank line at the top, or checking it manually, if needed.
> >
> > Here's what I mean, if my description isn't clear: \(stringA.*\)\@<!\n\zs.*stringB
>
> Thanks, Ben. The problem isn't whether the 1st and/or the 2nd of the two lines are matched. It's whether I can even locate lines containing stringB *only* when the preceding line does not contain stringA. Currently, all expressions locate cases of stringB regardless of whether the preceding contains stringA. The text file I use is:
>
> asldkfjals stringA asldkjf
> asldkfjals stringB asldkjf
>
> asldkfjals stringX asldkjf
> asldkfjals stringB asldkjf
>
> asldkfjals stringA asldkjf
> asldkfjals stringB asldkjf
>
> asldkfjals stringX asldkjf
> asldkfjals stringB asldkjf
Did you try the pattern I sent? Works for me on your test data. The key was to move the \n out of the lookbehind to make sure you're matching line boundaries.
The part about whether the 1st or 2nd line matches was just the \zs to exclude the newline from the matched text itself while forcing it to be present just before the match.
--
--
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/d/optout.
Re: Packages
Matthew Desjardins wrote:
> There have been a couple of people posting about how the new package
> feature can, in its current state, replace Pathogen.
>
> https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
> https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
>
> Could someone explain how? It doesn't seem to work for plugins that
> don't have a "plugin" directory, and as far as I can tell from the
> source it's not supposed to, either.
>
> Why was this decision made to only support plugins with a "plugin"
> directory?
It's very easy to add an empty plugin/foo.vim file. If you really need
to, I would expect nearly every plugin to at least do something, such as
defining a user command or mapping. Maybe it's empty if you only want to
make a syntax file available.
It would be possible to make another command than :loadplugin to find
any directory with the specified name under 'packpath', but I don't see
a good reason. Perhaps adding a remark to the documentation is
sufficient?
--
A special law prohibits unmarried women from parachuting on Sunday or she
shall risk arrest, fine, and/or jailing.
[real standing law in Florida, United States of America]
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/d/optout.
> There have been a couple of people posting about how the new package
> feature can, in its current state, replace Pathogen.
>
> https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
> https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
>
> Could someone explain how? It doesn't seem to work for plugins that
> don't have a "plugin" directory, and as far as I can tell from the
> source it's not supposed to, either.
>
> Why was this decision made to only support plugins with a "plugin"
> directory?
It's very easy to add an empty plugin/foo.vim file. If you really need
to, I would expect nearly every plugin to at least do something, such as
defining a user command or mapping. Maybe it's empty if you only want to
make a syntax file available.
It would be possible to make another command than :loadplugin to find
any directory with the specified name under 'packpath', but I don't see
a good reason. Perhaps adding a remark to the documentation is
sufficient?
--
A special law prohibits unmarried women from parachuting on Sunday or she
shall risk arrest, fine, and/or jailing.
[real standing law in Florida, United States of America]
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/d/optout.
Re: how to transfer output of ':.w !sh' back to current buffer
> On Friday, February 26, 2016 at 11:29:48 AM UTC-5, Roman wrote:
> > I use ':.w !sh' to run some lines with shell commands
> > Is any way to transfer output of this commands back to buffer or maybe to split buffer window or do something like ':r !sh $current_line'
>
> You could always just *replace* the content of the current buffer with the output with a filter, like "%!sh". But if you want the current buffer left as-is, then you could still use something like "w !sh > temp_thing" and then read that file.
Thank you Matthew, I think I just need to open temp_thing in :split and 'set autoread' in it.
--
--
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/d/optout.
> > I use ':.w !sh' to run some lines with shell commands
> > Is any way to transfer output of this commands back to buffer or maybe to split buffer window or do something like ':r !sh $current_line'
>
> You could always just *replace* the content of the current buffer with the output with a filter, like "%!sh". But if you want the current buffer left as-is, then you could still use something like "w !sh > temp_thing" and then read that file.
Thank you Matthew, I think I just need to open temp_thing in :split and 'set autoread' in it.
--
--
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/d/optout.
Re: gvim acts differently when invoked from mingw64 and ms-windows
Hi, Christian,
Thanks for your comment.
I compared 2 outputs of : scriptnames, turned out that the one in windows has two more lines:
$VIMRUNTIME\syntax\tcl.vim
$VIMRUNTIME\indent\vim.vim
All others are the same: same runtime path and other scripts.
Wonder why gvim refuses to load those 2 scripts when started in mingw.
Best.
--
--
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/d/optout.
Thanks for your comment.
I compared 2 outputs of : scriptnames, turned out that the one in windows has two more lines:
$VIMRUNTIME\syntax\tcl.vim
$VIMRUNTIME\indent\vim.vim
All others are the same: same runtime path and other scripts.
Wonder why gvim refuses to load those 2 scripts when started in mingw.
Best.
--
--
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/d/optout.
Re: how to transfer output of ':.w !sh' back to current buffer
On Friday, February 26, 2016 at 11:29:48 AM UTC-5, Roman wrote:
> I use ':.w !sh' to run some lines with shell commands
> Is any way to transfer output of this commands back to buffer or maybe to split buffer window or do something like ':r !sh $current_line'
You could always just *replace* the content of the current buffer with the output with a filter, like "%!sh". But if you want the current buffer left as-is, then you could still use something like "w !sh > temp_thing" and then read that file.
--
--
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/d/optout.
> I use ':.w !sh' to run some lines with shell commands
> Is any way to transfer output of this commands back to buffer or maybe to split buffer window or do something like ':r !sh $current_line'
You could always just *replace* the content of the current buffer with the output with a filter, like "%!sh". But if you want the current buffer left as-is, then you could still use something like "w !sh > temp_thing" and then read that file.
--
--
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/d/optout.
how to transfer output of ':.w !sh' back to current buffer
I use ':.w !sh' to run some lines with shell commands
Is any way to transfer output of this commands back to buffer or maybe to split buffer window or do something like ':r !sh $current_line'
--
--
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/d/optout.
Is any way to transfer output of this commands back to buffer or maybe to split buffer window or do something like ':r !sh $current_line'
--
--
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/d/optout.
Re: Search for line containing stringB, not preceded by a line containing stringA
On Wednesday, February 24, 2016 at 3:01:24 PM UTC-5, Ben Fritz wrote:
> On Wednesday, February 24, 2016 at 12:00:22 PM UTC-6, Paul wrote:
> > I have a text file and I would like to compose a regular expression
> > that matches lines containing stringB but not preceded by a line
> > containing string A. I thought one of these might do it:
> >
> > \(stringA.*\n\)\@<!.*stringB
> > \(stringA.*\n\)\@<!\(.*stringB\)
> >
> > The \@<! was *intended* to ensure a non-match with stringA in the
> > preceding line. However, they highlight the same lines that are
> > highlighted by the opposite regular expressions:
> >
> > \(stringA.*\n\)\@<=.*stringB
> > \(stringA.*\n\)\@<=\(.*stringB\)
> >
> > With a little pondering, it is obvious why. The first .* matches any
> > set of characters, so even if stringA exists in the preceding line,
> > you can always find some portion of the line that doesn't match
> > \(stringA.*\n\).
> >
> > Is there a way to achieve the search described in above?
>
> Move the newline outside of your negative look-behind, then start the match using \zs after the newline if you only want to match the 2nd line.
>
> Make it work on the 1st line as well by temporarily inserting a blank line at the top, or checking it manually, if needed.
>
> Here's what I mean, if my description isn't clear: \(stringA.*\)\@<!\n\zs.*stringB
Thanks, Ben. The problem isn't whether the 1st and/or the 2nd of the two lines are matched. It's whether I can even locate lines containing stringB *only* when the preceding line does not contain stringA. Currently, all expressions locate cases of stringB regardless of whether the preceding contains stringA. The text file I use is:
asldkfjals stringA asldkjf
asldkfjals stringB asldkjf
asldkfjals stringX asldkjf
asldkfjals stringB asldkjf
asldkfjals stringA asldkjf
asldkfjals stringB asldkjf
asldkfjals stringX asldkjf
asldkfjals stringB asldkjf
--
--
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/d/optout.
> On Wednesday, February 24, 2016 at 12:00:22 PM UTC-6, Paul wrote:
> > I have a text file and I would like to compose a regular expression
> > that matches lines containing stringB but not preceded by a line
> > containing string A. I thought one of these might do it:
> >
> > \(stringA.*\n\)\@<!.*stringB
> > \(stringA.*\n\)\@<!\(.*stringB\)
> >
> > The \@<! was *intended* to ensure a non-match with stringA in the
> > preceding line. However, they highlight the same lines that are
> > highlighted by the opposite regular expressions:
> >
> > \(stringA.*\n\)\@<=.*stringB
> > \(stringA.*\n\)\@<=\(.*stringB\)
> >
> > With a little pondering, it is obvious why. The first .* matches any
> > set of characters, so even if stringA exists in the preceding line,
> > you can always find some portion of the line that doesn't match
> > \(stringA.*\n\).
> >
> > Is there a way to achieve the search described in above?
>
> Move the newline outside of your negative look-behind, then start the match using \zs after the newline if you only want to match the 2nd line.
>
> Make it work on the 1st line as well by temporarily inserting a blank line at the top, or checking it manually, if needed.
>
> Here's what I mean, if my description isn't clear: \(stringA.*\)\@<!\n\zs.*stringB
Thanks, Ben. The problem isn't whether the 1st and/or the 2nd of the two lines are matched. It's whether I can even locate lines containing stringB *only* when the preceding line does not contain stringA. Currently, all expressions locate cases of stringB regardless of whether the preceding contains stringA. The text file I use is:
asldkfjals stringA asldkjf
asldkfjals stringB asldkjf
asldkfjals stringX asldkjf
asldkfjals stringB asldkjf
asldkfjals stringA asldkjf
asldkfjals stringB asldkjf
asldkfjals stringX asldkjf
asldkfjals stringB asldkjf
--
--
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/d/optout.
Re: big with windows codepage 65001 (UTF-8)
On Friday, February 26, 2016 at 5:45:38 AM UTC-6, klo uo wrote:
> Hi,
>
>
> on Windows I've set my default code page to 65001 (UTF-8)
>
>
> This is how vim looks like:
>
>
>
>
>
> If I change code page to some other, like `chcp 866` if works as expected.
>
>
Works fine, for me.
What is your 'termencoding' setting after launching Vim in this way (if you can see that)? It should match (i.e. it should be cp65001).
--
--
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/d/optout.
> Hi,
>
>
> on Windows I've set my default code page to 65001 (UTF-8)
>
>
> This is how vim looks like:
>
>
>
>
>
> If I change code page to some other, like `chcp 866` if works as expected.
>
>
Works fine, for me.
What is your 'termencoding' setting after launching Vim in this way (if you can see that)? It should match (i.e. it should be cp65001).
--
--
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/d/optout.
Re: How to write autocmd command to set local variable to some value when new buffer is created?
On Friday, February 26, 2016 at 1:19:35 AM UTC-6, Igor Forca wrote:
> The only work-around I have found now is to replace "BufNew" with "BufEnter" in autocmd command inside $MYVIMRC file, restarted gVim and then it works fine.
> It is still mistery to me why BufNew does not have effect in my case and BufEnter has. Any idea how to debug?
>
Yes. You've already pretty much ruled out your .vimrc, so next check if the problem is in your plugins by starting Vim with:
gvim -N -u NONE -i NONE
(technically this turns off both your plugins and your .vimrc, plus it sets nocompatible mode)
Then, enter your autocmds, and the one plugin you may need. I assume your problem will go away. The usual advice after that would be to enable half your plugins and do a "binary search" for the offending plugin.
But if you don't have very many, it may be faster do debug directly. Instead of :enew do :debug enew
Then enter 's' (step) and/or 'n' (next) until you see where the heck your commenstring gets overwritten. Then go zap that line.
--
--
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/d/optout.
> The only work-around I have found now is to replace "BufNew" with "BufEnter" in autocmd command inside $MYVIMRC file, restarted gVim and then it works fine.
> It is still mistery to me why BufNew does not have effect in my case and BufEnter has. Any idea how to debug?
>
Yes. You've already pretty much ruled out your .vimrc, so next check if the problem is in your plugins by starting Vim with:
gvim -N -u NONE -i NONE
(technically this turns off both your plugins and your .vimrc, plus it sets nocompatible mode)
Then, enter your autocmds, and the one plugin you may need. I assume your problem will go away. The usual advice after that would be to enable half your plugins and do a "binary search" for the offending plugin.
But if you don't have very many, it may be faster do debug directly. Instead of :enew do :debug enew
Then enter 's' (step) and/or 'n' (next) until you see where the heck your commenstring gets overwritten. Then go zap that line.
--
--
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/d/optout.
Re: Referring to a buffer, and :help help
On Friday, February 26, 2016 at 9:53:42 AM UTC-5, Jan wrote:
> On Friday, 26 February, 2016 at 14:51:00 GMT, Matthew Desjardins wrote:
> >There is also ":sbuffer" which will take a buffer number or partial buffer name.
>
> Ah, thanks. I actually just realised that #2 does with with :split! But I'd still like to know what to search for for help on those arguments.
Try ":h {file}"
--
--
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/d/optout.
> On Friday, 26 February, 2016 at 14:51:00 GMT, Matthew Desjardins wrote:
> >There is also ":sbuffer" which will take a buffer number or partial buffer name.
>
> Ah, thanks. I actually just realised that #2 does with with :split! But I'd still like to know what to search for for help on those arguments.
Try ":h {file}"
--
--
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/d/optout.
Re: Referring to a buffer, and :help help
On Friday, 26 February, 2016 at 14:51:00 GMT, Matthew Desjardins wrote:
>There is also ":sbuffer" which will take a buffer number or partial buffer name.
Ah, thanks. I actually just realised that #2 does with with :split! But I'd still like to know what to search for for help on those arguments.
--
--
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/d/optout.
>There is also ":sbuffer" which will take a buffer number or partial buffer name.
Ah, thanks. I actually just realised that #2 does with with :split! But I'd still like to know what to search for for help on those arguments.
--
--
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/d/optout.
Re: Referring to a buffer, and :help help
On Friday, February 26, 2016 at 9:46:16 AM UTC-5, Jan wrote:
> I've two files loaded, FileNumberOne in buffer 1, and FileNumberTwo in buffer 2, with just FileNumberOne currently shown. I want to open FileNumberTwo in a new split window. I can do ":split FileNumberTwo" to achieve this. However, I don't want to type out or use completion to refer to FileNumberTwo. Some commands will accept "#2", or even part of the buffer name as an argument, but not :split (and some others) - or can they?
>
> I see the usage of split is ":[N]sp[lit] [++opt] [+cmd] [file]", so I was trying to find help on what "[file]" means and what exactly I can substitute it with, but don't know how to search the help for "[file]". What would I search for for that? And [++opt], [cmd], etc. Are they in the help somewhere?
There is also ":sbuffer" which will take a buffer number or partial buffer name.
--
--
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/d/optout.
> I've two files loaded, FileNumberOne in buffer 1, and FileNumberTwo in buffer 2, with just FileNumberOne currently shown. I want to open FileNumberTwo in a new split window. I can do ":split FileNumberTwo" to achieve this. However, I don't want to type out or use completion to refer to FileNumberTwo. Some commands will accept "#2", or even part of the buffer name as an argument, but not :split (and some others) - or can they?
>
> I see the usage of split is ":[N]sp[lit] [++opt] [+cmd] [file]", so I was trying to find help on what "[file]" means and what exactly I can substitute it with, but don't know how to search the help for "[file]". What would I search for for that? And [++opt], [cmd], etc. Are they in the help somewhere?
There is also ":sbuffer" which will take a buffer number or partial buffer name.
--
--
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/d/optout.
Referring to a buffer, and :help help
I've two files loaded, FileNumberOne in buffer 1, and FileNumberTwo in buffer 2, with just FileNumberOne currently shown. I want to open FileNumberTwo in a new split window. I can do ":split FileNumberTwo" to achieve this. However, I don't want to type out or use completion to refer to FileNumberTwo. Some commands will accept "#2", or even part of the buffer name as an argument, but not :split (and some others) - or can they?
I see the usage of split is ":[N]sp[lit] [++opt] [+cmd] [file]", so I was trying to find help on what "[file]" means and what exactly I can substitute it with, but don't know how to search the help for "[file]". What would I search for for that? And [++opt], [cmd], etc. Are they in the help somewhere?
--
--
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/d/optout.
I see the usage of split is ":[N]sp[lit] [++opt] [+cmd] [file]", so I was trying to find help on what "[file]" means and what exactly I can substitute it with, but don't know how to search the help for "[file]". What would I search for for that? And [++opt], [cmd], etc. Are they in the help somewhere?
--
--
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/d/optout.
Packages
There have been a couple of people posting about how the new package feature can, in its current state, replace Pathogen.
https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
Could someone explain how? It doesn't seem to work for plugins that don't have a "plugin" directory, and as far as I can tell from the source it's not supposed to, either.
Why was this decision made to only support plugins with a "plugin" directory?
--
--
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/d/optout.
https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
Could someone explain how? It doesn't seem to work for plugins that don't have a "plugin" directory, and as far as I can tell from the source it's not supposed to, either.
Why was this decision made to only support plugins with a "plugin" directory?
--
--
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/d/optout.
big with windows codepage 65001 (UTF-8)
Hi,
-- on Windows I've set my default code page to 65001 (UTF-8)
This is how vim looks like:
If I change code page to some other, like `chcp 866` if works as expected.
========================================
> vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 10 2013 14:33:40)
MS-Windows 32-bit console version
Compiled by mool@tororo
Big version without GUI. Features included (+) or not (-):
+arabic +ex_extra -mouseshape +tag_binary
+autocmd +extra_search +multi_byte +tag_old_static
-balloon_eval +farsi +multi_lang -tag_any_white
-browse +file_in_path -mzscheme -tcl
++builtin_terms +find_in_path -netbeans_intg -tgetent
+byte_offset +float +path_extra -termresponse
+cindent +folding -perl +textobjects
+clientserver -footer +persistent_undo +title
+clipboard +gettext/dyn -postscript -toolbar
+cmdline_compl -hangul_input +printer +user_commands
+cmdline_hist +iconv/dyn -profile +vertsplit
+cmdline_info +insert_expand -python +virtualedit
+comments +jumplist -python3 +visual
+conceal +keymap +quickfix +visualextra
+cryptv +langmap +reltime +viminfo
+cscope +libcall +rightleft +vreplace
+cursorbind +linebreak -ruby +wildignore
+cursorshape +lispindent +scrollbind +wildmenu
+dialog_con +listcmds +signs +windows
+diff +localmap +smartindent +writebackup
+digraphs -lua -sniff -xfontset
-dnd +menu +startuptime -xim
-ebcdic +mksession +statusline -xterm_save
+emacs_tags +modify_fname -sun_workshop -xpm_w32
+eval +mouse +syntax
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$HOME\vimfiles\vimrc"
3rd user vimrc file: "$VIM\_vimrc"
user exrc file: "$HOME\_exrc"
2nd user exrc file: "$VIM\_exrc"
Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 /Fo.\ObjCi386/ /Ox /GL -DNDEBUG /Zl /MT -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_BIG /Fd.\ObjCi386/ /Zi
Linking: link /RELEASE /nologo /subsystem:console /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib libcmt.lib user32.lib /PDB:vim.pdb -debug
========================================
--
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/d/optout.
Subscribe to:
Posts (Atom)