GNU bug report logs - #35624
log-view-diff regression

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 7 May 2019 22:02:02 UTC

Severity: normal

Tags: patch

Found in version 26.1

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 35624 <at> debbugs.gnu.org
Subject: bug#35624: log-view-diff regression
Date: Tue, 21 May 2019 23:39:28 +0300
On 21.05.2019 23:12, Juri Linkov wrote:
>> One alternative which I have already mentioned is to make a different
>> command handle this. E.g. 'C-u d' might diff workfile and the revision at
>> point. This actually seems faster that go to bob and create the
>> necessary region.
> 
> This is not self-evident and not WYSIWYG as the visual region selection is.

If showing diffs was the main purpose of the log buffer, I might agree 
with you.

Okay, it's not self-evident, but going above the first visible line is 
not self-evident either. For instance, most users would never on purpose 
try C-p instead of p to get to the line before the first revision, 
especially if it's 1-pixel tall like your last patch did.

Not to mention that most users would not simply think to create an 
active region before pressing 'd'.

>> For the main purpose of the log buffer, the empty first line is weird
>> (saying "working revision" would be just as weird).
> 
> vc-rcs and vc-cvs inserts 12-lines long header in the log buffer
> and no one complained for several decades :)

Guess that's because those lines show something remotely helpful and 
pertinent to the main purpose of the buffer.

> OTOH, when recently Android developers changed the position of the clock
> from the right side of the screen to the left, billions of users silently
> adapted their habits to the new position without protests :(

We're talking about adding a banana to a clock hand.

>> I could maybe live with it if were 1-character tall (and in a terminal,
>> maybe invisible until you move point to it)
> 
> It's already 1-character tall.
> 
> But it you meant 1-pixel tall, then I agree it's a good idea
> (like 1-pixel line is already used in log-edit.el):

Yes, that's what I meant, sorry.

> diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
> index b6feb3b8d1..238b04929b 100644
> --- a/lisp/vc/vc-git.el
> +++ b/lisp/vc/vc-git.el
> @@ -1018,7 +1018,7 @@ vc-git-print-log
>       ;; read-only.
>       (let ((inhibit-read-only t))
>         (with-current-buffer buffer
> -	(insert "\n")
> +	(insert (propertize "\n" 'font-lock-face '(:height 0.1)))
>   	(apply 'vc-git-command buffer
>   	       'async files
>   	       (append

It's better, but a) it shifts the buffer text by 1 pixel, which I 
actually find annoying now that I look at the bottom entry that fits in 
that window, b) from your side, it should look suboptimal as well, 
because the cursor is basically invisible when it's on the top line 
(speaking of WYSIWYG).

If you really must have it this way, do we have an example of invisible 
text expanding when cursor moves inside, and then contracting when it's 
out again? Meaning if would look like an empty line you wanted after you 
press 'C-p', but not visible at all otherwise.




This bug report was last modified 5 years and 336 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.