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.
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’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.
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.
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 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”.
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.
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.
After many years of using it, I switched from Orgmode to Asciidoc.
I think it's a nice middle ground between the full suit of tools you get in Orgmode and bare Markdown. I realized Orgmode is basically kinda of like .docx. A weird poorly specified format that is only fully editable from one editor. Then it feels like.. I might as well use .odt .. maybe?
With .adoc I definitely have a lot fewer features, but I find it sufficient (the only part I miss is tangle). You have a plethora 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 I don't think Markdown has a standard for) Most importantly I can run the asciidoc converter from the command line or even call it from programs in from Clojure (since it runs on JRuby). So I feel less married to an editor.
Ideally there'd be some markup that's specified with 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.
This is very close to why I ended up doing Marktwin. Obsidian was not giving me what I wanted.
It keeps Markdown in GitHub but gives people a nicer place to edit, discuss and review changes together. I never have access to your content. Is free and open source, and I have no intention of adding a paywall for what there is now.
It’s a hobby project: https://marktwin.com
If you have feedback, let me know. It gives me another reason to procrastinate and work on it. I am now working on the macos app (as I prefer to work out of the browser). I hope to make it flexible because everyone in my team has different workflows and we are using this as our internal documentation/collaboration tool.
- `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)
Are you using the 31 release or prerelease? The mode was changed to experimental right before release.
Just FYI, I think the comment you replied to is by the author of the mode and an upstream Emacs contributor, so I would assume their instructions are up to date for the 31 release.
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.
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)?
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.
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.
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 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.
44 comments
[ 0.29 ms ] story [ 154 ms ] threademacs -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.
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.
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 then use mAgit to review it.
Setting up a keyboard replacement is the way to go here. Solves the issue for all devices.
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.....
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 think it's a nice middle ground between the full suit of tools you get in Orgmode and bare Markdown. I realized Orgmode is basically kinda of like .docx. A weird poorly specified format that is only fully editable from one editor. Then it feels like.. I might as well use .odt .. maybe?
With .adoc I definitely have a lot fewer features, but I find it sufficient (the only part I miss is tangle). You have a plethora 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 I don't think Markdown has a standard for) Most importantly I can run the asciidoc converter from the command line or even call it from programs in from Clojure (since it runs on JRuby). So I feel less married to an editor.
Ideally there'd be some markup that's specified with 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.
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.
- `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.
Just FYI, I think the comment you replied to is by the author of the mode and an upstream Emacs contributor, so I would assume their instructions are up to date for the 31 release.
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.
They host binaries already; why not host all of the binaries necessary for the supported features to function?
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?
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.
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.
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.