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

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

bug#36644: Git log search


From: Robert Pluim
Subject: bug#36644: Git log search
Date: Thu, 25 Jul 2019 15:37:05 +0200

>>>>> On Thu, 25 Jul 2019 16:08:37 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> Cc: rpluim@gmail.com, 36644@debbugs.gnu.org, juri@linkov.net
    >> From: Dmitry Gutov <dgutov@yandex.ru>
    >> Date: Thu, 25 Jul 2019 15:36:54 +0300
    >> 
    >> > I also see your point: it would be nice to be able to document the
    >> > semantics of PATTERN in a backend-independent way.  But I think this
    >> > is next to impossible in this case, both because of significant
    >> > differences in the backend capabilities (e.g., bzr doesn't have the
    >> > equivalent of Git's --fixed-strings, AFAICT), and because some backend
    >> > allow great flexibility in interpreting PATTERN, under control of
    >> > optional switches passed to the backend.
    >> 
    >> The other option is to standardize on basic or extended regexp, and 
    >> simply give up for backends that can't support that.

    Eli> We could simply say "regular expression" and leave the details
    Eli> unspecified.  But I think Juri said that fixed strings was the lowest
    Eli> common denominator, which is why I proposed a slightly more vague doc
    Eli> string.  Juri, which backends don't support regular expressions?  And
    Eli> Robert, why did you insist on saying STRING?

I donʼt think I did, we can say PATTERN. The thing Iʼm insistent about
is not doing anything to that argument, since its meaning will be
understood only by the backend.

    >> Git supports all kinds of regexps. 'hg grep' uses Perl-compatible ones 
    >> (meaning extended regexps are supported, at least). I'm not sure which 
    >> regular expressions are expected by 'bzr log -match', but if it doesn't 
    >> support the extended ones, *shrug*.

    Eli> I didn't dig deep enough, but since bzr is written in Python, I'd bet
    Eli> it supports whatever Python supports natively.

    >> Anyway, if people disagree, I'm not going to press the issue.

    Eli> If all the backends either support regular expressions or don't
    Eli> support this feature at all, then we had better mentioned regular
    Eli> expressions in the doc string.

Yes, although the regular expression types they support may be
different.

Robert





reply via email to

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