Found it. It's Ctrl+o and Ctrl+i. Not sure why to use Ctrl for vi-like jumps though... Inconsistent.

See https://neovim.io/doc/user/motion.html#jumplist Some plugins like https://github.com/nvim-telescope/telescope.nvim expose it through a fuzzy search interface as well.

I use all the time:

vim.keymap.set('n','<leader>p', ':Telescope oldfiles include_current_session=true<CR>')

That's slightly different from :Telescope jumplist. One difference is the jumplist is per window.

Alright. Thanks. At least this exists. For now I decided that I'll use Spacemacs for now (as I do for several years) as Conjure mode doesn't have some important features. Maybe I'll try to use it again but not now.

What are the features that were missing for you?

These are only ones that are related to Clojure and file browsing: • Rerun failed tests, • Jump to a failing test (in spacemacs they have a test error buffer where you can see diffs and choose a test to jump to) but well... can we have at least a simple jump for now...? • Follow open file in the directory tree without clicking any buttons (I could do it with NvimTreeFindFile but I don't want to spam it). This is probably not an issue as I wrote my Bachelors with regular VIM+NerdTree and I was fine. But I didn't have more than 20 TeX files so probably that's why. For this recent NeoVim config I used FZF to find files and it's great. It could also find colors which is also nice. But there is no ample-zen theme in vim though. Also vim highlights keywords as a whole and Emacs highlights the namespace and name separately but probably it's configuration. But minor inconveniences are there probably because I tried to configure it from scratch. In spacemacs though I have problems that I can't use VI-style keybinds in various inspection and test buffers. And that makes whole distribution fall apart somewhat. Also you can't not notice the slowness. It feels slow when I open 2.5k LOC clj file. But other than that it's solid. I also like that VIM doesn't render anything in a special way as Emacs tries to be smart in some buffers and change the font size because it's a "heading".

I saw your question in #conjure, what I do in many cases is if there is a test that I am driving, is I will set a mark on that test, then evaluate at that mark

Oh right. Mark+eval feature is awesome. I don't know if it exists in spacemacs but it's really nice.

and by using a capital letter mark, it allows me to eval that mark from whatever files I am in

plus it gives me a jump back to that test 😉

Actually that's nice if you're changing some third source file which actually causes the test to fail :thinking_face: And I didn't even know that marks could jump through files :thinking_face:

capital letter marks do as they are global marks, lower case ones are buffer specific

Nice. Jump works on Spacemacs too. But I know that they don't have eval-at-mark.

Oh right. In Spacemacs CIDER - if you evaluate things and it gives a large result it renders first ~10 lines in the bottom minibuffer. And if I have a large map it can take almost 1 second. And it somewhat lags UI, then it jumps. This is one of the reasons why I came back to look at VIM again. The other one was that I couldn't use f{ in an inspection buffer. One thing that I miss from spacemacs is the evaluation result buffer. But probably it displays the results in the log buffer.

Also what I don't like with VIM is that when I enter command mode with : then I must use arrow keys to move back. In terminal and in spacemacs I can use Alt+b and Alt+f to move by word. Probably I can configure it.

With conjure you can keep the evaluation buffer open instead of a floating window if you want

ctrl(or shift) + left/right arrow moves cursor to next/previous word. something in my config maps Alt+b/Alt+f to do the same but not sure what:shrug:

But yeah, changing editor is very hard. Tried Spacemacs some time ago when I've joined a team where everyone was using it. But went back to Vim right after I left :rolling_on_the_floor_laughing:

If your fingers are on your home row the last thing you want to do is to reach for that arrow key (why use vim at all then...). So Ctrl is at least not that far away and it's a good compromise because otherwise we would need to have insertion mode for that command mode. And if you open bash you can use Ctrl+f + Ctrl+b (type in some words and press these keys). So I expected it to be consistent. Shell prompts are emacs-like (sometimes) and I still think that one has to use both models at the same time to be productive. Why did you want to try spacemacs after vim though? What's the reasoning? For me to try vim was to have all buffers to use normal-mode and nothing else.

You can always map the keys yourself. I think that would be

cnoremap <M-b> <S-left>
cnoremap <M-f> <S-right>

The reasoning was that especially at the time Emacs was considered the best editor for Clojure. And I like the idea of molding the editor to your needs which is supposed to be much easier in Emacs. Having all the other team members using it felt like a perfect opportunity to test it out Never got to that level of proficiency though ... And what jarred me is that for some reason Spacemacs was really slow on the 2015 Mac I had to work on at the time. I think it was 2019 There was a noticable delay from keypress to reaction

I wanted to move to VIM because I couldn't mold something without total hacking of it. It was how the CIDER modes are implemented. So I couldn't simply "enable VIM-like keys" there. Spacemacs is still slow on my Ryzen 5900HX... and by slowness I mean that when you evaluate a large form it can lag for a second because it tries to render it for you. So the renderer lags somewhat. And REPL also lags when there's a lot of output. So I also wanted to avoid this inability to "simply use vim keys everywhere" via moving to VIM. So... several years ago I moved from regular VIM to Spacemacs because I couldn't find a decent overall development experience. With Spacemacs I've worked on Golang codebase and Typescript one. And it worked. Also some plugins are inferior too. For instance some LSP servers for TypeScript force some weird defaults and don't allow much in return. So probably it's missing config of the editor.

With moldability I'm getting spoiled with Glamorous Toolkit 😅 And these days if someone asks me for advice about text editor I tell them to use VS Code unless they do want to spend their life on working on their editor configuration

Also some plugins are inferior too - in neovim?

Spacemacs is still slow - I was hoping the recent change in how Emacs is compiled would have speed up things

My theory is that the two are to some degree moving towards each other - Emacs becoming faster, Neovim more programmable due to move to Lua, having actual packages, and even being able to use a Lisp - Fennel

I don't know. Spacemacs IS faster to start than before -- that one I have felt. But it's not faster when it tries to render too much stuff which I don't need. And it's not fast when I have a large Clojure buffer (2K LOC let's say). It's also not fast when I try to evaluate some EDN and it tries to render it for some reason even though I only wanted to blindly evaluate it. It's not unusably slow but I think that quite often it simply lags or even freezes where it shouldn't. Also sometimes it randomly freezes the whole editor without any ability to recover. Regarding my comment on LSP -- they need to be configured from the editor's side. And if nobody configures them then it doesn't work correctly. For instance I think I had issues about .editorconfig not being taken into account for Java/Clojure or something like that. Also I can't simply jump into Java's JAR from Clojure source code. I don't know Emacs Lisp too well and I'm not at the level to write this kind of code.

I got this strange frustration about Clojure on nvim (via conjure). I've configured LSP, language servers, highlighting... and now I still can't switch to nvim. It's faster, sure. But I'm so used to simply press <localleader>tn to run namespace's tests and then look into the buffer to find red lines and then jump to that test from the test result buffer... How do I even find the failing test in the failing namespace? What do you do? There was some guy that tried to rerun the failing test by running the expression in a marked other buffer position. But to find that line you have to manually look into the test log buffer (and hope it doesn't have too much text) and find the failing test line in an unhighlighted test output. And then you have to remember the number, jump to that file via FZF or other tool, then jump to that line and by this point you probably already forgot what is the output of the test. So how do you do this? Maybe there is a better way...?

IMO, relying on a LSP client like neovim sounds the best

Yep, this worked fine:

$ clojure-lsp diagnostics --raw > diagnostics.txt
$ nvim -q diagnostics.txt

what does nvim -q file does?

Takes a file that's in errorformat and sets it up as the quickfix list's initial contents https://vim.fandom.com/wiki/Errorformats

If you setup neovim lsp, the clojure-lsp will contribute diagnostics. You can navigate diagnostics :h vim.diagnostic.goto_next() or fill quickfix list with them :h vim.diagnostic.setqflist()

well, that's a lot easier

(though discovering :cfile the other day was really nice for being able to take the report output from carve and amend it before just jumping through and deleting stuff via the quickfix)