Re: Choices for Vim9 class implementation
I'm not a big fan of the "this" keyword. I agree if going to use it,
ensure to use it everywhere. Consistency is good. I like simplicity, and
dislike redundancy.
So, about "this", alternatively, don't use it anywhere, but maybe you
could throw an error if a function argument name is also member variable
name. Not sure what static analysis is available - given that its a
scripting language. There's not really a compilation step is there?
OR, perhaps another option, just thinking outside the box, if a function
argument does actually happen to match a member variable name - then
automatically force it to actually set that variable. When (if) this
becomes the expected behavior, I think it would enable simplifying some
things a lot.
Explaining with an example. Often, when I'm coding and the arg name is the
same as a member variable name, then I usually find myself setting that
early-ish in the code. (just using a pseudo code to explain, obviously not
real code;)
class Blahh
this.toX: TYPE_A
this.toX: TYPE_B
fn SetXandY(toX: TPYE_A, toY: TYPE_B )
this.toX = toX
this.toY = toY
enfunc
endclass
So, I find that pattern happens a lot. And it gets real tedious.I
think this could be simplified to the following;
class Blahh
toX: TYPE_A
toX: TYPE_B
fn SetXandY(toX, toY)
enfunc
endclass
ie. This would set the member variables, toX and toY automatically.
Now, we might want to do some sanity check on the argument before
clobbering whatever was in there previously. The developer could very
easily use another temporary name, for example prefixed with p_ as they
wish, and check it is in range for example, before setting it. Like so;
class Blahh
toX: TYPE_A
toX: TYPE_B
fn SetXandY(p_toX, toY)
if p_toX in range
toX = p_toX
else
ignore, or throw, or set some default, whatever for toX
endif
enfunc
endclass
In this last example, any matching names could be automatically set, so
here, the toY would be automatically set.
This is inspired by your idea from the constructor idea you had here;
def new(this.lnum, this.col)
enddef
I like that one :)
Cheers,
Chris Plewright
On Monday, 19 December 2022 at 10:00:22 UTC+11 Maxim Kim wrote:
>
>
> понедельник, 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/0f9af573-98b6-47b5-aba3-eb36f8c19d1cn%40googlegroups.com.
Re: Choices for Vim9 class implementation
On Monday, 19 December 2022 at 19:52:34 UTC+11 Christopher Plewright wrote: > I'm not a big fan of the "this" keyword. I agree if going to use it, > ensure to use it everywhere. Consistency is good. I like simplicity, and > dislike redundancy. > > So, about "this", alternatively, don't use it anywhere, but maybe you > could throw an error if a function argument name is also member variable > name. Not sure what static analysis is available - given that its a > scripting language. There's not really a compilation step is there? > > OR, perhaps another option, just thinking outside the box, if a function > argument does actually happen to match a member variable name - then > automatically force it to actually set that variable. When (if) this > becomes the expected behavior, I think it would enable simplifying some > things a lot. > > Explaining with an example. Often, when I'm coding and the arg name is > the same as a member variable name, then I usually find myself setting > that early-ish in the code. (just using a pseudo code to explain, > obviously not real code;) > > class Blahh > this.toX: TYPE_A > this.toY: TYPE_B > fn SetXandY(toX: TPYE_A, toY: TYPE_B ) > this.toX = toX > this.toY = toY > enfunc > endclass > > So, I find that pattern happens a lot. And it gets real tedious.I > think this could be simplified to the following; > > class Blahh > toX: TYPE_A > toY: TYPE_B > fn SetXandY(toX, toY) > enfunc > endclass > > ie. This would set the member variables, toX and toY automatically. > > Now, we might want to do some sanity check on the argument before > clobbering whatever was in there previously. The developer could very > easily use another temporary name, for example prefixed with p_ as they > wish, and check it is in range for example, before setting it. Like so; > > class Blahh > toX: TYPE_A > toY: TYPE_B > fn SetXandY(p_toX, toY) > if p_toX in range > toX = p_toX > else > ignore, or throw, or set some default, whatever for toX > endif > enfunc > endclass > > In this last example, any matching names could be automatically set, so > here, the toY would be automatically set. > > > This is inspired by your idea from the constructor idea you had here; > def new(this.lnum, this.col) > enddef > > I like that one :) > > Cheers, > > Chris Plewright > > >> 1. Sorry for top posting. I'm still learning to navigate the google groups platform. 2. typo: toX: TYPE_B was meant to be toY: TYPE_B Hope my idea is still readable. Have fixed that in this reply anyway. -- -- 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/04cd3cac-3895-4be2-804b-9f87b0ad3bb7n%40googlegroups.com.
Patch 9.0.1076
Patch 9.0.1076
Problem:ASAN complains about NULL argument.
Solution: Skip memmove() when there is nothing to move.
Files: src/vim9class.c
*** ../vim-9.0.1075/src/vim9class.c 2022-12-18 21:42:49.010716927 +
--- src/vim9class.c 2022-12-19 12:16:16.520328897 +
***
*** 164,170
*members = gap->ga_len == 0 ? NULL : ALLOC_MULT(ocmember_T, gap->ga_len);
if (gap->ga_len > 0 && *members == NULL)
return FAIL;
! mch_memmove(*members, gap->ga_data, sizeof(ocmember_T) * gap->ga_len);
VIM_CLEAR(gap->ga_data);
return OK;
}
--- 164,171
*members = gap->ga_len == 0 ? NULL : ALLOC_MULT(ocmember_T, gap->ga_len);
if (gap->ga_len > 0 && *members == NULL)
return FAIL;
! if (gap->ga_len > 0)
! mch_memmove(*members, gap->ga_data, sizeof(ocmember_T) * gap->ga_len);
VIM_CLEAR(gap->ga_data);
return OK;
}
*** ../vim-9.0.1075/src/version.c 2022-12-18 22:01:38.873926637 +
--- src/version.c 2022-12-19 12:17:02.788283081 +
***
*** 697,698
--- 697,700
{ /* Add new patch number below this line */
+ /**/
+ 1076,
/**/
--
CUSTOMER: You're not fooling anyone y'know. Look, isn't there something
you can do?
DEAD PERSON: I feel happy... I feel happy.
[whop]
CUSTOMER: Ah, thanks very much.
MORTICIAN:Not at all. See you on Thursday.
CUSTOMER: Right.
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/20221219121940.1A78C1C09DC%40moolenaar.net.
Patch 9.0.1077
Patch 9.0.1077
Problem:Can add text property with negative ID before virtual text
property.
Solution: Remember that a text property with a negative ID was used and give
an appropriate error message. (closes #11725)
Fix index computation.
Files: src/textprop.c, src/errors.h, src/charset.c,
src/testdir/test_textprop.vim,
src/testdir/dumps/Test_prop_negative_error_1.dump,
src/testdir/dumps/Test_prop_negative_error_2.dump
*** ../vim-9.0.1076/src/textprop.c 2022-12-02 20:46:01.936019457 +
--- src/textprop.c 2022-12-19 12:56:46.432201033 +
***
*** 424,429
--- 424,433
return -(buf->b_textprop_text.ga_len + 1);
}
+ // Flag that is set when a negative ID isused for a normal text property.
+ // It is then impossible to use virtual text properties.
+ static int did_use_negative_pop_id = FALSE;
+
/*
* Shared between prop_add() and popup_create().
* "dict_arg" is the function argument of a dict containing "bufnr".
***
*** 576,588
if (dict_arg != NULL && get_bufnr_from_arg(dict_arg, &buf) == FAIL)
goto theend;
! if (id < 0 && buf->b_textprop_text.ga_len > 0)
{
! emsg(_(e_cannot_use_negative_id_after_adding_textprop_with_text));
! goto theend;
}
if (text != NULL)
id = get_textprop_id(buf);
// This must be done _before_ we add the property because property changes
// trigger buffer (memline) reorganisation, which needs this flag to be
--- 580,604
if (dict_arg != NULL && get_bufnr_from_arg(dict_arg, &buf) == FAIL)
goto theend;
! if (id < 0)
{
! if (buf->b_textprop_text.ga_len > 0)
! {
! emsg(_(e_cannot_use_negative_id_after_adding_textprop_with_text));
! goto theend;
! }
! did_use_negative_pop_id = TRUE;
}
+
if (text != NULL)
+ {
+ if (did_use_negative_pop_id)
+ {
+
emsg(_(e_cannot_add_textprop_with_text_after_using_textprop_with_negative_id));
+ goto theend;
+ }
id = get_textprop_id(buf);
+ }
// This must be done _before_ we add the property because property changes
// trigger buffer (memline) reorganisation, which needs this flag to be
*** ../vim-9.0.1076/src/errors.h2022-12-18 21:42:49.010716927 +
--- src/errors.h2022-12-19 13:05:03.482436969 +
***
*** 3397,3399
--- 3397,3403
EXTERN char e_member_not_found_on_class_str_str[]
INIT(= N_("E1338: Member not found on class \"%s\": %s"));
#endif
+ #ifdef FEAT_PROP_POPUP
+ EXTERN char
e_cannot_add_textprop_with_text_after_using_textprop_with_negative_id[]
+ INIT(= N_("E1339: Cannot add a textprop with text after using a
textprop with a negative id"));
+ #endif
*** ../vim-9.0.1076/src/charset.c 2022-12-06 14:17:32.178527467 +
--- src/charset.c 2022-12-19 13:03:10.186757558 +
***
*** 1181,1187
? col == 0
: (s[0] == NUL || s[1] == NUL)
&& cts->cts_with_trailing)))
! && tp->tp_id - 1 < gap->ga_len)
{
char_u *p = ((char_u **)gap->ga_data)[-tp->tp_id - 1];
--- 1181,1187
? col == 0
: (s[0] == NUL || s[1] == NUL)
&& cts->cts_with_trailing)))
! && -tp->tp_id - 1 < gap->ga_len)
{
char_u *p = ((char_u **)gap->ga_data)[-tp->tp_id - 1];
*** ../vim-9.0.1076/src/testdir/test_textprop.vim 2022-12-17
11:32:37.918855670 +
--- src/testdir/test_textprop.vim 2022-12-19 13:28:03.439879237 +
***
*** 3725,3730
--- 3725,3774
call StopVimInTerminal(buf)
endfunc
+
+ func Test_error_when_using_negative_id()
+ call prop_type_add('test1', #{highlight: 'ErrorMsg'})
+ call prop_add(1, 1, #{type: 'test1', text: 'virtual'})
+ call assert_fails("call prop_add(1, 1, #{type: 'test1', length: 1, id:
-1})", 'E1293:')
+
+ call prop_type_delete('test1')
+ endfunc
+
+ func Test_error_after_using_negative_id()
+ " This needs to run a separate Vim instance because the
+ " "did_use_negative_pop_id" will be set.
+ CheckRunVimInTerminal
+
+ let lines =<< trim END
+ vim9script
+
+ setline(1, ['one', 'two', 'three'])
+ prop_type_add('test_1', {highlight: 'Error'})
+ prop_type_add('test_2', {highlight: 'WildMenu'})
+
+ prop_add(3, 1, {
+ type: 'test_1',
+ length: 5,
+ id: -1
+ })
+
+ def g:AddTextprop()
+ prop_add(1, 0, {
+ type: 'test_2',
+ text: 'The quick fox',
+ text_padding_left: 2
+ })
+ endd
Re: Choices for Vim9 class implementation
> I'm not a big fan of the "this" keyword. I agree if going to use it, > ensure to use it everywhere. Consistency is good. I like simplicity, and > dislike redundancy. What do you mean, do you prefer "self"? > So, about "this", alternatively, don't use it anywhere, but maybe you > could throw an error if a function argument name is also member variable > name. That is actually very common. It is very likely that methods pass arguments to set or modify the object members, thus using the same name is very likely to happen. > Not sure what static analysis is available - given that its a > scripting language. There's not really a compilation step is there? Some minimal checks can be done, but static analysis is too complicated and time consuming to build in. > OR, perhaps another option, just thinking outside the box, if a function > argument does actually happen to match a member variable name - then > automatically force it to actually set that variable. When (if) this > becomes the expected behavior, I think it would enable simplifying some > things a lot. Boundary checks are often done on arguments, assuming that the argument is always assigned to an object member is too limiting. I also want to avoid doing things very differently from what existing languages are doing. Some different syntax and rules can be acceptable, but introducing new mechanisms that are hard to understand are to be avoided. > Explaining with an example. Often, when I'm coding and the arg name is the > same as a member variable name, then I usually find myself setting that > early-ish in the code. (just using a pseudo code to explain, obviously not > real code;) > > class Blahh > this.toX: TYPE_A > this.toY: TYPE_B > fn SetXandY(toX: TPYE_A, toY: TYPE_B ) > this.toX = toX > this.toY = toY > enfunc > endclass > > So, I find that pattern happens a lot. And it gets real tedious.I > think this could be simplified to the following; > > class Blahh > toX: TYPE_A > toY: TYPE_B > fn SetXandY(toX, toY) > enfunc > endclass > > ie. This would set the member variables, toX and toY automatically. I don't know any language that does this and I find it very obscure and confusing. Also, it makes giving useful errors difficult. Using an argument name that happens to be a member name would not result in any error but silently turned into an assignment. [...] -- A computer programmer is a device for turning requirements into undocumented features. It runs on cola, pizza and Dilbert cartoons. Bram Moolenaar /// 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/20221219142609.5D0811C09F0%40moolenaar.net.
Re: Choices for Vim9 class implementation
> > 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. That is indeed an alternative, and more like a normal declaration. Although in Typescript, which syntax has been mostly used for declarations, it would be: name: string; gender: Gender; Unfortunately, this doesn't stand out and easily gets lost in a long class. It would require the habit of putting all the members at the start of the class. Other languages, like Java, put the type before the name and also don't have a keyword, e.g.: String name; Gender gender; There are advantages and disadvantages of using the normal "var" style declarations. But it appears that most language don't declare object members with a keyword. I still like the consistency of always prefixing the object members with "this.", instead of having it depend on the context. -- A mathematician is a device for turning coffee into theorems. Paul Erdos A computer programmer is a device for turning coffee into bugs. Bram Moolenaar /// 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/20221219142609.543541C09D3%40moolenaar.net.
Re: Choices for Vim9 class implementation
On Tuesday, 20 December 2022 at 01:26:15 UTC+11 Bram Moolenaar wrote: > > > I'm not a big fan of the "this" keyword. I agree if going to use it, > > ensure to use it everywhere. Consistency is good. I like simplicity, and > > dislike redundancy. > > What do you mean, do you prefer "self"? > No, I prefer 'this' over 'self'. I was considering if its possible to go without any keyword for it. For example, these days we also have syntax highlighting which can give a different color for member variables and arguments. > > So, about "this", alternatively, don't use it anywhere, but maybe you > > could throw an error if a function argument name is also member variable > > name. > > That is actually very common. It is very likely that methods pass > arguments to set or modify the object members, thus using the same name > is very likely to happen. Yes, it is common, and it is a source of confusion & errors - especially when its not referring to the same thing. Thats my point. It seems like it would be better practice to use different names for different context, especially when those contexts overlap in scope. > > OR, perhaps another option, just thinking outside the box, if a function > > argument does actually happen to match a member variable name - then > > automatically force it to actually set that variable. When (if) this > > becomes the expected behavior, I think it would enable simplifying some > > things a lot. > > Boundary checks are often done on arguments, assuming that the argument > is always assigned to an object member is too limiting. > To be clear, I didn't mean that every argument is always assigned to an object member, I only meant assign it when it has the same name... I think you understood anyay, but just in case I was ambiguous. But, yes, I see that it could be restrictive. Still, really, if you are using the same name to mean something different, then that is also a potential pitfall. > I also want to avoid doing things very differently from what existing > languages are doing. Some different syntax and rules can be acceptable, > but introducing new mechanisms that are hard to understand are to be > avoided. > It is unusual, I agree. I've never seen it done like that in any modern major language. It reminds me of some languages that don't really use scope very well, where ALL of the variable names were pretty much scoped to the whole class, no matter where they were declared in that class. I can't recall what language I saw that in, that was over 20 years ago. > > class Blahh > > this.toX: TYPE_A > > this.toY: TYPE_B > > fn SetXandY(toX: TPYE_A, toY: TYPE_B ) > > this.toX = toX > > this.toY = toY > > enfunc > > endclass > > > > So, I find that pattern happens a lot. And it gets real tedious. I > > think this could be simplified to the following; > > > > class Blahh > > toX: TYPE_A > > toY: TYPE_B > > fn SetXandY(toX, toY) > > enfunc > > endclass > > > > ie. This would set the member variables, toX and toY automatically. > > I don't know any language that does this and I find it very obscure and > confusing. Also, it makes giving useful errors difficult. Using an > argument name that happens to be a member name would not result in any > error but silently turned into an assignment. Yeah, it could be confusing to get used to it. But, there would not need to be any error messages, because it wouldn't be an error. It would be a feature. And, once you got used to it, you'd realise it solves a number of problems. I take your point though. Considering it would behave different to current paradigm of most popular languages, then users would get surprised that they didn't get an error - because they were expecting something different to happen. But, at the end of the day, "this" is a pragmatic choice, and I like your idea of enforcing it everywhere such member variables are used. -- -- 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/a5d88361-2326-4f36-9e68-ac50fd03b8f0n%40googlegroups.com.
Re: Choices for Vim9 class implementation
> class Blahh > toX: TYPE_A > toY: TYPE_B > fn SetXandY(toX, toY) > enfunc > endclass So... like you said, that was confusing. But, I just realised that prefixing member variables with "this" everywhere consistently could perhaps allow us to do something in between, along these lines? class Blahh this.toX: TYPE_A this.toY: TYPE_B fn SetXandY(this.toX, this.toY, Z : TYPE_C) blahh blah.. enfunc endclass Could we make this signature pattern auto assign this.toX and this.toY, for any function? I'm just exploring other possibilities inspired by the idea you presented with respect to the new() constructor. > Simplifying the new() method ~ > > Many constructors take values for the object members. Thus you very often see > this pattern: > > >this.lnum: number >this.col: number > >def new(lnum: number, col: number) > this.lnum = lnum > this.col = col >enddef > > Not only is this text you need to write, it also has the type of each member > twice. Since this is so common a shorter way to write new() is provided: > > >def new(this.lnum, this.col) >enddef > > The semantics are easy to understand: Providing the object member name, > including "this.", as the argument to new() means the value provided in the > new() call is assigned to that object member. This mechanism is coming from > the Dart language. Why limit this idea to only the new constructor? -- -- 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/e199e7b2-a852-451b-8700-718d4bbb533bn%40googlegroups.com.
Patch 9.0.1078
Patch 9.0.1078
Problem:With the +vartabs feature indent folding may use wrong 'tabstop'.
Solution: Use the "buf" argument instead of "curbuf".
Files: src/indent.c, src/testdir/test_fold.vim
*** ../vim-9.0.1077/src/indent.c2022-10-15 16:04:43.998187220 +0100
--- src/indent.c2022-12-19 15:50:04.019923725 +
***
*** 420,426
{
# ifdef FEAT_VARTABS
return get_indent_str_vtab(ml_get_buf(buf, lnum, FALSE),
! (int)curbuf->b_p_ts, buf->b_p_vts_array, FALSE);
# else
return get_indent_str(ml_get_buf(buf, lnum, FALSE), (int)buf->b_p_ts,
FALSE);
# endif
--- 420,426
{
# ifdef FEAT_VARTABS
return get_indent_str_vtab(ml_get_buf(buf, lnum, FALSE),
! (int)buf->b_p_ts, buf->b_p_vts_array, FALSE);
# else
return get_indent_str(ml_get_buf(buf, lnum, FALSE), (int)buf->b_p_ts,
FALSE);
# endif
*** ../vim-9.0.1077/src/testdir/test_fold.vim 2022-11-11 22:57:41.774304953
+
--- src/testdir/test_fold.vim 2022-12-19 15:51:09.223938033 +
***
*** 157,162
--- 157,183
bw!
endfunc
+ func Test_indent_fold_tabstop()
+ call setline(1, ['0', '1', '1', "\t2", "\t2"])
+ setlocal shiftwidth=4
+ setlocal foldcolumn=1
+ setlocal foldlevel=2
+ setlocal foldmethod=indent
+ redraw
+ call assert_equal('22', ScreenLines(5, 10)[0])
+ vsplit
+ windo diffthis
+ botright new
+ " This 'tabstop' value should not be used for folding in other buffers.
+ setlocal tabstop=4
+ diffoff!
+ redraw
+ call assert_equal('22', ScreenLines(5, 10)[0])
+
+ bwipe!
+ bwipe!
+ endfunc
+
func Test_manual_fold_with_filter()
CheckExecutable cat
for type in ['manual', 'marker']
*** ../vim-9.0.1077/src/version.c 2022-12-19 13:30:34.319772241 +
--- src/version.c 2022-12-19 15:49:58.791922384 +
***
*** 697,698
--- 697,700
{ /* Add new patch number below this line */
+ /**/
+ 1078,
/**/
--
Vim is like Emacs without all the typing. (John "Johann" Spetz)
/// 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/20221219155223.709891C0950%40moolenaar.net.
Re: Choices for Vim9 class implementation
> > class Blahh > > toX: TYPE_A > > toY: TYPE_B > > fn SetXandY(toX, toY) > > enfunc > > endclass > > So... like you said, that was confusing. > > But, I just realised that prefixing member variables with "this" everywhere > consistently could perhaps allow us to do something in between, along these > lines? > > class Blahh > this.toX: TYPE_A > this.toY: TYPE_B > fn SetXandY(this.toX, this.toY, Z : TYPE_C) >blahh blah.. > enfunc > endclass > > > Could we make this signature pattern auto assign this.toX and this.toY, for > any function? I'm just exploring other possibilities inspired by the idea > you presented with respect to the new() constructor. I do not see much use for it. Without supporting using "this.member" as an argument name the code for the assignment would need to be given explicitly, which isn't that bad. > > Simplifying the new() method ~ > > > > Many constructors take values for the object members. Thus you very > often see > > this pattern: > > > > >this.lnum: number > >this.col: number > > > >def new(lnum: number, col: number) > > this.lnum = lnum > > this.col = col > >enddef > > > > Not only is this text you need to write, it also has the type of each > member > > twice. Since this is so common a shorter way to write new() is provided: > > > > > >def new(this.lnum, this.col) > >enddef > > > > The semantics are easy to understand: Providing the object member name, > > including "this.", as the argument to new() means the value provided in > the > > new() call is assigned to that object member. This mechanism is coming > from > > the Dart language. > > Why limit this idea to only the new constructor? The difference between a regular method and a constructor is that for a constructor it is very common to assign the argument to an object member. The idea comes from Dart, and I don't think Dart supports this for anything but constructors. -- Q: Is selling software the same as selling hardware? A: No, good hardware is sold new, good software has already been used by many. /// 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/20221219165003.C5BA41C09DC%40moolenaar.net.
Patch 9.0.1079
Patch 9.0.1079
Problem:Leaking memory when defining a user command fails.
Solution: Free "compl_arg" when needed. (closes #11726)
Files: src/usercmd.c, src/testdir/test_usercommands.vim
*** ../vim-9.0.1078/src/usercmd.c 2022-11-13 23:30:02.419807434 +
--- src/usercmd.c 2022-12-19 16:48:50.338894648 +
***
*** 1167,1173
end = skiptowhite(p);
if (uc_scan_attr(p, end - p, &argt, &def, &flags, &compl,
&compl_arg, &addr_type_arg) == FAIL)
! return;
p = skipwhite(end);
}
--- 1167,1173
end = skiptowhite(p);
if (uc_scan_attr(p, end - p, &argt, &def, &flags, &compl,
&compl_arg, &addr_type_arg) == FAIL)
! goto theend;
p = skipwhite(end);
}
***
*** 1179,1185
if (!ends_excmd2(eap->arg, p) && !VIM_ISWHITE(*p))
{
emsg(_(e_invalid_command_name));
! return;
}
end = p;
name_len = (int)(end - name);
--- 1179,1185
if (!ends_excmd2(eap->arg, p) && !VIM_ISWHITE(*p))
{
emsg(_(e_invalid_command_name));
! goto theend;
}
end = p;
name_len = (int)(end - name);
***
*** 1188,1200
--- 1188,1206
// we are listing commands
p = skipwhite(end);
if (!has_attr && ends_excmd2(eap->arg, p))
+ {
uc_list(name, end - name);
+ }
else if (!ASCII_ISUPPER(*name))
+ {
emsg(_(e_user_defined_commands_must_start_with_an_uppercase_letter));
+ }
else if ((name_len == 1 && *name == 'X')
|| (name_len <= 4
&& STRNCMP(name, "Next", name_len > 4 ? 4 : name_len) == 0))
+ {
emsg(_(e_reserved_name_cannot_be_used_for_user_defined_command));
+ }
else if (compl > 0 && (argt & EX_EXTRA) == 0)
{
// Some plugins rely on silently ignoring the mistake, only make this
***
*** 1215,1221
--- 1221,1232
uc_add_command(name, end - name, p, argt, def, flags, compl, compl_arg,
addr_type_arg, eap->forceit);
vim_free(tofree);
+
+ return; // success
}
+
+ theend:
+ vim_free(compl_arg);
}
/*
*** ../vim-9.0.1078/src/testdir/test_usercommands.vim 2022-11-13
23:30:02.423807434 +
--- src/testdir/test_usercommands.vim 2022-12-19 16:46:19.478947940 +
***
*** 342,347
--- 342,352
call assert_fails('com DoCmd :', 'E174:')
comclear
call assert_fails('delcom DoCmd', 'E184:')
+
+ " These used to leak memory
+ call assert_fails('com! -complete=custom,CustomComplete _ :', 'E182:')
+ call assert_fails('com! -complete=custom,CustomComplete docmd :', 'E183:')
+ call assert_fails('com! -complete=custom,CustomComplete -xxx DoCmd :',
'E181:')
endfunc
func CustomComplete(A, L, P)
*** ../vim-9.0.1078/src/version.c 2022-12-19 15:51:40.379943472 +
--- src/version.c 2022-12-19 16:47:36.486920619 +
***
*** 697,698
--- 697,700
{ /* Add new patch number below this line */
+ /**/
+ 1079,
/**/
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
/// 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/20221219165003.CAF951C09F0%40moolenaar.net.
Patch 9.0.1080
Patch 9.0.1080 (after 9.0.1073)
Problem:The "kitty" terminfo entry is not widespread, resulting in the
kitty terminal not working properly.
Solution: Go back to using "xterm-kitty" and avoid the problems it causes in
another way.
Files: runtime/doc/term.txt, src/term.c, src/os_unix.c
*** ../vim-9.0.1079/runtime/doc/term.txt2022-12-18 17:47:11.430957013
+
--- runtime/doc/term.txt2022-12-19 18:54:22.413876147 +
***
*** 306,314
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|.
--- 307,320
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, so that is what
! happens now, the builtin xterm termcap entries are not used. However, the
! t_RV is set, otherwise other things would not work, such as automatically
! setting 'ttymouse' to "sgr".
!
! It is not clear why kitty sets $TERM to "xterm-kitty", the terminal isn't
! really xterm compatible. "kitty" would be more appropriate, but a terminfo
! entry with that name is not widespread.
Note that using the kitty keyboard protocol is a separate feature, see
|kitty-keyboard-protocol|.
*** ../vim-9.0.1079/src/term.c 2022-12-18 17:47:11.430957013 +
--- src/term.c 2022-12-19 18:42:33.912112976 +
***
*** 1675,1680
--- 1675,1686
#endif
#ifdef HAVE_TGETENT
+ /*
+ * Get the termcap entries we need with tgetstr(), tgetflag() and tgetnum().
+ * "invoke_tgetent()" must have been called before.
+ * If "*height" or "*width" are not zero then use the "li" and "col" entries
to
+ * get their value.
+ */
static void
get_term_entries(int *height, int *width)
{
***
*** 2033,2046
#endif
parse_builtin_tcap(term);
- // Use the 'keyprotocol' option to adjust the t_TE and t_TI
- // termcap entries if there is an entry maching "term".
- keyprot_T kpc = match_keyprotocol(term);
- if (kpc == KEYPROTOCOL_KITTY)
- apply_builtin_tcap(term, builtin_kitty, TRUE);
- else if (kpc == KEYPROTOCOL_MOK2)
- apply_builtin_tcap(term, builtin_mok2, TRUE);
-
#ifdef FEAT_GUI
if (term_is_gui(term))
{
--- 2039,2044
***
*** 2060,2065
--- 2058,2076
}
#endif
+ #ifdef FEAT_GUI
+ if (!gui.in_use)
+ #endif
+ {
+ // Use the 'keyprotocol' option to adjust the t_TE and t_TI
+ // termcap entries if there is an entry maching "term".
+ keyprot_T kpc = match_keyprotocol(term);
+ if (kpc == KEYPROTOCOL_KITTY)
+ apply_builtin_tcap(term, builtin_kitty, TRUE);
+ else if (kpc == KEYPROTOCOL_MOK2)
+ apply_builtin_tcap(term, builtin_mok2, TRUE);
+ }
+
/*
* special: There is no info in the termcap about whether the cursor
* positioning is relative to the start of the screen or to the start of the
***
*** 2611,2638
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;
--- 2622,2629
***
*** 2644,2653
// 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
}
/*
--- 2635,2640
*** ../vim-9.0.1079/src/os_unix.c 2022-12-01 12:03:42.263227523 +
--- src/os_unix.c 2022-12-19 18:28:04.142328442 +000
vim_dev@googlegroups.com
On 2022-12-02, Gary Johnson wrote: > I've submitted a bug report to the mintty project, issue #1189. This doesn't seem to have been a bug in mintty, but mintty resolved the conflict with xterm anyway in version 3.6.3, which is now the latest version in Cygwin. Regards, Gary -- -- 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/20221219191725.GC6446%40phoenix.
Patch 9.0.1081
Patch 9.0.1081
Problem:Using "->" with split lines does not always work.
Solution: Avoid trying to get another line. (closes #11723)
Files: src/eval.c, src/testdir/test_user_func.vim
*** ../vim-9.0.1080/src/eval.c 2022-12-18 21:42:49.010716927 +
--- src/eval.c 2022-12-19 20:26:08.073476338 +
***
*** 4548,4558
if (**arg != '(' && alias == NULL
&& (paren = vim_strchr(*arg, '(')) != NULL)
{
- char_u *deref;
-
*arg = name;
*paren = NUL;
! deref = deref_function_name(arg, &tofree, evalarg, verbose);
if (deref == NULL)
{
*arg = name + len;
--- 4548,4566
if (**arg != '(' && alias == NULL
&& (paren = vim_strchr(*arg, '(')) != NULL)
{
*arg = name;
+
+ // Truncate the name a the "(". Avoid trying to get another line
+ // by making "getline" NULL.
*paren = NUL;
! char_u *(*getline)(int, void *, int, getline_opt_T) = NULL;
! if (evalarg != NULL)
! {
! getline = evalarg->eval_getline;
! evalarg->eval_getline = NULL;
! }
!
! char_u *deref = deref_function_name(arg, &tofree, evalarg, verbose);
if (deref == NULL)
{
*arg = name + len;
***
*** 4563,4569
--- 4571,4580
name = deref;
len = (long)STRLEN(name);
}
+
*paren = '(';
+ if (getline != NULL)
+ evalarg->eval_getline = getline;
}
if (ret == OK)
*** ../vim-9.0.1080/src/testdir/test_user_func.vim 2022-10-15
21:35:51.191403811 +0100
--- src/testdir/test_user_func.vim 2022-12-19 20:25:13.369634729 +
***
*** 179,184
--- 179,238
eval 'bar'->s:addFoo()->assert_equal('barfoo')
endfunc
+ func Test_method_with_linebreaks()
+ let lines =<< trim END
+ vim9script
+
+ export def Scan(ll: list): func(func(number))
+ return (Emit: func(number)) => {
+ for v in ll
+ Emit(v)
+ endfor
+ }
+ enddef
+
+ export def Build(Cont: func(func(number))): list
+ var result: list = []
+ Cont((v) => {
+ add(result, v)
+ })
+ return result
+ enddef
+
+ export def Noop(Cont: func(func(number))): func(func(number))
+ return (Emit: func(number)) => {
+ Cont(Emit)
+ }
+ enddef
+ END
+ call writefile(lines, 'Xlib.vim', 'D')
+
+ let lines =<< trim END
+ vim9script
+
+ import "./Xlib.vim" as lib
+
+ const x = [1, 2, 3]
+
+ var result = lib.Scan(x)->lib.Noop()->lib.Build()
+ assert_equal([1, 2, 3], result)
+
+ result = lib.Scan(x)->lib.Noop()
+ ->lib.Build()
+ assert_equal([1, 2, 3], result)
+
+ result = lib.Scan(x)
+ ->lib.Noop()->lib.Build()
+ assert_equal([1, 2, 3], result)
+
+ result = lib.Scan(x)
+ ->lib.Noop()
+ ->lib.Build()
+ assert_equal([1, 2, 3], result)
+ END
+ call v9.CheckScriptSuccess(lines)
+ endfunc
+
func Test_failed_call_in_try()
try | call UnknownFunc() | catch | endtry
endfunc
*** ../vim-9.0.1080/src/version.c 2022-12-19 18:56:44.173594364 +
--- src/version.c 2022-12-19 20:26:23.833433379 +
***
*** 697,698
--- 697,700
{ /* Add new patch number below this line */
+ /**/
+ 1081,
/**/
--
The question is: What do you do with your life?
The wrong answer is: Become the richest guy in the graveyard.
(billionaire and Oracle founder Larry Ellison)
/// 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/20221219202913.142481C09DC%40moolenaar.net.
Patch 9.0.1082
Patch 9.0.1082
Problem:Some jsonc files are not recognized.
Solution: Add patterns for jsonc and move some from json to jsonc.
(closes #11711)
Files: runtime/filetype.vim, src/testdir/test_filetype.vim
*** ../vim-9.0.1081/runtime/filetype.vim2022-12-05 21:40:33.155131915
+
--- runtime/filetype.vim2022-12-19 20:38:16.876275826 +
***
*** 993,1015
" Jovial
au BufNewFile,BufRead *.jov,*.j73,*.jovialsetf jovial
- " JSON
- au BufNewFile,BufRead *.json,*.jsonp,*.webmanifestsetf json
-
" JSON5
au BufNewFile,BufRead *.json5 setf json5
" JSON Patch (RFC 6902)
! au BufNewFile,BufRead *.json-patchsetf json
" Jupyter Notebook is also json
! au BufNewFile,BufRead *.ipynb setf json
" Other files that look like json
! au BufNewFile,BufRead .babelrc,.eslintrc,.prettierrc,.firebaserc setf json
! " JSONC
! au BufNewFile,BufRead *.jsonc setf jsonc
" Jsonnet
au BufNewFile,BufRead *.jsonnet,*.libsonnet setf jsonnet
--- 993,1016
" Jovial
au BufNewFile,BufRead *.jov,*.j73,*.jovialsetf jovial
" JSON5
au BufNewFile,BufRead *.json5 setf json5
" JSON Patch (RFC 6902)
! au BufNewFile,BufRead *.json-patchsetf json
" Jupyter Notebook is also json
! au BufNewFile,BufRead *.ipynb setf json
" Other files that look like json
! au BufNewFile,BufRead .prettierrc,.firebaserc setf json
! " JSONC (JSON with comments)
! au BufNewFile,BufRead *.jsonc,.babelrc,.eslintrc,.jsfmtrc setf jsonc
! au BufNewFile,BufRead .jshintc,.hintrc,.swrc,[jt]sconfig*.jsonsetf
jsonc
!
! " JSON
! au BufNewFile,BufRead *.json,*.jsonp,*.webmanifestsetf json
" Jsonnet
au BufNewFile,BufRead *.jsonnet,*.libsonnet setf jsonnet
*** ../vim-9.0.1081/src/testdir/test_filetype.vim 2022-12-14
16:42:11.286755477 +
--- src/testdir/test_filetype.vim 2022-12-19 20:41:33.160108820 +
***
*** 287,295
\ 'jgraph': ['file.jgr'],
\ 'jovial': ['file.jov', 'file.j73', 'file.jovial'],
\ 'jproperties': ['file.properties', 'file.properties_xx',
'file.properties_xx_xx', 'some.properties_xx_xx_file', 'org.eclipse.xyz.prefs'],
! \ 'json': ['file.json', 'file.jsonp', 'file.json-patch',
'file.webmanifest', 'Pipfile.lock', 'file.ipynb', '.babelrc', '.eslintrc',
'.prettierrc', '.firebaserc', 'file.slnf'],
\ 'json5': ['file.json5'],
! \ 'jsonc': ['file.jsonc'],
\ 'jsonnet': ['file.jsonnet', 'file.libsonnet'],
\ 'jsp': ['file.jsp'],
\ 'julia': ['file.jl'],
--- 287,295
\ 'jgraph': ['file.jgr'],
\ 'jovial': ['file.jov', 'file.j73', 'file.jovial'],
\ 'jproperties': ['file.properties', 'file.properties_xx',
'file.properties_xx_xx', 'some.properties_xx_xx_file', 'org.eclipse.xyz.prefs'],
! \ 'json': ['file.json', 'file.jsonp', 'file.json-patch',
'file.webmanifest', 'Pipfile.lock', 'file.ipynb', '.prettierrc', '.firebaserc',
'file.slnf'],
\ 'json5': ['file.json5'],
! \ 'jsonc': ['file.jsonc', '.babelrc', '.eslintrc', '.jsfmtrc',
'.jshintc', '.hintrc', '.swrc', 'jsconfig.json', 'tsconfig.json',
'tsconfig.test.json', 'tsconfig-test.json'],
\ 'jsonnet': ['file.jsonnet', 'file.libsonnet'],
\ 'jsp': ['file.jsp'],
\ 'julia': ['file.jl'],
*** ../vim-9.0.1081/src/version.c 2022-12-19 20:28:34.061118368 +
--- src/version.c 2022-12-19 20:39:36.268203892 +
***
*** 697,698
--- 697,700
{ /* Add new patch number below this line */
+ /**/
+ 1082,
/**/
--
Witches prefer brooms: vacuum-cleaners need extension cords!
/// 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/20221219204324.A86DD1C09DC%40moolenaar.net.
Re: Choices for Vim9 class implementation
> > > The difference between a regular method and a constructor is that for a > constructor it is very common to assign the argument to an object > member. > > The idea comes from Dart, and I don't think Dart supports this for > anything but constructors. > That's a good point, it is usually constructors where it get tedious. I really appreciate your considered replies. Thanks -- -- 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/e303f1ac-1519-4de3-b538-3fa33c44c121n%40googlegroups.com.
