Re: Support for Private class/object methods
If "public" is omitted, shouldn't class members and method be private by default just like "def" functions and script variables are script-local by default unless prefixed with "export"? In general, I would also like it to be symmetric. So, either introducing "public" and "private" together, or no modifier keyword at all. In the latter case an underscore indicates private class members and methods whereas public ones don't have an underscore. And another issue: why isn't this thread shown in GitHub Discussions? Wasn't the whole point of enabling Discussions so that more people can participate in such decision making? On Friday, August 25, 2023 at 6:11:34 AM UTC+2 Doug Kearns wrote: > On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan > wrote: > >> Hi all, >> >> The following item is in the todo.txt file for implementing private >> methods in a class: >> >> - Private methods? >> either: private def Func() >> or: def _Func() >> Perhaps use "private" keyword instead of "_" prefix? >> >> Function and method names always start with an uppercase letter. So >> if we use the >> "_" prefix for a private method name then it will diverge from that. So I >> have >> implemented this using the "private" keyword. >> >> Any opinions? >> > > Thanks very much for keeping the ball rolling on this. > > For others, there was some previous discussion[1] about it on the list > when Bram asked for opinions. My recollection is that both you and he were > in favour of the "_" prefix for call-site identification purposes? > > My personal preference would be for the modifier keyword with a symmetric, > even if possibly redundant, "public". I think this is justifiable on the > grounds of it meeting the "less weird" requirement for Vim9 script. While > I'm sure there are others, JavaScript is the only language I can think of > off the top of my head that defaults to public and uses a sigil for private > access. > > Thanks again, > Doug > > 1. https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1 > > > -- -- 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/394f9be0-0aef-4c32-9da0-a90ac499723fn%40googlegroups.com.
Re: Choices for Vim9 class implementation
> 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. In order to give different colors for member variables and function arguments you need a very sophisticated parser. Otherwise you cannot distinguish the two in code. For the same reason C++ developers often prefix member variables with `m_`, like `m_age`, others use a postfix underscore like `age_` etc. I don't like it because it's not consistent. Personally, I would prefer `this` (or `self` etc.) for member variables. It makes the syntax script a lot simpler and the syntax highlighting will work 100%. It will also be easier to `:grep` for all usages of a member variable since every reference of a member variable will contain `this`. On Monday, December 19, 2022 at 4:12:37 PM UTC+1 ch...@createng.com wrote: > 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
Re: Adding multiple virtual text properties using the prop_add_list() function
Personally, I haven't measured a significant difference between prop_add()
and
prop_add_list() for normal text-properties. For signs, on the other hand,
there's a significant difference between sign_place() in a for-loop and
sign_place_list().
But what I've noticed is that calling prop_remove() can be very slow when
removing over a thousand virtual text-properties.
For comparison: with normal text-properties, we can group them under a given
text-prop ID and use that ID in prop_remove() to remove a set of "related"
text-properties:
prop_remove({
'id': group_id,
'bufnr': some_bufnr,
'type': 'my_prop_type',
'both': true,
'all': true
})
This is very efficient, even when removing 10'000 text-properties with the
same
ID.
However, with virtual text-properties we cannot group them under the same ID
(why?), instead each virtual text will be assigned a unique ID. Thus, we
need
to cache every ID returned by prop_add() and then remove them individually
in a
for-loop, something like:
var virt_IDs: list
# fill virt_IDs with IDs returned by prop_add() …
for i in virt_IDs
prop_remove({
'id': i,
'bufnr': some_bufnr
})
endfor
Since the IDs are unique within a buffer, we don't have to specify `type` or
`both` in `prop_remove()`. Nevertheless, removing virtual text this way is
very
slow when several hundred properties need to be removed.
To give you an example, on my 10 year old laptop calling prop_remove() in a
for-loop to remove 10'000 text-properties takes over 2 seconds. If I remove
the
'id' entry in prop_remove() and match by 'type' it takes only a few
milliseconds. It's also significantly faster when I add 'lnum' to
prop_remove(),
but the problem is that lnum isn't known when removing the virtual-text
since
the lines might have shifted.
I think removing a set of virtual text-properties is very common, for
example,
when `align`, `wrap` or `text_padding_left` need to be toggled. The only
way to
accomplish this is by removing the old ones and re-adding them with a
different
'align', 'wrap' etc. value.
On Monday, November 28, 2022 at 12:27:45 PM UTC+1 Bram Moolenaar wrote:
>
> Yegappan wrote:
>
> > > > Currently the prop_add_list() function doesn't support adding
> multiple
> > > > virtual text properties. This functionality is useful when applying
> > > > the inlay hints reply received from a LSP server.
> > >
> > > What is against calling prop_add() for each one?
> >
> > When adding a large number of text properties for inlay hints to a
> > source file with many lines, calling prop_add() multiple times may not
> > be efficient.
> >
> > > prop_add_list() is intended to add the same type of property and a list
> > > of positions. I don't expect you want to add the same text in a list of
> > > positions? Unless it's some kind of error or marker.
> >
> > When adding the text properties for inlay hints, the text will be
> > different for each position.
> >
> > > > Should we extend the prop_add_list() function to support the "text"
> > > > value in the second argument? The second argument (list of items)
> > > > needs to support the following:
> > > >
> > > > [{lnum}, {col}, {end-lnum}, {end-col}, "text"]
> > > >
> > > > Should we make the "text_align", "text_padding_left" and "text_wrap"
> > > > properties common to all the text properties or support a dict for
> the
> > > > list element:
> > > >
> > > > [{lnum}, {col}, {end-lnum}, {end-col}, {'text': value, 'text_align':
> value,
> > > > 'text_padding_left':
> > > > value, 'text'wrap': value}]
> > >
> > > This quickly gets complicated, since depending on what you are adding
> > > some fields will be the same for all properties and some will be
> > > different. I doubt the complexity is justified by calling one function
> > > for multiple text properties instead of calling prop_add() for each
> one.
> > >
> > > Is there a virtual text property with several fields that are the same
> > > (padding, align, etc.) and only differ in position and text?
> >
> > No. The LSP specification for inlay hints is at:
> >
> >
> https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#inlayHint
> >
> > The padding is specified for each inlay hint item.
>
> It also mentions a tooltip. I suppose we don't support that (yet).
>
> Since this is an optimization, and the choices for implementation are
> not directly clear, we should do this later perhaps. Using prop_add()
> now should make clear how it works, even when it's a little bit slower.
> Perhaps we might actually want to make it work better before making it
> more efficient.
>
> --
> Keep America beautiful. Swallow your beer cans.
>
> /// 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
Re: List of features to vote on
Bram, when you say built-in LSP support, do you mean written in C, or as a vim9script plugin? And what do you mean with the last item "may hide part of the first line, scroll per screen line"? It looks like there are quite a few items in the voting list that can be removed since they have been added by now, or that won't be improved (Python, Ruby, TCL interface) since vim9script was added. There are also a couple of duplicate items that can be merged into one item (for example the ones on syntax highlighting or insert-mode completion). On Sun, Jul 3, 2022 at 6:46 PM Bram Moolenaar wrote: > > > Now that Vim 9.0 has been released I thought it would be a good moment > to update the list of features: > https://www.vim.org/sponsor/vote_results.php > > Although it would be nice to reduce the length of the list, I find it > difficult to decide what items to drop. Perhaps items that won't > happen, such as improving the Athena support? > > What I was thinking of adding: > - Multiple cursors, edit in several locations at the same time > - built-in LSP support > - virtual text (e.g. to display type information) > - may hide part of the first line, scroll per screen line > > Anything else? I prefer not to add too many items, only things worth > voting on, to avoid the list getting even longer. > > Note that this is not an invitation for everybody to call out their > favorite feature! > > - Bram > > -- > It was recently discovered that research causes cancer in rats. > > /// 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/20220703164639.577621C091A%40moolenaar.net. -- -- 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/CAPAs8TAqjkuV88ZHn6HdnkqoZdNVgrqCr8JrEWGthmAQwRYgLQ%40mail.gmail.com.
Re: modifying a few characters in a buffer (sanity check)
This has already been requested in the past, see https://github.com/vim/vim/issues/5632. On 2022-03-29, Ernie Rael wrote: > I've done little vim9script programing (and no vimscript). > > I want to replace a part of a buffer line. I thought to do "getline()", > slicing, "setline()", no joy; I couldn't see any way to manipulate the > string directly.Anything better I couldn't find? I'm still getting used > to the synthesis of vim9script and vim commands > > In the following, F1() seems expensive, F2() feels uncomfortable (for > example 'x' command might go to the next line). For performance is F2() > better (assuming there's some checking). > > Any comments/suggestions appreciated > > -ernie > > vim9script > # This line gets modified > # This line gets modified > > def F1(lino: number, pos1: number, pos2: number, newtext: string) > var t1 = getline(lino)->str2list() > t1->remove(pos1, pos2) > t1->extend(str2list(newtext), pos1)->list2str()->setline(lino) > > enddef > > def F2(lino: number, pos1: number, pos2: number, newtext: string) > cursor(lino, pos1 + 1) > execute 'normal ' .. (pos2 - pos1 + 1) .. 'x' > execute 'normal i' .. newtext > enddef > > F1(2, 12, 15, 'BOO') > F2(3, 12, 15, 'FOO') > > > -- > -- > 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/773e9647-93d1-b339-18f6-783e3316e484%40raelity.com. -- -- 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/YkTPjQ62DT6VC/u9%40laptop.homenetwork.
Re: Vim9: Compile time argument type checks for built-in functions
On 2021-07-25, Bram Moolenaar wrote: > > Yegappan wrote: > > > Patch 8.2.3221 added the last of the Vim9 compile time argument > > type check for built-in functions. Now the 525 built-in functions have > > argument type checks. If you run into any problems with these > > checks or if the checks can be improved, let us know. > > Awesome work! Not only do we now have compile time type checking, also > a lot more tests were added. > > We are getting closer and closer to launching Vim9 script. But I do > keep finding bugs, we still need to test more. Ideally all the tests > run on legacy script are also run on compiled functions and Vim9 script. 1. Once Vim9 is officially released will we still have to specify "vim9script" at the top of the script file? 2. Will the parsed Vim9 script files eventually be written to a .vimc file, similar to .pyc or .luac? It would certainly increase the startup time since more often than not script files are not modified when launching Vim. -- -- 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/YP2csxDUm5J8IzVw%40laptop.homenetwork.
Re: new feature: autoevents - catching keystrokes, resize, window deletion
Boson Joe, some of the issues have already been brought up on GitHub: 2) WinClose event: https://github.com/vim/vim/issues/742 3) WinResize event: https://github.com/vim/vim/issues/3226 If you need to do something very often, you could use the SafeState or SafeStateAgain events. See ":help SafeState" for more details. Alternatively, add a custom function to your 'statusline' which monitors your window layout, or whatever you need. The statusline is updated very frequently, hence the function is called very often. Regards, Ben On 2021-07-13, 'boson_joe' via vim_dev wrote: > Hello everybody! > > Long story short - I`ve been working on my plugin that adds tabs into Vim, > and some things that I expected to be done with ease actually turned to be a > whole puzzle. I'm talking about the following events that cannot be caught: > > 1) Keystrokes - there is no uniform way to catch keystrokes. For example, at > one point I had to catch CTRL-W_r and other actions that move windows around > to redraw tab bars timely. There is no way known to me of doing it reliably. > The only way that seems legit to use for this purpose at the moment is > writing a custom processor for all keys typed by the user. > 2) Resize - no way to uniformly catch windows being resized. At the moment, a > combination of actions need to be used, like looking at commands a user > entered to catch ":resize", catching Vim resize, etc, etc. > 3) Window deletion - there is no event to catch window deletion. I personally > used a combination of WinEnter with checking if the previous window was > deleted, which is not 100% bug free. > > I am writing this mail because during discussion of this topics on the > Internet some people suggested to write about this features here in case > somebody finds these useful as well. So, I would like to ask if there is any > demand on these features to be added and if it is even possible? > > Thank you in advance for your time! > > Best, > boson joe > > PS. I am sorry if I am being too straight-ahead with the features. Don't want > to clutter the maillist up with the things that are not relevant. > > -- > -- > 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/QV0CnWWj3Gcjuq6iVmEULg2zqxaB_O4P_WnBK8gVrpJomCGNP0oC2JvnddKpjhzPbbfGKWscZE6uKE7g0JmaHPy4-qrcyQo-C78KQs-YXdo%3D%40protonmail.com. -- -- 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/YPFla6FtWHjYsPNj%40laptop.homenetwork.
