Comment by ~skejg on ~bptato/chawan
And thanks again for fixing, everything looks OK now :)
Comment by ~skejg on ~bptato/chawan
~bptato
Well.... That's not all, it seems :)
I have a cgi script, which wraps the current html page in a table, adding left and right columns to narrow down the reading area. Basically it curls a page and pipes it to awk:
awk ' BEGIN{ print "Content-type: text/html\n\n" } /<body/{ sub(/<body[^>]*>/, "<body><table><tbody><tr><td width=\"20%\"></td><td>") } /<\/body>/{ sub(/<\/body>/, "</td><td width=\"20%\"></td></tr></tbody></table></body>") } { print }'With the commit a68e17b7 (and
buffer.stylingdisabled), it's now broken. Settingbuffer.stylingtotruemakes it work. Except there's no style here, I'd say :)
Comment by ~skejg on ~bptato/chawan
Can confirm, works for me.
Thanks!
Comment by ~skejg on ~bptato/chawan
Users would have to learn about x-needsstyle only if they set styling=false and added a custom x-htmloutput mailcap entry and wished to use CSS in that entry. Probably not too much of a burden to read the docs at that point :P
Agreed, that sounds reasonable (both the scheme and the docs reading condition :)
If you mean "just ignore the styling option on x-htmloutput"
I thought more about "just ignore this option for this protocol". But your proposed solution above seems like a way better approach.
Comment by ~skejg on ~bptato/chawan
Or, better: we could add a mailcap extension field like x-needsstyle and set it only on formats that output built-in styles, so that styling can still affect HTML dialects like Markdown where author styles exist.
That would require a user to learn and do something new and non-standard about the mailcap, or am I mistaken? My point is, people rarely read the documentation in general -- and especially about the things they think they already know and use :)
I personally would just put a guard in the code to ignore certain configuration values on certain occasions. But maybe it's a bad practice or would have some caveats...
Comment by ~skejg on ~bptato/chawan
Aesthetically, a menu would, in my opinion, look a lot cleaner and, therefore, better :). However, you are right that it may appear challenging to find the right link. Besides, the menu approach is only known to w3m users, while the hints mode would be already familiar to anyone, who was previously accustomed with some of its variations via numerous extensions for GUI browsers (or even at the OS level), so the UX would be more widespread and even to some degree more consistent.
The menu approach would probably require more interaction from a user, too: when opening a menu, a user will have to scroll it with their eyes to find the right link (and maybe even press some additional keys for that). While with the hints, a user is usually already looking at the link they want to jump or to open. Then they invoke the hints mode, and the hint appears exactly at their sight, so they just press it -- and voilà.
However, in the end, of course, it's up to you, the developer, to decide, which way to choose. Unfortunately, can't really help you much here :).
~skejg wrote:
I found the culprit, it's
buffer.styling, when set totrueeverything looks fine, and your test returns two lines (and when set tofalse, it's one line, 'testtest').As a workaround, it can be toggled with a siteconf option, of course. But in general, unless I'm very wrong, Gemini sites don't really have styles, and
buffer.stylingprobably shouldn't apply to them?Oh.
Well, intuitively they don't have styles. But in the background, gemtext gets converted to HTML, and then
<body>getswhite-space: pre-lineto match the spec-mandated formatting style.That does make
stylingas a global parameter somewhat unusable. Maybe it shouldn't affect x-htmloutput's inline styles at all?Or, better: we could add a mailcap extension field like x-needsstyle and set it only on formats that output built-in styles, so that
stylingcan still affect HTML dialects like Markdown where author styles exist.
Comment by ~skejg on ~bptato/chawan
Thanks! Can confirm, it works as advertised now.
Comment by ~skejg on ~bptato/chawan
I found the culprit, it's
buffer.styling, when set totrueeverything looks fine, and your test returns two lines (and when set tofalse, it's one line, 'testtest').As a workaround, it can be toggled with a siteconf option, of course. But in general, unless I'm very wrong, Gemini sites don't really have styles, and
buffer.stylingprobably shouldn't apply to them?
