💾 Archived View for rawtext.club › ~mieum › relog › 2020-08-29-bouncepaw-on_hardwrap.gmi captured on 2022-01-08 at 13:45:07. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-03)

-=-=-=-=-=-=-

Re: on hardwrap

gemini://tanelorn.city:1965/~bouncepaw/gemlog/hardwrap.gemini

Hardwrap should be avoided.

I've had to think too much about hard breaks lately, so I'll take this opportunity to vent a little!

I write long manuscripts in pandoc markdown without hard breaks. I have found, though, that syntax highlighting scripts for Vim and Emacs prefer hard breaks for different reasons. In Emacs, some footnote markup will cause the text which follows it to be erroneously highlighted until the next occurrence of a bracket. It is a weird bug, but according to the issue tracker on github, inserting hard breaks into the paragraph will correct the highligting. In Vim, I had a lot of trouble with the pancoc-markdown-syntax highlighter lagging like crazy. The problem stopped after making a bunch of changes to my configuration (many unrelated to syntax highlighting), but I haven't located the certain cause. It apparently was weighed down by the Jumbo-Sized markdown lines, especially with lots of citations and fun embellishments. A workaround is to increase the "redrawtime" in your .vimrc, but it still takes a while to load large documents. Another factor could be the actual source of your color scheme. When I was having the trouble, I was using the official Solarized vim colorscheme. It is quite thorough, and works correctly with pandoc's highligting, but perhaps something about the two cause them to work to hard against each other?

One last note. A librarian friend of mine warned about using hard breaks for markdown (or any other kind of markup for the purpose of document creation). Technically, markdown will render them as expected: a cohesive paragraph. But markdown is not standardized, and depending on the implementation, you may end up having to do more work with the text than you should need to.

This coincides with part of Gemini's design philosophy. The text is provided as-is to the client for rendering, which makes more sense, not only because screen size varies, but also because it keeps the strings intact, making them portable and formatable~

Anyway, that's just my inexperienced and uninformed two-cents on hardwrap.

_________

./ Gemlog

../ Home

CC-BY-NC-SA 4.0 mieum(at)rawtext.club