{"thread":{"id":"60346","subject":"why does git set X in LESS env var?","startedAt":"2023-10-11T22:19:54Z","lastAt":"2024-03-21T15:53:18Z","messageCount":39,"participants":["Christoph Anton Mitterer","Junio C Hamano","Dragan Simic","Jeff King","Thomas Guyot","Andy Koppe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"483098","messageId":"3a2c362c019338ca7408b7a3bc5715b535d15b8a.camel@scientia.org","threadId":"60346","inReplyTo":null,"subject":"why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-11T22:19:40Z","receivedAt":"2023-10-11T22:19:54Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"Hey.\n\n\nI recently stumbled over the problem that mouse wheel scrolling doesn't\nwork with (git-)delta[0], a problem[1][2], which apparently numerous\npeople had before me.\n\nNumerous solutions were given in [1] and [2], for example using --mouse\nas less option.\nI noticed however, that this causes a somewhat different mouse\nscrolling behaviour than my less usually gives me and dug a bit\nfurther, noticing that the problem was that `X` was set in the `LESS`\nenv var for the less process, wrongly assuming[3] first that delta\nwould set it.\n\nAfter delta's upstream noticed that this must be wrong, I looked\nfurther and found that git set it since commit\n0abc0260fa3419de649fcc1444e3d256a17ca6c7, which gives however no\nindication why it was added.\n\nA somewhat later commit, b3275838d969b7ecb91aae584226fccbeb046aca,\nwhich removes `S` from being set, mentions:\n> … The FRX flags actually make sense for Git (F and X because\n> sometimes the output Git pipes to less is short, and R because Git\n> pipes colored output).\n\nBut I still don't get from that why X would be needed?\n\nMy less manpage documents it as:\n> -X or --no‐init\n>     Disables sending the termcap initialization and deinitialization\n>     strings to the terminal.  This is sometimes desirable if the\n>     deinitialization string does something unnecessary, like clearing\n>     the screen.\n\nIs it to avoid clearing the screen?\n\n\nNot sure whether git should really do something here... I mean it could\nadd --mouse per default, but then users who don't want that would need\nto work around it (and there is no negative option for --mouse, it\nseems).\n\n\nOh, I should add that scrolling without `X` and without `--mouse` sees\nto only work on some terminals (e.g. VTE based ones, but not xterm).\n\nThanks,\nChris.\n\n\n[0] https://github.com/dandavison/delta/\n[1] https://github.com/dandavison/delta/issues/58\n[2] https://github.com/dandavison/delta/issues/630\n[3] https://github.com/dandavison/delta/issues/58#issuecomment-1756542986\n"},{"id":"483099","messageId":"xmqqa5sokdd3.fsf@gitster.g","threadId":"60346","inReplyTo":"3a2c362c019338ca7408b7a3bc5715b535d15b8a.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-11T22:23:20Z","receivedAt":"2023-10-11T22:23:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christoph Anton Mitterer <calestyo@scientia.org> writes:\n\n> But I still don't get from that why X would be needed?\n>\n> My less manpage documents it as:\n>> -X or --no‐init\n>>     Disables sending the termcap initialization and deinitialization\n>>     strings to the terminal.  This is sometimes desirable if the\n>>     deinitialization string does something unnecessary, like clearing\n>>     the screen.\n>\n> Is it to avoid clearing the screen?\n\nI think that was the reason we added it back in 2005.  In any case,\nasking \"why\" is not a useful use of anybody's time, because it is\nvery unlikely to change in the official version we ship, and because\nit is so easy for any individual who does not like it to drop by\nexporting the $LESS environment variable.\n\nThanks.\n"},{"id":"483100","messageId":"0c10c4b95f2a947a5d569a2c3d51fcb02b35e81d.camel@scientia.org","threadId":"60346","inReplyTo":"xmqqa5sokdd3.fsf@gitster.g","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-11T22:26:52Z","receivedAt":"2023-10-11T22:27:03Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Wed, 2023-10-11 at 15:23 -0700, Junio C Hamano wrote:\n> I think that was the reason we added it back in 2005.  In any case,\n> asking \"why\" is not a useful use of anybody's time, because it is\n> very unlikely to change in the official version we ship, and because\n> it is so easy for any individual who does not like it to drop by\n> exporting the $LESS environment variable.\n\n\nWell the other commit I've mentioned kinda read as if it was thought\nthat either X or both F and X were needed for the effect to exit less\nimmediately if the output is too short (\"F and X because\n> sometimes the output Git pipes to less is short\").\n\nSo I thought maybe that was intended, and the no-clear was just a side-\neffect no one ever really thought about.\n\n\nAnyway, thanks,\nChris.\n"},{"id":"483108","messageId":"eadc03fc56d530ea31790f8a4b47a16e@manjaro.org","threadId":"60346","inReplyTo":"0c10c4b95f2a947a5d569a2c3d51fcb02b35e81d.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-11T22:51:48Z","receivedAt":"2023-10-11T22:51:54Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 00:26, Christoph Anton Mitterer wrote:\n> On Wed, 2023-10-11 at 15:23 -0700, Junio C Hamano wrote:\n>> I think that was the reason we added it back in 2005.  In any case,\n>> asking \"why\" is not a useful use of anybody's time, because it is\n>> very unlikely to change in the official version we ship, and because\n>> it is so easy for any individual who does not like it to drop by\n>> exporting the $LESS environment variable.\n> \n> Well the other commit I've mentioned kinda read as if it was thought\n> that either X or both F and X were needed for the effect to exit less\n> immediately if the output is too short (\"F and X because\n> sometimes the output Git pipes to less is short\").\n\nIn general, not clearing the screen (i.e. \"-X\") is there so the \ndisplayed contents is still visible in the terminal after exiting the \npager.  That wouldn't be the case if the screen was cleared, making it \nless usable for most users.\n\nExiting if less contents than one full screen was displayed (i.e. \"-F\") \nis there to save people from the frustration of quitting a pager that \nactually wasn't needed to be executed.\n\nWhen it comes to \"-R\", it has to be there, otherwise no coloring of the \npaginated output could be possible.\n\n> So I thought maybe that was intended, and the no-clear was just a side-\n> effect no one ever really thought about.\n> \n> \n> Anyway, thanks,\n> Chris.\n"},{"id":"483116","messageId":"ec43820562198de078db7df54d0338edf1f333ea.camel@scientia.org","threadId":"60346","inReplyTo":"eadc03fc56d530ea31790f8a4b47a16e@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-11T23:16:22Z","receivedAt":"2023-10-11T23:23:10Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Thu, 2023-10-12 at 00:51 +0200, Dragan Simic wrote:\n> In general, not clearing the screen (i.e. \"-X\") is there so the \n> displayed contents is still visible in the terminal after exiting the\n> pager.  That wouldn't be the case if the screen was cleared, making\n> it \n> less usable for most users.\n\nWell, I personally, also prefer it that way... but I'd also say that\njust like in the case of `S`, this is not really needed from the git\nside, but rather simply a user choice.\n\nAnd since, if the output did not fit one one screen, the non-cleared\nremains may likely be chopped off,... one could argue that some users\nwould actually prefer to have it cleared.\n\n\n> Exiting if less contents than one full screen was displayed (i.e. \"-\n> F\") \n> is there to save people from the frustration of quitting a pager that\n> actually wasn't needed to be executed.\n\nSame actually here, at least strictly speaking, ... though I (and\nprobably everybody else?) would really hate it, if that was removed. ^^\n\n\nAnyway... that's no request from my side to change the default. I just\nwanted to know whether that don't-clear-the-screen part was the\nmotivation for the `X`.\n\n\nIn case someone cares, I've asked less upstream whether there's a way\nto have VTE scrolling work with -X:\nhttps://github.com/gwsw/less/issues/445\n\n\nThanks,\nChris.\n"},{"id":"483118","messageId":"6457310b8ca0e7d3b288a3bbbe264012@manjaro.org","threadId":"60346","inReplyTo":"ec43820562198de078db7df54d0338edf1f333ea.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-11T23:29:41Z","receivedAt":"2023-10-11T23:29:46Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 01:16, Christoph Anton Mitterer wrote:\n> On Thu, 2023-10-12 at 00:51 +0200, Dragan Simic wrote:\n>> In general, not clearing the screen (i.e. \"-X\") is there so the\n>> displayed contents is still visible in the terminal after exiting the\n>> pager.  That wouldn't be the case if the screen was cleared, making\n>> it\n>> less usable for most users.\n> \n> Well, I personally, also prefer it that way... but I'd also say that\n> just like in the case of `S`, this is not really needed from the git\n> side, but rather simply a user choice.\n\nIt's about providing a set of sane defaults for less(1), which other \nutilities also do, including dmesg, for example.  Of course, everyone \ncan set $PAGER or $GIT_PAGER to fit their own prereferences.\n\n> And since, if the output did not fit one one screen, the non-cleared\n> remains may likely be chopped off,... one could argue that some users\n> would actually prefer to have it cleared.\n\nI'm not sure what do you mean by the non-cleared remains being chopped \noff...  Could you clarify that a bit, please?\n\nAs I already mentioned above, everyone is free to configure the pager \nbehavior in any way they like.\n\n>> Exiting if less contents than one full screen was displayed (i.e. \"-\n>> F\")\n>> is there to save people from the frustration of quitting a pager that\n>> actually wasn't needed to be executed.\n> \n> Same actually here, at least strictly speaking, ... though I (and\n> probably everybody else?) would really hate it, if that was removed. ^^\n\nI'm afraid that I don't understand very well are you complaining about \nthe presence of \"-F\" or not?\n\n> Anyway... that's no request from my side to change the default. I just\n> wanted to know whether that don't-clear-the-screen part was the\n> motivation for the `X`.\n\nAFAIK, there should be no motivation other than not clearing the screen. \n  Other utilities that invoke the pager internally configure the default \npager options in a very similar way.\n\n> In case someone cares, I've asked less upstream whether there's a way\n> to have VTE scrolling work with -X:\n> https://github.com/gwsw/less/issues/445\n\nQuite frankly, I can't stand scrolling in less(1) using the mouse wheel, \nbut I do understand why some people like it.\n"},{"id":"483122","messageId":"fbb3c2bf1c832f0f16cb913da6b862dd313359ef.camel@scientia.org","threadId":"60346","inReplyTo":"6457310b8ca0e7d3b288a3bbbe264012@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-11T23:43:54Z","receivedAt":"2023-10-11T23:44:06Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Thu, 2023-10-12 at 01:29 +0200, Dragan Simic wrote:\n> I'm not sure what do you mean by the non-cleared remains being\n> chopped \n> off...  Could you clarify that a bit, please?\n\nWell if I do say:\n$ reset\n$ git diff HEAD~10\n\nand from there scroll down a bit and then q to exit less (and the\nscreen is not cleared), I see the output only so far as I've had\npreviously scrolled down in less.\n\nEverything that would have come after that is of course not visible.\nThe place where I exited may be some \"well defined\" border, like the\nend of a commit... or anywhere it the middle of a patch (making the\nleft over remains on the terminal perhaps even ambiguous).\n\nWhat's worse, when (in less) I scroll down and up again, perhaps\nrepeating several times, and then quit... I see (at least in my\nless/terminal combination) things twice and mangled up (i.e. when I\nscroll up the terminal (outside of less)).\n\nSo AFAICS, not clearing the screen only works properly when never\nscrolling up again (in less).\n\n\n> As I already mentioned above, everyone is free to configure the pager\n> behavior in any way they like.\n\nSure :-)\n\n> \n> > > Exiting if less contents than one full screen was displayed (i.e.\n> > > \"-\n> > > F\")\n> > > is there to save people from the frustration of quitting a pager\n> > > that\n> > > actually wasn't needed to be executed.\n> > \n> > Same actually here, at least strictly speaking, ... though I (and\n> > probably everybody else?) would really hate it, if that was\n> > removed. ^^\n> \n> I'm afraid that I don't understand very well are you complaining\n> about \n> the presence of \"-F\" or not?\n\nNo :-) As I've said, I like it that way and I and probably everyone\nelse would be annoyed, if -F was not present.\n\nI just meant that strictly speaking the same reason why \"S\" was\nremoved, could be applied to \"F\" as well.\n\nIt is - like -R - not necessary for less to work with git.\n\nBut it is, of course, what virtually everyone will want in practise.\n\n\n> Quite frankly, I can't stand scrolling in less(1) using the mouse\n> wheel, \n> but I do understand why some people like it.\n\nThe main reason I want it is, that things don't get messy, when I\nforget being in less and mouse scroll. ;-)\n\n\nThanks,\nChris.\n"},{"id":"483123","messageId":"20231012000416.GA520855@coredump.intra.peff.net","threadId":"60346","inReplyTo":"xmqqa5sokdd3.fsf@gitster.g","subject":"Re: why does git set X in LESS env var?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-10-12T00:04:16Z","receivedAt":"2023-10-12T00:04:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 11, 2023 at 03:23:20PM -0700, Junio C Hamano wrote:\n\n> Christoph Anton Mitterer <calestyo@scientia.org> writes:\n> \n> > But I still don't get from that why X would be needed?\n> >\n> > My less manpage documents it as:\n> >> -X or --no‐init\n> >>     Disables sending the termcap initialization and deinitialization\n> >>     strings to the terminal.  This is sometimes desirable if the\n> >>     deinitialization string does something unnecessary, like clearing\n> >>     the screen.\n> >\n> > Is it to avoid clearing the screen?\n> \n> I think that was the reason we added it back in 2005.  In any case,\n> asking \"why\" is not a useful use of anybody's time, because it is\n> very unlikely to change in the official version we ship, and because\n> it is so easy for any individual who does not like it to drop by\n> exporting the $LESS environment variable.\n\nI agree it is probably not worth changing now, but I think the history\nhere is a little interesting.\n\nYes, I think \"X\" was added because less would clear the screen after\nexiting, and with \"F\" this meant you'd see nothing. Here's a thread from\nthe same time period discussing it:\n\n  https://lore.kernel.org/git/cc723f590610210623sbee2075i5f2fd441cceb84ae@mail.gmail.com/\n\nBut I also think this was a pretty well-known annoyance with \"less\" back\nthen.\n\nHowever, I can't seem to reproduce it now! Digging into the history and\nthe changelog, this note is in \"changes between less versions 487 and\n530\":\n\n  Don't output terminal init sequence if using -F and file fits on one\n  screen.\n\nSo it seems like the problem has been fixed inside less for recent\nversions. And in theory we _could_ drop \"-X\" if it is causing problems.\nThat version of less is ~5 years old. It does seem a little premature to\nassume everybody has it. And as you say, if there are people who really\ncare about their LESS options, it is easy for them to override it.\n\n-Peff\n"},{"id":"483124","messageId":"ace230a469fabbbbceb38cc884a40b4c@manjaro.org","threadId":"60346","inReplyTo":"fbb3c2bf1c832f0f16cb913da6b862dd313359ef.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-12T00:06:56Z","receivedAt":"2023-10-12T00:07:00Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 01:43, Christoph Anton Mitterer wrote:\n> On Thu, 2023-10-12 at 01:29 +0200, Dragan Simic wrote:\n>> I'm not sure what do you mean by the non-cleared remains being\n>> chopped\n>> off...  Could you clarify that a bit, please?\n> \n> Well if I do say:\n> $ reset\n> $ git diff HEAD~10\n> \n> and from there scroll down a bit and then q to exit less (and the\n> screen is not cleared), I see the output only so far as I've had\n> previously scrolled down in less.\n\nThere's also scrollback in the terminal, which can be used to show more \nof the contents that was displayed before exiting the pager.\n\n> Everything that would have come after that is of course not visible.\n> The place where I exited may be some \"well defined\" border, like the\n> end of a commit... or anywhere it the middle of a patch (making the\n> left over remains on the terminal perhaps even ambiguous).\n\nIf you didn't select some line or page to be displayed, by scrolling \nwithin the pager, it obviously isn't going to be displayed, which is the \nwhole point of using a pager instead of \"spitting\" the whole contents \nout at once.\n\nWhere and when you exit the pager is up to you only, and you can decide \nwhat will be left on the screen at that point.\n\n> What's worse, when (in less) I scroll down and up again, perhaps\n> repeating several times, and then quit... I see (at least in my\n> less/terminal combination) things twice and mangled up (i.e. when I\n> scroll up the terminal (outside of less)).\n\nThat sounds like some issue with your terminal or terminal emulator, \nwhich should be debugged and fixed separately.  Such misbehavior isn't \nsupposed to happen at all.\n\n> So AFAICS, not clearing the screen only works properly when never\n> scrolling up again (in less).\n\nIt works just fine for me, for example.  You're obviously having some \nunrelated issues with your terminal emulator.\n\n>> As I already mentioned above, everyone is free to configure the pager\n>> behavior in any way they like.\n> \n> Sure :-)\n> \n>> \n>> > > Exiting if less contents than one full screen was displayed (i.e.\n>> > > \"-\n>> > > F\")\n>> > > is there to save people from the frustration of quitting a pager\n>> > > that\n>> > > actually wasn't needed to be executed.\n>> >\n>> > Same actually here, at least strictly speaking, ... though I (and\n>> > probably everybody else?) would really hate it, if that was\n>> > removed. ^^\n>> \n>> I'm afraid that I don't understand very well are you complaining\n>> about\n>> the presence of \"-F\" or not?\n> \n> No :-) As I've said, I like it that way and I and probably everyone\n> else would be annoyed, if -F was not present.\n> \n> I just meant that strictly speaking the same reason why \"S\" was\n> removed, could be applied to \"F\" as well.\n\nI see.  Actually, removing \"-S\" was a good decision, IMHO, because \nchopping long lines isn't something that a sane set of defaults should \ndo.  Many users would probably be confused with the need to use the \nright arrow to see long lines in their entirety.\n\n> It is - like -R - not necessary for less to work with git.\n> \n> But it is, of course, what virtually everyone will want in practise.\n\nWell, \"-R\" is pretty much mandatory, because coloring the outputs has \nbecome some kind of defacto standard, and it's very useful when viewing \ndiffs, for example.\n\n>> Quite frankly, I can't stand scrolling in less(1) using the mouse\n>> wheel,\n>> but I do understand why some people like it.\n> \n> The main reason I want it is, that things don't get messy, when I\n> forget being in less and mouse scroll. ;-)\n> \n> \n> Thanks,\n> Chris.\n"},{"id":"483125","messageId":"e1023bd04f9f45b25caf254a7c2885fd@manjaro.org","threadId":"60346","inReplyTo":"20231012000416.GA520855@coredump.intra.peff.net","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-12T00:16:36Z","receivedAt":"2023-10-12T00:16:42Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 02:04, Jeff King wrote:\n> On Wed, Oct 11, 2023 at 03:23:20PM -0700, Junio C Hamano wrote:\n> \n>> Christoph Anton Mitterer <calestyo@scientia.org> writes:\n>> \n>> > But I still don't get from that why X would be needed?\n>> >\n>> > My less manpage documents it as:\n>> >> -X or --no‐init\n>> >>     Disables sending the termcap initialization and deinitialization\n>> >>     strings to the terminal.  This is sometimes desirable if the\n>> >>     deinitialization string does something unnecessary, like clearing\n>> >>     the screen.\n>> >\n>> > Is it to avoid clearing the screen?\n>> \n>> I think that was the reason we added it back in 2005.  In any case,\n>> asking \"why\" is not a useful use of anybody's time, because it is\n>> very unlikely to change in the official version we ship, and because\n>> it is so easy for any individual who does not like it to drop by\n>> exporting the $LESS environment variable.\n> \n> I agree it is probably not worth changing now, but I think the history\n> here is a little interesting.\n> \n> Yes, I think \"X\" was added because less would clear the screen after\n> exiting, and with \"F\" this meant you'd see nothing. Here's a thread \n> from\n> the same time period discussing it:\n> \n> \n> https://lore.kernel.org/git/cc723f590610210623sbee2075i5f2fd441cceb84ae@mail.gmail.com/\n> \n> But I also think this was a pretty well-known annoyance with \"less\" \n> back\n> then.\n> \n> However, I can't seem to reproduce it now! Digging into the history and\n> the changelog, this note is in \"changes between less versions 487 and\n> 530\":\n> \n>   Don't output terminal init sequence if using -F and file fits on one\n>   screen.\n> \n> So it seems like the problem has been fixed inside less for recent\n> versions. And in theory we _could_ drop \"-X\" if it is causing problems.\n> That version of less is ~5 years old. It does seem a little premature \n> to\n> assume everybody has it. And as you say, if there are people who really\n> care about their LESS options, it is easy for them to override it.\n\nThanks for this detailed analysis!\n\nIt's important to keep in mind that removing \"-X\" and leaving \"-F\" would \nintroduce an inconsistency in the displaying of outputs, by having the \nlong outputs disappear after exiting the pager manually, and by having \nthe short outputs remain displayed after the pager exits on its own.\n\nOn the other hand, removing both \"-X\" and \"-F\" would make people even \nmore annoyed by requiring them to exit the pager manually even for short \noutputs.\n\nQuite frankly, \"-FRX\" is a just fine set of defaults.\n"},{"id":"483126","messageId":"8f3bec2752f4c2d3ebdd29d20910a4a94f75f608.camel@scientia.org","threadId":"60346","inReplyTo":"ace230a469fabbbbceb38cc884a40b4c@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-12T00:22:49Z","receivedAt":"2023-10-12T00:23:02Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Thu, 2023-10-12 at 02:06 +0200, Dragan Simic wrote:\n> There's also scrollback in the terminal, which can be used to show\n> more \n> of the contents that was displayed before exiting the pager.\n\nSure.\n\n\n> > Everything that would have come after that is of course not\n> > visible.\n> > The place where I exited may be some \"well defined\" border, like\n> > the\n> > end of a commit... or anywhere it the middle of a patch (making the\n> > left over remains on the terminal perhaps even ambiguous).\n> \n> If you didn't select some line or page to be displayed, by scrolling \n> within the pager, it obviously isn't going to be displayed, which is\n> the \n> whole point of using a pager instead of \"spitting\" the whole contents\n> out at once.\n\nIt's also clear that it's one point of a pager :-)\n\nBut that doesn't change that it's rather a user decision, whether or\nnot it makes sense to leave that, what's already been shown by the\npager, on the terminal after exiting the pager or not.\n\nI don't think people always select the lines in the pager to some\nreasonable border (e.g. end of a commit, end of a hunk, whatever).\nSo it's likely that after leaving the pager, the terminal's scrollback\nbuffer will contain something that is not complete and may thus be\nambiguous.\n\n\n> \n> That sounds like some issue with your terminal or terminal emulator, \n> which should be debugged and fixed separately.  Such misbehavior\n> isn't \n> supposed to happen at all.\n\nAre you sure about that?\n\nWell it happens at least in gnome-terminal, xterm and (KDE) konsole.\n\n\n> I see.  Actually, removing \"-S\" was a good decision, IMHO, because \n> chopping long lines isn't something that a sane set of defaults\n> should \n> do.  Many users would probably be confused with the need to use the \n> right arrow to see long lines in their entirety.\n\nSure.\n\nAnd having -F is IMO a good default (that virtually everyone would\nwant), too.\n\nWith respect to -X, I'm less sure whether it's that clear.\n\n\nCheers,\nChris.\n\n"},{"id":"483127","messageId":"23cc509bfb433e19c7683c97314e4ac8@manjaro.org","threadId":"60346","inReplyTo":"8f3bec2752f4c2d3ebdd29d20910a4a94f75f608.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-12T00:31:39Z","receivedAt":"2023-10-12T00:31:45Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 02:22, Christoph Anton Mitterer wrote:\n> On Thu, 2023-10-12 at 02:06 +0200, Dragan Simic wrote:\n>> There's also scrollback in the terminal, which can be used to show\n>> more\n>> of the contents that was displayed before exiting the pager.\n> \n> Sure.\n> \n>> > Everything that would have come after that is of course not\n>> > visible.\n>> > The place where I exited may be some \"well defined\" border, like\n>> > the\n>> > end of a commit... or anywhere it the middle of a patch (making the\n>> > left over remains on the terminal perhaps even ambiguous).\n>> \n>> If you didn't select some line or page to be displayed, by scrolling\n>> within the pager, it obviously isn't going to be displayed, which is\n>> the\n>> whole point of using a pager instead of \"spitting\" the whole contents\n>> out at once.\n> \n> It's also clear that it's one point of a pager :-)\n> \n> But that doesn't change that it's rather a user decision, whether or\n> not it makes sense to leave that, what's already been shown by the\n> pager, on the terminal after exiting the pager or not.\n> \n> I don't think people always select the lines in the pager to some\n> reasonable border (e.g. end of a commit, end of a hunk, whatever).\n> So it's likely that after leaving the pager, the terminal's scrollback\n> buffer will contain something that is not complete and may thus be\n> ambiguous.\n\nMakes sense, but please see also my other reply on the list.  To sum it \nup, we can have either the current behavior, the inconsistent behavior, \nor an even more annoying behavior.  I believe that the current behavior \nis the best choice among these three options.\n\n>> That sounds like some issue with your terminal or terminal emulator,\n>> which should be debugged and fixed separately.  Such misbehavior\n>> isn't\n>> supposed to happen at all.\n> \n> Are you sure about that?\n> \n> Well it happens at least in gnome-terminal, xterm and (KDE) konsole.\n\nYes, I'm sure, because I'd be fixing that already if that were the case \nin my environment. :)  I use Xfce and its default terminal emulator, \nthough, and I don't know what it's like in other desktop environments \nand their terminal emulators.\n\n>> I see.  Actually, removing \"-S\" was a good decision, IMHO, because\n>> chopping long lines isn't something that a sane set of defaults\n>> should\n>> do.  Many users would probably be confused with the need to use the\n>> right arrow to see long lines in their entirety.\n> \n> Sure.\n> \n> And having -F is IMO a good default (that virtually everyone would\n> want), too.\n> \n> With respect to -X, I'm less sure whether it's that clear.\n\nPlease see my other response, which explains why having \"-FX\" is \nactually a good thing.\n"},{"id":"483128","messageId":"xmqqh6mwipqi.fsf@gitster.g","threadId":"60346","inReplyTo":"20231012000416.GA520855@coredump.intra.peff.net","subject":"Re: why does git set X in LESS env var?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-12T01:39:01Z","receivedAt":"2023-10-12T01:39:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> ... Digging into the history and\n> the changelog, this note is in \"changes between less versions 487 and\n> 530\":\n>\n>   Don't output terminal init sequence if using -F and file fits on one\n>   screen.\n\n;-)\n\nThat is really a good one to dig out.  So in short, X was needed\nbecause we wanted to use F, and we could drop it if everybody is\nusing recent versions of less, but the default to use FX at the same\ntime gives us the same behaviour between both newer and older\nversions of less.\n\n> ... And as you say, if there are people who really\n> care about their LESS options, it is easy for them to override it.\n\nYup.  I really like the discovery of that changelog entry.\n\nThanks.\n"},{"id":"483129","messageId":"2f3ef5568ed19ac5bdcd23f84ddfb13dc6901043.camel@scientia.org","threadId":"60346","inReplyTo":"23cc509bfb433e19c7683c97314e4ac8@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-12T01:39:57Z","receivedAt":"2023-10-12T01:40:11Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Thu, 2023-10-12 at 02:31 +0200, Dragan Simic wrote:\n> \n> Makes sense, but please see also my other reply on the list.  To sum\n> it \n> up, we can have either the current behavior, the inconsistent\n> behavior, \n> or an even more annoying behavior.  I believe that the current\n> behavior \n> is the best choice among these three options.\n\nWell as I've said... I don't demand that it's changed, but I simply\nthink it's a wrong assumption that it's in any way better or worse.\n\nLeaving back partial output, or when scrolling up&down completely\nmessed up output, is surely not per se more annoying or a bigger\nproblem than leaving back no output at all in one case (when it doesn't\nfit on one screen) or leaving back output (when it fits).\n\n\n\n> Yes, I'm sure, because I'd be fixing that already if that were the\n> case \n> in my environment. :)  I use Xfce and its default terminal emulator, \n> though, and I don't know what it's like in other desktop environments\n> and their terminal emulators.\n\nI just tried it with xfce4-terminal 1.1.0 (which AFAICS is the most\nrecent version) in Debian, and unless they break anything with custom\npatches, or you distro fixes anything with custom patches... I'd say\nyou must suffer from the same issue and probably just try something\ndifferent.\n\nSince Debian's less is pretty outdated, I've even compiled a quite\nrecent less 643 (there's not even a tarball yet for 644, only a git\ntag).\n\n\nA made a screen recording... it's not 8K ;-) but I guess you can see\nwhat I do:\nhttps://youtu.be/KMs3sLk9nXY\n\n\n\nCheers,\nChris.\n"},{"id":"483130","messageId":"07bf5744c7d123635740c62a940999e089339fa4.camel@scientia.org","threadId":"60346","inReplyTo":"20231012000416.GA520855@coredump.intra.peff.net","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-12T03:54:51Z","receivedAt":"2023-10-12T03:59:19Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"Hey.\n\nJust noted that the popular bat utility apparently also uses -X to make\n-F work (but also mention that this break scrolling).\n\nBut it seem they have a check, an if less is version 530 or newer they\ndon't set -X.\n\nhttps://github.com/sharkdp/bat#using-a-different-pager\n\nCould be a way to go for git.\n\nCheers,\nChris.\n"},{"id":"483131","messageId":"3946c06e90604a92ad0dddf787729668@manjaro.org","threadId":"60346","inReplyTo":"xmqqh6mwipqi.fsf@gitster.g","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-12T05:30:47Z","receivedAt":"2023-10-12T05:30:53Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 03:39, Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n>> ... Digging into the history and\n>> the changelog, this note is in \"changes between less versions 487 and\n>> 530\":\n>> \n>>   Don't output terminal init sequence if using -F and file fits on one\n>>   screen.\n> \n> ;-)\n> \n> That is really a good one to dig out.  So in short, X was needed\n> because we wanted to use F, and we could drop it if everybody is\n> using recent versions of less, but the default to use FX at the same\n> time gives us the same behaviour between both newer and older\n> versions of less.\n\nPlease note that dropping \"-X\" and leaving \"-F\" would actually introduce \nthe inconsistency that I already mentioned.  To reiterate, short outputs \nwould then remain displayed on screen, while long outputs would \ndisappear after exiting less(1).  I don't think that's the desired \nbehavior.\n\n>> ... And as you say, if there are people who really\n>> care about their LESS options, it is easy for them to override it.\n> \n> Yup.  I really like the discovery of that changelog entry.\n> \n> Thanks.\n"},{"id":"483133","messageId":"161b9584c6c9a004c01bda98cea4f1f8@manjaro.org","threadId":"60346","inReplyTo":"2f3ef5568ed19ac5bdcd23f84ddfb13dc6901043.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-12T05:46:10Z","receivedAt":"2023-10-12T05:46:51Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 03:39, Christoph Anton Mitterer wrote:\n> On Thu, 2023-10-12 at 02:31 +0200, Dragan Simic wrote:\n>> \n>> Makes sense, but please see also my other reply on the list.  To sum\n>> it\n>> up, we can have either the current behavior, the inconsistent\n>> behavior,\n>> or an even more annoying behavior.  I believe that the current\n>> behavior\n>> is the best choice among these three options.\n> \n> Well as I've said... I don't demand that it's changed, but I simply\n> think it's a wrong assumption that it's in any way better or worse.\n> \n> Leaving back partial output, or when scrolling up&down completely\n> messed up output, is surely not per se more annoying or a bigger\n> problem than leaving back no output at all in one case (when it doesn't\n> fit on one screen) or leaving back output (when it fits).\n\nLet me repeat that the messed up output you're experiencing isn't normal \nand has nothing to do with the arguments passed to less(1).  That's a \nseparate issue of the terminal emulator(s) you're using, or in issue of \nyour specific environment, and should be debugged and addressed as a \nseparate issue.\n\nTo me, having inconsistent displaying of the short and long outputs is \nsimply not acceptable.\n\n>> Yes, I'm sure, because I'd be fixing that already if that were the\n>> case\n>> in my environment. :)  I use Xfce and its default terminal emulator,\n>> though, and I don't know what it's like in other desktop environments\n>> and their terminal emulators.\n> \n> I just tried it with xfce4-terminal 1.1.0 (which AFAICS is the most\n> recent version) in Debian, and unless they break anything with custom\n> patches, or you distro fixes anything with custom patches... I'd say\n> you must suffer from the same issue and probably just try something\n> different.\n\nLet me repeat that I don't see those issues, and actually, IIRC, have \nnever seen them in my 25+ years of using various Linux distributions.  \nIf I've ever seen that, it would've already motivated me to have it \ndebugged and fixed.\n\nPerhaps something is wrong with your specific environment, because I see \nno other reason for this issue.\n\n> Since Debian's less is pretty outdated, I've even compiled a quite\n> recent less 643 (there's not even a tarball yet for 644, only a git\n> tag).\n> \n> A made a screen recording... it's not 8K ;-) but I guess you can see\n> what I do:\n> https://youtu.be/KMs3sLk9nXY\n\nFor some reason, I can see it with 360p as the highest available \nresolution, so I really can't read what's displayed on the recorded \nscreen.  Strange.  Could you, please, upload the video in higher \nresolution, perhaps to a file sharing service such as \nhttps://easyupload.io/ ?\n"},{"id":"483134","messageId":"1ef5b918d54cc1444c4a5b8df3a340ad@manjaro.org","threadId":"60346","inReplyTo":"07bf5744c7d123635740c62a940999e089339fa4.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-12T05:57:43Z","receivedAt":"2023-10-12T05:57:47Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 05:54, Christoph Anton Mitterer wrote:\n> Hey.\n> \n> Just noted that the popular bat utility apparently also uses -X to make\n> -F work (but also mention that this break scrolling).\n> \n> But it seem they have a check, an if less is version 530 or newer they\n> don't set -X.\n> \n> https://github.com/sharkdp/bat#using-a-different-pager\n> \n> Could be a way to go for git.\n\nLet me repeat that the described scrolling-related issues are \nmisleading.  I use this, configured through $BAT_PAGER, and have never \nexperienced such issues in a few years of using bat(1):\n\n       ├─bash\n       │   └─bat -n --tabs 8 --wrap never message.txt\n       │       └─less -R -F -X\n"},{"id":"483154","messageId":"xmqqr0lzhkzk.fsf@gitster.g","threadId":"60346","inReplyTo":"3946c06e90604a92ad0dddf787729668@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-12T16:19:11Z","receivedAt":"2023-10-12T16:19:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dragan Simic <dsimic@manjaro.org> writes:\n\n> Please note that dropping \"-X\" and leaving \"-F\" would actually\n> introduce the inconsistency that I already mentioned.  To reiterate,\n> short outputs would then remain displayed on screen, while long\n> outputs would disappear after exiting less(1).\n\nGood point.\n"},{"id":"483170","messageId":"e1e187ca3d970c18e1a11d51ff93b6cb212bcbaa.camel@scientia.org","threadId":"60346","inReplyTo":"161b9584c6c9a004c01bda98cea4f1f8@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-12T20:23:49Z","receivedAt":"2023-10-12T20:24:03Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Thu, 2023-10-12 at 07:46 +0200, Dragan Simic wrote:\n> Let me repeat that the messed up output you're experiencing isn't\n> normal \n> and has nothing to do with the arguments passed to less(1).  That's a\n> separate issue of the terminal emulator(s) you're using, or in issue\n> of \n> your specific environment, and should be debugged and addressed as a \n> separate issue.\n\nBe it as it may...\n\nAs I've told you before it happens at least in gnome-terminal (and thus\npresumably and VTE based terminal), xterm, xfce4-terminal and konsole\n(all current versions of Debian unstable)... with less as of Debian\nunstable as well as 643.\n\nThat affects at least on major distro, and there's a good chance that\nit affects any other distro based on Debian (*buntu, etc.).\n\n\nI further tried on SLES 15 with both gnome-terminal 3.42.2 and xterm\n330 as well as less 530.\n\nEven tried with the terminal emulator started via env -i and only TERM\nset manually.\n\n\n*All* cases affected by the same problem I've described before.\n\n\nSame with the command you've used in your follow-up post, here a video\nof it in HD:\nhttps://youtu.be/MsxtQgrKM50\n\n\n> To me, having inconsistent displaying of the short and long outputs\n> is \n> simply not acceptable.\n\nWhich is fine - and as I've said: I personally also tend to prefer it\nlike that - but even if the above would be just some bug (which however\nseems to affect all systems I could test on a short notice, except\nyours)... one can IMO still not generally say whether on or the other\nbehaviour is generally accepted to be the better one.\n\nEven if output may be just chopped of and thus ambiguously incomplete,\nsome people may still prefer to have rather no output at all.\n\nAnd in fact:\nThis is the default mode of less alone.\n\n\n\n> > \n> Perhaps something is wrong with your specific environment, because I\n> see \n> no other reason for this issue.\n\nWell may be, but seems unlikely from my PoV, given that I've now tested\neven on other distros and systems not under my control.\n\n\n\nAnyway... I think this got a bit too off-topic here :-D\n\n\nCheers,\nChris.\n\n\n\n\n"},{"id":"483180","messageId":"31b6f4a2b88cc3a2cfa908f82f4f2302@manjaro.org","threadId":"60346","inReplyTo":"e1e187ca3d970c18e1a11d51ff93b6cb212bcbaa.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-12T21:15:07Z","receivedAt":"2023-10-12T21:15:11Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 22:23, Christoph Anton Mitterer wrote:\n> On Thu, 2023-10-12 at 07:46 +0200, Dragan Simic wrote:\n>> Let me repeat that the messed up output you're experiencing isn't \n>> normal\n>> and has nothing to do with the arguments passed to less(1).  That's a\n>> separate issue of the terminal emulator(s) you're using, or in issue \n>> of\n>> your specific environment, and should be debugged and addressed as a\n>> separate issue.\n> \n> As I've told you before it happens at least in gnome-terminal (and thus\n> presumably and VTE based terminal), xterm, xfce4-terminal and konsole\n> (all current versions of Debian unstable)... with less as of Debian\n> unstable as well as 643.\n> \n> That affects at least on major distro, and there's a good chance that\n> it affects any other distro based on Debian (*buntu, etc.).\n> \n> I further tried on SLES 15 with both gnome-terminal 3.42.2 and xterm\n> 330 as well as less 530.\n> \n> Even tried with the terminal emulator started via env -i and only TERM\n> set manually.\n> \n> *All* cases affected by the same problem I've described before.\n> \n> Same with the command you've used in your follow-up post, here a video\n> of it in HD:\n> https://youtu.be/MsxtQgrKM50\n\nAh, I can finally see what are you talking about...  Thank you very much \nfor all the testing you've performed and for supplying this screen \nrecording!  I can confirm that my environment is also affected, but for \nsome reason I haven't observed it this way before.\n\nHuh, that's really worrisome and I'm willing to help you with debugging \nand fixing this issue.  Please, let me perform some debugging and \ndigging around, and I'll come back to you with some further insights,\n\n>> To me, having inconsistent displaying of the short and long outputs\n>> is simply not acceptable.\n> \n> Which is fine - and as I've said: I personally also tend to prefer it\n> like that - but even if the above would be just some bug (which however\n> seems to affect all systems I could test on a short notice, except\n> yours)... one can IMO still not generally say whether on or the other\n> behaviour is generally accepted to be the better one.\n> \n> Even if output may be just chopped of and thus ambiguously incomplete,\n> some people may still prefer to have rather no output at all.\n\nThose people, just as anyone else, can use $PAGER or $GIT_PAGER to \nconfigure the pagination the way they like it.  In the end, that's also \nwhat I do in my environment.\n\n>> Perhaps something is wrong with your specific environment, because\n>> I see no other reason for this issue.\n> \n> Well may be, but seems unlikely from my PoV, given that I've now tested\n> even on other distros and systems not under my control.\n> \n> Anyway... I think this got a bit too off-topic here :-D\n\nWell, yes and no.  This scrolling-related issue is obviously affecting \nnumerous git users, which makes it quite relevant for git as a project.  \nOf course, not directly relevant, but indirectly, yes.\n"},{"id":"483181","messageId":"c6cd3133573d5ade6d02b5da1051853a4b3885e1.camel@scientia.org","threadId":"60346","inReplyTo":"31b6f4a2b88cc3a2cfa908f82f4f2302@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-12T21:48:57Z","receivedAt":"2023-10-12T21:49:15Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Thu, 2023-10-12 at 23:15 +0200, Dragan Simic wrote:\n> \n> Ah, I can finally see what are you talking about...  Thank you very\n> much \n> for all the testing you've performed and for supplying this screen \n> recording!  I can confirm that my environment is also affected, but\n> for \n> some reason I haven't observed it this way before.\n\nWell... perhaps because it's not really \"easy\" to spot unless one\ncarefully reads through the lines (which I guess, one does not that\noften in the terminal \"history\").\n\nHave a look at my ticket at less, especially:\nhttps://github.com/gwsw/less/issues/445#issuecomment-1758887183\n\nWhere it was confirmed that the issue I describe might happen (and I\nguess is non-fixable?\n\nThe whole issue also contains an explanation on why scrolling doesn't\nwork when -X is used (but --mouse is not) on VTE terminals (and maybe\nothers, though not xterm).\nAnd it's basically not \"fixable\" but simply \"by design\".\n\n\n> Huh, that's really worrisome and I'm willing to help you with\n> debugging \n> and fixing this issue.  Please, let me perform some debugging and \n> digging around, and I'll come back to you with some further insights,\n\nWell, my assumption (though I'm really not a terminal expert) would be\nthat it's not fixable... because less would somehow make sure that\neverything it prints (in the alt screen buffer) is properly\nconcatenated in the the regular one.\n\n\nless upstream made some suggestions:\nhttps://github.com/gwsw/less/issues/445#issuecomment-1759986293\n\nOne would be to change the terminfo entry, which I guess is not really\nfeasible as a general solution.\n\nThe other would be less’ --redraw-on-quit option.\n\n\nMaybe that would be an even better solution for git?\nAFAICS, we could have -F, the VTE mouse scrolling out of the box, plus\n(via that option) the final screen buffer of less printed when exiting.\n\nWould give some context (what one did in the pager, where one was) on\nthe regular screen buffer, but (presumably) avoid that mess up... and\nperhaps even prevent unneeded pages of output from the pager, if one\nscrolled down a lot, which maybe aren't even needed?\n\n\n(Also note, that less` upstream calls `-X` \"a risky flag\" ;-) )\n\n\n> Those people, just as anyone else, can use $PAGER or $GIT_PAGER to \n> configure the pagination the way they like it.  In the end, that's\n> also \n> what I do in my environment.\n\nSure... all I said, that (IMO) in the case of `-X` it's not like with\n`-R` but rater like with `-S`... i.e. neither mode has more right to be\nthe default than the other.\n\n\n\nCheers,\nChris.\n"},{"id":"483185","messageId":"60f1922b12a6ef304ffa36c334348e34@manjaro.org","threadId":"60346","inReplyTo":"c6cd3133573d5ade6d02b5da1051853a4b3885e1.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-12T22:36:33Z","receivedAt":"2023-10-12T22:36:37Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 23:48, Christoph Anton Mitterer wrote:\n> On Thu, 2023-10-12 at 23:15 +0200, Dragan Simic wrote:\n>> \n>> Ah, I can finally see what are you talking about...  Thank you very \n>> much\n>> for all the testing you've performed and for supplying this screen\n>> recording!  I can confirm that my environment is also affected, but \n>> for\n>> some reason I haven't observed it this way before.\n> \n> Well... perhaps because it's not really \"easy\" to spot unless one\n> carefully reads through the lines (which I guess, one does not that\n> often in the terminal \"history\").\n> \n> Have a look at my ticket at less, especially:\n> https://github.com/gwsw/less/issues/445#issuecomment-1758887183\n\nGreat, thanks, it's full of very useful information.\n\n> Where it was confirmed that the issue I describe might happen (and I\n> guess is non-fixable?\n> \n> The whole issue also contains an explanation on why scrolling doesn't\n> work when -X is used (but --mouse is not) on VTE terminals (and maybe\n> others, though not xterm).\n> And it's basically not \"fixable\" but simply \"by design\".\n\nIt seems that \"--redraw-on-quit\" is a possible candidate for replacing \n\"-X\" in the set of default options for less(1), and also in other CLI \nutilities, but I still need to test it in detail.\n\n>> Huh, that's really worrisome and I'm willing to help you with\n>> debugging\n>> and fixing this issue.  Please, let me perform some debugging and\n>> digging around, and I'll come back to you with some further insights,\n> \n> Well, my assumption (though I'm really not a terminal expert) would be\n> that it's not fixable... because less would somehow make sure that\n> everything it prints (in the alt screen buffer) is properly\n> concatenated in the the regular one.\n\nI did some work on terminal emulators, but I'm also not very much of an \nexpert when it comes to terminal emulators.\n\n> less upstream made some suggestions:\n> https://github.com/gwsw/less/issues/445#issuecomment-1759986293\n> \n> One would be to change the terminfo entry, which I guess is not really\n> feasible as a general solution.\n> \n> The other would be less’ --redraw-on-quit option.\n\nI agree that the latter seems like a viable solution, but as I already \nwrote above, I need to test it first, together with doing some digging \nthrough the less(1) source code.\n\n> Maybe that would be an even better solution for git?\n> AFAICS, we could have -F, the VTE mouse scrolling out of the box, plus\n> (via that option) the final screen buffer of less printed when exiting.\n\nExactly, but still needs testing and a detailed insight.\n\n> Would give some context (what one did in the pager, where one was) on\n> the regular screen buffer, but (presumably) avoid that mess up... and\n> perhaps even prevent unneeded pages of output from the pager, if one\n> scrolled down a lot, which maybe aren't even needed?\n\nYes, it seems to tick all the boxes.\n\n> (Also note, that less` upstream calls `-X` \"a risky flag\" ;-) )\n\nIn general, \"-X\" seems to be more of a bandaid option.\n\n>> Those people, just as anyone else, can use $PAGER or $GIT_PAGER to\n>> configure the pagination the way they like it.  In the end, that's\n>> also\n>> what I do in my environment.\n> \n> Sure... all I said, that (IMO) in the case of `-X` it's not like with\n> `-R` but rater like with `-S`... i.e. neither mode has more right to be\n> the default than the other.\n"},{"id":"483187","messageId":"ec91ff19cca3d881d4746208744663c650ebd250.camel@scientia.org","threadId":"60346","inReplyTo":"60f1922b12a6ef304ffa36c334348e34@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-12T23:06:40Z","receivedAt":"2023-10-12T23:07:01Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Fri, 2023-10-13 at 00:36 +0200, Dragan Simic wrote:\n> It seems that \"--redraw-on-quit\" is a possible candidate for\n> replacing \n> \"-X\" in the set of default options for less(1)\n\n*If* some changes were made to how git handles this, it might perhaps\nbe worth to consider not to touch LESS at all, but only add the\nrequired settings via command line arguments (i.e. -F -R ...).\n\nOr perhaps only remove options from it, if they're known to break the\nbehaviour with git (like -+R might).\n\n\nI always feel configuration via env vars is a bit fragile:\n- especially when one has generic names like POSIXLY_CORRECT there's\n  some chance that by exporting it to one program, where one wants the\n  effect, another program started off by that also gets it\n  unintentionally\n- generic terms may be used by multiple programs, causing problems\n\nAlso, if one can set only one LESS var in the environment, not one for\nless \"alone\", one for less with git, etc. - that is unless for programs\nlike bat/delta which have specific own env vars to set the pager.\n\nSo if I set e.g. LESS to something, than typically only to stuff from\nwhich I believe it works as expected for any possible users.\nE.g. -F might be such a case.\n\nBut if I do that, git won't touch LESS and set the required -R, so I\nhave to do that manually for git, e.g. either via git_config or by\ndefining an alias git='LESS=FRX git'.\nBut in both cases it would \"break\" again, should ever another option be\nneeded and added by git to the default LESS (which is however only set\nwhen it's unset).\nAnd in case of an alias, there would be the additional problem, that\nit's typically not picked up in non-interactive shells.\n\n\nLong story short, it might make sense for git, to (mostly) ignore LESS\nand rather invoke less with -F -R.\n\nThe problem with that in turn would of course be that it doesn't\nautomatically propagate down, if e.g. git's pager is set to detla and\ndelta in turn runs less.\nHowever, that's IMO litte concern, since then it's delta's duty to set\n-R (if it think it needs to do so), which it actually does.\n\n\nCheers,\nChris.\n"},{"id":"483189","messageId":"6d673c1bdae41236e95e3a9fca853731@manjaro.org","threadId":"60346","inReplyTo":"ec91ff19cca3d881d4746208744663c650ebd250.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-13T04:43:05Z","receivedAt":"2023-10-13T04:43:09Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-13 01:06, Christoph Anton Mitterer wrote:\n> On Fri, 2023-10-13 at 00:36 +0200, Dragan Simic wrote:\n>> It seems that \"--redraw-on-quit\" is a possible candidate for\n>> replacing \"-X\" in the set of default options for less(1)\n> \n> *If* some changes were made to how git handles this, it might perhaps\n> be worth to consider not to touch LESS at all, but only add the\n> required settings via command line arguments (i.e. -F -R ...).\n\nActually, that would be wrong.  If someone sets $LESS or $PAGER (or \n$GIT_PAGER, more specifically), it's up to the utility that invokes the \npager internally not to override the user preferences configured through \nthese environment variables.  That's how everyone can customize the \npager behavior.\n\n> Or perhaps only remove options from it, if they're known to break the\n> behaviour with git (like -+R might).\n\nAgain, not the way the whole thing with pagination works.  If someone \nsets their environment variables wrong, it's simply the way they want \nit, and it isn't anyone else's business to attempt fixing it \nautomatically.\n\n> I always feel configuration via env vars is a bit fragile:\n> - especially when one has generic names like POSIXLY_CORRECT there's\n>   some chance that by exporting it to one program, where one wants the\n>   effect, another program started off by that also gets it\n>   unintentionally\n> - generic terms may be used by multiple programs, causing problems\n\nWell, fragile or not, that's the way it works.  It has its downsides for \nsure, but it's all about having each utility handle the environment \ncarefully and document it in its man page(s), so the users can also \ncarefully craft the values of their customized environment variables.\n\n> Also, if one can set only one LESS var in the environment, not one for\n> less \"alone\", one for less with git, etc. - that is unless for programs\n> like bat/delta which have specific own env vars to set the pager.\n\n$LESS can be seen as a global set of the common options for less(1), \nwhich may include the coloring configuration or the enablement of \ncase-insensitive search, for example, while $MANPAGER, $GIT_PAGER and \n$BAT_PAGER may contain utility-specific options for less(1).  That's \nactually very good, because it makes possible to avoid duplication of \nthe common options.\n\n> So if I set e.g. LESS to something, than typically only to stuff from\n> which I believe it works as expected for any possible users.\n> E.g. -F might be such a case.\n\nIt's up to everyone to decide what are the common options for less(1) \nthat they want to set in $LESS.\n\n> But if I do that, git won't touch LESS and set the required -R, so I\n> have to do that manually for git, e.g. either via git_config or by\n> defining an alias git='LESS=FRX git'.\n\nYou don't have to define an alias, there's $GIT_PAGER for that purpose, \nas I already explained above.\n\nMoreover, the whole idea of the various utilities touching the $LESS \nvariable internally is to provide sane defaults to the users that don't \nconfigure $LESS, $PAGER, etc. on their own.  Once the user starts to \nprovide their own environment variable(s), it's no longer up to the \nutility to help the user by altering their environment configuration.\n\n> But in both cases it would \"break\" again, should ever another option be\n> needed and added by git to the default LESS (which is however only set\n> when it's unset).\n> And in case of an alias, there would be the additional problem, that\n> it's typically not picked up in non-interactive shells.\n\nAs you can see in my replies, it isn't about taking care of the users \nwho provide their own environment configuration.  It's all about \nproviding the set of sane defaults, for the users with no custom \nconfiguration.\n\n> Long story short, it might make sense for git, to (mostly) ignore LESS\n> and rather invoke less with -F -R.\n\nNo, that would be wrong on multiple levels, as I already explained in \ndetail.\n\n> The problem with that in turn would of course be that it doesn't\n> automatically propagate down, if e.g. git's pager is set to detla and\n> delta in turn runs less.\n> However, that's IMO litte concern, since then it's delta's duty to set\n> -R (if it think it needs to do so), which it actually does.\n\nI don't know what delta is and how it actually paginates its outputs, \nbut it should follow the rules of the environment-based pager \nconfiguration that I described in detail above.\n"},{"id":"483197","messageId":"48ff9c2ac262cec32ab4681e8417413488278294.camel@scientia.org","threadId":"60346","inReplyTo":"6d673c1bdae41236e95e3a9fca853731@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2023-10-13T13:45:58Z","receivedAt":"2023-10-13T13:46:11Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Fri, 2023-10-13 at 06:43 +0200, Dragan Simic wrote:\n> > *If* some changes were made to how git handles this, it might\n> > perhaps\n> > be worth to consider not to touch LESS at all, but only add the\n> > required settings via command line arguments (i.e. -F -R ...).\n> \n> Actually, that would be wrong.  If someone sets $LESS or $PAGER (or \n> $GIT_PAGER, more specifically), it's up to the utility that invokes\n> the \n> pager internally not to override the user preferences configured\n> through \n> these environment variables.  That's how everyone can customize the \n> pager behavior.\n\nWell, but if its clear that the output would otherwise be garbage (e.g.\nbecause -R is missing).\n\nIn any case right now we have the situation that a user cannot just\neasily set LESS in his environment, with a minimum set of options, and\ngit's use of less will continue flawlessly out of the box, as the -R\nwould be missing.\n\n\n> > Or perhaps only remove options from it, if they're known to break\n> > the\n> > behaviour with git (like -+R might).\n> \n> Again, not the way the whole thing with pagination works.  If someone\n> sets their environment variables wrong, it's simply the way they want\n> it, and it isn't anyone else's business to attempt fixing it \n> automatically.\n\nWell, I wouldn't agree with that.\nLESS foremost a env var to configure less (surprise ^^).\n\nIf git (or anyone else) uses less internally, e.g. because they don't\nwant to implement their own pager, fine... but then they cannot just\nblindly assume that LESS is set only for git's (or any other tool's\nneeds).\n\nSo I'd say the proper way is rather that any such tool makes sure, that\nany options strictly required as set no matter what. Just as e.g. delta\ndoes.\n\n\n> Well, fragile or not, that's the way it works.  It has its downsides\n> for \n> sure, but it's all about having each utility handle the environment \n> carefully and document it in its man page(s), so the users can also \n> carefully craft the values of their customized environment variables.\n\nSure, but from a user's view, the use of less (or anything else) within\ngit is conceptually completely opaque.\n\nIn less' manpage LESS isn't documented as \"oh and you must make sure -R\nis included or otherwise git will break\"...\n\n\n\n> $LESS can be seen as a global set of the common options for less(1), \n\no.O ... but, as I've described, one cannot really use it as that:\n\nIf I globally set e.g. LESS=\"F\" because my desire is to make less\nalways exit as soon as the file fits on a screen, which I think is a\nreasonable thing to do, git would no longer add \"R\" and output would\nbreak.\n\n\n> You don't have to define an alias, there's $GIT_PAGER for that\n> purpose, \n> as I already explained above.\n\nWell, yes... and as I've said before, one could also solve it via\ngit_config... but the problem stays the same... as soon as someone\nwants to use LESS as global less options just as you described it\nyourself, git will no longer worker properly because of the missing -R.\n\nAnd actually if one would use GIT_PAGER one would again defeat the\npurpose of a allegedly global options LESS, because unless one does\nsomething like GIT_PAGER=\"${LESS}R\" it wouldn't see any changes made to\nLESS.\n\n\n> Moreover, the whole idea of the various utilities touching the $LESS \n> variable internally is to provide sane defaults to the users that\n> don't \n> configure $LESS, $PAGER, etc. on their own.\n\nThen I don't see what the big problem would be to just do it via a\ncommand argument - if someone really has ever some reasons to remove --\nRAW‐CONTROL‐CHARS from the command options when less is invoked via git\n... then he could still go into git_config and set that manually.\n\nBut it would seem to me that the overall handling would be much more\nwhat one expects, than when doing the same via LESS.\n\n\n\n> I don't know what delta is and how it actually paginates its outputs,\n> but it should follow the rules of the environment-based pager \n> configuration that I described in detail above.\n\nWell, AFAIU, it doesn't and for good reasons :-)\n\n\nAnyway... I think all necessary things have been said and this thread\nhas grown far to large with only semi-related stuff... so thanks for\nall the replies why git uses \"-X\".\n\n\nCheers,\nChris.\n"},{"id":"483199","messageId":"2bbfc823d05434b63ef3e119df106d4e@manjaro.org","threadId":"60346","inReplyTo":"48ff9c2ac262cec32ab4681e8417413488278294.camel@scientia.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-13T15:00:44Z","receivedAt":"2023-10-13T15:00:48Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-13 15:45, Christoph Anton Mitterer wrote:\n> On Fri, 2023-10-13 at 06:43 +0200, Dragan Simic wrote:\n>> Actually, that would be wrong.  If someone sets $LESS or $PAGER (or\n>> $GIT_PAGER, more specifically), it's up to the utility that invokes\n>> the pager internally not to override the user preferences configured\n>> through these environment variables.  That's how everyone can \n>> customize\n>> the pager behavior.\n> \n> Well, but if its clear that the output would otherwise be garbage (e.g.\n> because -R is missing).\n\nWell, it's the basic principle of \"garbage in, garbage out\".  If there's \nsomething wrong with the contents of the environment variables, that's \nsimply the way the user configured it, and it's only their job to get it \nright.\n\n> In any case right now we have the situation that a user cannot just\n> easily set LESS in his environment, with a minimum set of options, and\n> git's use of less will continue flawlessly out of the box, as the -R\n> would be missing.\n\nLet me repeat that it isn't the job of git or any other pager-enabled \nutility to fix the user-defined environment.  Otherwise, the user \nactually wouldn't be able to make their choice freely.\n\n>> Again, not the way the whole thing with pagination works.  If someone\n>> sets their environment variables wrong, it's simply the way they want\n>> it, and it isn't anyone else's business to attempt fixing it\n>> automatically.\n> \n> Well, I wouldn't agree with that.\n> LESS foremost a env var to configure less (surprise ^^).\n> \n> If git (or anyone else) uses less internally, e.g. because they don't\n> want to implement their own pager, fine... but then they cannot just\n> blindly assume that LESS is set only for git's (or any other tool's\n> needs).\n\nYou seem to be missing the presence of other enviroment variables, \nnamely $GIT_PAGER, which I already described in detail in my previous \nreply.  I'd appreciate if you'd read that description in detail, and \npossibly test it a bit.\n\n> So I'd say the proper way is rather that any such tool makes sure, that\n> any options strictly required as set no matter what. Just as e.g. delta\n> does.\n\nAgain, that's simply wrong and defeats the user's freedom of choice.\n\n>> Well, fragile or not, that's the way it works.  It has its downsides\n>> for\n>> sure, but it's all about having each utility handle the environment\n>> carefully and document it in its man page(s), so the users can also\n>> carefully craft the values of their customized environment variables.\n> \n> Sure, but from a user's view, the use of less (or anything else) within\n> git is conceptually completely opaque.\n\nActually, it isn't, because there are $LESS, $PAGER and $GIT_PAGER \nenvironment variables to customize the behavior.\n\n> In less' manpage LESS isn't documented as \"oh and you must make sure -R\n> is included or otherwise git will break\"...\n\nQuite frankly, it would be silly to expect the less(1) man page to \nmention something about git(1).\n\n>> $LESS can be seen as a global set of the common options for less(1),\n> \n> o.O ... but, as I've described, one cannot really use it as that:\n> \n> If I globally set e.g. LESS=\"F\" because my desire is to make less\n> always exit as soon as the file fits on a screen, which I think is a\n> reasonable thing to do, git would no longer add \"R\" and output would\n> break.\n\nAgain, you seem not to understand well the distinction between the \nglobal settings (i.e. $LESS and $PAGER) and the utility-specific \nsettings (e.g. $GIT_PAGER).  Or you maybe simply refuse to understand \nit, I don't know.\n\n>> You don't have to define an alias, there's $GIT_PAGER for that\n>> purpose, as I already explained above.\n> \n> Well, yes... and as I've said before, one could also solve it via\n> git_config... but the problem stays the same... as soon as someone\n> wants to use LESS as global less options just as you described it\n> yourself, git will no longer worker properly because of the missing -R.\n> \n> And actually if one would use GIT_PAGER one would again defeat the\n> purpose of a allegedly global options LESS, because unless one does\n> something like GIT_PAGER=\"${LESS}R\" it wouldn't see any changes made to\n> LESS.\n\nLet me clarify that the contents of $LESS is applied by less(1) \ninternally, so the final runtime configuration for less(1) is a sum of \nthe configurations made available through the $LESS and $PAGER (or \n$GIT_PAGER) environment variables.  It's a rather powerful approach, if \nused properly.\n\n>> Moreover, the whole idea of the various utilities touching the $LESS\n>> variable internally is to provide sane defaults to the users that\n>> don't\n>> configure $LESS, $PAGER, etc. on their own.\n> \n> Then I don't see what the big problem would be to just do it via a\n> command argument - if someone really has ever some reasons to remove --\n> RAW‐CONTROL‐CHARS from the command options when less is invoked via git\n> ... then he could still go into git_config and set that manually.\n> \n> But it would seem to me that the overall handling would be much more\n> what one expects, than when doing the same via LESS.\n\nAgain, adding or modifying any command-line arguments by git itself \nwould defeat the purpose of the environment variables and prevent the \nusers from making their choice of the pagination configuration freely.\n\n>> I don't know what delta is and how it actually paginates its outputs,\n>> but it should follow the rules of the environment-based pager\n>> configuration that I described in detail above.\n> \n> Well, AFAIU, it doesn't and for good reasons :-)\n\nIn that case, delta does it wrong, and I hope you understand why.\n\n> Anyway... I think all necessary things have been said and this thread\n> has grown far to large with only semi-related stuff... so thanks for\n> all the replies why git uses \"-X\".\n\nI hope all this was useful to you.  It was useful to me. :)\n"},{"id":"483227","messageId":"a831af51b6fb46b5d6fcd9768a7fb52d@manjaro.org","threadId":"60346","inReplyTo":"xmqqr0lzhkzk.fsf@gitster.g","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-10-13T20:12:57Z","receivedAt":"2023-10-13T20:13:01Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-10-12 18:19, Junio C Hamano wrote:\n> Dragan Simic <dsimic@manjaro.org> writes:\n> \n>> Please note that dropping \"-X\" and leaving \"-F\" would actually\n>> introduce the inconsistency that I already mentioned.  To reiterate,\n>> short outputs would then remain displayed on screen, while long\n>> outputs would disappear after exiting less(1).\n> \n> Good point.\n\nI've been thinking about this, and a rather elegant, backward-compatible \nsolution is possible, but it requires some improvements to be made to \nless(1) first.  I'll reach out to the author of less(1) and propose that \nnew feature, and I'll let you know his opinion about it.\n"},{"id":"484331","messageId":"aefa38cd-d0fa-4dc6-8d10-4358e36b39af@gmail.com","threadId":"60346","inReplyTo":"cfbe174f-23ac-4a35-8db4-66bdfdfdc14e@gmail.com","subject":"Re: why does git set X in LESS env var?","fromName":"Thomas Guyot","fromEmail":"tguyot@gmail.com","sentAt":"2023-11-02T06:01:51Z","receivedAt":"2023-11-02T06:01:59Z","isPatch":false,"sender":{"key":"tguyot@gmail.com","avatar":"https://avatars.githubusercontent.com/u/403890?v=4"},"body":"On 2023-11-02 01:48, Thomas Guyot wrote:\n> Hey there...\n\nI obviously thought about checking this client's setting the moment I \nhit the send button - if the response is garbled I'll resend it properly.\n\n--\nThomas\n"},{"id":"484332","messageId":"20889d91b28af0946c7f2f226561bf2c@manjaro.org","threadId":"60346","inReplyTo":"aefa38cd-d0fa-4dc6-8d10-4358e36b39af@gmail.com","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-11-02T06:14:08Z","receivedAt":"2023-11-02T06:14:15Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-11-02 07:01, Thomas Guyot wrote:\n> On 2023-11-02 01:48, Thomas Guyot wrote:\n>> Hey there...\n> \n> I obviously thought about checking this client's setting the moment I\n> hit the send button - if the response is garbled I'll resend it\n> properly.\n\nIt's in HTML format, which isn't the preferred way, but it's still \nreadable.\n"},{"id":"484333","messageId":"8022dae27797bf1e1770f099ed37f5d3@manjaro.org","threadId":"60346","inReplyTo":"cfbe174f-23ac-4a35-8db4-66bdfdfdc14e@gmail.com","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-11-02T06:48:42Z","receivedAt":"2023-11-02T06:48:49Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-11-02 06:48, Thomas Guyot wrote:\n> On 2023-10-13 16:12, Dragan Simic wrote:\n>> On 2023-10-12 18:19, Junio C Hamano wrote:\n>>> Dragan Simic <dsimic@manjaro.org> writes:\n>>>> Please note that dropping \"-X\" and leaving \"-F\" would actually\n>>>> introduce the inconsistency that I already mentioned.  To reiterate,\n>>>> short outputs would then remain displayed on screen, while long\n>>>> outputs would disappear after exiting less(1).\n>>> \n>>> Good point.\n>> \n>> I've been thinking about this, and a rather elegant, \n>> backward-compatible\n>> solution is possible, but it requires some improvements to be made to\n>> less(1) first.  I'll reach out to the author of less(1) and propose \n>> that\n>> new feature, and I'll let you know his opinion about it.\n> \n>  Hey there...\n\nHello!\n\n> I'm clearly late to the party but I'm wondering, has anyone tested\n> adding -cy0 ? From the manpage (slightly edited):\n> \n>        -c or --clear-screen ( and backward compat. -C or\n> --CLEAR-SCREEN )\n>               Causes full screen repaints to be painted from the top\n> line down.  By default, full screen repaints are done by scrolling\n> from the  bottom  of the screen.\n\nAFAIK, the \"-c\" option is about the way screen contents is updated when \nscrolled, and it exists to aid in resolving possible issues with some \nterminal emulators.  To make sure, I just tested it, and \"-c\" doesn't \nreplace \"-X\".\n\n>        -yn or --max-forw-scroll=n\n>               Specifies  a  maximum  number of lines to scroll\n> forward.  If it is necessary to scroll forward more than n lines, the\n> screen is repainted in‐\n>               stead.  The -c or -C option may be used to repaint from\n> the top of the screen if desired.  By default, any forward movement\n> causes scrolling.\n\nThis option is, I'd guess, also about aiding in resolving possible \nissues with some terminal emulators.  Or maybe even with some actual \nterminals as pieces of hardware, who knows, which may be too slow to \nscroll many lines at once.\n\n> I actually have one major issue with it, it's that displaying anything\n> less than a full page will fill the screen with ~ on the bottom, just\n> like when scrolling up on a partial page  without -F. I can see this\n> being a major annoyance when using for ex. git log -1, git show --stat\n> or --name-only, etc. as I  usually do it to keep the latest history\n> within the current screen (and there's likely even commands that I\n> never seen using the pager because I never exceeded the page height).\n\nHuh, this confuses me a bit, quite frankly.  Isn't the \"-F\" option used \nspecifically to make pagination invisible in case fewer lines than one \nfull screen are displayed?\n\n> OTOH by repainting from the top, the scrollback buffer is never\n> affected. only the last displayed page remains on the terminal.\n\nJust to clarify, it's the \"-X\" option that creates all the issues, and \nthe \"--redraw-on-quit\" option is already there to replace it with no \nassociated issues, but the trouble is that only newer versions of \nless(1) support the \"--redraw-on-quit\" option.  IOW, it's all about \nimproving less(1) to avoid complex workarounds required to handle \ndifferent versions, such as the workarounds used in bat(1).\n\n> If less could only enable this behavior after the first full page\n> draw, that would be perfect!\n\nCould you, please, elaborate a bit on that?\n\n> Dragan, that may be useful if you're discussing with less\n> developers...\n\nWe've basically reached some kind of an agreement about the need for a \ngood solution, which turned out to be rather complex as a result of \nbeing quite universal and extensible, which was required for it to, \nhopefully, be accepted into less(1).  Also, the author of less(1) seems \nto be quite busy with some other things, and he prefers to implement new \nfeatures himself.\n\nWe've also agreed on another new feature for less(1), hopefully, which \nisn't exactly related, but should be quite useful.  It's about the \nsecure mode for less(1).\n"},{"id":"484350","messageId":"d54eedf0-7825-44f5-908c-a51541345872@gmail.com","threadId":"60346","inReplyTo":"8022dae27797bf1e1770f099ed37f5d3@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Thomas Guyot","fromEmail":"tguyot@gmail.com","sentAt":"2023-11-02T13:19:11Z","receivedAt":"2023-11-02T13:19:15Z","isPatch":false,"sender":{"key":"tguyot@gmail.com","avatar":"https://avatars.githubusercontent.com/u/403890?v=4"},"body":"On 2023-11-02 02:48, Dragan Simic wrote:\n> On 2023-11-02 06:48, Thomas Guyot wrote:\n>>         -c or --clear-screen ( and backward compat. -C or\n>> --CLEAR-SCREEN )\n>>                Causes full screen repaints to be painted from the top\n>> line down.  By default, full screen repaints are done by scrolling\n>> from the  bottom  of the screen.\n> AFAIK, the \"-c\" option is about the way screen contents is updated when\n> scrolled, and it exists to aid in resolving possible issues with some\n> terminal emulators.  To make sure, I just tested it, and \"-c\" doesn't\n> replace \"-X\".\nThat's correct, you need both and also -y0\n\n>>         -yn or --max-forw-scroll=n\n>>                Specifies  a  maximum  number of lines to scroll\n>> forward.  If it is necessary to scroll forward more than n lines, the\n>> screen is repainted in‐\n>>                stead.  The -c or -C option may be used to repaint from\n>> the top of the screen if desired.  By default, any forward movement\n>> causes scrolling.\n> This option is, I'd guess, also about aiding in resolving possible\n> issues with some terminal emulators.  Or maybe even with some actual\n> terminals as pieces of hardware, who knows, which may be too slow to\n> scroll many lines at once.\n\nWith a value of 0, it effectively redraw the screen on scroll. This \ncould have a potential impact on slow connections.\n\n>> I actually have one major issue with it, it's that displaying anything\n>> less than a full page will fill the screen with ~ on the bottom, just\n>> like when scrolling up on a partial page  without -F. I can see this\n>> being a major annoyance when using for ex. git log -1, git show --stat\n>> or --name-only, etc. as I  usually do it to keep the latest history\n>> within the current screen (and there's likely even commands that I\n>> never seen using the pager because I never exceeded the page height).\n> Huh, this confuses me a bit, quite frankly.  Isn't the \"-F\" option used\n> specifically to make pagination invisible in case fewer lines than one\n> full screen are displayed?\n\nIndeed, but when less update from the bottom, it can add new lines and \nlet the overflow lines scroll up into the scrollback buffer.\n\nThen updating it from the top, it draws the whole page, top to bottom. \nThat's fine for a full page but not desired for a partial one. Also note \nthat on my terminal (rxvt-unicode) when less clears the screen to draw \nthe first page the current screen is rolled up into scrollback - iirc \nthat's a configurable option, it would be worth testing other terminal's \nbehavior on that. IIRC it may also erase it when using the wrong termcap \nfile.\n\nI haven't looked at the code, but I think it could be possibly to start \nthe -c behavior only after a full page is drawn, after exiting on \npartial pages, which would give us the best of both worlds.\n\n>> OTOH by repainting from the top, the scrollback buffer is never\n>> affected. only the last displayed page remains on the terminal.\n> Just to clarify, it's the \"-X\" option that creates all the issues, and\n> the \"--redraw-on-quit\" option is already there to replace it with no\n> associated issues, but the trouble is that only newer versions of\n> less(1) support the \"--redraw-on-quit\" option.  IOW, it's all about\n> improving less(1) to avoid complex workarounds required to handle\n> different versions, such as the workarounds used in bat(1).\n\nTBH I haven't tested --redraw-on-quit, even on Debian Bookworm which was \njust released a couple months ago this option isn't available. I suspect \nthat the issue isn't -X, but the scrolling behavior controlled by -y and \nthe full redraw controlled by -c.Actually I just tested my solution on \nxfce4-terminal and it doesn't work, the terminal still push up stuff \nabove on redraw (noteworthy is with rxvt-unicode the first draw pushes \nthe current screen contents up but no other redraw does, which is what \nmakes it work so well - I haven't tried to find out what is being done \nexactly... OTOH the redraw on scroll down is slightly noticeable there, \nwhile impossible to see on xfce4-terminal. I'll install the latest less \nand see what happens with --redraw on\n>> If less could only enable this behavior after the first full page\n>> draw, that would be perfect!\n> Could you, please, elaborate a bit on that?\n\nI mentioned it slightly above, to be clear it would mean that:\n\n1. less starts by just writing lined down as usual, making any lines \nabove scroll up and overflow into the scrollback buffer as usual\n2.  If less draws less than a page, exits as before - the effective \nresult is as if pager was cat\n3. If less reaches a full page and still has lines to write, it turns on \n-c's behavior and further updates happen from the top of the screen, \npreventing scroll up (at least on rxvt-unicode)\n\nNow, if all other terms misbehave here, that's an issue, making this \nsuggestion mostly useless. And considering the number of Windows users \nwe absolutely need to test Windows Terminal, and should probably test \nMacOS's term too (whatever that is).\n>> Dragan, that may be useful if you're discussing with less\n>> developers...\n> We've basically reached some kind of an agreement about the need for a\n> good solution, which turned out to be rather complex as a result of\n> being quite universal and extensible, which was required for it to,\n> hopefully, be accepted into less(1).  Also, the author of less(1) seems\n> to be quite busy with some other things, and he prefers to implement new\n> features himself.\n>\n> We've also agreed on another new feature for less(1), hopefully, which\n> isn't exactly related, but should be quite useful.  It's about the\n> secure mode for less(1).\n\nFeel free to cc me on your next correspondence. If there are mailing \nlists archives for the thread I'll fetch them as needed. We have at \nleast one working term/switch combination, which IMO is a better start \nthan nothing :)\n\nRegards,\n\n--\nThomas\n"},{"id":"484366","messageId":"79cf1bf35ba6c9348735685b01e0f2f9@manjaro.org","threadId":"60346","inReplyTo":"d54eedf0-7825-44f5-908c-a51541345872@gmail.com","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-11-02T14:19:54Z","receivedAt":"2023-11-02T14:20:01Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-11-02 14:19, Thomas Guyot wrote:\n> On 2023-11-02 02:48, Dragan Simic wrote:\n>> On 2023-11-02 06:48, Thomas Guyot wrote:\n>>>         -c or --clear-screen ( and backward compat. -C or\n>>> --CLEAR-SCREEN )\n>>>                Causes full screen repaints to be painted from the top\n>>> line down.  By default, full screen repaints are done by scrolling\n>>> from the  bottom  of the screen.\n>> \n>> AFAIK, the \"-c\" option is about the way screen contents is updated \n>> when\n>> scrolled, and it exists to aid in resolving possible issues with some\n>> terminal emulators.  To make sure, I just tested it, and \"-c\" doesn't\n>> replace \"-X\".\n> \n> That's correct, you need both and also -y0\n\nHmm, I tried the following:\n\n     GIT_PAGER='less -R -F -X -c -y0'\n\nIn my environment (Xfce), the result after scrolling the output of \"git \nlog -p\" up and down a bit was about 20 copies of the same screen \"page\" \nin the scrollback, plus a couple of blank \"pages\".  Not good, \nunfortunately, and actually much worse than having just \"-R -F -X\".\n\n>> Huh, this confuses me a bit, quite frankly.  Isn't the \"-F\" option \n>> used\n>> specifically to make pagination invisible in case fewer lines than one\n>> full screen are displayed?\n> \n> Indeed, but when less update from the bottom, it can add new lines and\n> let the overflow lines scroll up into the scrollback buffer.\n> \n> Then updating it from the top, it draws the whole page, top to bottom.\n> That's fine for a full page but not desired for a partial one. Also\n> note that on my terminal (rxvt-unicode) when less clears the screen to\n> draw the first page the current screen is rolled up into scrollback -\n> iirc that's a configurable option, it would be worth testing other\n> terminal's behavior on that. IIRC it may also erase it when using the\n> wrong termcap file.\n> \n> I haven't looked at the code, but I think it could be possibly to\n> start the -c behavior only after a full page is drawn, after exiting\n> on partial pages, which would give us the best of both worlds.\n\nDoes the GIT_PAGER setup, as I described it above, work for you without \nthe described artifacts, in any of the environments you have access to?\n\n>>> OTOH by repainting from the top, the scrollback buffer is never\n>>> affected. only the last displayed page remains on the terminal.\n>> \n>> Just to clarify, it's the \"-X\" option that creates all the issues, and\n>> the \"--redraw-on-quit\" option is already there to replace it with no\n>> associated issues, but the trouble is that only newer versions of\n>> less(1) support the \"--redraw-on-quit\" option.  IOW, it's all about\n>> improving less(1) to avoid complex workarounds required to handle\n>> different versions, such as the workarounds used in bat(1).\n> \n> TBH I haven't tested --redraw-on-quit, even on Debian Bookworm which\n> was just released a couple months ago this option isn't available. I\n> suspect that the issue isn't -X, but the scrolling behavior controlled\n> by -y and the full redraw controlled by -c.\n\nWhen you get into the terminfo entry definitions, the root cause is that \nthe terminal initialization sequences contain switching to alternate \nscreen, which causes screen contents to be lost when less(1) exits.  \nThus, \"-X\" has been actually abused in the pager setups to skip the \nterminal initialization sequences, which may also result in other \nissues.\n\nOne of the solutions is to edit the terminfo entry manually and remove \nthe escape codes that cause the switching to and from alternate screen, \nwhich I tested, but that also introduced another issue -- the screen \ncontents was always present after less(1) exited, which isn't always the \ndesired behavior.\n\n> Actually I just tested my\n> solution on xfce4-terminal and it doesn't work, the terminal still\n> push up stuff above on redraw (noteworthy is with rxvt-unicode the\n> first draw pushes the current screen contents up but no other redraw\n> does, which is what makes it work so well - I haven't tried to find\n> out what is being done exactly... OTOH the redraw on scroll down is\n> slightly noticeable there, while impossible to see on xfce4-terminal.\n> I'll install the latest less and see what happens with --redraw on\n\nPlease test the \"--redraw-on-quit\" option, so far it's the best \navailable solution, IMHO.\n\n>>> If less could only enable this behavior after the first full page\n>>> draw, that would be perfect!\n>> \n>> Could you, please, elaborate a bit on that?\n> \n> I mentioned it slightly above, to be clear it would mean that:\n> \n> 1. less starts by just writing lined down as usual, making any lines\n> above scroll up and overflow into the scrollback buffer as usual\n> 2.  If less draws less than a page, exits as before - the effective\n> result is as if pager was cat\n> 3. If less reaches a full page and still has lines to write, it turns\n> on -c's behavior and further updates happen from the top of the\n> screen, preventing scroll up (at least on rxvt-unicode)\n> \n> Now, if all other terms misbehave here, that's an issue, making this\n> suggestion mostly useless. And considering the number of Windows users\n> we absolutely need to test Windows Terminal, and should probably test\n> MacOS's term too (whatever that is).\n\nQuite frankly, I think that such a solution would be like \"fixing the \nfix, which is actually an abuse\", as I described it above, eventually \nintroducing even more issues, instead of solving the original issue.\n\n>>> Dragan, that may be useful if you're discussing with less\n>>> developers...\n>> \n>> We've basically reached some kind of an agreement about the need for a\n>> good solution, which turned out to be rather complex as a result of\n>> being quite universal and extensible, which was required for it to,\n>> hopefully, be accepted into less(1).  Also, the author of less(1) \n>> seems\n>> to be quite busy with some other things, and he prefers to implement \n>> new\n>> features himself.\n>> \n>> We've also agreed on another new feature for less(1), hopefully, which\n>> isn't exactly related, but should be quite useful.  It's about the\n>> secure mode for less(1).\n> \n> Feel free to cc me on your next correspondence. If there are mailing\n> lists archives for the thread I'll fetch them as needed. We have at\n> least one working term/switch combination, which IMO is a better start\n> than nothing :)\n\nPlease test the \"--redraw-on-quit\" option, AFAICT that's all we need \n(plus the already mentioned other improvements to less(1), to avoid the \nversion-dependent workarounds), and the distributions will eventually \ncatch up with the newer versions of less(1).  If the whole thing has \nworked for decades as-is, it can continue working that way for a year or \ntwo until the packages get updated.\n\nThere's actually no two-way mailing list for less(1), the entire project \nis pretty much a one-man show, so to speak.  There's a GitHub page that \nallows issues to be submitted, but I didn't use that, so I exchanged a \nfew private email messages instead with the author.  I've already summed \nup the important parts of those messages.\n"},{"id":"484389","messageId":"24c46f25-6b31-437d-9f89-1e8eb74136c8@gmail.com","threadId":"60346","inReplyTo":"79cf1bf35ba6c9348735685b01e0f2f9@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Thomas Guyot","fromEmail":"tguyot@gmail.com","sentAt":"2023-11-03T11:47:39Z","receivedAt":"2023-11-03T11:47:43Z","isPatch":false,"sender":{"key":"tguyot@gmail.com","avatar":"https://avatars.githubusercontent.com/u/403890?v=4"},"body":"On 2023-11-02 10:19, Dragan Simic wrote:\n> On 2023-11-02 14:19, Thomas Guyot wrote:\n>> That's correct, you need both and also -y0\n> Hmm, I tried the following:\n>\n>       GIT_PAGER='less -R -F -X -c -y0'\n>\n> In my environment (Xfce), the result after scrolling the output of \"git\n> log -p\" up and down a bit was about 20 copies of the same screen \"page\"\n> in the scrollback, plus a couple of blank \"pages\".  Not good,\n> unfortunately, and actually much worse than having just \"-R -F -X\".\n\nIndeed, I did notice it with xfce4-term - I suspect different controls \nare used to clear the screen, with rxvt-unicode the initial one scrolls \nanything in the current display to the scrollback (which is important to \navoid clearing the last commands/output form the scrollback), but \nafterward screen updates do not update the scrollback, it remains within \nthe screen.\n\nThese options may actually affect the behavior (I have put my current \nvalues there)\n\n     secondaryScreen: True\n         Turn on/off secondary screen (default enabled).\n\n     secondaryScroll: True\n         Turn on/off secondary screen scroll (default enabled). If this\n         option is enabled, scrolls on the secondary screen will change the\n         scrollback buffer and, when secondaryScreen is off, switching\n         to/from the secondary screen will instead scroll the screen up.\n\nSo it appears I could disable secondaryScroll to avoid getting scrolled \nlines into the scrollback buffer. It's also noteworthy that with \nsecondaryScreen disabled, rxvt-unicode instead scroll things up to avoid \nthe current screen form being wiped out.\n>> Indeed, but when less update from the bottom, it can add new lines and\n>> let the overflow lines scroll up into the scrollback buffer.\n>>\n>> Then updating it from the top, it draws the whole page, top to bottom.\n>> That's fine for a full page but not desired for a partial one. Also\n>> note that on my terminal (rxvt-unicode) when less clears the screen to\n>> draw the first page the current screen is rolled up into scrollback -\n>> iirc that's a configurable option, it would be worth testing other\n>> terminal's behavior on that. IIRC it may also erase it when using the\n>> wrong termcap file.\n>>\n>> I haven't looked at the code, but I think it could be possibly to\n>> start the -c behavior only after a full page is drawn, after exiting\n>> on partial pages, which would give us the best of both worlds.\n> Does the GIT_PAGER setup, as I described it above, work for you without\n> the described artifacts, in any of the environments you have access to?\n\nYes, rxvt-unicode, with the settings mentioned above.\n\n>>> Just to clarify, it's the \"-X\" option that creates all the issues, and\n>>> the \"--redraw-on-quit\" option is already there to replace it with no\n>>> associated issues, but the trouble is that only newer versions of\n>>> less(1) support the \"--redraw-on-quit\" option.  IOW, it's all about\n>>> improving less(1) to avoid complex workarounds required to handle\n>>> different versions, such as the workarounds used in bat(1).\n>> TBH I haven't tested --redraw-on-quit, even on Debian Bookworm which\n>> was just released a couple months ago this option isn't available. I\n>> suspect that the issue isn't -X, but the scrolling behavior controlled\n>> by -y and the full redraw controlled by -c.\n> When you get into the terminfo entry definitions, the root cause is that\n> the terminal initialization sequences contain switching to alternate\n> screen, which causes screen contents to be lost when less(1) exits.\n> Thus, \"-X\" has been actually abused in the pager setups to skip the\n> terminal initialization sequences, which may also result in other\n> issues.\n\nRight - this is something that rxvt-unicode addresses with the correct \nsettings.\nIIRC I disabled the secondasyScreen to be able to use the scrollback \nbuffer (unavailable otherwise), which probably also means that with it \nenabled I would also have no issue without -X, but that would need \ntesting. Also note that rxvt-unicode has its own terminfo file \n(xfce4-term uses xterm), and in some places I'm forced to use xterm as a \nfallback I get issues like current screen being wiped when switching \nto/from secondary screen.\n> One of the solutions is to edit the terminfo entry manually and remove\n> the escape codes that cause the switching to and from alternate screen,\n> which I tested, but that also introduced another issue -- the screen\n> contents was always present after less(1) exited, which isn't always the\n> desired behavior.\n\nBut when less scrolls down (line by line, not page by page), it always \nappend lines and let them scroll up. Won't you see these? (page-by-page \notoh will redraw the full screen without scrolling).\n\nAlso won't it wipe the *current* screen so that you won't see the \ncommands/output you had *before* running less?\n\nThis is why rxvt-unicode has an option to disable secondary screen, and \nscroll contents all the way to the buffer on switch to/from secondary \nscreen.\n>> Actually I just tested my\n>> solution on xfce4-terminal and it doesn't work, the terminal still\n>> push up stuff above on redraw (noteworthy is with rxvt-unicode the\n>> first draw pushes the current screen contents up but no other redraw\n>> does, which is what makes it work so well - I haven't tried to find\n>> out what is being done exactly... OTOH the redraw on scroll down is\n>> slightly noticeable there, while impossible to see on xfce4-terminal.\n>> I'll install the latest less and see what happens with --redraw on\n> Please test the \"--redraw-on-quit\" option, so far it's the best\n> available solution, IMHO.\n\nI will, not now though - need it compile less form source I guess...\n>>>> If less could only enable this behavior after the first full page\n>>>> draw, that would be perfect!\n>>> Could you, please, elaborate a bit on that?\n>> I mentioned it slightly above, to be clear it would mean that:\n>>\n>> 1. less starts by just writing lined down as usual, making any lines\n>> above scroll up and overflow into the scrollback buffer as usual\n>> 2.  If less draws less than a page, exits as before - the effective\n>> result is as if pager was cat\n>> 3. If less reaches a full page and still has lines to write, it turns\n>> on -c's behavior and further updates happen from the top of the\n>> screen, preventing scroll up (at least on rxvt-unicode)\n>>\n>> Now, if all other terms misbehave here, that's an issue, making this\n>> suggestion mostly useless. And considering the number of Windows users\n>> we absolutely need to test Windows Terminal, and should probably test\n>> MacOS's term too (whatever that is).\n> Quite frankly, I think that such a solution would be like \"fixing the\n> fix, which is actually an abuse\", as I described it above, eventually\n> introducing even more issues, instead of solving the original issue.\n\nI'll let you know my findings... I'm not convinced --redraw-on-quit is \nactually going to fix it for all unless this does a lot more than the \noption name implies (but quite happy if it does).\n\nRegards.\n--\nThomas\n\n"},{"id":"484398","messageId":"CAHWeT-aftfawZ9DhqC1NkQrJAuArJZC65ZDr4FyPwEc7aXGVuA@mail.gmail.com","threadId":"60346","inReplyTo":"24c46f25-6b31-437d-9f89-1e8eb74136c8@gmail.com","subject":"Re: why does git set X in LESS env var?","fromName":"Andy Koppe","fromEmail":"andy.koppe@gmail.com","sentAt":"2023-11-03T15:28:12Z","receivedAt":"2023-11-03T15:28:27Z","isPatch":false,"sender":{"key":"andy.koppe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/223411?v=4"},"body":"Thomas Guyot wrote:\n> >> I actually have one major issue with it, it's that displaying anything\n> >> less than a full page will fill the screen with ~ on the bottom, just\n> >> like when scrolling up on a partial page  without -F.\n\n'less' has the '-~' (or --tilde) option to suppress that.\n\n> I mentioned it slightly above, to be clear it would mean that:\n>\n> 1. less starts by just writing lined down as usual, making any lines\n> above scroll up and overflow into the scrollback buffer as usual\n> 2.  If less draws less than a page, exits as before - the effective\n> result is as if pager was cat\n> 3. If less reaches a full page and still has lines to write, it turns on\n> -c's behavior and further updates happen from the top of the screen,\n> preventing scroll up (at least on rxvt-unicode)\n>\n> Now, if all other terms misbehave here, that's an issue, making this\n> suggestion mostly useless. And considering the number of Windows users\n> we absolutely need to test Windows Terminal, and should probably test\n> MacOS's term too (whatever that is).\n\nFor what it's worth, the 'mintty' terminal used by default for Git for\nWindows as well as MSYS and Cygwin has another approach to the whole\nproblem. Its rather flippantly named 'Flip Screen' context menu\ncommand with Alt+F12 or Ctrl+Shift+S shortcut lets users temporarily\nlook at the alternate screen buffer while the main screen buffer is\nactive, and vice versa.\n\nIf 'less' is invoked without the -X option, it will switch to the\nalternate screen, where mousewheel scrolling works by sending cursor\nup/down keycodes. While in 'less', you can temporarily flip to the\nmain screen to look up something in the shell session there or copy\nsomething for searching in 'less'. While looking at the main screen,\nthe mousewheel will scroll the scrollback buffer. Keyboard input\nthat's sent to 'less' will flip back to the alternate screen.\n\nQuitting 'less' switches back to the main screen, so the 'less' output\ndisappears and you're back in the shell session with the command that\ninvoked 'less' as the last thing shown. But again, the 'Flip Screen'\ncommand or shortcuts can be used to temporarily look at or copy from\nthe alternate screen, which will contain the last page displayed by\n'less'. (The alternate screen does not have a scrollback buffer.)\n\nThe 'Flip Screen' feature of course also works with other\nalternate-screen applications, for example editors.\n\nApparently the Mac terminal has such a feature as well:\nhttps://support.apple.com/en-ie/guide/terminal/trmld1f46097/mac\n\n(Full disclosure: I originally made mintty, from PuTTY.)\n\nKind regards,\nAndy\n"},{"id":"484407","messageId":"ba144b9b5ee0dd7cb51500fd7c8214e2@manjaro.org","threadId":"60346","inReplyTo":"24c46f25-6b31-437d-9f89-1e8eb74136c8@gmail.com","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-11-03T18:22:23Z","receivedAt":"2023-11-03T18:22:31Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-11-03 12:47, Thomas Guyot wrote:\n> On 2023-11-02 10:19, Dragan Simic wrote:\n>> On 2023-11-02 14:19, Thomas Guyot wrote:\n>>> That's correct, you need both and also -y0\n>> \n>> Hmm, I tried the following:\n>> \n>>       GIT_PAGER='less -R -F -X -c -y0'\n>> \n>> In my environment (Xfce), the result after scrolling the output of \n>> \"git\n>> log -p\" up and down a bit was about 20 copies of the same screen \n>> \"page\"\n>> in the scrollback, plus a couple of blank \"pages\".  Not good,\n>> unfortunately, and actually much worse than having just \"-R -F -X\".\n> \n> Indeed, I did notice it with xfce4-term - I suspect different controls\n> are used to clear the screen, with rxvt-unicode the initial one\n> scrolls anything in the current display to the scrollback (which is\n> important to avoid clearing the last commands/output form the\n> scrollback), but afterward screen updates do not update the\n> scrollback, it remains within the screen.\n> \n> These options may actually affect the behavior (I have put my current\n> values there)\n> \n>     secondaryScreen: True\n>         Turn on/off secondary screen (default enabled).\n> \n>     secondaryScroll: True\n>         Turn on/off secondary screen scroll (default enabled). If this\n>         option is enabled, scrolls on the secondary screen will change \n> the\n>         scrollback buffer and, when secondaryScreen is off, switching\n>         to/from the secondary screen will instead scroll the screen up.\n> \n> So it appears I could disable secondaryScroll to avoid getting\n> scrolled lines into the scrollback buffer. It's also noteworthy that\n> with secondaryScreen disabled, rxvt-unicode instead scroll things up\n> to avoid the current screen form being wiped out.\n\nThis is quite interesting.  However, we can't expect that the users \nperform such adjustments to their environments, if you agree.  Tweaking \none's own environment is fine, but the shipped solution should \"just \nwork\" in most environments, or ideally in all environments in their \noriginal form.\n\n>>> Indeed, but when less update from the bottom, it can add new lines \n>>> and\n>>> let the overflow lines scroll up into the scrollback buffer.\n>>> \n>>> Then updating it from the top, it draws the whole page, top to \n>>> bottom.\n>>> That's fine for a full page but not desired for a partial one. Also\n>>> note that on my terminal (rxvt-unicode) when less clears the screen \n>>> to\n>>> draw the first page the current screen is rolled up into scrollback -\n>>> iirc that's a configurable option, it would be worth testing other\n>>> terminal's behavior on that. IIRC it may also erase it when using the\n>>> wrong termcap file.\n>>> \n>>> I haven't looked at the code, but I think it could be possibly to\n>>> start the -c behavior only after a full page is drawn, after exiting\n>>> on partial pages, which would give us the best of both worlds.\n>> \n>> Does the GIT_PAGER setup, as I described it above, work for you \n>> without\n>> the described artifacts, in any of the environments you have access \n>> to?\n> \n> Yes, rxvt-unicode, with the settings mentioned above.\n\nGood to know, thanks.  Looking forward to see will the \n\"--redraw-on-quit\" option work as expected in your rxvt-unicode \nterminal.\n\n>> One of the solutions is to edit the terminfo entry manually and remove\n>> the escape codes that cause the switching to and from alternate \n>> screen,\n>> which I tested, but that also introduced another issue -- the screen\n>> contents was always present after less(1) exited, which isn't always \n>> the\n>> desired behavior.\n> \n> But when less scrolls down (line by line, not page by page), it always\n> append lines and let them scroll up. Won't you see these?\n> (page-by-page otoh will redraw the full screen without scrolling).\n> \n> Also won't it wipe the *current* screen so that you won't see the\n> commands/output you had *before* running less?\n> \n> This is why rxvt-unicode has an option to disable secondary screen,\n> and scroll contents all the way to the buffer on switch to/from\n> secondary screen.\n\nIIRC, when I tested by removing the escape codes manually from the \nterminfo entry, it all worked fine, but the screen contents always \nremained displayed after less(1) exited.  That isn't always the desired \nbehavior.\n\n>>> Actually I just tested my\n>>> solution on xfce4-terminal and it doesn't work, the terminal still\n>>> push up stuff above on redraw (noteworthy is with rxvt-unicode the\n>>> first draw pushes the current screen contents up but no other redraw\n>>> does, which is what makes it work so well - I haven't tried to find\n>>> out what is being done exactly... OTOH the redraw on scroll down is\n>>> slightly noticeable there, while impossible to see on xfce4-terminal.\n>>> I'll install the latest less and see what happens with --redraw on\n>> \n>> Please test the \"--redraw-on-quit\" option, so far it's the best\n>> available solution, IMHO.\n> \n> I will, not now though - need it compile less form source I guess...\n\nGreat, thanks.  Looking forward to the results of your testing.  As a \nreminder, this is what I use:\n\n     GIT_PAGER='less -R -F --redraw-on-quit'\n\nMy LESS environment variable contains only some coloring-related \noptions, which don't matter in this case.\n\n>>> Now, if all other terms misbehave here, that's an issue, making this\n>>> suggestion mostly useless. And considering the number of Windows \n>>> users\n>>> we absolutely need to test Windows Terminal, and should probably test\n>>> MacOS's term too (whatever that is).\n>> \n>> Quite frankly, I think that such a solution would be like \"fixing the\n>> fix, which is actually an abuse\", as I described it above, eventually\n>> introducing even more issues, instead of solving the original issue.\n> \n> I'll let you know my findings... I'm not convinced --redraw-on-quit is\n> actually going to fix it for all unless this does a lot more than the\n> option name implies (but quite happy if it does).\n\nActually, it's more about not (ab)using the \"-X\" option, because \nskipping the terminal initialization may cause various issues.  The \n\"--redraw-on-quit\" option is there just to have the screen contents \npreserved after less(1) exits.\n"},{"id":"484408","messageId":"db923ad4f3fba79e2a2e279f6d5aff16@manjaro.org","threadId":"60346","inReplyTo":"CAHWeT-aftfawZ9DhqC1NkQrJAuArJZC65ZDr4FyPwEc7aXGVuA@mail.gmail.com","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-11-03T18:38:09Z","receivedAt":"2023-11-03T18:38:16Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-11-03 16:28, Andy Koppe wrote:\n> Thomas Guyot wrote:\n>> >> I actually have one major issue with it, it's that displaying anything\n>> >> less than a full page will fill the screen with ~ on the bottom, just\n>> >> like when scrolling up on a partial page  without -F.\n> \n> 'less' has the '-~' (or --tilde) option to suppress that.\n\nGood to know, thanks.  However, with the \"-F\" option in place, the \nsituation in which less than a full page is displayed within less(1) \nshouldn't be encountered.\n\n> For what it's worth, the 'mintty' terminal used by default for Git for\n> Windows as well as MSYS and Cygwin has another approach to the whole\n> problem. Its rather flippantly named 'Flip Screen' context menu\n> command with Alt+F12 or Ctrl+Shift+S shortcut lets users temporarily\n> look at the alternate screen buffer while the main screen buffer is\n> active, and vice versa.\n\nThis is a rather neat feature.  Though, I wonder how many users are \nactually aware of this feature, and how frequently is it used.  I wasn't \naware of it, and I used Git CLI on Windows for some time.\n\n> If 'less' is invoked without the -X option, it will switch to the\n> alternate screen, where mousewheel scrolling works by sending cursor\n> up/down keycodes. While in 'less', you can temporarily flip to the\n> main screen to look up something in the shell session there or copy\n> something for searching in 'less'. While looking at the main screen,\n> the mousewheel will scroll the scrollback buffer. Keyboard input\n> that's sent to 'less' will flip back to the alternate screen.\n\nTo me, this is another confirmation that (ab)using the \"-X\" option is \nsomething that we need to get rid of, as I already described earlier in \nthis email thread.\n\n> Quitting 'less' switches back to the main screen, so the 'less' output\n> disappears and you're back in the shell session with the command that\n> invoked 'less' as the last thing shown. But again, the 'Flip Screen'\n> command or shortcuts can be used to temporarily look at or copy from\n> the alternate screen, which will contain the last page displayed by\n> 'less'. (The alternate screen does not have a scrollback buffer.)\n> \n> The 'Flip Screen' feature of course also works with other\n> alternate-screen applications, for example editors.\n> \n> Apparently the Mac terminal has such a feature as well:\n> https://support.apple.com/en-ie/guide/terminal/trmld1f46097/mac\n\nMaybe there is some data available about how frequently this neat \nfeature is used?  It would be really good to know how much is it \nactually used.\n\n> (Full disclosure: I originally made mintty, from PuTTY.)\n\nThanks for your work!\n"},{"id":"484448","messageId":"5752129cbefe064a10e57e1b628e516c@manjaro.org","threadId":"60346","inReplyTo":"79cf1bf35ba6c9348735685b01e0f2f9@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2023-11-06T03:47:54Z","receivedAt":"2023-11-06T03:47:59Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2023-11-02 15:19, Dragan Simic wrote:\n> On 2023-11-02 14:19, Thomas Guyot wrote:\n>> On 2023-11-02 02:48, Dragan Simic wrote:\n>>> We've basically reached some kind of an agreement about the need for \n>>> a\n>>> good solution, which turned out to be rather complex as a result of\n>>> being quite universal and extensible, which was required for it to,\n>>> hopefully, be accepted into less(1).  Also, the author of less(1) \n>>> seems\n>>> to be quite busy with some other things, and he prefers to implement \n>>> new\n>>> features himself.\n>>> \n>>> We've also agreed on another new feature for less(1), hopefully, \n>>> which\n>>> isn't exactly related, but should be quite useful.  It's about the\n>>> secure mode for less(1).\n>> \n>> Feel free to cc me on your next correspondence. If there are mailing\n>> lists archives for the thread I'll fetch them as needed. We have at\n>> least one working term/switch combination, which IMO is a better start\n>> than nothing :)\n> \n> Please test the \"--redraw-on-quit\" option, AFAICT that's all we need\n> (plus the already mentioned other improvements to less(1), to avoid\n> the version-dependent workarounds), and the distributions will\n> eventually catch up with the newer versions of less(1).  If the whole\n> thing has worked for decades as-is, it can continue working that way\n> for a year or two until the packages get updated.\n> \n> There's actually no two-way mailing list for less(1), the entire\n> project is pretty much a one-man show, so to speak.  There's a GitHub\n> page that allows issues to be submitted, but I didn't use that, so I\n> exchanged a few private email messages instead with the author.  I've\n> already summed up the important parts of those messages.\n\nGood news! :)  The author of less(1) has implemented a couple of new \nfeatures that should resolve our issues with the pagination.  The \nimprovements for the secure mode of less(1) have also been implemented.  \nI'll test all that in detail, and I'll move forward with implementing \nthe required changes in Git.\n\nIt seems that a new version of less(1) may also be released rather soon, \nso we might be on a good way to have these longstanding issues resolved \nin the upcoming releases of Git and less(1).  It will take time for the \nLinux distributions to catch up with their package versions, but also \nthe rolling-release distributions will get the new versions with no \ndelays.\n"},{"id":"491155","messageId":"8289ef15266172cbfa10bb146afe9797@manjaro.org","threadId":"60346","inReplyTo":"5752129cbefe064a10e57e1b628e516c@manjaro.org","subject":"Re: why does git set X in LESS env var?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-03-21T15:53:16Z","receivedAt":"2024-03-21T15:53:18Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello all,\n\nOn 2023-11-06 04:47, Dragan Simic wrote:\n> On 2023-11-02 15:19, Dragan Simic wrote:\n>> On 2023-11-02 14:19, Thomas Guyot wrote:\n>>> On 2023-11-02 02:48, Dragan Simic wrote:\n>>>> We've basically reached some kind of an agreement about the need for \n>>>> a\n>>>> good solution, which turned out to be rather complex as a result of\n>>>> being quite universal and extensible, which was required for it to,\n>>>> hopefully, be accepted into less(1).  Also, the author of less(1) \n>>>> seems\n>>>> to be quite busy with some other things, and he prefers to implement \n>>>> new\n>>>> features himself.\n>>>> \n>>>> We've also agreed on another new feature for less(1), hopefully, \n>>>> which\n>>>> isn't exactly related, but should be quite useful.  It's about the\n>>>> secure mode for less(1).\n>>> \n>>> Feel free to cc me on your next correspondence. If there are mailing\n>>> lists archives for the thread I'll fetch them as needed. We have at\n>>> least one working term/switch combination, which IMO is a better \n>>> start\n>>> than nothing :)\n>> \n>> Please test the \"--redraw-on-quit\" option, AFAICT that's all we need\n>> (plus the already mentioned other improvements to less(1), to avoid\n>> the version-dependent workarounds), and the distributions will\n>> eventually catch up with the newer versions of less(1).  If the whole\n>> thing has worked for decades as-is, it can continue working that way\n>> for a year or two until the packages get updated.\n>> \n>> There's actually no two-way mailing list for less(1), the entire\n>> project is pretty much a one-man show, so to speak.  There's a GitHub\n>> page that allows issues to be submitted, but I didn't use that, so I\n>> exchanged a few private email messages instead with the author.  I've\n>> already summed up the important parts of those messages.\n> \n> Good news! :)  The author of less(1) has implemented a couple of new\n> features that should resolve our issues with the pagination.  The\n> improvements for the secure mode of less(1) have also been\n> implemented.  I'll test all that in detail, and I'll move forward with\n> implementing the required changes in Git.\n> \n> It seems that a new version of less(1) may also be released rather\n> soon, so we might be on a good way to have these longstanding issues\n> resolved in the upcoming releases of Git and less(1).  It will take\n> time for the Linux distributions to catch up with their package\n> versions, but also the rolling-release distributions will get the new\n> versions with no delays.\n\nGood news, new beta version 653 of less(1) has been released! [1]\n\nVersion 653 contains new pagination-related features (in particular,\nLESSKEY_CONTENT and LESS_UNSUPPORT) I asked the less(1) author for,\nwhich will finally resolve age-old pagination issues in git and\na few other upstream projects.\n\nI'll test the new beta version, after which I'll start working on\nthe required patches for git and a few other upstream projects.\n\nLooking forward to resolving those age-old pagination issues! :)\n\n[1] https://greenwoodsoftware.com/less/news.653.html\n"}]}