Re: Support for Private class/object methods

[shane.qian]

On 23/08/24 08:18PM, 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,
> Yegappan

what's the time that 'todo' item added?
2022/02/08 bram had comment about that:
https://github.com/vim/vim/issues/9713#issuecomment-1031938822

-- 
shane.xb.qian

-- 
-- 
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/OSZP286MB09187403B9D60C23527E8C86EBE3A%40OSZP286MB0918.JPNP286.PROD.OUTLOOK.COM.

Re: Support for Private class/object methods

[Ernie Rael]

On 23/08/24 9:10 PM, 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".


Is it only redundant, or is there some semantic meaning or change? 
Referring only to functions?


About that "_". Looking through that old thread, and thinking about the 
code I've got. It is convenient to look at a member name and immediately 
know it's private. Allowing "private" doesn't seem that important; I 
don't particularly buy into the "only have one way to do it" but private 
member seems low priority to me.


-ernie


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/CAJ1uvoBnoV9pM47k%2BGsSDApk3Xciu4RgGrSQJKbc0V1e8NAJjw%40mail.gmail.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/3981d25d-d088-800d-462e-106f7be031fb%40raelity.com.

Re: Support for Private class/object methods

[Yegappan Lakshmanan]

Hi,

On Thu, Aug 24, 2023 at 9:11 PM 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?
>

Yes.

>
> 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 for forwarding the email thread.  I totally forgot about that
discussion.  It is unfortunate
there was no conclusion at the end of that thread that we can refer to.

Regards,
Yegappan

> 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/CAAW7x7%3DanbqeJ9MjoZyP71zsXYPP5bT7%2BQwTB2E0JXvAaj%3DTFQ%40mail.gmail.com.

Re: Support for Private class/object methods

[Yegappan Lakshmanan]

Hi,

On Thu, Aug 24, 2023 at 8:50 PM Ernie Rael  wrote:
>
> On 23/08/24 8:18 PM, 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.
>
> That's mostly a parsing issue? The requirement becomes _[A-Z] means private.
>

Yes. It is a parsing issue.  Using the "_" prefix for both private members
and methods will make it symmetric though.

>
> >   So I have
> > implemented this using the "private" keyword.
>
> Can "private" be used with members, in addition to prefixing "_"?
>

We can make changes to support the "private" keyword for members also.


>
> > Any opinions?
> I'm personally OK with "private", and happy to avoid the parsing
> hassles. Would like to see it usable with class/instance members.
>

Let me see whether we can support using the "_" prefix for private methods.

Thanks,
Yegappan

-- 
-- 
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/CAAW7x7%3DcCempeBm2aW%3DP6%3DyjWdYTVJ_w8bXNZyfor6OuiiwB9g%40mail.gmail.com.

Re: Support for Private class/object methods

[Doug Kearns]

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/CAJ1uvoBnoV9pM47k%2BGsSDApk3Xciu4RgGrSQJKbc0V1e8NAJjw%40mail.gmail.com.

Re: Support for Private class/object methods

[Ernie Rael]

On 23/08/24 8:18 PM, 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.

That's mostly a parsing issue? The requirement becomes _[A-Z] means private.

  So I have
implemented this using the "private" keyword.

Can "private" be used with members, in addition to prefixing "_"?

Any opinions?
I'm personally OK with "private", and happy to avoid the parsing 
hassles. Would like to see it usable with class/instance members.


-ernie



Thanks,
Yegappan



--
--
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/969ed3c5-c760-e743-d057-3b48f1f10b85%40raelity.com.

Support for Private class/object methods

[Yegappan Lakshmanan]

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,
Yegappan

-- 
-- 
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/CAAW7x7nGpgMAmCyMkezRJxFKJyEtujmmhBn1rOShnb2sx4%3D4Tg%40mail.gmail.com.

Re: Updates on the Vim project

[Ernie Rael]

On 23/08/24 2:44 AM, Tony Mechelynck wrote:

[...]
Well,  if the Mercurial mirror goes puff, I'll have to decide
either to fall back on the Vim from my distro (always somewhat behind,
currently 9.0.1632 and with a slightly different choice of features
than I would have chosen) or to start learning git seriously on a
fresh clone.


Have you considered the "hg-git" extension? "hg-git" on PyPi. It's had a 
lot of work done in the last couple of years; it's in good shape,  with 
regular releases. Also the newer "evolve" extension is useful, I use it 
in favor of mq.


-ernie



Best regards,
Tony



Let me know, what you all think.
__
¹) https://github.com/vim/vim/pulls?q=is%3Aopen+is%3Apr+milestone%3Avim-9.1

Thanks,
Christian
--
You are dishonest, but never to the point of hurting a friend.

--
--
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/ZOZpf40nvrjjllpo%40256bit.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/8ee16bd0-86f5-f70e-10e3-1decc99cdbd0%40raelity.com.

Commit: runtime(todo): Update todo.txt to remove recently addressed issues (#12910)

[Christian Brabandt]

runtime(todo): Update todo.txt to remove recently addressed issues (#12910)

Commit: 
https://github.com/vim/vim/commit/e750f8c330bc28ee9f3b7dce06481311a090972f
Author: Yegappan Lakshmanan <4298407+yegap...@users.noreply.github.com>
Date:   Thu Aug 24 07:07:05 2023 -0700

runtime(todo): Update todo.txt to remove recently addressed issues 
(https://github.com/vim/vim/issues/12910)

Signed-off-by: Christian Brabandt 

diff --git a/runtime/doc/todo.txt b/runtime/doc/todo.txt
index 93c19b514..8479e15d3 100644
--- a/runtime/doc/todo.txt
+++ b/runtime/doc/todo.txt
@@ -61,8 +61,6 @@ without all the help files.
 SpellCap highlight not updated - PR #12428
 
 Virtual text problems:
--  Deleting character before a wrapping virtual text, causes for the following
-   lines to dissapear (Issue #12244)
 -  If 'list' is on, 'below' virtual text which includes 1 or 2 characters are
gone (Issue #12028)
 -  Virtual text aligned "above": Wrong indentation when using tabs  (Issue
@@ -75,14 +73,6 @@ Virtual text problems:
'below' on an empty line (Issue #11959)
 -  truncated Virtual text below an empty line causes display error #12493
 
-include #12403: window for Termdebug showing local variables
-
-include #12140: positional arguments in printf(), fixes #10577
-
-Include #11818: attach custom data to quickfix items.
-
-Include #12292: buffer argument for undotree()?
-
 When 'virtualedit' is "all" and 'cursorcolumn' is set, the wrong column may be
 highlighted. (van-de-bugger, 2018 Jan 23, #2576)
 
@@ -131,7 +121,7 @@ Upcoming larger works:
 
 
 Further Vim9 improvements, possibly after launch:
-- implement :class and :interface: See |vim9-classes
+- Classes and Interfaces. See |vim9-classes|
   - Change access: public by default, private by prefixing "_".
Check for error: can't have same name twice (ignoring "_" prefix).
   - Private methods?
@@ -142,22 +132,15 @@ Further Vim9 improvements, possibly after launch:
   - Cannot use class type of itself in the method (Issue #12369)
   - Cannot use an object method in a lambda  #12417
Define all methods before compiling them?
-  - class members initialized during definition (Issue #12041)
   - Cannot call class member of funcref type  (Issue #12324)
Also #12081 first case.
   - Using list of functions does not work #12081 (repro in later message).
-  - Weird `class X not found on interface X` error (Issue #12023)
   - First argument of call() cannot be "obj.Func". (#11865)
-  - "return this" required for early return from constructor (inconsistent)
-(Issue #12040)
-  - class/method confusion inside ":def" when using "class extends" (Issue
-#12089)
   - null_object - constant type 17 not supported (Issue #12043)
   - problem compiling object method call as function call argument (Issue
 #12081)
   - Make ":defcompile ClassName" compile all functions and methods in the
 class.
-  - object's method in stacktrace missing information (Issue #12078)
   - Forward declaration of a class?  E.g. for Clone() function.
email lifepillar 2023 Mar 26
   - Getting member of variable with "any" type should be handled at runtime.
@@ -180,7 +163,7 @@ Further Vim9 improvements, possibly after launch:
   - For chaining, allow using the class name as type for function return
 value.
   - Implement generics
-  - Add "instanceof" (exact class name).  And "assignable" (class or child)?
+  - Add "assignable" (class or child)?
   - More efficient way for interface member index than iterating over list?
   - a variant of type() that returns a different type for each class?
   list and list should also differ.
diff --git a/runtime/doc/vim9.txt b/runtime/doc/vim9.txt
index 4b0cdbb67..1431a134e 100644
--- a/runtime/doc/vim9.txt
+++ b/runtime/doc/vim9.txt
@@ -1033,10 +1033,12 @@ In Vim9 script one can use the following predefined 
values: >
null
null_blob
null_channel
+   null_class
null_dict
null_function
null_job
null_list
+   null_object
null_partial
null_string
 `true` is the same as `v:true`, `false` the same as `v:false`, `null` the same

-- 
-- 
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/E1qZB72-00GS9y-T3%40256bit.org.

Re: Updates on the Vim project

[Enan Ajmain]

On Thu, 24 Aug 2023 01:00:39 -0700
"akspecs"  wrote:
> Long time vim operator here (for more than half my life).
>
> I believe sourcehut [1][2] would be a great service to consider to host
> and/or mirror vim's source code.
>
> On Thu Aug 24, 2023 at 12:33 AM PDT, mattn wrote:
> > OSDN hosting has already become unacceptable.
> > The console screen appears only once every few times. Also, shell.osdn.net
> > rarely connects.
>
> In comparison, sourcehut has a very fast and snappy user experience with
> their web based interface.
>
> sourcehut's lead is also based in Amsterdam!
>
> > 2023___8___24 15:34:45 UTC+9 Ken Takata:
> >
> > > Hi Christian,
> > >
> > > > For a similar reason and because of the mess I created with the
> > > > mercurial mirror, I am thinking to retire the mercurial repository. I
> > > > think it is pretty clear that nowadays git is the preferred VCS of
> > > > choice for most programmers.
> > >
> > > To be honest, I'm still using the mercurial mirror on osdn.net.
> > > I use MQ (mercurial queues) to manage my personal patches.
> > > There are some similar tools for Git (guilt, etc.),
> > > but they had some issues (for my usecases) when I tried them.
>
> for this reason, i suggest sourcehut.  one can host either git or
> mercurial repos with the sourcehut platform.  the platform is also
> designed around plaintext mailing list workflows.

Not to speak for Christian, but I don't think he is considering retiring
the Hg repo because of lack of hosting options.  He was weighing the
cost of maintaining an Hg clone and its benefit to its users.  But,
granted, if one were to have two clones, having them in one site is
preferable.

> i really do hope the folks in charge of this project seriously consider
> this as an option.

I'm a fan of SourceHut and its creator (owner?) Drew.  But AFAIK its CI
feature is paid-only while GitHub's is free.  And I don't think srht
supports Windows at all (unsure on this).  Then there is the issue of
srht being a small company with relatively smaller set of engineers to
its disposal.  If issues were to occur, I would bet on GH solving them
faster than srht.

I can't give hard data: the documentation of srht are exhaustive and I
don't have time to read and distil it.  Just wanted to leave what little
I do know.  I really would like it if Vim moved to srht, though, even if
just because of the simplicity and the email-centric workflow of srht.
Unfortunately it seem untenable.

--
Enan

P.S.  I just saw you said "host and/or mirror."  Mirroring Vim source in
srht would be nice, actually.  We can use the free CI on GH and use srht
for actual devel.  Could be fun.

> [1]: https://sourcehut.org
> [2]: https://sr.ht

-- 
-- 
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/20230824194337.0a92%40gmail.com.

Re: Updates on the Vim project

[Marvin Renich]

* Tony Mechelynck  [230824 05:45]:
> On Wed, Aug 23, 2023 at 10:18 PM Christian Brabandt  
> wrote:
> [...]
> > For a similar reason and because of the mess I created with the
> > mercurial mirror, I am thinking to retire the mercurial repository. I
> > think it is pretty clear that nowadays git is the preferred VCS of
> > choice for most programmers.
> 
> Ah, too bad. I never got around to really understand how git "thinks"
> while I understand Mercurial well enough and, as with Vim, when I
> forget something about Mercurial I find it easily and quickly in the
> online help. Lately I used "hg help merge" to get out of the
> above-mentioned "mess" and it seems more or less OK. If you retire the
> Mercurial repository I shall have to scrap what I have and start again
> from scratch with a fresh clone of the git master. I daresay I am not
> enchanted with the prospect.

I rarely need bleeding-edge features, and James McCoy keeps the Debian
version more than close enough to the latest for my needs (Thanks,
James!), so I have only built from source a small number of times in the
past decade.  In the early years, before Vim had a public Mercurial
repo, I was building from source more often.

However I, too, strongly prefer Mercurial over Git.  Git is the most
over-engineered piece of software from this millennium.  One of its most
touted features, the index, is really its biggest wart and hindrance to
usability.  Almost anything you want to do is simpler to understand and
at least as simple to do in Mercurial.

In another part of this thread, someone suggested sourcehut.org.  I
hadn't heard of them, but from their website, I think it might be work a
try.

...Marvin

-- 
-- 
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/ZOdYA8nHPeItm7WG%40basil.wdw.

Re: Updates on the Vim project

[Tony Mechelynck]

On Wed, Aug 23, 2023 at 10:18 PM Christian Brabandt  wrote:
[...]
> For a similar reason and because of the mess I created with the
> mercurial mirror, I am thinking to retire the mercurial repository. I
> think it is pretty clear that nowadays git is the preferred VCS of
> choice for most programmers.

Ah, too bad. I never got around to really understand how git "thinks"
while I understand Mercurial well enough and, as with Vim, when I
forget something about Mercurial I find it easily and quickly in the
online help. Lately I used "hg help merge" to get out of the
above-mentioned "mess" and it seems more or less OK. If you retire the
Mercurial repository I shall have to scrap what I have and start again
from scratch with a fresh clone of the git master. I daresay I am not
enchanted with the prospect.

Well,  if the Mercurial mirror goes puff, I'll have to decide
either to fall back on the Vim from my distro (always somewhat behind,
currently 9.0.1632 and with a slightly different choice of features
than I would have chosen) or to start learning git seriously on a
fresh clone.

Best regards,
Tony


>
> Let me know, what you all think.
> __
> ¹) https://github.com/vim/vim/pulls?q=is%3Aopen+is%3Apr+milestone%3Avim-9.1
>
> Thanks,
> Christian
> --
> You are dishonest, but never to the point of hurting a friend.
>
> --
> --
> 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/ZOZpf40nvrjjllpo%40256bit.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/CAJkCKXsugKURy-4x3gNaDVVaPDYbbnJeNd66Q%2B6yj4We-yY%3DkA%40mail.gmail.com.

Re: Updates on the Vim project

[akspecs]

Long time vim operator here (for more than half my life).

I believe sourcehut [1][2] would be a great service to consider to host
and/or mirror vim's source code.

On Thu Aug 24, 2023 at 12:33 AM PDT, mattn wrote:
> OSDN hosting has already become unacceptable.
> The console screen appears only once every few times. Also, shell.osdn.net 
> rarely connects.

In comparison, sourcehut has a very fast and snappy user experience with
their web based interface.

sourcehut's lead is also based in Amsterdam!

> 2023年8月24日木曜日 15:34:45 UTC+9 Ken Takata:
>
> > Hi Christian,
> >
> > > For a similar reason and because of the mess I created with the 
> > > mercurial mirror, I am thinking to retire the mercurial repository. I 
> > > think it is pretty clear that nowadays git is the preferred VCS of 
> > > choice for most programmers. 
> >
> > To be honest, I'm still using the mercurial mirror on osdn.net.
> > I use MQ (mercurial queues) to manage my personal patches.
> > There are some similar tools for Git (guilt, etc.),
> > but they had some issues (for my usecases) when I tried them.

for this reason, i suggest sourcehut.  one can host either git or
mercurial repos with the sourcehut platform.  the platform is also
designed around plaintext mailing list workflows.

i really do hope the folks in charge of this project seriously consider
this as an option.

[1]: https://sourcehut.org
[2]: https://sr.ht

-- 
-- 
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/CV0M7VETCYRL.V7LB6EZOZ7M7%40nano.

Re: Updates on the Vim project

[mattn]

OSDN hosting has already become unacceptable.
The console screen appears only once every few times. Also, shell.osdn.net 
rarely connects.

2023年8月24日木曜日 15:34:45 UTC+9 Ken Takata:

> Hi Christian,
>
> > For a similar reason and because of the mess I created with the 
> > mercurial mirror, I am thinking to retire the mercurial repository. I 
> > think it is pretty clear that nowadays git is the preferred VCS of 
> > choice for most programmers. 
>
> To be honest, I'm still using the mercurial mirror on osdn.net.
> I use MQ (mercurial queues) to manage my personal patches.
> There are some similar tools for Git (guilt, etc.),
> but they had some issues (for my usecases) when I tried them.
>
> Regards,
> Ken Takata
>
> 2023年8月24日木曜日 14:58:12 UTC+9 Ernie Rael:
>
>> Hoping https://github.com/vim/vim/pull/12192 is merged. 
>>
>> Vim 9.1 has a nsec profiling clock available; but without this PR, which 
>> fixes a severe timing problem related to user function calls, we can't 
>> say v9.1 has high accuracy profiling. 
>>
>> -ernie 
>>
>> On 23/08/23 1:18 PM, Christian Brabandt wrote: 
>> > Hi, 
>> > this is a small update over what happened the last few weeks. 
>> > 
>> > Over the last days, I have been merging mostly runtime file changes, 
>> > small improvements to the Vim9 class implementations and bug fixes. 
>> > 
>> > If you check the Milestone¹ for the release 9.1, most of the remaining 
>> > changes are small runtime changes, for which I'd like to get an 
>> > ACK/NACK. 
>> > 
>> > Thanks for all your contributions, this is really appreciated! 
>> > 
>> > I am not sure, what the status of the Vim9 classes implementation is 
>> and 
>> > if we are going to get further improvements there or if we can consider 
>> > this "good enough". 
>> > 
>> > @Yegappan, what is your opinion? 
>> > 
>> > If you are a runtime file maintainer, or you have been providing 
>> > translations, now it's time to check your runtime files against the 
>> > version in the Vim repository and please consider sending updated 
>> files. 
>> > 
>> > I also checked the huntr organization, but it looks like there are no 
>> > open security issues reported over there. 
>> > 
>> > On a somewhat related note, I have been asked how to handle security 
>> > issues in the future and I am thinking about creating a "private" list 
>> > for this. Not sure how to handle packagers or if it is good enough, if 
>> I 
>> > mark commits/mails with some security related flag. 
>> > 
>> > Regarding the vim Homepage, I'll move it to a new hoster after the 
>> > release has been done. I got several offers so that should not be a 
>> > problem. I'll also need to check the amount of work to migrate the old 
>> > php5 code to an updated php version. 
>> > 
>> > Regarding the ftp server, I decided to no longer use it. I checked with 
>> > the owners and while they were willing to help, I come to the 
>> conclusion 
>> > that it stems from an old time and it no longer required, so I will not 
>> > update the data there. I may however need to download the generated 
>> > spell files and move this to the new Vim Homepage, once it has been 
>> > moved. 
>> > 
>> > For a similar reason and because of the mess I created with the 
>> > mercurial mirror, I am thinking to retire the mercurial repository. I 
>> > think it is pretty clear that nowadays git is the preferred VCS of 
>> > choice for most programmers. 
>> > 
>> > Let me know, what you all think. 
>> > __ 
>> > ¹) 
>> https://github.com/vim/vim/pulls?q=is%3Aopen+is%3Apr+milestone%3Avim-9.1 
>> > 
>> > Thanks, 
>> > Christian 
>>
>>
>>

-- 
-- 
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/16d3bd06-5835-4af0-ba39-de399c651e6cn%40googlegroups.com.

Re: Commit: patch 9.0.1786: Vim9: need instanceof() function

[Tony Mechelynck]

On Thu, Aug 24, 2023 at 8:01 AM Christian Brabandt  wrote:
>
>
> On Do, 24 Aug 2023, Christian Brabandt wrote:
>
> >
> > On Mi, 23 Aug 2023, Tony Mechelynck wrote:
> >
> > > Discontinuous tagging again : notice the second line below.
> > >
> > > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Aug 23 2023 23:29:38)
> > > Included patches: 1-1783, 1786
> > > Compiled by antoine.mechely...@gmail.com
> > > Huge version with GTK3 GUI.  Features included (+) or not (-):
> > > [...]
> >
> > Yeah I noticed. hg refuses to sync the git patches
>
> But should be in sync now again

Well, once again I had to merge manually because of several heads. I
hope I ended up at the right place (i.e. with the right "current
directory") even if not by the canonical way (i.e. maybe I merged in a
different sequence). At least I arrived at a sequential "list of
patches" in version.c.

>
> Best,
> Christian
> --
> I don't do it for the money.
> -- Donald Trump, Art of the Deal
I don't do it, period.


Best regards,
Tony.

-- 
-- 
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/CAJkCKXv7QYxcOzu0oXM3uEBAkax5buHOaYP%2B3BqAjrJqpGA3fA%40mail.gmail.com.