- `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 phase, so users need to "opt in" and load the mode to play with it, hence the first part of the guide.
I think in 31 registering the file types isnt necessary any more, the mode opens automatically for me (and i did manually delete the old markdown-mode)
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 those aren't typically sitting in your package repository, so users have to find a grammar and compile it themselves. There's not even a good recommendation given by Emacs on where to get them, leaving users to hope that whatever repository showed up on a Google search is both in good working order and safe to use.
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.
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.
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.
> if it didn't, it would launch to little more than an elisp REPL by default.
I'm confused. Have things changed? The scratch buffer it starts with is for writing elisp.
> this is a shipped feature that _does not function_ without changes to the defaults!
Do you know how many shipped features come with Emacs that don't function without changes to defaults?
A huge number of them! Stuff like hippie-expand, ibuffer, etc. This isn't something new - it's been that way for decades.
> Good defaults ensure that Emacs doesn't repel new users and casual users and users who are not interested in fiddling.
This has been argued to death forever. While even I think they can and should change some defaults, the reality is that Emacs as an ecosystem is doing just fine without so many new/casual users, and will continue to do so. They don't want to be something for everyone.
And while I don't have the latest Emacs, in my experience with eglot - it's simply not ready for the masses. I frequently get timeouts, and would often have to shut down and restart eglot. It's been a while since I had to, so perhaps they've fixed all the issues, but it's simply not as robust as what you'd get with other IDEs. I'd rather they address those issues than the ease of use.
It launches with a scratch buffer, menu bar with populated menus, a functional mini buffer, and so on. All of this is opinionated defaults and configurable with elisp.
And yes, much of Emacs is broken out of the box and it's been that way a long while. That's not a good thing.
Emacs isn't ready for the masses. Broken defaults, and a brittle experience once features are made working is standard.
I've used Emacs for thirty years now. I don't recommend it to new users.
It never will be. It's simply not a goal they have. It's tiring to keep hearing people point it out. Emacs is also not ready to be your web server. Or your Jira replacement. It's not a lot of things - we don't need to itemize them all.
I've written a lot of stuff. Some of it I released publicly. None of it is for the masses. There are better tools for the masses - let them use those!
> I don't recommend it to new users.
"New" to what? In general, I don't recommend Emacs unless someone shows genuine curiosity. I always tell people "Give me any task, and I'll find a better tool than Emacs." And "If you want to get up and running quickly for your task, Emacs is not a good choice." Followed by "What makes Emacs worthwhile is you get it all in one package where they can interact with one another." And "It's a lifelong journey."
Nevertheless, some not technically savvy users do use Emacs today because they needed help editing files on a remote machine and I couldn't teach vim because Emacs was all I knew :-)
> I always tell people "Give me any task, and I'll find a better tool than Emacs." And "If you want to get up and running quickly for your task, Emacs is not a good choice." Followed by "What makes Emacs worthwhile is you get it all in one package where they can interact with one another." And "It's a lifelong journey."
That is the proper response. These tools are designed for someone that does need them as they are, not for someone that just need some tools. Software like vim and emacs are in fact a whole workshop that you need to make your own. If you just want a tool, there are better software out there, but people that usually go for emacs wants a workspace, not just one tool.
I think eglot often just works now. I recently started doing c++ stuff, and it just detected clangd and I was off to the races with no config. Same with rust-analyzer for rust projects.
“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.
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?
For those of us who have just been using Emacs, rather than following its recent evolution, "ts-mode" refers to a mode which uses tree-sitter for parsing, highlighting etc.
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.
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. I'd prefer to just have the config living in/around init.el/config.el (I used DoomEmacs most recently).
I realize that org/agenda, etc does a ton more than markdown offers, but most of my flow is just around: raw notes to be consumed, check lists, due dates on items, and other "basics" of org-mode.
Any recent Emacsers have similar workflows that are tgenible these days? I'd love to get Emacs back in use in my new antigenic Tmux-centric coding flows, and have it be a first class markdown editor, organizaer, and potentially collaboration.....
Org mode is a coherent whole, and has capabilities far beyond what Markdown can accomplish (Markdown is inherently HTML-based, org-mode is not). Markdown's history is littered with folks trying to augment it in just the right way to bring these sorts of features, which has resulted in a diaspora of flavors, none particularly dominant+powerful (which is to say, no real org-mode competitor has emerged, even though one could have). I've used Markdown and Org-mode for 20 years concurrently, and trying to make Markdown work like org-mode has never been successful for me.
I wrote a bit about this back in 2021, in response to a query on Reddit "Why didn't org-mode just use Markdown?".
I love Org-mode and use it for many things - the outline format is great, even for some unexpected cases - Jira tickets, Slack, Reddit and HN threads, etc. But of course, hard to escape Markdown these days, so I burned some tokens to implement this https://github.com/agzam/prisma.el
For example, I just added the ability of seamlessly copy&pasting between two formats (prisma-yank-mode) - if the source was a markdown, and you're pasting it into org - it will convert and vice versa. And if you really need to insert it verbatim - you just call it with C-u arg.
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 editable/usable from anywhere, even Notepad.
.adoc is usually sufficient (the only part I miss is tangle). Lots of options to specify at the top of a document like the images directory, or the CSS file to use, line SVG on HTML export etc. (which Markdown lacks). But the asciidoc converter runs from the command line or from code ( I write .adocs and convert them in Clojure). So you're less married to your editor.
Ideally there'd be some markup that's specified with a regex of PEGs or something that you could easily make a parse for in any context. I thought djot would be that, but it looks like making a grammar is secondary for them. I hope some day one could navigate to markup file in the browser and they'd automatically render with your own specified CSS.
> 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.
What is wrong with markdown mode? Is it that you would rather do the org agenda or calendar via md rather then org? I do understand that if that is the case.
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-sort; column views; tags and tag inheritance; etc.
Anyone who's familiar with even a small subset of things that's possible in Org-mode and unlikely ever be supported in Markdown (just because there's no agreed format standard) have no confusion about it - Org-mode is absolutely superior. But superior doesn't mean universally better for everyone. The biggest drag of Org-mode is that it can never fully exist outside of Emacs. Yet Markdown can't ever fully cover its grounds (even in Emacs), simply because Markdown has to exist and work outside of Emacs as well.
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 could in theory just render this all out to markdown instead and come up with some way to render todos into md.
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.
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.
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 as todo.
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?
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.
Yeup, I would love to have some of the org/agenda operations/views on a regular markdown file. Especially so I could just copy it raw out, and paste into other markdown-centric tools, github md files, etc. for colaborating with others.
Since markdown is becoming so prevalent. Even our product managers are becoming natively conversant with it, I'd just prefer to have as markdown first world.
(don't get me started ranting about how Atlassian and Slack have migrated away from markdown and to proprietary formats....).
Yes must say I have found myself moving away from org and looking at it as an annoyance wrapping up many excellent features that could be wrapped up in simple elisp function and structures that could then just be encoded in what every way one likes, it seems to me that for example todo lists are actually better as nested lisp lists, And then you can simply render as what ever you like. Of course one might like to serialize back as well but I have often wondered about it.
I definitely think markdown has won (at org was never going to 'win' of course given it's limited scope) and actually is probably what we should just all be using and accept.
That's actually not a bad mindset, especially when lisp can be vibed so easily. I could actually see myself building out my own library that does the things I want over markdown.
- have it look through all md files in a directory, collect all the todos into a main view
- look for items tagged with a date
- support customer tagging, and provide workflow exports for each one...
- behind the scenes git management for files
- etc...
I've been wanting to build a collaborative markdown editor for awhile now, making it so that different front-ends could work with it is an interesting thing to think about....
My thinking was lean into lisp lists rather then the actual rendered format, so that instead of a text buffer (although you could always open up a text buffer that is the lisp list) you have a list that you can use normal elisp functions that is bindable to keys and highly customizable and your only really building fairly simple elisp machinery on top and you can just use an alist (though you could use a plist I think alist's work better for todos) to represent todo's and just use assoc and setf and friends to do your modifications.
Of course one might also want to actually build out todo nodes as CLOS style objects. Only caveat hear is that you would need to decide how the object should be serialized and deserialized and the deserializing has to be more precise.
serializing and deserializing to MD should be easy I think since all we need to do is read in headings and list items into lists with some denotation to the type it was.
Those are just my thoughts on the topic. My thinking has been I have gotten fed up with emacs modes that are good and a lot of effort to write but just end up adding a lot of stuff on top that make it difficult to customize or customize the the standard way and returning to simple lists could be good.
You might just as well require a sqlite db as the persistence layer. Emacs has always been about using plain text files as both data and interface while lisp is the control mechanism.
That’s why you got org files and a handful of lisp functions to turn them into a living documents. Using lists take that aspect away while markdown is just not that good to serve such a role.
org-mode is a way more powerful literate programming environment which can be exported to many different formats including markdown. In the past, I have collaborated with others with markdown as the sort of interface format. But on the collaboration front and not everyone liking emacs, I found that there's no way around that. I am a huge fan of emacs and use it every day but it is not that great of a collaboration tool due to it not being everyone's cup of tea.
What are people’s workflows for using eMacs with generative coding? I’m trying to get a workflow where I can generate code and approve it like a PR (maybe leave comments for a next round of generation) but I’m new to eMacs and the ai coding package isn’t working with the latest eMacs
I'll have to try it again. It definitely feels like the right way to do things, but when I tried it it had a couple of show-stopper limitations and a show-stopper bug, so I've been using claude-code-ide.el instead.
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 little bit.
I found my answer, I needed to be using page up and page down keys to “scroll” through the claude history - which is apparently required due to Claude capturing my C-v and M-v’s in its “text-box”.
Thanks, I would, and I’ve used it on my personal machines (it works great), but I’m trying to stick to the apt package repos on my $WORK machine.
Ubuntu has a fair number of elpa packages in its repos, so I’m trying to make it work if possible. Not sure if I’m missing anything config wise within the confines of vterm
I’ve been using gptel, I’ll have it generate org babel blocks I can tangle (write to files) or have it use tools to write and edit files in the project I’m working in, and then review with magit.
IMO, generative coding on Emacs works nicely because magit is awesome for code review. A good agent integration package is going to have a command you can use to send the current cursor line & file to the agent so you can reference and comment.
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.
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 phase, so users need to "opt in" and load the mode to play with it, hence the first part of the guide.
I think in 31 registering the file types isnt necessary any more, the mode opens automatically for me (and i did manually delete the old markdown-mode)
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 those aren't typically sitting in your package repository, so users have to find a grammar and compile it themselves. There's not even a good recommendation given by Emacs on where to get them, leaving users to hope that whatever repository showed up on a Google search is both in good working order and safe to use.
It's really quite a failure on Emacs.
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.
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.
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.
> if it didn't, it would launch to little more than an elisp REPL by default.
I'm confused. Have things changed? The scratch buffer it starts with is for writing elisp.
> this is a shipped feature that _does not function_ without changes to the defaults!
Do you know how many shipped features come with Emacs that don't function without changes to defaults?
A huge number of them! Stuff like hippie-expand, ibuffer, etc. This isn't something new - it's been that way for decades.
> Good defaults ensure that Emacs doesn't repel new users and casual users and users who are not interested in fiddling.
This has been argued to death forever. While even I think they can and should change some defaults, the reality is that Emacs as an ecosystem is doing just fine without so many new/casual users, and will continue to do so. They don't want to be something for everyone.
And while I don't have the latest Emacs, in my experience with eglot - it's simply not ready for the masses. I frequently get timeouts, and would often have to shut down and restart eglot. It's been a while since I had to, so perhaps they've fixed all the issues, but it's simply not as robust as what you'd get with other IDEs. I'd rather they address those issues than the ease of use.
It launches with a scratch buffer, menu bar with populated menus, a functional mini buffer, and so on. All of this is opinionated defaults and configurable with elisp.
And yes, much of Emacs is broken out of the box and it's been that way a long while. That's not a good thing.
Emacs isn't ready for the masses. Broken defaults, and a brittle experience once features are made working is standard.
I've used Emacs for thirty years now. I don't recommend it to new users.
> Emacs isn't ready for the masses.
It never will be. It's simply not a goal they have. It's tiring to keep hearing people point it out. Emacs is also not ready to be your web server. Or your Jira replacement. It's not a lot of things - we don't need to itemize them all.
I've written a lot of stuff. Some of it I released publicly. None of it is for the masses. There are better tools for the masses - let them use those!
> I don't recommend it to new users.
"New" to what? In general, I don't recommend Emacs unless someone shows genuine curiosity. I always tell people "Give me any task, and I'll find a better tool than Emacs." And "If you want to get up and running quickly for your task, Emacs is not a good choice." Followed by "What makes Emacs worthwhile is you get it all in one package where they can interact with one another." And "It's a lifelong journey."
Nevertheless, some not technically savvy users do use Emacs today because they needed help editing files on a remote machine and I couldn't teach vim because Emacs was all I knew :-)
> I always tell people "Give me any task, and I'll find a better tool than Emacs." And "If you want to get up and running quickly for your task, Emacs is not a good choice." Followed by "What makes Emacs worthwhile is you get it all in one package where they can interact with one another." And "It's a lifelong journey."
That is the proper response. These tools are designed for someone that does need them as they are, not for someone that just need some tools. Software like vim and emacs are in fact a whole workshop that you need to make your own. If you just want a tool, there are better software out there, but people that usually go for emacs wants a workspace, not just one tool.
I think eglot often just works now. I recently started doing c++ stuff, and it just detected clangd and I was off to the races with no config. Same with rust-analyzer for rust projects.
“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.
The critique converning lsp and eglot support is nonetheless true.
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?
For those of us who have just been using Emacs, rather than following its recent evolution, "ts-mode" refers to a mode which uses tree-sitter for parsing, highlighting etc.
Thanks for adding this. I just made a comment expanding a bit of what users may find in the new mode.
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.
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. I'd prefer to just have the config living in/around init.el/config.el (I used DoomEmacs most recently).
I realize that org/agenda, etc does a ton more than markdown offers, but most of my flow is just around: raw notes to be consumed, check lists, due dates on items, and other "basics" of org-mode.
Any recent Emacsers have similar workflows that are tgenible these days? I'd love to get Emacs back in use in my new antigenic Tmux-centric coding flows, and have it be a first class markdown editor, organizaer, and potentially collaboration.....
Org mode is a coherent whole, and has capabilities far beyond what Markdown can accomplish (Markdown is inherently HTML-based, org-mode is not). Markdown's history is littered with folks trying to augment it in just the right way to bring these sorts of features, which has resulted in a diaspora of flavors, none particularly dominant+powerful (which is to say, no real org-mode competitor has emerged, even though one could have). I've used Markdown and Org-mode for 20 years concurrently, and trying to make Markdown work like org-mode has never been successful for me.
I wrote a bit about this back in 2021, in response to a query on Reddit "Why didn't org-mode just use Markdown?".
https://rpdillon.net/why-doesnt-emacs-org-mode-just-use-mark...
I love Org-mode and use it for many things - the outline format is great, even for some unexpected cases - Jira tickets, Slack, Reddit and HN threads, etc. But of course, hard to escape Markdown these days, so I burned some tokens to implement this https://github.com/agzam/prisma.el
For example, I just added the ability of seamlessly copy&pasting between two formats (prisma-yank-mode) - if the source was a markdown, and you're pasting it into org - it will convert and vice versa. And if you really need to insert it verbatim - you just call it with C-u arg.
That's a neat trick. I know about org-md for exporting generally to a markdown file but going in/out via buffers is useful.
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 editable/usable from anywhere, even Notepad.
.adoc is usually sufficient (the only part I miss is tangle). Lots of options to specify at the top of a document like the images directory, or the CSS file to use, line SVG on HTML export etc. (which Markdown lacks). But the asciidoc converter runs from the command line or from code ( I write .adocs and convert them in Clojure). So you're less married to your editor.
Ideally there'd be some markup that's specified with a regex of PEGs or something that you could easily make a parse for in any context. I thought djot would be that, but it looks like making a grammar is secondary for them. I hope some day one could navigate to markup file in the browser and they'd automatically render with your own specified CSS.
> 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.
What is wrong with markdown mode? Is it that you would rather do the org agenda or calendar via md rather then org? I do understand that if that is the case.
> 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-sort; column views; tags and tag inheritance; etc.
Anyone who's familiar with even a small subset of things that's possible in Org-mode and unlikely ever be supported in Markdown (just because there's no agreed format standard) have no confusion about it - Org-mode is absolutely superior. But superior doesn't mean universally better for everyone. The biggest drag of Org-mode is that it can never fully exist outside of Emacs. Yet Markdown can't ever fully cover its grounds (even in Emacs), simply because Markdown has to exist and work outside of Emacs as well.
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 could in theory just render this all out to markdown instead and come up with some way to render todos into md.
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.
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.
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 as todo.
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?
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.
Yeup, I would love to have some of the org/agenda operations/views on a regular markdown file. Especially so I could just copy it raw out, and paste into other markdown-centric tools, github md files, etc. for colaborating with others.
Since markdown is becoming so prevalent. Even our product managers are becoming natively conversant with it, I'd just prefer to have as markdown first world.
(don't get me started ranting about how Atlassian and Slack have migrated away from markdown and to proprietary formats....).
Yes must say I have found myself moving away from org and looking at it as an annoyance wrapping up many excellent features that could be wrapped up in simple elisp function and structures that could then just be encoded in what every way one likes, it seems to me that for example todo lists are actually better as nested lisp lists, And then you can simply render as what ever you like. Of course one might like to serialize back as well but I have often wondered about it.
I definitely think markdown has won (at org was never going to 'win' of course given it's limited scope) and actually is probably what we should just all be using and accept.
That's actually not a bad mindset, especially when lisp can be vibed so easily. I could actually see myself building out my own library that does the things I want over markdown.
- have it look through all md files in a directory, collect all the todos into a main view
- look for items tagged with a date
- support customer tagging, and provide workflow exports for each one...
- behind the scenes git management for files
- etc...
I've been wanting to build a collaborative markdown editor for awhile now, making it so that different front-ends could work with it is an interesting thing to think about....
My thinking was lean into lisp lists rather then the actual rendered format, so that instead of a text buffer (although you could always open up a text buffer that is the lisp list) you have a list that you can use normal elisp functions that is bindable to keys and highly customizable and your only really building fairly simple elisp machinery on top and you can just use an alist (though you could use a plist I think alist's work better for todos) to represent todo's and just use assoc and setf and friends to do your modifications.
Of course one might also want to actually build out todo nodes as CLOS style objects. Only caveat hear is that you would need to decide how the object should be serialized and deserialized and the deserializing has to be more precise.
serializing and deserializing to MD should be easy I think since all we need to do is read in headings and list items into lists with some denotation to the type it was.
Those are just my thoughts on the topic. My thinking has been I have gotten fed up with emacs modes that are good and a lot of effort to write but just end up adding a lot of stuff on top that make it difficult to customize or customize the the standard way and returning to simple lists could be good.
You might just as well require a sqlite db as the persistence layer. Emacs has always been about using plain text files as both data and interface while lisp is the control mechanism.
That’s why you got org files and a handful of lisp functions to turn them into a living documents. Using lists take that aspect away while markdown is just not that good to serve such a role.
Not tested this myself, but there are ways to improve markdown/org-mode interop, like in https://youtu.be/RJqRwlVvB3E
org-mode is a way more powerful literate programming environment which can be exported to many different formats including markdown. In the past, I have collaborated with others with markdown as the sort of interface format. But on the collaboration front and not everyone liking emacs, I found that there's no way around that. I am a huge fan of emacs and use it every day but it is not that great of a collaboration tool due to it not being everyone's cup of tea.
I use markdown and nvim with telekasten plugin on desktop and mobile obsidian and for me is good enough
What are people’s workflows for using eMacs with generative coding? I’m trying to get a workflow where I can generate code and approve it like a PR (maybe leave comments for a next round of generation) but I’m new to eMacs and the ai coding package isn’t working with the latest eMacs
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.
I'm a huge fan of agent-shell, too. It keeps getting better and better, and it's infinitely customizable, like any good Emacs package.
I'll have to try it again. It definitely feels like the right way to do things, but when I tried it it had a couple of show-stopper limitations and a show-stopper bug, so I've been using claude-code-ide.el instead.
Seconded, agent-shell is my favorite LLM interface bar none
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 little bit.
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.
I found my answer, I needed to be using page up and page down keys to “scroll” through the claude history - which is apparently required due to Claude capturing my C-v and M-v’s in its “text-box”.
Definitely try ghostel, it's really solid.
Thanks, I would, and I’ve used it on my personal machines (it works great), but I’m trying to stick to the apt package repos on my $WORK machine.
Ubuntu has a fair number of elpa packages in its repos, so I’m trying to make it work if possible. Not sure if I’m missing anything config wise within the confines of vterm
I’ve been using gptel, I’ll have it generate org babel blocks I can tangle (write to files) or have it use tools to write and edit files in the project I’m working in, and then review with magit.
I use cLaude cOde in my eMacs (through ghostel, which is unbelievably great!) to generate code :-)
I then use mAgit to review it.
The iPhone autocorrects it to eMacs... it's so annoying.
https://en.wikipedia.org/wiki/EMac
Setting up a keyboard replacement is the way to go here. Solves the issue for all devices.
IMO, generative coding on Emacs works nicely because magit is awesome for code review. A good agent integration package is going to have a command you can use to send the current cursor line & file to the agent so you can reference and comment.
Which AI coding package? Agent-shell? Gptel-agent?
It’s just called ai-code I’m new to eMacs so this popped up but had a bunch of issues I was trying to debug https://github.com/tninja/ai-code-interface.el
Never heard of that one. The most popular ways for agent stuff seems to be https://github.com/xenodium/agent-shell , or just opening a terminal in emacs and using claude code. If you want to run it through an emacs terminal, consider using https://github.com/dakra/ghostel#ghostel (or vterm, or eat)
Thanks for posting the ghostel link, I hadn’t heard of it. Excited to try it out and see how it compares to vterm
I still use my markdown-modern, and obsidian-style renderer. I read more markdown than I write and for that it works well. https://github.com/rjprins/markdown-modern
just switched to doom emacs this month, absolutely loving it tbh
“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.