Open toastal opened 1 year ago
On Thu, Dec 22, 2022 at 08:44:52AM -0800, toastal wrote:
Humans prefer to read text that's about 55 to 65 characters per line. Terminals aren't required but are recommended to stick to 80 characters (it may have been what the unused MAX_WIDTH was in this commit). Unless I'm in a tiling split or in a multiplexer session, I'm likely in a full screen context where I can get 200 characters or more to a line and it's not manageable to read. Because of this, I would like to be able to set a max characters per line so the text is comfortable to read regardless of how big my terminal is.
JFTR, related Debian bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825790 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941335
Tracked here: https://todo.sr.ht/~rkta/w3m/23
Patch exists and will be merged into my branch 'next' after some more testing.
That would be cool -- toastal ไข่ดาว | https://toast.al PGP: 7944 74b7 d236 dab9 c9ef e7f9 5cce 6f14 66d4 7c9e
On Sun, Aug 25, 2024 at 08:18:27AM -0700, toastal wrote:
That would be cool
Could you checkout my branch 'cols' from https://git.sr.ht/~rkta/w3m and see if it works for you? Thanks!
@rkta this worked for me as a flag… but I didn’t see how to set the value in the config file. Did I miss something? Also are you taking on the maintainership, & if so are you opening tickets on SourceHut too, or is issue tracking staying on this proprietary Microsoft GitHub repository?
On Tue, Aug 27, 2024 at 10:32:06AM -0700, toastal wrote:
@rkta this worked for me as a flag…
Thanks for testing!
but I didn’t see how to set the value in the config file. Did I miss something?
No, you did not miss something. I just implemented it only as a flag. Probably because that's how it was reported in other reports. After re-reading your issue here I see what you meant. Seems reasonable to me. I will try how I can implement this.
To be clear: I add an option which sets a maximal text width, so that only if the terminal is wider the text is wrapped at this limit, right?
Also are you taking on the maintainership,
I'm waiting for tats to come back to me so we can work out how we will proceed in the future. Until that, I maintain w3m at my fork, yes.
if so are you opening tickets on SourceHut too, or is issue tracking staying on this proprietary Microsoft GitHub repository?
I have a todo tracker at https://todo.sr.ht/~rkta/w3m. While anyone can open a ticket there I strongly prefer if people reach out to the mailing list0 first. Then I will open a ticket, if necessary. If one, for whatever reason, does not want to reach out to the ML, I can be reached via email and on #w3m on libera.chat.
I'm still subscribed here, though, and will react to activity here.
github will censor out any mail address if you reply by mail FYI.
arg... Thanks @N-R-K
It's: ~rkta/w3m@lists.sr.ht
@toastal I added a commit which adds a option for this. Can test if this works as expected for you? Note, that you need to restart w3m to make any change effective when changing the value from the options panel.
@rkta Worked great in the $HOME/.w3m
folder (non-XDG) config file. The only enhancement might be to center the text vs left aligning it—which would make a better ‘zero distraction’ mode, but keeping the line length cap is helping readability for me which is ‘good enough’.
On Thu, Aug 29, 2024 at 01:08:49AM -0700, toastal wrote:
@rkta Worked great in the
$HOME/.w3m
folder (non-XDG) config file.
Thanks for testing and reporting back.
The only enhancement might be to center the text vs left aligning it—which would make a better ‘zero distraction’ mode,
Yes, would certainly look nicer. I will put this on my todo list. This probably needs some refactoring first as I don't think there is a single place were I could apply the indenting needed for this.
I wouldn’t make centering a blocker, but rather a separate enhancement
On Thu, Aug 29, 2024 at 04:46:35AM -0700, toastal wrote:
I wouldn’t make centering a blocker, but rather a separate enhancement
This was the idea. I already staged the commits.
Humans prefer to read text that's about 55 to 65 characters per line. Terminals aren't required but are recommended to stick to 80 characters (it may have been what the unused MAX_WIDTH was in this commit). Unless I'm in a tiling split or in a multiplexer session, I'm likely in a full screen context where I can get 200 characters or more to a line and it's not manageable to read. Because of this, I would like to be able to set a max characters per line so the text is comfortable to read regardless of how big my terminal is.