On 29/10/2017 19:45, Dominique Pellé wrote:
> Lifepillar <lifepillar@lifepillar.me> wrote:
>
>> I might be missing something trivial, but I need others's
>> eyes to look at it. Why are these patterns
>>
>> :echo match('x', "[)-~]")
>> :echo match('x', "[(-~]")
>> :echo match('x', "[(->]")
>> :echo match('x', "[)->]")
>>
>> matching? It seems they match any character.
>>
>> Thanks,
>> Life.
>
> When you type something like [0-9] it matches
> any number between 0 and 9. Similarly, when
> you type [)-~] it matches any character between
> ) and ~ (which includes all letters and more).
Ah right, thanks! You know, when you are staring at something
for a while and cannot see the obvious...
Life.
--
--
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, October 29, 2017
Re: Puzzling regexp match
Lifepillar <lifepillar@lifepillar.me> wrote:
> I might be missing something trivial, but I need others's
> eyes to look at it. Why are these patterns
>
> :echo match('x', "[)-~]")
> :echo match('x', "[(-~]")
> :echo match('x', "[(->]")
> :echo match('x', "[)->]")
>
> matching? It seems they match any character.
>
> Thanks,
> Life.
When you type something like [0-9] it matches
any number between 0 and 9. Similarly, when
you type [)-~] it matches any character between
) and ~ (which includes all letters and more).
Regards
Dominique
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> I might be missing something trivial, but I need others's
> eyes to look at it. Why are these patterns
>
> :echo match('x', "[)-~]")
> :echo match('x', "[(-~]")
> :echo match('x', "[(->]")
> :echo match('x', "[)->]")
>
> matching? It seems they match any character.
>
> Thanks,
> Life.
When you type something like [0-9] it matches
any number between 0 and 9. Similarly, when
you type [)-~] it matches any character between
) and ~ (which includes all letters and more).
Regards
Dominique
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Puzzling regexp match
I might be missing something trivial, but I need others's
eyes to look at it. Why are these patterns
:echo match('x', "[)-~]")
:echo match('x', "[(-~]")
:echo match('x', "[(->]")
:echo match('x', "[)->]")
matching? It seems they match any character.
Thanks,
Life.
--
--
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.
eyes to look at it. Why are these patterns
:echo match('x', "[)-~]")
:echo match('x', "[(-~]")
:echo match('x', "[(->]")
:echo match('x', "[)->]")
matching? It seems they match any character.
Thanks,
Life.
--
--
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, October 28, 2017
Re: Varying behaviour when exiting vim depending on filetype (perhaps)
O>
>
>Am 10/27/17 um 19:15 schrieb David Woodfall:
>> … sometimes when I exit I am still at the top of the terminal. Other
>> times vim drops me at the bottom.
>> … My $TERM is screen-256color-bce … setting the term variable …
>> … doesn't seem to make any difference.
>
> I fear, this is really complex. The 'pty' (pseudo tty, abstract
>terminal the window works with) 'sits' between shell+vim and the
>program which shows the characters onscreen. In the special case
>of using 'screen', you even have TWO ptys stacked (one for your
>'display' where you look on 'screen' PLUS one inside 'screen'
>on which the shell+vim work. This makes the switching possible).
>So each of the two steps reacts on the TERM codes and is assumed
>to do exactly the same things.
> Now the 'screen' has TWO scrollbacks to enable exactly what
>you want, one for keeping the screen the shell works on with
>the position and command line, the other for running programs
>(e.g. vim) with random cursor movement on.
>When vim starts, it (normally) switches to the second screen,
>on ending it switches back.
> BUT, if by any means, this switched state is switched back
>by something else while vim runs (other programs running in
>background, hitting ^Z to suspend vim, or running interactive
>programs from inside vim), THEN the state of the normal
>(command line) scrollback changes 'behind' vim and you drop
>to a surprisingly different screen by ending vim. Having so
>many possibilities makes it really hard to find each single
>cause of unwanted changes.
> The seeming dependence on filetype might stem from the
>set of programs you (or vim) use to work with that filetype.
> Even more complex are cases of remote 'screen' (may be even
>on a local 'screen') possibly calling on a xterm:
>$ screen ssh -t SOME_HOST screen
>here you get even more ptys and the remote connection in
>between and you local window in xterm. Each should do/show
>the same, but each level can get out of whack and loose
>the position your terminal falls back to at the end of vim.
> All this did not mention the problem, which begins if
>different ptys/terminal-programs run on different $TERMs.
>The program 'screen' maps the $TERMinal of your window
>(or display) to its own terminal type 'screen-...-bce'
>(so if you work with an 'xterm' or 'gnome-terminal',
>screen remaps the terminfo codes, then runs screens with
>TERM='screen-....' inside.
> NOW this adds the differences in TERMinal definitions into
>the problem's complexity ;-)
>
>Working ~30 years with vi(m), and 'screen' since it exists,
>I saw SO many strange 'messups', that after a while I simply
>begun to ignore it as long as it does not hinder me from
>working ...
>
>Stucki
That is definitely complex :)
Thanks,
Dave
--
--
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.
>
>Am 10/27/17 um 19:15 schrieb David Woodfall:
>> … sometimes when I exit I am still at the top of the terminal. Other
>> times vim drops me at the bottom.
>> … My $TERM is screen-256color-bce … setting the term variable …
>> … doesn't seem to make any difference.
>
> I fear, this is really complex. The 'pty' (pseudo tty, abstract
>terminal the window works with) 'sits' between shell+vim and the
>program which shows the characters onscreen. In the special case
>of using 'screen', you even have TWO ptys stacked (one for your
>'display' where you look on 'screen' PLUS one inside 'screen'
>on which the shell+vim work. This makes the switching possible).
>So each of the two steps reacts on the TERM codes and is assumed
>to do exactly the same things.
> Now the 'screen' has TWO scrollbacks to enable exactly what
>you want, one for keeping the screen the shell works on with
>the position and command line, the other for running programs
>(e.g. vim) with random cursor movement on.
>When vim starts, it (normally) switches to the second screen,
>on ending it switches back.
> BUT, if by any means, this switched state is switched back
>by something else while vim runs (other programs running in
>background, hitting ^Z to suspend vim, or running interactive
>programs from inside vim), THEN the state of the normal
>(command line) scrollback changes 'behind' vim and you drop
>to a surprisingly different screen by ending vim. Having so
>many possibilities makes it really hard to find each single
>cause of unwanted changes.
> The seeming dependence on filetype might stem from the
>set of programs you (or vim) use to work with that filetype.
> Even more complex are cases of remote 'screen' (may be even
>on a local 'screen') possibly calling on a xterm:
>$ screen ssh -t SOME_HOST screen
>here you get even more ptys and the remote connection in
>between and you local window in xterm. Each should do/show
>the same, but each level can get out of whack and loose
>the position your terminal falls back to at the end of vim.
> All this did not mention the problem, which begins if
>different ptys/terminal-programs run on different $TERMs.
>The program 'screen' maps the $TERMinal of your window
>(or display) to its own terminal type 'screen-...-bce'
>(so if you work with an 'xterm' or 'gnome-terminal',
>screen remaps the terminfo codes, then runs screens with
>TERM='screen-....' inside.
> NOW this adds the differences in TERMinal definitions into
>the problem's complexity ;-)
>
>Working ~30 years with vi(m), and 'screen' since it exists,
>I saw SO many strange 'messups', that after a while I simply
>begun to ignore it as long as it does not hinder me from
>working ...
>
>Stucki
That is definitely complex :)
Thanks,
Dave
--
--
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: Varying behaviour when exiting vim depending on filetype (perhaps)
Am 10/27/17 um 19:15 schrieb David Woodfall:
> … sometimes when I exit I am still at the top of the terminal. Other
> times vim drops me at the bottom.
> … My $TERM is screen-256color-bce … setting the term variable …
> … doesn't seem to make any difference.
I fear, this is really complex. The 'pty' (pseudo tty, abstract
terminal the window works with) 'sits' between shell+vim and the
program which shows the characters onscreen. In the special case
of using 'screen', you even have TWO ptys stacked (one for your
'display' where you look on 'screen' PLUS one inside 'screen'
on which the shell+vim work. This makes the switching possible).
So each of the two steps reacts on the TERM codes and is assumed
to do exactly the same things.
Now the 'screen' has TWO scrollbacks to enable exactly what
you want, one for keeping the screen the shell works on with
the position and command line, the other for running programs
(e.g. vim) with random cursor movement on.
When vim starts, it (normally) switches to the second screen,
on ending it switches back.
BUT, if by any means, this switched state is switched back
by something else while vim runs (other programs running in
background, hitting ^Z to suspend vim, or running interactive
programs from inside vim), THEN the state of the normal
(command line) scrollback changes 'behind' vim and you drop
to a surprisingly different screen by ending vim. Having so
many possibilities makes it really hard to find each single
cause of unwanted changes.
The seeming dependence on filetype might stem from the
set of programs you (or vim) use to work with that filetype.
Even more complex are cases of remote 'screen' (may be even
on a local 'screen') possibly calling on a xterm:
$ screen ssh -t SOME_HOST screen
here you get even more ptys and the remote connection in
between and you local window in xterm. Each should do/show
the same, but each level can get out of whack and loose
the position your terminal falls back to at the end of vim.
All this did not mention the problem, which begins if
different ptys/terminal-programs run on different $TERMs.
The program 'screen' maps the $TERMinal of your window
(or display) to its own terminal type 'screen-...-bce'
(so if you work with an 'xterm' or 'gnome-terminal',
screen remaps the terminfo codes, then runs screens with
TERM='screen-....' inside.
NOW this adds the differences in TERMinal definitions into
the problem's complexity ;-)
Working ~30 years with vi(m), and 'screen' since it exists,
I saw SO many strange 'messups', that after a while I simply
begun to ignore it as long as it does not hinder me from
working ...
Stucki
--
--
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.
> … sometimes when I exit I am still at the top of the terminal. Other
> times vim drops me at the bottom.
> … My $TERM is screen-256color-bce … setting the term variable …
> … doesn't seem to make any difference.
I fear, this is really complex. The 'pty' (pseudo tty, abstract
terminal the window works with) 'sits' between shell+vim and the
program which shows the characters onscreen. In the special case
of using 'screen', you even have TWO ptys stacked (one for your
'display' where you look on 'screen' PLUS one inside 'screen'
on which the shell+vim work. This makes the switching possible).
So each of the two steps reacts on the TERM codes and is assumed
to do exactly the same things.
Now the 'screen' has TWO scrollbacks to enable exactly what
you want, one for keeping the screen the shell works on with
the position and command line, the other for running programs
(e.g. vim) with random cursor movement on.
When vim starts, it (normally) switches to the second screen,
on ending it switches back.
BUT, if by any means, this switched state is switched back
by something else while vim runs (other programs running in
background, hitting ^Z to suspend vim, or running interactive
programs from inside vim), THEN the state of the normal
(command line) scrollback changes 'behind' vim and you drop
to a surprisingly different screen by ending vim. Having so
many possibilities makes it really hard to find each single
cause of unwanted changes.
The seeming dependence on filetype might stem from the
set of programs you (or vim) use to work with that filetype.
Even more complex are cases of remote 'screen' (may be even
on a local 'screen') possibly calling on a xterm:
$ screen ssh -t SOME_HOST screen
here you get even more ptys and the remote connection in
between and you local window in xterm. Each should do/show
the same, but each level can get out of whack and loose
the position your terminal falls back to at the end of vim.
All this did not mention the problem, which begins if
different ptys/terminal-programs run on different $TERMs.
The program 'screen' maps the $TERMinal of your window
(or display) to its own terminal type 'screen-...-bce'
(so if you work with an 'xterm' or 'gnome-terminal',
screen remaps the terminfo codes, then runs screens with
TERM='screen-....' inside.
NOW this adds the differences in TERMinal definitions into
the problem's complexity ;-)
Working ~30 years with vi(m), and 'screen' since it exists,
I saw SO many strange 'messups', that after a while I simply
begun to ignore it as long as it does not hinder me from
working ...
Stucki
--
--
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, October 27, 2017
Re: Open terminal at the bottom
On 27/10/2017 03:15 p.m., Bram Moolenaar wrote:
>
> Cesar Romani wrote:
>
>> I'm using vim 8.0.1226 on Windows 7.
>> When I open a terminal with :terminal it usually opens at the top of the
>> window. How can I open it at the bottom?
>
> :bottom terminal
>
> Short:
> :bo ter
>
> (which happens to be the Dutch word for Butter :-)
>
Bedankt Bram en Christian
--
Cesar
--
--
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.
>
> Cesar Romani wrote:
>
>> I'm using vim 8.0.1226 on Windows 7.
>> When I open a terminal with :terminal it usually opens at the top of the
>> window. How can I open it at the bottom?
>
> :bottom terminal
>
> Short:
> :bo ter
>
> (which happens to be the Dutch word for Butter :-)
>
Bedankt Bram en Christian
--
Cesar
--
--
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: Open terminal at the bottom
Cesar Romani wrote:
> I'm using vim 8.0.1226 on Windows 7.
> When I open a terminal with :terminal it usually opens at the top of the
> window. How can I open it at the bottom?
:bottom terminal
Short:
:bo ter
(which happens to be the Dutch word for Butter :-)
--
The war between Emacs and Vi is over. Vi has won with 3 to 1.
http://m.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/030/3044/3044s1.html
/// 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'm using vim 8.0.1226 on Windows 7.
> When I open a terminal with :terminal it usually opens at the top of the
> window. How can I open it at the bottom?
:bottom terminal
Short:
:bo ter
(which happens to be the Dutch word for Butter :-)
--
The war between Emacs and Vi is over. Vi has won with 3 to 1.
http://m.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/030/3044/3044s1.html
/// 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: Open terminal at the bottom
On Fr, 27 Okt 2017, Cesar Romani wrote:
> I'm using vim 8.0.1226 on Windows 7.
> When I open a terminal with :terminal it usually opens at the top of the
> window. How can I open it at the bottom?
:h :botright
Christian
--
Die Arbeit ist ein Vergnügen, das als Widerspiel schlecht anfängt und
dann immer mehr erfreuet und das am Ende gerade zu allen andern
Vergnügen einlädt.
-- 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.
> I'm using vim 8.0.1226 on Windows 7.
> When I open a terminal with :terminal it usually opens at the top of the
> window. How can I open it at the bottom?
:h :botright
Christian
--
Die Arbeit ist ein Vergnügen, das als Widerspiel schlecht anfängt und
dann immer mehr erfreuet und das am Ende gerade zu allen andern
Vergnügen einlädt.
-- 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: Open terminal at the bottom
On 27/10/2017 01:43 p.m., Wolf Bogacz wrote:
> You should investigate help for the window sizing and positions
> settings.
>
> :he terminal
>
> see the paragraphs about settings for t_WP (for postion) and t_WS (for
> size).
There is nothing about t_WP and t_WS under :he terminal
--
--
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 should investigate help for the window sizing and positions
> settings.
>
> :he terminal
>
> see the paragraphs about settings for t_WP (for postion) and t_WS (for
> size).
There is nothing about t_WP and t_WS under :he terminal
--
--
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.
Seemingly random behaviour on exiting vim
If I clear my terminal and run vim, depending on the file I'm editing, when I exit vim I will sometimes be left at the top of the term where I started, or sometimes dropped at the bottom.
My TERM is set to screen-256color-bce. I've tried changng the term variable in .vimrc, but it doesn't seem to make a difference.
Ideally, I'd like to exit vim and be on the next line down from where I started from. Not a real big issue, but I just wondered why it did this and if there is a way to control 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.
My TERM is set to screen-256color-bce. I've tried changng the term variable in .vimrc, but it doesn't seem to make a difference.
Ideally, I'd like to exit vim and be on the next line down from where I started from. Not a real big issue, but I just wondered why it did this and if there is a way to control 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: Open terminal at the bottom
You should investigate help for the window sizing and positions settings.
:he terminal
see the paragraphs about settings for t_WP (for postion) and t_WS (for size).
On Fri, Oct 27, 2017 at 2:33 PM, Cesar Romani <cesar.romani@gmail.com> wrote:
I'm using vim 8.0.1226 on Windows 7.
When I open a terminal with :terminal it usually opens at the top of the
window. How can I open it at the bottom?
Many thanks in advance,
--
Cesar
--
--
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.
Open terminal at the bottom
I'm using vim 8.0.1226 on Windows 7.
When I open a terminal with :terminal it usually opens at the top of the
window. How can I open it at the bottom?
Many thanks in advance,
--
Cesar
--
--
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 I open a terminal with :terminal it usually opens at the top of the
window. How can I open it at the bottom?
Many thanks in advance,
--
Cesar
--
--
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.
Varying behaviour when exiting vim depending on filetype (perhaps)
I've noticed that if I clear my terminal and edit files in vim,
sometimes when I exit I am still at the top of the terminal. Other
times vim drops me at the bottom.
I'm just curious why vim does this? My $TERM is screen-256color-bce.
I've tried setting the term variable in .vimrc but it doesn't seem to
make any difference.
--
--
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.
sometimes when I exit I am still at the top of the terminal. Other
times vim drops me at the bottom.
I'm just curious why vim does this? My $TERM is screen-256color-bce.
I've tried setting the term variable in .vimrc but it doesn't seem to
make any difference.
--
--
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 subscribe vim-subscribe@vim.org for maillist
Oh, Thank you very much.
On Oct 27, 2017 14:34, "Christian Brabandt" <cblists@256bit.org> wrote:
On Do, 26 Okt 2017, Nie Ge wrote:
> Hello, everyone! I want to subscribe vim usage for the maillist. But when I send
> and empty subject and empty content email to vim-subscribe@vim.org, I get reply below:
You are successfully subscribed. Looks like your subscription message
was finally delivered. So it might have been just a temporary problem.
Christian
--
Was man Idee nennt: Das, was immer zur Erscheinung kommt und
daher als Gesetz aller Erscheinungen uns entgegentritt.
-- Goethe, Maximen und Reflektionen, Nr. 1062
--
--
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.
Thursday, October 26, 2017
Re: How to subscribe vim-subscribe@vim.org for maillist
On Do, 26 Okt 2017, Nie Ge wrote:
> Hello, everyone! I want to subscribe vim usage for the maillist. But when I send
> and empty subject and empty content email to vim-subscribe@vim.org, I get reply below:
You are successfully subscribed. Looks like your subscription message
was finally delivered. So it might have been just a temporary problem.
Christian
--
Was man Idee nennt: Das, was immer zur Erscheinung kommt und
daher als Gesetz aller Erscheinungen uns entgegentritt.
-- Goethe, Maximen und Reflektionen, Nr. 1062
--
--
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, everyone! I want to subscribe vim usage for the maillist. But when I send
> and empty subject and empty content email to vim-subscribe@vim.org, I get reply below:
You are successfully subscribed. Looks like your subscription message
was finally delivered. So it might have been just a temporary problem.
Christian
--
Was man Idee nennt: Das, was immer zur Erscheinung kommt und
daher als Gesetz aller Erscheinungen uns entgegentritt.
-- Goethe, Maximen und Reflektionen, Nr. 1062
--
--
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 subscribe vim-subscribe@vim.org for maillist
Hello, everyone! I want to subscribe vim usage for the maillist. But when I send
and empty subject and empty content email to vim-subscribe@vim.org, I get reply below:
>This is the mail system at host jail.42.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<vim_use+subscribe@googlegroups.com> (expanded from <vim-subscribe@vim.org>):
host gmr-smtp-in.l.google.com[64.233.184.14] said: 550-5.7.1 [46.41.23.236
12] Our system has detected that this message is 550-5.7.1 likely
unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1
this message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for
more information. g84si262494lfl.3 - gsmtp (in reply to end of DATA
command)
Final-Recipient: rfc822; vim_use+subscribe@googlegroups.com
Original-Recipient: rfc822;vim-subscribe@vim.org
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmr-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [46.41.23.236 12] Our system has detected
that this message is 550-5.7.1 likely unsolicited mail. To reduce the
amount of spam sent to Gmail, 550-5.7.1 this message has been blocked.
Please visit 550-5.7.1
https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for
more information. g84si262494lfl.3 - gsmtp
---------- 已转发邮件 ----------
From: Nie Ge <genie.6qp@gmail.com>
To: vim-subscribe@vim.org
Cc:
Bcc:
Date: Fri, 27 Oct 2017 13:30:10 +0800
Subject:
I don't know how to subscribe the vim@vim.org, I just want to learn vim and subscribe it with my gmail. So please help me. Thank you.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
and empty subject and empty content email to vim-subscribe@vim.org, I get reply below:
>This is the mail system at host jail.42.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<vim_use+subscribe@googlegroups.com> (expanded from <vim-subscribe@vim.org>):
host gmr-smtp-in.l.google.com[64.233.184.14] said: 550-5.7.1 [46.41.23.236
12] Our system has detected that this message is 550-5.7.1 likely
unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1
this message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for
more information. g84si262494lfl.3 - gsmtp (in reply to end of DATA
command)
Final-Recipient: rfc822; vim_use+subscribe@googlegroups.com
Original-Recipient: rfc822;vim-subscribe@vim.org
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmr-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [46.41.23.236 12] Our system has detected
that this message is 550-5.7.1 likely unsolicited mail. To reduce the
amount of spam sent to Gmail, 550-5.7.1 this message has been blocked.
Please visit 550-5.7.1
https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for
more information. g84si262494lfl.3 - gsmtp
---------- 已转发邮件 ----------
From: Nie Ge <genie.6qp@gmail.com>
To: vim-subscribe@vim.org
Cc:
Bcc:
Date: Fri, 27 Oct 2017 13:30:10 +0800
Subject:
I don't know how to subscribe the vim@vim.org, I just want to learn vim and subscribe it with my gmail. So please help me. Thank you.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: recommendation for a function over the entire buffer
On 2017-10-26 21:12, Jose Caballero wrote:
> Quick question: when using the :g command, can I call a plugin
> function? Like
>
> :g/<pattern>/:call AFunction()
Yes (that 2nd colon is optional). It would require the function to
context-aware with regards to the current line, but otherwise, it
Should Work™. Other than a second :g or :v command, I believe any Ex
command (or chain of "|"-separated commands) can follow
the :g/pattern/ so :call certainly qualifies.
-tim
--
--
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.
> Quick question: when using the :g command, can I call a plugin
> function? Like
>
> :g/<pattern>/:call AFunction()
Yes (that 2nd colon is optional). It would require the function to
context-aware with regards to the current line, but otherwise, it
Should Work™. Other than a second :g or :v command, I believe any Ex
command (or chain of "|"-separated commands) can follow
the :g/pattern/ so :call certainly qualifies.
-tim
--
--
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: recommendation for a function over the entire buffer
2017-10-26 20:24 GMT-04:00 Tim Chase <vim@tim.thechases.com>:
> On 2017-10-26 19:13, Jose Caballero wrote:
>> if I want to write a function that does something after every line
>> matching a given pattern (for example, for every python method
>> definition), what does the community prefer to handle it?
>> Just iteratively?
>
> The pattern you describe matches nigh-exactly the functionality of
> the :g command
>
> :g/^\s*def\>/ACTION
>
> You don't mention *what* you want to do for each of these lines, but
> the ex-mode :g command gives you lots of power. From each of those
> matching lines, you can define a range relative to that line and
> perform any command you want over that range. It could be as simple
> as "append a comment after every function definition":
>
> :g/^\s*def\>/s/$/ # my comment here
>
> or adding a Python docstring underneath it:
>
> :g/^\s*def\>/put='"Docstring here"'
>
> or indent the following line through the next blank line:
>
> :g/^\s*def\>/sil! +,/^\s*$/->
>
> That's the implicit way of writing the clearer
>
> :g/^\s*def\>/sil! .+1,/^\s*$/-1>
>
> It (and its counterpart ":v") is one of the most powerful vim
> commands and I use it nigh-daily.
>
> -tim
>
>
>
Hi Tim,
thanks for the pointer.
Quick question: when using the :g command, can I call a plugin function? Like
:g/<pattern>/:call AFunction()
Well, I think I can investigate that myself :)
Thanks a lot.
Jose
--
--
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 2017-10-26 19:13, Jose Caballero wrote:
>> if I want to write a function that does something after every line
>> matching a given pattern (for example, for every python method
>> definition), what does the community prefer to handle it?
>> Just iteratively?
>
> The pattern you describe matches nigh-exactly the functionality of
> the :g command
>
> :g/^\s*def\>/ACTION
>
> You don't mention *what* you want to do for each of these lines, but
> the ex-mode :g command gives you lots of power. From each of those
> matching lines, you can define a range relative to that line and
> perform any command you want over that range. It could be as simple
> as "append a comment after every function definition":
>
> :g/^\s*def\>/s/$/ # my comment here
>
> or adding a Python docstring underneath it:
>
> :g/^\s*def\>/put='"Docstring here"'
>
> or indent the following line through the next blank line:
>
> :g/^\s*def\>/sil! +,/^\s*$/->
>
> That's the implicit way of writing the clearer
>
> :g/^\s*def\>/sil! .+1,/^\s*$/-1>
>
> It (and its counterpart ":v") is one of the most powerful vim
> commands and I use it nigh-daily.
>
> -tim
>
>
>
Hi Tim,
thanks for the pointer.
Quick question: when using the :g command, can I call a plugin function? Like
:g/<pattern>/:call AFunction()
Well, I think I can investigate that myself :)
Thanks a lot.
Jose
--
--
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: recommendation for a function over the entire buffer
On 2017-10-26 19:13, Jose Caballero wrote:
> if I want to write a function that does something after every line
> matching a given pattern (for example, for every python method
> definition), what does the community prefer to handle it?
> Just iteratively?
The pattern you describe matches nigh-exactly the functionality of
the :g command
:g/^\s*def\>/ACTION
You don't mention *what* you want to do for each of these lines, but
the ex-mode :g command gives you lots of power. From each of those
matching lines, you can define a range relative to that line and
perform any command you want over that range. It could be as simple
as "append a comment after every function definition":
:g/^\s*def\>/s/$/ # my comment here
or adding a Python docstring underneath it:
:g/^\s*def\>/put='"Docstring here"'
or indent the following line through the next blank line:
:g/^\s*def\>/sil! +,/^\s*$/->
That's the implicit way of writing the clearer
:g/^\s*def\>/sil! .+1,/^\s*$/-1>
It (and its counterpart ":v") is one of the most powerful vim
commands and I use it nigh-daily.
-tim
--
--
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.
> if I want to write a function that does something after every line
> matching a given pattern (for example, for every python method
> definition), what does the community prefer to handle it?
> Just iteratively?
The pattern you describe matches nigh-exactly the functionality of
the :g command
:g/^\s*def\>/ACTION
You don't mention *what* you want to do for each of these lines, but
the ex-mode :g command gives you lots of power. From each of those
matching lines, you can define a range relative to that line and
perform any command you want over that range. It could be as simple
as "append a comment after every function definition":
:g/^\s*def\>/s/$/ # my comment here
or adding a Python docstring underneath it:
:g/^\s*def\>/put='"Docstring here"'
or indent the following line through the next blank line:
:g/^\s*def\>/sil! +,/^\s*$/->
That's the implicit way of writing the clearer
:g/^\s*def\>/sil! .+1,/^\s*$/-1>
It (and its counterpart ":v") is one of the most powerful vim
commands and I use it nigh-daily.
-tim
--
--
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.
recommendation for a function over the entire buffer
Hello,
if I want to write a function that does something after every line
matching a given pattern (for example, for every python method
definition), what does the community prefer to handle it?
Just iteratively?
Or with a recursive function where the range changes from call to call?
I am just wondering if there is a favorite way for this type of things...
Cheers,
Jose
--
--
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.
if I want to write a function that does something after every line
matching a given pattern (for example, for every python method
definition), what does the community prefer to handle it?
Just iteratively?
Or with a recursive function where the range changes from call to call?
I am just wondering if there is a favorite way for this type of things...
Cheers,
Jose
--
--
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: Vim startup profiling
Hi,
2017/10/25 Wed 21:28:50 UTC+9 Christian Brabandt wrote:
> Hi Ken,
> I briefly looked at your patch and have some feedback.
>
> On Mi, 25 Okt 2017, Ken Takata wrote:
>
> > Changes are:
> > * Merge the two patches into one.
> > * Update the document.
> > * Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
> > I'm still wondering what is the best name for this variable.
> > * Remove `has('win16')`. Not needed anymore.
> > * Add <silent> to the "Show File Types in Menu" item. Showing the command
> > of this item is not so useful.
>
> +If you want to have all these items already present at startup, add: >
> + :let do_lazyload_menus = 1
>
> I think this variable should either be called `do_no_lazyload_menus` or
> the value should be 0, since by default the menus will be lazy loaded.
Okay, I changed it to `do_no_lazyload_menus`:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/cda66cbfc90b98a5ca6c16229ee129fd448c1bad/improve-loading-menu.vim.patch?fileviewer=file-view-default
Actually, menu.vim only checks the existence of the global variable, the value
is not checked. This is the same as other variable in menu.vim.
> + let n = globpath(&runtimepath, "colors/*.vim")
>
> I think that should be
>
> + let n = globpath(&runtimepath, "colors/*.vim", 1, 1)
>
> So you have a list available already and don't need to split later on
> manually and you probably do want to ignore the suffixes and wildignore
> options, if only the user having set them to bad values.
>
> The same holds for the keymap and compiler runtime files.
It makes the code simpler. Updated.
> + augroup SetupLazyloadMenus
> + au!
> + au CursorHold,CursorHoldI * call <SID>SetupLazyloadMenus() | au! SetupLazyloadMenus
> + augroup END
>
> Is this actually a good idea to delete the augroup from within itself?
Deleting autocommands in the group is a usual usage. The similar usage can be
found in `augroup LoadBufferMenu` in menu.vim. Moreover, just using `au!`
in an augroup is a normal usage. Deleting an autogroup within itself by
`augroup!` doesn't work in contrast. It causes W19 or E936.
Actually, I want to delete the group here...
> BTW: there are many runtime file variables. Perhaps we should start to
> document internal runtime file variables in a help file at a central
> place.
>
> Also I am starting to wonder, whether it would make sense to start using
> a common prefix, so that the names are more consistent and less likely
> to clash with user variables, e.g. something like
> vim_ftplugin_undo
> vim_indent_undo
> vim_menu_init_immediate
Regards,
Ken Takata
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
2017/10/25 Wed 21:28:50 UTC+9 Christian Brabandt wrote:
> Hi Ken,
> I briefly looked at your patch and have some feedback.
>
> On Mi, 25 Okt 2017, Ken Takata wrote:
>
> > Changes are:
> > * Merge the two patches into one.
> > * Update the document.
> > * Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
> > I'm still wondering what is the best name for this variable.
> > * Remove `has('win16')`. Not needed anymore.
> > * Add <silent> to the "Show File Types in Menu" item. Showing the command
> > of this item is not so useful.
>
> +If you want to have all these items already present at startup, add: >
> + :let do_lazyload_menus = 1
>
> I think this variable should either be called `do_no_lazyload_menus` or
> the value should be 0, since by default the menus will be lazy loaded.
Okay, I changed it to `do_no_lazyload_menus`:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/cda66cbfc90b98a5ca6c16229ee129fd448c1bad/improve-loading-menu.vim.patch?fileviewer=file-view-default
Actually, menu.vim only checks the existence of the global variable, the value
is not checked. This is the same as other variable in menu.vim.
> + let n = globpath(&runtimepath, "colors/*.vim")
>
> I think that should be
>
> + let n = globpath(&runtimepath, "colors/*.vim", 1, 1)
>
> So you have a list available already and don't need to split later on
> manually and you probably do want to ignore the suffixes and wildignore
> options, if only the user having set them to bad values.
>
> The same holds for the keymap and compiler runtime files.
It makes the code simpler. Updated.
> + augroup SetupLazyloadMenus
> + au!
> + au CursorHold,CursorHoldI * call <SID>SetupLazyloadMenus() | au! SetupLazyloadMenus
> + augroup END
>
> Is this actually a good idea to delete the augroup from within itself?
Deleting autocommands in the group is a usual usage. The similar usage can be
found in `augroup LoadBufferMenu` in menu.vim. Moreover, just using `au!`
in an augroup is a normal usage. Deleting an autogroup within itself by
`augroup!` doesn't work in contrast. It causes W19 or E936.
Actually, I want to delete the group here...
> BTW: there are many runtime file variables. Perhaps we should start to
> document internal runtime file variables in a help file at a central
> place.
>
> Also I am starting to wonder, whether it would make sense to start using
> a common prefix, so that the names are more consistent and less likely
> to clash with user variables, e.g. something like
> vim_ftplugin_undo
> vim_indent_undo
> vim_menu_init_immediate
Regards,
Ken Takata
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Wednesday, October 25, 2017
Re: ZWNJ (Zero Width Non-Joiner) in Persian
در سهشنبه 24 اکتبر 2017، ساعت 21:38:41 (UTC+3:30)، Hamidreza Jafari نوشته:
> در دوشنبه 23 اکتبر 2017، ساعت 22:48:10 (UTC+3:30)، Bram Moolenaar نوشته:
> > Hamidreza Jafari wrote:
> >
> > > Vim with mlterm is able to process Farsi input except with (some)
> > > special characters such as zero width non-joiner which is becoming a
> > > concern. I observe:
> > >
> > > - if I set keymap to persian-iranian then text entry in Farsi and
> > > driving Vim with commands are seamless because there is no need to
> > > change keyboard language at OS level for commands. Keyboard language
> > > is fix in English. Whenever I start to type for text it automatically
> > > changes to Persian. Problem is I don't find a way to insert the famous
> > > ZWNJ, coincidentally a much used character in Persian and Arabic.
> > >
> > > - if I do not change keymap to Persian, I can achieve similar text
> > > entry capability with the benefit that ZWNJ input is as easy as the
> > > usual: shift + space. It actually shows the codepoint in blue (<c200>)
> > > but viewing from other editor-aware (such as mlterm's cat) it shows
> > > all well done. Now the problem is I should change keyboard language to
> > > English at OS level every time I escape to drive, that is use Vim's
> > > commands for text manipulation, navigation etc. It breaks (or brakes!)
> > > Vim's major usability.
> > >
> > > I checked mlterm's font options (in configuration) but didn't notice a
> > > difference when changing font name etc.
> > >
> > > How do I introduce ZWNJ to the first scenario?
> > >
> > > ZWNJ reference: https://codepoints.net/U+200C
> >
> > There hasn't been much work on Farsi support lately. The Farsi mapping
> > is outdated, doesn't work with utf-8. What I heard was that it's
> > probably best to do something similar to what Arabic support is doing.
> >
> > Anyway, can you type this character with CTRL-V u 200c?
> > If not, maybe we can make CTRL-V switch the input to English, since
> > that makes most sense.
> >
> >
> > --
> > ARTHUR: Shut up! Will you shut up!
> > DENNIS: Ah, now we see the violence inherent in the system.
> > ARTHUR: Shut up!
> > DENNIS: Oh! Come and see the violence inherent in the system!
> > HELP! HELP! I'm being repressed!
> > The Quest for the Holy Grail (Monty Python)
> >
> > /// 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 ///
>
> The signal is reject. It seems not the right tool for now. It will perfect with time when there are more people turning to Linux in Persian for the prime (and sub-prime) computing. Is there a way to have an overview of Vim's development, e.g. subscribe to specific topics?
Subscribed to vim_announce. By vim_use.
--
--
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.
> در دوشنبه 23 اکتبر 2017، ساعت 22:48:10 (UTC+3:30)، Bram Moolenaar نوشته:
> > Hamidreza Jafari wrote:
> >
> > > Vim with mlterm is able to process Farsi input except with (some)
> > > special characters such as zero width non-joiner which is becoming a
> > > concern. I observe:
> > >
> > > - if I set keymap to persian-iranian then text entry in Farsi and
> > > driving Vim with commands are seamless because there is no need to
> > > change keyboard language at OS level for commands. Keyboard language
> > > is fix in English. Whenever I start to type for text it automatically
> > > changes to Persian. Problem is I don't find a way to insert the famous
> > > ZWNJ, coincidentally a much used character in Persian and Arabic.
> > >
> > > - if I do not change keymap to Persian, I can achieve similar text
> > > entry capability with the benefit that ZWNJ input is as easy as the
> > > usual: shift + space. It actually shows the codepoint in blue (<c200>)
> > > but viewing from other editor-aware (such as mlterm's cat) it shows
> > > all well done. Now the problem is I should change keyboard language to
> > > English at OS level every time I escape to drive, that is use Vim's
> > > commands for text manipulation, navigation etc. It breaks (or brakes!)
> > > Vim's major usability.
> > >
> > > I checked mlterm's font options (in configuration) but didn't notice a
> > > difference when changing font name etc.
> > >
> > > How do I introduce ZWNJ to the first scenario?
> > >
> > > ZWNJ reference: https://codepoints.net/U+200C
> >
> > There hasn't been much work on Farsi support lately. The Farsi mapping
> > is outdated, doesn't work with utf-8. What I heard was that it's
> > probably best to do something similar to what Arabic support is doing.
> >
> > Anyway, can you type this character with CTRL-V u 200c?
> > If not, maybe we can make CTRL-V switch the input to English, since
> > that makes most sense.
> >
> >
> > --
> > ARTHUR: Shut up! Will you shut up!
> > DENNIS: Ah, now we see the violence inherent in the system.
> > ARTHUR: Shut up!
> > DENNIS: Oh! Come and see the violence inherent in the system!
> > HELP! HELP! I'm being repressed!
> > The Quest for the Holy Grail (Monty Python)
> >
> > /// 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 ///
>
> The signal is reject. It seems not the right tool for now. It will perfect with time when there are more people turning to Linux in Persian for the prime (and sub-prime) computing. Is there a way to have an overview of Vim's development, e.g. subscribe to specific topics?
Subscribed to vim_announce. By vim_use.
--
--
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: Vim startup profiling
Hi Ken,
I briefly looked at your patch and have some feedback.
On Mi, 25 Okt 2017, Ken Takata wrote:
> Changes are:
> * Merge the two patches into one.
> * Update the document.
> * Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
> I'm still wondering what is the best name for this variable.
> * Remove `has('win16')`. Not needed anymore.
> * Add <silent> to the "Show File Types in Menu" item. Showing the command
> of this item is not so useful.
+If you want to have all these items already present at startup, add: >
+ :let do_lazyload_menus = 1
I think this variable should either be called `do_no_lazyload_menus` or
the value should be 0, since by default the menus will be lazy loaded.
+ let n = globpath(&runtimepath, "colors/*.vim")
I think that should be
+ let n = globpath(&runtimepath, "colors/*.vim", 1, 1)
So you have a list available already and don't need to split later on
manually and you probably do want to ignore the suffixes and wildignore
options, if only the user having set them to bad values.
The same holds for the keymap and compiler runtime files.
+ augroup SetupLazyloadMenus
+ au!
+ au CursorHold,CursorHoldI * call <SID>SetupLazyloadMenus() | au! SetupLazyloadMenus
+ augroup END
Is this actually a good idea to delete the augroup from within itself?
BTW: there are many runtime file variables. Perhaps we should start to
document internal runtime file variables in a help file at a central
place.
Also I am starting to wonder, whether it would make sense to start using
a common prefix, so that the names are more consistent and less likely
to clash with user variables, e.g. something like
vim_ftplugin_undo
vim_indent_undo
vim_menu_init_immediate
Christian
--
Neuer MS-Slogan:
Speicherst Du noch oder fluchst Du schon?
--
--
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 briefly looked at your patch and have some feedback.
On Mi, 25 Okt 2017, Ken Takata wrote:
> Changes are:
> * Merge the two patches into one.
> * Update the document.
> * Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
> I'm still wondering what is the best name for this variable.
> * Remove `has('win16')`. Not needed anymore.
> * Add <silent> to the "Show File Types in Menu" item. Showing the command
> of this item is not so useful.
+If you want to have all these items already present at startup, add: >
+ :let do_lazyload_menus = 1
I think this variable should either be called `do_no_lazyload_menus` or
the value should be 0, since by default the menus will be lazy loaded.
+ let n = globpath(&runtimepath, "colors/*.vim")
I think that should be
+ let n = globpath(&runtimepath, "colors/*.vim", 1, 1)
So you have a list available already and don't need to split later on
manually and you probably do want to ignore the suffixes and wildignore
options, if only the user having set them to bad values.
The same holds for the keymap and compiler runtime files.
+ augroup SetupLazyloadMenus
+ au!
+ au CursorHold,CursorHoldI * call <SID>SetupLazyloadMenus() | au! SetupLazyloadMenus
+ augroup END
Is this actually a good idea to delete the augroup from within itself?
BTW: there are many runtime file variables. Perhaps we should start to
document internal runtime file variables in a help file at a central
place.
Also I am starting to wonder, whether it would make sense to start using
a common prefix, so that the names are more consistent and less likely
to clash with user variables, e.g. something like
vim_ftplugin_undo
vim_indent_undo
vim_menu_init_immediate
Christian
--
Neuer MS-Slogan:
Speicherst Du noch oder fluchst Du schon?
--
--
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: Vim startup profiling
Hi,
2017/10/25 Wed 6:20:09 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> > > > >
> > > > > menu.vim uses `globpath()` to search some kind of files under the
> > > > runtimepath.
> > > > > If you search `globpath` in menu.vim, you may find the following lines:
> > > > >
> > > > > let s:n = globpath(&runtimepath, "colors/*.vim")
> > > > > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > > > > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > > > > let s:n = globpath(&runtimepath, "compiler/*.vim")
> > > > >
> > > > > Color schemes, keymaps, spell files and compiler plugins are searched when
> > > > > menu.vim is loaded.
> > > > > This is why it takes long time to be loaded.
> > > > >
> > > > > Unlike those items, file types are not listed automatically. If a user
> > > > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > > > If we use a similar way for color schemes etc., the startup time would be
> > > > > reduced.
> > > >
> > > > I wrote a patch for reduce the loading the of menu.vim by skip using
> > > > globpath().
> > > >
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
> > > >
> > > > Instead of searching colors/*.vim and other files, the following menuitems are
> > > > added in the menu:
> > > >
> > > > Edit > Show Color Schemes in Menu
> > > > Edit > Show Keymaps in Menu
> > > > Tools > Show Compiler Settings in Menu
> > > >
> > > > If these menuitems are selected, all available colorschemes etc. are shown
> > > > in the menu. If a user want to load them at startup, the following line
> > > > can be added in .vimrc:
> > > > :let do_globpath_menus = 1
> > > > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > > >
> > > >
> > > > In my environment, the loading time of menu.vim is:
> > > > Without this patch: 30 - 50 ms
> > > > Skip using globpath: 15 - 20 ms
> > >
> > > Not a very big difference. But still worth it if you never use those
> > > menus.
> > >
> > > I wonder if we can do this lazily. Thus fill in the missing entries
> > > when we start waiting for the user to type. Should be around the same
> > > place where timers may be triggered. Not sure if we can do it with an
> > > actual timer from the menu.vim script though. Might need a special kind
> > > of timer. Perhaps an "idle timer"?
> >
> > How about this additional patch, then?
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default&fileviewer=file-view-default
> >
> > This uses CursorHold to load the menuitems when idle.
>
> I like the idea. I'll wait for a few people to try it out.
I have updated the patches:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/c58b17bb22261436910d77dcda76409edd962ad5/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
Changes are:
* Merge the two patches into one.
* Update the document.
* Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
I'm still wondering what is the best name for this variable.
* Remove `has('win16')`. Not needed anymore.
* Add <silent> to the "Show File Types in Menu" item. Showing the command
of this item is not so useful.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
2017/10/25 Wed 6:20:09 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> > > > >
> > > > > menu.vim uses `globpath()` to search some kind of files under the
> > > > runtimepath.
> > > > > If you search `globpath` in menu.vim, you may find the following lines:
> > > > >
> > > > > let s:n = globpath(&runtimepath, "colors/*.vim")
> > > > > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > > > > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > > > > let s:n = globpath(&runtimepath, "compiler/*.vim")
> > > > >
> > > > > Color schemes, keymaps, spell files and compiler plugins are searched when
> > > > > menu.vim is loaded.
> > > > > This is why it takes long time to be loaded.
> > > > >
> > > > > Unlike those items, file types are not listed automatically. If a user
> > > > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > > > If we use a similar way for color schemes etc., the startup time would be
> > > > > reduced.
> > > >
> > > > I wrote a patch for reduce the loading the of menu.vim by skip using
> > > > globpath().
> > > >
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
> > > >
> > > > Instead of searching colors/*.vim and other files, the following menuitems are
> > > > added in the menu:
> > > >
> > > > Edit > Show Color Schemes in Menu
> > > > Edit > Show Keymaps in Menu
> > > > Tools > Show Compiler Settings in Menu
> > > >
> > > > If these menuitems are selected, all available colorschemes etc. are shown
> > > > in the menu. If a user want to load them at startup, the following line
> > > > can be added in .vimrc:
> > > > :let do_globpath_menus = 1
> > > > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > > >
> > > >
> > > > In my environment, the loading time of menu.vim is:
> > > > Without this patch: 30 - 50 ms
> > > > Skip using globpath: 15 - 20 ms
> > >
> > > Not a very big difference. But still worth it if you never use those
> > > menus.
> > >
> > > I wonder if we can do this lazily. Thus fill in the missing entries
> > > when we start waiting for the user to type. Should be around the same
> > > place where timers may be triggered. Not sure if we can do it with an
> > > actual timer from the menu.vim script though. Might need a special kind
> > > of timer. Perhaps an "idle timer"?
> >
> > How about this additional patch, then?
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default&fileviewer=file-view-default
> >
> > This uses CursorHold to load the menuitems when idle.
>
> I like the idea. I'll wait for a few people to try it out.
I have updated the patches:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/c58b17bb22261436910d77dcda76409edd962ad5/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
Changes are:
* Merge the two patches into one.
* Update the document.
* Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
I'm still wondering what is the best name for this variable.
* Remove `has('win16')`. Not needed anymore.
* Add <silent> to the "Show File Types in Menu" item. Showing the command
of this item is not so useful.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Tuesday, October 24, 2017
Re: Vim startup profiling
Ken Takata wrote:
> > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> > > >
> > > > menu.vim uses `globpath()` to search some kind of files under the
> > > runtimepath.
> > > > If you search `globpath` in menu.vim, you may find the following lines:
> > > >
> > > > let s:n = globpath(&runtimepath, "colors/*.vim")
> > > > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > > > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > > > let s:n = globpath(&runtimepath, "compiler/*.vim")
> > > >
> > > > Color schemes, keymaps, spell files and compiler plugins are searched when
> > > > menu.vim is loaded.
> > > > This is why it takes long time to be loaded.
> > > >
> > > > Unlike those items, file types are not listed automatically. If a user
> > > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > > If we use a similar way for color schemes etc., the startup time would be
> > > > reduced.
> > >
> > > I wrote a patch for reduce the loading the of menu.vim by skip using
> > > globpath().
> > >
> > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
> > >
> > > Instead of searching colors/*.vim and other files, the following menuitems are
> > > added in the menu:
> > >
> > > Edit > Show Color Schemes in Menu
> > > Edit > Show Keymaps in Menu
> > > Tools > Show Compiler Settings in Menu
> > >
> > > If these menuitems are selected, all available colorschemes etc. are shown
> > > in the menu. If a user want to load them at startup, the following line
> > > can be added in .vimrc:
> > > :let do_globpath_menus = 1
> > > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > >
> > >
> > > In my environment, the loading time of menu.vim is:
> > > Without this patch: 30 - 50 ms
> > > Skip using globpath: 15 - 20 ms
> >
> > Not a very big difference. But still worth it if you never use those
> > menus.
> >
> > I wonder if we can do this lazily. Thus fill in the missing entries
> > when we start waiting for the user to type. Should be around the same
> > place where timers may be triggered. Not sure if we can do it with an
> > actual timer from the menu.vim script though. Might need a special kind
> > of timer. Perhaps an "idle timer"?
>
> How about this additional patch, then?
> https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default&fileviewer=file-view-default
>
> This uses CursorHold to load the menuitems when idle.
I like the idea. I'll wait for a few people to try it out.
--
Trees moving back and forth is what makes the wind blow.
/// 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.
> > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> > > >
> > > > menu.vim uses `globpath()` to search some kind of files under the
> > > runtimepath.
> > > > If you search `globpath` in menu.vim, you may find the following lines:
> > > >
> > > > let s:n = globpath(&runtimepath, "colors/*.vim")
> > > > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > > > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > > > let s:n = globpath(&runtimepath, "compiler/*.vim")
> > > >
> > > > Color schemes, keymaps, spell files and compiler plugins are searched when
> > > > menu.vim is loaded.
> > > > This is why it takes long time to be loaded.
> > > >
> > > > Unlike those items, file types are not listed automatically. If a user
> > > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > > If we use a similar way for color schemes etc., the startup time would be
> > > > reduced.
> > >
> > > I wrote a patch for reduce the loading the of menu.vim by skip using
> > > globpath().
> > >
> > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
> > >
> > > Instead of searching colors/*.vim and other files, the following menuitems are
> > > added in the menu:
> > >
> > > Edit > Show Color Schemes in Menu
> > > Edit > Show Keymaps in Menu
> > > Tools > Show Compiler Settings in Menu
> > >
> > > If these menuitems are selected, all available colorschemes etc. are shown
> > > in the menu. If a user want to load them at startup, the following line
> > > can be added in .vimrc:
> > > :let do_globpath_menus = 1
> > > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > >
> > >
> > > In my environment, the loading time of menu.vim is:
> > > Without this patch: 30 - 50 ms
> > > Skip using globpath: 15 - 20 ms
> >
> > Not a very big difference. But still worth it if you never use those
> > menus.
> >
> > I wonder if we can do this lazily. Thus fill in the missing entries
> > when we start waiting for the user to type. Should be around the same
> > place where timers may be triggered. Not sure if we can do it with an
> > actual timer from the menu.vim script though. Might need a special kind
> > of timer. Perhaps an "idle timer"?
>
> How about this additional patch, then?
> https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default&fileviewer=file-view-default
>
> This uses CursorHold to load the menuitems when idle.
I like the idea. I'll wait for a few people to try it out.
--
Trees moving back and forth is what makes the wind blow.
/// 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: Insert space before last character
Thanks Tim and Edwin for quick reply
--
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.
Much appreciated
Adrian
On Tuesday, October 24, 2017, Tim Chase <vim@tim.thechases.com> wrote:
-- On Tuesday, October 24, 2017, Tim Chase <vim@tim.thechases.com> wrote:
On 2017-10-24 12:58, Adrian Johnson wrote:
> I am trying to insert space after first character in a line and a
> space before last character in same line using command mode. I could
> introduce space before first character but could not insert space
> before last character.
>
>
> F783S
> Y625D
> A1705V
>
> :%s//\(^.\)/\1 /g results in
>
> F 783S
> Y 625D
> A 1705V
>
>
> now I want to give space before last character to get following:
>
> F 783 S
> Y 625 D
> A 1705 V
>
> I tried different ways and could not introduce space. I am
> successful in remove the last character. Could anyone help please.
You can do
:%s/.$/ &/
which will add a space before the last character. If there's
trailing whitespace, you may have to tweak it:
:%s/\S\s*$/ &/
In the future, you can do both in one pass by capturing the parts you
want and reassembling them:
:%s/\(.\)\(.*\)\(.\)/\1 \2 \3/
Hope this helps,
-tim
--
--
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: ZWNJ (Zero Width Non-Joiner) in Persian
در دوشنبه 23 اکتبر 2017، ساعت 22:48:10 (UTC+3:30)، Bram Moolenaar نوشته:
> Hamidreza Jafari wrote:
>
> > Vim with mlterm is able to process Farsi input except with (some)
> > special characters such as zero width non-joiner which is becoming a
> > concern. I observe:
> >
> > - if I set keymap to persian-iranian then text entry in Farsi and
> > driving Vim with commands are seamless because there is no need to
> > change keyboard language at OS level for commands. Keyboard language
> > is fix in English. Whenever I start to type for text it automatically
> > changes to Persian. Problem is I don't find a way to insert the famous
> > ZWNJ, coincidentally a much used character in Persian and Arabic.
> >
> > - if I do not change keymap to Persian, I can achieve similar text
> > entry capability with the benefit that ZWNJ input is as easy as the
> > usual: shift + space. It actually shows the codepoint in blue (<c200>)
> > but viewing from other editor-aware (such as mlterm's cat) it shows
> > all well done. Now the problem is I should change keyboard language to
> > English at OS level every time I escape to drive, that is use Vim's
> > commands for text manipulation, navigation etc. It breaks (or brakes!)
> > Vim's major usability.
> >
> > I checked mlterm's font options (in configuration) but didn't notice a
> > difference when changing font name etc.
> >
> > How do I introduce ZWNJ to the first scenario?
> >
> > ZWNJ reference: https://codepoints.net/U+200C
>
> There hasn't been much work on Farsi support lately. The Farsi mapping
> is outdated, doesn't work with utf-8. What I heard was that it's
> probably best to do something similar to what Arabic support is doing.
>
> Anyway, can you type this character with CTRL-V u 200c?
> If not, maybe we can make CTRL-V switch the input to English, since
> that makes most sense.
>
>
> --
> ARTHUR: Shut up! Will you shut up!
> DENNIS: Ah, now we see the violence inherent in the system.
> ARTHUR: Shut up!
> DENNIS: Oh! Come and see the violence inherent in the system!
> HELP! HELP! I'm being repressed!
> The Quest for the Holy Grail (Monty Python)
>
> /// 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 ///
The signal is reject. It seems not the right tool for now. It will perfect with time when there are more people turning to Linux in Persian for the prime (and sub-prime) computing. Is there a way to have an overview of Vim's development, e.g. subscribe to specific topics?
--
--
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.
> Hamidreza Jafari wrote:
>
> > Vim with mlterm is able to process Farsi input except with (some)
> > special characters such as zero width non-joiner which is becoming a
> > concern. I observe:
> >
> > - if I set keymap to persian-iranian then text entry in Farsi and
> > driving Vim with commands are seamless because there is no need to
> > change keyboard language at OS level for commands. Keyboard language
> > is fix in English. Whenever I start to type for text it automatically
> > changes to Persian. Problem is I don't find a way to insert the famous
> > ZWNJ, coincidentally a much used character in Persian and Arabic.
> >
> > - if I do not change keymap to Persian, I can achieve similar text
> > entry capability with the benefit that ZWNJ input is as easy as the
> > usual: shift + space. It actually shows the codepoint in blue (<c200>)
> > but viewing from other editor-aware (such as mlterm's cat) it shows
> > all well done. Now the problem is I should change keyboard language to
> > English at OS level every time I escape to drive, that is use Vim's
> > commands for text manipulation, navigation etc. It breaks (or brakes!)
> > Vim's major usability.
> >
> > I checked mlterm's font options (in configuration) but didn't notice a
> > difference when changing font name etc.
> >
> > How do I introduce ZWNJ to the first scenario?
> >
> > ZWNJ reference: https://codepoints.net/U+200C
>
> There hasn't been much work on Farsi support lately. The Farsi mapping
> is outdated, doesn't work with utf-8. What I heard was that it's
> probably best to do something similar to what Arabic support is doing.
>
> Anyway, can you type this character with CTRL-V u 200c?
> If not, maybe we can make CTRL-V switch the input to English, since
> that makes most sense.
>
>
> --
> ARTHUR: Shut up! Will you shut up!
> DENNIS: Ah, now we see the violence inherent in the system.
> ARTHUR: Shut up!
> DENNIS: Oh! Come and see the violence inherent in the system!
> HELP! HELP! I'm being repressed!
> The Quest for the Holy Grail (Monty Python)
>
> /// 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 ///
The signal is reject. It seems not the right tool for now. It will perfect with time when there are more people turning to Linux in Persian for the prime (and sub-prime) computing. Is there a way to have an overview of Vim's development, e.g. subscribe to specific topics?
--
--
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: Insert space before last character
On 2017-10-24 12:58, Adrian Johnson wrote:
> I am trying to insert space after first character in a line and a
> space before last character in same line using command mode. I could
> introduce space before first character but could not insert space
> before last character.
>
>
> F783S
> Y625D
> A1705V
>
> :%s//\(^.\)/\1 /g results in
>
> F 783S
> Y 625D
> A 1705V
>
>
> now I want to give space before last character to get following:
>
> F 783 S
> Y 625 D
> A 1705 V
>
> I tried different ways and could not introduce space. I am
> successful in remove the last character. Could anyone help please.
You can do
:%s/.$/ &/
which will add a space before the last character. If there's
trailing whitespace, you may have to tweak it:
:%s/\S\s*$/ &/
In the future, you can do both in one pass by capturing the parts you
want and reassembling them:
:%s/\(.\)\(.*\)\(.\)/\1 \2 \3/
Hope this helps,
-tim
--
--
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 trying to insert space after first character in a line and a
> space before last character in same line using command mode. I could
> introduce space before first character but could not insert space
> before last character.
>
>
> F783S
> Y625D
> A1705V
>
> :%s//\(^.\)/\1 /g results in
>
> F 783S
> Y 625D
> A 1705V
>
>
> now I want to give space before last character to get following:
>
> F 783 S
> Y 625 D
> A 1705 V
>
> I tried different ways and could not introduce space. I am
> successful in remove the last character. Could anyone help please.
You can do
:%s/.$/ &/
which will add a space before the last character. If there's
trailing whitespace, you may have to tweak it:
:%s/\S\s*$/ &/
In the future, you can do both in one pass by capturing the parts you
want and reassembling them:
:%s/\(.\)\(.*\)\(.\)/\1 \2 \3/
Hope this helps,
-tim
--
--
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: Insert space before last character
Hello Adrian,
This should work:
:%s#\(.*\)\(.\)#\1 \2
Like in your solution \( \) is defined to use \1 and \2 in the substitution.
Hope this works fine,
regards
Edwin
Am 24.10.2017 um 18:58 schrieb Adrian Johnson:
> Dear group:
>
> I am trying to insert space after first character in a line and a
> space before last character in same line using command mode. I could
> introduce space before first character but could not insert space
> before last character.
>
>
> F783S
> Y625D
> A1705V
>
> :%s//\(^.\)/\1 /g results in
>
> F 783S
> Y 625D
> A 1705V
>
>
> now I want to give space before last character to get following:
>
> F 783 S
> Y 625 D
> A 1705 V
>
> I tried different ways and could not introduce space. I am successful
> in remove the last character. Could anyone help please.
>
>
> Thanks
> Adrian
>
--
--
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.
This should work:
:%s#\(.*\)\(.\)#\1 \2
Like in your solution \( \) is defined to use \1 and \2 in the substitution.
Hope this works fine,
regards
Edwin
Am 24.10.2017 um 18:58 schrieb Adrian Johnson:
> Dear group:
>
> I am trying to insert space after first character in a line and a
> space before last character in same line using command mode. I could
> introduce space before first character but could not insert space
> before last character.
>
>
> F783S
> Y625D
> A1705V
>
> :%s//\(^.\)/\1 /g results in
>
> F 783S
> Y 625D
> A 1705V
>
>
> now I want to give space before last character to get following:
>
> F 783 S
> Y 625 D
> A 1705 V
>
> I tried different ways and could not introduce space. I am successful
> in remove the last character. Could anyone help please.
>
>
> Thanks
> Adrian
>
--
--
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.
Insert space before last character
Dear group:
I am trying to insert space after first character in a line and a
space before last character in same line using command mode. I could
introduce space before first character but could not insert space
before last character.
F783S
Y625D
A1705V
:%s//\(^.\)/\1 /g results in
F 783S
Y 625D
A 1705V
now I want to give space before last character to get following:
F 783 S
Y 625 D
A 1705 V
I tried different ways and could not introduce space. I am successful
in remove the last character. Could anyone help please.
Thanks
Adrian
--
--
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 trying to insert space after first character in a line and a
space before last character in same line using command mode. I could
introduce space before first character but could not insert space
before last character.
F783S
Y625D
A1705V
:%s//\(^.\)/\1 /g results in
F 783S
Y 625D
A 1705V
now I want to give space before last character to get following:
F 783 S
Y 625 D
A 1705 V
I tried different ways and could not introduce space. I am successful
in remove the last character. Could anyone help please.
Thanks
Adrian
--
--
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: Vim startup profiling
Hi Bram,
2017/10/24 Tue 5:45:40 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> > >
> > > menu.vim uses `globpath()` to search some kind of files under the
> > runtimepath.
> > > If you search `globpath` in menu.vim, you may find the following lines:
> > >
> > > let s:n = globpath(&runtimepath, "colors/*.vim")
> > > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > > let s:n = globpath(&runtimepath, "compiler/*.vim")
> > >
> > > Color schemes, keymaps, spell files and compiler plugins are searched when
> > > menu.vim is loaded.
> > > This is why it takes long time to be loaded.
> > >
> > > Unlike those items, file types are not listed automatically. If a user
> > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > If we use a similar way for color schemes etc., the startup time would be
> > > reduced.
> >
> > I wrote a patch for reduce the loading the of menu.vim by skip using
> > globpath().
> >
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
> >
> > Instead of searching colors/*.vim and other files, the following menuitems are
> > added in the menu:
> >
> > Edit > Show Color Schemes in Menu
> > Edit > Show Keymaps in Menu
> > Tools > Show Compiler Settings in Menu
> >
> > If these menuitems are selected, all available colorschemes etc. are shown
> > in the menu. If a user want to load them at startup, the following line
> > can be added in .vimrc:
> > :let do_globpath_menus = 1
> > (This is similar to `:let do_syntax_sel_menu = 1`.)
> >
> >
> > In my environment, the loading time of menu.vim is:
> > Without this patch: 30 - 50 ms
> > Skip using globpath: 15 - 20 ms
>
> Not a very big difference. But still worth it if you never use those
> menus.
>
> I wonder if we can do this lazily. Thus fill in the missing entries
> when we start waiting for the user to type. Should be around the same
> place where timers may be triggered. Not sure if we can do it with an
> actual timer from the menu.vim script though. Might need a special kind
> of timer. Perhaps an "idle timer"?
How about this additional patch, then?
https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default&fileviewer=file-view-default
This uses CursorHold to load the menuitems when idle.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
2017/10/24 Tue 5:45:40 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> > >
> > > menu.vim uses `globpath()` to search some kind of files under the
> > runtimepath.
> > > If you search `globpath` in menu.vim, you may find the following lines:
> > >
> > > let s:n = globpath(&runtimepath, "colors/*.vim")
> > > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > > let s:n = globpath(&runtimepath, "compiler/*.vim")
> > >
> > > Color schemes, keymaps, spell files and compiler plugins are searched when
> > > menu.vim is loaded.
> > > This is why it takes long time to be loaded.
> > >
> > > Unlike those items, file types are not listed automatically. If a user
> > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > If we use a similar way for color schemes etc., the startup time would be
> > > reduced.
> >
> > I wrote a patch for reduce the loading the of menu.vim by skip using
> > globpath().
> >
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
> >
> > Instead of searching colors/*.vim and other files, the following menuitems are
> > added in the menu:
> >
> > Edit > Show Color Schemes in Menu
> > Edit > Show Keymaps in Menu
> > Tools > Show Compiler Settings in Menu
> >
> > If these menuitems are selected, all available colorschemes etc. are shown
> > in the menu. If a user want to load them at startup, the following line
> > can be added in .vimrc:
> > :let do_globpath_menus = 1
> > (This is similar to `:let do_syntax_sel_menu = 1`.)
> >
> >
> > In my environment, the loading time of menu.vim is:
> > Without this patch: 30 - 50 ms
> > Skip using globpath: 15 - 20 ms
>
> Not a very big difference. But still worth it if you never use those
> menus.
>
> I wonder if we can do this lazily. Thus fill in the missing entries
> when we start waiting for the user to type. Should be around the same
> place where timers may be triggered. Not sure if we can do it with an
> actual timer from the menu.vim script though. Might need a special kind
> of timer. Perhaps an "idle timer"?
How about this additional patch, then?
https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default&fileviewer=file-view-default
This uses CursorHold to load the menuitems when idle.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Monday, October 23, 2017
Re: How to handle non-ascii characters?
Barry Gold wrote:
You wrote:
> I'm impressed that you can type your entire vimrc from memory. I'm
> tempted to use some of that. If only I _understood_ it.
Well the normal stuff that applies globablly. Stuff for specific classes
of files is a bit more difficult. :^) It's basically these three maps
and some :set options.
>> " Use * to "run" a line from the edit buffer
>> " Mnemonic: * is executible in "ls -F"
>> " Uses register y
>> :map * "yyy@y
:map begin a key remap
* remap key "*"
"y into register y
yy yank the current line
@y execute the commands in register y
The beauty of this one is the ability to compose complex commands
(typically ":g/select/ s/this/that/" type stuff for me) and then
being able to 'u'ndo and fix the command if I don't get it right
the first time. It also is useful to keep commands in comments of
code.
>> " Find previous space and split line on it
>> " Mnemonic: 'S'pace
>> :map S F r<CR>
:map begin a key remap
S remap key "S"
F ("F ") find previous " " on current line
r<CR> replace that space with carriage return
>> " Double the character under the cursor
>> " Mnemonic: fix C code like "if (0 = i) ..."
>> :map = y p
:map begin a key remap
= remap key "="
y ("y ") yank character under cursor
o put last yank
I remember learning a lot of vi tricks from comp.editors from people
doing things like the above breakdown. Approximately no one reads or
posts there any more.
Elijah
--
--
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 wrote:
> I'm impressed that you can type your entire vimrc from memory. I'm
> tempted to use some of that. If only I _understood_ it.
Well the normal stuff that applies globablly. Stuff for specific classes
of files is a bit more difficult. :^) It's basically these three maps
and some :set options.
>> " Use * to "run" a line from the edit buffer
>> " Mnemonic: * is executible in "ls -F"
>> " Uses register y
>> :map * "yyy@y
:map begin a key remap
* remap key "*"
"y into register y
yy yank the current line
@y execute the commands in register y
The beauty of this one is the ability to compose complex commands
(typically ":g/select/ s/this/that/" type stuff for me) and then
being able to 'u'ndo and fix the command if I don't get it right
the first time. It also is useful to keep commands in comments of
code.
>> " Find previous space and split line on it
>> " Mnemonic: 'S'pace
>> :map S F r<CR>
:map begin a key remap
S remap key "S"
F ("F ") find previous " " on current line
r<CR> replace that space with carriage return
>> " Double the character under the cursor
>> " Mnemonic: fix C code like "if (0 = i) ..."
>> :map = y p
:map begin a key remap
= remap key "="
y ("y ") yank character under cursor
o put last yank
I remember learning a lot of vi tricks from comp.editors from people
doing things like the above breakdown. Approximately no one reads or
posts there any more.
Elijah
--
--
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 handle non-ascii characters?
On 10/23/2017 1:50 PM, Eli the Bearded wrote:
> Barry Gold wrote:
>> None of these looks like themselves when I edit the file with vim in a
>> cygwin Terminal window. I can search for [^ -~^t] to find the non-ASCII
>> characters, then go to the original word document to find out what the
>> correct character is. If I had only a few of these, that would be
>> enough. But in a longer document, a given non-ASCII can occur hundreds
>> of times. So once I've found (e.g.) an emdash, I want to replace _all_
>> occurrences with "—". But I have no way of representing the
>> character I want to replace on the command line.
> I have a very similar problem to yours and have evolved some fixes that
> I use. You've already gotten some replies, but maybe my methods would
> help, too.
>
> In my case, I paste content from web pages into Usenet posts and want to
> have as much US-ASCII as possible for best readibility. To that end I
> have a specific vimrc for news that fixes things with map!s. It could
> easily be modified to a ':so script' usage, to fix things on command
> or a 'autocmd BufRead *.html' script to fix thins on load.
>
> In my vimrc:
>
> autocmd BufRead .article.* :so ~eli/.news_vimrc
>
> And my news_vimrc looks like this:
>
> :r! cat ~/.news_vimrc | mmencode -q
> " smart quotes
> map! =E2=80=99 '
> map! =E2=80=98 '
> map! =E2=80=9C "
> map! =E2=80=9D "
> map! =E2=80=B3 "
> " ellipsis
> map! =E2=80=A6 ...
> " n-dash
> map! =E2=80=93 --
> " m-dash
> map! =E2=80=94 --
> " U+2212 minus
> map! =E2=88=92 -
> " U+2010 hyphen
> map! =E2=80=90 -
> "
> " find non-ascii
> map <F5> /[^ -~]<cr>
> " add mime headers if leaving in non-ascii
> map <F6> iContent-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
> 0<cr><esc>
> map! <F6> Content-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
> 0<cr>
> " general news settings
> set ai sw=3D4 tw=3D72
>
> Basically, I'm suggesting that you take all the charcters you find and
> want to replace, and save the replacements in a script you can run
> easily before looking for new characters that you want to fix.
>
> I use http://qaz.wtf/u/ "Show unicode character" if needed to identify
> characters, the plugin might suit you better.
>
> And I have a long-standing macro:
>
> " Use * to "run" a line from the edit buffer
> " Mnemonic: * is executible in "ls -F"
> " Uses register y
> :map * "yyy@y
>
> If I were you, I would make the commands, test them with *, then 'p'ut
> them in the fix script.
>
> That * command is one of three macros I consider essential. The other
> two I think are less likely to be universally useful, but anyway:
>
> " Find previous space and split line on it
> " Mnemonic: 'S'pace
> :map S F r<CR>
> "
> " Double the character under the cursor
> " Mnemonic: fix C code like "if (0 = i) ..."
> :map = y p
>
I'm impressed that you can type your entire vimrc from memory. I'm
tempted to use some of that. If only I _understood_ it.
--
On Beta, we'd have earrings for that. You could buy them in any jewelry store.
http://www.conchord.org/xeno/bdgsig.html
--
--
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.
> Barry Gold wrote:
>> None of these looks like themselves when I edit the file with vim in a
>> cygwin Terminal window. I can search for [^ -~^t] to find the non-ASCII
>> characters, then go to the original word document to find out what the
>> correct character is. If I had only a few of these, that would be
>> enough. But in a longer document, a given non-ASCII can occur hundreds
>> of times. So once I've found (e.g.) an emdash, I want to replace _all_
>> occurrences with "—". But I have no way of representing the
>> character I want to replace on the command line.
> I have a very similar problem to yours and have evolved some fixes that
> I use. You've already gotten some replies, but maybe my methods would
> help, too.
>
> In my case, I paste content from web pages into Usenet posts and want to
> have as much US-ASCII as possible for best readibility. To that end I
> have a specific vimrc for news that fixes things with map!s. It could
> easily be modified to a ':so script' usage, to fix things on command
> or a 'autocmd BufRead *.html' script to fix thins on load.
>
> In my vimrc:
>
> autocmd BufRead .article.* :so ~eli/.news_vimrc
>
> And my news_vimrc looks like this:
>
> :r! cat ~/.news_vimrc | mmencode -q
> " smart quotes
> map! =E2=80=99 '
> map! =E2=80=98 '
> map! =E2=80=9C "
> map! =E2=80=9D "
> map! =E2=80=B3 "
> " ellipsis
> map! =E2=80=A6 ...
> " n-dash
> map! =E2=80=93 --
> " m-dash
> map! =E2=80=94 --
> " U+2212 minus
> map! =E2=88=92 -
> " U+2010 hyphen
> map! =E2=80=90 -
> "
> " find non-ascii
> map <F5> /[^ -~]<cr>
> " add mime headers if leaving in non-ascii
> map <F6> iContent-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
> 0<cr><esc>
> map! <F6> Content-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
> 0<cr>
> " general news settings
> set ai sw=3D4 tw=3D72
>
> Basically, I'm suggesting that you take all the charcters you find and
> want to replace, and save the replacements in a script you can run
> easily before looking for new characters that you want to fix.
>
> I use http://qaz.wtf/u/ "Show unicode character" if needed to identify
> characters, the plugin might suit you better.
>
> And I have a long-standing macro:
>
> " Use * to "run" a line from the edit buffer
> " Mnemonic: * is executible in "ls -F"
> " Uses register y
> :map * "yyy@y
>
> If I were you, I would make the commands, test them with *, then 'p'ut
> them in the fix script.
>
> That * command is one of three macros I consider essential. The other
> two I think are less likely to be universally useful, but anyway:
>
> " Find previous space and split line on it
> " Mnemonic: 'S'pace
> :map S F r<CR>
> "
> " Double the character under the cursor
> " Mnemonic: fix C code like "if (0 = i) ..."
> :map = y p
>
I'm impressed that you can type your entire vimrc from memory. I'm
tempted to use some of that. If only I _understood_ it.
--
On Beta, we'd have earrings for that. You could buy them in any jewelry store.
http://www.conchord.org/xeno/bdgsig.html
--
--
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 handle non-ascii characters?
To each his/her taste of course, but IMHO all-ASCII does not always go
hand in hand with best legibility. What it does go hand in hand with
is best typability on English-language keyboards when no keymap is in
use.
My first HTML pages were in French and I took the trouble to replace
all French non-ASCII characters by their ASCII entities: à
ç é ï œ û etc. etc. etc. For French the
result is still (barely) human-readable thanks to the many unaccented
Latin letters in the text.
My current project is a Russian-French dictionary, and replacing all
Cyrillic by numeric entities would have turned it completely into
gobbledygook. Here I have chosen in favour of UTF-8 with the help of
an owncoded keymap and an "international" Latin-alphabet keyboard
(except in rare cases such as written as such in otherwise
empty <td> table cells) and this suits me perfectly; even the French
text looks more readable to me now that I write it in UTF-8.
Best regards,
Tony.
On Mon, Oct 23, 2017 at 10:50 PM, Eli the Bearded
<vim@eli.users.panix.com> wrote:
> Barry Gold wrote:
>> None of these looks like themselves when I edit the file with vim in a
>> cygwin Terminal window. I can search for [^ -~^t] to find the non-ASCII
>> characters, then go to the original word document to find out what the
>> correct character is. If I had only a few of these, that would be
>> enough. But in a longer document, a given non-ASCII can occur hundreds
>> of times. So once I've found (e.g.) an emdash, I want to replace _all_
>> occurrences with "—". But I have no way of representing the
>> character I want to replace on the command line.
>
> I have a very similar problem to yours and have evolved some fixes that
> I use. You've already gotten some replies, but maybe my methods would
> help, too.
>
> In my case, I paste content from web pages into Usenet posts and want to
> have as much US-ASCII as possible for best readibility. To that end I
> have a specific vimrc for news that fixes things with map!s. It could
> easily be modified to a ':so script' usage, to fix things on command
> or a 'autocmd BufRead *.html' script to fix thins on load.
>
> In my vimrc:
>
> autocmd BufRead .article.* :so ~eli/.news_vimrc
>
> And my news_vimrc looks like this:
>
> :r! cat ~/.news_vimrc | mmencode -q
> " smart quotes
> map! =E2=80=99 '
> map! =E2=80=98 '
> map! =E2=80=9C "
> map! =E2=80=9D "
> map! =E2=80=B3 "
> " ellipsis
> map! =E2=80=A6 ...
> " n-dash
> map! =E2=80=93 --
> " m-dash
> map! =E2=80=94 --
> " U+2212 minus
> map! =E2=88=92 -
> " U+2010 hyphen
> map! =E2=80=90 -
> "
> " find non-ascii
> map <F5> /[^ -~]<cr>
> " add mime headers if leaving in non-ascii
> map <F6> iContent-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
> 0<cr><esc>
> map! <F6> Content-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
> 0<cr>
> " general news settings
> set ai sw=3D4 tw=3D72
>
> Basically, I'm suggesting that you take all the charcters you find and
> want to replace, and save the replacements in a script you can run
> easily before looking for new characters that you want to fix.
>
> I use http://qaz.wtf/u/ "Show unicode character" if needed to identify
> characters, the plugin might suit you better.
>
> And I have a long-standing macro:
>
> " Use * to "run" a line from the edit buffer
> " Mnemonic: * is executible in "ls -F"
> " Uses register y
> :map * "yyy@y
>
> If I were you, I would make the commands, test them with *, then 'p'ut
> them in the fix script.
>
> That * command is one of three macros I consider essential. The other
> two I think are less likely to be universally useful, but anyway:
>
> " Find previous space and split line on it
> " Mnemonic: 'S'pace
> :map S F r<CR>
> "
> " Double the character under the cursor
> " Mnemonic: fix C code like "if (0 = i) ..."
> :map = y p
>
> Elijah
> ------
> can type his entire vimrc from memory, and often does
>
> --
> --
> 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.
hand in hand with best legibility. What it does go hand in hand with
is best typability on English-language keyboards when no keymap is in
use.
My first HTML pages were in French and I took the trouble to replace
all French non-ASCII characters by their ASCII entities: à
ç é ï œ û etc. etc. etc. For French the
result is still (barely) human-readable thanks to the many unaccented
Latin letters in the text.
My current project is a Russian-French dictionary, and replacing all
Cyrillic by numeric entities would have turned it completely into
gobbledygook. Here I have chosen in favour of UTF-8 with the help of
an owncoded keymap and an "international" Latin-alphabet keyboard
(except in rare cases such as written as such in otherwise
empty <td> table cells) and this suits me perfectly; even the French
text looks more readable to me now that I write it in UTF-8.
Best regards,
Tony.
On Mon, Oct 23, 2017 at 10:50 PM, Eli the Bearded
<vim@eli.users.panix.com> wrote:
> Barry Gold wrote:
>> None of these looks like themselves when I edit the file with vim in a
>> cygwin Terminal window. I can search for [^ -~^t] to find the non-ASCII
>> characters, then go to the original word document to find out what the
>> correct character is. If I had only a few of these, that would be
>> enough. But in a longer document, a given non-ASCII can occur hundreds
>> of times. So once I've found (e.g.) an emdash, I want to replace _all_
>> occurrences with "—". But I have no way of representing the
>> character I want to replace on the command line.
>
> I have a very similar problem to yours and have evolved some fixes that
> I use. You've already gotten some replies, but maybe my methods would
> help, too.
>
> In my case, I paste content from web pages into Usenet posts and want to
> have as much US-ASCII as possible for best readibility. To that end I
> have a specific vimrc for news that fixes things with map!s. It could
> easily be modified to a ':so script' usage, to fix things on command
> or a 'autocmd BufRead *.html' script to fix thins on load.
>
> In my vimrc:
>
> autocmd BufRead .article.* :so ~eli/.news_vimrc
>
> And my news_vimrc looks like this:
>
> :r! cat ~/.news_vimrc | mmencode -q
> " smart quotes
> map! =E2=80=99 '
> map! =E2=80=98 '
> map! =E2=80=9C "
> map! =E2=80=9D "
> map! =E2=80=B3 "
> " ellipsis
> map! =E2=80=A6 ...
> " n-dash
> map! =E2=80=93 --
> " m-dash
> map! =E2=80=94 --
> " U+2212 minus
> map! =E2=88=92 -
> " U+2010 hyphen
> map! =E2=80=90 -
> "
> " find non-ascii
> map <F5> /[^ -~]<cr>
> " add mime headers if leaving in non-ascii
> map <F6> iContent-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
> 0<cr><esc>
> map! <F6> Content-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
> 0<cr>
> " general news settings
> set ai sw=3D4 tw=3D72
>
> Basically, I'm suggesting that you take all the charcters you find and
> want to replace, and save the replacements in a script you can run
> easily before looking for new characters that you want to fix.
>
> I use http://qaz.wtf/u/ "Show unicode character" if needed to identify
> characters, the plugin might suit you better.
>
> And I have a long-standing macro:
>
> " Use * to "run" a line from the edit buffer
> " Mnemonic: * is executible in "ls -F"
> " Uses register y
> :map * "yyy@y
>
> If I were you, I would make the commands, test them with *, then 'p'ut
> them in the fix script.
>
> That * command is one of three macros I consider essential. The other
> two I think are less likely to be universally useful, but anyway:
>
> " Find previous space and split line on it
> " Mnemonic: 'S'pace
> :map S F r<CR>
> "
> " Double the character under the cursor
> " Mnemonic: fix C code like "if (0 = i) ..."
> :map = y p
>
> Elijah
> ------
> can type his entire vimrc from memory, and often does
>
> --
> --
> 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: How to handle non-ascii characters?
Barry Gold wrote:
> None of these looks like themselves when I edit the file with vim in a
> cygwin Terminal window. I can search for [^ -~^t] to find the non-ASCII
> characters, then go to the original word document to find out what the
> correct character is. If I had only a few of these, that would be
> enough. But in a longer document, a given non-ASCII can occur hundreds
> of times. So once I've found (e.g.) an emdash, I want to replace _all_
> occurrences with "—". But I have no way of representing the
> character I want to replace on the command line.
I have a very similar problem to yours and have evolved some fixes that
I use. You've already gotten some replies, but maybe my methods would
help, too.
In my case, I paste content from web pages into Usenet posts and want to
have as much US-ASCII as possible for best readibility. To that end I
have a specific vimrc for news that fixes things with map!s. It could
easily be modified to a ':so script' usage, to fix things on command
or a 'autocmd BufRead *.html' script to fix thins on load.
In my vimrc:
autocmd BufRead .article.* :so ~eli/.news_vimrc
And my news_vimrc looks like this:
:r! cat ~/.news_vimrc | mmencode -q
" smart quotes
map! =E2=80=99 '
map! =E2=80=98 '
map! =E2=80=9C "
map! =E2=80=9D "
map! =E2=80=B3 "
" ellipsis
map! =E2=80=A6 ...
" n-dash
map! =E2=80=93 --
" m-dash
map! =E2=80=94 --
" U+2212 minus
map! =E2=88=92 -
" U+2010 hyphen
map! =E2=80=90 -
"
" find non-ascii
map <F5> /[^ -~]<cr>
" add mime headers if leaving in non-ascii
map <F6> iContent-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
0<cr><esc>
map! <F6> Content-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
0<cr>
" general news settings
set ai sw=3D4 tw=3D72
Basically, I'm suggesting that you take all the charcters you find and
want to replace, and save the replacements in a script you can run
easily before looking for new characters that you want to fix.
I use http://qaz.wtf/u/ "Show unicode character" if needed to identify
characters, the plugin might suit you better.
And I have a long-standing macro:
" Use * to "run" a line from the edit buffer
" Mnemonic: * is executible in "ls -F"
" Uses register y
:map * "yyy@y
If I were you, I would make the commands, test them with *, then 'p'ut
them in the fix script.
That * command is one of three macros I consider essential. The other
two I think are less likely to be universally useful, but anyway:
" Find previous space and split line on it
" Mnemonic: 'S'pace
:map S F r<CR>
"
" Double the character under the cursor
" Mnemonic: fix C code like "if (0 = i) ..."
:map = y p
Elijah
------
can type his entire vimrc from memory, and often does
--
--
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.
> None of these looks like themselves when I edit the file with vim in a
> cygwin Terminal window. I can search for [^ -~^t] to find the non-ASCII
> characters, then go to the original word document to find out what the
> correct character is. If I had only a few of these, that would be
> enough. But in a longer document, a given non-ASCII can occur hundreds
> of times. So once I've found (e.g.) an emdash, I want to replace _all_
> occurrences with "—". But I have no way of representing the
> character I want to replace on the command line.
I have a very similar problem to yours and have evolved some fixes that
I use. You've already gotten some replies, but maybe my methods would
help, too.
In my case, I paste content from web pages into Usenet posts and want to
have as much US-ASCII as possible for best readibility. To that end I
have a specific vimrc for news that fixes things with map!s. It could
easily be modified to a ':so script' usage, to fix things on command
or a 'autocmd BufRead *.html' script to fix thins on load.
In my vimrc:
autocmd BufRead .article.* :so ~eli/.news_vimrc
And my news_vimrc looks like this:
:r! cat ~/.news_vimrc | mmencode -q
" smart quotes
map! =E2=80=99 '
map! =E2=80=98 '
map! =E2=80=9C "
map! =E2=80=9D "
map! =E2=80=B3 "
" ellipsis
map! =E2=80=A6 ...
" n-dash
map! =E2=80=93 --
" m-dash
map! =E2=80=94 --
" U+2212 minus
map! =E2=88=92 -
" U+2010 hyphen
map! =E2=80=90 -
"
" find non-ascii
map <F5> /[^ -~]<cr>
" add mime headers if leaving in non-ascii
map <F6> iContent-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
0<cr><esc>
map! <F6> Content-Type: text/plain; charset=3D"UTF-8"<cr>MIME-Version: 1.=
0<cr>
" general news settings
set ai sw=3D4 tw=3D72
Basically, I'm suggesting that you take all the charcters you find and
want to replace, and save the replacements in a script you can run
easily before looking for new characters that you want to fix.
I use http://qaz.wtf/u/ "Show unicode character" if needed to identify
characters, the plugin might suit you better.
And I have a long-standing macro:
" Use * to "run" a line from the edit buffer
" Mnemonic: * is executible in "ls -F"
" Uses register y
:map * "yyy@y
If I were you, I would make the commands, test them with *, then 'p'ut
them in the fix script.
That * command is one of three macros I consider essential. The other
two I think are less likely to be universally useful, but anyway:
" Find previous space and split line on it
" Mnemonic: 'S'pace
:map S F r<CR>
"
" Double the character under the cursor
" Mnemonic: fix C code like "if (0 = i) ..."
:map = y p
Elijah
------
can type his entire vimrc from memory, and often does
--
--
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: Vim startup profiling
Ken Takata wrote:
> 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> >
> > menu.vim uses `globpath()` to search some kind of files under the
> runtimepath.
> > If you search `globpath` in menu.vim, you may find the following lines:
> >
> > let s:n = globpath(&runtimepath, "colors/*.vim")
> > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > let s:n = globpath(&runtimepath, "compiler/*.vim")
> >
> > Color schemes, keymaps, spell files and compiler plugins are searched when
> > menu.vim is loaded.
> > This is why it takes long time to be loaded.
> >
> > Unlike those items, file types are not listed automatically. If a user
> > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > If we use a similar way for color schemes etc., the startup time would be
> > reduced.
>
> I wrote a patch for reduce the loading the of menu.vim by skip using
> globpath().
>
> https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
>
> Instead of searching colors/*.vim and other files, the following menuitems are
> added in the menu:
>
> Edit > Show Color Schemes in Menu
> Edit > Show Keymaps in Menu
> Tools > Show Compiler Settings in Menu
>
> If these menuitems are selected, all available colorschemes etc. are shown
> in the menu. If a user want to load them at startup, the following line
> can be added in .vimrc:
> :let do_globpath_menus = 1
> (This is similar to `:let do_syntax_sel_menu = 1`.)
>
>
> In my environment, the loading time of menu.vim is:
> Without this patch: 30 - 50 ms
> Skip using globpath: 15 - 20 ms
Not a very big difference. But still worth it if you never use those
menus.
I wonder if we can do this lazily. Thus fill in the missing entries
when we start waiting for the user to type. Should be around the same
place where timers may be triggered. Not sure if we can do it with an
actual timer from the menu.vim script though. Might need a special kind
of timer. Perhaps an "idle timer"?
--
With sufficient thrust, pigs fly just fine.
-- RFC 1925
/// 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.
> 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
> >
> > menu.vim uses `globpath()` to search some kind of files under the
> runtimepath.
> > If you search `globpath` in menu.vim, you may find the following lines:
> >
> > let s:n = globpath(&runtimepath, "colors/*.vim")
> > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > let s:n = globpath(&runtimepath, "compiler/*.vim")
> >
> > Color schemes, keymaps, spell files and compiler plugins are searched when
> > menu.vim is loaded.
> > This is why it takes long time to be loaded.
> >
> > Unlike those items, file types are not listed automatically. If a user
> > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > If we use a similar way for color schemes etc., the startup time would be
> > reduced.
>
> I wrote a patch for reduce the loading the of menu.vim by skip using
> globpath().
>
> https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
>
> Instead of searching colors/*.vim and other files, the following menuitems are
> added in the menu:
>
> Edit > Show Color Schemes in Menu
> Edit > Show Keymaps in Menu
> Tools > Show Compiler Settings in Menu
>
> If these menuitems are selected, all available colorschemes etc. are shown
> in the menu. If a user want to load them at startup, the following line
> can be added in .vimrc:
> :let do_globpath_menus = 1
> (This is similar to `:let do_syntax_sel_menu = 1`.)
>
>
> In my environment, the loading time of menu.vim is:
> Without this patch: 30 - 50 ms
> Skip using globpath: 15 - 20 ms
Not a very big difference. But still worth it if you never use those
menus.
I wonder if we can do this lazily. Thus fill in the missing entries
when we start waiting for the user to type. Should be around the same
place where timers may be triggered. Not sure if we can do it with an
actual timer from the menu.vim script though. Might need a special kind
of timer. Perhaps an "idle timer"?
--
With sufficient thrust, pigs fly just fine.
-- RFC 1925
/// 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: ZWNJ (Zero Width Non-Joiner) in Persian
Hamidreza Jafari wrote:
> Vim with mlterm is able to process Farsi input except with (some)
> special characters such as zero width non-joiner which is becoming a
> concern. I observe:
>
> - if I set keymap to persian-iranian then text entry in Farsi and
> driving Vim with commands are seamless because there is no need to
> change keyboard language at OS level for commands. Keyboard language
> is fix in English. Whenever I start to type for text it automatically
> changes to Persian. Problem is I don't find a way to insert the famous
> ZWNJ, coincidentally a much used character in Persian and Arabic.
>
> - if I do not change keymap to Persian, I can achieve similar text
> entry capability with the benefit that ZWNJ input is as easy as the
> usual: shift + space. It actually shows the codepoint in blue (<c200>)
> but viewing from other editor-aware (such as mlterm's cat) it shows
> all well done. Now the problem is I should change keyboard language to
> English at OS level every time I escape to drive, that is use Vim's
> commands for text manipulation, navigation etc. It breaks (or brakes!)
> Vim's major usability.
>
> I checked mlterm's font options (in configuration) but didn't notice a
> difference when changing font name etc.
>
> How do I introduce ZWNJ to the first scenario?
>
> ZWNJ reference: https://codepoints.net/U+200C
There hasn't been much work on Farsi support lately. The Farsi mapping
is outdated, doesn't work with utf-8. What I heard was that it's
probably best to do something similar to what Arabic support is doing.
Anyway, can you type this character with CTRL-V u 200c?
If not, maybe we can make CTRL-V switch the input to English, since
that makes most sense.
--
ARTHUR: Shut up! Will you shut up!
DENNIS: Ah, now we see the violence inherent in the system.
ARTHUR: Shut up!
DENNIS: Oh! Come and see the violence inherent in the system!
HELP! HELP! I'm being repressed!
The Quest for the Holy Grail (Monty Python)
/// 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.
> Vim with mlterm is able to process Farsi input except with (some)
> special characters such as zero width non-joiner which is becoming a
> concern. I observe:
>
> - if I set keymap to persian-iranian then text entry in Farsi and
> driving Vim with commands are seamless because there is no need to
> change keyboard language at OS level for commands. Keyboard language
> is fix in English. Whenever I start to type for text it automatically
> changes to Persian. Problem is I don't find a way to insert the famous
> ZWNJ, coincidentally a much used character in Persian and Arabic.
>
> - if I do not change keymap to Persian, I can achieve similar text
> entry capability with the benefit that ZWNJ input is as easy as the
> usual: shift + space. It actually shows the codepoint in blue (<c200>)
> but viewing from other editor-aware (such as mlterm's cat) it shows
> all well done. Now the problem is I should change keyboard language to
> English at OS level every time I escape to drive, that is use Vim's
> commands for text manipulation, navigation etc. It breaks (or brakes!)
> Vim's major usability.
>
> I checked mlterm's font options (in configuration) but didn't notice a
> difference when changing font name etc.
>
> How do I introduce ZWNJ to the first scenario?
>
> ZWNJ reference: https://codepoints.net/U+200C
There hasn't been much work on Farsi support lately. The Farsi mapping
is outdated, doesn't work with utf-8. What I heard was that it's
probably best to do something similar to what Arabic support is doing.
Anyway, can you type this character with CTRL-V u 200c?
If not, maybe we can make CTRL-V switch the input to English, since
that makes most sense.
--
ARTHUR: Shut up! Will you shut up!
DENNIS: Ah, now we see the violence inherent in the system.
ARTHUR: Shut up!
DENNIS: Oh! Come and see the violence inherent in the system!
HELP! HELP! I'm being repressed!
The Quest for the Holy Grail (Monty Python)
/// 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.
Subscribe to:
Posts (Atom)