Fair enough, though that notice can easily be disabled.

For what it's worth, I happened across bbatsov/prelude in 2011, not long after it started being developed, having no prior emacs experience. The notice you mentioned was one of several that nudged me to learn and use the various key combinations, so I'm grateful for the notices, but I understand that not everyone would be.

Lack of support for my perfectly useful arrow keys is one of the key reasons I didn't pick up vi back in 1990/1991 (when I first started Unixing) and did Emacs instead.

So I tried again and disabled guru mode (had to hunt for how and had to read the author's opinionated nonsense about the "one true way to use Emacs is by using it the way it was intended to be used " (phbtbt... nonsense... have you looked at the Space Cadet keyboard?).

So far I like the bundling of lsp and so on, it worked nicely out of the box to bring in my Rust projects ... it's nice to have it all set up.

But there's more... opinionated stuff in here that's frustrating. C-x u for undo is wonky, and C-g does not appear to be working to abort/get out of prompts. My fingers were tripping all over the place.

I feel like by the time I'd unpeeled enough of this guy's opinions and undone all the non-standard stuff in here, I'd be best to just start over.

Maybe there's been a recent change, but I use C-g all the time every day to get out of prompts, etc.

For me, C-x u opens a buffer for undo-tree, not sure if that's what you meant or not.

It's possible I customized for C-g and or C-x u; I haven't changed much in .emacs.d/personal recently, except for adding a few scripts.

In any case, glad you gave it another shot, but perhaps it isn't your cup of tea. It's great that Emacs is (and has long been) able to adapted to a variety of needs and preferences.

Yeah I don't want an undo-tree bound like that, because when I'm hitting undo, I just want a quick response. Default emacs behaviour is what I want.

And C-g, yeah, I don't know what it was doing. It got really weird.

In general this thing seems to want to open buffers all over the place. It's... visually confusing and I kept losing cursor focus in the task I was trying to focus on.

It's very much worth taking it as true.

I was in the same position as you initially and it took a week or two to get the muscle memory but it's so smooth to navigate using keys near the home row compared to arrow keys.

Plus those keys work in bash shells (anything that uses readline) and a lot of other places too.

Amazingly... arrow keys also work in bash/zsh etc. shells, back to the late 80s. :-)

Actually back then I used tcsh first because it was the one that commonly had niceties like.. arrow keys.

In shell, I use the emacs bindings for kill-buffer, incremental search, and end of line jump, etc. but arrow keys for cursor movement. I suspect most people who aren't using vi bindings are much the same.

To me the ctrl-n/ctrl-p thing is a piece of ideology, not practicality; as sibling comment pointed out, they are not really ergonomic, and really just date to the fact that various terminals did not have consistent arrow navigations at various point.

Actually I did get used to ctrl-p/ctrl-n in the context of an old MUD client I used to use (TinyFugue, actually I still use it sometimes). It used those bindings for history cycling. And the MOO client I used in emacs also used ESC-p for similar purposes, I recall.

I find them incredibly ergonomic, at least compared to the arrow keys, but that's just me. My newest keyboard doesn't even have arrows keys due to how little I would use them.

In all the web browsers I've tried on Windows, Mac and Linux, up and down arrow scroll a little (roughly a twelfth of a page) and people spend more time in browsers than in any editor.

So I end up using Ctrl-n and Ctrl-p to move down and up a line in my editor so that I can customize my editor to make the up and down arrow keys behave like they do in browsers.

Like you, I am annoyed by comments that gush about how great it is to use Emacs keybinds in programs other than Emacs because in for example VSCode, the editor used by about 70% of the world's programmers, none of the Emacs shortcuts work: e.g., ctrl-n / ctrl-p don't move to the next / previous line. And I'm a heavy Emacs user.

It interferes with my thinking mode - right hand on the mouse and probably scrolling in docs on the other screen, left hand stroking my beard.

More seriously, I'm just the same with hjkl and vim - cool if it works for you, when I am scrolling through I don't need to be efficient (which is highly subjective anyway), I need to have it how I like it.

the keys prelude pushes you towards with guru-mode are not the ones on the home row (hjkl, which is justifiable) but keys originally chosen for english words: n(ext), p(revious), f(orward), b(ack). It's mystifying, these aren't ergonomic at all, but just memnomics to help teach navigation _in the absence of clearly marked arrow keys_. So if anything, rather than being for gurus, these are keys for beginners.

I feel you. I am using both cua mode and arrow keys proudly even after a decade of using emacs. Sometimes convenience is more important than keyboard efficiency. I learned to avoid (or even turn off) cua-mode where necessary (e.g. when recording key board macros).

I used to have my own (rather extensive) config, and switched to prelude a bit more than a year ago. I think the whole key to prelude is that it promotes useful packages, with an eye on beginners. I did change a whole bunch of things, but there's less I need to get rid of in prelude (like disabling guru-mode, what you mention - too patronising for me) than I'd have to add to vanilla Emacs, so I stuck with it. I can recommend investing some time and giving it a chance - I think most people won't be entirely happy if they just go for the out of the box behaviour.

My additions/removals are just a few lines now and I find the whole setup a lot more maintainable than rolling my own: https://github.com/fhd/prelude/tree/personal/personal

But yeah, all I can say is that it works for me (with a little investment), YMMV.

The thing is about emacs, it makes you self-sufficient. You can always change any behaviour you want to, including this.

I've never used prelude before. I just ran it for the very first time and this is what I did to discover what to change:

C-h k <down>

Help buffer comes up for that key. It looks like it's bound to a lambda, which is actually a bit annoying as you can't jump to the definition or anything, but it's enough to see that it's in `guru-mode-map'.

Then I grepped the project for "guru" (I used C-c p s g because I figured out it was using Projectile and familiar with its default key bindings, but you could use M-x grep, M-x rgrep or just grep in whatever way you are familiar with).

I found this in the docs: https://prelude.emacsredux.com/en/latest/troubleshooting/#wa... (Note, I found and read this in emacs, in docs/troubleshooting.md, I'm just giving the web link here for convenience).

Basically just add `(setq prelude-guru nil)` to your init file.

Btw, for anyone wondering, to run these kind of starter kits "standalone", clone the repo and from within the repo run `emacs -Q --load init.el --init-directory=$(pwd)`. Otherwise it will try to use your actual init dir by default.