Many LaTeX tricks only get passed down from advisors to students, or from collaborators to collaborators. Rarely someone would look for how to improve their typesetting when all they want is to quickly communicate content.
It be nice if content and typesetting can be completely separated, where I just write content, and something (LaTeX, AI, some manual typesetter) does all the typesetting.
Also, should I be the one controlling how the reader consume my content? Maybe the reader prefers another font? Or the reader is viewing in a kindle so pdf page size should be different?
This would be impossible unless the reader have my LaTeX source code and compile it themselves. But it is super simple for epub, or html webpage (by modifying the css).
To a certain degree, the LaTeX environment is already like that. I designed my custom resume style years ago and rarely touch it. I often tweak the actual content which gets poured into the style to produce the final document. The few changes I’ve made to the style have never affected the (separate) content either.
> Many LaTeX tricks only get passed down from advisors to students, or from collaborators to collaborators.
Which is a great point on why the average quality of LaTeX homework submissions by undergraduates without any research experience usually makes for a less-than-ideal grading experience. And this is not about the nit-picky mistakes, but the visually glaring ones.
> This would be impossible unless the reader have my LaTeX source code and compile it themselves. But it is super simple for epub, or html webpage (by modifying the css).
Well ..., wouldn't the html page be the source code in this case? Also, in most cases changing the look of a LaTeX document is as simple as changing the docuent class or switching to a different package. Also, modifying CSS is anything but simple in some cases, especially when the original style is not ideal.
+1 for quarto, i wrote my thesis in rmarkdown which flipped easily between latex and html output, with a bibtex referencing system. It also allowed you to inline latex for more complex outputs. And inlining calculated tables and charts meant i could keep my writing and code together. Quarto is the successor.
It looks really nice! I’ve sent this to a few friends to check it out.
To give some context, I'm a professor in theoretical computer science, so I write a lot of LaTeX documents and notes.
Some observations of my work flow.
- Writing: I'm writing the source, and occasionally look at the output. So as long as the output time is reasonable, then it is sufficient.
- Editing: I'm reading the output, and then edit the source. So going from the output to the part of the source I have to edit should be as smooth as possible.
- Typesetting is the least of my concern. I only check if there are any glaring typesetting problems right before we publish. This takes at most 1% of the total time in preparing a document.
- Live editing almost never happen. But I see why it might be useful to incorporate it into the work flow. (A cursor on the rending of the live editing would be very nice)
There are some choices on how to present source and the rendering.
Typst went with the 2 panel design, with one side source, one side rendering.
So I found something close to WYSIWYG is better for editing. However, full WYSIWYG is hard to get right and comes with its own problem. Currently I found there are a few common things people do with respect to source/rendering.
- WYSIWYG editors, which renders everything (word, TeXmacs, Lyx). Editing is done in the rendering. It is smooth, but takes a long time to get used to.
- The app Typora that renders everything except the part where you are editing (which shows as the source). This can be generalized to render all except the current line, or something similar. Editing is done in the source, but feels like I'm editing in the rendering. This is extremely smooth for my editing work, and is my preferred way.
- The app like Compositor https://compositorapp.com/ that renders everything, but can call out the selected part of the source.
- The source and render are in two different panels. Editing is done in the source. So usually one can click part of the rendering, and cursor jumps to the corresponding part of the source. This introduce some friction, as the eyes have to do a jump, and also a quick context switch.
I understand this is useful for people who doesn't type math regularly, but as someone who write a huge amount of math, `$...$` is so much less friction than the LaTeX one `\(...\)`.
Even in LaTeX, mix and match. `$...$` for normal mode, and `\[...\]` for display math, and it works well for two reasons. Inline math are generally short, less prone to mistakes, so `$` saves a lot of time.
Recently I have been testing vditor, vditor is a markdown editor that have a instant rendering feature [1]. If I'm creating my own editor, how hard is it to implement it using Lexical?
But not for most markdown files, at least how I use it. I only start new line (actually, 2 new lines) when I reach a new paragraph, and I think this is normal for most people who ever write something in markdown.
So now I get a huge 2000 character line with a few small edits, and I can hardly see where the changes are.
> I think this is normal for most people who ever write something in markdown
I recognize that I am not normal and this doesn't contradict your assumption, but I use Emacs' fill command to hard-wrap long lines at ~80 characters when I'm writing Markdown. In fact, it's so habitual for me that it causes me problems when writing Gemtext. I keep meaning to disable filling in gemini-mode.
> But not for most markdown files, at least how I use it. I only start new line when I reach a new paragraph, and I think this is normal for most people who ever write something in markdown.
Markdown treats lines separated with a single line break as a continuous line/the same paragraph, and you need to add two or more newlines for Markdown to interpret it as a new paragraph.
> But how does someone take advantage of it without changing their current behavior: write an entire paragraph and do 2 line breaks.
I don't understand your question. Markdown's syntax already requires 2+ newlines to define a paragraph. There should be no change in a workflow if you're already using Markdown.
The only nuance is that if you want git to track changes in each sentence that forms a paragraph, just add a single line break after the punctuation mark. Markdown still interprets that as the same text block, but git is able to handle changes per line.
Hmm, interesting. I've not yet come across a situation where I'd need diffing or going back to a change or looking for one. I just use git for syncing.
Hard line wrapping is not a panacea in this regard, like when you have a words added/removed from a line and then you get a cascading series of changes for the rest of the paragraph as you rewrap it.
i think it depends on your writing style. i tend to do a lot of outlining with bullet points so it works pretty well. for longer paragraphs it can definitely be a pain
This does not align with my experience of people working in OR.