there is a before-save-hook in emacs you could use

Yes but then I need to find out whether it's Clojure file. Does it also save the file? I found that with current ~undo-history~ files my file saving takes quite a bit of time already. I would like that the formatting would not save the file and would happen before it :thinking_face:

(defun cider-format-buffer-back ()
  (save-excursion
    (cider-format-buffer)))

(defun add-cider-format-before-save ()
  (add-hook 'before-save-hook 'cider-format-buffer-back t t))

(add-hook 'clojure-mode-hook 'add-cider-format-before-save)

The formatting does not "save the file" - it is done to the buffer before your save command writes the buffer to disk.

Are you talking about cljfmt or in general. In case of cljfmt - https://docs.cider.mx/cider/usage/misc_features.html#formatting-code-with-cljfmt

This case was already covered by @UE1N3HAJH as well.

I have created for myself nvim config where they format code using LSP server on each file save. So I wanted to mirror the workflow and compare. Previously I was using = to format but = is broken on nvim and it's also not a good idea to spam around = for formatting. So formatting on save looks kind-of sensible. So I also try to find out which tool is more configurable. Also I don't know why but nvim navigation (just basic jumping around) in clojure files (even ones with 2k LOC) seems incredibly fast (even at this moment I have a test file which has 1134lines... wow) (probably it's because in Emacs evil mode is interpreted on higher layer; weird feeling).

@U028ART884X if you notice specific performance issues which are easy to replicate, please don't hesitate to drop an issue on evil's github page. Some things like recursive macros and ex commands are already known, but new issues remind me what things annoy users the most 🙏

I can name several from the top of my head even now (mostly not related to CIDER). For me the most annoying thing is that when I use layout saving (in spacemacs you can find it at <SPC>l or layouts-transient-state) it takes forever to load. I think it unzips some kind of undo-history files and loads all buffers that I had which is a lot. So when I start emacs it's fast but then I click to load my previous layout and it locks the editor for about 30s or something. CIDER is not related to this one. But on nvim I don't have workspace reload option. So I can't compare it. Also one more thing is the ~undo-tree files which prevent me from using regular good old grep from command line. CIDER-specific ones are (or somehow directly related): Formatting large output in the bottom modeline buffer and displaying it twice - in the buffer itself (near the line) and in the buttom modeline buffer too. So the formatting is also probably done twice. So if I eval a list that has 1000 integers it takes 200ms+ to display it but at least it doesn't lock up the editor and that's what's important. Huge REPL outputs are slow. If I start my server and it produces several hundred lines of output I deliberately close the REPL buffer because it's very slow to render it. I think it can sometimes unrecoverably lock up the editor so I learned to avoid large outputs there or in the bottom minibuffer. I think that over time this improved quite a bit, I think I've had not that many editor lockups for past 1-2 years. I remember that I had some kind of bash command to kill Emacs running process without killing the whole of it. I don't remember what it was (there is no Ctrl-g when main thread locks up). And if you accidentally produce about 10k LOC of output while REPL is open your editor can lock up for quite some time or even for good. I don't know if these are fixable. I didn't report them because I know that these must be incredibly hard to fix. But the double buffer display one could be fixed by having a variable that says "display either in here or in here". Only one variable and not two variables so that there would be only one place to display it.

What throws me off a bit is that when I reevaluate my expression and send it into the result buffer it doesn't blink anymore. It's a performance fix but actually it decreased my usability because I don't know when it finally reevaluated the form. Yes, I tend to reevaluate the same form over and over (e.g. if I insert/delete something from DB). So that little blink was actually useful for me because evaluation takes time and much of the times it's not immediate. And without the blink I tend to wait and not know if it worked at all. Maybe my command was bad. So IMO if you fixed performance there then I would like to have some kind of indication that the newest evaluation succeeded. Also I like that result more than cider-inspect one because it's basic and displays only what I want. (and it can lock up the editor if there is a lot of output there but I prefer it over cider-inspect because it's as basic as I expect it to be; also I can browse it and walk inside using evil mode keys) Also instead of the rendering into the fixed buffer why not allow to render into the floating one as you render exceptions? Could be a config option :thinking_face: But then you won't be able to view the code and the output side-by-side and it doesn't really work that well. But it would work for copying. Oh right. I like the test result buffer very much. But I can't use evil mode there. But the buffer works. From CIDER I mostly use cider-result and test-result. Conjure doesn't have test-result

> I remember that I had some kind of bash command to kill Emacs running process without killing the whole of it. probably pkill -usr2 emacs or similar

I don't remember what command it was. I don't want to boot up my old laptop. I remember that if I kill it then something may not be usable (for instance treemacs wouldn't work anymore). So that's not a good thing to do. But restarting a REPL is also not a good thing. 😕

Most of the above are more cider/emacs related actually (which is fitting for this channel 😄 ) - I'll have a more thorough read at some point and make evil issues out of anything worth taking a look at for evil. Lots of good stuff there - thanks for taking the time to type it all out!

What version of emacs are you using @U028ART884X? I realise some professional environments force use of older versions, but if possible I would recommend upgrading to the latest version you feel comfortable using. Undo/redo is now properly implemented (undo tree is no longer necessary), native-compilation speeds up lots of things a bit, and files with long lines no longer slow down emacs so much (on very recent versions). Worth taking a look if you can.

Currently

GNU Emacs 28.1
Spacemacs develop branch 2e897fcc8

I can generate the spacemacs issue debug info for you if you want. It's very descriptive.

Ah you should have most of the above in emacs 28 afair

I'll paste it here.

#### System Info :computer:
- OS: gnu/linux
- Emacs: 28.1
- Spacemacs: 0.999.0
- Spacemacs branch: develop (rev. 2e897fcc8)
- Graphic display: t
- Running in daemon: nil
- Distribution: spacemacs
- Editing style: vim
- Completion: helm
- Layers:

- System configuration features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

I think that things are improving over time and stability is slowly improving. Maybe it's Emacs 28, maybe it's something else. I'm not sure. That's the thing with these tools. They change all the time.

(I haven’t read the full thread, sorry if I missed anything) If you don’t mind using LSP for formatting, I have this (uses eglot, will need small tweaks for lsp-mode):

(defun apt-eglot-format-if-clojure
      (&rest _)
    (when (and buffer-file-name
	           (derived-mode-p 'clojure-mode)
	           (bound-and-true-p eglot-managed-mode-hook)
	           (bound-and-true-p inf-clojure-minor-mode)
	           (buffer-modified-p))
      (eglot-format)))

(dolist (command '(other-window
		             other-frame))
    ;; TODO: might timeout and make Emacs lag
    (advice-add command :before #'apt-eglot-format-if-clojure))

However, as the TO-DO says, it might cause some performance issues if the server takes too long to respond. So I stopped using it.

i had the undo-tree thing happen after an update. you can disable the history file or set a different folder (i disabled it, i don't really care about undos after an emacs restart). For the repl output being slow, i thing something improved last year, some modes now stop working when the blob of text is too large. But yeah I do feel like there is room for improvement here the other points i can't comment i don't think i've encountered it (and i don't use evil mode) undo-tree fix: https://www.reddit.com/r/emacs/comments/tejte0/undotree_bug_undotree_files_scattering_everywhere/