From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#50344: C-x v keybinding for vc-print-branch-log Date: Thu, 7 Oct 2021 03:57:47 +0300 Message-ID: <11783eab-c11c-771d-a9d3-a7608a2f69d8@yandex.ru> References: <87mtoux1ha.fsf@mail.linkov.net> <1f39aa34-6626-3d0b-d764-2c9908787d99@yandex.ru> <87o8998wf4.fsf@mail.linkov.net> <84e4e2ef-6c8d-3645-9e1e-3129981dd45f@yandex.ru> <875yvgvohe.fsf@gnus.org> <87y28burzd.fsf@mail.linkov.net> <87o896kt5k.fsf@gnus.org> <87sfyhj3qw.fsf@mail.linkov.net> <87zgsoctoc.fsf@gnus.org> <59a05468-2309-c6e7-5a2a-51426c208966@yandex.ru> <87tuiv4hvc.fsf@gnus.org> <87fsudsngq.fsf@mail.linkov.net> <85dfa858-091b-80df-b9d1-bd1136c2b91e@yandex.ru> <878rz72wqg.fsf@mail.linkov.net> <30b7d470-26b1-7d7a-2d43-9e85059c1fc5@yandex.ru> <87fstevcfl.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40147"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: 50344@debbugs.gnu.org, Lars Ingebrigtsen , Filipp Gunbin To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 07 02:58:16 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYHjj-000AJp-Ph for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Oct 2021 02:58:15 +0200 Original-Received: from localhost ([::1]:34808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYHji-0004pH-EF for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Oct 2021 20:58:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55620) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYHjW-0004l1-9P for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 20:58:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34183) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYHjW-0007bc-1z for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 20:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mYHjV-0007QY-Tt for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 20:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Oct 2021 00:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50344 X-GNU-PR-Package: emacs Original-Received: via spool by 50344-submit@debbugs.gnu.org id=B50344.163356827828539 (code B ref 50344); Thu, 07 Oct 2021 00:58:01 +0000 Original-Received: (at 50344) by debbugs.gnu.org; 7 Oct 2021 00:57:58 +0000 Original-Received: from localhost ([127.0.0.1]:45729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYHjS-0007QF-3i for submit@debbugs.gnu.org; Wed, 06 Oct 2021 20:57:58 -0400 Original-Received: from mail-lf1-f41.google.com ([209.85.167.41]:39831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYHjO-0007Py-Vj for 50344@debbugs.gnu.org; Wed, 06 Oct 2021 20:57:56 -0400 Original-Received: by mail-lf1-f41.google.com with SMTP id n8so16912123lfk.6 for <50344@debbugs.gnu.org>; Wed, 06 Oct 2021 17:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=s27nGt8R929f4YS0c9lsOq3Wzx8pdtUi4qQE/tkmTTs=; b=RZyBel04S3OOvY9mAeMjSf/7bqOi8/gyl+4uA8qfgq8BJJxMahLacfDCewuDmSV10e d8ctAVU4x5xTCiikEsQ7Hi4DwiFFBeJLXHXTt2Afm2PFpTzwjJ8R2/u4a5GKe5dkfGNH tfeu4C6oR7V4tvulzbK3N9BvZle1/KLIhfFGR1JL28r8liFBaOoxKhpahS03x9cCsJTK nvRBqaP9TB+1WKZ7VPrksRkwF9CJU/RW9xFacwPBTSK48KL1IyoQX8o35Tgi3PpbOdjT KZ4bLpok0sdMVuZG984IksTPpQ1z84VCibek+7en7cdErv7q+C+j7Onj3CMZjMTVw98u LBoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=s27nGt8R929f4YS0c9lsOq3Wzx8pdtUi4qQE/tkmTTs=; b=ArY4zbU7GGYyCgDIxewLcaA89h25bZq+Jz/FXZR/mJNSlWCTmuI1L8Mrxdro/A1yZd A+f8g2Xl+aZDCxWqf22eqYPhOrsafQJVHSgnVL6jRSY5gk/fFhDezgdMmuQV34upD8gG Jl+FiWfIOVkS6fuuUUvCMU5apFGwOn4LzS8IxvWsRwMtyhnZH0VDJcq1vXO9/9+pH1zZ zTRcowqUIu4D7zKLaIiM6t7rOHiqMe/+oY7E05NuVoKvnmv/+tu4WuNz0jnJYD7hZ35K MJbZ8iHAe2fLd1/u0kKYpDnY0axg8sxpfnGstoI+vR23vIZ/0maW9zRVNxgezstumbDo bSQA== X-Gm-Message-State: AOAM5327Ki5oZssKoQAut2TqoDwpc6otYQhjY6pqWL86tUttq8RbHNwV HzsN+i5sNJjKsb8OgzB1yX4= X-Google-Smtp-Source: ABdhPJz23EV/kYyfM4s5EoGlIa83D9/2senhTA6roI67HvH837HCd23R0ndKm+TblnQSRcksgIq+sw== X-Received: by 2002:ac2:5c4b:: with SMTP id s11mr1182929lfp.463.1633568268697; Wed, 06 Oct 2021 17:57:48 -0700 (PDT) Original-Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id 13sm2395813lfq.285.2021.10.06.17.57.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 17:57:48 -0700 (PDT) In-Reply-To: <87fstevcfl.fsf@mail.linkov.net> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:216601 Archived-At: On 06.10.2021 10:29, Juri Linkov wrote: >>>> The command could have a mode for specifying START-POINT, so for Git the >>>> command becomes "git checkout -b new-branch-name START-POINT". This >>>> could be on C-u (unless there're other frequent "customization" cases). >>> The existing API method has no argument for START-POINT. >>> Maybe every backend could handle its prefix arg directly >>> from current-prefix-arg? For example, >>> (defun vc-git-create-tag (dir name branchp) >>> (if current-prefix-arg (completion-read "Start point: ") ... >> >> Maybe we should add a new argument, an optional one. Then backends which >> don't support it can continue working without 'C-u' (we can make sure to >> call them with appropriate number of arguments) but will obviously fail >> when passed an extra argument. We could even catch the error and report >> that the backend doesn't support this feature. > > We need to add new optional arguments to another VC-API methods anyway, e.g. > > (vc-call-backend backend 'revision-completion-table files) > > needs a new argument 'branchp' to avoid the recently added hack > 'vc-git-revision-complete-only-branches' that can't be used > in the new command 'vc-switch-branch' by 'vc-read-revision' > (that also needs a new argument 'branchp'). This will probably help in vc-switch-branch (when the user wants to retrieve a tag, I guess they will use the tag-specific command). Not sure about other places: if we're talking about the START-POSITION argument, I suppose it is possible that the user will want to start a branch from a tag instead. Or any other kind of ref, but "raw" commit hashes aren't helpful in completion anyway. >> But maybe the command should prompt for START-POINT by default: one doesn't >> create branches that often to be bothered by an extra RET, and it can be >> useful to verify the branch you are branching off of every time you do >> it. That would be my preferred behavior. And the implementation could be >> the same if we manage to treat RET as unspecified START-POINT. > > Prompting for START-POINT by default is ok. The problem is how to handle > existing backends after adding new optional arguments to VC-API methods. > Maybe first to call with an extra argument, catch an error, then call again > without an extra argument? Yes, that's the method I was thinking of.