search

rust-lang / rust-mode

Emacs configuration for Rust
Apache License 2.0
1.1k stars 176 forks source link

Prettification customization is broken #535

Open jjpe opened 3 months ago

jjpe commented 3 months ago

The section on prettifying in the README.md mentions being able to add one's own prettifications.

While really cool in theory, in practice I cannot get that to work at all. Meanwhile, the built-in prettifications work without issue. When I go and check the rust-prettify-symbols-alist var after loading a Rust project, it just contains the built-in prettifications (<=, >=, -> etc). While I haven't checked the code, this leads me to believe that rust-mode bluntly setqs the prettify-symbols-alist or rust-prettify-symbols-alist var rather than adding or pushing to it, as it should. The problem here is that if I alter the value of prettify-symbols-alist, I need to turn prettify-symbols-mode off and on again in order to use them, and that process erases any modifications I (or my elisp code) makes to prettify-symbols-alist.

So this means I can't update prettify-symbols-alist before loading prettify-symbols-mode (because it will get overwritten), and I cannot do it after (because prettify-symbols-mode will not pick it up until it is reloaded, at which point it will overwrite prettify-symbols-alist).

While it shouldn't be a problem (again in theory), one last thing worth mentioning is that I'm using Prelude.el. EDIT: at this point I'm 99.9% confident that this isn't the issue.

EDIT: Suspicion confirmed, see rust-prog-mode.el in this GitHub search result.

psibi commented 3 months ago

I would be to accept a PR for the same.

jjpe commented 3 months ago

Strange. I had a commit all ready to go, and when I went to test it, my definitions just started working with upstream (i.e. I wasn't loading my fork).

It seems like the behavior I observed is the result of a strange interaction between rust-mode and desktop-save/desktop-change-dir.

The weird part is that in one library file I can see the behavior I observed earlier (and reliably so), and in a sibling library file (i.e. in the same repo, and both files live in $PROJECT_DIR/src) I observe the correct behavior, also reliably. What's more is that if I close and reopen the file in which the erroneous behavior is observed, after reopening the correct behavior is observed.

I'm not sure what should and could be done to fix this TBH. In any case it is apparent that the patch I had ready is not useful in its current form.

I'm not quite ready to close this issue just yet; I'll think about this for a little while, see if a solution presents itself.