Gary Johnson wrote:
> > > I recently learned that Vim can query an xterm directly for the
> > > number of colors it supports. (This is not necessarily the same
> > > value reported by terminfo. Otherwise, it wouldn't be very useful.)
> > > Vim then sets t_Co to this number. I would like to use that value
> > > to affect other color settings, but I can't figure out when to do
> > > that. I captured the value of &t_Co at the start and end of my
> > > ~/.vimrc and upon these autocommand events,
> > >
> > > BufWinEnter
> > > ColorScheme
> > > FileType
> > > OptionSet
> > > TermResponse
> > > VimEnter
> > >
> > > but the value was always 8. By the time I queried the value from
> > > Vim's command line, though, the value was 256.
> > >
> > > What event do I need to wait for to determine that t_Co may have
> > > changed to 256?
> >
> > Can't think of something. We do have the OptionSet autocommand event,
> > but it's not triggered in this case. Perhaps we should make a change
> > for that. The code is near the end of set_num_option().
>
> That seems like the right thing to do. I'm trying to think of what
> could go wrong. I'm concerned about this statement under ":help
> OptionsSet":
>
> Note: It's a bad idea to reset an option
> during this autocommand, this may break a
> plugin. You can always use `:noa` to prevent
> triggering this autocommand.
>
> I was considering having this autocommand execute a :colorscheme
> {name} command. That would often set 'background'. And if "nested"
> was used, it would trigger a ColorScheme event.
>
> That all seems OK. I'll look at creating a patch.
The color schemes are reloaded when t_Co changes, perhaps you can set a
color scheme that checks the value of t_Co?
--
There are three kinds of people: Those who can count & those who can't.
/// 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.
Thursday, December 31, 2015
Re: When is an xterm's t_Co detected?
On Do, 31 Dez 2015, Gary Johnson wrote:
> That seems like the right thing to do. I'm trying to think of what
> could go wrong. I'm concerned about this statement under ":help
> OptionsSet":
>
> Note: It's a bad idea to reset an option
> during this autocommand, this may break a
> plugin. You can always use `:noa` to prevent
> triggering this autocommand.
>
> I was considering having this autocommand execute a :colorscheme
> {name} command. That would often set 'background'. And if "nested"
> was used, it would trigger a ColorScheme event.
Yes possibly. What was meant with above paragraph was to be prepared
that resetting an option value once OptionSet triggers, might have
unwanted consequences, because usually plugins do set those options for
a reason. Nevertheless, you can do that, and I have already used it to
reset unwanted option values.
That works most of time, if the option is set correctly (and not by just
resetting some flag in the Vim core, which happens e.g. when diff mode
is turned on).
Best,
Christian
--
In der Ehe gilt Verstand (zumal des Weibs) weit mehr als Liebe. Diese
hält nicht lange nach, wird leicht gestört und bringt nie in Ordnung.
Also bildet eure Töchter verständig, nicht bloß liebend.
-- Jean Paul
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> That seems like the right thing to do. I'm trying to think of what
> could go wrong. I'm concerned about this statement under ":help
> OptionsSet":
>
> Note: It's a bad idea to reset an option
> during this autocommand, this may break a
> plugin. You can always use `:noa` to prevent
> triggering this autocommand.
>
> I was considering having this autocommand execute a :colorscheme
> {name} command. That would often set 'background'. And if "nested"
> was used, it would trigger a ColorScheme event.
Yes possibly. What was meant with above paragraph was to be prepared
that resetting an option value once OptionSet triggers, might have
unwanted consequences, because usually plugins do set those options for
a reason. Nevertheless, you can do that, and I have already used it to
reset unwanted option values.
That works most of time, if the option is set correctly (and not by just
resetting some flag in the Vim core, which happens e.g. when diff mode
is turned on).
Best,
Christian
--
In der Ehe gilt Verstand (zumal des Weibs) weit mehr als Liebe. Diese
hält nicht lange nach, wird leicht gestört und bringt nie in Ordnung.
Also bildet eure Töchter verständig, nicht bloß liebend.
-- Jean Paul
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: When is an xterm's t_Co detected?
On 2015-12-31, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > I recently learned that Vim can query an xterm directly for the
> > number of colors it supports. (This is not necessarily the same
> > value reported by terminfo. Otherwise, it wouldn't be very useful.)
> > Vim then sets t_Co to this number. I would like to use that value
> > to affect other color settings, but I can't figure out when to do
> > that. I captured the value of &t_Co at the start and end of my
> > ~/.vimrc and upon these autocommand events,
> >
> > BufWinEnter
> > ColorScheme
> > FileType
> > OptionSet
> > TermResponse
> > VimEnter
> >
> > but the value was always 8. By the time I queried the value from
> > Vim's command line, though, the value was 256.
> >
> > What event do I need to wait for to determine that t_Co may have
> > changed to 256?
>
> Can't think of something. We do have the OptionSet autocommand event,
> but it's not triggered in this case. Perhaps we should make a change
> for that. The code is near the end of set_num_option().
That seems like the right thing to do. I'm trying to think of what
could go wrong. I'm concerned about this statement under ":help
OptionsSet":
Note: It's a bad idea to reset an option
during this autocommand, this may break a
plugin. You can always use `:noa` to prevent
triggering this autocommand.
I was considering having this autocommand execute a :colorscheme
{name} command. That would often set 'background'. And if "nested"
was used, it would trigger a ColorScheme event.
That all seems OK. I'll look at creating a patch.
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> Gary Johnson wrote:
>
> > I recently learned that Vim can query an xterm directly for the
> > number of colors it supports. (This is not necessarily the same
> > value reported by terminfo. Otherwise, it wouldn't be very useful.)
> > Vim then sets t_Co to this number. I would like to use that value
> > to affect other color settings, but I can't figure out when to do
> > that. I captured the value of &t_Co at the start and end of my
> > ~/.vimrc and upon these autocommand events,
> >
> > BufWinEnter
> > ColorScheme
> > FileType
> > OptionSet
> > TermResponse
> > VimEnter
> >
> > but the value was always 8. By the time I queried the value from
> > Vim's command line, though, the value was 256.
> >
> > What event do I need to wait for to determine that t_Co may have
> > changed to 256?
>
> Can't think of something. We do have the OptionSet autocommand event,
> but it's not triggered in this case. Perhaps we should make a change
> for that. The code is near the end of set_num_option().
That seems like the right thing to do. I'm trying to think of what
could go wrong. I'm concerned about this statement under ":help
OptionsSet":
Note: It's a bad idea to reset an option
during this autocommand, this may break a
plugin. You can always use `:noa` to prevent
triggering this autocommand.
I was considering having this autocommand execute a :colorscheme
{name} command. That would often set 'background'. And if "nested"
was used, it would trigger a ColorScheme event.
That all seems OK. I'll look at creating a patch.
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: When is an xterm's t_Co detected?
Gary Johnson wrote:
> I recently learned that Vim can query an xterm directly for the
> number of colors it supports. (This is not necessarily the same
> value reported by terminfo. Otherwise, it wouldn't be very useful.)
> Vim then sets t_Co to this number. I would like to use that value
> to affect other color settings, but I can't figure out when to do
> that. I captured the value of &t_Co at the start and end of my
> ~/.vimrc and upon these autocommand events,
>
> BufWinEnter
> ColorScheme
> FileType
> OptionSet
> TermResponse
> VimEnter
>
> but the value was always 8. By the time I queried the value from
> Vim's command line, though, the value was 256.
>
> What event do I need to wait for to determine that t_Co may have
> changed to 256?
Can't think of something. We do have the OptionSet autocommand event,
but it's not triggered in this case. Perhaps we should make a change
for that. The code is near the end of set_num_option().
--
LAUNCELOT: I am, sir. I am a Knight of King Arthur.
FATHER: 'Mm ... very nice castle, Camelot ... very good pig country....
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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.
> I recently learned that Vim can query an xterm directly for the
> number of colors it supports. (This is not necessarily the same
> value reported by terminfo. Otherwise, it wouldn't be very useful.)
> Vim then sets t_Co to this number. I would like to use that value
> to affect other color settings, but I can't figure out when to do
> that. I captured the value of &t_Co at the start and end of my
> ~/.vimrc and upon these autocommand events,
>
> BufWinEnter
> ColorScheme
> FileType
> OptionSet
> TermResponse
> VimEnter
>
> but the value was always 8. By the time I queried the value from
> Vim's command line, though, the value was 256.
>
> What event do I need to wait for to determine that t_Co may have
> changed to 256?
Can't think of something. We do have the OptionSet autocommand event,
but it's not triggered in this case. Perhaps we should make a change
for that. The code is near the end of set_num_option().
--
LAUNCELOT: I am, sir. I am a Knight of King Arthur.
FATHER: 'Mm ... very nice castle, Camelot ... very good pig country....
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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.
When is an xterm's t_Co detected?
I recently learned that Vim can query an xterm directly for the
number of colors it supports. (This is not necessarily the same
value reported by terminfo. Otherwise, it wouldn't be very useful.)
Vim then sets t_Co to this number. I would like to use that value
to affect other color settings, but I can't figure out when to do
that. I captured the value of &t_Co at the start and end of my
~/.vimrc and upon these autocommand events,
BufWinEnter
ColorScheme
FileType
OptionSet
TermResponse
VimEnter
but the value was always 8. By the time I queried the value from
Vim's command line, though, the value was 256.
What event do I need to wait for to determine that t_Co may have
changed to 256?
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
number of colors it supports. (This is not necessarily the same
value reported by terminfo. Otherwise, it wouldn't be very useful.)
Vim then sets t_Co to this number. I would like to use that value
to affect other color settings, but I can't figure out when to do
that. I captured the value of &t_Co at the start and end of my
~/.vimrc and upon these autocommand events,
BufWinEnter
ColorScheme
FileType
OptionSet
TermResponse
VimEnter
but the value was always 8. By the time I queried the value from
Vim's command line, though, the value was 256.
What event do I need to wait for to determine that t_Co may have
changed to 256?
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: mysterious grey bar with symbols in it
Christian Brabandt wrote:
> Hi 'Andy'!
>
> On So, 27 Dez 2015, 'Andy' via vim_use wrote:
>
>> Thanks!
>> That was exactly it. I never would have connected that featurewith the symbols, otherwise.
>> To complete the answer for others reading: making the symbolsand bar go away mans doing this:
>> :sign unplace *
> You probably have a plugin installed, that you do not need. In that
> case, simply uninstall it.
>
>
Look for a plugin that has the word "Mark" in it: under Linux, from the
.vim/ directory, use: find -L "$(pwd)" -name "*Mark*" -exec "echo" "{}"
";" 2> /dev/null
Regards,
Chip Campbell
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> Hi 'Andy'!
>
> On So, 27 Dez 2015, 'Andy' via vim_use wrote:
>
>> Thanks!
>> That was exactly it. I never would have connected that featurewith the symbols, otherwise.
>> To complete the answer for others reading: making the symbolsand bar go away mans doing this:
>> :sign unplace *
> You probably have a plugin installed, that you do not need. In that
> case, simply uninstall it.
>
>
Look for a plugin that has the word "Mark" in it: under Linux, from the
.vim/ directory, use: find -L "$(pwd)" -name "*Mark*" -exec "echo" "{}"
";" 2> /dev/null
Regards,
Chip Campbell
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Is there a way to display line numbers and relative line numbers as with two rulers?
On Fri, Dec 18, 2015 at 7:51 AM, Christian Brabandt <cblists@256bit.org> wrote:
> On Do, 17 Dez 2015, Igor Forca wrote:
>
>> Is there some setting to have two rulers one on the left and one on
>> the right in single window?
>
> No there isn't. We would have told you so otherwise.
>
> Best,
> Christian
If by "ruler" you mean the same as Vim (the current line and column in, or instead of, the status line), then with a custom status line you can add to it the absolute and relative numbers of the first and last lines visible in the window.
See
:help 'statusline'
and in particular the item for %{
:help line()> On Do, 17 Dez 2015, Igor Forca wrote:
>
>> Is there some setting to have two rulers one on the left and one on
>> the right in single window?
>
> No there isn't. We would have told you so otherwise.
>
> Best,
> Christian
If by "ruler" you mean the same as Vim (the current line and column in, or instead of, the status line), then with a custom status line you can add to it the absolute and relative numbers of the first and last lines visible in the window.
See
:help 'statusline'
and in particular the item for %{
--
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: Is there a way to display line numbers and relative line numbers as with two rulers?
Arun wrote:
> On Thu, Dec 17, 2015 at 1:05 PM, Christian Brabandt
> <cblists@256bit.org <mailto:cblists@256bit.org>> wrote:
>
> On Do, 17 Dez 2015, Arun wrote:
>
> > visual indication is a very acceptable trade off for me. I have two
> > visual mode mappings in that regard:
> >
> >
> > :vnoremap <c-d> :d<cr> :vnoremap <c-y> :y<cr>
>
> Well, you could simply press d or y in visual mode.
>
>
> That would only delete/yank the visually selected area (which could be
> partial in first/last lines), though; my intent was to delete/yank the
> selected lines.
>
Then you'd want to use V (visual-line) mode to do your visual selection.
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 Thu, Dec 17, 2015 at 1:05 PM, Christian Brabandt
> <cblists@256bit.org <mailto:cblists@256bit.org>> wrote:
>
> On Do, 17 Dez 2015, Arun wrote:
>
> > visual indication is a very acceptable trade off for me. I have two
> > visual mode mappings in that regard:
> >
> >
> > :vnoremap <c-d> :d<cr> :vnoremap <c-y> :y<cr>
>
> Well, you could simply press d or y in visual mode.
>
>
> That would only delete/yank the visually selected area (which could be
> partial in first/last lines), though; my intent was to delete/yank the
> selected lines.
>
Then you'd want to use V (visual-line) mode to do your visual selection.
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.
Tuesday, December 29, 2015
Re: How to pass format string to ?
On Tuesday, December 29, 2015 at 10:53:31 PM UTC-6, jimmy yuan wrote:
> I want to auto load CCTree, find in parent recursion.
>
> command! -nargs=? -complete=file CCTreeLoadDB call s:CCTreeCmdLine.mLoadDB(<q-args>, s:DBClasses.cscopeid)
>
> function! LoadCCTreeParent()
> let newcsdbpath = FindInParent("cscope.out",WindowDir(),$HOME)
> if newcsdbpath != "Nothing"
> let b:csdbpath = newcsdbpath
> "CCTreeLoadDB b:csdbpath . "cscope.out"
> endif
> endfunc
>
> augroup AutoLoadCCTree
> au!
> au BufEnter *.[chly] call LoadCCTreeParent()
> au BufEnter *.cc call LoadCCTreeParent()
> augroup END
>
> CCTreeLoadDB does not use the format string.How can I done it?
CCTreeLoadDB is defined to take arguments, not an expression. You are passing the literal string "b:csdbpath" to it rather than the value of that variable.
You need to use the :execute command. E.g.:
execute "CCTreeLoadDB" b:csdbpath . "cscope.out"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> I want to auto load CCTree, find in parent recursion.
>
> command! -nargs=? -complete=file CCTreeLoadDB call s:CCTreeCmdLine.mLoadDB(<q-args>, s:DBClasses.cscopeid)
>
> function! LoadCCTreeParent()
> let newcsdbpath = FindInParent("cscope.out",WindowDir(),$HOME)
> if newcsdbpath != "Nothing"
> let b:csdbpath = newcsdbpath
> "CCTreeLoadDB b:csdbpath . "cscope.out"
> endif
> endfunc
>
> augroup AutoLoadCCTree
> au!
> au BufEnter *.[chly] call LoadCCTreeParent()
> au BufEnter *.cc call LoadCCTreeParent()
> augroup END
>
> CCTreeLoadDB does not use the format string.How can I done it?
CCTreeLoadDB is defined to take arguments, not an expression. You are passing the literal string "b:csdbpath" to it rather than the value of that variable.
You need to use the :execute command. E.g.:
execute "CCTreeLoadDB" b:csdbpath . "cscope.out"
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
How to pass format string to ?
I want to auto load CCTree, find in parent recursion.
command! -nargs=? -complete=file CCTreeLoadDB call s:CCTreeCmdLine.mLoadDB(<q-args>, s:DBClasses.cscopeid)
function! LoadCCTreeParent()
let newcsdbpath = FindInParent("cscope.out",WindowDir(),$HOME)
if newcsdbpath != "Nothing"
let b:csdbpath = newcsdbpath
"CCTreeLoadDB b:csdbpath . "cscope.out"
endif
endfunc
augroup AutoLoadCCTree
au!
au BufEnter *.[chly] call LoadCCTreeParent()
au BufEnter *.cc call LoadCCTreeParent()
augroup END
CCTreeLoadDB does not use the format string.How can I done it?command! -nargs=? -complete=file CCTreeLoadDB call s:CCTreeCmdLine.mLoadDB(<q-args>, s:DBClasses.cscopeid)
function! LoadCCTreeParent()
let newcsdbpath = FindInParent("cscope.out",WindowDir(),$HOME)
if newcsdbpath != "Nothing"
let b:csdbpath = newcsdbpath
"CCTreeLoadDB b:csdbpath . "cscope.out"
endif
endfunc
augroup AutoLoadCCTree
au!
au BufEnter *.[chly] call LoadCCTreeParent()
au BufEnter *.cc call LoadCCTreeParent()
augroup END
--
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 pass a format string to ?
function! LoadCCTree()
let newcsdbpath = FindInParent("cscope.out",WindowDir(),$HOME)
if newcsdbpath != "Nothing"
let b:csdbpath = newcsdbpath
CCTreeLoadDB b:csdbpath . "cscope.out"
endif
endfunc
augroup AutoLoadCCTree
au!
au BufEnter *.[chly] call LoadCCTree()
au BufEnter *.cc call LoadCCTree()
augroup END
Not using the format string to load.
Help me.
--
--
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, December 28, 2015
Re: Apparent regex bug involving `\_.' (and other newline-matching constructs)
On Mon, Dec 28, 2015 at 12:20 PM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
> Brett Stahlman wrote:
>
>> > > Given a file containing the following 2 lines...
>> > > 1a3
>> > > 123xyz
>> > >
>> > > ...try the following tests, and note the unexpected results.
>> > >
>> > > Case 1.1:
>> > > call cursor(1, 1)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
>> > > => [1, 1, 2]
>> > >
>> > > Case 1.2:
>> > > call cursor(1, 2)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
>> > > => [2, 1, 1]
>> > > Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
>> > > Note: Clearly, submatch should be 2, not 1, but this error is simply a
>> > > consequence of the first error: since match doesn't begin on 1st line,
>> > > the "a" at cursor pos can't be captured.
>> >
>> > This is because of the 'c' flag in 'cpoptions'. The Vi-compatible way
>> > of searching is to start at the first column and skip over the match.
>> > Then take the first match after the start position.
>>
>> If this is how it works, then I would have assumed it would have skipped the
>> match it returned for Case 1.1 (at starting position 1,1). But perhaps not
>> skipping the match at column 1 had something to do with (from help on 'cpo')
>> "...but not further than the start of the next line"? If so, the help text
>> isn't very clear in this case. It seems to be describing search
>> "continuation", and my tests were for an isolated search beginning at an
>> arbitrary buffer position. Also, the term "next line" is a bit misleading:
>> in this case, it seems to refer to what would have been the next line of a
>> *previous* search. But I guess the Vi designers didn't want to complicate
>> the implementation by maintaining the state needed to differentiate between
>> a subsequent search for the same pattern without intervening cursor movement
>> and a new search...
>>
>> >
>> > > Case 1.3:
>> > > call cursor(1, 3)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
>> > > => [2, 1, 1]
>> > > Note: Why isn't a match found at cursor pos (1, 3)?
>> > >
>> > > Repeat these tests with a \zs in the pattern, and note how the capture
>> > > is matched unconditionally...
>> > >
>> > > Case 2.1:
>> > > call cursor(1, 1)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
>> > > => [2, 4, 2]
>> > >
>> > > Case 2.2:
>> > > call cursor(1, 2)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
>> > > => [2, 4, 2]
>> > >
>> > > Case 2.3:
>> > > call cursor(1, 3)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
>> > > => [2, 4, 2]
>> > > Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
>> > > capture to match unconditionally.
>> > >
>> > > Points to note... Originally, I thought the error had to do with the 'p'
>> > > flag, but that appears not to be the case: the submatch errors are simply a
>> > > consequence of the incorrectly determined start locations. Also, it appears
>> > > the results would have been the same with * as they were with \{-}.
>> > > Finally, the unexpected behavior is not limited to \_., but is seen even
>> > > when (e.g.) explicit \n is used.
>> >
>> > After removing 'c' from 'cpoptions', does it work as you expect?
>>
>> Not as I expected, but the first 3 tests, at least, work as I now expect.
>>
>> Case 3.3, however, makes no sense to me now. It returns...
>> => [2, 4, 2]
>> ...even though there's nothing to match the [a-z]. If I change the "1a3" to
>> "123", it returns...
>> => [2, 4, 1]
>> ...which tells me that the parens were capturing the "a" *before* the start
>> position, in spite of the 'W' flag prohibiting wrap. This tells me that the
>> search must be starting before the cursor position, most likely at the start
>> of the cursor line. I would not have expected that a forward search with no
>> lookbehind of any sort could find anything prior to the starting cursor
>> position. But I guess it's not really finding a match prior to the cursor
>> position - just checking to see what needs to be skipped? But with &cpo no
>> longer containing 'c', and the 'c' flag passed to searchpos(), why would it
>> even need this sort of "skip-over" test prior to cursor position?
>
> The search always starts in the first column. Then when a match is
> found and it's before the cursor, another search is done at the next
> position.
Interesting. So IIUC, that could result in a lot of redundant
searches, when the pattern appears multiple times on the same line
prior to start position: e.g., with the following text and cursor
position...
123 123 123 123 <cursor> 123 123 123
A search for "123" would have to try and discard 4 matches before
finding one to return; a subsequent search from the new location would
have to discard 5 matches, a subsequent search would discard 6
matches, and so on... Although this could be inefficient in certain
pathological, long-line scenarios, the bigger issue is the effect it
has on the returned 'submatch' value when the 'p' flag is used.
> Vi compatible is to continue after the matched pattern. When
> removing 'c' from 'cpo' it searches from the next column.
>
> With the \zs the search in the first column returns a position after the
> start position, thus it's a match. Without the \zs the column would be
> the first column.
>
> I can see this is not what you expect or what you want. We can add
> another flag to actually start at the search start position.
I guess that makes sense; either that, or perhaps alter the existing
implementation to ensure that a capture can't capture anything before
the starting location (unless the capture occurs in a look-behind
context).
Thanks,
Brett S.
>
> --
> Computers are not intelligent. They only think they are.
>
> /// 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.
>
> Brett Stahlman wrote:
>
>> > > Given a file containing the following 2 lines...
>> > > 1a3
>> > > 123xyz
>> > >
>> > > ...try the following tests, and note the unexpected results.
>> > >
>> > > Case 1.1:
>> > > call cursor(1, 1)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
>> > > => [1, 1, 2]
>> > >
>> > > Case 1.2:
>> > > call cursor(1, 2)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
>> > > => [2, 1, 1]
>> > > Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
>> > > Note: Clearly, submatch should be 2, not 1, but this error is simply a
>> > > consequence of the first error: since match doesn't begin on 1st line,
>> > > the "a" at cursor pos can't be captured.
>> >
>> > This is because of the 'c' flag in 'cpoptions'. The Vi-compatible way
>> > of searching is to start at the first column and skip over the match.
>> > Then take the first match after the start position.
>>
>> If this is how it works, then I would have assumed it would have skipped the
>> match it returned for Case 1.1 (at starting position 1,1). But perhaps not
>> skipping the match at column 1 had something to do with (from help on 'cpo')
>> "...but not further than the start of the next line"? If so, the help text
>> isn't very clear in this case. It seems to be describing search
>> "continuation", and my tests were for an isolated search beginning at an
>> arbitrary buffer position. Also, the term "next line" is a bit misleading:
>> in this case, it seems to refer to what would have been the next line of a
>> *previous* search. But I guess the Vi designers didn't want to complicate
>> the implementation by maintaining the state needed to differentiate between
>> a subsequent search for the same pattern without intervening cursor movement
>> and a new search...
>>
>> >
>> > > Case 1.3:
>> > > call cursor(1, 3)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
>> > > => [2, 1, 1]
>> > > Note: Why isn't a match found at cursor pos (1, 3)?
>> > >
>> > > Repeat these tests with a \zs in the pattern, and note how the capture
>> > > is matched unconditionally...
>> > >
>> > > Case 2.1:
>> > > call cursor(1, 1)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
>> > > => [2, 4, 2]
>> > >
>> > > Case 2.2:
>> > > call cursor(1, 2)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
>> > > => [2, 4, 2]
>> > >
>> > > Case 2.3:
>> > > call cursor(1, 3)
>> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
>> > > => [2, 4, 2]
>> > > Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
>> > > capture to match unconditionally.
>> > >
>> > > Points to note... Originally, I thought the error had to do with the 'p'
>> > > flag, but that appears not to be the case: the submatch errors are simply a
>> > > consequence of the incorrectly determined start locations. Also, it appears
>> > > the results would have been the same with * as they were with \{-}.
>> > > Finally, the unexpected behavior is not limited to \_., but is seen even
>> > > when (e.g.) explicit \n is used.
>> >
>> > After removing 'c' from 'cpoptions', does it work as you expect?
>>
>> Not as I expected, but the first 3 tests, at least, work as I now expect.
>>
>> Case 3.3, however, makes no sense to me now. It returns...
>> => [2, 4, 2]
>> ...even though there's nothing to match the [a-z]. If I change the "1a3" to
>> "123", it returns...
>> => [2, 4, 1]
>> ...which tells me that the parens were capturing the "a" *before* the start
>> position, in spite of the 'W' flag prohibiting wrap. This tells me that the
>> search must be starting before the cursor position, most likely at the start
>> of the cursor line. I would not have expected that a forward search with no
>> lookbehind of any sort could find anything prior to the starting cursor
>> position. But I guess it's not really finding a match prior to the cursor
>> position - just checking to see what needs to be skipped? But with &cpo no
>> longer containing 'c', and the 'c' flag passed to searchpos(), why would it
>> even need this sort of "skip-over" test prior to cursor position?
>
> The search always starts in the first column. Then when a match is
> found and it's before the cursor, another search is done at the next
> position.
Interesting. So IIUC, that could result in a lot of redundant
searches, when the pattern appears multiple times on the same line
prior to start position: e.g., with the following text and cursor
position...
123 123 123 123 <cursor> 123 123 123
A search for "123" would have to try and discard 4 matches before
finding one to return; a subsequent search from the new location would
have to discard 5 matches, a subsequent search would discard 6
matches, and so on... Although this could be inefficient in certain
pathological, long-line scenarios, the bigger issue is the effect it
has on the returned 'submatch' value when the 'p' flag is used.
> Vi compatible is to continue after the matched pattern. When
> removing 'c' from 'cpo' it searches from the next column.
>
> With the \zs the search in the first column returns a position after the
> start position, thus it's a match. Without the \zs the column would be
> the first column.
>
> I can see this is not what you expect or what you want. We can add
> another flag to actually start at the search start position.
I guess that makes sense; either that, or perhaps alter the existing
implementation to ensure that a capture can't capture anything before
the starting location (unless the capture occurs in a look-behind
context).
Thanks,
Brett S.
>
> --
> Computers are not intelligent. They only think they are.
>
> /// 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: Apparent regex bug involving `\_.' (and other newline-matching constructs)
Brett Stahlman wrote:
> > > Given a file containing the following 2 lines...
> > > 1a3
> > > 123xyz
> > >
> > > ...try the following tests, and note the unexpected results.
> > >
> > > Case 1.1:
> > > call cursor(1, 1)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > > => [1, 1, 2]
> > >
> > > Case 1.2:
> > > call cursor(1, 2)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > > => [2, 1, 1]
> > > Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
> > > Note: Clearly, submatch should be 2, not 1, but this error is simply a
> > > consequence of the first error: since match doesn't begin on 1st line,
> > > the "a" at cursor pos can't be captured.
> >
> > This is because of the 'c' flag in 'cpoptions'. The Vi-compatible way
> > of searching is to start at the first column and skip over the match.
> > Then take the first match after the start position.
>
> If this is how it works, then I would have assumed it would have skipped the
> match it returned for Case 1.1 (at starting position 1,1). But perhaps not
> skipping the match at column 1 had something to do with (from help on 'cpo')
> "...but not further than the start of the next line"? If so, the help text
> isn't very clear in this case. It seems to be describing search
> "continuation", and my tests were for an isolated search beginning at an
> arbitrary buffer position. Also, the term "next line" is a bit misleading:
> in this case, it seems to refer to what would have been the next line of a
> *previous* search. But I guess the Vi designers didn't want to complicate
> the implementation by maintaining the state needed to differentiate between
> a subsequent search for the same pattern without intervening cursor movement
> and a new search...
>
> >
> > > Case 1.3:
> > > call cursor(1, 3)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > > => [2, 1, 1]
> > > Note: Why isn't a match found at cursor pos (1, 3)?
> > >
> > > Repeat these tests with a \zs in the pattern, and note how the capture
> > > is matched unconditionally...
> > >
> > > Case 2.1:
> > > call cursor(1, 1)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > > => [2, 4, 2]
> > >
> > > Case 2.2:
> > > call cursor(1, 2)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > > => [2, 4, 2]
> > >
> > > Case 2.3:
> > > call cursor(1, 3)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > > => [2, 4, 2]
> > > Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
> > > capture to match unconditionally.
> > >
> > > Points to note... Originally, I thought the error had to do with the 'p'
> > > flag, but that appears not to be the case: the submatch errors are simply a
> > > consequence of the incorrectly determined start locations. Also, it appears
> > > the results would have been the same with * as they were with \{-}.
> > > Finally, the unexpected behavior is not limited to \_., but is seen even
> > > when (e.g.) explicit \n is used.
> >
> > After removing 'c' from 'cpoptions', does it work as you expect?
>
> Not as I expected, but the first 3 tests, at least, work as I now expect.
>
> Case 3.3, however, makes no sense to me now. It returns...
> => [2, 4, 2]
> ...even though there's nothing to match the [a-z]. If I change the "1a3" to
> "123", it returns...
> => [2, 4, 1]
> ...which tells me that the parens were capturing the "a" *before* the start
> position, in spite of the 'W' flag prohibiting wrap. This tells me that the
> search must be starting before the cursor position, most likely at the start
> of the cursor line. I would not have expected that a forward search with no
> lookbehind of any sort could find anything prior to the starting cursor
> position. But I guess it's not really finding a match prior to the cursor
> position - just checking to see what needs to be skipped? But with &cpo no
> longer containing 'c', and the 'c' flag passed to searchpos(), why would it
> even need this sort of "skip-over" test prior to cursor position?
The search always starts in the first column. Then when a match is
found and it's before the cursor, another search is done at the next
position. Vi compatible is to continue after the matched pattern. When
removing 'c' from 'cpo' it searches from the next column.
With the \zs the search in the first column returns a position after the
start position, thus it's a match. Without the \zs the column would be
the first column.
I can see this is not what you expect or what you want. We can add
another flag to actually start at the search start position.
--
Computers are not intelligent. They only think they are.
/// 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.
> > > Given a file containing the following 2 lines...
> > > 1a3
> > > 123xyz
> > >
> > > ...try the following tests, and note the unexpected results.
> > >
> > > Case 1.1:
> > > call cursor(1, 1)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > > => [1, 1, 2]
> > >
> > > Case 1.2:
> > > call cursor(1, 2)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > > => [2, 1, 1]
> > > Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
> > > Note: Clearly, submatch should be 2, not 1, but this error is simply a
> > > consequence of the first error: since match doesn't begin on 1st line,
> > > the "a" at cursor pos can't be captured.
> >
> > This is because of the 'c' flag in 'cpoptions'. The Vi-compatible way
> > of searching is to start at the first column and skip over the match.
> > Then take the first match after the start position.
>
> If this is how it works, then I would have assumed it would have skipped the
> match it returned for Case 1.1 (at starting position 1,1). But perhaps not
> skipping the match at column 1 had something to do with (from help on 'cpo')
> "...but not further than the start of the next line"? If so, the help text
> isn't very clear in this case. It seems to be describing search
> "continuation", and my tests were for an isolated search beginning at an
> arbitrary buffer position. Also, the term "next line" is a bit misleading:
> in this case, it seems to refer to what would have been the next line of a
> *previous* search. But I guess the Vi designers didn't want to complicate
> the implementation by maintaining the state needed to differentiate between
> a subsequent search for the same pattern without intervening cursor movement
> and a new search...
>
> >
> > > Case 1.3:
> > > call cursor(1, 3)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > > => [2, 1, 1]
> > > Note: Why isn't a match found at cursor pos (1, 3)?
> > >
> > > Repeat these tests with a \zs in the pattern, and note how the capture
> > > is matched unconditionally...
> > >
> > > Case 2.1:
> > > call cursor(1, 1)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > > => [2, 4, 2]
> > >
> > > Case 2.2:
> > > call cursor(1, 2)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > > => [2, 4, 2]
> > >
> > > Case 2.3:
> > > call cursor(1, 3)
> > > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > > => [2, 4, 2]
> > > Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
> > > capture to match unconditionally.
> > >
> > > Points to note... Originally, I thought the error had to do with the 'p'
> > > flag, but that appears not to be the case: the submatch errors are simply a
> > > consequence of the incorrectly determined start locations. Also, it appears
> > > the results would have been the same with * as they were with \{-}.
> > > Finally, the unexpected behavior is not limited to \_., but is seen even
> > > when (e.g.) explicit \n is used.
> >
> > After removing 'c' from 'cpoptions', does it work as you expect?
>
> Not as I expected, but the first 3 tests, at least, work as I now expect.
>
> Case 3.3, however, makes no sense to me now. It returns...
> => [2, 4, 2]
> ...even though there's nothing to match the [a-z]. If I change the "1a3" to
> "123", it returns...
> => [2, 4, 1]
> ...which tells me that the parens were capturing the "a" *before* the start
> position, in spite of the 'W' flag prohibiting wrap. This tells me that the
> search must be starting before the cursor position, most likely at the start
> of the cursor line. I would not have expected that a forward search with no
> lookbehind of any sort could find anything prior to the starting cursor
> position. But I guess it's not really finding a match prior to the cursor
> position - just checking to see what needs to be skipped? But with &cpo no
> longer containing 'c', and the 'c' flag passed to searchpos(), why would it
> even need this sort of "skip-over" test prior to cursor position?
The search always starts in the first column. Then when a match is
found and it's before the cursor, another search is done at the next
position. Vi compatible is to continue after the matched pattern. When
removing 'c' from 'cpo' it searches from the next column.
With the \zs the search in the first column returns a position after the
start position, thus it's a match. Without the \zs the column would be
the first column.
I can see this is not what you expect or what you want. We can add
another flag to actually start at the search start position.
--
Computers are not intelligent. They only think they are.
/// 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: Apparent regex bug involving `\_.' (and other newline-matching constructs)
On Mon, Dec 28, 2015 at 6:20 AM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
>
> Brett Stahlman wrote:
>
> > Given a file containing the following 2 lines...
> > 1a3
> > 123xyz
> >
> > ...try the following tests, and note the unexpected results.
> >
> > Case 1.1:
> > call cursor(1, 1)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > => [1, 1, 2]
> >
> > Case 1.2:
> > call cursor(1, 2)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > => [2, 1, 1]
> > Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
> > Note: Clearly, submatch should be 2, not 1, but this error is simply a
> > consequence of the first error: since match doesn't begin on 1st line,
> > the "a" at cursor pos can't be captured.
>
> This is because of the 'c' flag in 'cpoptions'. The Vi-compatible way
> of searching is to start at the first column and skip over the match.
> Then take the first match after the start position.
If this is how it works, then I would have assumed it would have skipped the
match it returned for Case 1.1 (at starting position 1,1). But perhaps not
skipping the match at column 1 had something to do with (from help on 'cpo')
"...but not further than the start of the next line"? If so, the help text
isn't very clear in this case. It seems to be describing search
"continuation", and my tests were for an isolated search beginning at an
arbitrary buffer position. Also, the term "next line" is a bit misleading:
in this case, it seems to refer to what would have been the next line of a
*previous* search. But I guess the Vi designers didn't want to complicate
the implementation by maintaining the state needed to differentiate between
a subsequent search for the same pattern without intervening cursor movement
and a new search...
>
> > Case 1.3:
> > call cursor(1, 3)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > => [2, 1, 1]
> > Note: Why isn't a match found at cursor pos (1, 3)?
> >
> > Repeat these tests with a \zs in the pattern, and note how the capture
> > is matched unconditionally...
> >
> > Case 2.1:
> > call cursor(1, 1)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > => [2, 4, 2]
> >
> > Case 2.2:
> > call cursor(1, 2)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > => [2, 4, 2]
> >
> > Case 2.3:
> > call cursor(1, 3)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > => [2, 4, 2]
> > Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
> > capture to match unconditionally.
> >
> > Points to note... Originally, I thought the error had to do with the 'p'
> > flag, but that appears not to be the case: the submatch errors are simply a
> > consequence of the incorrectly determined start locations. Also, it appears
> > the results would have been the same with * as they were with \{-}.
> > Finally, the unexpected behavior is not limited to \_., but is seen even
> > when (e.g.) explicit \n is used.
>
> After removing 'c' from 'cpoptions', does it work as you expect?
Not as I expected, but the first 3 tests, at least, work as I now expect.
Case 3.3, however, makes no sense to me now. It returns...
=> [2, 4, 2]
...even though there's nothing to match the [a-z]. If I change the "1a3" to
"123", it returns...
=> [2, 4, 1]
...which tells me that the parens were capturing the "a" *before* the start
position, in spite of the 'W' flag prohibiting wrap. This tells me that the
search must be starting before the cursor position, most likely at the start
of the cursor line. I would not have expected that a forward search with no
lookbehind of any sort could find anything prior to the starting cursor
position. But I guess it's not really finding a match prior to the cursor
position - just checking to see what needs to be skipped? But with &cpo no
longer containing 'c', and the 'c' flag passed to searchpos(), why would it
even need this sort of "skip-over" test prior to cursor position?
Thanks,
Brett S.
>
> --
> Veni, Vidi, Video -- I came, I saw, I taped what I saw.
>
> /// 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.
>
>
> Brett Stahlman wrote:
>
> > Given a file containing the following 2 lines...
> > 1a3
> > 123xyz
> >
> > ...try the following tests, and note the unexpected results.
> >
> > Case 1.1:
> > call cursor(1, 1)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > => [1, 1, 2]
> >
> > Case 1.2:
> > call cursor(1, 2)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > => [2, 1, 1]
> > Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
> > Note: Clearly, submatch should be 2, not 1, but this error is simply a
> > consequence of the first error: since match doesn't begin on 1st line,
> > the "a" at cursor pos can't be captured.
>
> This is because of the 'c' flag in 'cpoptions'. The Vi-compatible way
> of searching is to start at the first column and skip over the match.
> Then take the first match after the start position.
If this is how it works, then I would have assumed it would have skipped the
match it returned for Case 1.1 (at starting position 1,1). But perhaps not
skipping the match at column 1 had something to do with (from help on 'cpo')
"...but not further than the start of the next line"? If so, the help text
isn't very clear in this case. It seems to be describing search
"continuation", and my tests were for an isolated search beginning at an
arbitrary buffer position. Also, the term "next line" is a bit misleading:
in this case, it seems to refer to what would have been the next line of a
*previous* search. But I guess the Vi designers didn't want to complicate
the implementation by maintaining the state needed to differentiate between
a subsequent search for the same pattern without intervening cursor movement
and a new search...
>
> > Case 1.3:
> > call cursor(1, 3)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> > => [2, 1, 1]
> > Note: Why isn't a match found at cursor pos (1, 3)?
> >
> > Repeat these tests with a \zs in the pattern, and note how the capture
> > is matched unconditionally...
> >
> > Case 2.1:
> > call cursor(1, 1)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > => [2, 4, 2]
> >
> > Case 2.2:
> > call cursor(1, 2)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > => [2, 4, 2]
> >
> > Case 2.3:
> > call cursor(1, 3)
> > echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> > => [2, 4, 2]
> > Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
> > capture to match unconditionally.
> >
> > Points to note... Originally, I thought the error had to do with the 'p'
> > flag, but that appears not to be the case: the submatch errors are simply a
> > consequence of the incorrectly determined start locations. Also, it appears
> > the results would have been the same with * as they were with \{-}.
> > Finally, the unexpected behavior is not limited to \_., but is seen even
> > when (e.g.) explicit \n is used.
>
> After removing 'c' from 'cpoptions', does it work as you expect?
Not as I expected, but the first 3 tests, at least, work as I now expect.
Case 3.3, however, makes no sense to me now. It returns...
=> [2, 4, 2]
...even though there's nothing to match the [a-z]. If I change the "1a3" to
"123", it returns...
=> [2, 4, 1]
...which tells me that the parens were capturing the "a" *before* the start
position, in spite of the 'W' flag prohibiting wrap. This tells me that the
search must be starting before the cursor position, most likely at the start
of the cursor line. I would not have expected that a forward search with no
lookbehind of any sort could find anything prior to the starting cursor
position. But I guess it's not really finding a match prior to the cursor
position - just checking to see what needs to be skipped? But with &cpo no
longer containing 'c', and the 'c' flag passed to searchpos(), why would it
even need this sort of "skip-over" test prior to cursor position?
Thanks,
Brett S.
>
> --
> Veni, Vidi, Video -- I came, I saw, I taped what I saw.
>
> /// 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: Apparent regex bug involving `\_.' (and other newline-matching constructs)
Brett Stahlman wrote:
> Given a file containing the following 2 lines...
> 1a3
> 123xyz
>
> ...try the following tests, and note the unexpected results.
>
> Case 1.1:
> call cursor(1, 1)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> => [1, 1, 2]
>
> Case 1.2:
> call cursor(1, 2)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> => [2, 1, 1]
> Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
> Note: Clearly, submatch should be 2, not 1, but this error is simply a
> consequence of the first error: since match doesn't begin on 1st line,
> the "a" at cursor pos can't be captured.
This is because of the 'c' flag in 'cpoptions'. The Vi-compatible way
of searching is to start at the first column and skip over the match.
Then take the first match after the start position.
> Case 1.3:
> call cursor(1, 3)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> => [2, 1, 1]
> Note: Why isn't a match found at cursor pos (1, 3)?
>
> Repeat these tests with a \zs in the pattern, and note how the capture
> is matched unconditionally...
>
> Case 2.1:
> call cursor(1, 1)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> => [2, 4, 2]
>
> Case 2.2:
> call cursor(1, 2)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> => [2, 4, 2]
>
> Case 2.3:
> call cursor(1, 3)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> => [2, 4, 2]
> Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
> capture to match unconditionally.
>
> Points to note... Originally, I thought the error had to do with the 'p'
> flag, but that appears not to be the case: the submatch errors are simply a
> consequence of the incorrectly determined start locations. Also, it appears
> the results would have been the same with * as they were with \{-}.
> Finally, the unexpected behavior is not limited to \_., but is seen even
> when (e.g.) explicit \n is used.
After removing 'c' from 'cpoptions', does it work as you expect?
--
Veni, Vidi, Video -- I came, I saw, I taped what I saw.
/// 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.
> Given a file containing the following 2 lines...
> 1a3
> 123xyz
>
> ...try the following tests, and note the unexpected results.
>
> Case 1.1:
> call cursor(1, 1)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> => [1, 1, 2]
>
> Case 1.2:
> call cursor(1, 2)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> => [2, 1, 1]
> Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
> Note: Clearly, submatch should be 2, not 1, but this error is simply a
> consequence of the first error: since match doesn't begin on 1st line,
> the "a" at cursor pos can't be captured.
This is because of the 'c' flag in 'cpoptions'. The Vi-compatible way
of searching is to start at the first column and skip over the match.
Then take the first match after the start position.
> Case 1.3:
> call cursor(1, 3)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
> => [2, 1, 1]
> Note: Why isn't a match found at cursor pos (1, 3)?
>
> Repeat these tests with a \zs in the pattern, and note how the capture
> is matched unconditionally...
>
> Case 2.1:
> call cursor(1, 1)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> => [2, 4, 2]
>
> Case 2.2:
> call cursor(1, 2)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> => [2, 4, 2]
>
> Case 2.3:
> call cursor(1, 3)
> echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
> => [2, 4, 2]
> Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
> capture to match unconditionally.
>
> Points to note... Originally, I thought the error had to do with the 'p'
> flag, but that appears not to be the case: the submatch errors are simply a
> consequence of the incorrectly determined start locations. Also, it appears
> the results would have been the same with * as they were with \{-}.
> Finally, the unexpected behavior is not limited to \_., but is seen even
> when (e.g.) explicit \n is used.
After removing 'c' from 'cpoptions', does it work as you expect?
--
Veni, Vidi, Video -- I came, I saw, I taped what I saw.
/// 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.
Sunday, December 27, 2015
Re: custom vim setup for C language
On Friday, December 25, 2015 at 2:58:06 PM UTC-6, nuliknol@gmail.com wrote:
>
> w1 (window1) has to contain the last 10 files opened, the mostly frequent edited file on the top
>
I'm not sure how to get this. Perhaps the MRU plugin can be configured to stay up. http://www.vim.org/scripts/script.php?script_id=521
> w2 (window2) has to contain the list of global variables of file currently selected on w1
>
> w3 (window3) has to contain all the functions contained in the file currently selected on window 1
>
It's not in 2 separate windows, it's in a single window, but the Tagbar plugin has a separate (foldable!) section for globals variables, functions, types, classes, etc. so I think that will achieve your goals even if it's not EXACTLY what you asked for. https://majutsushi.github.io/tagbar/
> w4 (window4) has to contain the source of the .c file currently selected on w1
>
> click on the global variable on w2 should position the cursor on that variable
>
> click on the function on w3 should position the cursor on the definition of that function
>
With Tagbar, this is Enter or Double-Click rather than single click. But you can probably map single-click to it.
> Alt-1,Alt-2,Alt-N to select a file on window1
>
This would require a mapping on your end but it shouldn't be too hard. Just map it to go to the specified line and press Enter.
--
--
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.
>
> w1 (window1) has to contain the last 10 files opened, the mostly frequent edited file on the top
>
I'm not sure how to get this. Perhaps the MRU plugin can be configured to stay up. http://www.vim.org/scripts/script.php?script_id=521
> w2 (window2) has to contain the list of global variables of file currently selected on w1
>
> w3 (window3) has to contain all the functions contained in the file currently selected on window 1
>
It's not in 2 separate windows, it's in a single window, but the Tagbar plugin has a separate (foldable!) section for globals variables, functions, types, classes, etc. so I think that will achieve your goals even if it's not EXACTLY what you asked for. https://majutsushi.github.io/tagbar/
> w4 (window4) has to contain the source of the .c file currently selected on w1
>
> click on the global variable on w2 should position the cursor on that variable
>
> click on the function on w3 should position the cursor on the definition of that function
>
With Tagbar, this is Enter or Double-Click rather than single click. But you can probably map single-click to it.
> Alt-1,Alt-2,Alt-N to select a file on window1
>
This would require a mapping on your end but it shouldn't be too hard. Just map it to go to the specified line and press Enter.
--
--
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: mysterious grey bar with symbols in it
Hi 'Andy'!
On So, 27 Dez 2015, 'Andy' via vim_use wrote:
>
> Thanks!
> That was exactly it. I never would have connected that featurewith the symbols, otherwise.
> To complete the answer for others reading: making the symbolsand bar go away mans doing this:
> :sign unplace *
You probably have a plugin installed, that you do not need. In that
case, simply uninstall it.
Best,
Christian
--
Puppe:
in Sekt'n Kind
--
--
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 So, 27 Dez 2015, 'Andy' via vim_use wrote:
>
> Thanks!
> That was exactly it. I never would have connected that featurewith the symbols, otherwise.
> To complete the answer for others reading: making the symbolsand bar go away mans doing this:
> :sign unplace *
You probably have a plugin installed, that you do not need. In that
case, simply uninstall it.
Best,
Christian
--
Puppe:
in Sekt'n Kind
--
--
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: mysterious grey bar with symbols in it
Thanks!
That was exactly it. I never would have connected that feature
with the symbols, otherwise.
To complete the answer for others reading: making the symbols
and bar go away mans doing this:
:sign unplace *
Thanks again,
Andy
From: Tony Mechelynck <antoine.mechelynck@gmail.com>
See :help sign.txt
Best regards,
Tony.
--
--
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.
Apparent regex bug involving `\_.' (and other newline-matching constructs)
Given a file containing the following 2 lines...
1a3
123xyz
...try the following tests, and note the unexpected results.
Case 1.1:
call cursor(1, 1)
echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
=> [1, 1, 2]
Case 1.2:
call cursor(1, 2)
echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
=> [2, 1, 1]
Question: Why does the \_. not permit earlier match at cursor pos (1, 2)?
Note: Clearly, submatch should be 2, not 1, but this error is simply a
consequence of the first error: since match doesn't begin on 1st line,
the "a" at cursor pos can't be captured.
Case 1.3:
call cursor(1, 3)
echo searchpos('\%(\([a-z]\)\|\_.\)\{-}xyz', 'pcW')
=> [2, 1, 1]
Note: Why isn't a match found at cursor pos (1, 3)?
Repeat these tests with a \zs in the pattern, and note how the capture
is matched unconditionally...
Case 2.1:
call cursor(1, 1)
echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
=> [2, 4, 2]
Case 2.2:
call cursor(1, 2)
echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
=> [2, 4, 2]
Case 2.3:
call cursor(1, 3)
echo searchpos('\%(\([a-z]\)\|\_.\)\{-}\zsxyz', 'pcW')
=> [2, 4, 2]
Note: Submatch should be 1, not 2, here. It's as though the \zs forces the
capture to match unconditionally.
Points to note... Originally, I thought the error had to do with the 'p' flag, but that appears not to be the case: the submatch errors are simply a consequence of the incorrectly determined start locations. Also, it appears the results would have been the same with * as they were with \{-}. Finally, the unexpected behavior is not limited to \_., but is seen even when (e.g.) explicit \n is used.
Thanks,
Brett Stahlman
--
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: mysterious grey bar with symbols in it
On Sun, Dec 27, 2015 at 7:49 AM, 'Andy' via vim_use
<vim_use@googlegroups.com> wrote:
> Hi folks,
>
> I am using vim as installed on opensuse, and have a question about it now
> that I have googled for, and cannot find any definitive information about.Or
> at least, any information that I can parse into something that "works for
> me". The only information I've come up with, that appears to bear on
> the behavior I see is stuff about folding, but I've tried turning it off
> (set
> nofoldenable), and nothing changes. The version of vim that opensuse loads
> is v7.3.831 according to the splash screen it throws up.
>
> My question is that when I fire up vim on some file, it begins with thefile
> itself just fine. But then, after a few seconds, I get a grey bar on the
> left
> side of the screen, in which some various symbols and numbers appear. For
> an example, take a look at the attached jpg. If I ever do a normal
> highlight and click,to get text from one window to another, the characters
> inside the grey barcome along too, and the grey bar turns into a two column
> wide space in thetransfered text, which is rather annoying and is most of
> the
> reason for myquestion here
>
> What is this functionality, why would I want it, and how can I get rid of it
> if in fact I don't want it after learning what it is?
>
> Thanks for any help you can provide to me,
> Andy
See :help sign.txt
Best regards,
Tony.
--
--
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_use@googlegroups.com> wrote:
> Hi folks,
>
> I am using vim as installed on opensuse, and have a question about it now
> that I have googled for, and cannot find any definitive information about.Or
> at least, any information that I can parse into something that "works for
> me". The only information I've come up with, that appears to bear on
> the behavior I see is stuff about folding, but I've tried turning it off
> (set
> nofoldenable), and nothing changes. The version of vim that opensuse loads
> is v7.3.831 according to the splash screen it throws up.
>
> My question is that when I fire up vim on some file, it begins with thefile
> itself just fine. But then, after a few seconds, I get a grey bar on the
> left
> side of the screen, in which some various symbols and numbers appear. For
> an example, take a look at the attached jpg. If I ever do a normal
> highlight and click,to get text from one window to another, the characters
> inside the grey barcome along too, and the grey bar turns into a two column
> wide space in thetransfered text, which is rather annoying and is most of
> the
> reason for myquestion here
>
> What is this functionality, why would I want it, and how can I get rid of it
> if in fact I don't want it after learning what it is?
>
> Thanks for any help you can provide to me,
> Andy
See :help sign.txt
Best regards,
Tony.
--
--
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: New to vim - c&p ident problem
On Sun, Dec 27, 2015 at 10:30 AM, evlute <teigmantel123@gmail.com> wrote:
> Hello,
>
> first of all, thanks you all of you for helping me. Now i'm in vim because
> on help register on point 8.
> It says that i can use *, + and ~ for retrieving gui information from
> xterm_clipboard. To be honest i don't know who to work with the information
> to reach my goal.
>
> greetz
> ev
The ~ register is read-only (see :help "~) and stores the latest stuff
you dropped on Vim. I don't use it, I find the other two easier to
use.
The + register is used in other programs (and in the gvim Edit menu)
for Edit→Paste, Edit→Cut and Edit→Copy.
On non-X11 platforms (Windows and Mac-Cocoa) the * register is the
same as the + register. On X11, yanking or deleting to it allows that
data to be pasted via <MiddleMouse> in other applications, and putting
from it gets the data selected in another application. In Vim,
<MiddleMouse> does the same in Normal mode, using the * register by
default, unless you just specified another register such as "a by
means of the keyboard.
see
:help registers
:help gui-selections
:help x11-selection
:help <MiddleMouse>
If you know what to copy, cut or paste where, the above will tell you
how to do it. For your original indented-paste problem, I suspect that
the 'paste' option is what makes the difference. Try pasting after
":set paste" and after ":set nopaste" and see if it changes anything.
see
:help paste
:help pastetoggle
In my case, I dont see that problem because I don't use autoindenting
(I source the vimrc_example.vim which includes a line "filetype plugin
indent on" but just after coming back from there my vimrc does
"filetype indent off" [see :help filetype-overview]).
Best regards,
Tony.
--
--
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,
>
> first of all, thanks you all of you for helping me. Now i'm in vim because
> on help register on point 8.
> It says that i can use *, + and ~ for retrieving gui information from
> xterm_clipboard. To be honest i don't know who to work with the information
> to reach my goal.
>
> greetz
> ev
The ~ register is read-only (see :help "~) and stores the latest stuff
you dropped on Vim. I don't use it, I find the other two easier to
use.
The + register is used in other programs (and in the gvim Edit menu)
for Edit→Paste, Edit→Cut and Edit→Copy.
On non-X11 platforms (Windows and Mac-Cocoa) the * register is the
same as the + register. On X11, yanking or deleting to it allows that
data to be pasted via <MiddleMouse> in other applications, and putting
from it gets the data selected in another application. In Vim,
<MiddleMouse> does the same in Normal mode, using the * register by
default, unless you just specified another register such as "a by
means of the keyboard.
see
:help registers
:help gui-selections
:help x11-selection
:help <MiddleMouse>
If you know what to copy, cut or paste where, the above will tell you
how to do it. For your original indented-paste problem, I suspect that
the 'paste' option is what makes the difference. Try pasting after
":set paste" and after ":set nopaste" and see if it changes anything.
see
:help paste
:help pastetoggle
In my case, I dont see that problem because I don't use autoindenting
(I source the vimrc_example.vim which includes a line "filetype plugin
indent on" but just after coming back from there my vimrc does
"filetype indent off" [see :help filetype-overview]).
Best regards,
Tony.
--
--
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: New to vim - c&p ident problem
Hello,
first of all, thanks you all of you for helping me. Now i'm in vim because
on help register on point 8.
It says that i can use *, + and ~ for retrieving gui information from
xterm_clipboard. To be honest i don't know who to work with the information
to reach my goal.
greetz
ev
--
View this message in context: http://vim.1045645.n5.nabble.com/New-to-vim-c-p-ident-problem-tp5726514p5726523.html
Sent from the Vim - General mailing list archive at Nabble.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.
first of all, thanks you all of you for helping me. Now i'm in vim because
on help register on point 8.
It says that i can use *, + and ~ for retrieving gui information from
xterm_clipboard. To be honest i don't know who to work with the information
to reach my goal.
greetz
ev
--
View this message in context: http://vim.1045645.n5.nabble.com/New-to-vim-c-p-ident-problem-tp5726514p5726523.html
Sent from the Vim - General mailing list archive at Nabble.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.
Saturday, December 26, 2015
mysterious grey bar with symbols in it
Hi folks,
I am using vim as installed on opensuse, and have a question about it now
that I have googled for, and cannot find any definitive information about.Or
at least, any information that I can parse into something that "works for
me". The only information I've come up with, that appears to bear on
the behavior I see is stuff about folding, but I've tried turning it off (set
nofoldenable), and nothing changes. The version of vim that opensuse loads
is v7.3.831 according to the splash screen it throws up.
My question is that when I fire up vim on some file, it begins with thefile
itself just fine. But then, after a few seconds, I get a grey bar on the left
side of the screen, in which some various symbols and numbers appear. For
an example, take a look at the attached jpg. If I ever do a normal
highlight and click,to get text from one window to another, the characters
inside the grey barcome along too, and the grey bar turns into a two column
wide space in thetransfered text, which is rather annoying and is most of the
reason for myquestion here
What is this functionality, why would I want it, and how can I get rid of it
if in fact I don't want it after learning what it is?
Thanks for any help you can provide to me,
Andy
I am using vim as installed on opensuse, and have a question about it now
that I have googled for, and cannot find any definitive information about.Or
at least, any information that I can parse into something that "works for
me". The only information I've come up with, that appears to bear on
the behavior I see is stuff about folding, but I've tried turning it off (set
nofoldenable), and nothing changes. The version of vim that opensuse loads
is v7.3.831 according to the splash screen it throws up.
My question is that when I fire up vim on some file, it begins with thefile
itself just fine. But then, after a few seconds, I get a grey bar on the left
side of the screen, in which some various symbols and numbers appear. For
an example, take a look at the attached jpg. If I ever do a normal
highlight and click,to get text from one window to another, the characters
inside the grey barcome along too, and the grey bar turns into a two column
wide space in thetransfered text, which is rather annoying and is most of the
reason for myquestion here
What is this functionality, why would I want it, and how can I get rid of it
if in fact I don't want it after learning what it is?
Thanks for any help you can provide to me,
Andy
Re: New in VIM
I have got it :-)
Thanks a lot for your nice help.
This is how this function works in Debian 8 with:
:version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 31 2015 23:36:03)
" -------------------------------------------
function Comment()
let currentLine = getline(".")
let result = match(currentLine, '^#\~ ')
if result == 0
exe 's/^#\~ //'
else
exe 's/^/#\~ /'
endif
endfunction
nmap <F7> :call Comment()<cr>
imap <F7> <Esc>:call Comment()<cr>
" -------------------------------------------
Here is a new VIM fan, now only using VIM.
Thanks again. Cheers.
--
Jose Angel Navarro Cortes
email: janc@telefonica.net
web: http://janc.es/
Usuario Linux: #49178
El 15.12.26 15:21:19 > Tony Mechelynck dijo:
> On Sat, Dec 26, 2015 at 1:07 PM, janc@telefonica.net
> <janc@telefonica.net> wrote:
> > Thanks Paolo and Tony for your help.
> > I can't find the way to match ~ without errors.
>
> See
> :help /\
> (which was already mentioned in my previous response)
> :help 'magic'
>
> Actually (with 'magic' set, which is the default and the recommended
> setting, as the opposite might break some of the plugins included with
> Vim), ~ matches the latest subsitute string and \~ matches a tilde.
> With 'nomagic', it's the opposite. The same applies to several other
> characters which have a special meaning in a pattern when either
> preceded or not preceded by a backslash. Now read my previous post
> again, including the example functions, which assume that 'magic' is
> set.
>
> Also try a plain search — either /~ or /\~ — on (for instance) a helpfile.
>
>
> Best regards,
> Tony.
>
> --
> --
> 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.
Thanks a lot for your nice help.
This is how this function works in Debian 8 with:
:version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 31 2015 23:36:03)
" -------------------------------------------
function Comment()
let currentLine = getline(".")
let result = match(currentLine, '^#\~ ')
if result == 0
exe 's/^#\~ //'
else
exe 's/^/#\~ /'
endif
endfunction
nmap <F7> :call Comment()<cr>
imap <F7> <Esc>:call Comment()<cr>
" -------------------------------------------
Here is a new VIM fan, now only using VIM.
Thanks again. Cheers.
--
Jose Angel Navarro Cortes
email: janc@telefonica.net
web: http://janc.es/
Usuario Linux: #49178
El 15.12.26 15:21:19 > Tony Mechelynck dijo:
> On Sat, Dec 26, 2015 at 1:07 PM, janc@telefonica.net
> <janc@telefonica.net> wrote:
> > Thanks Paolo and Tony for your help.
> > I can't find the way to match ~ without errors.
>
> See
> :help /\
> (which was already mentioned in my previous response)
> :help 'magic'
>
> Actually (with 'magic' set, which is the default and the recommended
> setting, as the opposite might break some of the plugins included with
> Vim), ~ matches the latest subsitute string and \~ matches a tilde.
> With 'nomagic', it's the opposite. The same applies to several other
> characters which have a special meaning in a pattern when either
> preceded or not preceded by a backslash. Now read my previous post
> again, including the example functions, which assume that 'magic' is
> set.
>
> Also try a plain search — either /~ or /\~ — on (for instance) a helpfile.
>
>
> Best regards,
> Tony.
>
> --
> --
> 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: New to vim - c&p ident problem
On Sat, Dec 26, 2015 at 4:10 PM, Niels Kobschaetzki
<niels@kobschaetzki.net> wrote:
[...]
> paste via "+p (or is it "*p - I have those registers synced). That
> should work. More about registers see :help registers
>
> Niels
On all platforms except Unix/Linux, they're the same. On Unix/Linux
without X11 (including X11-enabled builds running in a console with no
access to an X11 server), they don't exist. On X11, "+ is used for
Edit→Cut, Edit→Paste, Edit→Copy while "* is used for MiddleMouse.
Best regards,
Tony.
--
--
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.
<niels@kobschaetzki.net> wrote:
[...]
> paste via "+p (or is it "*p - I have those registers synced). That
> should work. More about registers see :help registers
>
> Niels
On all platforms except Unix/Linux, they're the same. On Unix/Linux
without X11 (including X11-enabled builds running in a console with no
access to an X11 server), they don't exist. On X11, "+ is used for
Edit→Cut, Edit→Paste, Edit→Copy while "* is used for MiddleMouse.
Best regards,
Tony.
--
--
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: New to vim - c&p ident problem
* evlute <teigmantel123@gmail.com> [2015-12-26 04:12 -0700]:
> Hello Folks,
>
> i hope all of you had a very nice christmas. Last week i copied and pasted
> css 3 code and now the text structure look like this:
>
> ...
> ....
> ...
> ...
>
> Why copy & paste acts this way? How do i prevent it? And how can i bring the
> structure automaticaly to
> ....
> ....
> ....
> this structure?
:help paste
:help pastetoggle
Elimar
--
Experience is something you don't get until
just after you need 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.
> Hello Folks,
>
> i hope all of you had a very nice christmas. Last week i copied and pasted
> css 3 code and now the text structure look like this:
>
> ...
> ....
> ...
> ...
>
> Why copy & paste acts this way? How do i prevent it? And how can i bring the
> structure automaticaly to
> ....
> ....
> ....
> this structure?
:help paste
:help pastetoggle
Elimar
--
Experience is something you don't get until
just after you need 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: New to vim - c&p ident problem
* evlute <teigmantel123@gmail.com> [2015-12-26 04:12 -0700]:
> Hello Folks,
>
> i hope all of you had a very nice christmas. Last week i copied and pasted
> css 3 code and now the text structure look like this:
>
> ...
> ....
> ...
> ...
>
> Why copy & paste acts this way? How do i prevent it? And how can i bring the
> structure automaticaly to
> ....
> ....
> ....
> this structure?
:help paste
:help pastetoggle
Elimar
--
Experience is something you don't get until
just after you need 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.
> Hello Folks,
>
> i hope all of you had a very nice christmas. Last week i copied and pasted
> css 3 code and now the text structure look like this:
>
> ...
> ....
> ...
> ...
>
> Why copy & paste acts this way? How do i prevent it? And how can i bring the
> structure automaticaly to
> ....
> ....
> ....
> this structure?
:help paste
:help pastetoggle
Elimar
--
Experience is something you don't get until
just after you need 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: New to vim - c&p ident problem
On 15/12/26 04:12, evlute wrote:
>Hello Folks,
>
>i hope all of you had a very nice christmas. Last week i copied and pasted
>css 3 code and now the text structure look like this:
>
>...
> ....
> ...
> ...
>
>Why copy & paste acts this way? How do i prevent it? And how can i bring the
>structure automaticaly to
>....
>....
>....
>this structure?
paste via "+p (or is it "*p - I have those registers synced). That
should work. More about registers see :help registers
Niels
--
--
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 Folks,
>
>i hope all of you had a very nice christmas. Last week i copied and pasted
>css 3 code and now the text structure look like this:
>
>...
> ....
> ...
> ...
>
>Why copy & paste acts this way? How do i prevent it? And how can i bring the
>structure automaticaly to
>....
>....
>....
>this structure?
paste via "+p (or is it "*p - I have those registers synced). That
should work. More about registers see :help registers
Niels
--
--
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: New to vim - c&p ident problem
* evlute <teigmantel123@gmail.com> [2015-12-26 04:12 -0700]:
> Hello Folks,
>
> i hope all of you had a very nice christmas. Last week i copied and pasted
> css 3 code and now the text structure look like this:
>
> ...
> ....
> ...
> ...
>
> Why copy & paste acts this way? How do i prevent it? And how can i bring the
> structure automaticaly to
> ....
> ....
> ....
> this structure?
:help paste
:help pastetoggle
Elimar
--
Experience is something you don't get until
just after you need 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.
> Hello Folks,
>
> i hope all of you had a very nice christmas. Last week i copied and pasted
> css 3 code and now the text structure look like this:
>
> ...
> ....
> ...
> ...
>
> Why copy & paste acts this way? How do i prevent it? And how can i bring the
> structure automaticaly to
> ....
> ....
> ....
> this structure?
:help paste
:help pastetoggle
Elimar
--
Experience is something you don't get until
just after you need 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: New in VIM
On Sat, Dec 26, 2015 at 1:07 PM, janc@telefonica.net
<janc@telefonica.net> wrote:
> Thanks Paolo and Tony for your help.
> I can't find the way to match ~ without errors.
See
:help /\
(which was already mentioned in my previous response)
:help 'magic'
Actually (with 'magic' set, which is the default and the recommended
setting, as the opposite might break some of the plugins included with
Vim), ~ matches the latest subsitute string and \~ matches a tilde.
With 'nomagic', it's the opposite. The same applies to several other
characters which have a special meaning in a pattern when either
preceded or not preceded by a backslash. Now read my previous post
again, including the example functions, which assume that 'magic' is
set.
Also try a plain search — either /~ or /\~ — on (for instance) a helpfile.
Best regards,
Tony.
--
--
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.
<janc@telefonica.net> wrote:
> Thanks Paolo and Tony for your help.
> I can't find the way to match ~ without errors.
See
:help /\
(which was already mentioned in my previous response)
:help 'magic'
Actually (with 'magic' set, which is the default and the recommended
setting, as the opposite might break some of the plugins included with
Vim), ~ matches the latest subsitute string and \~ matches a tilde.
With 'nomagic', it's the opposite. The same applies to several other
characters which have a special meaning in a pattern when either
preceded or not preceded by a backslash. Now read my previous post
again, including the example functions, which assume that 'magic' is
set.
Also try a plain search — either /~ or /\~ — on (for instance) a helpfile.
Best regards,
Tony.
--
--
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: New in VIM
Thanks Paolo and Tony for your help.
I have tried this way maped to F7 so it works comment/uncomment
function Comment()
let currentLine = getline(".")
let result = match(currentLine, "^\#~ ") " here is the problem
if result >= 0
" Uncomment, delete "#~ "
else
" Comment, write "#~ " at ^ of line.
endif
endfunction
The problem is: (from :help /~)
~ matches the last given substitute string */~**/\~*
I can't find the way to match ~ without errors.
This is because I also use Geany, it has comment/uncomment with "#~ " but I
will use only "# " if I can find how to match() it in the current line.
Thanks a lot. Cheers.
--
Jose Angel Navarro Cortes
email: janc@telefonica.net
web: http://janc.es/
Usuario Linux: #49178
El 15.12.26 07:11:52 > Tony Mechelynck dijo:
> Even ^#\~ works for me: the # doesn't need backslash-escaping
>
> Let's say (assuming # is the start-comment delimiter)
>
> function Comment() range
> exe a:firstline ',' a:lastline 's/^\ze\~/#/'
> endfunction
>
> function Uncomment() range
> exe a:firstline ',' a:lastline 's/^#\ze\~//'
> endfunction
>
> Then use these functions by using the :call command with a range (or
> from Visual mode, which will pass '<,'> as the range to execute the
> function on the selected lines). For the whole file, use :%call or
> :1,$call
>
> See
> :help /~
> :help /\
> :help /\ze
> :help :func-range
> :help :call
> :help v_:
> :help :range
>
>
> Best regards,
> Tony.
>
> On Sat, Dec 26, 2015 at 5:54 AM, Paolo Bolzoni
> <paolo.bolzoni.brown@gmail.com> wrote:
> > ^\#\~ works fine to me, what is the problem?
> >
> > On Sat, Dec 26, 2015 at 4:39 AM, janc@telefonica.net
> > <janc@telefonica.net> wrote:
> >> Hi! all.
> >>
> >> I am almost newbie about VIM and every day I like it more and more.
> >>
> >> I am try to make a function to comment/uncomment lines with "#~ " at ^ of line.
> >>
> >> But I can not find the regex to search "#~ " at ^ of line, I think I have tried
> >> almost every posibilities.
> >>
> >> Can you help me? Thank in advanced.
> >>
> >> --
> >> Jose Angel Navarro Cortes
> >> email: janc@telefonica.net
> >> web: http://janc.es/
> >> Usuario Linux: #49178
> >>
> >> --
> >> --
> >> 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.
>
> --
> --
> 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.
I have tried this way maped to F7 so it works comment/uncomment
function Comment()
let currentLine = getline(".")
let result = match(currentLine, "^\#~ ") " here is the problem
if result >= 0
" Uncomment, delete "#~ "
else
" Comment, write "#~ " at ^ of line.
endif
endfunction
The problem is: (from :help /~)
~ matches the last given substitute string */~**/\~*
I can't find the way to match ~ without errors.
This is because I also use Geany, it has comment/uncomment with "#~ " but I
will use only "# " if I can find how to match() it in the current line.
Thanks a lot. Cheers.
--
Jose Angel Navarro Cortes
email: janc@telefonica.net
web: http://janc.es/
Usuario Linux: #49178
El 15.12.26 07:11:52 > Tony Mechelynck dijo:
> Even ^#\~ works for me: the # doesn't need backslash-escaping
>
> Let's say (assuming # is the start-comment delimiter)
>
> function Comment() range
> exe a:firstline ',' a:lastline 's/^\ze\~/#/'
> endfunction
>
> function Uncomment() range
> exe a:firstline ',' a:lastline 's/^#\ze\~//'
> endfunction
>
> Then use these functions by using the :call command with a range (or
> from Visual mode, which will pass '<,'> as the range to execute the
> function on the selected lines). For the whole file, use :%call or
> :1,$call
>
> See
> :help /~
> :help /\
> :help /\ze
> :help :func-range
> :help :call
> :help v_:
> :help :range
>
>
> Best regards,
> Tony.
>
> On Sat, Dec 26, 2015 at 5:54 AM, Paolo Bolzoni
> <paolo.bolzoni.brown@gmail.com> wrote:
> > ^\#\~ works fine to me, what is the problem?
> >
> > On Sat, Dec 26, 2015 at 4:39 AM, janc@telefonica.net
> > <janc@telefonica.net> wrote:
> >> Hi! all.
> >>
> >> I am almost newbie about VIM and every day I like it more and more.
> >>
> >> I am try to make a function to comment/uncomment lines with "#~ " at ^ of line.
> >>
> >> But I can not find the regex to search "#~ " at ^ of line, I think I have tried
> >> almost every posibilities.
> >>
> >> Can you help me? Thank in advanced.
> >>
> >> --
> >> Jose Angel Navarro Cortes
> >> email: janc@telefonica.net
> >> web: http://janc.es/
> >> Usuario Linux: #49178
> >>
> >> --
> >> --
> >> 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.
>
> --
> --
> 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.
New to vim - c&p ident problem
Hello Folks,
i hope all of you had a very nice christmas. Last week i copied and pasted
css 3 code and now the text structure look like this:
...
....
...
...
Why copy & paste acts this way? How do i prevent it? And how can i bring the
structure automaticaly to
....
....
....
this structure?
Regards
evlute
--
View this message in context: http://vim.1045645.n5.nabble.com/New-to-vim-c-p-ident-problem-tp5726514.html
Sent from the Vim - General mailing list archive at Nabble.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.
i hope all of you had a very nice christmas. Last week i copied and pasted
css 3 code and now the text structure look like this:
...
....
...
...
Why copy & paste acts this way? How do i prevent it? And how can i bring the
structure automaticaly to
....
....
....
this structure?
Regards
evlute
--
View this message in context: http://vim.1045645.n5.nabble.com/New-to-vim-c-p-ident-problem-tp5726514.html
Sent from the Vim - General mailing list archive at Nabble.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.
Friday, December 25, 2015
Re: New in VIM
Even ^#\~ works for me: the # doesn't need backslash-escaping
Let's say (assuming # is the start-comment delimiter)
function Comment() range
exe a:firstline ',' a:lastline 's/^\ze\~/#/'
endfunction
function Uncomment() range
exe a:firstline ',' a:lastline 's/^#\ze\~//'
endfunction
Then use these functions by using the :call command with a range (or
from Visual mode, which will pass '<,'> as the range to execute the
function on the selected lines). For the whole file, use :%call or
:1,$call
See
:help /~
:help /\
:help /\ze
:help :func-range
:help :call
:help v_:
:help :range
Best regards,
Tony.
On Sat, Dec 26, 2015 at 5:54 AM, Paolo Bolzoni
<paolo.bolzoni.brown@gmail.com> wrote:
> ^\#\~ works fine to me, what is the problem?
>
> On Sat, Dec 26, 2015 at 4:39 AM, janc@telefonica.net
> <janc@telefonica.net> wrote:
>> Hi! all.
>>
>> I am almost newbie about VIM and every day I like it more and more.
>>
>> I am try to make a function to comment/uncomment lines with "#~ " at ^ of line.
>>
>> But I can not find the regex to search "#~ " at ^ of line, I think I have tried
>> almost every posibilities.
>>
>> Can you help me? Thank in advanced.
>>
>> --
>> Jose Angel Navarro Cortes
>> email: janc@telefonica.net
>> web: http://janc.es/
>> Usuario Linux: #49178
>>
>> --
>> --
>> 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.
--
--
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.
Let's say (assuming # is the start-comment delimiter)
function Comment() range
exe a:firstline ',' a:lastline 's/^\ze\~/#/'
endfunction
function Uncomment() range
exe a:firstline ',' a:lastline 's/^#\ze\~//'
endfunction
Then use these functions by using the :call command with a range (or
from Visual mode, which will pass '<,'> as the range to execute the
function on the selected lines). For the whole file, use :%call or
:1,$call
See
:help /~
:help /\
:help /\ze
:help :func-range
:help :call
:help v_:
:help :range
Best regards,
Tony.
On Sat, Dec 26, 2015 at 5:54 AM, Paolo Bolzoni
<paolo.bolzoni.brown@gmail.com> wrote:
> ^\#\~ works fine to me, what is the problem?
>
> On Sat, Dec 26, 2015 at 4:39 AM, janc@telefonica.net
> <janc@telefonica.net> wrote:
>> Hi! all.
>>
>> I am almost newbie about VIM and every day I like it more and more.
>>
>> I am try to make a function to comment/uncomment lines with "#~ " at ^ of line.
>>
>> But I can not find the regex to search "#~ " at ^ of line, I think I have tried
>> almost every posibilities.
>>
>> Can you help me? Thank in advanced.
>>
>> --
>> Jose Angel Navarro Cortes
>> email: janc@telefonica.net
>> web: http://janc.es/
>> Usuario Linux: #49178
>>
>> --
>> --
>> 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.
--
--
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: New in VIM
^\#\~ works fine to me, what is the problem?
On Sat, Dec 26, 2015 at 4:39 AM, janc@telefonica.net
<janc@telefonica.net> wrote:
> Hi! all.
>
> I am almost newbie about VIM and every day I like it more and more.
>
> I am try to make a function to comment/uncomment lines with "#~ " at ^ of line.
>
> But I can not find the regex to search "#~ " at ^ of line, I think I have tried
> almost every posibilities.
>
> Can you help me? Thank in advanced.
>
> --
> Jose Angel Navarro Cortes
> email: janc@telefonica.net
> web: http://janc.es/
> Usuario Linux: #49178
>
> --
> --
> 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.
On Sat, Dec 26, 2015 at 4:39 AM, janc@telefonica.net
<janc@telefonica.net> wrote:
> Hi! all.
>
> I am almost newbie about VIM and every day I like it more and more.
>
> I am try to make a function to comment/uncomment lines with "#~ " at ^ of line.
>
> But I can not find the regex to search "#~ " at ^ of line, I think I have tried
> almost every posibilities.
>
> Can you help me? Thank in advanced.
>
> --
> Jose Angel Navarro Cortes
> email: janc@telefonica.net
> web: http://janc.es/
> Usuario Linux: #49178
>
> --
> --
> 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.
New in VIM
Hi! all.
I am almost newbie about VIM and every day I like it more and more.
I am try to make a function to comment/uncomment lines with "#~ " at ^ of line.
But I can not find the regex to search "#~ " at ^ of line, I think I have tried
almost every posibilities.
Can you help me? Thank in advanced.
--
Jose Angel Navarro Cortes
email: janc@telefonica.net
web: http://janc.es/
Usuario Linux: #49178
--
--
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 am almost newbie about VIM and every day I like it more and more.
I am try to make a function to comment/uncomment lines with "#~ " at ^ of line.
But I can not find the regex to search "#~ " at ^ of line, I think I have tried
almost every posibilities.
Can you help me? Thank in advanced.
--
Jose Angel Navarro Cortes
email: janc@telefonica.net
web: http://janc.es/
Usuario Linux: #49178
--
--
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.
custom vim setup for C language
Hi. I am a new VIM user, so please, forgive me if this has been already asked.
I need the following custom IDE setup in vim to edit GNU .c files under Linux, so I would appreciate any pointers on how to configure it, or point me to one if it is there any like this available already:
4 windows on the screen
[ w1 ][ w2 ]
------------------
[ ][ ]
[ w3 ][ w4 ]
[ ][ ]
w1 (window1) has to contain the last 10 files opened, the mostly frequent edited file on the top
w2 (window2) has to contain the list of global variables of file currently selected on w1
w3 (window3) has to contain all the functions contained in the file currently selected on window 1
w4 (window4) has to contain the source of the .c file currently selected on w1
click on the global variable on w2 should position the cursor on that variable
click on the function on w3 should position the cursor on the definition of that function
Alt-1,Alt-2,Alt-N to select a file on window1
Thank you very much in advance.
Nulik
--
--
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 need the following custom IDE setup in vim to edit GNU .c files under Linux, so I would appreciate any pointers on how to configure it, or point me to one if it is there any like this available already:
4 windows on the screen
[ w1 ][ w2 ]
------------------
[ ][ ]
[ w3 ][ w4 ]
[ ][ ]
w1 (window1) has to contain the last 10 files opened, the mostly frequent edited file on the top
w2 (window2) has to contain the list of global variables of file currently selected on w1
w3 (window3) has to contain all the functions contained in the file currently selected on window 1
w4 (window4) has to contain the source of the .c file currently selected on w1
click on the global variable on w2 should position the cursor on that variable
click on the function on w3 should position the cursor on the definition of that function
Alt-1,Alt-2,Alt-N to select a file on window1
Thank you very much in advance.
Nulik
--
--
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 double negation in regex
2015-12-25 10:16 GMT+03:00 Chump Ma <chumpma@gmail.com>:
For example,
[[:punct:]]
match punctuations, now I want to match punctuations but not '-', so I try
[^[^[:punct:]\]\-]
and
[^[:punct:]\-]\@!
but neither worked, can someone help?
Use negative look-aheads or look-behinds (AFAIK first is faster):
\%(-\@![[:punct:]]\)
(`\%(\)` is here so that you can work with this construct as one atom: in case you need to e.g. place `*` after it). And I do not see anything double in your request.
--
--
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.