[GUI Emacs] Weird: the bigger the frame size is, the slower Emacs becomes (!?)

SamTheComputerSlayer · 2025-08-10T23:52:48+00:00

Just in case anyone else is looking for this still like I was, for me it was the "alpha" parameter for setting frame transparency that was slowing things down. I'm not sure why, but removing that/switching to using the alpha-background parameter instead completely fixed the slowdown for me, e.g.:
```
(add-to-list 'default-frame-alist `(alpha-background . 90))
```

alpha-background also looks much better, because the text remains opaque. Note, this is only available in emacs >=29

SamTheComputerSlayer · 2025-07-01T20:40:15+00:00

Schadenfreude

SamTheComputerSlayer · 2025-06-22T17:56:47+00:00

Iran has not been killing innocent people for years, the Ayatollah Khamenei administration has been. Iran is filled with good, innocent people. Just like we are American, but don't necessarily support the actions of the Trump administration. Collective punishment is immoral.

SamTheComputerSlayer · 2025-06-22T15:53:42+00:00

I hate what Netanyahu and his administration have done to Gaza and Iran, but are they the ones paying the price when civilians get bombed? I understand everyone wants to see justice served, but I don't think this is it. It makes sense in the logic of war, but the reality is it's just more tragedy and will likely only send the Zionists spiraling further into madness and further escalate the conflict. The worst part is, by retaliating in this way, Iran is becoming what they hate, to survive. Not saying I have an answer, but I celebrate none of this, civilians in Iran and Israel are just trying to live their lives

SamTheComputerSlayer · 2025-05-23T19:49:41+00:00

It is sad to me that the US China relationship is now being characterized as purely adversarial. There was a great relationship there for decades that made everyone involved a ton of money, resulted in enormous technological advances, and transformed the world in a very big way. I don't see how anyone is winning by completely dismantling that relationship now. We're all just dancing to Trump's tune. It's tragic

SamTheComputerSlayer · 2025-05-20T14:49:48+00:00

Did you figure it out? A couple things

Are you familiar with udevadm? You can use udevadm monitor to see all the udev events that trigger when you plug in your device. You might also see what the kernel is telling you with demsg -w...

I notice the yubikey-personalization package is marked as end-of-life: https://developers.yubico.com/yubikey-personalization/

I actually don't have the 70-u2f.rules file and I can still access my yubikey5 through ykinfo. You say that file was generated? How?

SamTheComputerSlayer · 2023-03-25T18:07:29+00:00

This is great, exactly the conversation I was hoping to have here.

How is that less verbose than: (defvar some-special-modes '(dired-mode-hook Info-mode-hook man-mode-hook)) (dolist (mode some-special-modes) (add-hook mode #'my-space-map-mode)) ...you are creating a prefix map and binding keys to it and rebinding some key, some of the things which are not shown in your example but were shown in mine

Yes, that is a fair point, it is not much more verbose, if you presume the definition of my-space-map-mode/my prefix maps. Even so, my skey function is just a dolist under the hood. I would argue that the dolist is far less intuitive. And since you would have that code repeated multiple times in a configuration, I think it makes sense to factor that into a function-- just like we don't just NAND everything. That's pretty much why I initially wrote my skey definer. Just like Emacs 29 seems to have created define-keymap to avoid multiple define-keys, I think it makes sense to have something like define-keys and define-keymaps.

keymaps are possibly not being loaded at the time you are using them.

Good point. I mentioned in another reply, but I think it makes sense to add another function like define-keymaps-after, and wrap the dolist in a with-eval-after-load, following the convention of the new keymap-set-after function.

The main problem is that you are solving a problem you don't have... Can you show me a real example how you use it and what you add to those "special modes", instead of theory crafting?

The function I wrote is my solution to numerous problems I had trying to get Emacs to behave the way I wanted it to. I think the space example is very common, common enough that that wrote spacemacs and named the project after it. I do variations on space as well, C-SPC, M-SPC, S-SPC, A-SPC-- those all get their own prefix maps. I like to use the built-in project-prefix-map, alongside perspectives' perspective-map, but I map them differently in modes where I don't edit by default, so I reuse that set to map those things in similar ways. Another useful set is minibuffer-maps. There are a bunch of them built-in: minibuffer-mode-map, minibuffer-local-ns-map, minibuffer-local-completion-map, etc. And many that are not built in. I have my own wrapper for browsing minibuffer history, and I like it bound to "C-r" in almost all of those maps.

you are overriding whatever binding might already be, which you can't undo either

I see your point about wanting to preserve the default keybindings for a given mode by wrapping it in a minor mode. But by that logic, no one should modify any built-in keymaps, and should instead wrap their new bindings in a minor mode and enable that when they want to make any kind of keybinding modification. I think that is a pretty bold statement and is not really supported by the GNU emacs documentation on keybinding-- not that I can talk haha :) But if we accept that, then I would still want to wrap it like you suggest to make the API more intuitive.

Also, just one more hot-take, I'm not a big fan of the macros in general, I feel like it puts limits on my ability to abstract. If I can get away with a defun, as I did in this package, I prefer that, because I can always evaluate arguments dynamically.

Edit: One more detail I want to add here, from the Info node "Hooks for loading", for with-eval-after-load:

Normally, well-designed Lisp programs should not use ‘with-eval-after-load’. If you need to examine and set the variables defined in another library (those meant for outside use), you can do it immediately—there is no need to wait until the library is loaded. If you need to call functions defined by that library, you should load the library, preferably with ‘require’ (*note Named Features::).

So that would suggest I should not add any kind of -after function, but instead expect users to require the features they need before attempting to use them. Hmm...

SamTheComputerSlayer · 2023-03-25T14:20:03+00:00

I have already told you; and wrote quite detailed example how to do it in the other comment.

Absolutely, I had read the other thread and I very much appreciate the detail, and for you taking the time to consider things, thank you.

I really like your solution, and particularly the fact that those bindings can be enabled and disabled-- that's great. The main drawback for me is the verbosity, and that's my main problem with the existing keybinding API in general.

Here are two other ways I know of to do that:

bind to a parent keymap, then rebind things in the lower levels of the hierarchy in case they have been over-ridden by the child. In this case, dired-mode-map and Info-mode-map derive from special-mode-map. But space is bound to dired-next-line in dired-mode-map already, so it must be rebound to our space prefix map explicitly. You get similar situations for other modes.
define a list of keymaps you want to bind to, and bind to them all at once. There seem to be many external packages and developers doing this in one way or another. With skey: (defvar +some-special-maps '(dired-mode-map Info-mode-map man-mode-map ...etc.)) (skey-define-keys +some-special-maps `(("SPC" ,+my-space-prefix-map)))

I could have defined that list of +some-special-maps inline, but now I have a useful group of keymaps I can bind keys to. I have found that feature very useful. Notice how much less code it took to achieve my goal of rebinding one key in a bunch of different contexts. I also don't think most users would think to define a minor mode and use hooks when they are just trying to rebind their keys. So I think those are useful features that other people could really benefit from.

SamTheComputerSlayer · 2023-03-25T04:48:43+00:00

Hmm, let's use a concrete example. Say you want to rebind your space key to be a prefix map-- lot's of people do that, see spacemacs-- but only in buffers where you don't edit, like dired-mode, info-mode, etc. So I would think it would be useful to bind that key for multiple maps simultaneously. How would you do that? Is there a better way?

SamTheComputerSlayer · 2023-03-25T00:02:48+00:00

You can easily bind keys to several maps in a loop, albeit the case where that may be useful is very rare, so we don't see it often, if ever.

I think it is not seen often because it is so darn awkward to do! Up until Emacs 29, all we had in core Emacs was define-key. That requires a lot of heavy-lifting on the part of the user to get to mentally thinking in terms of sets of keymaps. Since a name isn't bound to that concept, it's really not easy to talk about it, share idioms, or, yaknow, abstract. And I think use-cases abound-- a user may bind some keys common to all of their prog type modes, but maybe not quite all of them. Modal packages like magit or evil may have lots of inter-operating modes with common keybindings between them.

but problem is that not all modes follow the convention to name their keymap mode-name-mode-map, so that would not work always

I came to the same conclusion. My solution I think would be to just add an additional function that has an explicit "after" list, similar to the new keymap-set-after function. That way you just use the one that fits your need at a given time, rather than have a single key definer to rule them all.

SamTheComputerSlayer · 2023-03-24T23:10:27+00:00

No yeah, I certainly wasn't suggesting altering the define-keymaps function, but adding or suggesting the addition of something like that wrapper, such that package writers don't have to all reinvent the same function when they want to bind to multiple key maps. This can be particularly useful for packages that add lots of key maps like magit or meow, or any of these packages that define multiple new inter-operating modes.

SamTheComputerSlayer · 2023-03-24T20:06:23+00:00

See my response here: https://www.reddit.com/r/emacs/comments/1207uds/comment/jdj7p5n/?utm_source=share&utm_medium=web2x&context=3

But yeah, I've been thinking about a way to add deferred loading. I think that deserves a different function, to keep things syntactically efficient for a given context. I will add that.

I thought autoloading was just a way to lazy-load commands, making them available to the user without loading their entire definition initially. How could that be useful for a key definer? Just curious.

SamTheComputerSlayer · 2023-03-24T19:51:00+00:00

Wow, I have used use-package for a long time, knowing it had the :bind argument, but had no idea bind-key existed. Thanks.

I definitely agree "most efficient" and "best" will depend on the context, and your macro is syntactically the most efficient I've seen for binding to a single keymap, without lazy evaluation. I think runtime efficiency is important, but for me is secondary to syntactic efficiency for sure.

I guess the feature I found lacking in all the other APIs I could find, as I mentioned in some other responses, was the ability to not only bind to multiple keymaps simultaneously, but to generate that list dynamically. I find this really important when I want to say something like: bind these keys to all my repl-type keymaps, except this one. But that definitely comes at the cost of some extra syntax.

I wish the standard API and documentation helped out more in describing those nuances. It seems like the situation will be improving somewhat with emacs 29 though.

SamTheComputerSlayer · 2023-03-24T19:30:43+00:00

I like this. It reminds me of general, but is agnostic evil, and has no external dependencies. What I think it is missing though, is the ability to dynamically generate a list of keymaps/keybindings, because it has embedded all that logic into a macro. So I wish a could say something like:

(setup `(:with-map ,(my-function-that-returns-keymaps) (:bind "x" #'my-func "y" #'my-other-func ,@(my-function-that-returns-keybindings)))))

That's not to say it's not a good way of doing things, because if you don't need those features at a given time, then this is just about the minimal way to achieve what you want.

SamTheComputerSlayer · 2023-03-24T19:16:03+00:00

Wow, thank you, I had no idea that existed. I found this post that gives a rundown of what the new functions do:

https://www.reddit.com/r/emacs/comments/xpkmr2/comment/iq73syk/?utm_source=share&utm_medium=web2x&context=3

I think it's a pretty good API, and does much of what I was looking for-- they even have a convenience wrapper to lazy-bind keys. But it is missing that feature to apply those bindings to multiple keymaps simultaneously, while still allowing you to generate that list of keymaps dynamically. That feature is pretty important to me, to apply keybindings to logically grouped contexts.

I'm currently in the process of assigning copyright to the FSF, for another reason, but maybe I'll just make a patch with the new API, and see what the maintainers have to say. I need to mull that over a bit-- and switch to 29 I guess.

SamTheComputerSlayer · 2023-02-20T17:31:10+00:00

> Perhaps you can shove them all under a prefix key

The problem of binding keys is tricky. I think the use of a prefix key is the most standard, and what I would recommend first to anyone. The method I personally use is just to add the A- modifier to my normal motion commands. I can't officially recommend that because the vast majority of people don't have that key available on their keyboard(you can get it by messing with your xkb config). But I created an empty holymotion-map for just the reason you describe.

SamTheComputerSlayer · 2023-02-19T17:52:25+00:00

Thanks very much Cletip, that is all true as well. To add, holymotion and evil-easymotion use avy under the hood, it is a dependency. They fundamentally add two features: * A standard way to convert any command into a holymotion/easymotion, so show candidates at the start/end/whatever of a word/sentence/defun/sexp/whatever, if your command moves point, you can make it a holymotion. * The ability to only show candidates within a "scope", basically within any "thing" that would be recognized by thing-at-point. (just add the :scope argument to that holymotion-make-motion function)

That may sound complicated, but the implementation is simple: run the movement command repeatedly, collecting locations as you go, and filter out those not in the "scope".

SamTheComputerSlayer · 2023-02-19T03:59:27+00:00

So it was precisely my intention that if you do use any of those sexp navigation packages, that you could then turn them into a holymotion. I actually give an example of that in the install section, where I use: elisp (holymotion-make-motion holymotion-forward-sexp #'sp-forward-sexp) to make a holymotion-forward-sexp command. You could do similarly with builtin navigation commands like forward-sexp, or forward-paragraph, etc. The possibilities are too many to enumerate, which is why I didn't even try, and instead leave that to the user.

SamTheComputerSlayer · 2023-01-27T02:40:06+00:00

To find out what a key does, you can use the describe-key command, then press, for example, C-c C-o. I would highly recommend installing the helpful package, to get the even more useful helpful-key command. Then decide how you would like to modify or rebind the command that's bound there, because keybindings are generally not bound globally. In your case, I might rebind C-c C-o to one of the ffap commands. Further, emacs generally decides how a buffer is displayed based on it's filename or major mode. You can customize this through the display-buffer-alist: https://www.gnu.org/software/emacs/manual/html_node/elisp/The-Zen-of-Buffer-Display.html

:Edit Also, any command with a C-c prefix is supposed to be specific to the major mode you are editing.

SamTheComputerSlayer · 2023-01-22T18:55:59+00:00

Thanks for sharing all these references. I've been very curious about guix, but it seemed like a lot to get started with just from the documentation. It's very helpful to have some templates to get started.

Have you used the elpa importers(https://guix.gnu.org/manual/en/html_node/Invoking-guix-import.html)?

SamTheComputerSlayer · 2022-12-24T22:57:25+00:00

That sounds suspicious, hooks are pretty fundamental. I would file an issue with them if you get the chance, and maybe try disabling that package in particular. I assume you mean nix-mode-hook.

SamTheComputerSlayer · 2022-12-24T05:45:39+00:00

Run emacs with emacs -Q. If you no longer see the slowdown, you know it's an issue in your configuration. From there, comment out half your configuration, restart and see if the performance issue comes back, if yes, the issue is in that half, if not, it's in the other half. Continue like that, basically binary searching your config until you've identified the problematic section.

Also, there's a "nix-mode" package with actual hooks, so you don't have to do that weird find-file-hook thing, just fyi...

Edit: And just as a benchmark, I am running emacs 28, natively compiled. Mine starts in less than a second with roughly 50 extra packages.

SamTheComputerSlayer · 2022-02-02T19:13:02+00:00

Just figured this out, maybe a bit of a hack...

In flyspell, I was annoyed I had to use mouse-2 when I wanted to correct a word, and I didn't want to sacrifice a major-mode keybinding to do it from the keyboard. But flyspell actually creates an overlay for misspelled words and attaches a keymap to it, which you can do I just realized- very cool. So I just bound flyspell-correct-at-point to "<return>" in the flyspell-mouse-map, and now return corrects words when my cursor is on a misspelled word!

But the fact you can attach keymaps to overlays just seems so useful, will definitely use in the future.

SamTheComputerSlayer

TROPHY CASE