From: Chris Packham <judge.packham@gmail.com>
To: Jeff Epler <jepler@unpythonic.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH] Configurable hyperlinking in gitk
Date: Sat, 17 Sep 2011 22:01:11 +1200 [thread overview]
Message-ID: <4E746FE7.4060608@gmail.com> (raw)
In-Reply-To: <4E7467B7.1090201@gmail.com>
On 17/09/11 21:26, Chris Packham wrote:
> Hi,
>
> On 17/09/11 14:29, Jeff Epler wrote:
>> Some time ago I hardcoded this into gitk for $DAY_JOB and find it very
>> useful. I made it configurable in the hopes that it might be adopted
>> upstream. (unfortunately, the configurable version is radically
>> different from the original hard-coded version, so I can't say this
>> has had much testing yet)
>
> This is definitely something folks at my $dayjob would be interested in.
> We've already done some customisation of gitweb to do something similar.
> I'm not actually sure what the changes where or how configurable they
> are. I'll see if I can dig them out on Monday someone else might want to
> polish them into something suitable (I might do it myself if I get some
> tuits).
>
>> The definition of the allowed regular expression in the docs
>> probably needs some refinement. Basically, they have to also be REs
>> that can be concatenated with the "|" character, which is not true
>> of REs that begin with the *** flavor selector (which I had not
>> heard of before rereading `man re_syntax` just now) or (?xyz)
>> embedded options. Or maybe there's an efficient alternate approach
>> to scanning for the next non-overlapping match among several
>> patterns that doesn't involve concatenating the patterns.
>>
>> I'm not sure about the "one line" restriction; at first I thought
>> that everything was fed to 'appendwithlinks' in arbitrary chunks,
>> but not I see that they are mostly logical chunks (and probably only
>> the comment, not the headers or commit descriptors, will have
>> anything to linkify). The problem again seems to be how to succinctly
>> describe what is permitted.
>
> For my use case the one line restriction is fine. We tend to put the bug
> number in the headline anyway.
>
> Sometimes when a commit fixes multiple bugs we put all the bug numbers
> in separated by commas. I don't know Tcl well enough to tell if your
> code supports that or not.
>
>> There are probably better names for the configuration options, too.
>
> It'd be nice if the config variables weren't gitk specific. .re and .sub
> could be applied to gitweb and maybe other git viewers outside of
> gig.git might decide to use them. My bikeshedding suggestion would be to
> just drop the gitk prefix and have linkify.re and linkify.sub.
That should be linkify.<name>.re and linkify.<name>.sub
>> Suggestions? Problems? Successes?
>
> Re-compiling now. I won't be able to actually test it properly until I'm
> back in the office but I can at least check that the links are generated.
Slight complication. The URL of our bug tracker has an ampersand '&' in
it. Tcl's substitution does what one might expect and puts the matched
text where the '&' is. I've tried using url friendly %26 but something
eats the %. I've also tried backslashes to no avail.
To answer my own question since I started writing this email I've found
that using %% works (only the first one gets eaten). Not sure if that's
expected behaviour or not (printf escaping maybe?).
Also since I've been playing around I've tried a commit with multiple
bug numbers on one line and that works as expected.
Thanks
Chris
next prev parent reply other threads:[~2011-09-17 10:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-17 2:29 [RFC/PATCH] Configurable hyperlinking in gitk Jeff Epler
2011-09-17 9:26 ` Chris Packham
2011-09-17 10:01 ` Chris Packham [this message]
2011-09-17 13:45 ` Jeff Epler
2011-09-17 23:33 ` Chris Packham
2011-09-18 0:30 ` git web--browse error handling URL with & in it (Was Re: [RFC/PATCH] Configurable hyperlinking in gitk) Chris Packham
2011-09-18 0:32 ` Chris Packham
2011-09-18 3:29 ` Jeff King
2011-09-18 10:20 ` [PATCH] git-web--browse: invoke kfmclient directly Chris Packham
2011-09-18 18:38 ` Jeff King
2011-09-19 9:26 ` [RFC/PATCHv2] git-web--browse: avoid the use of eval Chris Packham
2011-09-19 18:34 ` Jeff King
2011-09-20 9:04 ` Chris Packham
2011-09-20 18:49 ` Jeff King
2011-09-20 19:35 ` Junio C Hamano
2011-09-19 17:57 ` [PATCH] git-web--browse: invoke kfmclient directly Junio C Hamano
2011-09-19 18:20 ` Jeff King
2011-09-19 20:42 ` Junio C Hamano
2011-09-19 20:44 ` Jeff King
2011-09-19 21:22 ` Junio C Hamano
2011-09-19 21:46 ` Andreas Schwab
2011-09-19 22:23 ` Jeff King
2011-09-19 22:28 ` Junio C Hamano
2011-09-19 20:44 ` Andreas Schwab
2011-09-19 21:32 ` Jakub Narebski
2011-09-18 14:46 ` git web--browse error handling URL with & in it (Was Re: [RFC/PATCH] Configurable hyperlinking in gitk) Christian Couder
2011-09-19 15:05 ` [RFC/PATCH] Configurable hyperlinking in gitk Marc Branchaud
2011-09-18 18:50 ` Jakub Narebski
2011-09-22 1:31 ` Jeff Epler
2011-09-22 2:15 ` [PATCH v3] " Jeff Epler
2011-10-11 18:37 ` [RESEND PATCH " Jeff Epler
2011-10-11 22:13 ` Junio C Hamano
2011-10-12 9:07 ` Chris Packham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E746FE7.4060608@gmail.com \
--to=judge.packham@gmail.com \
--cc=git@vger.kernel.org \
--cc=jepler@unpythonic.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).