From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: vc-find-revision-no-save? Date: Mon, 27 Mar 2023 16:50:25 -0400 Message-ID: References: <4423f660-933d-bbcb-1432-76548dfbf08c@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17344"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , Stefan Monnier , Stefan Kangas , schwab@linux-m68k.org, Juri Linkov , Emacs developers To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 27 22:51:43 2023 Return-path: Envelope-to: ged-emacs-devel@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 1pgtod-0004Eb-7n for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Mar 2023 22:51:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pgtnd-0005xA-RZ; Mon, 27 Mar 2023 16:50:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pgtnc-0005ww-Jk for emacs-devel@gnu.org; Mon, 27 Mar 2023 16:50:40 -0400 Original-Received: from mail-ed1-f43.google.com ([209.85.208.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pgtna-0000ko-U9 for emacs-devel@gnu.org; Mon, 27 Mar 2023 16:50:40 -0400 Original-Received: by mail-ed1-f43.google.com with SMTP id w9so41498014edc.3 for ; Mon, 27 Mar 2023 13:50:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679950237; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fES4Xr2Y0zvcbU1QbEW0xP2/YNgEIkgyqbe8Zi3ADYE=; b=4/90nbDxUk9axAwTFRdSqs4UFq10BWWNrNqlA7/bl1DxVY18mZ6w0xR+omQ5qz439N iyta608wlviHDs1f60kgSLmzjETvGNV5snDd/Zj+0x8TQFGdpBNulDz3eVDUOXeQgBF9 r51K89R1BPOyUjs3ty7UC54dDxs2R9gs/5HLs5pLJ9kawE58T8sX7pBGH+oKqoGCih90 OVXK5qU2gCi5Ne1RPOvYDLC1qOZJQcy9U4o4DejnxWSMibAErCmaUJTCeBRqFHL5Y0b1 Ehxl43VQhiTAdigrH1tt92WDw95nty6On1yREt2QpKE1xfbTLEHp+Bl8g9OAXQTa+mue CDJw== X-Gm-Message-State: AAQBX9cn8X8htc15RKn9SQphkBbOBpoPcdiDGG53g/MZx53ySVkKMAjh fztk6l42xUaUvAdhITIMHefrsYPwkN1UnmDalys= X-Google-Smtp-Source: AKy350biN0H7DQVDHZpcC7H9TerfWCpmI9oY/J7M9GoqKWc9z8ULCVTdCOhbUOZ2OLBGXfUhutYvntKxtNLrKLHwhEc= X-Received: by 2002:a17:907:d687:b0:93d:a14f:c9b4 with SMTP id wf7-20020a170907d68700b0093da14fc9b4mr6437001ejc.2.1679950237035; Mon, 27 Mar 2023 13:50:37 -0700 (PDT) In-Reply-To: <4423f660-933d-bbcb-1432-76548dfbf08c@yandex.ru> Received-SPF: pass client-ip=209.85.208.43; envelope-from=john.yates.sheets@gmail.com; helo=mail-ed1-f43.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304791 Archived-At: On Fri, Feb 10, 2023 at 6:47=E2=80=AFPM Dmitry Gutov wro= te: > > Now, to go back to the original thread you referred to, I mentioned > vc-annotate, and you agreed that it has similar features but misses some > stuff. Such as syntax highlighting. And editing support (is that > necessary?). Actually, what I wrote was: | That said, vc-annotate is a jarring presentation. As I browse through | different revisions I want the major mode to remain that of the original | (non-annotated) file. I want syntax-based highlighting, lsp support, et= c. I do not wantdestructive editing. A revision buffer presents a view of an immutable revision. I should never be allowed to alter history (unless, of course, I do choose to rewrite history, but then, as we all know, I am actually creating new revisions with new revision IDs). What I would like is to be able to operate within a revision buffer using all non-destructive commands and modes. > Overall, I think it might be better to add features to vc-annotate than > add a very similar but different feature. Especially since it has unique > features of its own, such as showing and being able to jump to a > revision that last modified a given line. Or the one before it, etc. > IME, that's usually more useful than going through a file history > linearly. But that's my opinion. I agree that stepping linearly through the revisions on a branch often is not the interface one would want. But that is beside the point. vc-annotate is a gussied-up presentation of the output of a backend database join. To me it shoves in my face how smart it is because it can tell me, for every line, the revision, the author and the date when that line was last modified. Further, to present a color coded sense of time, it presents my source in a jarring, and utterly unfamiliar style. I view the vc-timemachine framework as one that simply knows, given a file, how to display arbitrary revisions on its branch. How the next revision to display is chosen is orthogonal. Today, vc-timemachine supports the analogs of vc-annotate's 'n' and 'p', plus "search the revision subject lines" and "jump to the n'th revision on the branch". I am working on date based navigation. There is no fundamental reason why, over time, other vc-annotate -like navigation functions cannot be added. > Finally, some nits about the first patch: > - It moves from the cache-by-default behavior to dont-cache-by-default. Correct. Stefan endorsed that change. > - It removes an existing user option without a deprecation period. The option did not go away. Originally, I changed its name to reflect the new default. Stefan had much the same objection that you did. I have since restored the original name and changed only the default. > - It adds a timemachine-related variable to vc.el (vc-tm--revision ?). > Timemachine will be a separate package, right? No. vc-timemachine is a properly integrated vc concept. (RMS explicity requested that it be so.) Any VCS backend can support vc-timemachine functionality by implementing one (optionally two) methods. > The overall idea seems sound. But if we choose the route of improving > vc-annotate, a revision cache will probably not help because we would be > caching the 'git annotate' output instead. Thus making it specific to > that feature only. That would be a different cache. This cache addresses cases where the cost simply to retrieve a revision is high, independent of whether or not that revision is then annotated.