limit the number of log entries displayed by C-x v l

limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Logs for some big trees can be huge, the Linux one is millions of
lines.  It would be nice if C-x v l could limit the number of items
displayed because it takes too long to compute, and very seldom anybody
wants to look at so many lines.

Modern VCS can limit the number of item displayed by using a command
line argument.  So the print-log VC method can be changed to do that,
Here's how to do that for Mercurial:

--- vc-hg.el.~1.105.~	2009-10-29 21:46:20.000000000 -0700
+++ vc-hg.el	2009-11-12 05:29:06.000000000 -0800
@@ -219,5 +219,5 @@ If nil, use the value of `vc-diff-switch
                  (repeat :tag "Argument List" :value ("") string))
   :group 'vc-hg)
 
-(defun vc-hg-print-log (files &optional buffer shortlog)
+(defun vc-hg-print-log (files &optional buffer shortlog limit)
   "Get change log associated with FILES."
@@ -236,7 +232,9 @@ If nil, use the value of `vc-diff-switch
       (apply 'vc-hg-command buffer 0 files "log"
 	     (if shortlog
                  (append '("--style" "compact") vc-hg-log-switches)
-                 vc-hg-log-switches)))))
+                 vc-hg-log-switches)
+	     (when limit
+	       (list "-l" limit))))))
 
 (defvar log-view-message-re)
 (defvar log-view-file-re)


One way to set the limit is to ask the user for a limit when using a
prefix argument so that it does not change the current default behavior,
like so:

--- vc.el.~1.738.~	2009-10-24 03:59:40.000000000 -0700
+++ vc.el	2009-11-12 06:35:20.000000000 -0800
@@ -1839,7 +1839,7 @@ If it contains `directory' then if the f
 If it contains `file' then show short logs for files.
 Not all VC backends support short logs!")
 
-(defun vc-print-log-internal (backend files working-revision)
+(defun vc-print-log-internal (backend files working-revision limit)
   ;; Don't switch to the output buffer before running the command,
   ;; so that any buffer-local settings in the vc-controlled
   ;; buffer can be accessed by the command.
@@ -1852,7 +1852,7 @@ Not all VC backends support short logs!"
 	  (not (null (if dir-present
 			 (memq 'directory vc-log-short-style)
 		       (memq 'file vc-log-short-style)))))
-    (vc-call-backend backend 'print-log files "*vc-change-log*" vc-short-log)
+    (vc-call-backend backend 'print-log files "*vc-change-log*" vc-short-log limit)
     (pop-to-buffer "*vc-change-log*")
     (vc-exec-after
      `(let ((inhibit-read-only t)
@@ -1868,15 +1868,27 @@ Not all VC backends support short logs!"
 	(set-buffer-modified-p nil)))))
 
 ;;;###autoload
-(defun vc-print-log (&optional working-revision)
+(defun vc-print-log (&optional working-revision limit)
   "List the change log of the current fileset in a window.
 If WORKING-REVISION is non-nil, leave the point at that revision."
-  (interactive)
+  (interactive
+   (progn
+     (cond
+      (current-prefix-arg
+       (let ((rev (read-from-minibuffer "Log from revision (default: last revision): " nil
+				   nil nil nil))
+	     (lim (read-from-minibuffer "Limit display (default: unlimited): " ""
+				     nil nil nil)))
+	 (when (string= rev "") (setq rev nil))
+	 (when (string= lim "") (setq lim nil))
+	 (list rev lim)))
+      (t
+       (list nil nil)))))
   (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)))
+    (vc-print-log-internal backend files working-revision limit)))
 
 ;;;###autoload
 (defun vc-print-root-log ()
@@ -1890,7 +1902,7 @@ If WORKING-REVISION is non-nil, leave th
       (error "Buffer is not version controlled"))
     (setq rootdir (vc-call-backend backend 'root default-directory))
     (setq working-revision (vc-working-revision rootdir))
-    (vc-print-log-internal backend (list rootdir) working-revision)))
+    (vc-print-log-internal backend (list rootdir) working-revision nil)))
 
 ;;;###autoload
 (defun vc-revert ()


Any reason not to check this in?

The backend part is straight forward, so that should be OK.
If some VCS does not support limiting, it can just ignore the argument.

Maybe we could limit the number of entries displayed by default, maybe a
few thousands?  But that's a separate issue...

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

> Logs for some big trees can be huge, the Linux one is millions of lines.

Yes, this is a fairly serious problem.  We need to refine the
`print-log' backend op to be able to control it somehow.  E.g. in
vc-annotate, it'd be good to be able to get just the log message
corresponding to a particular commit.

For a generic `vc-print-log' operation where the user doesn't specify
any particular revision, I wonder what the best UI should be.  What do
other front-ends (e.g. loggerhead, viewCVS, ...) do to cope with the
large number of log messages?

Maybe we should show just the first thousand or so by default and then
provide a button (and command) in log-view-mode to get more?


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > Logs for some big trees can be huge, the Linux one is millions of lines.
  > 
  > Yes, this is a fairly serious problem.  We need to refine the
  > `print-log' backend op to be able to control it somehow.  E.g. in
  > vc-annotate, it'd be good to be able to get just the log message
  > corresponding to a particular commit.

With the proposed backend change that just needs
vc-annotate-show-log-revision-at-line to pass a 1 as the last argument
to vc-print-log-internal.

  > For a generic `vc-print-log' operation where the user doesn't specify
  > any particular revision, I wonder what the best UI should be.  What do
  > other front-ends (e.g. loggerhead, viewCVS, ...) do to cope with the
  > large number of log messages?

Sorry, no idea.
gitk seems to show all the entries, but it shows only the short log by default.

  > Maybe we should show just the first thousand or so by default and then
  > provide a button (and command) in log-view-mode to get more?

That could work.  
It would work with the proposed backend change.

C-x v l call would call the backend to show vc-log-show-entries, then
the button would get the revision id for the last entry in the buffer,
and it would then call the backend starting from that revision to
request more entries.

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

> With the proposed backend change that just needs
> vc-annotate-show-log-revision-at-line to pass a 1 as the last argument
> to vc-print-log-internal.

Assuming we retarget the `working-revision' argument to specify the
"starting" revision, I guess.  Yes, that could work.

>> For a generic `vc-print-log' operation where the user doesn't specify
>> any particular revision, I wonder what the best UI should be.  What do
>> other front-ends (e.g. loggerhead, viewCVS, ...) do to cope with the
>> large number of log messages?

> Sorry, no idea.  gitk seems to show all the entries, but it shows only
> the short log by default.

Good point, we (c|sh)ould also start with a more terse log and then
offer buttons/commands in log-view-mode to expand it.


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > With the proposed backend change that just needs
  > > vc-annotate-show-log-revision-at-line to pass a 1 as the last argument
  > > to vc-print-log-internal.
  > 
  > Assuming we retarget the `working-revision' argument to specify the
  > "starting" revision, I guess.  Yes, that could work.

Actually, after looking a bit more we'd need more changes, the
`working-revision' is not passed to the `print-log' VC method, so a bit
more work would be needed for that :-(
But this does not affect my original proposal, which is still needed.

  > >> For a generic `vc-print-log' operation where the user doesn't specify
  > >> any particular revision, I wonder what the best UI should be.  What do
  > >> other front-ends (e.g. loggerhead, viewCVS, ...) do to cope with the
  > >> large number of log messages?
  > 
  > > Sorry, no idea.  gitk seems to show all the entries, but it shows only
  > > the short log by default.
  > 
  > Good point, we (c|sh)ould also start with a more terse log and then
  > offer buttons/commands in log-view-mode to expand it.

We show the terse log for directories already, but there's no way to
expand it (yet).  But even when using the terse log, there's still a
need to limit the log size.

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

>> > With the proposed backend change that just needs
>> > vc-annotate-show-log-revision-at-line to pass a 1 as the last argument
>> > to vc-print-log-internal.
>> Assuming we retarget the `working-revision' argument to specify the
>> "starting" revision, I guess.  Yes, that could work.
> Actually, after looking a bit more we'd need more changes, the
> `working-revision' is not passed to the `print-log' VC method, so a bit
> more work would be needed for that :-(
> But this does not affect my original proposal, which is still needed.

Yes, I'm not opposing it, I'm just trying to get a better general
picture.  Some of the problems we may encounter is that some backends
don't support the `limit' argument.  Hopefully all those backends can
easily turn a "print-log FILE REV LIMIT=1" request into "print-log FILE
REV1 REV2" instead, tho.  Not sure what to do for other values of LIMIT,
but maybe that's doable as well.

> We show the terse log for directories already, but there's no way to
> expand it (yet).  But even when using the terse log, there's still a
> need to limit the log size.

That's my impression a well,


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> > With the proposed backend change that just needs
  > >> > vc-annotate-show-log-revision-at-line to pass a 1 as the last argument
  > >> > to vc-print-log-internal.
  > >> Assuming we retarget the `working-revision' argument to specify the
  > >> "starting" revision, I guess.  Yes, that could work.
  > > Actually, after looking a bit more we'd need more changes, the
  > > `working-revision' is not passed to the `print-log' VC method, so a bit
  > > more work would be needed for that :-(
  > > But this does not affect my original proposal, which is still needed.
  > 
  > Yes, I'm not opposing it,

I checked a patch that adds the LIMIT argument.
LIMIT defaults to the value of new variable vc-log-show-limit (not a
very good name).  vc-log-show-limit is set to 0 (meaning no limit), so
the default behavior has not changed.  Please feel free to change the
default value.

The limit can be set interactively when using a prefix argument.

I changed all the backends that do not support LIMIT to ignore it.  And
I added support for it for all the ones that do, except for Git.  Git
has enough fans on this list, so surely someone else will do it.

I'll work on adding button(s) to request more entries.

  >  I'm just trying to get a better general
  > picture.  Some of the problems we may encounter is that some backends
  > don't support the `limit' argument.  Hopefully all those backends can
  > easily turn a "print-log FILE REV LIMIT=1" request into "print-log FILE
  > REV1 REV2" instead, tho.  Not sure what to do for other values of LIMIT,
  > but maybe that's doable as well.

It seems that for this we need to add another argument to the
`print-log' VC method: START-REVISION.
Do we want to also add END-REVISION?

Given that vc-annotate would only use START-REVISION in conjunction with
LIMIT==1, we can document that the backends should only support that
combination, at least for the time being.

Re: limit the number of log entries displayed by C-x v l

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> I checked a patch that adds the LIMIT argument.
> LIMIT defaults to the value of new variable vc-log-show-limit (not a
> very good name).  vc-log-show-limit is set to 0 (meaning no limit), so
> the default behavior has not changed.  Please feel free to change the
> default value.
>
> The limit can be set interactively when using a prefix argument.

Thank you.  Please add a NEWS entry as well.

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > I'll work on adding button(s) to request more entries.

Here's how this can be done.  OK?

Index: vc.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc.el,v
retrieving revision 1.739
diff -u -3 -p -r1.739 vc.el
--- vc.el	15 Nov 2009 20:29:02 -0000	1.739
+++ vc.el	16 Nov 2009 09:34:00 -0000
@@ -1858,6 +1858,10 @@ Not all VC backends support short logs!"
 	  (not (null (if dir-present
 			 (memq 'directory vc-log-short-style)
 		       (memq 'file vc-log-short-style)))))
+
+    ;; Some backends cannot support output limits.
+    (when (memq backend '(RCS CVS SCCS)) (setq limit nil))
+
     (vc-call-backend backend 'print-log files "*vc-change-log*" vc-short-log limit)
     (pop-to-buffer "*vc-change-log*")
     (vc-exec-after
@@ -1867,6 +1871,23 @@ Not all VC backends support short logs!"
 	(set (make-local-variable 'log-view-vc-backend) ',backend)
 	(set (make-local-variable 'log-view-vc-fileset) ',files)
 
+	(when ,limit
+	  (goto-char (point-max))
+	  (widget-create 'push-button
+			 :notify (lambda (&rest ignore)
+				   (vc-print-log-internal
+				    ',backend ',files ',working-revision (* 2 ,limit)))
+			 :help-echo "Show the log again, and double the number of log entries shown"
+			 "Show 2X entries")
+	  (widget-insert "    ")
+	  (widget-create 'push-button
+			 :notify (lambda (&rest ignore)
+				   (vc-print-log-internal
+				    ',backend ',files ',working-revision nil))
+			 :help-echo "Show the log again, showing all entries"
+			 "Show unlimited entries")
+	  (widget-setup))
+
 	(shrink-window-if-larger-than-buffer)
 	;; move point to the log entry for the working revision
 	(vc-call-backend ',backend 'show-log-entry ',working-revision)
Index: log-view.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/log-view.el,v
retrieving revision 1.61
diff -u -3 -p -r1.61 log-view.el
--- log-view.el	5 Oct 2009 15:10:04 -0000	1.61
+++ log-view.el	16 Nov 2009 09:34:01 -0000
@@ -139,6 +139,7 @@
     ("\M-n" . log-view-file-next)
     ("\M-p" . log-view-file-prev))
   "Log-View's keymap."
+  :inherit widget-keymap
   :group 'log-view)
 
 (easy-menu-define log-view-mode-menu log-view-mode-map

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

> Here's how this can be done.  OK?
[...]
> +    ;; Some backends cannot support output limits.
> +    (when (memq backend '(RCS CVS SCCS)) (setq limit nil))

This is not OK, no.  You could make `print-log' return the relevant
info instead.


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > Here's how this can be done.  OK?
  > [...]
  > > +    ;; Some backends cannot support output limits.
  > > +    (when (memq backend '(RCS CVS SCCS)) (setq limit nil))
  > 
  > This is not OK, no. 

How about the rest?  This is about the most unimportant part of the
patch.  I can even be taken out.

  >  You could make `print-log' return the relevant info instead.

Like say, make `vc-rcs-print-log' return `limit-unsupported' if passed a
non-nil limit?  OK with that kind of change?

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

>> > Here's how this can be done.  OK?
>> [...]
>> > +    ;; Some backends cannot support output limits.
>> > +    (when (memq backend '(RCS CVS SCCS)) (setq limit nil))
>> This is not OK, no.
> How about the rest?  This is about the most unimportant part of the
> patch.  I can even be taken out.

The rest seemed OK, yes.

>> You could make `print-log' return the relevant info instead.
> Like say, make `vc-rcs-print-log' return `limit-unsupported' if passed a
> non-nil limit?  OK with that kind of change?

Yes,


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> > Here's how this can be done.  OK?
  > >> [...]
  > >> > +    ;; Some backends cannot support output limits.
  > >> > +    (when (memq backend '(RCS CVS SCCS)) (setq limit nil))
  > >> This is not OK, no.
  > > How about the rest?  This is about the most unimportant part of the
  > > patch.  I can even be taken out.
  > 
  > The rest seemed OK, yes.
  > 
  > >> You could make `print-log' return the relevant info instead.
  > > Like say, make `vc-rcs-print-log' return `limit-unsupported' if passed a
  > > non-nil limit?  OK with that kind of change?
  > 
  > Yes,

Checked in with the requested changes.
I set vc-log-show-limit arbitrarily to 2000.  It can be changed if it's
considered too small or too big.

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> > With the proposed backend change that just needs
  > >> > vc-annotate-show-log-revision-at-line to pass a 1 as the last argument
  > >> > to vc-print-log-internal.
  > >> Assuming we retarget the `working-revision' argument to specify the
  > >> "starting" revision, I guess.  Yes, that could work.
  > > Actually, after looking a bit more we'd need more changes, the
  > > `working-revision' is not passed to the `print-log' VC method, so a bit
  > > more work would be needed for that :-(
  > > But this does not affect my original proposal, which is still needed.
  > 
  > Yes, I'm not opposing it, I'm just trying to get a better general
  > picture.  Some of the problems we may encounter is that some backends
  > don't support the `limit' argument.  Hopefully all those backends can
  > easily turn a "print-log FILE REV LIMIT=1" request into "print-log FILE
  > REV1 REV2" instead, tho.  Not sure what to do for other values of LIMIT,
  > but maybe that's doable as well.

Here's a patch that implements only showing a single log entry from
vc-annotate.
It adds a START-REVISION argument to the print-log VC method.
It adds a boolean argument to vc-print-log-internal, when set it means
that the WORKING-REVISION argument is the start revision.

What do you think?

Index: vc-annotate.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-annotate.el,v
retrieving revision 1.10
diff -u -3 -p -r1.10 vc-annotate.el
--- vc-annotate.el	19 Oct 2009 05:04:28 -0000	1.10
+++ vc-annotate.el	17 Nov 2009 13:35:55 -0000
@@ -487,7 +487,7 @@ Return a cons (REV . FILENAME)."
       (if (not rev-at-line)
 	  (message "Cannot extract revision number from the current line")
 	(vc-print-log-internal
-	 vc-annotate-backend (list (cdr rev-at-line)) (car rev-at-line))))))
+	 vc-annotate-backend (list (cdr rev-at-line)) (car rev-at-line) 1 t)))))
 
 (defun vc-annotate-show-diff-revision-at-line-internal (filediff)
   (if (not (equal major-mode 'vc-annotate-mode))
Index: vc-bzr.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-bzr.el,v
retrieving revision 1.85
diff -u -3 -p -r1.85 vc-bzr.el
--- vc-bzr.el	15 Nov 2009 20:29:01 -0000	1.85
+++ vc-bzr.el	17 Nov 2009 13:35:55 -0000
@@ -481,7 +481,7 @@ REV non-nil gets an error."
 		    (2 'change-log-email))
 		   ("^ *timestamp: \\(.*\\)" (1 'change-log-date-face)))))))
 
-(defun vc-bzr-print-log (files buffer &optional shortlog limit)
+(defun vc-bzr-print-log (files buffer &optional shortlog limit start-revision)
   "Get bzr change log for FILES into specified BUFFER."
   ;; `vc-do-command' creates the buffer, but we need it before running
   ;; the command.
@@ -493,11 +493,13 @@ REV non-nil gets an error."
   ;; way of getting the above regexps working.
   (with-current-buffer buffer
     (apply 'vc-bzr-command "log" buffer 'async files
-	   (when shortlog "--short")
-	   (when limit (list "-l" (format "%s" limit)))
-	   (if (stringp vc-bzr-log-switches)
-	       (list vc-bzr-log-switches)
-	     vc-bzr-log-switches))))
+	   (append
+	    (when shortlog '("--short"))
+	    (when start-revision (list (format "-r..%s" start-revision)))
+	    (when limit (list "-l" (format "%s" limit)))
+	    (if (stringp vc-bzr-log-switches)
+		(list vc-bzr-log-switches)
+	      vc-bzr-log-switches)))))
 
 (defun vc-bzr-show-log-entry (revision)
   "Find entry for patch name REVISION in bzr change log buffer."
Index: vc.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc.el,v
retrieving revision 1.740
diff -u -3 -p -r1.740 vc.el
--- vc.el	16 Nov 2009 20:36:11 -0000	1.740
+++ vc.el	17 Nov 2009 13:35:55 -0000
@@ -333,13 +333,16 @@
 ;;
 ;; HISTORY FUNCTIONS
 ;;
-;; * print-log (files buffer &optional shortlog limit)
+;; * print-log (files buffer &optional shortlog limit start-revision)
 ;;
 ;;   Insert the revision log for FILES into BUFFER.
 ;;   If SHORTLOG is true insert a short version of the log.
 ;;   If LIMIT is true insert only insert LIMIT log entries.  If the
 ;;   backend does not support limiting the number of entries to show
 ;;   it should return `limit-unsupported'.
+;;   If START-REVISION is given, then show the log starting from the
+;;   revision.  At this point START-REVISION is only required to work
+;;   in conjunction with LIMIT = 1.
 ;;
 ;; - log-view-mode ()
 ;;
@@ -1847,7 +1850,7 @@ If it contains `directory' then if the f
 If it contains `file' then show short logs for files.
 Not all VC backends support short logs!")
 
-(defun vc-print-log-internal (backend files working-revision limit)
+(defun vc-print-log-internal (backend files working-revision limit is-start-revision)
   ;; Don't switch to the output buffer before running the command,
   ;; so that any buffer-local settings in the vc-controlled
   ;; buffer can be accessed by the command.
@@ -1863,7 +1866,8 @@ Not all VC backends support short logs!"
 		       (memq 'file vc-log-short-style)))))
 
     (setq pl-return (vc-call-backend backend 'print-log files "*vc-change-log*"
-				     vc-short-log limit))
+				     vc-short-log limit 
+				     (when is-start-revision working-revision)))
     (pop-to-buffer "*vc-change-log*")
     (vc-exec-after
      `(let ((inhibit-read-only t)
@@ -1872,19 +1876,20 @@ Not all VC backends support short logs!"
 	(set (make-local-variable 'log-view-vc-backend) ',backend)
 	(set (make-local-variable 'log-view-vc-fileset) ',files)
 
-	(when (and ,limit (not (eq 'limit-unsupported pl-return)))
+	(when (and ,limit (not (eq 'limit-unsupported pl-return))
+		   (not ,is-start-revision))
 	  (goto-char (point-max))
 	  (widget-create 'push-button
 			 :notify (lambda (&rest ignore)
 				   (vc-print-log-internal
-				    ',backend ',files ',working-revision (* 2 ,limit)))
+				    ',backend ',files ',working-revision (* 2 ,limit) nil))
 			 :help-echo "Show the log again, and double the number of log entries shown"
 			 "Show 2X entries")
 	  (widget-insert "    ")
 	  (widget-create 'push-button
 			 :notify (lambda (&rest ignore)
 				   (vc-print-log-internal
-				    ',backend ',files ',working-revision nil))
+				    ',backend ',files ',working-revision nil nil))
 			 :help-echo "Show the log again, showing all entries"
 			 "Show unlimited entries")
 	  (widget-setup))
@@ -1918,7 +1923,7 @@ If WORKING-REVISION is non-nil, leave th
 	 (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 limit)))
+    (vc-print-log-internal backend files working-revision limit nil)))
 
 ;;;###autoload
 (defun vc-print-root-log (&optional limit)
@@ -1943,7 +1948,7 @@ If WORKING-REVISION is non-nil, leave th
       (error "Buffer is not version controlled"))
     (setq rootdir (vc-call-backend backend 'root default-directory))
     (setq working-revision (vc-working-revision rootdir))
-    (vc-print-log-internal backend (list rootdir) working-revision limit)))
+    (vc-print-log-internal backend (list rootdir) working-revision limit nil)))
 
 ;;;###autoload
 (defun vc-revert ()

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

> Here's a patch that implements only showing a single log entry from
> vc-annotate.
> It adds a START-REVISION argument to the print-log VC method.
> It adds a boolean argument to vc-print-log-internal, when set it means
> that the WORKING-REVISION argument is the start revision.

> What do you think?

Doesn't look too bad.  Maybe the UI part could be improved (e.g. show
the single log-comment in a tooltip), but that's fairly minor.

Having tried it on Bzr I see that it's still sufficiently slow with that
backend, that I might prefer to see the complete log so I can then
navigate it to see the various revisions I'm interested in, rather than
get a single-comment N times.


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > > Here's a patch that implements only showing a single log entry from
  > > vc-annotate.
  > > It adds a START-REVISION argument to the print-log VC method.
  > > It adds a boolean argument to vc-print-log-internal, when set it means
  > > that the WORKING-REVISION argument is the start revision.
  > 
  > > What do you think?
  > 
  > Doesn't look too bad.  Maybe the UI part could be improved (e.g. show
  > the single log-comment in a tooltip), but that's fairly minor.
  > 
  > Having tried it on Bzr I see that it's still sufficiently slow with that
  > backend, that I might prefer to see the complete log so I can then
  > navigate it to see the various revisions I'm interested in, rather than
  > get a single-comment N times.

Then one can just do C-x v l ... 
The reason I found your idea to show a single entry interesting: with
the limiting of C-x v l output that we do now by default, you can ask
for a log in vc-annotate and not get it if the log entry is old enough.
It's rather nice to see exactly the entry you asked for.

So what should we do?

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

>> Having tried it on Bzr I see that it's still sufficiently slow with that
>> backend, that I might prefer to see the complete log so I can then
>> navigate it to see the various revisions I'm interested in, rather than
>> get a single-comment N times.
> Then one can just do C-x v l ...

Good point.

> The reason I found your idea to show a single entry interesting: with
> the limiting of C-x v l output that we do now by default, you can ask
> for a log in vc-annotate and not get it if the log entry is old enough.
> It's rather nice to see exactly the entry you asked for.
> So what should we do?

Change vc-annotate's code so that if the file's log is already displayed
in the *vc-change-log* buffer, it just jumps to the appropriate entry,
otherwise it does what your code did (i.e. ask the backend for just
that revision's log).


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Having tried it on Bzr I see that it's still sufficiently slow with that
>>> backend, that I might prefer to see the complete log so I can then
>>> navigate it to see the various revisions I'm interested in, rather than
>>> get a single-comment N times.
>> Then one can just do C-x v l ...
>
> Good point.
>
>> The reason I found your idea to show a single entry interesting: with
>> the limiting of C-x v l output that we do now by default, you can ask
>> for a log in vc-annotate and not get it if the log entry is old enough.
>> It's rather nice to see exactly the entry you asked for.
>> So what should we do?
>
> Change vc-annotate's code so that if the file's log is already displayed
> in the *vc-change-log* buffer, it just jumps to the appropriate entry,
> otherwise it does what your code did (i.e. ask the backend for just
> that revision's log).

Have a look at xhg-annotate mode in DVC (screenshot).
http://tinyurl.com/ycen32l


-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

  > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > 
  > >>> Having tried it on Bzr I see that it's still sufficiently slow with that
  > >>> backend, that I might prefer to see the complete log so I can then
  > >>> navigate it to see the various revisions I'm interested in, rather than
  > >>> get a single-comment N times.
  > >> Then one can just do C-x v l ...
  > >
  > > Good point.
  > >
  > >> The reason I found your idea to show a single entry interesting: with
  > >> the limiting of C-x v l output that we do now by default, you can ask
  > >> for a log in vc-annotate and not get it if the log entry is old enough.
  > >> It's rather nice to see exactly the entry you asked for.
  > >> So what should we do?
  > >
  > > Change vc-annotate's code so that if the file's log is already displayed
  > > in the *vc-change-log* buffer, it just jumps to the appropriate entry,
  > > otherwise it does what your code did (i.e. ask the backend for just
  > > that revision's log).
  > 
  > Have a look at xhg-annotate mode in DVC (screenshot).
  > http://tinyurl.com/ycen32l

That seems to show a buffer with both the diff and the log.
Why is that a good idea?  What mode does it use?

Re: limit the number of log entries displayed by C-x v l

[Thierry Volpiatto]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>   > Stefan Monnier <monnier@iro.umontreal.ca> writes:
>   > 
>   > >>> Having tried it on Bzr I see that it's still sufficiently slow with that
>   > >>> backend, that I might prefer to see the complete log so I can then
>   > >>> navigate it to see the various revisions I'm interested in, rather than
>   > >>> get a single-comment N times.
>   > >> Then one can just do C-x v l ...
>   > >
>   > > Good point.
>   > >
>   > >> The reason I found your idea to show a single entry interesting: with
>   > >> the limiting of C-x v l output that we do now by default, you can ask
>   > >> for a log in vc-annotate and not get it if the log entry is old enough.
>   > >> It's rather nice to see exactly the entry you asked for.
>   > >> So what should we do?
>   > >
>   > > Change vc-annotate's code so that if the file's log is already displayed
>   > > in the *vc-change-log* buffer, it just jumps to the appropriate entry,
>   > > otherwise it does what your code did (i.e. ask the backend for just
>   > > that revision's log).
>   > 
>   > Have a look at xhg-annotate mode in DVC (screenshot).
>   > http://tinyurl.com/ycen32l
>
> That seems to show a buffer with both the diff and the log.
> Why is that a good idea?  What mode does it use?

The mode is xhg-annotate-mode, it is part of DVC
http://www.xsteve.at/prg/emacs_dvc/
The file is xhg-annotate.el

It does what hg annotate does but interactively:

,----
| From current file under hg control, run xhg-annotate in one buffer
| and xhg-log in the other buffer at the revision corresponding to current line
| of current file.
| once in the xhg-annotate buffer you can navigate to the different line
| showing at each movement the xhg-log output corresponding to revision.
`----

See hg help annotate.

About C-x v l, see also xhg-log, that use prefix arg to reduce number of
revisions to show, or to show from rev number x to rev number y.


,----[ C-h f xhg-log RET ]
| xhg-log is an interactive compiled Lisp function in `xhg.el'.
| 
| (xhg-log &optional R1 R2 SHOW-PATCH FILE)
| 
| Run hg log.
| When run interactively, the prefix argument decides, which parameters are queried from the user.
| C-u      : Show patches also, use all revisions
| C-u C-u  : Show patches also, ask for revisions
| positive : Don't show patches, ask for revisions.
| negative : Don't show patches, limit to n revisions.
| 
| ===*===*===*===*===*===*===*===*===*===*===
`----


-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

>> Have a look at xhg-annotate mode in DVC (screenshot).
>> http://tinyurl.com/ycen32l
> That seems to show a buffer with both the diff and the log.
> Why is that a good idea?

I have nothing to do with this code and have never used it, but usually
I want to seem them both.


        Stefan "still waiting for VCS to give me a "history of region NN..MM"
                command that will show the sequenece of patches with their
                commit logs that resulted in the lines between NN and MM"

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> Have a look at xhg-annotate mode in DVC (screenshot).
  > >> http://tinyurl.com/ycen32l
  > > That seems to show a buffer with both the diff and the log.
  > > Why is that a good idea?
  > 
  > I have nothing to do with this code and have never used it, but usually
  > I want to seem them both.

In the same buffer?  Then you'd have to give up on the capabilities of
one of diff-mode or log-view-mode (as we can't currently use multiple
major modes in a single buffer).

If you'd want diff and log in separate buffers, we can make a deal: I
can write the few lines needed to compute both buffers, if you write the
part to display the 2 buffers.


  >         Stefan "still waiting for VCS to give me a "history of region NN..MM"
  >                 command that will show the sequenece of patches with their
  >                 commit logs that resulted in the lines between NN and MM"

Dream on :-)

Re: limit the number of log entries displayed by C-x v l

[Stephen J. Turnbull]

Dan Nicolaescu writes:

 >   >         Stefan "still waiting for VCS to give me a "history of region NN..MM"
 >   >                 command that will show the sequenece of patches with their
 >   >                 commit logs that resulted in the lines between NN and MM"
 > 
 > Dream on :-)

For git users it wouldn't be hard, actually.

The algorithm is a straightforward filter on annotate, and since
you have to do a diff anyway to get line numbers, Bob's yer uncle, you
just refuse to forget them as you go along.

You ought to suggest it on bazaar@canonical; this is the kind of thing
that gets them all hot and bothered, leading to massive insomnia until
they have implemented a new branch format to support it.<0.5 wink>
Better do it before they catch Moratorium Fever, though!

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

> You ought to suggest it on bazaar@canonical; this is the kind of thing
> that gets them all hot and bothered, leading to massive insomnia until
> they have implemented a new branch format to support it.<0.5 wink>
> Better do it before they catch Moratorium Fever, though!

They can't even do "log+diff", and some of the main contributors have
already seen this suggestion back when I asked for it for Arch.
Nobody's ever seemed to understand how useful it would be.


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Štěpán Němec]

On Sun, Nov 22, 2009 at 03:12:17PM -0500, Stefan Monnier wrote:
> > You ought to suggest it on bazaar@canonical; this is the kind of thing
> > that gets them all hot and bothered, leading to massive insomnia until
> > they have implemented a new branch format to support it.<0.5 wink>
> > Better do it before they catch Moratorium Fever, though!
> 
> They can't even do "log+diff", and some of the main contributors have
> already seen this suggestion back when I asked for it for Arch.
> Nobody's ever seemed to understand how useful it would be.

Bzr does have `log -p' (as does Git and Hg of course), which shows the
log and diff at the same time.

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

>> They can't even do "log+diff", and some of the main contributors have
>> already seen this suggestion back when I asked for it for Arch.
>> Nobody's ever seemed to understand how useful it would be.

> Bzr does have `log -p' (as does Git and Hg of course), which shows the
> log and diff at the same time.

Thanks for proving me wrong. ;-)
So maybe there is hope for the feature of which I've been dreaming.


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Bob Rogers]

   From: Stefan Monnier <monnier@iro.umontreal.ca>
   Date: Sun, 22 Nov 2009 21:29:15 -0500

   >> They can't even do "log+diff", and some of the main contributors have
   >> already seen this suggestion back when I asked for it for Arch.
   >> Nobody's ever seemed to understand how useful it would be.

   > Bzr does have `log -p' (as does Git and Hg of course), which shows the
   > log and diff at the same time.

   Thanks for proving me wrong. ;-)
   So maybe there is hope for the feature of which I've been dreaming.

	   Stefan

Here's a non-backend-specific hack for C-n and C-p in vc-annotate-mode
that keeps any log-view-mode buffer displayed on the same frame in sync
to the same revision.  A post-command-hook solution might be more
thorough, though (handling C-s, e.g.), but is this in the direction of
what you had in mind?

					-- Bob Rogers
					   http://www.rgrjr.com/

------------------------------------------------------------------------
(defun vc-annotate-find-visible-log-buffer-window
       (file &optional start-window last-window)
  ;; Look for a window on the current frame that contains a
  ;; log-view-mode buffer that is looking at file.
  (or start-window (setq start-window (selected-window)
			 last-window start-window))
  (let ((window (next-window last-window)))
    (if (not (eq window start-window))
	;; See if window contains a log buffer.
	(or (save-excursion
	      (set-buffer (window-buffer window))
	      (and (eq major-mode 'log-view-mode)
		   (condition-case ()
		       ;; This shouldn't fail in a log-view-mode
		       ;; buffer, but just in case.
		       (equal (log-view-current-file) file)
		     (error nil))
		   window))
	    (vc-annotate-find-visible-log-buffer-window file start-window
							window)))))

(defun vc-annotate-next-line (&optional arg)
  "Next line in an annotation buffer, keeping any visible log in sync."
  (interactive "^p")
  (line-move-1 (or arg 1))
  (if (not (equal major-mode 'vc-annotate-mode))
      (error "Cannot be invoked outside of a vc annotate buffer."))
  (let* ((backend vc-annotate-backend)
	 (rev-at-line (vc-annotate-extract-revision-at-line))
	 (revision (car rev-at-line))
	 (file (cdr rev-at-line))
	 (log-buffer-window
	   (and rev-at-line
		(vc-annotate-find-visible-log-buffer-window file))))
    (if log-buffer-window
	(let ((original-window (selected-window)))
	  (select-window log-buffer-window)
	  (vc-call-backend backend 'show-log-entry revision)
	  (select-window original-window)))))

(defun vc-annotate-previous-line (&optional arg)
  "Previous line in an annotation buffer, keeping any visible log in sync."
  (interactive "^p")
  (vc-annotate-next-line (- (or arg 1))))

(define-key vc-annotate-mode-map "\C-n" 'vc-annotate-next-line)
(define-key vc-annotate-mode-map "\C-p" 'vc-annotate-previous-line)

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

> Here's a non-backend-specific hack for C-n and C-p in vc-annotate-mode
> that keeps any log-view-mode buffer displayed on the same frame in sync
> to the same revision.  A post-command-hook solution might be more
> thorough, though (handling C-s, e.g.), but is this in the direction of
> what you had in mind?

Not really.  I want to give a range of lines BEG..END and then get
a list of patches going backward in time showing all the commits that
ended up (directly or indirectly) with generating those lines.
So it will give me an information akin to (tho not in prose) "those
lines were changed in r1834 by changing indentation, before that r1498
renamed foo to bar, before that r1244 extended the code to handle one
more case, and finally r1022 is the one change that really introduced
the core behavior of those lines (and then it'll keep telling me more
things but I won't care about them)".

I do it in a backend-independent way by hand, in the following way:
1- start at REV=latest revision
2- vc-annotate REV
3- get the diff and log of the lines
4- set REV to the revision prior to the one that changed those lines and
   go back to 2.


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

>> I have nothing to do with this code and have never used it, but usually
>> I want to seem them both.
> In the same buffer?

Ideally, yes, tho currently I usually just do `l' and `d', so I get
two buffers.

> Then you'd have to give up on the capabilities of one of diff-mode or
> log-view-mode (as we can't currently use multiple major modes in
> a single buffer).

Since it would only show a single log message, I wouldn't lose much of
log-view's functionality.

>> Stefan "still waiting for VCS to give me a "history of region NN..MM"
>> command that will show the sequenece of patches with their
>> commit logs that resulted in the lines between NN and MM"
> Dream on :-)

I know, but it would be so much more useful than `annotate'.


        Stefan

Re: limit the number of log entries displayed by C-x v l

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> Having tried it on Bzr I see that it's still sufficiently slow with that
  > >> backend, that I might prefer to see the complete log so I can then
  > >> navigate it to see the various revisions I'm interested in, rather than
  > >> get a single-comment N times.
  > > Then one can just do C-x v l ...
  > 
  > Good point.
  > 
  > > The reason I found your idea to show a single entry interesting: with
  > > the limiting of C-x v l output that we do now by default, you can ask
  > > for a log in vc-annotate and not get it if the log entry is old enough.
  > > It's rather nice to see exactly the entry you asked for.
  > > So what should we do?
  > 
  > Change vc-annotate's code so that if the file's log is already displayed
  > in the *vc-change-log* buffer, it just jumps to the appropriate entry,
  > otherwise it does what your code did (i.e. ask the backend for just
  > that revision's log).

This patch does that.
OK?

Index: vc.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc.el,v
retrieving revision 1.744
diff -u -3 -p -r1.744 vc.el
--- vc.el	3 Dec 2009 03:11:17 -0000	1.744
+++ vc.el	6 Dec 2009 17:36:53 -0000
@@ -333,13 +333,16 @@
 ;;
 ;; HISTORY FUNCTIONS
 ;;
-;; * print-log (files buffer &optional shortlog limit)
+;; * print-log (files buffer &optional shortlog limit start-revision)
 ;;
 ;;   Insert the revision log for FILES into BUFFER.
 ;;   If SHORTLOG is true insert a short version of the log.
 ;;   If LIMIT is true insert only insert LIMIT log entries.  If the
 ;;   backend does not support limiting the number of entries to show
 ;;   it should return `limit-unsupported'.
+;;   If START-REVISION is given, then show the log starting from the
+;;   revision.  At this point START-REVISION is only required to work
+;;   in conjunction with LIMIT = 1.
 ;;
 ;; - log-view-mode ()
 ;;
@@ -1863,7 +1866,7 @@ Not all VC backends support short logs!"
 (defvar log-view-vc-fileset)
 
 (defun vc-print-log-internal (backend files working-revision
-                                      &optional limit)
+                                      &optional limit is-start-revision)
   ;; Don't switch to the output buffer before running the command,
   ;; so that any buffer-local settings in the vc-controlled
   ;; buffer can be accessed by the command.
@@ -1879,7 +1882,8 @@ Not all VC backends support short logs!"
 		       (memq 'file vc-log-short-style)))))
 
     (setq pl-return (vc-call-backend backend 'print-log files "*vc-change-log*"
-				     vc-short-log limit))
+				     vc-short-log limit
+				     (when is-start-revision working-revision)))
     (pop-to-buffer "*vc-change-log*")
     (let ((inhibit-read-only t))
       ;; log-view-mode used to be called with inhibit-read-only bound
@@ -1890,19 +1894,20 @@ Not all VC backends support short logs!"
 
     (vc-exec-after
      `(let ((inhibit-read-only t))
-	(when (and ,limit (not (eq 'limit-unsupported pl-return)))
+	(when (and ,limit (not ,(eq 'limit-unsupported pl-return))
+		   (not ,is-start-revision))
 	  (goto-char (point-max))
 	  (widget-create 'push-button
 			 :notify (lambda (&rest ignore)
 				   (vc-print-log-internal
-				    ',backend ',files ',working-revision (* 2 ,limit)))
+				    ',backend ',files ',working-revision (* 2 ,limit) nil))
 			 :help-echo "Show the log again, and double the number of log entries shown"
 			 "Show 2X entries")
 	  (widget-insert "    ")
 	  (widget-create 'push-button
 			 :notify (lambda (&rest ignore)
 				   (vc-print-log-internal
-				    ',backend ',files ',working-revision nil))
+				    ',backend ',files ',working-revision nil nil))
 			 :help-echo "Show the log again, showing all entries"
 			 "Show unlimited entries")
 	  (widget-setup))
@@ -1962,7 +1967,7 @@ If WORKING-REVISION is non-nil, leave th
       (error "Buffer is not version controlled"))
     (setq rootdir (vc-call-backend backend 'root default-directory))
     (setq working-revision (vc-working-revision rootdir))
-    (vc-print-log-internal backend (list rootdir) working-revision limit)))
+    (vc-print-log-internal backend (list rootdir) working-revision limit nil)))
 
 ;;;###autoload
 (defun vc-revert ()
Index: vc-annotate.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-annotate.el,v
retrieving revision 1.12
diff -u -3 -p -r1.12 vc-annotate.el
--- vc-annotate.el	25 Nov 2009 23:47:35 -0000	1.12
+++ vc-annotate.el	6 Dec 2009 17:36:53 -0000
@@ -486,8 +486,24 @@ Return a cons (REV . FILENAME)."
     (let ((rev-at-line (vc-annotate-extract-revision-at-line)))
       (if (not rev-at-line)
 	  (message "Cannot extract revision number from the current line")
-	(vc-print-log-internal
-	 vc-annotate-backend (list (cdr rev-at-line)) (car rev-at-line) nil)))))
+	(let ((backend vc-annotate-backend)
+	      (log-buf (get-buffer "*vc-change-log*"))
+	      pos)
+	  (if (and
+	       log-buf
+	       (with-current-buffer log-buf
+		 (and (eq backend log-view-vc-backend)
+		      (null (cdr log-view-vc-fileset))
+		      (string= (car log-view-vc-fileset) (cdr rev-at-line))
+		      (vc-call-backend
+		       backend 'show-log-entry (car rev-at-line))
+		      (setq pos (point)))))
+	      (progn
+		(pop-to-buffer log-buf)
+		(goto-char pos))
+	    (vc-print-log-internal
+	     vc-annotate-backend (list (cdr rev-at-line))
+	     (car rev-at-line) 1 t)))))))
 
 (defun vc-annotate-show-diff-revision-at-line-internal (filediff)
   (if (not (equal major-mode 'vc-annotate-mode))
Index: vc-bzr.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-bzr.el,v
retrieving revision 1.89
diff -u -3 -p -r1.89 vc-bzr.el
--- vc-bzr.el	3 Dec 2009 08:53:06 -0000	1.89
+++ vc-bzr.el	6 Dec 2009 17:36:53 -0000
@@ -468,11 +468,11 @@ REV non-nil gets an error."
        ;; log-view-font-lock-keywords is careful to use the buffer-local
        ;; value of log-view-message-re only since Emacs-23.
        (if vc-short-log
-	 (append `((,log-view-message-re
-		    (1 'log-view-message-face)
-		    (2 'change-log-name)
-		    (3 'change-log-date)
-		    (4 'change-log-list))))
+	   '(("^ +\\([0-9]+\\) \\(.*?\\)[ \t]+\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\}\\)\\( \\[merge\\]\\)?"
+              (1 'log-view-message-face)
+              (2 'change-log-name)
+              (3 'change-log-date)
+              (4 'change-log-list nil lax)))
 	 (append `((,log-view-message-re . 'log-view-message-face))
 		 ;; log-view-font-lock-keywords
 		 '(("^ *committer: \
@@ -481,7 +481,7 @@ REV non-nil gets an error."
 		    (2 'change-log-email))
 		   ("^ *timestamp: \\(.*\\)" (1 'change-log-date-face)))))))
 
-(defun vc-bzr-print-log (files buffer &optional shortlog limit)
+(defun vc-bzr-print-log (files buffer &optional shortlog limit start-revision)
   "Get bzr change log for FILES into specified BUFFER."
   ;; `vc-do-command' creates the buffer, but we need it before running
   ;; the command.
@@ -495,6 +495,7 @@ REV non-nil gets an error."
     (apply 'vc-bzr-command "log" buffer 'async files
 	   (append
 	    (when shortlog '("--short"))
+	    (when start-revision (list (format "-r..%s" start-revision)))
 	    (when limit (list "-l" (format "%s" limit)))
 	    (if (stringp vc-bzr-log-switches)
 		(list vc-bzr-log-switches)
@@ -504,7 +505,8 @@ REV non-nil gets an error."
   "Find entry for patch name REVISION in bzr change log buffer."
   (goto-char (point-min))
   (when revision
-    (let (case-fold-search)
+    (let (case-fold-search
+	  found)
       (if (re-search-forward
 	   ;; "revno:" can appear either at the beginning of a line,
 	   ;; or indented.
@@ -512,8 +514,11 @@ REV non-nil gets an error."
 		   ;; The revision can contain ".", quote it so that it
 		   ;; does not interfere with regexp matching.
 		   (regexp-quote revision) "$") nil t)
-	  (beginning-of-line 0)
-	(goto-char (point-min))))))
+	  (progn
+	    (beginning-of-line 0)
+	    (setq found t))
+	(goto-char (point-min)))
+      found)))
 
 (defun vc-bzr-diff (files &optional rev1 rev2 buffer)
   "VC bzr backend for diff."
Index: vc-hg.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-hg.el,v
retrieving revision 1.107
diff -u -3 -p -r1.107 vc-hg.el
--- vc-hg.el	18 Nov 2009 19:12:26 -0000	1.107
+++ vc-hg.el	6 Dec 2009 17:36:53 -0000
@@ -219,7 +223,7 @@ If nil, use the value of `vc-diff-switch
                  (repeat :tag "Argument List" :value ("") string))
   :group 'vc-hg)
 
-(defun vc-hg-print-log (files buffer &optional shortlog limit)
+(defun vc-hg-print-log (files buffer &optional shortlog limit start-revision)
   "Get change log associated with FILES."
   ;; `vc-do-command' creates the buffer, but we need it before running
   ;; the command.
@@ -231,6 +235,7 @@ If nil, use the value of `vc-diff-switch
 	buffer
       (apply 'vc-hg-command buffer 0 files "log"
 	     (append
+	      (when start-revision (list (format "-r%s:" start-revision)))
 	      (when limit (list "-l" (format "%s" limit)))
 	      (when shortlog '("--style" "compact"))
 	      vc-hg-log-switches)))))

Re: limit the number of log entries displayed by C-x v l

[Stefan Monnier]

> This patch does that.
> OK?

Look OK, just one nit:

> -;; * print-log (files buffer &optional shortlog limit)
> +;; * print-log (files buffer &optional shortlog limit start-revision)

Seen from here, it would make sense to have 

   print-log (files buffer &optional shortlog start-rev end-rev)

instead.  Now admittedly, `end-rev' will often/usually not be known, but
we could allow it to be an integer rather than a string, in order to
specify the number of revisions to show.

That might also make it easier to move to

    incoming = (print-log files buf short 'working-revision 'upstream)
and
    outgoing = (print-log files buf short 'upstream 'working-revision)

In any case, what it means in the short term is to use

   print-log (files buffer &optional shortlog start-revision limit)


-- Stefan

Re: limit the number of log entries displayed by C-x v l

[Giorgos Keramidas]

On Thu, 12 Nov 2009 18:21:56 -0800 (PST), Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > > Logs for some big trees can be huge, the Linux one is millions of lines.
> >
> > Yes, this is a fairly serious problem.  We need to refine the
> > `print-log' backend op to be able to control it somehow. [...]
> > Maybe we should show just the first thousand or so by default and then
> > provide a button (and command) in log-view-mode to get more?
>
> That could work.
> It would work with the proposed backend change.
>
> C-x v l call would call the backend to show vc-log-show-entries, then
> the button would get the revision id for the last entry in the buffer,
> and it would then call the backend starting from that revision to
> request more entries.

I think this is a good idea :D

This is what Tortoise-Hg does by default for Mercurial clones, and it
seems to help a lot with clones that have many thousand changes.  By
limiting the changes to a shorter, one line per changeset output, it is
easy to see how displaying everything by default may slow things down.

I have a Mercurial clone converted from the current Git repository on my
laptop.  Showing around 300 changes completes in less than a second, but
anything over 30000 changes is noticeably slow:

: keramida@kobe:/hg/emacs/gnu$ hg short -l3
: 102087 67289587a4fe | 2009-11-10 00:54:45 +0000 | juri: (read-file-name): Support a list of default values
: 102086 5ee7a01ed6e0 | 2009-11-10 00:07:41 +0000 | lekktu: Fix typos.
: 102085 624cc4a874eb | 2009-11-09 22:15:41 +0000 | michael: *** empty log message ***
: keramida@kobe:/hg/emacs/gnu$ time hg short -l3 > /dev/null
:         0.572 real      0.326 user      0.244 sys
: keramida@kobe:/hg/emacs/gnu$ time hg short -l300 > /dev/null
:         0.742 real      0.439 user      0.301 sys
: keramida@kobe:/hg/emacs/gnu$ time hg short -l3000 > /dev/null
:         1.817 real      1.523 user      0.288 sys
: keramida@kobe:/hg/emacs/gnu$ time hg short -l30000 > /dev/null
:         13.802 real     12.692 user     0.412 sys

I think that we can display the last 300-500 commits reasonably fast,
and add a few button at the start and end of the log-view buffer.  Maybe
something like this would do?

    [Previous 500] [Previous 1000] [Previous 5000] [All]

    changeset:   637:4364dceabece
    user:        Giorgos Keramidas <keramida@ceid.upatras.gr>
    date:        Sun Jul 12 06:58:02 2009 +0300
    summary:     bash: make 'sbcl --noinform' my default sbcl startup mode

    changeset:   592:0ac83b70787e
    user:        Giorgos Keramidas <keramida@ceid.upatras.gr>
    date:        Tue Jun 23 22:11:39 2009 +0300
    summary:     tortoise-hg: forking is now tunable through hgrc(5)

    changeset:   572:bca0dfd0bd27
    user:        Giorgos Keramidas <keramida@ceid.upatras.gr>
    date:        Sun Jun 21 03:19:02 2009 +0300
    summary:     bash: add a bit of color to my default shell prompt

    [Next 500] [Next 1000] [Next 5000] [All]

Re: limit the number of log entries displayed by C-x v l

[Alfred M. Szmidt]

I love the idea of this feature, but I find commands that ask many
questions very annoying, specifying the number of lines interactivly
isn't that useful anyway since it is not something you do very often.

A nicer approach would to add a `forward' key binding when browsing
vc-log output, so by default you get N entries, if you hit M-v when
being at the last page, you get N additional entries.  And then
specify the default number of lines using a global variable.  

C-s could also be extended in a similar way so that you can do
searches beyond the inital number of lines shown by hitting C-s
repeatedly.

Re: limit the number of log entries displayed by C-x v l

[Richard Stallman]

How about making C-x v l asynchronous like C-x v =?

Re: limit the number of log entries displayed by C-x v l

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> How about making C-x v l asynchronous like C-x v =?

It is aready.  Only asynchronous mode setup is missing.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: limit the number of log entries displayed by C-x v l

[Richard Stallman]

    > How about making C-x v l asynchronous like C-x v =?

    It is aready.  Only asynchronous mode setup is missing.

What does it mean for asynchronous mode setup to be missing?

Anyway, if it is already asyncronous, why propose commands to see more
of the output, search thru the next batch of the output, etc.?  What
is the avance of limiting the amount of data shown if all that does is
turn off asynchronous filling of the rest of the buffer?

By the way, the doc strings do not say that these commands are
asynchronous.

Re: limit the number of log entries displayed by C-x v l

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     > How about making C-x v l asynchronous like C-x v =?
>
>     It is aready.  Only asynchronous mode setup is missing.
>
> What does it mean for asynchronous mode setup to be missing?

The mode setup happens only after the output is complete.

> Anyway, if it is already asyncronous, why propose commands to see more
> of the output, search thru the next batch of the output, etc.?

As long as the output is incomplete the buffer is in fundamental mode,
so none of the log-view commands work yet.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: limit the number of log entries displayed by C-x v l

[Richard Stallman]

    The mode setup happens only after the output is complete.

I see.  Could someone fix it to set up the mode at the outset?