Re: [PATCH] userdiff: add built-in pattern for CSS

Am 03.06.2016 um 00:48 schrieb William Duclot: Logic behind the "pattern" regex is: The name of the macro parameter is "pattern", but the actual meaning is "function name" regex. diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index e3b1de8..81f60ad 100644

Re: What's cooking in git.git (Jun 2016, #01; Thu, 2)

On 06/03/2016 01:13 AM, Mike Hommey wrote: On Thu, Jun 02, 2016 at 03:52:41PM -0700, Junio C Hamano wrote: * mh/connect (2016-06-01) 9 commits - connect: move ssh command line preparation to a separate function - connect: actively reject git:// urls with a user part - connect: change the

Re: [PATCH] t1308: do not get fooled by symbolic links to the source tree

On Thu, Jun 02, 2016 at 04:23:00PM -0700, Stefan Beller wrote: > > To prevent this in the future, I switched my default --root= to point to > > a symlink. I wonder if we could do something in the test suite, though, > > as we did long ago by introducing "trash directory" with a space to > > catch

Re: [PATCHv3] pathspec: allow escaped query values

On Thu, Jun 2, 2016 at 4:23 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> However if we add a value restriction here, we need to be as strict in the >> .gitattributes parsing as well and put a warning there (similar to >> invalid_attr_name_message)

Re: [PATCHv3] pathspec: allow escaped query values

Stefan Beller writes: > However if we add a value restriction here, we need to be as strict in the > .gitattributes parsing as well and put a warning there (similar to > invalid_attr_name_message) I would think. Remember, the attribute system is used for many purposes other

Re: [PATCH] t1308: do not get fooled by symbolic links to the source tree

On Thu, Jun 2, 2016 at 4:16 PM, Jeff King wrote: > On Thu, Jun 02, 2016 at 03:15:39PM -0700, Junio C Hamano wrote: > >> When your $PWD does not match $(/bin/pwd), e.g. you have your copy >> of the git source tree in one place, point it with a symbolic link, >> and then "cd" to that

Re: [PATCH] t1308: do not get fooled by symbolic links to the source tree

On Thu, Jun 02, 2016 at 03:15:39PM -0700, Junio C Hamano wrote: > When your $PWD does not match $(/bin/pwd), e.g. you have your copy > of the git source tree in one place, point it with a symbolic link, > and then "cd" to that symbolic link before running 'make test', one > of the tests in t1308

[PATCHv3] pathspec: allow escaped query values

In our own .gitattributes file we have attributes such as: *.[ch] whitespace=indent,trail,space When querying for attributes we want to be able to ask for the exact value, i.e. git ls-files :(attr:whitespace=indent,trail,space) should work, but the commas are used in the attr magic to

Re: What's cooking in git.git (Jun 2016, #01; Thu, 2)

On Thu, Jun 02, 2016 at 03:52:41PM -0700, Junio C Hamano wrote: > * mh/connect (2016-06-01) 9 commits > - connect: move ssh command line preparation to a separate function > - connect: actively reject git:// urls with a user part > - connect: change the --diag-url output to separate user and

[PATCH 2/2] rev-list: disable bitmaps when "-n" is used with listing objects

You can ask rev-list to use bitmaps to speed up an --objects traversal, which should generally give you your answers much faster. Likewise, you can ask rev-list to limit such a traversal with `-n`, in which case we'll show only a limited set of commits (and only the tree and commit objects

[PATCH 1/2] rev-list: "adjust" results of "--count --use-bitmap-index -n"

If you ask rev-list for: git rev-list --count --use-bitmap-index HEAD we optimize out the actual traversal and just give you the number of bits set in the commit bitmap. This is faster, which is good. But if you ask to limit the size of the traversal, like: git rev-list --count

[PATCH 0/2] corner cases with "rev-list --use-bitmap-index -n"

This series fixes two corner-cases I found when using "-n" along with bitmaps. The results do make _some_ sense if you interpret them correctly, but are sufficiently confusing that I think it's worth dealing with. See the commit messages for the gory details. The good news is that in the first

Re: [PATCH] userdiff: add built-in pattern for CSS

William Duclot writes: > diff --git a/userdiff.c b/userdiff.c > index 6bf2505..00fc3bf 100644 > --- a/userdiff.c > +++ b/userdiff.c > @@ -148,6 +148,18 @@ PATTERNS("csharp", >"[a-zA-Z_][a-zA-Z0-9_]*" >

Re: [PATCHv2] pathspec: allow escaped query values

Stefan Beller writes: > Thinking about efficiency, I have the believe that memmove can be faster > than a `*src=*dst` thing we do ourselves as it may have access to specialized > assembly instructions to move larger chunks of memory or such. > So I think ideally we would do

Re: [PATCHv2] pathspec: allow escaped query values

On Thu, Jun 2, 2016 at 2:54 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> In our own .gitattributes file we have attributes such as: >> >> *.[ch] whitespace=indent,trail,space >> >> When querying for attributes we want to be able to ask for the

What's cooking in git.git (Jun 2016, #01; Thu, 2)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. 2.9-rc2 is scheduled for early

[PATCH] userdiff: add built-in pattern for CSS

CSS is widely used, motivating it being included as a built-in pattern. It must be noted that the word_regex for CSS (i.e. the regex defining what is a word in the language) does not consider '.' and '#' characters (in CSS selectors) to be part of the word. This behavior is documented by the test

[PATCH] t1308: do not get fooled by symbolic links to the source tree

When your $PWD does not match $(/bin/pwd), e.g. you have your copy of the git source tree in one place, point it with a symbolic link, and then "cd" to that symbolic link before running 'make test', one of the tests in t1308 expects that the per-user configuration was reported to have been read

Re: [PATCHv2] pathspec: allow escaped query values

On Thu, Jun 2, 2016 at 2:54 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> In our own .gitattributes file we have attributes such as: >> >> *.[ch] whitespace=indent,trail,space >> >> When querying for attributes we want to be able to ask for the

Re: [PATCH] pathspec: rename free_pathspec() to clear_pathspec()

Jeff King writes: > I think diff_filespec_clear() would not be quite right. It is freeing > only the allocated _data_, but leaving the other portions intact. You are (as usual) more right than I am ;-) Yes, the free_data() is designed to retain enough information about the

Re: Mark remote `gc --auto` error messages

Jeff King writes: > So the greater question is not "should this output be marked" but > "should auto-gc data go over the sideband so that all clients see it > (and any server-side stderr does not)". And I think the answer is > probably yes. And that fixes the "remote: " thing as a

Re: [PATCHv2] pathspec: allow escaped query values

Stefan Beller writes: > In our own .gitattributes file we have attributes such as: > > *.[ch] whitespace=indent,trail,space > > When querying for attributes we want to be able to ask for the exact > value, i.e. > > git ls-files :(attr:whitespace=indent,trail,space) >

Re: Mark remote `gc --auto` error messages

On Thu, Jun 02, 2016 at 01:14:02PM -0700, Junio C Hamano wrote: > > What exactly are you referring to (you only quoted the introduction)? > > Do you think we should fix the git-gc issue but keep the general > > behavior of printing messages unaltered? Do you think it would be > > worthwhile to

Re: Mark remote `gc --auto` error messages

On Thu, Jun 02, 2016 at 01:14:02PM -0700, Junio C Hamano wrote: > On Thu, Jun 2, 2016 at 1:06 PM, Lukas Fleischer wrote: > > On Thu, 02 Jun 2016 at 21:33:33, Junio C Hamano wrote: > >> Lukas Fleischer writes: > >> > >> > When running `git push`, it might

Re: What's cooking in git.git (May 2016, #09; Tue, 31) t1308 broken

On Thu, Jun 02, 2016 at 02:31:50PM -0700, Junio C Hamano wrote: > Perhaps like this, taking hint from the log message of 6eafa6d0 > (submodules: don't stumble over symbolic links when cloning > recursively, 2012-07-12)? > > t/t1308-config-set.sh | 2 +- > 1 file changed, 1 insertion(+), 1

Re: What's cooking in git.git (May 2016, #09; Tue, 31) t1308 broken

Junio C Hamano writes: > Torsten Bögershausen writes: > >> It seams as ./t1308-config-set.sh is broken, >> when the the directory is a soft link: >> >> -name=/home/tb/NoBackup/projects/git/git.pu/t/trash >> directory.t1308-config-set/.gitconfig >>

[PATCHv2] pathspec: allow escaped query values

In our own .gitattributes file we have attributes such as: *.[ch] whitespace=indent,trail,space When querying for attributes we want to be able to ask for the exact value, i.e. git ls-files :(attr:whitespace=indent,trail,space) should work, but the commas are used in the attr magic to

Re: [PATCH] pathspec: rename free_pathspec() to clear_pathspec()

On Thu, Jun 02, 2016 at 02:18:47PM -0700, Junio C Hamano wrote: > The function takes a pointer to a pathspec structure, and releases > the resources held by it, but does not free() the structure itself. > Such a function should be called "clear", not "free". Hmm, makes sense, though... > *

Re: What's cooking in git.git (May 2016, #09; Tue, 31) t1308 broken

Torsten Bögershausen writes: > It seams as ./t1308-config-set.sh is broken, > when the the directory is a soft link: > > -name=/home/tb/NoBackup/projects/git/git.pu/t/trash > directory.t1308-config-set/.gitconfig > +name=/home/tb/projects/git/git.pu/t/trash >

[PATCH] pathspec: rename free_pathspec() to clear_pathspec()

The function takes a pointer to a pathspec structure, and releases the resources held by it, but does not free() the structure itself. Such a function should be called "clear", not "free". Signed-off-by: Junio C Hamano --- * This is just something I noticed. Among the hits

Re: [PATCH/RFC 0/4] Add option to enable filters in git-svn

Matteo Bertini wrote: > Il 2016-05-31 20:12 Eric Wong ha scritto: > >Matteo Bertini wrote: > >>Sorry to all, but I missed a Checksum mismatch error, I'll have a > >>look and submit an update. > > I've had a look, the problem is a missing smudge

Re: Mark remote `gc --auto` error messages

On Thu, Jun 2, 2016 at 1:06 PM, Lukas Fleischer wrote: > On Thu, 02 Jun 2016 at 21:33:33, Junio C Hamano wrote: >> Lukas Fleischer writes: >> >> > When running `git push`, it might occur that error messages are >> > transferred from the server to the

Re: Mark remote `gc --auto` error messages

On Thu, 02 Jun 2016 at 21:33:33, Junio C Hamano wrote: > Lukas Fleischer writes: > > > When running `git push`, it might occur that error messages are > > transferred from the server to the client. While most messages (those > > explicitly sent on sideband 2) are prefixed

Re: [WIP-PATCH 1/2] send-email: create email parser subroutine

Samuel GROOT wrote: > On 05/29/2016 01:33 AM, Eric Wong wrote: > >Matthieu Moy wrote: > >>Samuel GROOT writes: > >> > >>>Parsing and processing in send-email is done in the same loop. > >>> > >>>To make

Re: [RFC/PATCH] pathspec: allow escaped query values

On 02/06/16 20:46, Junio C Hamano wrote: > Ramsay Jones writes: > >> I think Junio wants to go with just " quoting (see other thread). > > No. I meant just \ quoting. Yes, sorry, I only just read your last email on the other thread. ATB, Ramsay Jones -- To

Re: [RFC/PATCH] pathspec: allow escaped query values

On 02/06/16 20:29, Junio C Hamano wrote: > Junio C Hamano writes: > >> On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones >> wrote: That would be workable, I would think. Before attr:VAR=VAL extention, supported pathspec were only

Re: [RFC/PATCH] pathspec: allow escaped query values

Ramsay Jones writes: > I think Junio wants to go with just " quoting (see other thread). No. I meant just \ quoting. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [RFC/PATCH] pathspec: allow escaped query values

On 02/06/16 20:04, Stefan Beller wrote: > On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones > wrote: >> >> >> On 02/06/16 17:10, Junio C Hamano wrote: >>> Ramsay Jones writes: >>> So, at risk of annoying you, let me continue in my

Re: Mark remote `gc --auto` error messages

Lukas Fleischer writes: > When running `git push`, it might occur that error messages are > transferred from the server to the client. While most messages (those > explicitly sent on sideband 2) are prefixed with "remote:", it seems > that error messages printed during the

Re: [RFC/PATCH] pathspec: allow escaped query values

Junio C Hamano writes: > On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones > wrote: >>> >>> That would be workable, I would think. Before attr:VAR=VAL >>> extention, supported pathspec were only single lowercase-ascii >>> alphabet tokens, so nobody

Mark remote `gc --auto` error messages

When running `git push`, it might occur that error messages are transferred from the server to the client. While most messages (those explicitly sent on sideband 2) are prefixed with "remote:", it seems that error messages printed during the automatic householding performed by git-gc(1) are

Re: [RFC/PATCH] pathspec: allow escaped query values

On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones wrote: > > > On 02/06/16 17:10, Junio C Hamano wrote: >> Ramsay Jones writes: >> >>> So, at risk of annoying you, let me continue in my ignorance a little >>> longer and ask: even if you have

Re: [RFC/PATCH] pathspec: allow escaped query values

On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones wrote: >> >> That would be workable, I would think. Before attr:VAR=VAL >> extention, supported pathspec were only single lowercase-ascii >> alphabet tokens, so nobody would have used " as a part of magic. So >> quting

Re: [RFC/PATCH] pathspec: allow escaped query values

On 02/06/16 17:10, Junio C Hamano wrote: > Ramsay Jones writes: > >> So, at risk of annoying you, let me continue in my ignorance a little >> longer and ask: even if you have to protect all of this 'magic' from >> the shell with '/" quoting, could you not use

Re: [PATCH v3 2/2] completion: add git status

Thomas Braun writes: > + untracked_state="$(__git_find_on_cmdline "--untracked-files=no\ > + --untracked-files=normal --untracked-files=all")" Just wondering but does this help my use of the command like $ git status -uno or do I now

Re: [PATCH 0/4] Fix prune/gc problem with multiple worktrees

Michael Haggerty writes: > Fixing reachability via the index and detached HEADs feels relatively > important. > ... I agree with the order of importance above. But "relatively" is a very good keyword. Just like bisection refs, what is in the index and the commit detached

Re: [PATCH v3 28/39] i18n: config: unfold error messages marked for translation

Vasco Almeida writes: > Às 17:43 de 01-06-2016, Junio C Hamano escreveu: >> Vasco Almeida writes: >> >>> Introduced in 473166b ("config: add 'origin_type' to config_source >>> struct", 2016-02-19), Git can inform the user about the origin of a >>>

Re: Segfault in the attr stack

On Thu, Jun 2, 2016 at 8:59 AM, Junio C Hamano wrote: > Junio C Hamano writes: > Gaah, of course. This is coming from the cache preload codepath, where multiple threads try to run ce_path_match(). It used to be OK because pathspec

Re: [PATCH v3 2/6] worktree.c: find_worktree() learns to identify worktrees by basename

Duy Nguyen writes: > On Thu, Jun 2, 2016 at 1:44 AM, Junio C Hamano wrote: >>> We would >>> need to convert or match both '/' and '\' in "to/foo" case because of >>> Windows, so it's not much easier than basename(). >> >> I never said "easier to implement".

Re: [PATCH 09/13] refs: introduce an iterator interface

On 06/02/2016 12:08 PM, Duy Nguyen wrote: > On Mon, May 30, 2016 at 2:55 PM, Michael Haggerty > wrote: >> Currently, the API for iterating over references is via a family of >> for_each_ref()-type functions that invoke a callback function for each >> selected reference. All

Re: [PATCH 1/2] fetch: better alignment in ref summary

Duy Nguyen writes: > On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano wrote: >> That is, I wonder if the above can become something like: >> >>> From github.com:pclouds/git >>> * [new branch] { -> pclouds/}2nd-index >>> * [new branch] { ->

Re: [RFC/PATCH] pathspec: allow escaped query values

Ramsay Jones writes: > So, at risk of annoying you, let me continue in my ignorance a little > longer and ask: even if you have to protect all of this 'magic' from > the shell with '/" quoting, could you not use (nested) quotes to > protect the part of an ? For

Re: Segfault in the attr stack

Junio C Hamano writes: >>> Gaah, of course. >>> >>> This is coming from the cache preload codepath, where multiple threads >>> try to run ce_path_match(). >>> It used to be OK because pathspec magic never looked at attributes, >>> but now it does, and attribute system is not

Re: [PATCH] push: deny policy to prevent pushes to unwanted remotes.

> On 30 May 2016, at 06:45, Antoine Queru > wrote: > > Currently, a user wanting to prevent accidental pushes to the wrong remote > has to create a pre-push hook. > The feature offers a configuration to allow users to prevent accidental pushes > to the

Re: [RFC/PATCH] pathspec: allow escaped query values

On 02/06/16 06:46, Junio C Hamano wrote: > Ramsay Jones writes: > >> Not having given this much thought at all, but the question which comes >> to mind is: can you use some other separator for the -s rather than >> a comma? That way you don't need to quote them in

[PATCH v3 1/2] completion: factor out untracked file modes into a variable

Signed-off-by: Thomas Braun --- contrib/completion/git-completion.bash | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 3402475..addea89 100644 ---

[PATCH v3 2/2] completion: add git status

Signed-off-by: Thomas Braun --- contrib/completion/git-completion.bash | 55 ++ 1 file changed, 55 insertions(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index addea89..fa7a03a

Re: [PATCH v2 2/2] completion: add git status

Am 01.06.2016 um 14:15 schrieb SZEDER Gábor: > > Quoting Thomas Braun : > >> Signed-off-by: Thomas Braun >> --- >> contrib/completion/git-completion.bash | 29 >> + >> 1 file changed, 29

Re: [PATCH v2 1/2] completion: create variable for untracked file modes

Am 01.06.2016 um 13:59 schrieb SZEDER Gábor: > > This subject would perhaps read better: > > completion: factor out untracked file modes into a variable Yes, definitly. Will be included in reroll. > Quoting Thomas Braun : > >> Signed-off-by: Thomas Braun

Re: [PATCH v3 28/39] i18n: config: unfold error messages marked for translation

Às 17:43 de 01-06-2016, Junio C Hamano escreveu: > Vasco Almeida writes: > >> Introduced in 473166b ("config: add 'origin_type' to config_source >> struct", 2016-02-19), Git can inform the user about the origin of a >> config error, but the implementation does not allow

Re: [PATCH v3 13/39] i18n: git-sh-setup.sh: mark strings for translation

Às 20:30 de 01-06-2016, Junio C Hamano escreveu: > Junio C Hamano writes: > Would it allow you to lose the $(git --exec-path) prefix in the new > dot-source to have this patch before applying your patch? > > -- >8 -- > Subject: t2300: run git-sh-setup in an environment that

Re: [PATCH v3 24/39] i18n: bisect: enable l10n of bisect terms in messages

Às 17:38 de 01-06-2016, Junio C Hamano escreveu: > Vasco Almeida writes: > >> +enum term { BAD, GOOD, OLD, NEW }; >> +static const char *term_names[] = { >> +/* TRANSLATORS: in bisect.c source code file, the following terms are >> + used to describe a "bad commit", "good

Re: [PATCH 0/2] strbuf: improve API

On Thu, Jun 02, 2016 at 02:58:22PM +0200, Matthieu Moy wrote: > Michael Haggerty writes: > >> 1. The amount of added code complexity is small and quite >>encapsulated. > > Actually, STRBUF_OWNS_MEMORY can even be seen as a simplification if > done properly: we already

Re: What's cooking in git.git (May 2016, #09; Tue, 31) t1308 broken

It seams as ./t1308-config-set.sh is broken, when the the directory is a soft link: -name=/home/tb/NoBackup/projects/git/git.pu/t/trash directory.t1308-config-set/.gitconfig +name=/home/tb/projects/git/git.pu/t/trash directory.t1308-config-set/.gitconfig scope=global key=foo.bar not ok 28 -

Re: [PATCH 1/2] fetch: better alignment in ref summary

On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano wrote: > That is, I wonder if the above can become something like: > >> From github.com:pclouds/git >> * [new branch] { -> pclouds/}2nd-index >> * [new branch] { -> pclouds/}3nd-index >> * [new branch] { ->

Re: [PATCH 0/2] strbuf: improve API

Michael Haggerty writes: > 1. The amount of added code complexity is small and quite >encapsulated. Actually, STRBUF_OWNS_MEMORY can even be seen as a simplification if done properly: we already have the case where the strbuf does not own the memory with

Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

On 05/31/2016 04:33 PM, Matthieu Moy wrote: > Jordan DE GEA writes: > [...] >> +DESCRIPTION >> +--- >> + >> +Triangular Workflow (or Asymmetric Workflow) is a workflow which gives >> +the possibility to: >> + >> +- fetch (or pull) from a repository >> +-

Re: [PATCH 0/4] Fix prune/gc problem with multiple worktrees

On 06/02/2016 11:53 AM, Duy Nguyen wrote: > (from patch 4/4 mail) > > On Wed, Jun 1, 2016 at 10:51 PM, Michael Haggerty > wrote: >>> + path = xstrdup(worktree_git_path(wt, "logs/refs/bisect")); >>> + if (file_exists(path)) >>> + handle_one_reflog(path,

Re: [PATCH 0/2] strbuf: improve API

On 06/01/2016 11:07 PM, Jeff King wrote: > On Wed, Jun 01, 2016 at 03:42:18AM -0400, Jeff King wrote: > >> I have no idea if those ideas would work. But I wouldn't want to start >> looking into either of them without some idea of how much time we're >> actually spending on strbuf mallocs (or how

Re: [PATCH 09/13] refs: introduce an iterator interface

On Mon, May 30, 2016 at 2:55 PM, Michael Haggerty wrote: > Currently, the API for iterating over references is via a family of > for_each_ref()-type functions that invoke a callback function for each > selected reference. All of these eventually call do_for_each_ref(), >

Re: [PATCH 0/4] Fix prune/gc problem with multiple worktrees

(from patch 4/4 mail) On Wed, Jun 1, 2016 at 10:51 PM, Michael Haggerty wrote: >> + path = xstrdup(worktree_git_path(wt, "logs/refs/bisect")); >> + if (file_exists(path)) >> + handle_one_reflog(path, NULL, 0, ); >> + free(path); >> +} > >

Re: [PATCH v3 2/6] worktree.c: find_worktree() learns to identify worktrees by basename

On Thu, Jun 2, 2016 at 1:44 AM, Junio C Hamano wrote: >> We would >> need to convert or match both '/' and '\' in "to/foo" case because of >> Windows, so it's not much easier than basename(). > > I never said "easier to implement". But can this codepath get > backslashed paths

Re: [PATCH 2/4] reachable.c: mark reachable objects in index from all worktrees

On Thu, Jun 2, 2016 at 1:57 AM, David Turner wrote: >> + struct index_state istate; >> + >> + memset(, 0, sizeof(istate)); > > > Why not just struct index_state istate = {0}; ? > My first thought was.. "hmm.. C99?" but then there are 24 of them

Re: [PATCH 2/4] reachable.c: mark reachable objects in index from all worktrees

On Thu, Jun 2, 2016 at 1:13 AM, Eric Sunshine wrote: > On Wed, Jun 1, 2016 at 6:45 AM, Nguyễn Thái Ngọc Duy > wrote: >> Current mark_reachable_objects() only marks objects from index from >> _current_ worktree as reachable instead of all worktrees.

Re: [PATCH 1/3] pretty: support "mboxrd" output format

Eric Wong wrote: > Eric Sunshine wrote: > > On Tue, May 31, 2016 at 3:45 AM, Eric Wong wrote: > > > Eric Sunshine wrote: > > >> I wonder if hand-coding, rather than using a regex, could be an > > >> improvement: