unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: rpluim@gmail.com, 36644@debbugs.gnu.org, juri@linkov.net
Subject: bug#36644: Git log search
Date: Thu, 25 Jul 2019 16:08:37 +0300	[thread overview]
Message-ID: <83h87antwq.fsf@gnu.org> (raw)
In-Reply-To: <3126d32c-fbe5-771e-c89f-d3e898e811c8@yandex.ru> (message from Dmitry Gutov on Thu, 25 Jul 2019 15:36:54 +0300)

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

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

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

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

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

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

> > So I think we should treat this as we do in "M-x grep": leave the
> > semantics of PATTERN backend-dependent, and rely on the user to quote
> > some characters in it as needed.  Admittedly, 'grep' is lower-level
> > than 'vc-log-search', but at least we have a precedent.
> 
> The difference is, 'M-x grep' doesn't use different backends.

It actually leaves that to the user: you can invoke any program you
want.  E.g., I invoke 'fgrep' this way very frequently.





  reply	other threads:[~2019-07-25 13:08 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-13 22:27 bug#36644: Git log search Juri Linkov
2019-07-15 15:05 ` Dmitry Gutov
2019-07-15 22:27   ` Juri Linkov
2019-07-16 14:25     ` Dmitry Gutov
2019-07-16 14:44       ` Andreas Schwab
2019-07-16 15:08       ` Robert Pluim
2019-07-16 20:20         ` Juri Linkov
2019-07-16 22:31           ` Noam Postavsky
2019-07-18 22:35             ` Juri Linkov
2019-07-24 14:57             ` Dmitry Gutov
2019-07-16 20:15       ` Juri Linkov
2019-07-18 15:01         ` Dmitry Gutov
2019-07-18 15:12           ` Robert Pluim
2019-07-18 18:02             ` Dmitry Gutov
2019-07-18 18:11               ` Robert Pluim
2019-07-18 22:32               ` Juri Linkov
2019-07-24 15:10                 ` Dmitry Gutov
2019-07-24 15:46                   ` Robert Pluim
2019-07-24 15:53                     ` Dmitry Gutov
2019-07-24 16:13                       ` Eli Zaretskii
2019-07-25 12:36                         ` Dmitry Gutov
2019-07-25 13:08                           ` Eli Zaretskii [this message]
2019-07-25 13:20                             ` Dmitry Gutov
2019-07-25 13:37                             ` Robert Pluim
2019-07-25 19:00                             ` Juri Linkov
2019-07-25 18:55                           ` Juri Linkov
2019-07-25 21:26                             ` Dmitry Gutov
2019-07-25 21:38                               ` Juri Linkov
2019-07-24 16:13                       ` Robert Pluim
2019-07-24 17:04                         ` Eli Zaretskii
2019-07-24 23:22                           ` Juri Linkov
2019-07-25 12:44                             ` Dmitry Gutov
2019-07-25 18:50                               ` Juri Linkov
2019-07-25 19:19                                 ` Dmitry Gutov
2019-07-29 22:38                             ` Juri Linkov

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83h87antwq.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=36644@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=juri@linkov.net \
    --cc=rpluim@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).