Sven wrote:
> when you start with "vim -u NONE" then there is a statusline.
> filename, modification status, ruler (line,column) and percentage.
>
> but when you look at the setting with ":set statusline" then
> nothing is shown. so i suppose an internal default value is used.
>
> but how to show it? the ":help statusline" does not list it.
> and with ":set statusline&" is goes back to empty again. :-/
>
> i am aware of the examples in options.txt, and yet i think
> that ":set stl" should show something else than an empty value.
> or rather, when this value is empty then nothing is shown at all. ;)
There are two ways to look at this. In general, when you make an option
empty and then later check the value, you expect it to still be empty.
We don't really have a mechanism to show what is used as "the builtin
default". And for 'statusline' I think the only reason to get this is
so you can change it. Then you need to look at the help for
'statusline' anyway, and you can find the example.
--
An indication you must be a manager:
You feel sorry for Dilbert's boss.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105311723.14VHNcP02088450%40masaka.moolenaar.net.
Monday, May 31, 2021
Vim 9 still under development; Kibaale Walk
Hello Vim users!
The work on Vim 9 is making progress. Most of the syntax has settled
down, but there are still a few todo items and we need to make sure
everything works well before we can launch it. You can read more about
it in the Vim9 help:
https://github.com/vim/vim/blob/master/runtime/doc/vim9.txt
It's hard to plan this, best I can say is that it still takes a few
months. Once we release it we want to stay backwards compatible again,
so as not to break your Vim 9 plugins. We better make sure we get it
right, rather than rushing it out.
About Vim's charity: In the last report I mentioned that the small
clinic in Kibaale has been turned into a small hospital. Especially
aimed at pregnant women, many babies have been born there in the past
year. The increase in services provided also means the cost of keeping
the clinic running has increased quite a lot.
To be able to keep providing the health care our partner Kuwasha is
organizing the Kibaale Walk fundraiser. Have a look at this video:
https://player.vimeo.com/video/548603566
Find out more on this page:
https://donate.kuwasha.net/kibaale2021/?where=emergbar/
Happy Vimming!
--
TIM: That is not an ordinary rabbit ... 'tis the most foul cruel and
bad-tempered thing you ever set eyes on.
ROBIN: You tit. I soiled my armour I was so scared!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105311649.14VGntGl2080490%40masaka.moolenaar.net.
The work on Vim 9 is making progress. Most of the syntax has settled
down, but there are still a few todo items and we need to make sure
everything works well before we can launch it. You can read more about
it in the Vim9 help:
https://github.com/vim/vim/blob/master/runtime/doc/vim9.txt
It's hard to plan this, best I can say is that it still takes a few
months. Once we release it we want to stay backwards compatible again,
so as not to break your Vim 9 plugins. We better make sure we get it
right, rather than rushing it out.
About Vim's charity: In the last report I mentioned that the small
clinic in Kibaale has been turned into a small hospital. Especially
aimed at pregnant women, many babies have been born there in the past
year. The increase in services provided also means the cost of keeping
the clinic running has increased quite a lot.
To be able to keep providing the health care our partner Kuwasha is
organizing the Kibaale Walk fundraiser. Have a look at this video:
https://player.vimeo.com/video/548603566
Find out more on this page:
https://donate.kuwasha.net/kibaale2021/?where=emergbar/
Happy Vimming!
--
TIM: That is not an ordinary rabbit ... 'tis the most foul cruel and
bad-tempered thing you ever set eyes on.
ROBIN: You tit. I soiled my armour I was so scared!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105311649.14VGntGl2080490%40masaka.moolenaar.net.
=?UTF-8?Q?Re:_Error_Building_Vim_x86_32bit_un? =?UTF-8?Q?der_MSYS2_Win10:_error:_‘_UI64_MAX’?MIME-Version: 1.0
> Documentation in installPc.txt section MSYS2 should be modified,
>
> "... And restart MSYS2 console (select "MSYS2 MSYS" icon from the Start
> Menu). "
>
> should be changed to
>
> "... And restart MSYS2 console (select "MSYS2 MinGW 32-Bit" icon from the
> Start Menu for building 32-bit Vim, otherwise select "MSYS2 MinGW 64-Bit"
> )."
OK, I'll change that.
--
ARTHUR: Charge!
[They all charge with swords drawn towards the RABBIT. A tremendous twenty
second fight with Peckinpahish shots and borrowing heavily also on the
Kung Fu and karate-type films ensues, in which some four KNIGHTS are
comprehensively killed.]
ARTHUR: Run away! Run away!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105311641.14VGfJVC2078724%40masaka.moolenaar.net.
>
> "... And restart MSYS2 console (select "MSYS2 MSYS" icon from the Start
> Menu). "
>
> should be changed to
>
> "... And restart MSYS2 console (select "MSYS2 MinGW 32-Bit" icon from the
> Start Menu for building 32-bit Vim, otherwise select "MSYS2 MinGW 64-Bit"
> )."
OK, I'll change that.
--
ARTHUR: Charge!
[They all charge with swords drawn towards the RABBIT. A tremendous twenty
second fight with Peckinpahish shots and borrowing heavily also on the
Kung Fu and karate-type films ensues, in which some four KNIGHTS are
comprehensively killed.]
ARTHUR: Run away! Run away!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105311641.14VGfJVC2078724%40masaka.moolenaar.net.
Re: Error Building Vim x86 32bit under MSYS2 Win10: error: ‘_UI64_MAX’
Documentation in installPc.txt section MSYS2 should be modified,
"... And restart MSYS2 console (select "MSYS2 MSYS" icon from the Start Menu). "
should be changed to
"... And restart MSYS2 console (select "MSYS2 MinGW 32-Bit" icon from the Start Menu for building 32-bit Vim, otherwise select "MSYS2 MinGW 64-Bit" )."
Le lundi 31 mai 2021 à 13:48:52 UTC+2, Ni Va a écrit :
Hi,Reading instructions in src/installPC.txt in order to build Vim x86 under MSYS2 it appears this error :$ make -f Make_ming.makgcc -c -I. -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=x86-64 -Wall -DFEAT_XPM_W32 -I xpm/x64/include -I xpm/x64/../include -O3 -fomit-frame-pointer -freg-struct-return charset.c -o gobjx86-64/charset.oIn file included from vim.h:1828,from charset.c:10:charset.c: In function 'vim_str2nr':structs.h:1311:24: error: '_UI64_MAX' undeclared (first use in this function); did you mean 'INT64_MAX'?1311 | # define UVARNUM_MAX _UI64_MAX| ^~~~~~~~~structs.h:1311:24: note: in definition of macro 'UVARNUM_MAX'1311 | # define UVARNUM_MAX _UI64_MAX
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6c4364b0-97de-4e8f-b16e-96123c781f53n%40googlegroups.com.
Error Building Vim x86 32bit under MSYS2 Win10: error: ‘_UI64_MAX’
Hi,
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6522585b-4672-4d50-94c4-1617a2e1d0f3n%40googlegroups.com.
Reading instructions in src/installPC.txt in order to build Vim x86 under MSYS2 it appears this error :
-- $ make -f Make_ming.mak
gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=x86-64 -Wall -DFEAT_XPM_W32 -I xpm/x64/include -I xpm/x64/../include -O3 -fomit-frame-pointer -freg-struct-return charset.c -o gobjx86-64/charset.o
In file included from vim.h:1828,
from charset.c:10:
charset.c: In function 'vim_str2nr':
structs.h:1311:24: error: '_UI64_MAX' undeclared (first use in this function); did you mean 'INT64_MAX'?
1311 | # define UVARNUM_MAX _UI64_MAX
| ^~~~~~~~~
structs.h:1311:24: note: in definition of macro 'UVARNUM_MAX'
1311 | # define UVARNUM_MAX _UI64_MAX
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6522585b-4672-4d50-94c4-1617a2e1d0f3n%40googlegroups.com.
Re: Build Vim Error MSys2 Environment
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/a48e7cbe-a84b-4a47-89cf-64907b6a4abdn%40googlegroups.com.
Le dimanche 30 mai 2021 à 14:02:39 UTC+2, Bram Moolenaar a écrit :
> I encounter an error trying build Vim under Win10 OS and Msys2 with gcc and
> make -f Make_ming.mak as is :
>
>
>
> gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600
> -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT
> -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE
> -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP
> -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX
> -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD
> -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=x86-64 -Wall
> -I./lua-5.3.5/src/include -I./lua-5.3.5/src -DFEAT_LUA -DDYNAMIC_LUA
> -DDYNAMIC_LUA_DLL=\"lua53.dll\" -DFEAT_RUBY -I C:/Ruby30/include/ruby-3.0.0
> -I C:/Ruby30/include/ruby-3.0.0/i386-mingw32 -DDYNAMIC_RUBY
> -DDYNAMIC_RUBY_DLL=\"x64-msvcrt-ruby300.dll\" -DRUBY_VERSION=30
> -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python39.dll\" -O3
> -fomit-frame-pointer -freg-struct-return beval.c -o gobjx86-64/beval.o
> In file included from beval.c:11:
> beval.c: In function 'find_word_under_cursor':
> vim.h:1704:18: error: 'INT_MAX' undeclared (first use in this function)
> 1704 | # define MAXCOL INT_MAX // maximum column number
> | ^~~~~~~
> vim.h:1704:18: note: in definition of macro 'MAXCOL'
> 1704 | # define MAXCOL INT_MAX // maximum column number
> | ^~~~~~~
> beval.c:12:1: note: 'INT_MAX' is defined in header '<limits.h>'; did you
> forget to '#include <limits.h>'?
> 11 | #include "vim.h"
> +++ |+#include <limits.h>
> 12 |
> In file included from beval.c:11:
> vim.h:1704:18: note: each undeclared identifier is reported only once for
> each function it appears in
> 1704 | # define MAXCOL INT_MAX // maximum column number
The limits.h file is only included when running configure.
I can't think of a good reason, every build environment should have
limits.h. I'll move the include.
--
Vi beats Emacs to death, and then again!
http://linuxtoday.com/stories/5764.html
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/a48e7cbe-a84b-4a47-89cf-64907b6a4abdn%40googlegroups.com.
Recursive parentheses in syntax
I'm writing a syntax file for a string template DSL (somewhat similar to Bash parameter expansion) which distinguishes between (a) `$(...)` (call it "placeholder") and (b) `(...)` (call it "parens") where placeholder is preferably an Operator and parens is preferably a String where the parentheses themselves are Special, and where placeholders can occur inside non-highlighted text and both can be nested inside (certain parts of) placeholders and inside parens which are inside a placeholder.
I know that Vim regex do not support recursive patterns but I'm pretty confident that this can be pulled off in a syntax definition using regions which contain other regions, but I'm not quite sure if/how. I'm wondering if someone can tell or point me to a relevant example. In particular I'm not sure how/if you can nest a region with some delimiters inside another region with the same delimiters without failing to match the outer closing delimiter or matching past it.
In Perl 5.10+ it corresponds to a regex like this (in lieu of a formal syntax), with the `\(` and `\)` which are part of the syntax replaced with `\{` and `\}` for clarity, and each `$foo` representing some more or less complicated subexpression whose exact shape is (I think) irrelevant to the recursion issue. Thus this is not the actual regex used to match a placeholder, but it is like an MWE which illustrates how it is supposed to work.
``````perl
my $placeholder_re = qr{
(?<placeholder>
\$\{
$varname_re
(?:
$operator_A_re
(?<parens>
\s*
\{
(?<content>
(?:
[^\{\}\$]++
| \$ (?! \{ )
| (?&placeholder)
| (?&parens)
)*?
)
\}
\s*
)
$operator_B_re
(?<parens_B> (?&parens) )
|
$some_operator_re
(?<content_B> (?&parens) | (?&content) )
)
\}
)
}msx;
``````
TIA,
/bpj
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CADAJKhCG13VLQL27oJ4FdLygChsz3RW7COEpoo8PFRjY5bMsyA%40mail.gmail.com.
statusline default - :set stl&
when you start with "vim -u NONE" then there is a statusline.
filename, modification status, ruler (line,column) and percentage.
but when you look at the setting with ":set statusline" then
nothing is shown. so i suppose an internal default value is used.
but how to show it? the ":help statusline" does not list it.
and with ":set statusline&" is goes back to empty again. :-/
i am aware of the examples in options.txt, and yet i think
that ":set stl" should show something else than an empty value.
or rather, when this value is empty then nothing is shown at all. ;)
Sven
$ cd vim; rg -w BOT .
./src/option.h
340:#define STL_ALTPERCENT 'P' // percentage as TOP BOT ALL or NN%
$ cd vim; rg %l,%c .
./runtime/doc/options.txt
7417: :set statusline=%<%f\ %h%m%r%=%-14.(%l,%c%V%)\ %P
7419: :set statusline=%<%f%h%m%r%=%b\ 0x%B\ \ %l,%c%V\ %P
Examples:
Emulate standard status line with 'ruler' set >
:set statusline=%<%f\ %h%m%r%=%-14.(%l,%c%V%)\ %P
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210531084216.c56mtkaxztagfrpd%40guckes.net.
filename, modification status, ruler (line,column) and percentage.
but when you look at the setting with ":set statusline" then
nothing is shown. so i suppose an internal default value is used.
but how to show it? the ":help statusline" does not list it.
and with ":set statusline&" is goes back to empty again. :-/
i am aware of the examples in options.txt, and yet i think
that ":set stl" should show something else than an empty value.
or rather, when this value is empty then nothing is shown at all. ;)
Sven
$ cd vim; rg -w BOT .
./src/option.h
340:#define STL_ALTPERCENT 'P' // percentage as TOP BOT ALL or NN%
$ cd vim; rg %l,%c .
./runtime/doc/options.txt
7417: :set statusline=%<%f\ %h%m%r%=%-14.(%l,%c%V%)\ %P
7419: :set statusline=%<%f%h%m%r%=%b\ 0x%B\ \ %l,%c%V\ %P
Examples:
Emulate standard status line with 'ruler' set >
:set statusline=%<%f\ %h%m%r%=%-14.(%l,%c%V%)\ %P
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210531084216.c56mtkaxztagfrpd%40guckes.net.
Re: Vim9: how to invoke callback with additional arguments?
>> What is Vim9's equivalent of the following?
>>
>> fun Callback(value, _j, _e)
>> echom 'callback with value: ' .. a:value
>> endf
>>
>> fun Func()
>> call job_start(['/bin/bash', '-c', ':'],
>> \ {'exit_cb': function('Callback', [42])})
>> endf
>>
>> call Func()
>
> I don't think there is a difference, you can still use function() to
> create a partial.
A definition such as this:
def Func()
job_start(['/bin/bash', '-c', ':'],
\ {'exit_cb': function('Callback', [42])})
enddef
results in `E117: Unknown function: Callback` (in Vim 8.2.2900).
> Is there a "Vim9 way" that would be better? You could use a lambda:
>
> call job_start(['/bin/bash', '-c', ':'],
> \ {'exit_cb': (j, e) => Callback(42, j, e)})
>
> It looks a bit nicer.
I like that. It is explicit about the arguments and it allows me to
reorder the callback's parameters as I see fit. And yes, it works.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/s922g7%2414o9%241%40ciao.gmane.io.
>>
>> fun Callback(value, _j, _e)
>> echom 'callback with value: ' .. a:value
>> endf
>>
>> fun Func()
>> call job_start(['/bin/bash', '-c', ':'],
>> \ {'exit_cb': function('Callback', [42])})
>> endf
>>
>> call Func()
>
> I don't think there is a difference, you can still use function() to
> create a partial.
A definition such as this:
def Func()
job_start(['/bin/bash', '-c', ':'],
\ {'exit_cb': function('Callback', [42])})
enddef
results in `E117: Unknown function: Callback` (in Vim 8.2.2900).
> Is there a "Vim9 way" that would be better? You could use a lambda:
>
> call job_start(['/bin/bash', '-c', ':'],
> \ {'exit_cb': (j, e) => Callback(42, j, e)})
>
> It looks a bit nicer.
I like that. It is explicit about the arguments and it allows me to
reorder the callback's parameters as I see fit. And yes, it works.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/s922g7%2414o9%241%40ciao.gmane.io.
Sunday, May 30, 2021
Re: Insert non-rectangular selection
On Di, 25 Mai 2021, Andre Tann wrote:
> Hi all,
>
> I repeatedly have the following situation, and wonder how it can be handled
> better than I do it now. These lines must be merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the first
> semicolon, and press P. Result is:
>
> /path/subdir ;text
> /path/longsubdir ;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the extra blanks?
With the latest Vim 8.2.2914 you can now paste using `zp` that will not
add any padding.
Best,
Christian
--
Männer verlangen von den Frauen immer das Gleiche.
Frauen verlangen von den Männern etwas Besonderes.
-- Sarah Bernhardt
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210531053908.GG1800871%40256bit.org.
> Hi all,
>
> I repeatedly have the following situation, and wonder how it can be handled
> better than I do it now. These lines must be merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the first
> semicolon, and press P. Result is:
>
> /path/subdir ;text
> /path/longsubdir ;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the extra blanks?
With the latest Vim 8.2.2914 you can now paste using `zp` that will not
add any padding.
Best,
Christian
--
Männer verlangen von den Frauen immer das Gleiche.
Frauen verlangen von den Männern etwas Besonderes.
-- Sarah Bernhardt
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210531053908.GG1800871%40256bit.org.
Re: Vim9: how to invoke callback with additional arguments?
> I am trying to understand how to invoke a callback in Vim9 script.
> I have started from this example (from the excellent lacygoill's wiki):
>
> vim9script
>
> def Callback(_j: job, _e: number)
> echom 'callback'
> enddef
>
> def Func()
> job_start(['/bin/bash', '-c', ':'], {exit_cb: Callback})
> enddef
>
> Func()
>
> That's fine, but now suppose that I want to pass additional arguments to
> Callback(). What is Vim9's equivalent of the following?
>
> fun Callback(value, _j, _e)
> echom 'callback with value: ' .. a:value
> endf
>
> fun Func()
> call job_start(['/bin/bash', '-c', ':'],
> \ {'exit_cb': function('Callback', [42])})
> endf
>
> call Func()
I don't think there is a difference, you can still use function() to
create a partial.
Is there a "Vim9 way" that would be better? You could use a lambda:
call job_start(['/bin/bash', '-c', ':'],
\ {'exit_cb': (j, e) => Callback(42, j, e)})
It looks a bit nicer. I haven't tried it, you may need to add types.
--
The Law of VIM:
For each member b of the possible behaviour space B of program P, there exists
a finite time t before which at least one user u in the total user space U of
program P will request b becomes a member of the allowed behaviour space B'
(B' <= B).
In other words: Sooner or later everyone wants everything as an option.
-- Vince Negri
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105302018.14UKI2951871595%40masaka.moolenaar.net.
> I have started from this example (from the excellent lacygoill's wiki):
>
> vim9script
>
> def Callback(_j: job, _e: number)
> echom 'callback'
> enddef
>
> def Func()
> job_start(['/bin/bash', '-c', ':'], {exit_cb: Callback})
> enddef
>
> Func()
>
> That's fine, but now suppose that I want to pass additional arguments to
> Callback(). What is Vim9's equivalent of the following?
>
> fun Callback(value, _j, _e)
> echom 'callback with value: ' .. a:value
> endf
>
> fun Func()
> call job_start(['/bin/bash', '-c', ':'],
> \ {'exit_cb': function('Callback', [42])})
> endf
>
> call Func()
I don't think there is a difference, you can still use function() to
create a partial.
Is there a "Vim9 way" that would be better? You could use a lambda:
call job_start(['/bin/bash', '-c', ':'],
\ {'exit_cb': (j, e) => Callback(42, j, e)})
It looks a bit nicer. I haven't tried it, you may need to add types.
--
The Law of VIM:
For each member b of the possible behaviour space B of program P, there exists
a finite time t before which at least one user u in the total user space U of
program P will request b becomes a member of the allowed behaviour space B'
(B' <= B).
In other words: Sooner or later everyone wants everything as an option.
-- Vince Negri
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105302018.14UKI2951871595%40masaka.moolenaar.net.
Vim9: how to invoke callback with additional arguments?
I am trying to understand how to invoke a callback in Vim9 script.
I have started from this example (from the excellent lacygoill's wiki):
vim9script
def Callback(_j: job, _e: number)
echom 'callback'
enddef
def Func()
job_start(['/bin/bash', '-c', ':'], {exit_cb: Callback})
enddef
Func()
That's fine, but now suppose that I want to pass additional arguments to
Callback(). What is Vim9's equivalent of the following?
fun Callback(value, _j, _e)
echom 'callback with value: ' .. a:value
endf
fun Func()
call job_start(['/bin/bash', '-c', ':'],
\ {'exit_cb': function('Callback', [42])})
endf
call Func()
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/s90kig%241788%241%40ciao.gmane.io.
I have started from this example (from the excellent lacygoill's wiki):
vim9script
def Callback(_j: job, _e: number)
echom 'callback'
enddef
def Func()
job_start(['/bin/bash', '-c', ':'], {exit_cb: Callback})
enddef
Func()
That's fine, but now suppose that I want to pass additional arguments to
Callback(). What is Vim9's equivalent of the following?
fun Callback(value, _j, _e)
echom 'callback with value: ' .. a:value
endf
fun Func()
call job_start(['/bin/bash', '-c', ':'],
\ {'exit_cb': function('Callback', [42])})
endf
call Func()
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/s90kig%241788%241%40ciao.gmane.io.
Re: Insert non-rectangular selection
On Do, 27 Mai 2021, Bram Moolenaar wrote:
>
> Christian wrote:
>
> > On Di, 25 Mai 2021, Andre Tann wrote:
> >
> > > Hi all,
> > >
> > > I repeatedly have the following situation, and wonder how it can be handled
> > > better than I do it now. These lines must be merged
> > >
> > > /path/subdir ;text
> > > /path/longsubdir ;text
> > > /path/longlongsubdir;text
> > >
> > > with these:
> > >
> > > /subdir
> > > /longsubdir
> > > /longlongsubdir
> > >
> > > Result:
> > >
> > > /path/subdir;text
> > > /path/longsubdir;text
> > > /path/longlongsubdir;text
> > >
> > >
> > > What I do now is to mark and yank the second block, go to the first
> > > semicolon, and press P. Result is:
> > >
> > > /path/subdir ;text
> > > /path/longsubdir ;text
> > > /path/longlongsubdir;text
> > >
> > > But this is obviously not what I want. How can I avoid the extra blanks?
> >
> > I have this annoyance a few times as well. I would go with the already
> > mentioned `:s` approach to remove the whitespace, afterwards. However, I
> > was wondering, if we not could do any better any perhaps have something
> > like a `zp` command, that does not add any trailing spaces.
>
> This makes a lot of sense. I don't see a problem using "zp" and "zP"
> for this.
>
> Can you turn this into a pull request and add a test?
Okay done.
>
>
> The example yanks until the end of the line, thus the register does not
> contain trailing spaces. I wonder what to do when yanking halfway a
> line, e.g. a column in a table:
>
> texttext /subdir columntext
> texttext /longsubdir columntext
> texttext /longlongsubdir columntext
>
> Here you can only yank a block including the spaces, and they would also
> be inserted with "zp". Perhaps we should also have a "zy" command to
> exclude the trailing spaces when yanking. I think that's better than
> having "zp" drop spaces that were yanked.
Okay, I'll have a look at adding a zy command as well (this will be a
separate PR).
Best,
Christian
--
Wer irgendeine Art von Religion zur Stütze seiner Sittlichkeit bedarf,
dessen Moralität ist nicht rein, denn diese muß ihrer Natur nach in
sich selbst bestehen.
-- Karoline von Günderode
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210530174228.GE1800871%40256bit.org.
>
> Christian wrote:
>
> > On Di, 25 Mai 2021, Andre Tann wrote:
> >
> > > Hi all,
> > >
> > > I repeatedly have the following situation, and wonder how it can be handled
> > > better than I do it now. These lines must be merged
> > >
> > > /path/subdir ;text
> > > /path/longsubdir ;text
> > > /path/longlongsubdir;text
> > >
> > > with these:
> > >
> > > /subdir
> > > /longsubdir
> > > /longlongsubdir
> > >
> > > Result:
> > >
> > > /path/subdir;text
> > > /path/longsubdir;text
> > > /path/longlongsubdir;text
> > >
> > >
> > > What I do now is to mark and yank the second block, go to the first
> > > semicolon, and press P. Result is:
> > >
> > > /path/subdir ;text
> > > /path/longsubdir ;text
> > > /path/longlongsubdir;text
> > >
> > > But this is obviously not what I want. How can I avoid the extra blanks?
> >
> > I have this annoyance a few times as well. I would go with the already
> > mentioned `:s` approach to remove the whitespace, afterwards. However, I
> > was wondering, if we not could do any better any perhaps have something
> > like a `zp` command, that does not add any trailing spaces.
>
> This makes a lot of sense. I don't see a problem using "zp" and "zP"
> for this.
>
> Can you turn this into a pull request and add a test?
Okay done.
>
>
> The example yanks until the end of the line, thus the register does not
> contain trailing spaces. I wonder what to do when yanking halfway a
> line, e.g. a column in a table:
>
> texttext /subdir columntext
> texttext /longsubdir columntext
> texttext /longlongsubdir columntext
>
> Here you can only yank a block including the spaces, and they would also
> be inserted with "zp". Perhaps we should also have a "zy" command to
> exclude the trailing spaces when yanking. I think that's better than
> having "zp" drop spaces that were yanked.
Okay, I'll have a look at adding a zy command as well (this will be a
separate PR).
Best,
Christian
--
Wer irgendeine Art von Religion zur Stütze seiner Sittlichkeit bedarf,
dessen Moralität ist nicht rein, denn diese muß ihrer Natur nach in
sich selbst bestehen.
-- Karoline von Günderode
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210530174228.GE1800871%40256bit.org.
Re: Build Vim Error MSys2 Environment
> I encounter an error trying build Vim under Win10 OS and Msys2 with gcc and
> make -f Make_ming.mak as is :
>
>
>
> gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600
> -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT
> -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE
> -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP
> -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX
> -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD
> -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=x86-64 -Wall
> -I./lua-5.3.5/src/include -I./lua-5.3.5/src -DFEAT_LUA -DDYNAMIC_LUA
> -DDYNAMIC_LUA_DLL=\"lua53.dll\" -DFEAT_RUBY -I C:/Ruby30/include/ruby-3.0.0
> -I C:/Ruby30/include/ruby-3.0.0/i386-mingw32 -DDYNAMIC_RUBY
> -DDYNAMIC_RUBY_DLL=\"x64-msvcrt-ruby300.dll\" -DRUBY_VERSION=30
> -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python39.dll\" -O3
> -fomit-frame-pointer -freg-struct-return beval.c -o gobjx86-64/beval.o
> In file included from beval.c:11:
> beval.c: In function 'find_word_under_cursor':
> vim.h:1704:18: error: 'INT_MAX' undeclared (first use in this function)
> 1704 | # define MAXCOL INT_MAX // maximum column number
> | ^~~~~~~
> vim.h:1704:18: note: in definition of macro 'MAXCOL'
> 1704 | # define MAXCOL INT_MAX // maximum column number
> | ^~~~~~~
> beval.c:12:1: note: 'INT_MAX' is defined in header '<limits.h>'; did you
> forget to '#include <limits.h>'?
> 11 | #include "vim.h"
> +++ |+#include <limits.h>
> 12 |
> In file included from beval.c:11:
> vim.h:1704:18: note: each undeclared identifier is reported only once for
> each function it appears in
> 1704 | # define MAXCOL INT_MAX // maximum column number
The limits.h file is only included when running configure.
I can't think of a good reason, every build environment should have
limits.h. I'll move the include.
--
Vi beats Emacs to death, and then again!
http://linuxtoday.com/stories/5764.html
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105301202.14UC2U5w1768756%40masaka.moolenaar.net.
> make -f Make_ming.mak as is :
>
>
>
> gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600
> -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT
> -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE
> -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP
> -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX
> -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD
> -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=x86-64 -Wall
> -I./lua-5.3.5/src/include -I./lua-5.3.5/src -DFEAT_LUA -DDYNAMIC_LUA
> -DDYNAMIC_LUA_DLL=\"lua53.dll\" -DFEAT_RUBY -I C:/Ruby30/include/ruby-3.0.0
> -I C:/Ruby30/include/ruby-3.0.0/i386-mingw32 -DDYNAMIC_RUBY
> -DDYNAMIC_RUBY_DLL=\"x64-msvcrt-ruby300.dll\" -DRUBY_VERSION=30
> -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python39.dll\" -O3
> -fomit-frame-pointer -freg-struct-return beval.c -o gobjx86-64/beval.o
> In file included from beval.c:11:
> beval.c: In function 'find_word_under_cursor':
> vim.h:1704:18: error: 'INT_MAX' undeclared (first use in this function)
> 1704 | # define MAXCOL INT_MAX // maximum column number
> | ^~~~~~~
> vim.h:1704:18: note: in definition of macro 'MAXCOL'
> 1704 | # define MAXCOL INT_MAX // maximum column number
> | ^~~~~~~
> beval.c:12:1: note: 'INT_MAX' is defined in header '<limits.h>'; did you
> forget to '#include <limits.h>'?
> 11 | #include "vim.h"
> +++ |+#include <limits.h>
> 12 |
> In file included from beval.c:11:
> vim.h:1704:18: note: each undeclared identifier is reported only once for
> each function it appears in
> 1704 | # define MAXCOL INT_MAX // maximum column number
The limits.h file is only included when running configure.
I can't think of a good reason, every build environment should have
limits.h. I'll move the include.
--
Vi beats Emacs to death, and then again!
http://linuxtoday.com/stories/5764.html
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105301202.14UC2U5w1768756%40masaka.moolenaar.net.
Saturday, May 29, 2021
Build Vim Error MSys2 Environment
Hi,
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/4d664714-a3a9-4be6-aac9-2f1221ed7b61n%40googlegroups.com.
I encounter an error trying build Vim under Win10 OS and Msys2 with gcc and make -f Make_ming.mak as is :
gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=x86-64 -Wall -I./lua-5.3.5/src/include -I./lua-5.3.5/src -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua53.dll\" -DFEAT_RUBY -I C:/Ruby30/include/ruby-3.0.0 -I C:/Ruby30/include/ruby-3.0.0/i386-mingw32 -DDYNAMIC_RUBY -DDYNAMIC_RUBY_DLL=\"x64-msvcrt-ruby300.dll\" -DRUBY_VERSION=30 -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python39.dll\" -O3 -fomit-frame-pointer -freg-struct-return beval.c -o gobjx86-64/beval.o
In file included from beval.c:11:
beval.c: In function 'find_word_under_cursor':
vim.h:1704:18: error: 'INT_MAX' undeclared (first use in this function)
1704 | # define MAXCOL INT_MAX // maximum column number
| ^~~~~~~
vim.h:1704:18: note: in definition of macro 'MAXCOL'
1704 | # define MAXCOL INT_MAX // maximum column number
| ^~~~~~~
beval.c:12:1: note: 'INT_MAX' is defined in header '<limits.h>'; did you forget to '#include <limits.h>'?
11 | #include "vim.h"
+++ |+#include <limits.h>
12 |
In file included from beval.c:11:
vim.h:1704:18: note: each undeclared identifier is reported only once for each function it appears in
1704 | # define MAXCOL INT_MAX // maximum column number
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/4d664714-a3a9-4be6-aac9-2f1221ed7b61n%40googlegroups.com.
Re: Plans (if any) for Vim9 runtime scripts?
> What is the vision for future runtime scripts? Is there a plan to move
> everything to Vim9—including, say, syntax scripts?
>
> What is your recommendation to contributors? Is it too early to
> translate runtime scripts to Vim9? Is it better to stick with the
> current Vim Script for the time being?
>
> I'd like to work on a major update on an ftplugin I contribute
> maintaining, and I am wondering whether it is worth rewriting in Vim9
> already.
You can write the script in Vim9 syntax now. Keep in mind that some
things might still change. If you regularly update Vim and don't mind
updating your script once in a while that will be fine.
I don't plan a mass migration yet, not only because it's a lot of work,
also because there might still be a few bugs to fix. Having a few
people migrate their scripts helps to uncover problems. Not only bugs,
but also things that turn out to be confusing or can be further
improved.
Eventually most scripts should use Vim9 syntax. It's easier to use and
when using compiled functions will execute much faster.
I also plan to update the help to put the Vim9 syntax where a command is
explained, instead of putting it all in vim9.txt. That will be quite a
bit of work!
--
Life is a gift, living is an art. (Bram Moolenaar)
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105291244.14TCiOJc1507419%40masaka.moolenaar.net.
> everything to Vim9—including, say, syntax scripts?
>
> What is your recommendation to contributors? Is it too early to
> translate runtime scripts to Vim9? Is it better to stick with the
> current Vim Script for the time being?
>
> I'd like to work on a major update on an ftplugin I contribute
> maintaining, and I am wondering whether it is worth rewriting in Vim9
> already.
You can write the script in Vim9 syntax now. Keep in mind that some
things might still change. If you regularly update Vim and don't mind
updating your script once in a while that will be fine.
I don't plan a mass migration yet, not only because it's a lot of work,
also because there might still be a few bugs to fix. Having a few
people migrate their scripts helps to uncover problems. Not only bugs,
but also things that turn out to be confusing or can be further
improved.
Eventually most scripts should use Vim9 syntax. It's easier to use and
when using compiled functions will execute much faster.
I also plan to update the help to put the Vim9 syntax where a command is
explained, instead of putting it all in vim9.txt. That will be quite a
bit of work!
--
Life is a gift, living is an art. (Bram Moolenaar)
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105291244.14TCiOJc1507419%40masaka.moolenaar.net.
Plans (if any) for Vim9 runtime scripts?
What is the vision for future runtime scripts? Is there a plan to move
everything to Vim9—including, say, syntax scripts?
What is your recommendation to contributors? Is it too early to
translate runtime scripts to Vim9? Is it better to stick with the
current Vim Script for the time being?
I'd like to work on a major update on an ftplugin I contribute
maintaining, and I am wondering whether it is worth rewriting in Vim9
already.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/s8t7p0%24m17%241%40ciao.gmane.io.
everything to Vim9—including, say, syntax scripts?
What is your recommendation to contributors? Is it too early to
translate runtime scripts to Vim9? Is it better to stick with the
current Vim Script for the time being?
I'd like to work on a major update on an ftplugin I contribute
maintaining, and I am wondering whether it is worth rewriting in Vim9
already.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/s8t7p0%24m17%241%40ciao.gmane.io.
Friday, May 28, 2021
Re: Where are vim macros stored
On 2021-05-28 11:47, 'Grant Taylor' via vim_use wrote:
> My understanding is that, by default, macros only exist in memory,
> are volatile, and not stored persistently. The only live in vim's
> memory while vim is running.
>
> There are some non-default options that you can use to change some
> of that.
Depends on whether vim was started in compatible mode or not. The
gritty details of "should I default to compatible or not" is spelled
out at
:help compatible-default
In compatible mode, it doesn't store registers in your viminfo,
whereas for nocp mode, it does by default:
:help 'viminfo'
Vi default: ""
Vim default
for MS-Windows: '100,<50,s10,h,rA:,rB:,
for Amiga: '100,<50,s10,h,rdf0:,rdf1:,rdf2:
for others: '100,<50,s10,h)
So based on a number of factors (initial 'cp' determination,
overridden 'cp' setting, manually setting 'viminfo', manually setting
'viminfofile', etc), the results may vary. Tuneable to the point of
fault^Wconfusion. ;-)
-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528131026.694cf5c9%40bigbox.attlocal.net.
> My understanding is that, by default, macros only exist in memory,
> are volatile, and not stored persistently. The only live in vim's
> memory while vim is running.
>
> There are some non-default options that you can use to change some
> of that.
Depends on whether vim was started in compatible mode or not. The
gritty details of "should I default to compatible or not" is spelled
out at
:help compatible-default
In compatible mode, it doesn't store registers in your viminfo,
whereas for nocp mode, it does by default:
:help 'viminfo'
Vi default: ""
Vim default
for MS-Windows: '100,<50,s10,h,rA:,rB:,
for Amiga: '100,<50,s10,h,rdf0:,rdf1:,rdf2:
for others: '100,<50,s10,h)
So based on a number of factors (initial 'cp' determination,
overridden 'cp' setting, manually setting 'viminfo', manually setting
'viminfofile', etc), the results may vary. Tuneable to the point of
fault^Wconfusion. ;-)
-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528131026.694cf5c9%40bigbox.attlocal.net.
Re: Where are vim macros stored
On 5/28/21 7:43 AM, Ruben Safir wrote:
> Where are the vim macros stored. I want to edit them by hand
My understanding is that, by default, macros only exist in memory, are
volatile, and not stored persistently. The only live in vim's memory
while vim is running.
There are some non-default options that you can use to change some of that.
--
Grant. . . .
unix || die
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/7f4523c3-53ef-abdf-4c36-24a4c1b8ec6a%40spamtrap.tnetconsulting.net.
> Where are the vim macros stored. I want to edit them by hand
My understanding is that, by default, macros only exist in memory, are
volatile, and not stored persistently. The only live in vim's memory
while vim is running.
There are some non-default options that you can use to change some of that.
--
Grant. . . .
unix || die
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/7f4523c3-53ef-abdf-4c36-24a4c1b8ec6a%40spamtrap.tnetconsulting.net.
Re: Where are vim macros stored
On 5/28/21 12:34 PM, Tim Chase wrote:
> Unless you have changed settings, it's stored in ~/.viminfo but it
> can get overwritten upon quitting if you edit it while vim is
> configured to (over)write it upon quitting. So if you plan to edit
> it, you might want to
>
> :set viminfo=
>
> before quitting.
thank you!
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/7a019cd1-8901-b078-5ff8-49787df8424b%40my.liu.edu.
> Unless you have changed settings, it's stored in ~/.viminfo but it
> can get overwritten upon quitting if you edit it while vim is
> configured to (over)write it upon quitting. So if you plan to edit
> it, you might want to
>
> :set viminfo=
>
> before quitting.
thank you!
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/7a019cd1-8901-b078-5ff8-49787df8424b%40my.liu.edu.
Re: Where are vim macros stored
On 2021-05-28 11:10, Ruben Safir wrote:
> I just want to open the file and edit it.
Unless you have changed settings, it's stored in ~/.viminfo but it
can get overwritten upon quitting if you edit it while vim is
configured to (over)write it upon quitting. So if you plan to edit
it, you might want to
:set viminfo=
before quitting.
> Quoting back the manual for macros is significantly less polite in
> this context. If the manual and tutorials had what I wanted, or if
> I could discover the necessary file with find (and I don't know why
> that didn't work actually), I wouldn't have asked the question on
> the public mailing list. SO I asked specifically "where are they
> stored" They are stored in memory is sort of an answer.
The answers were an attempt to correct a misunderstanding that macros
were stored somewhere. Maybe they are, maybe they aren't. It
depends on your settings. So help-references were provided to arm
you with the understanding of how the pieces fit together.
Macros are not anything special. Just a register. Same as where you
yank/delete to and put from. Those are stored in memory.
Vim offers settings to control *if* those registers are then stored.
So if you're like me, you have vim configured to not save registers
in your viminfo file, so the answer is "there is no file to edit".
Or maybe your configuration does write them.
> For future generations reading this.... vim writes back to
> ~/.viminfo when you run the :wq! command. So you need to edit
> viminfo in vi mode or another editor, otherwise it just overwrites
> your edits.
By default, this is stored in ~/.viminfo but as also mentioned, this
filename can be changed. So if you want to store your viminfo in
~/cthulu/is/my/copilot then the "n" parameter of 'viminfo' or setting
'viminfofile' will change that location.
By giving you this information and the further details in the
help-files, it arms you with the information you need regardless of
your configuration.
> also qf in a command starts a new macro @F
> where as qF just appends to the existing macro.
Again, this goes back to the understanding that macros are stored in
registers. As mentioned in
:help quote_alpha
using an uppercase register name (when yanking, deleting, or
recording a macro), it appends to the existing contents.
> It says this in the docs, but the language is not clear.
:help q
"""
q{0-9a-zA-Z"} Record typed characters into register
{0-9a-zA-Z"} (uppercase to append).
""
If you have suggestions for improving the text, it's possible they
could be included. But it seems pretty clear that using the
uppercase version appends to that register.
-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528113405.7a827584%40bigbox.attlocal.net.
> I just want to open the file and edit it.
Unless you have changed settings, it's stored in ~/.viminfo but it
can get overwritten upon quitting if you edit it while vim is
configured to (over)write it upon quitting. So if you plan to edit
it, you might want to
:set viminfo=
before quitting.
> Quoting back the manual for macros is significantly less polite in
> this context. If the manual and tutorials had what I wanted, or if
> I could discover the necessary file with find (and I don't know why
> that didn't work actually), I wouldn't have asked the question on
> the public mailing list. SO I asked specifically "where are they
> stored" They are stored in memory is sort of an answer.
The answers were an attempt to correct a misunderstanding that macros
were stored somewhere. Maybe they are, maybe they aren't. It
depends on your settings. So help-references were provided to arm
you with the understanding of how the pieces fit together.
Macros are not anything special. Just a register. Same as where you
yank/delete to and put from. Those are stored in memory.
Vim offers settings to control *if* those registers are then stored.
So if you're like me, you have vim configured to not save registers
in your viminfo file, so the answer is "there is no file to edit".
Or maybe your configuration does write them.
> For future generations reading this.... vim writes back to
> ~/.viminfo when you run the :wq! command. So you need to edit
> viminfo in vi mode or another editor, otherwise it just overwrites
> your edits.
By default, this is stored in ~/.viminfo but as also mentioned, this
filename can be changed. So if you want to store your viminfo in
~/cthulu/is/my/copilot then the "n" parameter of 'viminfo' or setting
'viminfofile' will change that location.
By giving you this information and the further details in the
help-files, it arms you with the information you need regardless of
your configuration.
> also qf in a command starts a new macro @F
> where as qF just appends to the existing macro.
Again, this goes back to the understanding that macros are stored in
registers. As mentioned in
:help quote_alpha
using an uppercase register name (when yanking, deleting, or
recording a macro), it appends to the existing contents.
> It says this in the docs, but the language is not clear.
:help q
"""
q{0-9a-zA-Z"} Record typed characters into register
{0-9a-zA-Z"} (uppercase to append).
""
If you have suggestions for improving the text, it's possible they
could be included. But it seems pretty clear that using the
uppercase version appends to that register.
-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528113405.7a827584%40bigbox.attlocal.net.
Re: Where are vim macros stored
On 5/28/21 10:47 AM, Karthick Gururaj wrote:
> I'm mostly an observer here - but..
> A. You should know you got a useful and correct response to your question
> B. If that is not the answer you are looking for, you should go back
> and check the question you asked.
> C. Entirely optional - but politeness goes a long way.
>
> You can "edit" the contents of the registers in many ways. You can
> even set the register directly with a :let
> :let @a="D"
> You can view it with an :echo @a
>
> However - if you are using registers for recording macros - the
> register may not have printable characters.
I just want to open the file and edit it. I don't want to go through
the manturations of vim, which is why I asked where they are stored.
You are right that politeness goes a long way, and so does the
politeness that requires short communication that is the point which is
exactly what I did.
Quoting back the manual for macros is significantly less polite in this
context. If the manual and tutorials had what I wanted, or if I could
discover the necessary file with find (and I don't know why that didn't
work actually), I wouldn't have asked the question on the public mailing
list. SO I asked specifically "where are they stored" They are stored
in memory is sort of an answer. They don't generate from the eether, so
they need to come from some file. I used to handle these things with
.vim, files or directly with vimrc in vim scripting language.
For future generations reading this.... vim writes back to ~/.viminfo
when you run the :wq! command. So you need to edit viminfo in vi mode
or another editor, otherwise it just overwrites your edits.
also qf in a command starts a new macro @F
where as qF just appends to the existing macro.
It says this in the docs, but the language is not clear.
Thanks for the help
Reuvain
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/7d9128d8-64ee-746b-2562-dd4572939ee6%40my.liu.edu.
> I'm mostly an observer here - but..
> A. You should know you got a useful and correct response to your question
> B. If that is not the answer you are looking for, you should go back
> and check the question you asked.
> C. Entirely optional - but politeness goes a long way.
>
> You can "edit" the contents of the registers in many ways. You can
> even set the register directly with a :let
> :let @a="D"
> You can view it with an :echo @a
>
> However - if you are using registers for recording macros - the
> register may not have printable characters.
I just want to open the file and edit it. I don't want to go through
the manturations of vim, which is why I asked where they are stored.
You are right that politeness goes a long way, and so does the
politeness that requires short communication that is the point which is
exactly what I did.
Quoting back the manual for macros is significantly less polite in this
context. If the manual and tutorials had what I wanted, or if I could
discover the necessary file with find (and I don't know why that didn't
work actually), I wouldn't have asked the question on the public mailing
list. SO I asked specifically "where are they stored" They are stored
in memory is sort of an answer. They don't generate from the eether, so
they need to come from some file. I used to handle these things with
.vim, files or directly with vimrc in vim scripting language.
For future generations reading this.... vim writes back to ~/.viminfo
when you run the :wq! command. So you need to edit viminfo in vi mode
or another editor, otherwise it just overwrites your edits.
also qf in a command starts a new macro @F
where as qF just appends to the existing macro.
It says this in the docs, but the language is not clear.
Thanks for the help
Reuvain
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/7d9128d8-64ee-746b-2562-dd4572939ee6%40my.liu.edu.
Re: Where are vim macros stored
On Fri, May 28, 2021 at 8:01 PM Ruben Safir <ruben.safir@my.liu.edu> wrote:
>
> On 5/28/21 10:21 AM, Tim Chase wrote:
> > On 2021-05-28 10:05, Ruben Safir wrote:
> >> On 5/28/21 10:02 AM, Christian Brabandt wrote:
> >>>> Where are the vim macros stored. I want to edit them by hand
> >>> in the register you specified.
> >>
> >> that is not the answer to the question I asked.
> >>
> >> Where are they STORED. Not how do I access them.
> >>
> >> Where on the filesystem are they stored.
> >
> > Christian answered your question: vim stores macros in *registers*.
>
> Which is where?
>
> ./.viminfo has command line history in it. The macros are stored in there?
I'm mostly an observer here - but..
A. You should know you got a useful and correct response to your question
B. If that is not the answer you are looking for, you should go back
and check the question you asked.
C. Entirely optional - but politeness goes a long way.
You can "edit" the contents of the registers in many ways. You can
even set the register directly with a :let
:let @a="D"
You can view it with an :echo @a
However - if you are using registers for recording macros - the
register may not have printable characters.
>
> >
> > However, vim optionally stores registers based on your 'viminfo'
> > setting: either in your ~/.viminfo (or in a different file if you
> > used the "n" option) or not at all. See
> >
> > :help viminfo-<
> > :help viminfo-n
> > :help viminfo-file
> >
> > -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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAPa-eGb%3D%3DvCyZ-cCag%2BxkkXbWiVeCw%3DjsRpLNs6w5sq6eCd7oQ%40mail.gmail.com.
>
> On 5/28/21 10:21 AM, Tim Chase wrote:
> > On 2021-05-28 10:05, Ruben Safir wrote:
> >> On 5/28/21 10:02 AM, Christian Brabandt wrote:
> >>>> Where are the vim macros stored. I want to edit them by hand
> >>> in the register you specified.
> >>
> >> that is not the answer to the question I asked.
> >>
> >> Where are they STORED. Not how do I access them.
> >>
> >> Where on the filesystem are they stored.
> >
> > Christian answered your question: vim stores macros in *registers*.
>
> Which is where?
>
> ./.viminfo has command line history in it. The macros are stored in there?
I'm mostly an observer here - but..
A. You should know you got a useful and correct response to your question
B. If that is not the answer you are looking for, you should go back
and check the question you asked.
C. Entirely optional - but politeness goes a long way.
You can "edit" the contents of the registers in many ways. You can
even set the register directly with a :let
:let @a="D"
You can view it with an :echo @a
However - if you are using registers for recording macros - the
register may not have printable characters.
>
> >
> > However, vim optionally stores registers based on your 'viminfo'
> > setting: either in your ~/.viminfo (or in a different file if you
> > used the "n" option) or not at all. See
> >
> > :help viminfo-<
> > :help viminfo-n
> > :help viminfo-file
> >
> > -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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAPa-eGb%3D%3DvCyZ-cCag%2BxkkXbWiVeCw%3DjsRpLNs6w5sq6eCd7oQ%40mail.gmail.com.
Re: Where are vim macros stored
On Fr, 28 Mai 2021, Ruben Safir wrote:
> On 5/28/21 10:21 AM, Tim Chase wrote:
> > On 2021-05-28 10:05, Ruben Safir wrote:
> >> On 5/28/21 10:02 AM, Christian Brabandt wrote:
> >>>> Where are the vim macros stored. I want to edit them by hand
> >>> in the register you specified.
> >>
> >> that is not the answer to the question I asked.
> >>
> >> Where are they STORED. Not how do I access them.
> >>
> >> Where on the filesystem are they stored.
> >
> > Christian answered your question: vim stores macros in *registers*.
>
> Which is where?
In memory. You can edit them by e.g. pasting them into a buffer,
changing them and them yanking them again into a register.
> ./.viminfo has command line history in it. The macros are stored in
> there?
Yes I think they can.
Best,
Christian
--
Kein Enthusiasmus der Liebe ist so groß als der der Zusammengewöhnung,
der auf jenen folgt.
-- 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528143613.GD1800871%40256bit.org.
> On 5/28/21 10:21 AM, Tim Chase wrote:
> > On 2021-05-28 10:05, Ruben Safir wrote:
> >> On 5/28/21 10:02 AM, Christian Brabandt wrote:
> >>>> Where are the vim macros stored. I want to edit them by hand
> >>> in the register you specified.
> >>
> >> that is not the answer to the question I asked.
> >>
> >> Where are they STORED. Not how do I access them.
> >>
> >> Where on the filesystem are they stored.
> >
> > Christian answered your question: vim stores macros in *registers*.
>
> Which is where?
In memory. You can edit them by e.g. pasting them into a buffer,
changing them and them yanking them again into a register.
> ./.viminfo has command line history in it. The macros are stored in
> there?
Yes I think they can.
Best,
Christian
--
Kein Enthusiasmus der Liebe ist so groß als der der Zusammengewöhnung,
der auf jenen folgt.
-- 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528143613.GD1800871%40256bit.org.
Re: Where are vim macros stored
On 5/28/21 10:21 AM, Tim Chase wrote:
> On 2021-05-28 10:05, Ruben Safir wrote:
>> On 5/28/21 10:02 AM, Christian Brabandt wrote:
>>>> Where are the vim macros stored. I want to edit them by hand
>>> in the register you specified.
>>
>> that is not the answer to the question I asked.
>>
>> Where are they STORED. Not how do I access them.
>>
>> Where on the filesystem are they stored.
>
> Christian answered your question: vim stores macros in *registers*.
Which is where?
./.viminfo has command line history in it. The macros are stored in there?
>
> However, vim optionally stores registers based on your 'viminfo'
> setting: either in your ~/.viminfo (or in a different file if you
> used the "n" option) or not at all. See
>
> :help viminfo-<
> :help viminfo-n
> :help viminfo-file
>
> -tim
>
>
>
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/18547d08-d49c-1d46-15f9-c0f5a9ac52e8%40my.liu.edu.
> On 2021-05-28 10:05, Ruben Safir wrote:
>> On 5/28/21 10:02 AM, Christian Brabandt wrote:
>>>> Where are the vim macros stored. I want to edit them by hand
>>> in the register you specified.
>>
>> that is not the answer to the question I asked.
>>
>> Where are they STORED. Not how do I access them.
>>
>> Where on the filesystem are they stored.
>
> Christian answered your question: vim stores macros in *registers*.
Which is where?
./.viminfo has command line history in it. The macros are stored in there?
>
> However, vim optionally stores registers based on your 'viminfo'
> setting: either in your ~/.viminfo (or in a different file if you
> used the "n" option) or not at all. See
>
> :help viminfo-<
> :help viminfo-n
> :help viminfo-file
>
> -tim
>
>
>
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/18547d08-d49c-1d46-15f9-c0f5a9ac52e8%40my.liu.edu.
Re: Where are vim macros stored
On 2021-05-28 10:05, Ruben Safir wrote:
> On 5/28/21 10:02 AM, Christian Brabandt wrote:
> >> Where are the vim macros stored. I want to edit them by hand
> > in the register you specified.
>
> that is not the answer to the question I asked.
>
> Where are they STORED. Not how do I access them.
>
> Where on the filesystem are they stored.
Christian answered your question: vim stores macros in *registers*.
However, vim optionally stores registers based on your 'viminfo'
setting: either in your ~/.viminfo (or in a different file if you
used the "n" option) or not at all. See
:help viminfo-<
:help viminfo-n
:help viminfo-file
-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528092119.1a154845%40bigbox.attlocal.net.
> On 5/28/21 10:02 AM, Christian Brabandt wrote:
> >> Where are the vim macros stored. I want to edit them by hand
> > in the register you specified.
>
> that is not the answer to the question I asked.
>
> Where are they STORED. Not how do I access them.
>
> Where on the filesystem are they stored.
Christian answered your question: vim stores macros in *registers*.
However, vim optionally stores registers based on your 'viminfo'
setting: either in your ~/.viminfo (or in a different file if you
used the "n" option) or not at all. See
:help viminfo-<
:help viminfo-n
:help viminfo-file
-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528092119.1a154845%40bigbox.attlocal.net.
Re: Where are vim macros stored
On 5/28/21 10:02 AM, Christian Brabandt wrote:
>> Where are the vim macros stored. I want to edit them by hand
> in the register you specified.
>
> Best,
> Christian
that is not the answer to the question I asked.
Where are they STORED. Not how do I access them.
Where on the filesystem are they stored.
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/056a373c-8e0c-aa13-97c7-b417496b1289%40my.liu.edu.
>> Where are the vim macros stored. I want to edit them by hand
> in the register you specified.
>
> Best,
> Christian
that is not the answer to the question I asked.
Where are they STORED. Not how do I access them.
Where on the filesystem are they stored.
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/056a373c-8e0c-aa13-97c7-b417496b1289%40my.liu.edu.
Re: Where are vim macros stored
On Fr, 28 Mai 2021, Ruben Safir wrote:
> Where are the vim macros stored. I want to edit them by hand
in the register you specified.
Best,
Christian
--
Beispiele, wie sich die Menschen über das Unerwartete, ja
Unerträgliche durch poetische Formen begütigen:
empirisch erscheinende absolute Gewalt
Oberon, Blaubart.
-- Goethe, Maximen und Reflektionen, Nr. 1311
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528140256.GC1800871%40256bit.org.
> Where are the vim macros stored. I want to edit them by hand
in the register you specified.
Best,
Christian
--
Beispiele, wie sich die Menschen über das Unerwartete, ja
Unerträgliche durch poetische Formen begütigen:
empirisch erscheinende absolute Gewalt
Oberon, Blaubart.
-- Goethe, Maximen und Reflektionen, Nr. 1311
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528140256.GC1800871%40256bit.org.
Where are vim macros stored
Where are the vim macros stored. I want to edit them by hand
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/d42e41c3-6f7c-99db-566b-dbb4867ec988%40my.liu.edu.
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/d42e41c3-6f7c-99db-566b-dbb4867ec988%40my.liu.edu.
Re: Insert non-rectangular selection
Andre Tann said on Tue, 25 May 2021 23:00:25 +0200
>Hi all,
>
>I repeatedly have the following situation, and wonder how it can be
>handled better than I do it now. These lines must be merged
>
>/path;text
>/path;text
>/path;text
>
>with these:
>
>/subdir
>/longsubdir
>/longlongsubdir
>
>Result:
>
>/path/subdir;text
>/path/longsubdir;text
>/path/longlongsubdir;text
>
>
>What I do now is to mark and yank the second block, go to the first
>semicolon, and press P. Result is:
>
>/path/subdir ;text
>/path/longsubdir ;text
>/path/longlongsubdir;text
>
>But this is obviously not what I want. How can I avoid the extra
>blanks?
I'd write a Python program to do this. Here's pseudocode of the main
loop:
until eof filea
read filea into stringa
read fileb into stringb
stringc = stringa + stringb
write stringc to filec
You'd also need to open and close the files, and you'd need an error
condition for the situation where the two files have a different number
of lines. But a different number of lines would be a horror movie for
the Vim solution too.
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528082423.449fd810%40mydesk.domain.cxm.
>Hi all,
>
>I repeatedly have the following situation, and wonder how it can be
>handled better than I do it now. These lines must be merged
>
>/path;text
>/path;text
>/path;text
>
>with these:
>
>/subdir
>/longsubdir
>/longlongsubdir
>
>Result:
>
>/path/subdir;text
>/path/longsubdir;text
>/path/longlongsubdir;text
>
>
>What I do now is to mark and yank the second block, go to the first
>semicolon, and press P. Result is:
>
>/path/subdir ;text
>/path/longsubdir ;text
>/path/longlongsubdir;text
>
>But this is obviously not what I want. How can I avoid the extra
>blanks?
I'd write a Python program to do this. Here's pseudocode of the main
loop:
until eof filea
read filea into stringa
read fileb into stringb
stringc = stringa + stringb
write stringc to filec
You'd also need to open and close the files, and you'd need an error
condition for the situation where the two files have a different number
of lines. But a different number of lines would be a horror movie for
the Vim solution too.
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210528082423.449fd810%40mydesk.domain.cxm.
Thursday, May 27, 2021
Re: Insert non-rectangular selection
Christian wrote:
> On Di, 25 Mai 2021, Andre Tann wrote:
>
> > Hi all,
> >
> > I repeatedly have the following situation, and wonder how it can be handled
> > better than I do it now. These lines must be merged
> >
> > /path/subdir ;text
> > /path/longsubdir ;text
> > /path/longlongsubdir;text
> >
> > with these:
> >
> > /subdir
> > /longsubdir
> > /longlongsubdir
> >
> > Result:
> >
> > /path/subdir;text
> > /path/longsubdir;text
> > /path/longlongsubdir;text
> >
> >
> > What I do now is to mark and yank the second block, go to the first
> > semicolon, and press P. Result is:
> >
> > /path/subdir ;text
> > /path/longsubdir ;text
> > /path/longlongsubdir;text
> >
> > But this is obviously not what I want. How can I avoid the extra blanks?
>
> I have this annoyance a few times as well. I would go with the already
> mentioned `:s` approach to remove the whitespace, afterwards. However, I
> was wondering, if we not could do any better any perhaps have something
> like a `zp` command, that does not add any trailing spaces.
This makes a lot of sense. I don't see a problem using "zp" and "zP"
for this.
Can you turn this into a pull request and add a test?
The example yanks until the end of the line, thus the register does not
contain trailing spaces. I wonder what to do when yanking halfway a
line, e.g. a column in a table:
texttext /subdir columntext
texttext /longsubdir columntext
texttext /longlongsubdir columntext
Here you can only yank a block including the spaces, and they would also
be inserted with "zp". Perhaps we should also have a "zy" command to
exclude the trailing spaces when yanking. I think that's better than
having "zp" drop spaces that were yanked.
--
5 out of 4 people have trouble with fractions.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105271129.14RBT7BW958367%40masaka.moolenaar.net.
> On Di, 25 Mai 2021, Andre Tann wrote:
>
> > Hi all,
> >
> > I repeatedly have the following situation, and wonder how it can be handled
> > better than I do it now. These lines must be merged
> >
> > /path/subdir ;text
> > /path/longsubdir ;text
> > /path/longlongsubdir;text
> >
> > with these:
> >
> > /subdir
> > /longsubdir
> > /longlongsubdir
> >
> > Result:
> >
> > /path/subdir;text
> > /path/longsubdir;text
> > /path/longlongsubdir;text
> >
> >
> > What I do now is to mark and yank the second block, go to the first
> > semicolon, and press P. Result is:
> >
> > /path/subdir ;text
> > /path/longsubdir ;text
> > /path/longlongsubdir;text
> >
> > But this is obviously not what I want. How can I avoid the extra blanks?
>
> I have this annoyance a few times as well. I would go with the already
> mentioned `:s` approach to remove the whitespace, afterwards. However, I
> was wondering, if we not could do any better any perhaps have something
> like a `zp` command, that does not add any trailing spaces.
This makes a lot of sense. I don't see a problem using "zp" and "zP"
for this.
Can you turn this into a pull request and add a test?
The example yanks until the end of the line, thus the register does not
contain trailing spaces. I wonder what to do when yanking halfway a
line, e.g. a column in a table:
texttext /subdir columntext
texttext /longsubdir columntext
texttext /longlongsubdir columntext
Here you can only yank a block including the spaces, and they would also
be inserted with "zp". Perhaps we should also have a "zy" command to
exclude the trailing spaces when yanking. I think that's better than
having "zp" drop spaces that were yanked.
--
5 out of 4 people have trouble with fractions.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202105271129.14RBT7BW958367%40masaka.moolenaar.net.
Re: Insert non-rectangular selection
On Di, 25 Mai 2021, Andre Tann wrote:
> Hi all,
>
> I repeatedly have the following situation, and wonder how it can be handled
> better than I do it now. These lines must be merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the first
> semicolon, and press P. Result is:
>
> /path/subdir ;text
> /path/longsubdir ;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the extra blanks?
I have this annoyance a few times as well. I would go with the already
mentioned `:s` approach to remove the whitespace, afterwards. However, I
was wondering, if we not could do any better any perhaps have something
like a `zp` command, that does not add any trailing spaces.
diff --git a/src/normal.c b/src/normal.c
index 92135c18c..25f8233bb 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -2973,6 +2973,10 @@ dozet:
}
break;
+ // "zp", "zP" in block mode put without addind trailing spaces
+ case 'P':
+ case 'p': nv_put(cap);
+ break;
#ifdef FEAT_FOLDING
// "zF": create fold command
// "zf": create fold operator
@@ -7407,11 +7411,13 @@ nv_put_opt(cmdarg_T *cap, int fix_indent)
}
else
dir = (cap->cmdchar == 'P'
- || (cap->cmdchar == 'g' && cap->nchar == 'P'))
- ? BACKWARD : FORWARD;
+ || ((cap->cmdchar == 'g' || cap->cmdchar == 'z')
+ && cap->nchar == 'P')) ? BACKWARD : FORWARD;
prep_redo_cmd(cap);
if (cap->cmdchar == 'g')
flags |= PUT_CURSEND;
+ else if (cap->cmdchar == 'z')
+ flags |= PUT_BLOCK_INNER;
if (VIsual_active)
{
diff --git a/src/register.c b/src/register.c
index 6ba4e896d..afa83cba8 100644
--- a/src/register.c
+++ b/src/register.c
@@ -1497,6 +1497,7 @@ copy_yank_reg(yankreg_T *reg)
* "flags": PUT_FIXINDENT make indent look nice
* PUT_CURSEND leave cursor after end of new text
* PUT_LINE force linewise put (":put")
+ * PUT_BLOCK_INNER in block mode, do not add trailing spaces
*/
void
do_put(
@@ -1845,12 +1846,17 @@ do_put(
yanklen = (int)STRLEN(y_array[i]);
- // calculate number of spaces required to fill right side of block
- spaces = y_width + 1;
- for (j = 0; j < yanklen; j++)
- spaces -= lbr_chartabsize(NULL, &y_array[i][j], 0);
- if (spaces < 0)
+ if (flags & PUT_BLOCK_INNER)
spaces = 0;
+ else
+ {
+ // calculate number of spaces required to fill right side of block
+ spaces = y_width + 1;
+ for (j = 0; j < yanklen; j++)
+ spaces -= lbr_chartabsize(NULL, &y_array[i][j], 0);
+ if (spaces < 0)
+ spaces = 0;
+ }
// insert the new text
totlen = count * (yanklen + spaces) + bd.startspaces + bd.endspaces;
diff --git a/src/vim.h b/src/vim.h
index 368cf3256..ef86312da 100644
--- a/src/vim.h
+++ b/src/vim.h
@@ -1068,6 +1068,7 @@ extern int (*dyn_libintl_wputenv)(const wchar_t *envstring);
#define PUT_LINE 8 // put register as lines
#define PUT_LINE_SPLIT 16 // split line for linewise register
#define PUT_LINE_FORWARD 32 // put linewise register below Visual sel.
+#define PUT_BLOCK_INNER 64 // in block mode, do not add trailing spaces
// flags for set_indent()
#define SIN_CHANGED 1 // call changed_bytes() when line changed
Mit freundlichen Grüßen
Christian
--
Werfen Sie leere Konservendosen nicht weg! Bewahren Sie sie auf! Nach
einigen Jahren haben Sie dann eine schöne Sammlung alter Konservendosen.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210527075859.GB1800871%40256bit.org.
> Hi all,
>
> I repeatedly have the following situation, and wonder how it can be handled
> better than I do it now. These lines must be merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the first
> semicolon, and press P. Result is:
>
> /path/subdir ;text
> /path/longsubdir ;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the extra blanks?
I have this annoyance a few times as well. I would go with the already
mentioned `:s` approach to remove the whitespace, afterwards. However, I
was wondering, if we not could do any better any perhaps have something
like a `zp` command, that does not add any trailing spaces.
diff --git a/src/normal.c b/src/normal.c
index 92135c18c..25f8233bb 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -2973,6 +2973,10 @@ dozet:
}
break;
+ // "zp", "zP" in block mode put without addind trailing spaces
+ case 'P':
+ case 'p': nv_put(cap);
+ break;
#ifdef FEAT_FOLDING
// "zF": create fold command
// "zf": create fold operator
@@ -7407,11 +7411,13 @@ nv_put_opt(cmdarg_T *cap, int fix_indent)
}
else
dir = (cap->cmdchar == 'P'
- || (cap->cmdchar == 'g' && cap->nchar == 'P'))
- ? BACKWARD : FORWARD;
+ || ((cap->cmdchar == 'g' || cap->cmdchar == 'z')
+ && cap->nchar == 'P')) ? BACKWARD : FORWARD;
prep_redo_cmd(cap);
if (cap->cmdchar == 'g')
flags |= PUT_CURSEND;
+ else if (cap->cmdchar == 'z')
+ flags |= PUT_BLOCK_INNER;
if (VIsual_active)
{
diff --git a/src/register.c b/src/register.c
index 6ba4e896d..afa83cba8 100644
--- a/src/register.c
+++ b/src/register.c
@@ -1497,6 +1497,7 @@ copy_yank_reg(yankreg_T *reg)
* "flags": PUT_FIXINDENT make indent look nice
* PUT_CURSEND leave cursor after end of new text
* PUT_LINE force linewise put (":put")
+ * PUT_BLOCK_INNER in block mode, do not add trailing spaces
*/
void
do_put(
@@ -1845,12 +1846,17 @@ do_put(
yanklen = (int)STRLEN(y_array[i]);
- // calculate number of spaces required to fill right side of block
- spaces = y_width + 1;
- for (j = 0; j < yanklen; j++)
- spaces -= lbr_chartabsize(NULL, &y_array[i][j], 0);
- if (spaces < 0)
+ if (flags & PUT_BLOCK_INNER)
spaces = 0;
+ else
+ {
+ // calculate number of spaces required to fill right side of block
+ spaces = y_width + 1;
+ for (j = 0; j < yanklen; j++)
+ spaces -= lbr_chartabsize(NULL, &y_array[i][j], 0);
+ if (spaces < 0)
+ spaces = 0;
+ }
// insert the new text
totlen = count * (yanklen + spaces) + bd.startspaces + bd.endspaces;
diff --git a/src/vim.h b/src/vim.h
index 368cf3256..ef86312da 100644
--- a/src/vim.h
+++ b/src/vim.h
@@ -1068,6 +1068,7 @@ extern int (*dyn_libintl_wputenv)(const wchar_t *envstring);
#define PUT_LINE 8 // put register as lines
#define PUT_LINE_SPLIT 16 // split line for linewise register
#define PUT_LINE_FORWARD 32 // put linewise register below Visual sel.
+#define PUT_BLOCK_INNER 64 // in block mode, do not add trailing spaces
// flags for set_indent()
#define SIN_CHANGED 1 // call changed_bytes() when line changed
Mit freundlichen Grüßen
Christian
--
Werfen Sie leere Konservendosen nicht weg! Bewahren Sie sie auf! Nach
einigen Jahren haben Sie dann eine schöne Sammlung alter Konservendosen.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210527075859.GB1800871%40256bit.org.
Wednesday, May 26, 2021
Re: Insert non-rectangular selection
:r! reply-body --top '/tmp/Re1BDLjSqOg3'
On Tue, 25 May 2021, Andre Tann <atann@alphasrv.net> wrote:
> I repeatedly have the following situation, and wonder how it can be
> handled better than I do it now. These lines must be merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the first
> semicolon, and press P. Result is:
>
> /path/subdir ;text
> /path/longsubdir ;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the extra blanks?
This is an interesting problem. I've personally found visual-block
yank / put most useful in ASCII art, where true rectangular blocks are a
feature. I see some tantalizing hints in the visual.txt help file about
padded with whitespace or not, but I can't get that to work for this
type of change.
Faced with a problem like this, I'd probably write a program to do the
change (possibly within the editor :'a,'e ! perl -wne '...' -- or
possibly as a separate true script), but I might also find a way to
do it with marks and macros. Maybe something like this tail-recursive
thing:
:map ## maf;'b"aDddmb`a"aPj0##
Set up mark b at the start of the /subdir area, move to the start of
the /path;text area and start
f; find the ;, hopefully will error out at end
ma set mark a
'b jump to mark b (start of line)
"pD delete to end of line, stored in p
dd delete now blank line
mb set a new mark b
`a return to mark a (mid line, on ; )
"pP put buffer p
j0 move to start of next line
## recurse
(Untested.)
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/4FqzFM5wzZzfYm%40panix5.panix.com.
On Tue, 25 May 2021, Andre Tann <atann@alphasrv.net> wrote:
> I repeatedly have the following situation, and wonder how it can be
> handled better than I do it now. These lines must be merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the first
> semicolon, and press P. Result is:
>
> /path/subdir ;text
> /path/longsubdir ;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the extra blanks?
This is an interesting problem. I've personally found visual-block
yank / put most useful in ASCII art, where true rectangular blocks are a
feature. I see some tantalizing hints in the visual.txt help file about
padded with whitespace or not, but I can't get that to work for this
type of change.
Faced with a problem like this, I'd probably write a program to do the
change (possibly within the editor :'a,'e ! perl -wne '...' -- or
possibly as a separate true script), but I might also find a way to
do it with marks and macros. Maybe something like this tail-recursive
thing:
:map ## maf;'b"aDddmb`a"aPj0##
Set up mark b at the start of the /subdir area, move to the start of
the /path;text area and start
f; find the ;, hopefully will error out at end
ma set mark a
'b jump to mark b (start of line)
"pD delete to end of line, stored in p
dd delete now blank line
mb set a new mark b
`a return to mark a (mid line, on ; )
"pP put buffer p
j0 move to start of next line
## recurse
(Untested.)
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/4FqzFM5wzZzfYm%40panix5.panix.com.
Re: Insert non-rectangular selection
On 26.05.21 15:49, arocker@Vex.Net wrote:
> That assumption is probably reasonable, but a semi-colon is a legal
> character in a Unix/Linux filename. (But should be reagarded as evidence
> of a psychopath loose in the department.) The only character not legal in
> a filename is "/".
...and the null byte, \x00.
The manual cleanup of the whitespaces is what I'm doing currently. But
it's a pain in the ass because the situation is more complex than
described, and the whitespaces are a bit tricky to catch with a regex.
Further I'm often dealing with dozens, if not hundreds of lines at a
time, making it difficult to see if the regex really matches what it should.
--
Andre Tann
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/b744ebba-a763-3c03-a22e-d5274c0fcd99%40alphasrv.net.
> That assumption is probably reasonable, but a semi-colon is a legal
> character in a Unix/Linux filename. (But should be reagarded as evidence
> of a psychopath loose in the department.) The only character not legal in
> a filename is "/".
...and the null byte, \x00.
The manual cleanup of the whitespaces is what I'm doing currently. But
it's a pain in the ass because the situation is more complex than
described, and the whitespaces are a bit tricky to catch with a regex.
Further I'm often dealing with dozens, if not hundreds of lines at a
time, making it difficult to see if the regex really matches what it should.
--
Andre Tann
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/b744ebba-a763-3c03-a22e-d5274c0fcd99%40alphasrv.net.
Re: Insert non-rectangular selection
> this applies only to the first semi-colon on each line (which
> will always exist in your situation and by assumption won't be
> found in the paths).
>
That assumption is probably reasonable, but a semi-colon is a legal
character in a Unix/Linux filename. (But should be reagarded as evidence
of a psychopath loose in the department.) The only character not legal in
a filename is "/".
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/429e6824d676bd29924cfba021aa75b4.squirrel%40webmail.vybenetworks.com.
> will always exist in your situation and by assumption won't be
> found in the paths).
>
That assumption is probably reasonable, but a semi-colon is a legal
character in a Unix/Linux filename. (But should be reagarded as evidence
of a psychopath loose in the department.) The only character not legal in
a filename is "/".
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/429e6824d676bd29924cfba021aa75b4.squirrel%40webmail.vybenetworks.com.
Re: Insert non-rectangular selection
On 5/25/21 4:54 PM, Andre Tann wrote:
> I repeatedly have the following situation, and wonder how it
> can be handled better than I do it now. These lines must be
> merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the
> first semicolon, and press P. Result is:
>
> /path/subdir ;text
> /path/longsubdir ;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the
> extra blanks?
One option might be to remove the spaces after pasting.
Assuming that none of the paths themselves contain a semi-colon,
you could visually select the lines of text and run this
substitute command::
:'<,'>s/ *;/;/
This finds zero or more spaces followed by a semi-colon and
replaces with just the semi-colon. It has no ``g`` flag, so
this applies only to the first semi-colon on each line (which
will always exist in your situation and by assumption won't be
found in the paths).
Michael Henry
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/753cc134-cef6-67a2-9596-9d51e0ab26d2%40drmikehenry.com.
> I repeatedly have the following situation, and wonder how it
> can be handled better than I do it now. These lines must be
> merged
>
> /path;text
> /path;text
> /path;text
>
> with these:
>
> /subdir
> /longsubdir
> /longlongsubdir
>
> Result:
>
> /path/subdir;text
> /path/longsubdir;text
> /path/longlongsubdir;text
>
>
> What I do now is to mark and yank the second block, go to the
> first semicolon, and press P. Result is:
>
> /path/subdir ;text
> /path/longsubdir ;text
> /path/longlongsubdir;text
>
> But this is obviously not what I want. How can I avoid the
> extra blanks?
One option might be to remove the spaces after pasting.
Assuming that none of the paths themselves contain a semi-colon,
you could visually select the lines of text and run this
substitute command::
:'<,'>s/ *;/;/
This finds zero or more spaces followed by a semi-colon and
replaces with just the semi-colon. It has no ``g`` flag, so
this applies only to the first semi-colon on each line (which
will always exist in your situation and by assumption won't be
found in the paths).
Michael Henry
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/753cc134-cef6-67a2-9596-9d51e0ab26d2%40drmikehenry.com.
Tuesday, May 25, 2021
Insert non-rectangular selection
Hi all,
I repeatedly have the following situation, and wonder how it can be
handled better than I do it now. These lines must be merged
/path;text
/path;text
/path;text
with these:
/subdir
/longsubdir
/longlongsubdir
Result:
/path/subdir;text
/path/longsubdir;text
/path/longlongsubdir;text
What I do now is to mark and yank the second block, go to the first
semicolon, and press P. Result is:
/path/subdir ;text
/path/longsubdir ;text
/path/longlongsubdir;text
But this is obviously not what I want. How can I avoid the extra blanks?
--
Andre Tann
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6af9cfec-bd59-25b3-45c9-98d72c80c62e%40alphasrv.net.
I repeatedly have the following situation, and wonder how it can be
handled better than I do it now. These lines must be merged
/path;text
/path;text
/path;text
with these:
/subdir
/longsubdir
/longlongsubdir
Result:
/path/subdir;text
/path/longsubdir;text
/path/longlongsubdir;text
What I do now is to mark and yank the second block, go to the first
semicolon, and press P. Result is:
/path/subdir ;text
/path/longsubdir ;text
/path/longlongsubdir;text
But this is obviously not what I want. How can I avoid the extra blanks?
--
Andre Tann
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6af9cfec-bd59-25b3-45c9-98d72c80c62e%40alphasrv.net.
Insert non-rectangular selection
Hi all,
I repeatedly have the following situation, and wonder how it can be
handled better than I do it now. These lines must be merged
/path;text
/path;text
/path;text
with these:
/subdir
/longsubdir
/longlongsubdir
Result:
/path/subdir;text
/path/longsubdir;text
/path/longlongsubdir;text
What I do now is to mark and yank the second block, go to the first
semicolon, and press P. Result is:
/path/subdir ;text
/path/longsubdir ;text
/path/longlongsubdir;text
But this is obviously not what I want. How can I avoid the extra blanks?
--
Andre Tann
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/fbfcf85d-69db-667e-7d3f-3d7ddce60f95%40alphasrv.net.
I repeatedly have the following situation, and wonder how it can be
handled better than I do it now. These lines must be merged
/path;text
/path;text
/path;text
with these:
/subdir
/longsubdir
/longlongsubdir
Result:
/path/subdir;text
/path/longsubdir;text
/path/longlongsubdir;text
What I do now is to mark and yank the second block, go to the first
semicolon, and press P. Result is:
/path/subdir ;text
/path/longsubdir ;text
/path/longlongsubdir;text
But this is obviously not what I want. How can I avoid the extra blanks?
--
Andre Tann
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/fbfcf85d-69db-667e-7d3f-3d7ddce60f95%40alphasrv.net.
Saturday, May 22, 2021
Re: Bug/inconsistency in /\%'/ in linewise-vs-characterwise?
On 2021-05-23 00:25, Bram Moolenaar wrote:
> Tim Chase wrote:
>> /\%'<\_.\{-}\%'>/
>>
>> So then I highlighted some text in *linewise* visual mode ("V")
>> and hit <esc> and the highlight was removed. Using "n" to search
>> for the next match gave me an
>>
>> E486: Pattern not found: \%'<\_.\{-}\%'>
>
> I guess the problem is that the '> mark is at "MAXCOL". That means
> "at the end of the line". But that position doesn't actually
> exist, so searching for "\%'>" fails.
>
> It probably works better when \%'> matches just beyond the last
> character of the line, like /\n does. You can create an issue for
> that.
That makes sense. Done:
https://github.com/vim/vim/issues/8238
(linking here just in case anybody else stumbles on this thread and
wants to follow along)
Thanks for looking into it.
-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210522175820.5bf7f140%40bigbox.attlocal.net.
> Tim Chase wrote:
>> /\%'<\_.\{-}\%'>/
>>
>> So then I highlighted some text in *linewise* visual mode ("V")
>> and hit <esc> and the highlight was removed. Using "n" to search
>> for the next match gave me an
>>
>> E486: Pattern not found: \%'<\_.\{-}\%'>
>
> I guess the problem is that the '> mark is at "MAXCOL". That means
> "at the end of the line". But that position doesn't actually
> exist, so searching for "\%'>" fails.
>
> It probably works better when \%'> matches just beyond the last
> character of the line, like /\n does. You can create an issue for
> that.
That makes sense. Done:
https://github.com/vim/vim/issues/8238
(linking here just in case anybody else stumbles on this thread and
wants to follow along)
Thanks for looking into it.
-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20210522175820.5bf7f140%40bigbox.attlocal.net.
Subscribe to:
Posts (Atom)