Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs 31: An unofficial guide to Markdown-ts-mode

rahuljuliato.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#71

Post by ngai_aku »

ggm wrote: post #58

So I can get bold at a cost of shift* to get the star. Or I can do ESC enable-this-mode-option and then press a single key. I'm struggling with this. If it's cheaper in keystrokes to type the codes inline why enable the mode? This isn't a vi vs emacs hate thing, It's a key count efficiency thing. I don't see the motivation even if translated to minimum prefix TAB complete terms. Its like 20x more presses.

I don’t think TFA meant to suggest that everyone should upend their current practices for the emphasize function. But I can see someone who is less familiar with the myriad of ways to emphasize, or the markers which signify the emphasis, appreciating what it offers

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#72

Post by ggm »

ngai_aku wrote: post #71
ggm wrote: post #58

So I can get bold at a cost of shift* to get the star. Or I can do ESC enable-this-mode-option and then press a single key. I'm struggling with this. If it's cheaper in keystrokes to type the codes inline why enable the mode? This isn't a vi vs emacs hate thing, It's a key count efficiency thing. I don't see the motivation even if translated to minimum prefix TAB complete terms. Its like 20x more presses.

I don’t think TFA meant to suggest that everyone should upend their current practices for the emphasize function. But I can see someone who is less familiar with the myriad of ways to emphasize, or the markers which signify the emphasis, appreciating what it offers

Yes. I also believe this motivation but a counter argument was put to me by Mike Lesk in the mid 80s. Bell did serious experiments on library query systems and the casual helpful, verbose ones were only useful for a brief period in any library index users lifetime, they moved to the terse, harder to learn, efficient one as soon as they could.

So, it's a universal feature of Emacs all things glue in like this but the strong likelihood is power users use terse brief commands more, more effectively.

I use Emacs org mode a lot and the only M-x command I use frequently is the column deletion because I seem not to use it enough to learn the brief form, but do need to do columnar edit stuff.

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#73

Post by kodoman »

iLemming wrote: post #43
kodoman wrote: post #33

Earlier quoted context omitted.

Else where in this thread you can see my argument is that all org-mode features such as calendar dates, todo's, take your pick could be implemented separate to and utilize markdown (or any other format) for actually rending to. I am familiar with org mode but dislike how it sometimes pushes against simply using elisp for things like setting up todo nodes and possible todo values. couple that with the fact that one co…

Rendering Org in markdown is a solved problem, but wanting Markdown as the source is nuanced. It's difficult to achieve because there's no single agreement or convention - Org is not just markup syntax, its headings have records with types slots: TODO keyword, priority, tags, properties drawer, clock entries, etc. - Markdown has none of this. A CommonMark heading is a line of text; the spec does not even define a sub…

The idea was minor a minor mode not to modify markdown mode it's self. You have a point on export from org mode to md or html or whatever but my issue with these has been that MD never rendered the way I wanted it to (simply as possible) and I probably did not try hard enough to play around with the rendering parameters.

The thing I have found more and more is separate from the actual rendering format is wanting org structures that are simpler to manipulate pragmatically I know that one could can simply manipulate as they would any text-buffer but that can be a little convoluted.

All that is to say my original proposal was probably hasty and poor and it sounds like you know org inside and out and I don't so although I use emacs heavily and love it I sort of fell out love with org mode and having this conversation it seems like I probably need to go and read up on it a lot more in light of all of this thank you.

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#74

Post by kqr »

geokon wrote: post #69
taude wrote: post #11

One of the biggest reason I've stopped using Emacs, and I was a pretty heavy user before was that org-mode files weren't fully native Markdown files, which caused annoying friction when collaborating with others. It would be interesting for me to have a new markdown-centric org-mode thing. I'd love to vibe lisp to customize my workflows, and I don't totally love Obsidian, which is what I've setup and configured now.…

Asciidoc is a nice middle ground between the full suit of tools you get in Orgmode and bare Markdown. To me Orgmode (after years of using it) feels like .docx. A weird poorly specified format that is only fully editable from one editor. Granted you ran read it from anywhere, but you won't want to edit it from anywhere other than Emacs. That feels like it defeats the point of using markup - which is supposed to be edi…

> A weird poorly specified format that is only fully editable from one editor.

While this has been true historically, the Org maintainers are moving away from that approach.

The example that comes to mind is that parsing and interpretation of formatting markup such as *bold* and /italics/ used to be controllable by Emacs Lisp variables that dictate things like which neighbouring characters cancel the interpretation of the markup as markup, or the maximum allowed distance between delimiters for them to count as a pair. Such things have been moved into standardised parsing routines now, with no variables for customising it.

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#75

Post by jlokier »

iLemming wrote: post #49
kodoman wrote: post #38

Earlier quoted context omitted.

I really don't dislike org-mode and respect it and you are right that org-mode was first. The point is that markdown could have todo's or virtually any other aspect that org mode supports put into it without changing the markdown standard and layer org functionality and various features on top for example todo's could simply be italic's starting with todo: so `# todo:todo hello` could be parsed as a todo entry marked…

It's not that simple. The formats differ structurally. Org-mode is a proper tree - that's its fundamental basis. A tree where each branch can hold k/v pairs of metadata. Markdown is rather a flat sequence of blocks with level markers sprinkled in. Neither of that (proper tree or records) fundamentally supported in Markdown within an agreed spec - pandoc attach attributes on its own way, kramdown does it differently,…

It would probably be enough if Org files could use Markdown for the free text parts, tables, headings and blockquotes, while keeping Org format for its key-value properties and structure other than headings, when those optional parts are used.

(Though Markdown's inability to nest Markdown inside HTML elements is a terrible default. HTML semantic elements containing marked up text is basically how I write documentation to myself, and obviously the right way to mix plain text-like markup with named, extensible annotations beyond the default syntax.)

I think most of the friction comes because you have to keep converting free text with bold, italics, headings, etc. between the two, costing time when you're moving notes, documentation, README.mds, code comments nowadays in Markdown, etc. back and forth between the two. That creates a dilemma: Should I write README.org or README.md in my personal project? Should I write Org notes about my work to help me track of WIP and notes that might become documentation, or Markdown blocks inside Org, or Markdown notes? What if I'm collaborating with others, or think I might in future? What about collaborating with LLMs?

It's just enough friction that I ended up avoiding Org for organising my work, even though I like the idea in principle and use Emacs all the time.

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#76

Post by jlokier »

mplanchard wrote: post #66
cpach wrote: post #52

“You probably heard of this new markdown-ts-mode and decided to check it out.” Uhm, no, I haven’t. Why should I care if the Markdown mode uses Treesitter or not…? Does it affect the performance or UX somehow?

One option would be to read the section of the linked article talking about features: https://rahuljuliato.com/posts/markdown-ts-mode-emacs-31#a-q...

It's still reasonable to ask what's different about markdown-ts-mode compared with markdown-mode.

I read that article, and I didn't notice anything that stands out as different from markdown-mode (the non Tree Sitter version).

Regular markdown-mode also highlights everything, hides markup if you like, cycles section visibility if you like, fills paragraphs in bullets, etc. With poly-markdown-mode it also does language-specific syntax highlighting in code blocks, and even language-specific structural editing, automatic indentation, etc. With math-preview it displays TeX/LaTeX math as rendered formulae.

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#77

Post by xenodium »

wilkystyle wrote: post #7
remedan wrote: post #6

Earlier quoted context omitted.

Agent Shell connected via ACP to local Claude Code. https://github.com/xenodium/agent-shell

Can't say enough good things about agent-shell.el! Xenodium has done amazing work there.

Wonderful to hear. Thank you sir!

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#78

Post by skydhash »

dleslie wrote: post #48
chroma_zone wrote: post #46

Earlier quoted context omitted.

If it can't find an LSP binary, Eglot will prompt you to pick one, and tell you which one it was looking for. That seems reasonable to me. I wouldn't want Emacs to download and install random binaries on my system automatically.

My experience with Emacs 30 is that Eglot will prompt and show nothing of meaningful assistance beyond a name. That leaves me to run a google search to find whatever binaries fit the description. They host binaries already; why not host all of the binaries necessary for the supported features to function?

Should they install make for you too (default command for compilation-mode) or the various sql client (for the sql-mode) pr a lisp runtime (for the repl)?

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#79

Post by skydhash »

jlokier wrote: post #76
mplanchard wrote: post #66

Earlier quoted context omitted.

One option would be to read the section of the linked article talking about features: https://rahuljuliato.com/posts/markdown-ts-mode-emacs-31#a-q...

It's still reasonable to ask what's different about markdown-ts-mode compared with markdown-mode. I read that article, and I didn't notice anything that stands out as different from markdown-mode (the non Tree Sitter version). Regular markdown-mode also highlights everything, hides markup if you like, cycles section visibility if you like, fills paragraphs in bullets, etc. With poly-markdown-mode it also does languag…

I think the appeal of tree sitter is to have a single query api for traversal of the nodes in the abstract tree of the language. So it become easier to adjust or adapt the parser.

Re: Emacs 31: An unofficial guide to Markdown-ts-mode

#80

Post by mplanchard »

jlokier wrote: post #76
mplanchard wrote: post #66

Earlier quoted context omitted.

One option would be to read the section of the linked article talking about features: https://rahuljuliato.com/posts/markdown-ts-mode-emacs-31#a-q...

It's still reasonable to ask what's different about markdown-ts-mode compared with markdown-mode. I read that article, and I didn't notice anything that stands out as different from markdown-mode (the non Tree Sitter version). Regular markdown-mode also highlights everything, hides markup if you like, cycles section visibility if you like, fills paragraphs in bullets, etc. With poly-markdown-mode it also does languag…

Mostly same as with any treesitter mode: it’s easier to build structurally-aware features, and it automatically supports any minor mode that’s enabled by treesitter (examples from my own config include structural movement, folding, selection, indentation guides, etc.). So, rather than every language having to reinvent the wheel, and every user having to install six different language-specific packages to get feature parity, more stuff just works.

You mention eg poly mode, which has always been extremely finicky for me. Syntax highlighting in treesitter modes is both more capable and more consistent.

Post reply on HN