Hi Branden, On Sun Feb 16, 2025 at 4:19 AM CET, G. Branden Robinson wrote: > At 2025-02-09T03:48:33+0100, onf wrote: > > On Sun Feb 9, 2025 at 3:20 AM CET, onf wrote: > > > [...] > > > TL;DR: > > > With the default settings, a tab essentially translates into a > > > horizontal motion. [...] > > > This is because tab stops are related to the beginning of a paragraph > > > rather than the beginning of an output line as one would expect. > > > > > > The desired behavior can be enabled with the request .linetabs, > > > but this is groff-specific and not supported by other troffs. > > > > By the way, Branden, are you aware of any use case where the default > > behavior is actually desirable? I am contemplating patching neatroff > > to behave like groff with enabled linetabs mode outside compatibility > > mode... > > No, I'm not. If anyone has such a scenario, I'd appreciate hearing > about it so I can add something like it to groff's Texinfo manual. > > I haven't thought about it deeply, let alone experimented, but the > reason for the status quo might have something to do with the way > leaders are handled. Recall that leaders by default are basically > motions to the next tab stop that are made visible with repeated `.` > characters. > > It then helps to recall the, ahem, leading use case of leaders. > _Possibly_, things go wrong if you enable "line-tabs" mode and then try > to set a multi-line table of contents entry. Perhaps it screws up as > the line length varies. > > Just a guess, but it's the sort of scenario I'd poke at before deciding > upon a reform of the default.
Actually, setting table of contents items was what lead me to discover .linetabs in the first place, because without it, multiline TOC items break when left-adjusted. It doesn't work as it should even with linetabs, though, which might be a bug. Sorry for not reporting this earlier, I kinda forgot about it. I just filed a bug on Savannah: https://savannah.gnu.org/bugs/?66805 ~ onf
