Emacs Lisp

When writing elisp code and looking for a function that would do something you need, what do you use to find it, inside Emacs only (no web search)?

Emacs has a lot of built-in documentation; it has

• a ,

• an ,

• all code has ,

• for other outside help, it has an excellent support for the man pages with:

  • and

On top of that you can install other complementary packages that add more help search features such as:

• (which is excellent)

There's a lot of commands available with the C-h or <f1> key prefix and lots that are not bound by default.

I documented the ones I know and created some others in my system in this PDF:

Despite all of that, every so often, I stumble to find the name of a function that I know exists but can't remember the name. The other day I was looking for the predicate function that tells whether point was at the beginning of line; bolp.

• I tried typing beginning and using C-M-i to complete it. That did not work.

• I typed C-u C-h d for apropos-documentation and got a long list of suggestions from which I searched for "beginning .? line" with some regexp and finally I found bolp at line 7833 of the Apropos buffer.

I eventually found it, but it took longer than I like. And was very tempted to search the internet or depend on a connection to the outside world (eg, IA). But there must be a better way to quickly find functions in Emacs.

How do *you* quickly find the functions you need *inside Emacs*?

Lately I've been using Lem (an emacsen written in Common Lisp and using CL as extension language) and I've been wondering about the performance of CL relative to EmacsLisp, especially now that EmacsLisp can be compiled to native code. Has anyone benchmarked these two languages recently?

I prefer CL anyway, and without native compilation turned on I'd expect EmacsLisp to lose by a good margin, but with native compilation should make the comparison more interesting.

EDIT: to clarify, by CL I mean a specific implementation, probably SBCL. And I'm not looking for comparisons between the two editors, just the two Lisps.

A good while ago I implemented a splay tree in elisp. It's been serving me well and I'm curious what people think of it and/or if anyone else may have a use for it. The code is currently part of a package with another purpose, but is package agnostic and doesn't depend on anything else in the package (or on anything outside of standard elisp constructs for that matter).

My use case for it has been to keep track of token positions in buffers and efficiently determine the context for which to provide code intelligence. I needed an efficient data-structure that accommodates for localized "hot" access zones and doesn't use an insane amount of memory.

I'd like to tell a little bit about my rationale and how it came to be. Initially, I tried to use hash tables. But a requirement for determining the context of `point` is finding any token that starts before and ends after `point`. It is this information that allows phpinspect to accurately resolve the type of a variable in a function or the type of `$this` inside a class, among other things. My initial approach was to fill a hash table with exact start and end positions of parsed tokens. It required an insane amount of table lookups in large buffers (one for every character before `point` in the buffer) to find enclosing tokens. Then I tried an n-ary tree implementation, but the performance was laughable as n-ary tree lookups are terribly inefficient. Then I implemented the splay tree, but it still wasn't performant enough. The nature of a splay tree is that it gets re-balanced, or "splayed" to make whatever node you last accessed the root node. This is great for frequent access of a specific region, but not so great when accessing far-apart regions. Moving `point` from the start of the buffer to the end would result in an expensive "splaying" of the entire tree.

Ultimately I ended up combining the splay tree and the n-ary tree approach for what I think is a best-of-both-worlds kind of scenario. All of the tokens in a buffer are stored in an n-ary tree, but with a twist: the children of each node are stored in a splay tree. The result is that only the nodes of tokens being actively edited and their enclosing parents are splayed while the rest of the tree remains untouched.

Actually, I even kept the hash-table in the mix for a best-of-three-worlds scenario. When only a single lookup of a token starting at an exact point is required, the hash table is still the more performant option so I kept it around. It is heavily used for incremental parsing of edited buffer code, but I won't bore you with the details of that at this time :).

The code:

I'm a bit anxious about your opinions as there's quite heavy use of `define-inline` and `defmacro` ;)

Read , it recommended

• Indent the file using the default indentation parameters.

which means enabling indent-tabs-mode and results mixed SPACE and TAB.

Checking some Emacs built-in packages, such as simple.el and indent.el, via global-whitespace-mode, you will find they are all mixed SPACE and TAB.

However, many recommend (setq-default indent-tabs-mode nil) to use spaces for indentation. No hard tabs.

Do you use TAB or SPACE for indenting Emacs Lisp code?

Personally, I prefer SPACE over TAB for two reasons:

1. Many other programming language now use SPACE for indentation.

2. SPACE is compatible with more editors without special settings. Note that because of the tab-width variable, using TAB is not a problem in Emacs, but other editors might not. For example, this let* is not aligned on .

TAB has its own advantage, such as reducing code size, but it's no longer a problem in 2024.

Unfortunately, if you'd like to submit patches to the GNU Emacs community, you might still have to use TAB instead of SPACE to follow the convention. That is why I am still keep indent-tabs-mode enabled now.

Any comment about it?

I'm a "Neovim Refugee" trying to get a deeper/better understanding of how emacs lisp works and how i can use it to expand on my emacs setup. I have never done anything in lisp before and still struggle to understand how single quotes signify a function or what ever.

With that said, i was also planning on doing AoC this year. Originally i wanted to look into zig or go, but now think that this might be the opportunity to dive into lisp for a bit.

But with knowing basically nothing: Is this even "viable", or advisable? Should i be looking at common lisp instead? Or would you say that's a pretty dumb idea and i should rather learn it in a different way?

Have you ever wanted to write a blog:

• contained in a unique org file,

• rendered with only one Emacs command,

• that can be modified by writing Emacs Lisp code (and CSS too),

• with "html templates" that are plain Emacs Lisp data,

• with no config file,

• and no dependencies on external static site generators?

If so, you might be interested in one.el a simple Static Site Generator for Emacs Lisp programmers and org-mode users.

👉

👉

👉

Hi,

I've been using Doom Emacs for about a year. I want to learn Emacs Lisp. The advice I've read is to solve an actual problem I have with Emacs Lisp. But my mind draws a blank when I think of problems I'd like to solve.

What have you written elisp for recently? What problems have you solved by writing an elisp function or mode?

Thank you.

I've noticed that many packages and libraries developed for emacs ar stored entirely in one huge file. For example I was just checking out the mpc source code and found out that it is a 2000+ lines file.

Is this a normal and accepted practice? I've never coded professionally in lisp based languages, but from my experience I always try to make my files no more than 100 or 200 lines long at most. Otheriwise it gets hard to navigate the code in my opinion.

Maybe in elisp this isn't as bad of a practice? Are there ways in emacs that can help work with long files that I'm not aware of?

My journey with Emacs began with trying to learn Common Lisp. I first set up my Emacs development environment with SLIME and made myself familiar with some Emacs key sequences. A few months later I am still learning Emacs and I am beginning to love Emacs Lisp.

Emacs Lisp looks like a powerful language on its own. I can execute Emacs Lisp code from command line as a script using emacs --script foo.lisp. I want to know if anyone here uses Emacs Lisp as a full blown general purpose programming language.

[ Also x-posted to ]

As part of their 12in23 challenge (trying out 12 programming languages in 2023) the exercism platform is currently highlighting the lisp family of languages — including Emacs Lisp.

Announcement video:

Emacs Lisp track:

I did not assess the quality of their material (although I heard good things about their Rust track) but, in all cases, I'm thinking it could be a good way for people not familiar with Emacs Lisp to start tweaking their editor. :-)

That is, if you want a new thread to execute a function, just create an entire new OS process instead that copies the current environment and let the OS manages the all the multi-threading burdens for you. Other features includes process management, thread/process pooling.

This seems to be the simplest option to make use of CPU power as physical cores are getting cheaper, so what haven't this happened from all those years?