Live data from Hacker News

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

rahuljuliato.com

41–50 of 92 posts

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

#41
post #32

Earlier quoted context omitted.

In Emacs 31 none of what you’re saying is true. Grammars auto install and setting them up is easy. https://www.reddit.com/r/emacs/comments/1utghab/treesitter_s...

Well that's a nice change; I'm still on Emacs 30. But note that this is not the default. Users have to enable that behaviour, and know to enable it. That's a bad default.

I speak only for myself and not the Emacs team, but ... IMO it shouldn't do this by default - unless there is a clear "winner" among all the choices.

IIRC, for eglot I had to install a Python language server. There are a bunch of them. Why would I want it to pick one by default?

I don't know if Emacs will ever have an IDE with TS and LSP working "out of the box" without some configuration. From my experience with Eglot, if it were enabled by default, it would confuse the heck out of some users who just want to, say, edit a Python script.

There are always opinionated releases like Doom Emacs or Spacemacs that can set whatever nice defaults you think should be there. Leave vanilla Emacs to be, well, vanilla. Emacs, while it can be a decent IDE, is not an IDE and shouldn't default to being one.

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

#42
post #41
post #32

Earlier quoted context omitted.

Well that's a nice change; I'm still on Emacs 30. But note that this is not the default. Users have to enable that behaviour, and know to enable it. That's a bad default.

I speak only for myself and not the Emacs team, but ... IMO it shouldn't do this by default - unless there is a clear "winner" among all the choices. IIRC, for eglot I had to install a Python language server. There are a bunch of them. Why would I want it to pick one by default? I don't know if Emacs will ever have an IDE with TS and LSP working "out of the box" without some configuration. From my experience with Egl…

Emacs makes many opinionated choices about defaults; if it didn't, it would launch to little more than an elisp REPL by default.

What's important is that _you can change it_. Good defaults ensure that Emacs doesn't repel new users and casual users and users who are not interested in fiddling.

And this isn't a matter of color theme default, or font default; this is a shipped feature that _does not function_ without changes to the defaults! By default, it does not work.

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

#43
post #33

Earlier quoted context omitted.

> What is wrong with markdown mode? Nothing. It's just not Org-mode, and thus many great features of Org just not possible - sparse tree search; timestamps with built-in calendaring features; outline features like narrow-to-subtree; editing the subtree in an indirect buffer; executable code blocks; embedded LaTeX snippets; real tables with spreadsheet-like capability; checkbox statistics cookies - [/] and [%]; org-so…

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 subtree, so folding, refiling and archiving need tree semantics layered on top.

So, you need to invent slots. Logseq did exactly that - all the org-mode specific lines get lifted verbatim into .md. Obsidian did it differently with emoji fields or Dataview inline fields (or whatever they called). Neither produces portable Markdown. GitHub renders those files as literal noise. The portability benefit that motivated the move evaporates the moment you add the metadata you need.

And then you'd have to build a specialized parser - there's no equivalent of `org-element` for Markdown. Sure, tree-sitter helps to some extent, but you're still lacking a semantic layer that turns nodes into records.

In essence - for Emacs to treat Markdown as Org-mode, we need to change Markdown, once that happens (if ever) Emacs can follow. But at this point it is already such a mess, it's crazy. Take front-matter alone - it's not CommonMark, it is a Jekyll convention that each tool does differently, and it is per-file, so your unit of thought is limited to become a file. That is the Obsidian/Denote/zk design, it works - but it moves your outline into the filesystem. You lose refile, subtree archive, narrowing, cut-and-yank of a subtree, and "this TODO belongs under that project heading". Org gives you both: file keywords at the top, property drawers on every heading, with inheritance down the subtree that front-matter structurally cannot express.

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

#44
post #32

Earlier quoted context omitted.

In Emacs 31 none of what you’re saying is true. Grammars auto install and setting them up is easy. https://www.reddit.com/r/emacs/comments/1utghab/treesitter_s...

Well that's a nice change; I'm still on Emacs 30. But note that this is not the default. Users have to enable that behaviour, and know to enable it. That's a bad default.

“ask” mode for installing tree-sitter grammars is the default setting. Tree-sitter modes broadly aren’t enabled by default, but that seems at least consistent with eMacs defaulting to very few modes enabled by default.

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

#45
post #41
post #32

Earlier quoted context omitted.

Well that's a nice change; I'm still on Emacs 30. But note that this is not the default. Users have to enable that behaviour, and know to enable it. That's a bad default.

I speak only for myself and not the Emacs team, but ... IMO it shouldn't do this by default - unless there is a clear "winner" among all the choices. IIRC, for eglot I had to install a Python language server. There are a bunch of them. Why would I want it to pick one by default? I don't know if Emacs will ever have an IDE with TS and LSP working "out of the box" without some configuration. From my experience with Egl…

I recently switched from full IDE to Emacs (wrote up about the things I learned at https://github.com/KallDrexx/emacs-zero-to-ide-journey/blob/...)

Typescript is a perfect example of why Emacs shouldn't own that setup. Typescript version 6 uses the "typescript-language-server" which is a totally stand alone nom package for lsp support.

Typescript 7, is incompatible with typescript-language-server and the compiler itself now acts as a lsp.

If Emacs handles that all by default it then needs to handle versioning of each language server itself across all operating systems, handle cases when different machines have different npm version managers, upgrades, etc...

It's not impossible but it's a lot to ask, and it requires more frequent version upgrades just to keep things in sync.

I couldn't even use the built in version of eglot and had to use ELPA version for bug fixes that affect c# LSP support that were committed to the package back in December.

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

#46
post #28
post #15

A bit of extra info: - `ts` stands for "tree-sitter", meaning this mode uses tree-sitter under the hood, which is, among other things, very performant. - There's support for the CommonMark spec and GFM, so things like `- [ ]` checkboxes and ~~strikethrough~~ work out of the box, along with many other small QoL features. - This mode is BUILT-IN, so no extra packages are needed. - This is currently in the experimental…

Tree sitter support is half baked in the same way official LSP support is, only kind of worse. Eglot won't help you get your system ready for LSP work, it will only avail itself if what's there. It doesn't even auto detect and configure that, either. There's no user prompting, so you'll have to read the docs to know that this even needs to be done. Similarly, tree sitter support doesn't include the grammars! And thos…

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.

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

#47
post #41

Earlier quoted context omitted.

I speak only for myself and not the Emacs team, but ... IMO it shouldn't do this by default - unless there is a clear "winner" among all the choices. IIRC, for eglot I had to install a Python language server. There are a bunch of them. Why would I want it to pick one by default? I don't know if Emacs will ever have an IDE with TS and LSP working "out of the box" without some configuration. From my experience with Egl…

I recently switched from full IDE to Emacs (wrote up about the things I learned at https://github.com/KallDrexx/emacs-zero-to-ide-journey/blob/... ) Typescript is a perfect example of why Emacs shouldn't own that setup. Typescript version 6 uses the "typescript-language-server" which is a totally stand alone nom package for lsp support. Typescript 7, is incompatible with typescript-language-server and the compiler it…

[deleted]

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

#48
post #28

Earlier quoted context omitted.

Tree sitter support is half baked in the same way official LSP support is, only kind of worse. Eglot won't help you get your system ready for LSP work, it will only avail itself if what's there. It doesn't even auto detect and configure that, either. There's no user prompting, so you'll have to read the docs to know that this even needs to be done. Similarly, tree sitter support doesn't include the grammars! And thos…

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?

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

#49
post #38

Earlier quoted context omitted.

Markdown didn't even exist when org-mode was first developed and released with many of the features you describe. But also, once you start extending markdown to support all these things you start getting something that's not markdown, it's markdown-based but something distinct since you'd rapidly lose compatibility with other markdown tools if you start incorporating custom annotations into it.

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, etc. That's the most difficult part - there's no agreement of what Markdown is - each tool treats it differently. While Org doesn't have a formal spec either, there's no mess, because "the spec" is in the Elisp code it ships with. Even if there's fragmentation (Org-Roam, Denote, howm, vulpea), it is all contained within emacs-land.

If you want to use markdown for Agenda and calendaring in Emacs you'd have to invent a different subset of markdown, most likely poorly supported anywhere else. And if you get there, then it begets a question - why? If we already have something far better and it's called Org-mode?

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

#50
post #39

Earlier quoted context omitted.

I use windows 11, wsl2, WezTerm. emacs -nw directly on the shell. its like working on a linux computer, but from windows. I run vterm inside emacs, and claude code inside vterm. I have special commands for extracting file routes, and flow between dired and magit. Everything runs like magic. I also have copilot-chat and copilot-mode installed. From time to time I use it to review what claude has done, or to chat a lit…

I’m trying to use a similar workflow, but when I attempt to use Claude code in vterm, I have issues. My use case is resuming a session and not being able to scroll back to the past history. Otherwise if I start a new session, it works fine. It’s probably related to me being on an old version of vterm, but I’m just wondering if you ever have come across this.

Definitely try ghostel, it's really solid.
Post reply on HN