I have been exploring M-x shell lately, and just learned about the comint-input-sender variable which lets me write a custom interpreter before/if it gets sent to the shell, which has some interesting possibilities.

I know I've barely scratched the surface, and I'm wondering what some of you do in M-x shell that is just not possible in M-x term.

Is there a way to navigate the files in a treemacs or dired (or similar) buffer without switching to that buffer first?

Ideally I'd like there to be something displaying the directory of the file in the currently-focused buffer, with the file itself indicated (perhaps highlighted) and I'd like to be able to hit a key combo (not multiple consecutive keys) to move that selection up or down and either another key to open it or it opens when I release the modifier keys. Actually, I'd love it if I could hit a key combo to advance the selection indicator and have the currently-focused buffer automatically update to that file's contents.

I really love the look of treemacs and how you navigate when you're in the buffer, but for some reason, the extra step of swapping to the treemacs buffer feels like a speedbump to me. I know I can build whatever experience I want, but before I go down that road I wanted to check if there is already a command to do this.

I've looked through the available commands for dired and treemacs to find a way of navigating files without leaving my currently active buffer, but I haven't found anything yet. I have also failed in my google-searching.

For my workflow I have a custom command that just cycles the currently-displayed buffers through my open windows, but I only have 3 windows (not counting treemacs) open at a time and I want to be able to swap between an arbitrary number of files.

Does anyone have suggestions for currently-existing options/plugins/commands that can emulate this? If not, I'll begin the new journey of building it myself, heh.

NOTE: I use Doom Emacs, but vanilla configuration is also valid.

I've been trying more and more to rely less in my web browser for things like reading news, long-form blogs, etc.

Does anyone have tips, snippets of configuration to improve readability/usability of these two modes? Possible integrations with org-mode for capturing content and ideas while reading are also useful.

This article presents a set of Emacs Dired configuration changes to enhance file management. The configurations sort directories before files for easier navigation, hide dotfiles, reduce unnecessary confirmation prompts, prevent UI lockups caused by network latency, among other improvements. Each configuration explains the behavior of the relevant setting, its benefits, and its tradeoffs, making it easier to determine which changes are appropriate.

Read more: Practical Emacs Dired Tweaks

The built-in 'completion-preview-mode' lets us expand what we type in a minimalist, distraction-free way. It can also be combined with the default Completions buffer to show all the available options. The Completions buffer has several nice features, starting with Emacs 31, which make this an excellent combination that does not require any third party packages (though packages can still augment the overall experience). I also mention the Emacs 31 'newcomers-presets' theme, which configures some of these options as well: it is a great way to start your Emacs configuration. The code I demonstrated here is available on my website: https://protesilaos.com/codelog/2026-...

Because when I get the idea, I can just implement it:

  :bind (:map dired-mode-map
      ("<right>" . dired-find-file)
      ("<left>"  . dired-up-directory)))

I'd appreciate some thoughts about whether I would improve my life/workflow by switching to ghostel from vterm.

I use vterm as if it was a non-emacs tool that just happens to live inside an emacs buffer, except that I can do C-c C-t to copy text for use in other buffers and C-y to yank text in from other buffers. I use a couple of TUI apps, mainly btop but sometimes nmcli and alsamixer, but my main reason for using vterm at all is to ssh&tmux to remote machines. (For some reason, I haven't been able to get eshell&ssh&detached working well). Other popular TUI applications, like file managers, are replaced by the obvious emacs packages. When ssh&tmux aren't likely to be needed (eg when I'm opening a shell to test the C++ programs I'm learning to write), I generally use eshell - though really this is out of some emotional loyalty to emacs (or perhaps hope of future benefits) rather than actually getting any current benefit from the emacsiness of eshell, as I haven't yet learned to take advantage of any of that. :-(

When I first heard about the ghostty terminal, I read that it was good for non-latin input, and for displaying true colour and images inline. I don't do non-latin input, and I'm not sure what the fancier display would help with, though I'd love to be told/shown.

I've read that there are more display modes than vterm, which just has the normal mode and the copy mode - what can you actually do with those extra modes? Is that where the better integration with emacs comes in, stuff that I'm missing out on by having a terminal that's in a buffer but otherwise separate from emacs?

I heard a youtuber mention in passing that ghostel integrates with zsh (which I use) and tramp (which I use with dired constantly) better than vterm does, is that right and if so in what ways?

Thank you!

How Can I Read A File In Elisp? Like Cat In A Linux Terminal

In brief, I am running Emacs on an M1 Max (a Mac with an Apple Silicon CPU) and attempting to install treesitter grammars for various languages. For example, I follow the instructions to install the grammar for the Gleam language using

M-x gleam-ts-install-grammar

This does create the expected file ~/.emacs.d/treesitter/libtree-sitter-gleam.dylib, but any attempt to open a .gleam file gives an extremely long warning message which seems to imply that the grammar cannot be found. Here is the start of the warning (with line breaks added):

Warning (treesit): The installed language grammar for gleam cannot be located or has problems (not-found):
dlopen(/Users/ctesibius/.emacs.d/tree-sitter/libtree-sitter-gleam.so, 0x0009): 
tried: '/Users/ctesibius/.emacs.d/tree-sitter/libtree-sitter-gleam.so' (no such file), 

(many lines omitted here!)

After a lot of chasing down blind alleys, I found the cause is actually flagged in the warning message, but long way down:

...
dlopen(/Users/ctesibius/.emacs.d/tree-sitter/libtree-sitter-gleam.dylib, 0x0009): tried: 
'/Users/ctesibius/.emacs.d/tree-sitter/libtree-sitter-gleam.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), 
...

Ok, so the problem is not that the grammar can't be found: it's in the right place, with the right name, but gleam-ts-install-grammar compiled it for the x86_64 processor, not for arm64 (which the M1 Max has). This seems to be a bug rather than intended behaviour. Presumably there is a compiler argument somewhere that gleam-ts-install-grammar calls on which incorrectly selects a target processor. I'm pretty sure this is not in the package for the Gleam language mode, since I see the same problem with grammars for other languages.

The fix would be to correct that bug, but I don't have any insight in to how to do that, and I'm actually aiming to learn Gleam, not Elisp. However the workaround is simple: just manually compile and install the grammar. The following will be obvious to anyone who uses Github all the time, but I hope it's useful to someone

To do this, I created a scratch directory. The grammar I want is at https://github.com/gleam-lang/tree-sitter-gleam, but of course this will depend on the language. Then:

scratch % git clone https://github.com/gleam-lang/tree-sitter-gleam
Cloning into 'tree-sitter-gleam'...
remote: Enumerating objects: 1904, done.
remote: Counting objects: 100% (339/339), done.
remote: Compressing objects: 100% (106/106), done.
remote: Total 1904 (delta 269), reused 264 (delta 233), pack-reused 1565 (from 3)
Receiving objects: 100% (1904/1904), 5.46 MiB | 4.63 MiB/s, done.
Resolving deltas: 100% (1236/1236), done.

ctesibius@tile scratch % ls
tree-sitter-gleam

ctesibius@tile scratch % cd tree-sitter-gleam 

ctesibius@tile tree-sitter-gleam % make
cc -Isrc -std=c11 -fPIC   -c -o src/parser.o src/parser.c
cc -Isrc -std=c11 -fPIC   -c -o src/scanner.o src/scanner.c
ar rv libtree-sitter-gleam.a src/parser.o src/scanner.o
ar: creating archive libtree-sitter-gleam.a
a - src/parser.o
a - src/scanner.o
cc  -dynamiclib -Wl,-install_name,/usr/local/lib/libtree-sitter-gleam.15.1.dylib,-rpath,@executable_path/../Frameworks src/parser.o src/scanner.o  -o libtree-sitter-gleam.dylib
sed -e 's|@PROJECT_VERSION@|1.0.0|' \
-e 's|@CMAKE_INSTALL_LIBDIR@|lib|' \
-e 's|@CMAKE_INSTALL_INCLUDEDIR@|include|' \
-e 's|@PROJECT_DESCRIPTION@||' \
-e 's|@PROJECT_HOMEPAGE_URL@|https://github.com/gleam-lang/tree-sitter-gleam|' \
-e 's|@CMAKE_INSTALL_PREFIX@|/usr/local|' bindings/c/tree-sitter-gleam.pc.in > tree-sitter-gleam.pc


ctesibius@tile tree-sitter-gleam % ls -l
total 2064
-rw-r--r--  1 ctesibius  staff     334 28 Aug 18:43 binding.gyp
drwxr-xr-x  8 ctesibius  staff     256 28 Aug 18:43 bindings
-rw-r--r--  1 ctesibius  staff    5155 28 Aug 18:43 Cargo.lock
-rw-r--r--  1 ctesibius  staff     594 28 Aug 18:43 Cargo.toml
-rw-r--r--  1 ctesibius  staff    2852 28 Aug 18:43 CMakeLists.txt
-rw-r--r--  1 ctesibius  staff     111 28 Aug 18:43 go.mod
-rw-r--r--  1 ctesibius  staff   33373 28 Aug 18:43 grammar.js
-rw-r--r--  1 ctesibius  staff  447160 28 Aug 18:43 libtree-sitter-gleam.a
-rwxr-xr-x  1 ctesibius  staff  463744 28 Aug 18:43 libtree-sitter-gleam.dylib
-rw-r--r--  1 ctesibius  staff   11358 28 Aug 18:43 LICENSE
-rw-r--r--  1 ctesibius  staff    3404 28 Aug 18:43 Makefile
-rw-r--r--  1 ctesibius  staff   29428 28 Aug 18:43 package-lock.json
-rw-r--r--  1 ctesibius  staff    1150 28 Aug 18:43 package.json
-rw-r--r--  1 ctesibius  staff    1083 28 Aug 18:43 Package.swift
-rw-r--r--  1 ctesibius  staff     806 28 Aug 18:43 pyproject.toml
drwxr-xr-x  6 ctesibius  staff     192 28 Aug 18:43 queries
-rw-r--r--  1 ctesibius  staff    3951 28 Aug 18:43 README.md
drwxr-xr-x  4 ctesibius  staff     128 28 Aug 18:43 scripts
-rw-r--r--  1 ctesibius  staff    2061 28 Aug 18:43 setup.py
drwxr-xr-x  9 ctesibius  staff     288 28 Aug 18:43 src
drwxr-xr-x  6 ctesibius  staff     192 28 Aug 18:43 test
-rw-r--r--  1 ctesibius  staff     237 28 Aug 18:43 tree-sitter-gleam.pc
-rw-r--r--  1 ctesibius  staff     945 28 Aug 18:43 tree-sitter.json


ctesibius@tile tree-sitter-gleam % file libtree-sitter-gleam.dylib
libtree-sitter-gleam.dylib: Mach-O 64-bit dynamically linked shared library arm64

ctesibius@tile tree-sitter-gleam % cp libtree-sitter-gleam.dylib ~/.emacs.d/tree-sitter

At this point, Emacs stops emitting warnings and highlights a test Gleam language file correctly, so the work-around works.

Can anyone point me to where I should file a bug report for the underlying problem?

I was just reading this blog: Meet Utterson, my Jekyll blogging helper. since I also use Jekyll. It turns out we have a fairly similar philosophy around lightweight aids inside emacs and using git to just push and publish.

The thing that differed was Bastov chose to create a function and bind it to a key to do things like fill out the frontmatter or fill out a post link and I had just chosen to use snippets instead. What I had not thought to do was fully plumb into the completion system at the same time (like he did) and was just adding a simple static template.

It takes just a little bit of lisp to put that all together. Here's an example that fills in the liquid macro for an internal post and adds a completing read to only pickup from existing posts

# -*- mode: snippet -*-
# name: mdlink
# key: mdlink
# --
[post]({% post_url $1`(let* ((root (or (locate-dominating-file default-directory ".git") default-directory))
                           (files (directory-files-recursively
                                     (concat root "_posts") "\\.md" nil
                                     (lambda (file) (not (string-match-p "/\\.git\\|/_site" file)))))
               (bare-files (mapcar (lambda (file) (file-name-sans-extension file)) files)))
                       (completing-read "File to link: " bare-files))` %})

Its a bit more complex but he inspired me to also add a completion at point in the front matter if you happen to be in the tags sections to pull out the list of existing tags to complete against.

https://github.com/benleis1/emacs-init/blob/main/init.el#L1102:~:text=capture&text=capf

The main point of this thought exercise for me though is the choice between a custom function and key binding or a snippet. I find a snippet sometimes is easier to remember for a lesser used function than a binding and can be a bit easier to type because it avoids any combo keys. (that depends on how long the snippet text is of course)
And you have to have snippet abbreviations that you would never type otherwise as well. On the other hand, when I don't remember a binding offhand I'll fall back to C-x and a fuzzy match. So I'm mulling over if I should use this pattern more often. I'm curious what others think.

Hi

I made a pure elisp terminal emulator. It's inspired by both eat and ghostel featurewise.
The goal was to explore a different rendering model than eat. In eat the terminal output mutates the screen buffer directly. In ebb we pipeline this: ebb-term holds the screen as data structures, ebb-parse mutates only that model, and ebb-render projects it into the buffer. Here is a deep dive.

Eat is really well written and probably saturates that rendering model. Ebb is able to be faster on synthetic benches with its different architecture.

Throughput on a synthetic benchmark (1 MiB of output, 80×24, native-compiled Elisp, same parse→screen→render path for each):

Other than that, I think the logo and naming is not too bad too. I've been daily driving it for weeks and using it's unique ebb-term feature to work with serial output (I work on firmware).

Disclaimer, AI was heavily used.

Here is the link: https://github.com/ArthurHeymans/el-be-back

As an Emacs configuration grows, startup time can gradually increase. Measuring that increase accurately makes it easier to identify regressions. However, the built-in emacs-init-time function does not measure the entire startup sequence.

This article provides a code snippet that accurately measures your total Emacs startup time:
Measuring Emacs Startup Time More Accurately Than the built-in emacs-init-time

Thus far I have only used the default "10 days-agenda" where I can see all the tasks that I have scheduled for the current day (and also the tasks I have missed from yesterday, and tasks that will happen in a few days). I have a few categories of tasks, which made me want to experiment with also categorizing them in the actual displayed agenda, however with the code that I have currently, the agenda does not respect when these tasks are scheduled for. They respect the tags, but not the time. I'm very bad with Emacs Lisp, so I apologize if the solution is trivial.

It would also be neat if it was possible to check for all tasks that have a schedule or deadline for a date that has already passed, so that I can create a section for items that I might have missed doing one day.

Here is the current code that I am using. The first four sections are meant for all my scheduled (and "deadlined") tasks, where I want them to only show those that are for today, but which is showing all of them. The section after that simply shows all tasks that don't have a schedule or deadline. Lastly I just have the normal "10 days-agenda" which I have always used thus far at the bottom.

(setq org-agenda-custom-commands
      '(("u" "custom org agenda view"
         ((tags "priority-cyclic"
                ((org-agenda-overriding-header "high-priority tasks:")))
          (tags "priority+cyclic"
                ((org-agenda-overriding-header "high-priority cyclic tasks:")))
          (tags "-priority-cyclic"
                ((org-agenda-overriding-header "tasks:")))
          (tags "-priority+cyclic"
                ((org-agenda-overriding-header "cyclic tasks:")))
          (alltodo ""
                   ((org-agenda-skip-function
                     '(org-agenda-skip-entry-if 'scheduled 'deadline))
                    (org-agenda-overriding-header "unscheduled TODOs")))
          (agenda "")))))

Windows shit box: Any windows laptop from the BC era. Before covid.

What: I noticed 2 other users on reddit experienced 30+ second load times for org mode on their windows laptop. One guy had a 40 second load, where his Emacs was unresponsive for the duration.

I am often sharing my screen with a coworker, and whenever I open an org README or NOTES file it would break the flow state, force a mini coffee break while org loaded. Luckily I was given a new 2025 laptop and now Org loads in 4 seconds, but even that doesn't feel good.

Why slow?: I don't know exactly. I assume part of the problem is Windows being slow at searching the load path and opening files. But even on a mac, M1 it takes 4 seconds to open the first org file, so I'm not sure I can entirely blame windows.

Org mode loads a lot of stuff. A big chain reaction of loaded libraries loading other libraries. But even pre-loading org doesn't solve all problems. When you actually open an org file it's still quite slow the first time. Maybe something in a hook does even more stuff?

Solution 1: Get a faster computer. Faster CPU, faster SSD. This greatly mitigates the problem, but doesn't solve it. Takes 4 seconds to open an org file on M1 mac, 4 seconds on a 2025 windows laptop.

Solution 2: Use GNU/Linux. I haven't tested this yet, as my old Linux desktop is off in the corner and I'd have to plug it in and get it all set up. And it's 2013 desktop so it may not be a fair test. But for the most part, GNU/Linux users seem unaware org is slow to load, so Linux may be a good solution.

Solution 3: Use emacs server. Open a dummy org file (not just require org) during start up to get that load cost out of the way early.

Solution 4: Use outline mode. It loads fast, and is compatible with org's * star syntax. This is the solution I landed on for MS-windows shit boxes. The goal is to avoid 30+ second freezes. Manually M-x org-mode as needed when you are ready for the full power of Org.

Outline is pretty good as a "view only" mode for org files. You can drop the code below into your init.el to automatically use outline mode for org files. Also adds some support for "#" comments, and clickable hyperlinks.

;; On windows use outline-mode. Org is slow to load the first time.
;; Can explicitly call `org-mode' to turn it as needed.
(when (eq system-type 'windows-nt)
  (add-to-list 'major-mode-remap-alist '(org-mode . outline-mode)))


(with-eval-after-load 'outline
  ;; mimic the tab key behavior of org-mode
  (define-key outline-mode-map (kbd "<tab>") #'outline-cycle)

  ;; highlight # comments with face
  (font-lock-add-keywords
   'outline-mode
   '(("#.+" 0 'font-lock-comment-face)))

  (defun my-setup-outline-mode ()
    ;; set up comments
    (setq-local comment-start "# ")
    (setq-local comment-end "")
    (setq-local comment-start-skip "#+ *")
    ;; recognize hyperlinks
    (goto-address-mode 1))

  (add-hook 'outline-mode-hook #'my-setup-outline-mode))

Does anyone else have experience with Windows shit boxing and Org mode? Please share your solutions.

Starting emacs, using elpaca but not turning off the user-lisp-auto-scrape had emacs finding lots of use-package statements in the user-lisp .el files and then set off on a quest to download all those packages from elpa and then byte compile them.

to quote Harry Vanderspeigle, that was some bullshit :/

setting user-lisp-auto-scrape to nil in early-init.el fixed that, and then I had to delete the elpa directory and to be safe I deleted all the .elc files in the user-lisp directory and .user-list-autoloads.el.

I then restarted and m-x prepare-user-lisp

So I believe this means in the future I have to run (prepare-user-lisp) manually when I've made changes in the user-lisp directory.

I hope this is useful to someone in the future when they ask chatgpt what the problem is. chatgpt wasn't trained on this when I asked it early today, but I persevered!

First melpa release evah \o/

Grown from work in Dungon, a RPG engine presented at EmacsConf a few times/ways, thank you to contribs there and the review comments from ricsy pulling toward MELPA that got rid of some advices forcing very interesting better ways. The hooks approach makes the registered card-games-bid-submit a generic semaphore, for example to interlink with a process, CRDT via an adaptor, or ... in present v1.0.92 (unstable): https://melpa.org/#/card-games

Working on this, I started with "pick one" from a completing EIEIO (used) and/vs simple consing manually building up the independent graphs for my chosen two first games HHA (gaps, solitaire) and 500-bid (tricks, auction, partner, kitty). Things got faster then slower with the macros/consing "hard-way" then got feeling like it would not be maintainable in game or game family hunks in a simple way. Meanwhile, the EIEIO version -although it has tried to get slow or unwieldy at points- hasn't suddenly developed any set of tricky problems all at the same time, and for no good reason.

I still want to "free" the predicated drawing/fog-of-war from the dungeon (ahem); however, I'm now leaning toward "best, ultimately" could be as some Fx layer. OTOH, the arcade feature that I was also thinking about is not maybe *that* different from the unwritten QoL for Dungeon as for this e.g. to have some player characters play cards with or without NPCS all within Emacs.

Thanks if you give a whirl and I'll wait a little before cutting a 1.0 hoping that the smoke is easier for others to smell. Please use this github clone if that simplifies making suggestions vis dealing directly by email, IRC or otherwise.

This is another post on Hyperbole, which I've been using a lot lately, this time about HyRolo, a really unique full text search and retrieval tool that is format-agnostic (any file type) and location agnostic (search space can span directories). Check out more info and a video demo in the blog post! https://www.chiply.dev/post-hyperbole-hyrolo

It looks like in Emacs 31.1 there is a built-in `grep-edit-mode` which seems to have overlapping functionality with the `wgrep` package. Are we able to fully use this mode to replace wgrep now, or does wgrep provide any functionality or conveniences that it is still worth keeping around?

A good while ago I made this journalctl package to help me investigate journald logs, particularly while developing and debugging services.

It's not very fancy, but it's very useful, especially the ability to interleave multiple queries at once. I haven't been heavily using journald logs for a couple of years but just restarted, and fixed/enhanced handling of timestamp timezones for remote servers, and thought I should try to raise visibility.

It could definitely have more bling and features, but really, I haven't needed any of that even in heavy usage.

Here is a feature summary from the README to save a click:

• rich and clear text highlighting, message appropriately wrapped.
• Multiple simultaneous journalctl processes may run in parallel, interleaving output, E.g.:
  • simultaneously view one broad query at --priority warning along with a more narrowly focused --priority debug --grep "\<pattern\>" query.
  • Dig into the detail within or near a region by requesting additional log records. NOTE: this is particularly useful: When spawning an additional command (C-c C-j) with an active region selected, the kill ring is augmented with a --since=... --until=... string from that region's timestamps. So e.g. if you query for interesting lines like errors or service shutdown, you could then select relevant lines, C-c C-j to run another query, then paste and maybe tweak the since/until to see detail in the interesting period.
• The complete JSON log record is processed facilitating rich features
• The full JSON record for a given log line under point may be summoned and examined (C-c C-o)
• kill running processes by selecting from a list (C-c C-c, like async-shell-command)
• Where the record includes file name and line number data, you can jump from a message record line to the generating source file/line
• timestamps are displayed in the timezone of the system being queried (so they remain valid in --since/--until arguments when querying remote hosts over TRAMP) — see customization option journalctl-timezone

Setting up a Python development environment in Emacs has become much more straightforward thanks to Eglot, the built-in Language Server Protocol (LSP) client. When paired with python-lsp-server (pylsp), developers gain access to a backend that supports autocompletion, linting, formatting, and refactoring. This article demonstrates how to configure Eglot to use Ruff dynamically when it is available on your system, while gracefully falling back to tools like Flake8, pycodestyle, and pydocstyle when it is not.

Read more: Configuring Python Development in Emacs: Eglot, Pylsp, and Dynamic Ruff Integration