From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Benjamin Rutt Newsgroups: gmane.emacs.devel Subject: Re: [patch] add interactive browse of revisions from vc *Annotate* buffers Date: Tue, 20 Jan 2004 11:45:54 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <1073937837.2822.180.camel@localhost> <1074519239.10692.24.camel@localhost> <87u12rbrlf.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1074618168 15662 80.91.224.253 (20 Jan 2004 17:02:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 20 Jan 2004 17:02:48 +0000 (UTC) Cc: Kai Grossjohann , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jan 20 18:02:39 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AizGv-0000sk-00 for ; Tue, 20 Jan 2004 18:02:37 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AizGv-0006uB-00 for ; Tue, 20 Jan 2004 18:02:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AizFi-0005ME-1S for emacs-devel@quimby.gnus.org; Tue, 20 Jan 2004 12:01:22 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AizDZ-0004nb-Cw for emacs-devel@gnu.org; Tue, 20 Jan 2004 11:59:09 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Aiz3M-0001Bv-Pe for emacs-devel@gnu.org; Tue, 20 Jan 2004 11:49:08 -0500 Original-Received: from [164.107.123.5] (helo=cis.ohio-state.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Aiz10-0000SD-9D for emacs-devel@gnu.org; Tue, 20 Jan 2004 11:46:10 -0500 Original-Received: from mu.cis.ohio-state.edu (daemon@mu.cis.ohio-state.edu [164.107.112.41]) by cis.ohio-state.edu (8.11.6p2-20030924/8.11.6) with ESMTP id i0KGjsP15400; Tue, 20 Jan 2004 11:45:54 -0500 (EST) Original-Received: (from rutt@localhost) by mu.cis.ohio-state.edu (8.11.6p2-20030924/8.11.6) id i0KGjst16311; Tue, 20 Jan 2004 11:45:54 -0500 (EST) X-Authentication-Warning: mu.cis.ohio-state.edu: rutt set sender to rutt.4@osu.edu using -f Original-To: Stefan Monnier Mail-Followup-To: Stefan Monnier , Kai Grossjohann , emacs-devel@gnu.org User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19357 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19357 Stefan Monnier writes: > No. In Emacs, we use chars rather than lines usually. > I think his patch should be changed to not use lines but use chars instead, > so it'll be simpler. After all, char positions are just as likely to be > more-or-less correct than line positions. I feel that the one time when line positions would be "more correct" would be when there are only minor changes to a file during successive revisions. Then, you'll likely be able to spot what was added or dropped between revisions by going back (P) and forth (N) a few times, since the code where the line was on originally will probably move up or down only a bit. On the other hand, if we went with char positions, then how closely the point follows the original line would not be determined by how many lines were added, but rather the sum of the lengths of the lines added. Another drawback of using characters, let's say only a C string was shortened during a commit, e.g.: changing "someverylongstring..." to "hi", then point might change lines even though the total # of lines in the file didn't change. > Or you could preserve "relative position in the file" (/ (- (point) > (point-min)) (- (point-max) (point-min))) instead. If we went with "relative position in the file", it would likely be surprising if you were e.g. browsing revision 1.1 whose annotate buffer had only 10 lines, and you were on line 2 (still the "Annotations for foo.c" line), then you browsed forward a few revisions. If the file grew a lot by then, all of a sudden you'd be about 20% into the file, which could be a few hundred lines by that time. This discussion brings up another point: I'd also like to preserve the column, since the annotate buffer can be very wide (it's usually > 80 columns, even if the original source code is < 80 columns). If you've spend the energy to h-scroll to the right, then I don't think I should make you h-scroll again every time you browse another revision. -- Benjamin