From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#15322: VC log buffer scrolls itself Date: Thu, 24 Oct 2013 10:39:20 +0200 Message-ID: References: <55fvtc5z7w.fsf@fencepost.gnu.org> <70six9g7nn.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2d6a0e8e0df04e9789129 X-Trace: ger.gmane.org 1382604012 7931 80.91.229.3 (24 Oct 2013 08:40:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Oct 2013 08:40:12 +0000 (UTC) Cc: 15322@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 24 10:40:16 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VZGSl-0004Ki-RN for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Oct 2013 10:40:16 +0200 Original-Received: from localhost ([::1]:53275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZGSl-0001h0-CR for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Oct 2013 04:40:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZGSd-0001eJ-QP for bug-gnu-emacs@gnu.org; Thu, 24 Oct 2013 04:40:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZGSY-0002Th-WB for bug-gnu-emacs@gnu.org; Thu, 24 Oct 2013 04:40:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZGSY-0002T7-Sz for bug-gnu-emacs@gnu.org; Thu, 24 Oct 2013 04:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VZGSY-00079T-C8 for bug-gnu-emacs@gnu.org; Thu, 24 Oct 2013 04:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Oct 2013 08:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15322 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15322-submit@debbugs.gnu.org id=B15322.138260396927437 (code B ref 15322); Thu, 24 Oct 2013 08:40:02 +0000 Original-Received: (at 15322) by debbugs.gnu.org; 24 Oct 2013 08:39:29 +0000 Original-Received: from localhost ([127.0.0.1]:40183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZGS0-00078S-Qf for submit@debbugs.gnu.org; Thu, 24 Oct 2013 04:39:29 -0400 Original-Received: from mail-ob0-f172.google.com ([209.85.214.172]:54904) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZGRy-00078D-6Q for 15322@debbugs.gnu.org; Thu, 24 Oct 2013 04:39:26 -0400 Original-Received: by mail-ob0-f172.google.com with SMTP id gq1so2020212obb.3 for <15322@debbugs.gnu.org>; Thu, 24 Oct 2013 01:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v4lVwzBcHKY3uP4sP0a6oriBxJL0kRvvSBS7Va89Q2s=; b=0jxzNuN3C4tq+uz+e+8Stlw4eIiVbtVyonLNDSIvF5CtqYf39Y+0WRBVfQOCrM5lM1 FrADgTZ+VAuF7izEfng9SqXIhnnpknGewEPm4hU8G6kdjSUEfxHMq5LcGPu3QXOKGVD8 PYcA7UJNpH2dTUnmhYfCo0iJDe6TLfTS8Q6a03Ax+sJu5ljGsS0O5vpFmTDL4qvL/axB f74OCz7hthGxaM1D+HgZfIIjUkfDJYACLoNlFQXyc2Tz5TLGJIZUSwkDMcxcNPLescAz Bx+SthWEdS5nBqkHAFqrazZLdeoQqccRocLuo82zLKX4fH0QuYektpBozkkNOCV/LAXm RYvg== X-Received: by 10.182.18.9 with SMTP id s9mr1280985obd.15.1382603960146; Thu, 24 Oct 2013 01:39:20 -0700 (PDT) Original-Received: by 10.182.200.163 with HTTP; Thu, 24 Oct 2013 01:39:20 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79581 Archived-At: --001a11c2d6a0e8e0df04e9789129 Content-Type: text/plain; charset=UTF-8 Let me explain why I think scrolling is *bad*, even if it scrolls to correct revision. Log buffer here is generated for 5-10 seconds. In the meantime, I can start reading it, scrolling manually or C-s contents. And then (when loading is finished) it scrolls to a different position by itself. This is no better than focus stealing, because it disrupts my activities. I tried adding the following advice, nulling 'working-revision': (defadvice vc-print-log-internal (before disable-scrolling-to-working-revision activate) (ad-set-arg 2 nil)) but it helped only so much, because now it always scrolls to the buffer beginning (for SVN it's still an improvement), even if I already C-s to some older revision. Is it possible to disable scrolling completely, even if in a hackish way through my '.emacs'? Paul On 26 September 2013 09:17, Paul Pogonyshev wrote: > In Emacs built from trunk yesterday it still jumps, though to the > "correct" version (the one reported by 'svn info'). However, given that > committing changes from the buffer does not advance the working directory > revision (e.g. what I have now is 26 revisions in the past), I'm not sure > how useful this is, at least for subversion. Probably it's better for saner > VCS's, but for subversion if feels like annoyance. > > Paul > > > On 12 September 2013 21:30, Glenn Morris wrote: > >> Stefan Monnier wrote: >> >> > And I think that makes sense. It's natural to select a particular >> > revision when running vc-print-log from (say) vc-annotate, but for >> > a plain `C-x v l', the user just wants to see "the log" and presumably >> > doesn't care about which revision happens to be current. >> > >> > IOW, I think we're trying too hard here. >> >> *** lisp/vc/vc.el 2013-09-12 06:10:12 +0000 >> --- lisp/vc/vc.el 2013-09-12 19:28:04 +0000 >> *************** >> *** 2299,2305 **** >> (let* ((vc-fileset (vc-deduce-fileset t)) ;FIXME: Why t? --Stef >> (backend (car vc-fileset)) >> (files (cadr vc-fileset)) >> ! (working-revision (or working-revision (vc-working-revision (car >> files))))) >> (vc-print-log-internal backend files working-revision nil limit))) >> >> ;;;###autoload >> --- 2299,2306 ---- >> (let* ((vc-fileset (vc-deduce-fileset t)) ;FIXME: Why t? --Stef >> (backend (car vc-fileset)) >> (files (cadr vc-fileset)) >> ! ;; (working-revision (or working-revision (vc-working-revision (car >> files)))) >> ! ) >> (vc-print-log-internal backend files working-revision nil limit))) >> >> ;;;###autoload >> > > --001a11c2d6a0e8e0df04e9789129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me explain why I think scrolling is *bad*, even i= f it scrolls to correct revision. Log buffer here is generated for 5-10 sec= onds. In the meantime, I can start reading it, scrolling manually or C-s co= ntents. And then (when loading is finished) it scrolls to a different posit= ion by itself. This is no better than focus stealing, because it disrupts m= y activities.

I tried adding the following advice, nulling 'working-revisio= n':

=C2=A0=C2=A0=C2=A0 (defadvice vc-print-log-interna= l (before disable-scrolling-to-working-revision activate)
=C2=A0 =C2=A0 = =C2=A0 (ad-set-arg 2 nil))

but it helped only so much, because now it always scrolls to= the buffer beginning (for SVN it's still an improvement), even if I al= ready C-s to some older revision.

Is it possible to disab= le scrolling completely, even if in a hackish way through my '.emacs= 9;?

Paul

On 26 September 2013 09:17, Paul Pogonyshev <pogonyshev@gmail.com> wrote:
In Emacs built from tr= unk yesterday it still jumps, though to the "correct" version (th= e one reported by 'svn info'). However, given that committing chang= es from the buffer does not advance the working directory revision (e.g. wh= at I have now is 26 revisions in the past), I'm not sure how useful thi= s is, at least for subversion. Probably it's better for saner VCS's= , but for subversion if feels like annoyance.

Paul=


On 12 September 2013 21= :30, Glenn Morris <rgm@gnu.org> wrote:
Stefan Monnier wrote:

> And I think that makes sense. =C2=A0It's natural to select a parti= cular
> revision when running vc-print-log from (say) vc-annotate, but for
> a plain `C-x v l', the user just wants to see "the log" = and presumably
> doesn't care about which revision happens to be current.
>
> IOW, I think we're trying too hard here.

*** lisp/vc/vc.el =C2=A0 =C2=A0 =C2=A0 2013-09-12 06:10:12 +0000
--- lisp/vc/vc.el =C2=A0 =C2=A0 =C2=A0 2013-09-12 19:28:04 +0000
***************
*** 2299,2305 ****
=C2=A0 =C2=A0 (let* ((vc-fileset (vc-deduce-fileset t)) ;FIXME: Why t? --St= ef
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(backend (car vc-fileset))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(files (cadr vc-fileset))
! =C2=A0 =C2=A0 =C2=A0 =C2=A0(working-revision (or working-revision (vc-wor= king-revision (car files)))))
=C2=A0 =C2=A0 =C2=A0 (vc-print-log-internal backend files working-revision = nil limit)))

=C2=A0 ;;;###autoload
--- 2299,2306 ----
=C2=A0 =C2=A0 (let* ((vc-fileset (vc-deduce-fileset t)) ;FIXME: Why t? --St= ef
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(backend (car vc-fileset))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(files (cadr vc-fileset))
! ;; =C2=A0 =C2=A0 (working-revision (or working-revision (vc-working-revis= ion (car files))))
! =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0)
=C2=A0 =C2=A0 =C2=A0 (vc-print-log-internal backend files working-revision = nil limit)))

=C2=A0 ;;;###autoload


--001a11c2d6a0e8e0df04e9789129--