All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.org>
To: Dragan Simic <dsimic@manjaro.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: why does git set X in LESS env var?
Date: Thu, 12 Oct 2023 02:22:49 +0200	[thread overview]
Message-ID: <8f3bec2752f4c2d3ebdd29d20910a4a94f75f608.camel@scientia.org> (raw)
In-Reply-To: <ace230a469fabbbbceb38cc884a40b4c@manjaro.org>

On Thu, 2023-10-12 at 02:06 +0200, Dragan Simic wrote:
> There's also scrollback in the terminal, which can be used to show
> more 
> of the contents that was displayed before exiting the pager.

Sure.


> > Everything that would have come after that is of course not
> > visible.
> > The place where I exited may be some "well defined" border, like
> > the
> > end of a commit... or anywhere it the middle of a patch (making the
> > left over remains on the terminal perhaps even ambiguous).
> 
> If you didn't select some line or page to be displayed, by scrolling 
> within the pager, it obviously isn't going to be displayed, which is
> the 
> whole point of using a pager instead of "spitting" the whole contents
> out at once.

It's also clear that it's one point of a pager :-)

But that doesn't change that it's rather a user decision, whether or
not it makes sense to leave that, what's already been shown by the
pager, on the terminal after exiting the pager or not.

I don't think people always select the lines in the pager to some
reasonable border (e.g. end of a commit, end of a hunk, whatever).
So it's likely that after leaving the pager, the terminal's scrollback
buffer will contain something that is not complete and may thus be
ambiguous.


> 
> That sounds like some issue with your terminal or terminal emulator, 
> which should be debugged and fixed separately.  Such misbehavior
> isn't 
> supposed to happen at all.

Are you sure about that?

Well it happens at least in gnome-terminal, xterm and (KDE) konsole.


> I see.  Actually, removing "-S" was a good decision, IMHO, because 
> chopping long lines isn't something that a sane set of defaults
> should 
> do.  Many users would probably be confused with the need to use the 
> right arrow to see long lines in their entirety.

Sure.

And having -F is IMO a good default (that virtually everyone would
want), too.

With respect to -X, I'm less sure whether it's that clear.


Cheers,
Chris.


  reply	other threads:[~2023-10-12  0:23 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-11 22:19 why does git set X in LESS env var? Christoph Anton Mitterer
2023-10-11 22:23 ` Junio C Hamano
2023-10-11 22:26   ` Christoph Anton Mitterer
2023-10-11 22:51     ` Dragan Simic
2023-10-11 23:16       ` Christoph Anton Mitterer
2023-10-11 23:29         ` Dragan Simic
2023-10-11 23:43           ` Christoph Anton Mitterer
2023-10-12  0:06             ` Dragan Simic
2023-10-12  0:22               ` Christoph Anton Mitterer [this message]
2023-10-12  0:31                 ` Dragan Simic
2023-10-12  1:39                   ` Christoph Anton Mitterer
2023-10-12  5:46                     ` Dragan Simic
2023-10-12 20:23                       ` Christoph Anton Mitterer
2023-10-12 21:15                         ` Dragan Simic
2023-10-12 21:48                           ` Christoph Anton Mitterer
2023-10-12 22:36                             ` Dragan Simic
2023-10-12 23:06                               ` Christoph Anton Mitterer
2023-10-13  4:43                                 ` Dragan Simic
2023-10-13 13:45                                   ` Christoph Anton Mitterer
2023-10-13 15:00                                     ` Dragan Simic
2023-10-12  0:04   ` Jeff King
2023-10-12  0:16     ` Dragan Simic
2023-10-12  1:39     ` Junio C Hamano
2023-10-12  5:30       ` Dragan Simic
2023-10-12 16:19         ` Junio C Hamano
2023-10-13 20:12           ` Dragan Simic
     [not found]             ` <cfbe174f-23ac-4a35-8db4-66bdfdfdc14e@gmail.com>
2023-11-02  6:01               ` Thomas Guyot
2023-11-02  6:14                 ` Dragan Simic
2023-11-02  6:48               ` Dragan Simic
2023-11-02 13:19                 ` Thomas Guyot
2023-11-02 14:19                   ` Dragan Simic
2023-11-03 11:47                     ` Thomas Guyot
2023-11-03 15:28                       ` Andy Koppe
2023-11-03 18:38                         ` Dragan Simic
2023-11-03 18:22                       ` Dragan Simic
2023-11-06  3:47                     ` Dragan Simic
2024-03-21 15:53                       ` Dragan Simic
2023-10-12  3:54     ` Christoph Anton Mitterer
2023-10-12  5:57       ` Dragan Simic

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=8f3bec2752f4c2d3ebdd29d20910a4a94f75f608.camel@scientia.org \
    --to=calestyo@scientia.org \
    --cc=dsimic@manjaro.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.
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.