unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: 36644@debbugs.gnu.org
Subject: bug#36644: Git log search
Date: Thu, 18 Jul 2019 18:01:12 +0300	[thread overview]
Message-ID: <e1cdbbde-0ad3-98b2-4d83-6119e2234a65@yandex.ru> (raw)
In-Reply-To: <87tvbliw37.fsf@mail.linkov.net>

On 16.07.2019 23:15, Juri Linkov wrote:

> Should this still be used when the need is to pass regexps to the backend
> search command verbatim?

What do you mean, "the need"? If it's a verbatim string, we should 
escape characters that have special meaning in regexps (or do like 
Andreas suggested and pass --fixed-string to 'git log'). If it's a 
regexp, we should document it as such.

>>>> Git supports regexps, but maybe we should look at what other backends
>>>> can support as well.
>>>
>>> It seems the most compatible type is string.
>>
>> OK, if that is your conclusion.
> 
> I'm still not sure.  Regexps are more useful.

That is true. If Hg or Bzr support regexp search as well, we might want 
to choose it to be a regexp. And kind of give up on the rest 
(unsupported, etc).

>>>> I wonder if the format of the output should be specified as well.
>>>> E.g. by saying that it's the same as for print-log, long version.
>>>
>>> Fixed by saying it's long version.
>>>
>>> Should it support short format as well?
>>
>> I don't know. How would it be used?
> 
> Short format displays one line per entry and allows expanding
> after pressing RET. 

That would be a different command, or...? Anyway, the idea sounds nice.

> However, when allowed to use regexp patterns, I don't know how to
> highlight matches in git-log output buffer using Emacs regexps
> when pattern uses e.g. Perl-compatible regexp allowed in git-log.

Maybe we shouldn't allow Perl extensions. Or, IDK, give up on 
highlighting in that particular case.

>>> Should it have a key binding?
>>>
>>> For example, `vc-log-incoming' is bound to `C-x v I',
>>> `vc-log-outgoing' is bound to key `C-x v O', so logically
>>> `vc-log-search' would be bound to `C-x v s', but unfortunately
>>> it's already taken by `vc-create-tag'.
>>
>> 'C-x v S', then?
> 
> This is good mnemonic keybinding.  The only doubt when adding a new
> keybinding is to think if it could be more useful as a prefix key.
> Maybe in this case upper-case shifted 'S' is not good as a prefix key.
> Otherwise such prefix key could accommodate other vc search related
> commands like grep vc files, etc.

FWIW, I prefer commands to have shorter bindings, when possible. Using 
prefix keys too much tends to conflict with that.





  reply	other threads:[~2019-07-18 15:01 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 [this message]
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
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=e1cdbbde-0ad3-98b2-4d83-6119e2234a65@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=36644@debbugs.gnu.org \
    --cc=juri@linkov.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.
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).