all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: 35624@debbugs.gnu.org
Subject: bug#35624: log-view-diff regression
Date: Tue, 21 May 2019 23:39:28 +0300	[thread overview]
Message-ID: <e4161343-d31f-2286-53e3-060c51cc8353@yandex.ru> (raw)
In-Reply-To: <87lfyzy3c1.fsf@mail.linkov.net>

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.





  reply	other threads:[~2019-05-21 20:39 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-07 21:56 bug#35624: log-view-diff regression Juri Linkov
2019-05-07 22:54 ` Dmitry Gutov
2019-05-08 19:52   ` Juri Linkov
2019-05-09 13:26     ` Dmitry Gutov
2019-05-09 19:41       ` Juri Linkov
2019-05-10  0:14         ` Dmitry Gutov
2019-05-10  7:56           ` Eli Zaretskii
2019-05-11 20:58           ` Juri Linkov
2019-05-13  0:32             ` Dmitry Gutov
2019-05-13 20:40               ` Juri Linkov
2019-05-13 21:21                 ` Dmitry Gutov
2019-05-14 20:29                   ` Juri Linkov
2019-05-15  0:34                     ` Dmitry Gutov
2019-05-15 21:12                       ` Juri Linkov
2019-05-15 22:05                         ` Dmitry Gutov
2019-05-16 20:04                           ` Juri Linkov
2019-05-19 20:11                             ` Juri Linkov
2019-05-20 23:29                               ` Dmitry Gutov
2019-05-21 20:12                                 ` Juri Linkov
2019-05-21 20:39                                   ` Dmitry Gutov [this message]
2019-05-21 21:32                                     ` Juri Linkov
2019-05-21 21:52                                       ` Dmitry Gutov
2019-05-22 21:52                                         ` Dmitry Gutov
2019-05-23 21:07                                         ` Juri Linkov
2019-05-24  1:29                                           ` Dmitry Gutov
2019-05-24 18:41                                             ` Juri Linkov
2019-05-27 15:26                                               ` Dmitry Gutov
2019-05-27 19:47                                                 ` Juri Linkov
2019-06-10  0:57                                                   ` Dmitry Gutov
2019-06-10 20:50                                                     ` Juri Linkov
2019-06-10 22:19                                                       ` Dmitry Gutov
2019-06-16  0:55                                                   ` Dmitry Gutov
2019-06-16 20:13                                                     ` Juri Linkov
2019-06-17 13:48                                                       ` Dmitry Gutov
2019-06-17 20:42                                                         ` Juri Linkov
2019-06-17 22:23                                                           ` Dmitry Gutov
2019-05-20 23:39                             ` Dmitry Gutov
2019-05-10  7:54     ` Eli Zaretskii
2019-05-08  6:01 ` Eli Zaretskii
2019-05-08 19:52   ` Juri Linkov
2019-05-10  7:51     ` Eli Zaretskii
2019-05-11 20:53       ` Juri Linkov
2019-05-12  2:36         ` Eli Zaretskii
2019-05-12 19:15           ` Juri Linkov
2019-05-13 14:24             ` Eli Zaretskii
2019-05-13 14:44               ` Dmitry Gutov
2019-05-13 15:09                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e4161343-d31f-2286-53e3-060c51cc8353@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=35624@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.