Re: [vim/vim] 3 issues in vim9script 'import' after yesterday's refactor (Issue #9490)
Hi, On Tue, Feb 1, 2022 at 8:05 AM Bram Moolenaar wrote: > > > v8.2.4264 revoked the '#' style function name in vim9, but: > > 1, that made some complex to call such vim9 func in legacy vim script > > e.g vimrc. > > I don't see how. You can still call the autoload function using the # > form. > The recent changes to disallow the use of '#' in a function name and the changes to the import mechanism resulted in quite a bit of changes to the LSP Vim9 plugin. You can see the impact in the following commits: https://github.com/yegappan/lsp/commit/aeede042a93441f038f6b36448aaf383969bc86b https://github.com/yegappan/lsp/commit/d7105d210391ad8fe3733d81f048df7a970b2488 In particular look at the changes to the plugin/lsp.vim. As all the users may not have the latest Vim, the plugin needs to support an older version of Vim and the latest version. This is difficult. Regards, Yegappan > > > 2, that exported func name had to be 'Uppercase' first letter? > > ```vim > > - func auto9#getsome() > > + export func Getsome() > > ``` > > Yes, that is intentional. In legacy script there was an inconsistency, > allowing lower case function names. It was OK there since you always > had to prefix "scriptname#". But in Vim9 script you can call the > function without the prefix inside the script, therefore the leading > capital is required. > > > 3, in some languages, if that first letter of function name is > > Uppercase, that means 'public' already, as my understanding, if it do > > req 'Uppercase' then maybe no req 'export' keyword?! > > No, we do not do it that way. > > > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAAW7x7kreO2UqUiM9pxvq9VTNhKnjg9JL7A_H0kNs%3DbaqWkQ5Q%40mail.gmail.com.
Patch 8.2.4282
Patch 8.2.4282
Problem:Restricted mode requires the -Z command line option.
Solution: Use restricted mode when $SHELL ends in "nologin" or "false".
(closes #9681)
Files: runtime/doc/starting.txt, src/option.c,
src/testdir/test_restricted.vim
*** ../vim-8.2.4281/runtime/doc/starting.txt2021-05-29 18:53:46.455055663
+0100
--- runtime/doc/starting.txt2022-02-01 17:23:57.358435792 +
***
*** 256,261
--- 256,263
Interfaces, such as Python, Ruby and Lua, are also disabled,
since they could be used to execute shell commands. Perl uses
the Safe module.
+ For Unix restricted mode is used when the last part of $SHELL
+ is "nologin" or "false".
Note that the user may still find a loophole to execute a
shell command, it has only been made difficult.
*** ../vim-8.2.4281/src/option.c2022-01-31 14:59:33.518943700 +
--- src/option.c2022-02-01 17:17:15.275300416 +
***
*** 307,312
--- 307,323
*/
set_options_default(0);
+ #ifdef UNIX
+ // Force restricted-mode on for "nologin" or "false" $SHELL
+ p = get_isolated_shell_name();
+ if (p != NULL)
+ {
+ if (fnamecmp(p, "nologin") == 0 || fnamecmp(p, "false") == 0)
+ restricted = TRUE;
+ vim_free(p);
+ }
+ #endif
+
#ifdef CLEAN_RUNTIMEPATH
if (clean_arg)
{
*** ../vim-8.2.4281/src/testdir/test_restricted.vim 2020-03-30
18:36:42.851754324 +0100
--- src/testdir/test_restricted.vim 2022-02-01 17:22:29.774654429 +
***
*** 105,110
--- 105,118
if RunVim([], [], '-Z --clean -S Xrestricted')
call assert_equal([], readfile('Xresult'))
endif
+ call delete('Xresult')
+ if has('unix') && RunVimPiped([], [], '--clean -S Xrestricted',
'SHELL=/bin/false ')
+ call assert_equal([], readfile('Xresult'))
+ endif
+ call delete('Xresult')
+ if has('unix') && RunVimPiped([], [], '--clean -S Xrestricted',
'SHELL=/sbin/nologin')
+ call assert_equal([], readfile('Xresult'))
+ endif
call delete('Xrestricted')
call delete('Xresult')
*** ../vim-8.2.4281/src/version.c 2022-02-01 13:54:11.651302024 +
--- src/version.c 2022-02-01 17:24:13.534396192 +
***
*** 748,749
--- 748,751
{ /* Add new patch number below this line */
+ /**/
+ 4282,
/**/
--
Team-building exercises come in many forms but they all trace their roots back
to the prison system. In your typical team-building exercise the employees
are subjected to a variety of unpleasant situations until they become either a
cohesive team or a ring of car jackers.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- b...@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_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20220201172650.227321C1771%40moolenaar.net.
Re: Build of 8.2.4277 failed
* Bram Moolenaar [2022-02-01 10:17 +]: > > Elimar Riesebieter wrote: > > > my build of 8.2.4277 failed. > > > > CC=clang-13 > > Term=tmux > > > > /usr/bin/ld: objects/testing.o: in function `test_gui_find_repl': > > ./src/vim-athena/testing.c:1354: undefined reference to `gui_do_findrepl' > > clang: error: linker command failed with exit code 1 (use -v to see > > invocation) > > link.sh: Linking failed > > The Athena GUI doesn't have a find/replace dialog. I'll add #ifdefs. Fixed! Many thanks :-) Elimar -- 355/113: Not the famous irrational number pi, but an incredible simulation! -unknown -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220201165753.tqrx43ye2vlhuikr%40baumbart.home.lxtec.de.
Re: doesn't make sure the visual marks are updated
Somehow I missed that, and I apologize. This solves my problem.
On Tue, Feb 1, 2022 at 9:04 AM Bram Moolenaar wrote:
>
> Christian J. Robinson wrote:
>
> > I have attached a demonstration script. If you edit then source it in a
> new
> > Vim instance you will get "0 0" then "1 1" echoed into the message
> history,
> > but it should be "1 1" then "2 2".
> >
> > If you change the \test mapping to have a preceding in the rhs, you
> > get the expected output, which is "1 1" then "2 2".
>
> This is unlreated to using . While Visual mode is active the
> '< and '> marks are still set to the previously selected text. This is
> mentioned at the help for these marks.
>
> Instead of using that, you can use line('v'). The help for that:
>
> v In Visual mode: the start of the Visual area
> (the
> cursor is the end). When not in Visual mode
> returns the cursor position. Differs from
> |'<| in
> that it's updated right away.
>
>
> --
> Lower life forms have more fun!
>
> /// Bram Moolenaar -- b...@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
> ///
>
--
Christian J. Robinson
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CAK14FZ%2B7W8RBa8VHf5uTwQ9o_y18fS8pSefGL7pO8ni5XAFHXg%40mail.gmail.com.
Re: doesn't make sure the visual marks are updated
Christian J. Robinson wrote:
> I have attached a demonstration script. If you edit then source it in a new
> Vim instance you will get "0 0" then "1 1" echoed into the message history,
> but it should be "1 1" then "2 2".
>
> If you change the \test mapping to have a preceding in the rhs, you
> get the expected output, which is "1 1" then "2 2".
This is unlreated to using . While Visual mode is active the
'< and '> marks are still set to the previously selected text. This is
mentioned at the help for these marks.
Instead of using that, you can use line('v'). The help for that:
v In Visual mode: the start of the Visual area (the
cursor is the end). When not in Visual mode
returns the cursor position. Differs from |'<| in
that it's updated right away.
--
Lower life forms have more fun!
/// Bram Moolenaar -- b...@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_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20220201160437.4055A1C1775%40moolenaar.net.
Re: doesn't make sure the visual marks are updated
I have attached a demonstration script. If you edit then source it in a new Vim instance you will get "0 0" then "1 1" echoed into the message history, but it should be "1 1" then "2 2". If you change the \test mapping to have a preceding in the rhs, you get the expected output, which is "1 1" then "2 2". On Tue, Feb 1, 2022 at 4:13 AM Bram Moolenaar wrote: > > Christian J. Robinson wrote: > > > I have several visual mappings that could benefit from but > they > > call functions that rely on the `< and `> marks to be properly set, and > > doesn't make sure they are "current" so the marks from a > > previous visual selection are used. > > > > If I prefix the with the marks update. > > > > It took me a while to figure this out as the behavior was so strange to > me > > (and my mappings/functions are fairly complex). > > I don't understand what you mean. The mapping doesn't do > anything with the '< and '> marks. And I don't see how CTRL-C does > anything but end Visual mode. > > The idea with is that it can be used in any mode and returns > to that mode after doing its work. > > -- > Never under any circumstances take a sleeping pill > and a laxative on the same night. > > /// Bram Moolenaar -- b...@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 > /// > -- Christian J. Robinson -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAK14FZKzVR-ByeRQVPobWkJw%3DhsWM%2B93KxzULUXKiUMrSYxb3w%40mail.gmail.com. scriptcmd_visual_bug.vim Description: Binary data
Patch 8.2.4281
Patch 8.2.4281
Problem:Using freed memory with :lopen and :bwipe.
Solution: Do not use a wiped out buffer.
Files: src/buffer.c, src/testdir/test_quickfix.vim
*** ../vim-8.2.4280/src/buffer.c2022-01-28 15:28:00.200927841 +
--- src/buffer.c2022-02-01 13:52:22.188928452 +
***
*** 1706,1711
--- 1706,1712
#endif
bufref_T newbufref;
bufref_T prevbufref;
+ int valid;
setpcmark();
if ((cmdmod.cmod_flags & CMOD_KEEPALT) == 0)
***
*** 1763,1775
// An autocommand may have deleted "buf", already entered it (e.g., when
// it did ":bunload") or aborted the script processing.
// If curwin->w_buffer is null, enter_buffer() will make it valid again
! if ((buf_valid(buf) && buf != curbuf
#ifdef FEAT_EVAL
&& !aborting()
#endif
) || curwin->w_buffer == NULL)
{
! enter_buffer(buf);
#ifdef FEAT_SYN_HL
if (old_tw != curbuf->b_p_tw)
check_colorcolumn(curwin);
--- 1764,1782
// An autocommand may have deleted "buf", already entered it (e.g., when
// it did ":bunload") or aborted the script processing.
// If curwin->w_buffer is null, enter_buffer() will make it valid again
! valid = buf_valid(buf);
! if ((valid && buf != curbuf
#ifdef FEAT_EVAL
&& !aborting()
#endif
) || curwin->w_buffer == NULL)
{
! // If the buffer is not valid but curwin->w_buffer is NULL we must
! // enter some buffer. Using the last one is hopefully OK.
! if (!valid)
! enter_buffer(lastbuf);
! else
! enter_buffer(buf);
#ifdef FEAT_SYN_HL
if (old_tw != curbuf->b_p_tw)
check_colorcolumn(curwin);
***
*** 2288,2295
clear_string_option(>b_p_vsts);
vim_free(buf->b_p_vsts_nopaste);
buf->b_p_vsts_nopaste = NULL;
! vim_free(buf->b_p_vsts_array);
! buf->b_p_vsts_array = NULL;
clear_string_option(>b_p_vts);
VIM_CLEAR(buf->b_p_vts_array);
#endif
--- 2295,2301
clear_string_option(>b_p_vsts);
vim_free(buf->b_p_vsts_nopaste);
buf->b_p_vsts_nopaste = NULL;
! VIM_CLEAR(buf->b_p_vsts_array);
clear_string_option(>b_p_vts);
VIM_CLEAR(buf->b_p_vts_array);
#endif
*** ../vim-8.2.4280/src/testdir/test_quickfix.vim 2022-01-29
21:45:30.485921485 +
--- src/testdir/test_quickfix.vim 2022-02-01 13:50:21.562719876 +
***
*** 979,984
--- 979,985
call assert_fails('lrewind', 'E924:')
augroup! testgroup
+ delfunc R
endfunc
func Test_locationlist_cross_tab_jump()
***
*** 5835,5838
--- 5836,5855
%bw!
endfunc
+ " Weird sequence of commands that caused entering a wiped-out buffer
+ func Test_lopen_bwipe()
+ func R()
+ silent! tab lopen
+ e x
+ silent! lfile
+ endfunc
+
+ cal R()
+ cal R()
+ cal R()
+ bw!
+ delfunc R
+ endfunc
+
+
" vim: shiftwidth=2 sts=2 expandtab
*** ../vim-8.2.4280/src/version.c 2022-02-01 12:47:03.775540464 +
--- src/version.c 2022-02-01 13:43:37.212714666 +
***
*** 748,749
--- 748,751
{ /* Add new patch number below this line */
+ /**/
+ 4281,
/**/
--
Are leaders born or made? And if they're made, can we return them under
warranty?
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- b...@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_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20220201135454.8200E1C0809%40moolenaar.net.
Patch 8.2.4280
Patch 8.2.4280 (after 8.2.4279)
Problem:list-dict test crashes.
Solution: Check declared type for add().
Files: src/vim9expr.vim
*** ../vim-8.2.4279/src/vim9expr.c 2022-01-30 15:28:26.642295028 +
--- src/vim9expr.c 2022-02-01 12:44:14.550051881 +
***
*** 759,765
if (STRCMP(name, "add") == 0 && argcount == 2)
{
! type_T *type = get_type_on_stack(cctx, 1);
// add() can be compiled to instructions if we know the type
if (type->tt_type == VAR_LIST)
--- 759,765
if (STRCMP(name, "add") == 0 && argcount == 2)
{
! type_T *type = get_decl_type_on_stack(cctx, 1);
// add() can be compiled to instructions if we know the type
if (type->tt_type == VAR_LIST)
*** ../vim-8.2.4279/src/version.c 2022-02-01 12:11:53.447041944 +
--- src/version.c 2022-02-01 12:46:52.595706360 +
***
*** 748,749
--- 748,751
{ /* Add new patch number below this line */
+ /**/
+ 4280,
/**/
--
Scientists decoded the first message from an alien civilization:
SIMPLY SEND 6 TIMES 10 TO THE 50 ATOMS OF HYDROGEN TO THE STAR
SYSTEM AT THE TOP OF THE LIST, CROSS OFF THAT STAR SYSTEM, THEN PUT
YOUR STAR SYSTEM AT THE BOTTOM OF THE LIST AND SEND IT TO 100 OTHER
STAR SYSTEMS. WITHIN ONE TENTH GALACTIC ROTATION YOU WILL RECEIVE
ENOUGH HYDROGREN TO POWER YOUR CIVILIZATION UNTIL ENTROPY REACHES ITS
MAXIMUM! IT REALLY WORKS!
/// Bram Moolenaar -- b...@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_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20220201124827.3B8BC1C1918%40moolenaar.net.
Patch 8.2.4279
Patch 8.2.4279
Problem:Vim9: cannot change item type with map() after range().
Solution: Split the return type in current type and declared type.
(closes #9665)
Files: src/evalfunc.c, src/proto/evalfunc.pro, src/vim9instr.c,
src/vim9type.c, src/proto/vim9type.pro,
src/testdir/test_vim9_builtin.vim
*** ../vim-8.2.4278/src/evalfunc.c 2022-01-31 17:39:45.394105533 +
--- src/evalfunc.c 2022-02-01 12:01:21.488896698 +
***
*** 992,1118
* Note that "argtypes" is NULL if "argcount" is zero.
*/
static type_T *
! ret_void(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _void;
}
static type_T *
! ret_any(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _any;
}
static type_T *
! ret_bool(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _bool;
}
static type_T *
! ret_number_bool(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _number_bool;
}
static type_T *
! ret_number(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _number;
}
static type_T *
! ret_float(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _float;
}
static type_T *
! ret_string(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _string;
}
static type_T *
! ret_list_any(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _list_any;
}
static type_T *
! ret_list_number(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _list_number;
}
static type_T *
! ret_list_string(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _list_string;
}
static type_T *
! ret_list_dict_any(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _list_dict_any;
}
static type_T *
! ret_list_items(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _list_list_any;
}
static type_T *
! ret_list_string_items(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _list_list_string;
}
static type_T *
! ret_dict_any(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _dict_any;
}
static type_T *
! ret_job_info(int argcount, type2_T *argtypes UNUSED)
{
if (argcount == 0)
return _list_job;
return _dict_any;
}
static type_T *
! ret_dict_number(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _dict_number;
}
static type_T *
! ret_dict_string(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _dict_string;
}
static type_T *
! ret_blob(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _blob;
}
static type_T *
! ret_func_any(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _func_any;
}
static type_T *
! ret_func_unknown(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _func_unknown;
}
static type_T *
! ret_channel(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _channel;
}
static type_T *
! ret_job(int argcount UNUSED, type2_T *argtypes UNUSED)
{
return _job;
}
static type_T *
! ret_first_arg(int argcount, type2_T *argtypes)
{
if (argcount > 0)
return argtypes[0].type_curr;
return _void;
}
static type_T *
! ret_repeat(int argcount, type2_T *argtypes)
{
if (argcount == 0)
return _any;
--- 992,1200
* Note that "argtypes" is NULL if "argcount" is zero.
*/
static type_T *
! ret_void(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _void;
}
static type_T *
! ret_any(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _any;
}
static type_T *
! ret_bool(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _bool;
}
static type_T *
! ret_number_bool(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _number_bool;
}
static type_T *
! ret_number(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _number;
}
static type_T *
! ret_float(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _float;
}
static type_T *
! ret_string(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _string;
}
static type_T *
! ret_list_any(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _list_any;
}
static type_T *
! ret_list_number(int argcount UNUSED,
! type2_T *argtypes UNUSED,
! type_T **decl_type UNUSED)
{
return _list_number;
}
static type_T *
!
Re: doesn't make sure the visual marks are updated
Christian J. Robinson wrote: > I have several visual mappings that could benefit from but they > call functions that rely on the `< and `> marks to be properly set, and > doesn't make sure they are "current" so the marks from a > previous visual selection are used. > > If I prefix the with the marks update. > > It took me a while to figure this out as the behavior was so strange to me > (and my mappings/functions are fairly complex). I don't understand what you mean. The mapping doesn't do anything with the '< and '> marks. And I don't see how CTRL-C does anything but end Visual mode. The idea with is that it can be used in any mode and returns to that mode after doing its work. -- Never under any circumstances take a sleeping pill and a laxative on the same night. /// Bram Moolenaar -- b...@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_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2022020333.1346D1C1918%40moolenaar.net.
Patch 8.2.4278
Patch 8.2.4278
Problem:Build with Athena GUI fails. (Elimar Riesebieter)
Solution: Add #ifdef.
Files: src/testing.c
*** ../vim-8.2.4277/src/testing.c 2022-01-31 17:39:45.394105533 +
--- src/testing.c 2022-02-01 10:12:44.551093682 +
***
*** 1331,1336
--- 1331,1337
return TRUE;
}
+ #if defined(FIND_REPLACE_DIALOG)
static int
test_gui_find_repl(dict_T *args)
{
***
*** 1357,1362
--- 1358,1364
return retval;
}
+ #endif
static int
test_gui_mouse_event(dict_T *args)
***
*** 1476,1483
--- 1478,1487
event = tv_get_string([0]);
if (STRCMP(event, "dropfiles") == 0)
rettv->vval.v_number = test_gui_drop_files(argvars[1].vval.v_dict);
+ # if defined(FIND_REPLACE_DIALOG)
else if (STRCMP(event, "findrepl") == 0)
rettv->vval.v_number = test_gui_find_repl(argvars[1].vval.v_dict);
+ # endif
else if (STRCMP(event, "mouse") == 0)
rettv->vval.v_number = test_gui_mouse_event(argvars[1].vval.v_dict);
else if (STRCMP(event, "scrollbar") == 0)
*** ../vim-8.2.4277/src/version.c 2022-01-31 18:59:09.844105727 +
--- src/version.c 2022-02-01 10:15:21.068537971 +
***
*** 748,749
--- 748,751
{ /* Add new patch number below this line */
+ /**/
+ 4278,
/**/
--
BEDEVERE: Wait. Wait ... tell me, what also floats on water?
ALL: Bread? No, no, no. Apples gravy ... very small rocks ...
ARTHUR: A duck.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@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_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20220201101754.9C78E1C0284%40moolenaar.net.
Re: Build of 8.2.4277 failed
Elimar Riesebieter wrote: > my build of 8.2.4277 failed. > > CC=clang-13 > Term=tmux > > /usr/bin/ld: objects/testing.o: in function `test_gui_find_repl': > ./src/vim-athena/testing.c:1354: undefined reference to `gui_do_findrepl' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > link.sh: Linking failed The Athena GUI doesn't have a find/replace dialog. I'll add #ifdefs. -- BEDEVERE:And what do you burn, apart from witches? FOURTH VILLAGER: ... Wood? BEDEVERE:So why do witches burn? SECOND VILLAGER: (pianissimo) ... Because they're made of wood...? "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@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_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220201101754.97C021C1918%40moolenaar.net.
