Updates on the Vim project

[Christian Brabandt]

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 are dishonest, but never to the point of hurting a friend.

[Yegappan Lakshmanan]

Hi Christian,

On Wed, Aug 23, 2023 at 1:18 PM Christian Brabandt <cbl...@256bit.org> 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.
>

Thanks.

>
> 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?
>

There are still several todo items related to Vim9 classes. But I
think it is usable
for simple plugins. We can keep improving the support after the 9.1 release.

The https://github.com/vim/vim/pull/12890 PR should be merged. I also
found another
minor issue and will open a PR for that.

Regards,
Yegappan

[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

[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:

[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:

[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

[Tony Mechelynck]

On Wed, Aug 23, 2023 at 10:18 PM Christian Brabandt <cbl...@256bit.org> 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, <sigh /> 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+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZOZpf40nvrjjllpo%40256bit.org.

[Marvin Renich]

* Tony Mechelynck <antoine.m...@gmail.com> [230824 05:45]:

> On Wed, Aug 23, 2023 at 10:18 PM Christian Brabandt <cbl...@256bit.org> 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

[Enan Ajmain]

On Thu, 24 Aug 2023 01:00:39 -0700
"akspecs" <aks...@gmail.com> 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.

[Ernie Rael]

On 23/08/24 2:44 AM, Tony Mechelynck wrote:
> [...]

> Well, <sigh /> 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

[akspecs]

i have some potentially exciting news.

On Thu Aug 24, 2023 at 6:43 AM PDT, Enan Ajmain wrote:
> 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.

indeed, both the git and mercurial repositories can be mirrored on sr.ht
in fact, i went ahead and jumpstarted the process.

check out both the git [0] and mercurial [1] sourcehut mirrors of the
official vim repository!

[0]: https://git.sr.ht/~vim-project/vim
[1]: https://hg.sr.ht/~vim-project/vim

so far i've done this by hand, but i'd be willing to automate this if
the community likes the idea of a sourcehut mirror!

> > 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 just asked drew (ddevault) on libera.chat #sr.ht for his thoughts on
the matter.

tl;dr drew is willing to have vim hosted on sourcehut and provide CI,
and if need be, there are willing members of the community who are
willing to front the costs!

irc log paste:
+=======================================================================
* 08/27 ddevault we would be happy to host vim, akspecs
* ddevault but I think they can manage to find someone who can
* scrounge up the 2 bucks per month the CI costs at the
* scale of vim
* 00:14 ddevault no windows support would probably be more important
* to them
* akspecs i'd be happy to do that -- i'll relay that info to
* them
* qball yeah, I would have no problem doing that.
* 00:15 ddevault well, let me be less of a scrooge
* ddevault I have a Vim tattoo for heaven's sake
* ddevault we'll cover it
* ddevault assuming that the volume is not so high as to be a
* serious cost sink for us to sponsor
* 00:19 qball lol
* ddevault the CI* volume, to be clear, we can cover any volume
* of email or git traffic or whatever
* 00:20 ddevault as for whether or not we'd have resources to address
* vim's problems, well, maybe not, but unlike github
* you don't have to convince anyone to care enough to
* patch a proprietary codebase for you; you can just
* fix things yourself if sourcehut staff aren't
* available to help
+======================================================================

he said it himself. and the man (drew) said it himself: if there's
something we find lacking with sr.ht CI, we have the power the address
that issue ourselves! however, it is my observation that the sourcehut
community and platform is thriving.

i think many here would be impressed with the wide array of available CI
platforms to test on.

and i'm certain there would be willing members of the community to help
write these integrations, myself included.

> 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.

i don't see why not. sourcehut's documentation is good. and it would
seem that many here do genuinely appreciate the email-centric workflow,
for which sourcehut provides first class support.

> 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.

again, the Vim project has the OK to use CI on sourcehut. we can use
github CI for proprietary target platforms, as sourcehut only supports
open source platforms.

[0]: https://git.sr.ht/~vim-project/vim
[1]: https://hg.sr.ht/~vim-project/vim

[Christ van Willegen]

Hi,

Op wo 23 aug. 2023 22:18 schreef Christian Brabandt <cbl...@256bit.org>:

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 hope this isn't taken as "tooting my own horn", since it's not intended to be, but translations can now reorder the arguments passed to printf() (and, consequently, in the translations) by using the $ positional argument specifier(s) in the translation. This may make error messages more readable in other languages. This same code has been added to NeoVim (as far as I can tell), so you can reuse translations back and forth.

Christ van Willegen

[Enan Ajmain]

Seems promising. Thanks for doing the recon. We should consider this
seriously. Wonder what the core devs think of this. Instead of copying
(or tagging) them here, would you mind opening a separate thread for
this proposal? I don't wanna push something on you but you do seem to
have the most information.

Consider listing all the pros and cons of shifting to srht, if you do
open a new thread for the proposal. Many people don't know about srht.
Unfortunately.

Thanks, man. This is exciting!

--
Enan

[Doug Kearns]

On Thu, 24 Aug 2023 at 06:18, Christian Brabandt <cbl...@256bit.org> 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.

Did you have a rough date in mind for the release?  Are we looking at weeks or months?

Thanks,

Doug

[Christian Brabandt]

I did go through the Vim9.1 milestone and try to merge what seems
uncontroversial and fixes crashes. But somehow I keep getting new PRs
there all the time :) (I am joking)

I would think once Yegappan thinks the Vim9 classes is good enough to
release, I'd go ahead. Not sure how much work this is left to be done,
but I'd rather sooner release than later. So it depends on how far we
want the Vim9 classes implementation have ready for the new release.

Also I'd like to get a few of Charles issues fixed if possible.
@Charles, please consider sending updates and checking the vim9.1
Milestone in Github https://github.com/vim/vim/milestone/1 for issues in
your plugins.

Thanks,
Christian
--
A full belly makes a dull brain.
-- Ben Franklin

[and the local candy machine man. Ed]

[Yegappan Lakshmanan]

Hi Christian,

On Sun, Aug 27, 2023 at 11:09 AM Christian Brabandt <cbl...@256bit.org> wrote:
>
> >
> > On Thu, 24 Aug 2023 at 06:18, Christian Brabandt <cbl...@256bit.org> 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.
> >
> >
> > Did you have a rough date in mind for the release? Are we looking at weeks or months?
>
> I did go through the Vim9.1 milestone and try to merge what seems
> uncontroversial and fixes crashes. But somehow I keep getting new PRs
> there all the time :) (I am joking)
>

:-). I keep adding the runtime file changes and minor fixes to the
Vim 9.1 milestone.
Can we take fixes for one more week and then stop?

>
> I would think once Yegappan thinks the Vim9 classes is good enough to
> release, I'd go ahead. Not sure how much work this is left to be done,
>

I want to make sure that all the Vim9 class changes that may break backward
compatibility go in before the Vim 9.1 release. I think, we are down to the
last one and it is about the default access for an object/class member variable.

Regards,
Yegappan

[Yegappan Lakshmanan]

On Sun, Aug 27, 2023 at 11:09 AM Christian Brabandt <cbl...@256bit.org> wrote:
>

> I would think once Yegappan thinks the Vim9 classes is good enough to
> release, I'd go ahead. Not sure how much work this is left to be done,
> but I'd rather sooner release than later. So it depends on how far we
> want the Vim9 classes implementation have ready for the new release.
>

The following Vim 9 class related items are currently in the todo list:

1. Change access: public by default, private by prefixing "_".
2. Check for error: can't have the same name twice (ignoring "_" prefix).
3. "final" object members - can only be set in the constructor.
4. Support export/import of classes and interfaces.
5. Cannot use class type of itself in the method (Issue #12369)
6. Cannot use an object method in a lambda (Issue #12417)
7. Cannot call class member of funcref type (Issue #12324)
8. Using a list of functions does not work (Issue #12081)
9. First argument of call() cannot be "obj.Func". (Issue #11865)
10. Make ":defcompile ClassName" compile all functions and methods in the class.
11. Support forward declaration of a class. E.g. for Clone() function.
12. Getting a member variable with "any" type should be handled at runtime.
13. "obj.Method()" does not always work in a compiled function, assumes "obj"
is a dictionary. (Issue #12196, #12024, #11822, #12198, #11981)
14. Support empty(), len() for objects.
15. Check types for "implements" - members and methods
16. Support locking and unlocking objects/classes.
17. When checking "implements" also check types of members and function args.
18. For chaining, allow using the class name as type for function return value.
19. Implement generics
20. Add "assignable" (class or child)?
21. Use a more efficient way for interface member index than iterating
over list.
22. Implement a variant of type() that returns a different type for each class.
23. Support class local to a function.
24. Support promise class, could be used to wait on a popup close callback.

Other than the first two items, I don't think we can get to the other items in
this list for the 9.1 release.

Regards,
Yegappan

[Christian Brabandt]

On So, 27 Aug 2023, Yegappan Lakshmanan wrote:

> Hi Christian,
>
> On Sun, Aug 27, 2023 at 11:09 AM Christian Brabandt <cbl...@256bit.org> wrote:
> >
> > >
> > > On Thu, 24 Aug 2023 at 06:18, Christian Brabandt <cbl...@256bit.org> 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.
> > >
> > >
> > > Did you have a rough date in mind for the release? Are we looking at weeks or months?
> >
> > I did go through the Vim9.1 milestone and try to merge what seems
> > uncontroversial and fixes crashes. But somehow I keep getting new PRs
> > there all the time :) (I am joking)
> >
>
> :-). I keep adding the runtime file changes and minor fixes to the
> Vim 9.1 milestone.
> Can we take fixes for one more week and then stop?

Yes of course.

>
> >
> > I would think once Yegappan thinks the Vim9 classes is good enough to
> > release, I'd go ahead. Not sure how much work this is left to be done,
> >
>
> I want to make sure that all the Vim9 class changes that may break backward
> compatibility go in before the Vim 9.1 release. I think, we are down to the
> last one and it is about the default access for an object/class member variable.

Perfect. That is fine.

Best,
Christian
--
18th Rule of Friendship:
A friend will let you hold the ladder while he goes up on the roof
to install your new aerial, which is the biggest son-of-a-bitch you
ever saw.
-- Esquire, May 1977

[Christian Brabandt]

On So, 27 Aug 2023, Yegappan Lakshmanan wrote:

That makes sense. Once the first two are included, we can have a one or
two week stability phase (to fix only crashes and other regressions)
before we push out the release. That will be an interesting exercise...

Thanks,
Christian
--
Divorce Assumption:
A form of Safety Net-ism, the belief that if a marriage
doesn't work out, then there is no problem because partners can simply
seek a divorce.
-- Douglas Coupland, "Generation X: Tales for an Accelerated
Culture"

[tux0r]

Ahoy,

> I'll also need to check the amount of work to migrate the old php5 code to an updated php version.

I’m sure there’s not /too/ much work involved. Basically,

1) replace mysql_* by mysqli_* (if used),
2) depending on the target version, add default parameters (PHP 8 prefers a slightly different syntax).

> 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.

Most programmers use Git because they aren’t granted any choice. It’s mostly: Git or nothing. I, for one, wouldn’t touch Git with a ten-foot pole. Compared to Mercurial and SVN (which I, personally, prefer for bazaar projects…), it is highly unreliable to use, only roughly compatible with Windows and its user interface is a horrible mess.

Although I use Git for my Vim builds (I moved away from Mercurial last year or so - there were problems fetching updates and I was too impatient to track them down), I can only suggest to *not* retire the mirror.

[Christian Brabandt]

On Mo, 28 Aug 2023, tux0r wrote:

> Ahoy,
>
> > I'll also need to check the amount of work to migrate the old php5 code to an updated php version.
>
> I’m sure there’s not /too/ much work involved. Basically,
>
> 1) replace mysql_* by mysqli_* (if used),

Yes, that was actually all that was needed.

> 2) depending on the target version, add default parameters (PHP 8 prefers a slightly different syntax).

Currently running on an empty db, and it seems to work fine.

> Most programmers use Git because they aren’t granted any choice. It’s
> mostly: Git or nothing. I, for one, wouldn’t touch Git with a ten-foot
> pole. Compared to Mercurial and SVN (which I, personally, prefer for
> bazaar projects…), it is highly unreliable to use, only roughly
> compatible with Windows and its user interface is a horrible mess.
>
> Although I use Git for my Vim builds (I moved away from Mercurial last
> year or so - there were problems fetching updates and I was too
> impatient to track them down), I can only suggest to *not* retire the
> mirror.

I use git, because all the information can easily be found in the
internet and it is still very actively developed and a lot of questions
on how to use it have already been asked :).

For mercurial I have to refresh my memories and the information on
StackOverflow and similar seem slightly outdated. And I just do not
remember how to use it anymore :/

But maybe it is just me...

Thanks,
Christian
--
Before you ask more questions, think about whether you really want to
know the answers.
-- Gene Wolfe, "The Claw of the Conciliator"

[tux.]

If your PHP runs on E_ALL and everything’s fine, you’re probably good indeed.

Unlike Git, hg won’t need too many tutorials on the internet because it’s intuitive to use. :-p

YMMV…

--
--
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+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZOzT3jaGX7yzQxwd%40256bit.org.

[Christian Brabandt]

On Mo, 28 Aug 2023, tux. wrote:

> If your PHP runs on E_ALL and everything’s fine, you’re probably good indeed.
>
> Unlike Git, hg won’t need too many tutorials on the internet because it’s intuitive to use. :-p

I already pushed two different heads for hg, so I already broke the
workflow for too many people. And I have no idea what that means and how
to fix this (other than force-pushing). So as usual, the devil is in the
details 🤷

Best,
Christian
--
What passes for woman's intuition is often nothing more than man's
transparency.
-- George Nathan

[Tony Mechelynck]

On Thu, Aug 24, 2023 at 4:17 PM Ernie Rael <err...@raelity.com> wrote:
>
> On 23/08/24 2:44 AM, Tony Mechelynck wrote:
> > [...]
> > Well, <sigh /> 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

I have used the mq extension, and it is OK for the uses I have, but
since I don't do actual "development" I use it rarely, and mostly for
typos in helpfiles, which I could just as well (but maybe a little
less practically for the maintainer) mention in purely "human readable
text" such as:
in file runtime/doc/foobar.txt, at line 1234
there is: azertyuiop wxcvbn
there should be: qwertyuiop wxcvbn

About using Mercurial on a git repo, I see that there is a "git"
extension distributed with Mercurial, but disabled by default and
labeled as "EXPERIMENTAL" in capitals in the output of "hg help
extensions". OTOH the output of "hg --config extensions.git= help
git" is extremely terse to the point that it seems only meant to make
people afraid of it.
If that hg-git extension you mention is so good, why haven't the
Mercurial maintainers adopted it ? I daresay I have cold feet about
it.

Christian, do you have any recommendations for someone who would want
to continue porting the changes from git to Mercurial if you ever
decide to close your own Mercurial mirror, or is it not worth the
trouble unless this new Mercurial mirror is made public (for instance
by maintaining a git mirror, exporting each patch as a set of diffs,
and importing that to a Mercurial clone) ? (I used to have a user site
but my ISP has closed it for no other reason than "if you want to
continue having a user site after DD/MM/YYYY, get into contact with us
before that date and an engineer of ours will build it for you". — I
was perfectly happy with building it slowly but surely by FTP and I
prefer to mind my own business, thank you.)


Best regards,
Tony.

[Christian Brabandt]

On Mo, 28 Aug 2023, Tony Mechelynck wrote:

> Christian, do you have any recommendations for someone who would want
> to continue porting the changes from git to Mercurial if you ever
> decide to close your own Mercurial mirror, or is it not worth the
> trouble unless this new Mercurial mirror is made public (for instance
> by maintaining a git mirror, exporting each patch as a set of diffs,
> and importing that to a Mercurial clone) ? (I used to have a user site
> but my ISP has closed it for no other reason than "if you want to
> continue having a user site after DD/MM/YYYY, get into contact with us
> before that date and an engineer of ours will build it for you". — I
> was perfectly happy with building it slowly but surely by FTP and I
> prefer to mind my own business, thank you.)

For a recommendation you mean what is required to set this up manually?

It's currently a self-written shell script (attached)¹, that pulls the
git mirror every 15 minutes and pushes each commit as new change to the
mercurial repository. It used to work flawlessly (until I recently added
pushing out mails). I reverted that part for now, let's see how well
this works in the future. If it keeps running as good as it was in the
past and doesn't cause any more issues, then it will just keep being
updated.

There is currently the following line commented out:
,----
| # echo "$patch" | hg import --bypass -
`----
Perhaps there were some issues with backslashes or other strange stuff,
that echo interpreted differently and caused those problems, did not
want to experiment with this to cause more issues for users.


¹) I thought about adding helper scripts as an additional repository
below the vim organization, so that basically everybody can run this on
their own and does no longer require a central bridge. Also, it could be
used for some help scripts (e.g. those famous scripts Bram used to
verify runtime files updates).

Best,
Christian
--
What happened last night can happen again.

[Tony Mechelynck]

On Mon, Aug 28, 2023 at 7:05 PM Christian Brabandt <cbl...@256bit.org> wrote:
[…]

> I use git, because all the information can easily be found in the
> internet and it is still very actively developed and a lot of questions
> on how to use it have already been asked :).
>
> For mercurial I have to refresh my memories and the information on
> StackOverflow and similar seem slightly outdated. And I just do not
> remember how to use it anymore :/
>
> But maybe it is just me...

Who knows ? For Mercurial I have preset command-lines for the commands
I use most, which are (for use with bash):
• hg in || echo "exit status" $? ; date
• hg --pager=yes --color=yes in || echo "exit status" $? ; date
• hg fetch --switch-parent || echo "exit status" $? ; date
• hg log -G -l 20
(or some other number: number of changesets to display, starting
from most recent)
When the fetch fails at the merge phase, it may be for various reasons
so I check the stdout for a clue and generally I find it. Then I may
correct the problem and/or make the merge in several steps, each time
followed by
• hg commit -m "manual merge"
or some other commit message
And when there is something I have forgotten, the online help is
almost as good as Vim's: for instance:
• tell me how to use the merge command
--- hg help merge
• tell me which extensions there are, and which one are installed
--- hg help extensions
etc.

>
> Thanks,
> Christian
> --
> Before you ask more questions, think about whether you really want to
> know the answers.
> -- Gene Wolfe, "The Claw of the Conciliator"

Best regards,
Tony.

[Tony Mechelynck]

On Mon, Aug 28, 2023 at 9:11 PM Christian Brabandt <c...@256bit.org> wrote:
>
>
> On Mo, 28 Aug 2023, Tony Mechelynck wrote:
>
> > Christian, do you have any recommendations for someone who would want
> > to continue porting the changes from git to Mercurial if you ever
> > decide to close your own Mercurial mirror, or is it not worth the
> > trouble unless this new Mercurial mirror is made public (for instance
> > by maintaining a git mirror, exporting each patch as a set of diffs,
> > and importing that to a Mercurial clone) ? (I used to have a user site
> > but my ISP has closed it for no other reason than "if you want to
> > continue having a user site after DD/MM/YYYY, get into contact with us
> > before that date and an engineer of ours will build it for you". — I
> > was perfectly happy with building it slowly but surely by FTP and I
> > prefer to mind my own business, thank you.)
>
> For a recommendation you mean what is required to set this up manually?

Yes, that's what I meant, as well as anything you might have about
warning me (or anyone) about any pitfalls you might have encountered
in the past and how to avoid them.

>
> It's currently a self-written shell script (attached)¹, that pulls the
> git mirror every 15 minutes and pushes each commit as new change to the
> mercurial repository. It used to work flawlessly (until I recently added
> pushing out mails). I reverted that part for now, let's see how well
> this works in the future. If it keeps running as good as it was in the
> past and doesn't cause any more issues, then it will just keep being
> updated.

Well, currently I run "hg in" approximately once an hour when I'm at
the computer, or not at all when I'm not; and when there is something
new, I update my clone then I compile, as a sanity test, five
different versions of Vim (they used to be huge, big, normal, small
and tiny; now that Bram has retired two of these they are huge with
GTK3 and as many features as I can, huge with GTK3 without interpreted
languages, normal with Motif and +sodium, tiny with Motif and tiny
with no GUI Sizes between 4.2 and 1.5 GB).

Thanks a lot for that script, I saved it where it won't get lost. I
think that I could understand it better with just a little study but
that it isn't really out of my mental reach.

A few days ago there were multiple heads in the "default" branch, as I
told you I think I found out how to make my clone easily usable and (I
think) compatible with your @256bit.org repo, in any case later
updates have come in with no problems. I ran "hg diff" between the
remote and the local and the only differences it found are the ones I
intentionally added in src/feature.h (add +xterm_save for which there
is no configure argument AFAIK) and in .hgignore (add runtime/doc/tags
at the very bottom, which means I have to either remove that file by
hand if there comes a change to it, or run manually "hg merge"
followed by "hg commit" if I forget).

>
> There is currently the following line commented out:
> ,----
> | # echo "$patch" | hg import --bypass -
> `----
> Perhaps there were some issues with backslashes or other strange stuff,
> that echo interpreted differently and caused those problems, did not
> want to experiment with this to cause more issues for users.
>
>
> ¹) I thought about adding helper scripts as an additional repository
> below the vim organization, so that basically everybody can run this on
> their own and does no longer require a central bridge. Also, it could be
> used for some help scripts (e.g. those famous scripts Bram used to
> verify runtime files updates).

It would be an idea, but then they would have to be documented, at
least with a lot of comments in the text (more than you would need
yourself) and maybe it would be too much toil for their use.
>
> Best,
> Christian

Best regards,
Tony.

> --
> What happened last night can happen again.

Yeah, that reminds me of the warning displayed in France below the
double St-Andrews cross at level crossings with double-track railway
lines:
"Un train peut en cacher un autre"
(i.e. One train can hide another one)

[Ernie Rael]

I've heard this is pretty basic, and local repositories built with it
can't interact with normal mercurial repositories. Also that it doesn't
handle git repos that have octopus merges/parentage (not sure what that
is). But it seems like it might be satisfactory for usage with the vim
repo for getting the latest.

> If that hg-git extension you mention is so good, why haven't the
> Mercurial maintainers adopted it ?

I'm not sure what you mean. Do you mean ship it with mercurial? I'm not
sure of the relationship is among the people that work on mercurial
components. I know mercurial is used by some large companies that fund a
lot of the work. I can't answer your question, for all I know the answer
is "they do".

I can say I've been using it with github for years, with several
projects (I will never learn that devil spawned git) one of them is one
of the largest project on github; I do PRs and all the regular
development stuff.

That's an interesting question for the mercurial mailing list.

-ernie

> I daresay I have cold feet about
> it.

I admit to enjoying the bleeding edge; after all, I have vim9project
that uses classes and should be ready to go with vim9.1.

[Christian Brabandt]

On Mo, 28 Aug 2023, Tony Mechelynck wrote:

> Thanks a lot for that script, I saved it where it won't get lost. I
> think that I could understand it better with just a little study but
> that it isn't really out of my mental reach.

There is one more important thing to remember. This script uses a
working tree, that is basically checked in at git and hg at the same
time. So you need to tell git to ignore the `.hg` folder and mercurial
to ignore the `.git` folder. For git, you can configure this in
.git/info/exclude for hg I think I have it configured using .hg/hgrc
with a custom ignore file ~/.hgignore, which contains the various .git
dirs and files

Thanks,
Christian
--
briefcase, n:
A trial where the jury gets together and forms a lynching party.

[Ernie Rael]

On 23/08/28 11:55 AM, Tony Mechelynck wrote:

If you ever feel like taking a chance, you could do this in parallel, you can do

1. Install hg-git (https://pypi.org/project/hg-git/ is a good starting place)
2. hg clone git+https://github.com/vim/vim.git [optional destination name]

Do "hg in", "hg pull", ..., whatever as usual.

-ernie