bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51316: 29.0.50; Should we match the final ".git" in bug-reference au


From: Tassilo Horn
Subject: bug#51316: 29.0.50; Should we match the final ".git" in bug-reference autosetup?
Date: Fri, 22 Oct 2021 22:45:23 +0200
User-agent: mu4e 1.7.3; emacs 29.0.50

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> If function 'bug-reference--build-forge-setup-entry':
>>
>>> `(,(concat "[/@]" host-domain "[/:]\\([.A-Za-z0-9_/-]+\\)\\.git")
>> This should be "(regexp-quote host-domain)".
>
> This is now fixed in Emacs 28.

Thanks.

>> Also, it would be nice if the final "\\.git" wasn't mandatory.  I
>> often git clone a website url as displayed in a web browser
>> ("https://gitlab.com/rstocker/emacs-bluetooth"; for example) without
>> appending ".git".  Git has no problem fetching from such an url
>> (tested with github, gitlab and gitea), but bug-reference autosetup
>> machinery fails to detect it as a valid url.

Oh, right, that seems to work just fine.  I only checked the URLs you
get with the "copy to clipboard" buttons the forges provide.

>> Unfortunately, we can't simply change the final .git into
>> "\\(?:\\.git\\)?" because regexp greediness would then swallow it
>> into the first match group.
>
> This would work, though:
>
> "[/:]\\([.A-Za-z0-9_/-]+?\\)\\(?:\\.git\\)?\\'"

Indeed.

> But requires that the string doesn't have anything after the .git,
> whereas it's currently more sloppy.  I'm not sure whether that's by
> intent or not.  (So I'm adding Tassilo to the CCs.)

No, in my experience there cannot be anything after ".git".  At least
it's the last part of the filename and I doubt you can have query
parameters like https://forge.org/user/project.git?foo=bar in a git url.

> This is a feature request, in any case, so it should go to Emacs 29, I
> think.

I would kindly ask to reconsider.  This complete bug-reference
auto-setup thingy is new in emacs 28, the forge setup code is even just
a month old, and using your improved regexp doesn't seem risky at all
and might provide a much better user experience to possibly a lot of
users, my vote would be to fix this in emacs-28.

Bye,
Tassilo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]