how many secretly feel ashamed they use vim keybindings more then lisp movement keys? 😆

Yay, there's one Emacs person now! At least it wasn't a totally useless question then! 😉 The number of subscribers to this channel blew me away. 635! OK, so in one day about 1.5% of the number of subscribers have answered my poll. 🥲

I am very thankful I took the time to learn vim style editing. It did take a few weeks for it to become natural, but it has made interacting with Spacemacs so much faster. I often use Vim style key bindings instead of the smartparens commands, especially wrapping things in parens. Outside of editing a file, the Spacemacs mnemonic key bindings are the same for Evil and Emacs, only with different leader keys. This is the reason I adopted Spacemacs, as I found the Emacs chorded keys for packages (i.e. Cider) to be really confusing and hard to remember

I am using Vim style editing in every editor/ide. They all support it impeccably...

I love the lisp interaction mode SPC k. I use it all the time for wrapping, slurping, and barfing.

Doom’s evaluation function +eval:region (build to g r by default) is awesome because it accepts text objects / motions. No more navigating to the end of a form to evaluate it, and no need to remember arbitrary key bindings. You can just use the Vim motions you already know. • g r a f evaluate function definition around point • g r a b evaluate parenthesized expression around point • g r i o evaluate symbol at point • g r a g evaluate entire file You can even combine it with things like https://github.com/hlissner/evil-snipe: • g r g s j select a line below point and evaluate everything from point to there Not sure if something similar exists for Spacemacs, but if it does I highly recommend trying it! Wouldn’t be too hard to port to Spacemacs if it doesn’t already exist, I imagine.

Thanks zane, those options exist in the default space emacs setup with the clojure package.

Cider can evaluate many different parts of a nested or top level form, without the need to move the cursor to select the context. In Spacemacs they are all bound under , e for evaluation

I am unclear why anyone would ever need to navigate to the end of an expression just to evaluate it, unless they are using something other than Cider perhaps.

Yeah. Lots of people get started with just eval-last-sexp, particularly those coming from other Lisps.

I’ve found the ability to use an arbitrary text object / motion to be significantly more useful, powerful, and easy to remember than the fixed list of evaluation functions that Spacemacs provides. Your mileage may vary, of course!

@U0DJ4T5U1 There’s a Spacemacs equivalent to the evil-snipe example?

Yea

I believe so, eval up to ... Or something

I don't think to use it very often though

I see. You can snipe with motions other than j though. For example, g s s for evil-avy-goto-char-2 to eval from point up to an arbitrary two-character sequence.

You can also use numeric prefixes the same way you would with other Vim commands.

e.x. • 5 j move five lines down • 5 d j delete the next five lines • 5 g s j eval the next five lines

Thanks to those who answered. 17 answers, at the time of writing, is a very small sample, but maybe VIM-style editing is an overwhelming reason for people to choose Spacemacs and that it just seems a given choice to most. The thread took a bit of a turn, but not a problem 🙂 . Cheers.

I think you can stage some changes and then stash only the staged changes. Not sure though.

thats a good point, in this case i already had staged pieces i wanted to stage though.

That's a weird way of doing it, if it is supported that way. Normal git stash stashes all changes, not taking into account what has been staged or not. It's been a while since I used magit but I would be really surprised if magit did not support the equivalent of the corresponding git command (git stash --patch) since I remember it as being very full-featured!

I don't think Git supports exactly what your asking for. It's possible to stash just the index (all currently staged changes) without staging untracked files. It's not clear from the Git docs what should happen to unstaged files. There is a patch option in stash that allows interactive selection of hunks from the working tree, but also includes the current index (already staged changes). I typically just stash everything

Yeah it seems like you'd need a second index (a.k.a. staging area) to do what you're trying to do. I think what I'd do in your case is stash just the index to get it out of the way (making sure nothing you want to stash is staged), then stage what you want to stash, then stash the index again, then apply and drop the first stash (i.e. the second on the stack).

I had the same question a few days ago actually. Made large changes and decided to split the work into two smaller PR's. I wanted to stage some stuff but wanted to stash the others. One particular hunk had both changes i wanted to stage and stash. Luckily, I found out that in magit you could highlight the parts of the hunk you want to stage. So I ended up staging the stuff I wanted, made a WIP commit then stashed everything else. Then reset the HEAD by 1 commit. Maybe that helps 🤷

Honestly, I feel the added info complicates things unnecessarily: > Exactly what you are asking for I didn't feel it was as clear what he was asking for*... but agree that git might not support what others suggested in the answers. > *"when looking at unstated and stated changes in magit is it possible to Stash by hunk or file?" I read the simplest interpretation of the question, and therefore the answer, that -p(atch) does what was requested -> stash by hunk, looking at all changes whether staged or not, so does magit not do that the same as plain git? Does it answer what you want @U0DJ4T5U1, or can you clarify with an example? If it is anything like the scenario you mention @UB0S1GF47 I think the easiest thing is to stash what you want to stash using -p(atch). Then you can stage/commit what is left. I'd say, don't worry about what you have placed in the staging/index or not. If you happen to have stuff in the index when you start, it's still easy to stash -p anyway (which takes everything into account, and you can select hunks from there). You could of course reset index if that feels better, and start from there if that helps, but I'd guess it's not needed.

Granted, I'm speaking of git and not magit, but I have never seen it provide less functionality.

> found out that in magit you could highlight the parts of the hunk you want to stage Yes exactly. magit actually extending the user experience beyond what git does (sort of...) is what I remember making it amazingly good. In git command line you'd have to edit the patch for the hunk manually, then deal with whatever you edited out.

I haven't forgotten this, i just got massively distracted before i could come back to it. I'll try to catch up tomorrow, likely i can solve my (very minor) issue another way.