Charles Zhang <csalin...@gmail.com> wrote: > However, if the author considers an email to be preformatted text and does > not intend it to be reflowed, f=f should be disabled for this email. > Generally it's not encouraged to send patches as f=f, as per the current > lkml guide [2].
Right, and most messages are not f=f nowadays. Every commit message in a patch email is expected to be preformatted as it ends up being viewed via `git log' in a terminal. > On Tue, Feb 14, 2023 at 07:35:56AM +0000, Eric Wong wrote: > > It's of utmost importance that users with broken graphics > > drivers be able to access public-inbox instances and download > > patches from the terminal (which may be required to fix their > > graphics drivers). > > public-inbox makes the raw email easily available through a link. That's > what I usually use to download a patch from mailing list. f=f won't affect > this functionality. I hope users will read a thread before deciding to download and apply a patch, though (and not mindlessly downloading + applying patches w/o context). > > Right. Using <pre> everywhere makes it easy to get a WYSIWYG > > experience for everyone, regardless of which browser they use > > (or even if it's just `curl $URL | $PAGER'). > > I might be trolling, but using preformatted text won't guarantee identical > representation at client side, due to possible wrapping and truncation by a > narrow-sized terminal. Feel free to ignore this point if feel so. 80 columns is the only width that has any sort of standardization behind it. Keeping messages <=80 columns ought to ensure it's OK for anybody reviewing patches because that's the most widely-standardized width for code. Obviously, if somebody is using a 60-column display then they're in for a hard time working on any project. > > The goal of our HTML isn't to be an end-all, be-all UI; > > but rather a way to bring a mutt-like experience to more users > > (and maybe drive local MUA adoption in the process). > > Speaking for myself, I'm mostly a read-only user of mailing lists. I would > like to follow some mailing list discussions more easily on a phone browser. > I expect f=f will improve the experience on phones (though such emails are > not that common). Currently the web page is subject to automatic font size > adjustment on phone browsers (called "font boosting" for mobile Chrome. > haven't tried to find the origin of this name). For preformatted text it > leads to ragged lines that are unpleasant to read. Given the lack of f=f messages on mailing lists (and f=f being actively discouraged); I doubt adding f=f to public-inbox would make a difference to people reading messages on a phone. Fwiw, the use of small phone displays is likely a passing phase. I've seen some fold-out phones with larger displays, and augmented reality glasses/contacts may become common one day. (and I'll still carry an ancient laptop with a good keyboard) > I still appreciate your work on public-inbox a lot. The web interface is > intuitive to use, and the search function is really helpful for digging into > the archive. Google seems to have given up on indexing mailing list archive > pages in past five years. Thanks again for the feedback. Of course, it's not in any corporation's interest to promote things they can't monetize. > [2] https://www.kernel.org/doc/html/v6.1/process/email-clients.html
