Re: Choices for Vim9 class implementation
понедельник, 19 декабря 2022 г. в 00:33:24 UTC+11, Bram Moolenaar:
>
>
>
>
> For object members most languages use the "this." prefix. But not
> everywhere, which makes it inconsistent. A good example is a
> constructor where object members that are also an argument need to be
> prefixed with "this." to avoid a name collision, while other object
> members are used without "this.". I find that very confusing. Example:
>
> SomeObject(String name)
> {
> this.name = name;
> gender = Gender.unknown;
> }
>
>
I would go with this.name and this.gender while accessing the variables.
>
> One thing I'm not yet sure about is the declaration. Currently it works
> like this:
>
> this.name: string
> this.gender: Gender
>
> and
var name: string
var gender: Gender
to declare them.
--
--
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/5e7c4f18-1652-45b8-9f24-bf5bba8df051n%40googlegroups.com.
Patch 9.0.1075
Patch 9.0.1075 (after 9.0.1074)
Problem:build fails if the compiler doesn't allow for a declaration right
after "case".
Solution: Add a block.
Files: src/vim9instr.c
*** ../vim-9.0.1074/src/vim9instr.c 2022-12-18 21:42:49.014716925 +
--- src/vim9instr.c 2022-12-18 22:00:56.013961567 +
***
*** 2188,2216
case dest_vimvar:
return generate_STORE(cctx, ISN_STOREV, vimvaridx, NULL);
case dest_script:
- int scriptvar_idx = lhs->lhs_scriptvar_idx;
- int scriptvar_sid = lhs->lhs_scriptvar_sid;
- if (scriptvar_idx < 0)
{
! isntype_T isn_type = ISN_STORES;
! if (SCRIPT_ID_VALID(scriptvar_sid)
!&& SCRIPT_ITEM(scriptvar_sid)->sn_import_autoload
!&& SCRIPT_ITEM(scriptvar_sid)->sn_autoload_prefix
== NULL)
! {
! // "import autoload './dir/script.vim'" - load script first
! if (generate_SOURCE(cctx, scriptvar_sid) == FAIL)
! return FAIL;
! isn_type = ISN_STOREEXPORT;
! }
! // "s:" may be included in the name.
! return generate_OLDSCRIPT(cctx, isn_type, name,
! scriptvar_sid, type);
! }
! return generate_VIM9SCRIPT(cctx, ISN_STORESCRIPT,
scriptvar_sid, scriptvar_idx, type);
case dest_class_member:
return generate_CLASSMEMBER(cctx, FALSE,
lhs->lhs_class, lhs->lhs_classmember_idx);
--- 2188,2219
case dest_vimvar:
return generate_STORE(cctx, ISN_STOREV, vimvaridx, NULL);
case dest_script:
{
! int scriptvar_idx = lhs->lhs_scriptvar_idx;
! int scriptvar_sid = lhs->lhs_scriptvar_sid;
! if (scriptvar_idx < 0)
! {
! isntype_T isn_type = ISN_STORES;
! if (SCRIPT_ID_VALID(scriptvar_sid)
!&& SCRIPT_ITEM(scriptvar_sid)->sn_import_autoload
!&& SCRIPT_ITEM(scriptvar_sid)->sn_autoload_prefix
== NULL)
! {
! // "import autoload './dir/script.vim'" - load script
! // first
! if (generate_SOURCE(cctx, scriptvar_sid) == FAIL)
! return FAIL;
! isn_type = ISN_STOREEXPORT;
! }
! // "s:" may be included in the name.
! return generate_OLDSCRIPT(cctx, isn_type, name,
! scriptvar_sid, type);
! }
! return generate_VIM9SCRIPT(cctx, ISN_STORESCRIPT,
scriptvar_sid, scriptvar_idx, type);
+ }
case dest_class_member:
return generate_CLASSMEMBER(cctx, FALSE,
lhs->lhs_class, lhs->lhs_classmember_idx);
*** ../vim-9.0.1074/src/version.c 2022-12-18 21:42:49.014716925 +
--- src/version.c 2022-12-18 21:59:20.962038407 +
***
*** 697,698
--- 697,700
{ /* Add new patch number below this line */
+ /**/
+ 1075,
/**/
--
DEAD PERSON: I don't want to go in the cart!
CUSTOMER: Oh, don't be such a baby.
MORTICIAN:I can't take him...
DEAD PERSON: I feel fine!
CUSTOMER: Oh, do us a favor...
MORTICIAN:I can't.
The Quest for the Holy Grail (Monty Python)
/// 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/20221218220211.26A471C0950%40moolenaar.net.
Re: Choices for Vim9 class implementation
> Just to remember static meaning in C/C++ : > '' > A static variable inside a function keeps its value between invocations ''. > https://stackoverflow.com/questions/572547/what-does-static-mean-in-c/572550#572550 We don't have static variables inside a function. Perhaps some day. In a class you can use the class member variables in a function, thus you could do: static someCount def SomeFunc() someCount += 1 echo 'count is now' someCount > In C++ static class purpose is helper class and don't need to be > instantiated. There are no plans for that. > Furthermore, direct access to static member can be easily > done as this : MyHelper::myStaticMember > > https://stackoverflow.com/questions/10442404/invoke-a-c-class-method-without-a-class-instance/10442432#10442432 > > Will it be same meaning in vim9 class ? > I think it should. C++ has lots of features that we won't get in Vim9 script. C++ is too complicated and the syntax is hard to understand, it's not a good example of a "nice" object oriented language. -- DEAD PERSON: I'm getting better! CUSTOMER: No, you're not -- you'll be stone dead in a moment. MORTICIAN:Oh, I can't take him like that -- it's against regulations. The Quest for the Holy Grail (Monty Python) /// 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/20221218215508.190081C09D3%40moolenaar.net.
Patch 9.0.1074
Patch 9.0.1074
Problem:Class members are not supported yet.
Solution: Add initial support for class members.
Files: src/errors.h, src/eval.c, src/structs.h, src/vim9.h,
src/vim9class.c, src/vim9compile.c, src/vim9expr.c,
src/vim9instr.c, src/proto/vim9instr.pro,
src/vim9cmds.c, src/vim9execute.c, src/testdir/test_vim9_class.vim
*** ../vim-9.0.1073/src/errors.h2022-12-16 16:41:19.204714805 +
--- src/errors.h2022-12-18 18:30:04.387224250 +
***
*** 3378,3393
INIT(= N_("E1329: Cannot get object member type from initializer: %s"));
EXTERN char e_invalid_type_for_object_member_str[]
INIT(= N_("E1330: Invalid type for object member: %s"));
! EXTERN char e_public_must_be_followed_by_this[]
! INIT(= N_("E1331: Public must be followed by \"this\""));
! EXTERN char e_public_object_member_name_cannot_start_with_underscore_str[]
! INIT(= N_("E1332: Public object member name cannot start with
underscore: %s"));
! EXTERN char e_cannot_access_private_object_member_str[]
! INIT(= N_("E1333: Cannot access private object member: %s"));
EXTERN char e_object_member_not_found_str[]
INIT(= N_("E1334: Object member not found: %s"));
! EXTERN char e_object_member_is_not_writable_str[]
! INIT(= N_("E1335: Object member is not writable: %s"));
#endif
EXTERN char e_internal_error_shortmess_too_long[]
INIT(= N_("E1336: Internal error: shortmess too long"));
--- 3378,3399
INIT(= N_("E1329: Cannot get object member type from initializer: %s"));
EXTERN char e_invalid_type_for_object_member_str[]
INIT(= N_("E1330: Invalid type for object member: %s"));
! EXTERN char e_public_must_be_followed_by_this_or_static[]
! INIT(= N_("E1331: Public must be followed by \"this\" or \"static\""));
! EXTERN char e_public_member_name_cannot_start_with_underscore_str[]
! INIT(= N_("E1332: Public member name cannot start with underscore:
%s"));
! EXTERN char e_cannot_access_private_member_str[]
! INIT(= N_("E1333: Cannot access private member: %s"));
EXTERN char e_object_member_not_found_str[]
INIT(= N_("E1334: Object member not found: %s"));
! EXTERN char e_member_is_not_writable_str[]
! INIT(= N_("E1335: Member is not writable: %s"));
#endif
EXTERN char e_internal_error_shortmess_too_long[]
INIT(= N_("E1336: Internal error: shortmess too long"));
+ #ifdef FEAT_EVAL
+ EXTERN char e_class_member_not_found_str[]
+ INIT(= N_("E1337: Class member not found: %s"));
+ EXTERN char e_member_not_found_on_class_str_str[]
+ INIT(= N_("E1338: Member not found on class \"%s\": %s"));
+ #endif
*** ../vim-9.0.1073/src/eval.c 2022-12-14 20:54:52.411699476 +
--- src/eval.c 2022-12-18 18:23:43.039785841 +
***
*** 1193,1211
var2.v_type = VAR_UNKNOWN;
while (*p == '[' || (*p == '.' && p[1] != '=' && p[1] != '.'))
{
! if (*p == '.' && lp->ll_tv->v_type != VAR_DICT
! && lp->ll_tv->v_type != VAR_OBJECT
! && lp->ll_tv->v_type != VAR_CLASS)
{
if (!quiet)
semsg(_(e_dot_can_only_be_used_on_dictionary_str), name);
return NULL;
}
! if (lp->ll_tv->v_type != VAR_LIST
! && lp->ll_tv->v_type != VAR_DICT
! && lp->ll_tv->v_type != VAR_BLOB
! && lp->ll_tv->v_type != VAR_OBJECT
! && lp->ll_tv->v_type != VAR_CLASS)
{
if (!quiet)
emsg(_(e_can_only_index_list_dictionary_or_blob));
--- 1193,1213
var2.v_type = VAR_UNKNOWN;
while (*p == '[' || (*p == '.' && p[1] != '=' && p[1] != '.'))
{
! vartype_T v_type = lp->ll_tv->v_type;
!
! if (*p == '.' && v_type != VAR_DICT
! && v_type != VAR_OBJECT
! && v_type != VAR_CLASS)
{
if (!quiet)
semsg(_(e_dot_can_only_be_used_on_dictionary_str), name);
return NULL;
}
! if (v_type != VAR_LIST
! && v_type != VAR_DICT
! && v_type != VAR_BLOB
! && v_type != VAR_OBJECT
! && v_type != VAR_CLASS)
{
if (!quiet)
emsg(_(e_can_only_index_list_dictionary_or_blob));
***
*** 1214,1222
// A NULL list/blob works like an empty list/blob, allocate one now.
int r = OK;
! if (lp->ll_tv->v_type == VAR_LIST && lp->ll_tv->vval.v_list == NULL)
r = rettv_list_alloc(lp->ll_tv);
! else if (lp->ll_tv->v_type == VAR_BLOB
&& lp->ll_tv->vval.v_blob == NULL)
r = rettv_blob_alloc(lp->ll_tv);
if (r == FAIL)
--- 1216,1224
// A NULL list/blob works like an empty list/blob, allocate one now.
int r = OK;
! if (v_type == VAR_LIST &&
Patch 9.0.1073
Patch 9.0.1073
Problem:Using "xterm-kitty" for 'term' causes problems.
Solution: Remove the "xterm-" part when 'term' is set from $TERM. Detect a
few kitty-specific properties based on the version response
instead of the terminal name.
Files: runtime/doc/term.txt, src/term.c
*** ../vim-9.0.1072/runtime/doc/term.txt2022-12-01 12:03:42.259227523
+
--- runtime/doc/term.txt2022-12-18 17:04:40.328414318 +
***
*** 294,299
--- 295,320
starts with CSI, it assumes that the terminal is in 8-bit mode and will
convert all key sequences to their 8-bit variants.
+ *xterm-kitty* *kitty-terminal*
+ The Kitty terminal is a special case. Mainly because it works different from
+ most other terminals, but also because, instead of trying the fit in and make
+ it behave like other terminals by default, it dictates how applications need
+ to work when using Kitty. This makes it very difficult for Vim to work in a
+ Kitty terminal. Some exceptions have been hard coded, but it is not at all
+ nice to have to make exceptions for one specific terminal.
+
+ One of the problems is that the value for $TERM is set to "xterm-kitty". For
+ Vim this is an indication that the terminal is xterm-compatible and the
+ builtin xterm termcap entries should be used. Many other terminals depend on
+ this. However, Kitty is not fully xterm compatible. The author suggested to
+ ignore the "xterm-" prefix and use the terminfo entry anyway, but that
+ conflicts with what is needed for other terminals. Therefore Vim removes the
+ "xterm-" prefix from "xterm-kitty" when it comes from $TERM.
+
+ Note that using the kitty keyboard protocol is a separate feature, see
+ |kitty-keyboard-protocol|.
+
+
==
2. Terminal options *terminal-options* *termcap-options* *E436*
*** ../vim-9.0.1072/src/term.c 2022-12-17 15:35:37.778657492 +
--- src/term.c 2022-12-18 17:26:20.064007686 +
***
*** 2071,2076
--- 2071,2082
else
T_CCS = empty_option;
+ // Special case: "kitty" does not normally have a "RV" entry in terminfo,
+ // but we need to request the version for several other things to work.
+ if (strstr((char *)term, "kitty") != NULL
+ && (T_CRV == NULL || *T_CRV == NUL))
+ T_CRV = (char_u *)"\033[>c";
+
#ifdef UNIX
/*
* Any "stty" settings override the default for t_kb from the termcap.
***
*** 2599,2613
void
termcapinit(char_u *name)
{
! char_u*term;
! if (name != NULL && *name == NUL)
! name = NULL;// empty name is equal to no name
! term = name;
#ifndef MSWIN
if (term == NULL)
term = mch_getenv((char_u *)"TERM");
#endif
if (term == NULL || *term == NUL)
term = DEFAULT_TERM;
--- 2605,2638
void
termcapinit(char_u *name)
{
! char_u*term = name;
! if (term != NULL && *term == NUL)
! term = NULL;// empty name is equal to no name
#ifndef MSWIN
+ char_u*tofree = NULL;
if (term == NULL)
+ {
term = mch_getenv((char_u *)"TERM");
+
+ // "xterm-kitty" is used for Kitty, but it is not actually compatible
+ // with xterm. Remove the "xterm-" part to avoid trouble.
+ if (term != NULL && STRNCMP(term, "xterm-kitty", 11) == 0)
+ {
+ #ifdef FEAT_EVAL
+ ch_log(NULL, "Removing xterm- prefix from terminal name %s", term);
+ #endif
+ if (p_verbose > 0)
+ {
+ verbose_enter();
+ smsg(_("Removing xterm- prefix from terminal name %s"), term);
+ verbose_leave();
+ }
+ term = vim_strsave(term + 6);
+ tofree = term;
+ }
+ }
#endif
if (term == NULL || *term == NUL)
term = DEFAULT_TERM;
***
*** 2617,2626
set_string_default("term", term);
set_string_default("ttytype", term);
! /*
! * Avoid using "term" here, because the next mch_getenv() may overwrite
it.
! */
set_termname(T_NAME != NULL ? T_NAME : term);
}
/*
--- 2642,2653
set_string_default("term", term);
set_string_default("ttytype", term);
! // Avoid using "term" here, because the next mch_getenv() may overwrite
it.
set_termname(T_NAME != NULL ? T_NAME : term);
+
+ #ifndef MSWIN
+ vim_free(tofree);
+ #endif
}
/*
***
*** 4999,5004
--- 5026,5034
{
term_props[TPR_KITTY].tpr_status = TPR_YES;
term_props[TPR_KITTY].tpr_set_by_termresponse = TRUE;
+
+ // Kitty can handle SGR mouse reporting.
+ term_props[TPR_MOUSE].tpr_status = TPR_MOUSE_SGR;
}
// GNU screen sends 83;30600;0,
Re: Choices for Vim9 class implementation
Hi Bram,
Just to remember static meaning in C/C++ :
''
A static variable inside a function keeps its value between invocations ''.
https://stackoverflow.com/questions/572547/what-does-static-mean-in-c/572550#572550
In C++ static class purpose is helper class and don't need to be
instantiated. Furthermore, direct access to static member can be easily
done as this : MyHelper::myStaticMember
https://stackoverflow.com/questions/10442404/invoke-a-c-class-method-without-a-class-instance/10442432#10442432
Will it be same meaning in vim9 class ?
I think it should.
N i c o l a s
Le dimanche 18 décembre 2022 à 14:33:24 UTC+1, Bram Moolenaar a écrit :
>
> You may have noticed I started implementing classes for Vim9 script.
> There are quite a few detailed choices to make. I have already written
> the documentation with the current ideas: ":help vim9class". But
> nothing is set in stone yet, we can discuss improvements.
>
> One thing where different languages have a different way of doing things
> is how object and class members are declared. Some are very verbose and
> offer detailed options for access, others are so concise it's hard to
> spot declarations and some have hardly any access control. For Vim9 the
> goal is to keep it simple, only support the features we really need, use
> a simple syntax.
>
> For object members most languages use the "this." prefix. But not
> everywhere, which makes it inconsistent. A good example is a
> constructor where object members that are also an argument need to be
> prefixed with "this." to avoid a name collision, while other object
> members are used without "this.". I find that very confusing. Example:
>
> SomeObject(String name)
> {
> this.name = name;
> gender = Gender.unknown;
> }
>
> Here both "name and "gender" are object members, but used differently,
> because "name" is also an argument.
>
> I looked into using the "this." prefix for object members everywhere,
> and that turns out to work very well. It's not really different from
> what other languages are doing, it's not a new mechanism. But instead
> of using it optionally, require using it everywhere makes it consistent.
>
> One thing I'm not yet sure about is the declaration. Currently it works
> like this:
>
> this.name: string
> this.gender: Gender
>
> Notice that there is no "var" keyword. It's not needed to recognize the
> declaration. I can't think of a good reason to add "var" here, other
> than that a declaration would be expected to always have "var". Well, I
> don't have that expectation.
>
> For class members most languages use the "static" keyword. It's a bit
> of a weird word, but I suppose most people are used to it, and I can't
> find a popular language that has a good alternative.
>
> If we leave out "var" for object members, I suppose we should also leave
> it out for class members. We then get:
>
> static oneClassMember: number
> static twoClassMember: string
>
> I think this looks fine. Any objections?
>
>
> --
> MORTICIAN: Bring out your dead!
> [clang]
> Bring out your dead!
> [clang]
> Bring out your dead!
> CUSTOMER: Here's one -- nine pence.
> DEAD PERSON: I'm not dead!
> The Quest for the Holy Grail (Monty Python)
>
> /// 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_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/e9b393cc-77b9-4eb6-85b4-da91cbfde2ean%40googlegroups.com.
Choices for Vim9 class implementation
You may have noticed I started implementing classes for Vim9 script.
There are quite a few detailed choices to make. I have already written
the documentation with the current ideas: ":help vim9class". But
nothing is set in stone yet, we can discuss improvements.
One thing where different languages have a different way of doing things
is how object and class members are declared. Some are very verbose and
offer detailed options for access, others are so concise it's hard to
spot declarations and some have hardly any access control. For Vim9 the
goal is to keep it simple, only support the features we really need, use
a simple syntax.
For object members most languages use the "this." prefix. But not
everywhere, which makes it inconsistent. A good example is a
constructor where object members that are also an argument need to be
prefixed with "this." to avoid a name collision, while other object
members are used without "this.". I find that very confusing. Example:
SomeObject(String name)
{
this.name = name;
gender = Gender.unknown;
}
Here both "name and "gender" are object members, but used differently,
because "name" is also an argument.
I looked into using the "this." prefix for object members everywhere,
and that turns out to work very well. It's not really different from
what other languages are doing, it's not a new mechanism. But instead
of using it optionally, require using it everywhere makes it consistent.
One thing I'm not yet sure about is the declaration. Currently it works
like this:
this.name: string
this.gender: Gender
Notice that there is no "var" keyword. It's not needed to recognize the
declaration. I can't think of a good reason to add "var" here, other
than that a declaration would be expected to always have "var". Well, I
don't have that expectation.
For class members most languages use the "static" keyword. It's a bit
of a weird word, but I suppose most people are used to it, and I can't
find a popular language that has a good alternative.
If we leave out "var" for object members, I suppose we should also leave
it out for class members. We then get:
static oneClassMember: number
static twoClassMember: string
I think this looks fine. Any objections?
--
MORTICIAN:Bring out your dead!
[clang]
Bring out your dead!
[clang]
Bring out your dead!
CUSTOMER: Here's one -- nine pence.
DEAD PERSON: I'm not dead!
The Quest for the Holy Grail (Monty Python)
/// 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/20221218133317.C359B1C0C91%40moolenaar.net.
Patch 9.0.1072
Patch 9.0.1072
Problem:screenpos() column result in fold may be too small.
Solution: Add space of 'number', sign column, etc. (closes #11715)
Files: src/move.c, src/testdir/test_cursor_func.vim
*** ../vim-9.0.1071/src/move.c 2022-12-05 22:26:40.255110186 +
--- src/move.c 2022-12-18 12:28:25.966350301 +
***
*** 1416,1422
if (pos->lnum >= wp->w_topline && pos->lnum <= wp->w_botline)
{
- colnr_T off;
colnr_T col;
int width;
linenr_Tlnum = pos->lnum;
--- 1416,1421
***
*** 1432,1442
row += diff_check_fill(wp, lnum);
#endif
#ifdef FEAT_FOLDING
if (is_folded)
{
row += W_WINROW(wp);
! coloff = wp->w_wincol + 1;
}
else
#endif
--- 1431,1442
row += diff_check_fill(wp, lnum);
#endif
+ colnr_T off = win_col_off(wp);
#ifdef FEAT_FOLDING
if (is_folded)
{
row += W_WINROW(wp);
! coloff = wp->w_wincol + 1 + off;
}
else
#endif
***
*** 1445,1451
// similar to what is done in validate_cursor_col()
col = scol;
- off = win_col_off(wp);
col += off;
width = wp->w_width - off + win_col_off2(wp);
--- 1445,1450
*** ../vim-9.0.1071/src/testdir/test_cursor_func.vim2022-12-05
22:26:40.259110192 +
--- src/testdir/test_cursor_func.vim2022-12-18 12:13:08.735443175 +
***
*** 150,157
redraw
call assert_equal(2, screenpos(1, 2, 1).row)
call assert_equal(#{col: 1, row: 3, endcol: 1, curscol: 1}, screenpos(1, 3,
1))
! call assert_equal(3, screenpos(1, 4, 1).row)
! call assert_equal(3, screenpos(1, 5, 1).row)
call assert_equal(4, screenpos(1, 6, 1).row)
bwipe!
endfunc
--- 150,161
redraw
call assert_equal(2, screenpos(1, 2, 1).row)
call assert_equal(#{col: 1, row: 3, endcol: 1, curscol: 1}, screenpos(1, 3,
1))
! call assert_equal(#{col: 1, row: 3, endcol: 1, curscol: 1}, screenpos(1, 4,
1))
! call assert_equal(#{col: 1, row: 3, endcol: 1, curscol: 1}, screenpos(1, 5,
1))
! setlocal number
! call assert_equal(#{col: 5, row: 3, endcol: 5, curscol: 5}, screenpos(1, 3,
1))
! call assert_equal(#{col: 5, row: 3, endcol: 5, curscol: 5}, screenpos(1, 4,
1))
! call assert_equal(#{col: 5, row: 3, endcol: 5, curscol: 5}, screenpos(1, 5,
1))
call assert_equal(4, screenpos(1, 6, 1).row)
bwipe!
endfunc
*** ../vim-9.0.1071/src/version.c 2022-12-17 15:47:41.398038024 +
--- src/version.c 2022-12-18 12:15:46.843246042 +
***
*** 697,698
--- 697,700
{ /* Add new patch number below this line */
+ /**/
+ 1072,
/**/
--
ARTHUR:Will you ask your master if he wants to join my court at Camelot?!
GUARD #1: But then of course African swallows are not migratory.
GUARD #2: Oh, yeah...
GUARD #1: So they couldn't bring a coconut back anyway...
The Quest for the Holy Grail (Monty Python)
/// 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/20221218123157.C5CCD1C0D15%40moolenaar.net.
Re: Basic vim key bindings
On Sat, 17 Dec 2022 22:20:02 +0100 Christ van Willegen wrote: > https://fosstodon.org/@ids1024/109515255660791632 We probably could build a D campaign around this. -- Enan 3nan.ajm...@gmail.com https://git.sr.ht/~enan/ https://www.github.com/3N4N -- -- 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/20221218121558.2dcc%40gmail.com.
