From: GitHub Chris Idema Date: Mon, 26 Jan 2026 15:21:06 GMT Subject: Re: [PATCH] diff.tcl: fixed alignment of tabs in git-gui diff by using spaces Message-ID: In-Reply-To: <5ab10a31-8ee5-48f9-a5fd-63c6d7f4adcf@kdbg.org> > I am not particularly fond of such a change. Years and years of reading patch text has trained my brain to expect such misalignment to the extent that even the absence of misalignment can sometimes indicate a whitespace error. The problem is not just incorrect alignment. It's also inconsistency. In gitk the alignment is correct. In the git gui window it's not. The best solution would be to make the git gui window behave like gitk. I thought my change only affected the way it was displayed. I'm going to see if there is a better way. -- Chris -------- Original Message -------- On Monday, 01/26/26 at 15:52 Johannes Sixt wrote: Am 26.01.26 um 15:43 schrieb GitHub Chris Idema: >> So, you mean that if the tab width is set to 4, then the tab stops >> are not aligned anymore? > > Indeed. It's probably due to the + character shifting everything by 1 character. BTW, this isn't a problem with a particular tab width. It happens with the default width 8 as well. >> My suspicion is that the patch text does not match the actual file >> contents, and so the commands fail. > > If you select and copy the text from the window with you mouse it > won't match the patch. I didn't know people used it that way. I use > it as a way to review my changes before staging. I don't mean copy-and-paste. I mean the context menu commands. They stop working (I suspect). This would be a show-stopper. > I don't know if there is a way to make it that when you copy it will > copy the original text and no the modified text. If not then we > should come up with a better way to align stops. I am not particularly fond of such a change. Years and years of reading patch text has trained my brain to expect such misalignment to the extent that even the absence of misalignment can sometimes indicate a whitespace error. -- Hannes