lainchan archive - /λ/ - 20996
[ Return /
Go to bottom ]
File: 1482342654009.png (89.59 KB, 300x300, 1447048898244-1.png)
There's a visible text editor thread - it's at reply limit, or this would be there. Still, So, here seems like a decent place to ask:
I detest out-the-box Emacs, for visceral alt-key-related reasons. I adore vi for probably pretty standard vi-user reasons. That pretty obviously means I use Vim for practically all my text editing (including typing out this post, as it happens). Recently though, I've started noticing Vim's shortcomings more and more - mostly the soykafty syntax highlighting and the all-around nightmare that is VimScript. Switching to Emacs+Evil seems a possible solution, but:
- Can I realistically remap or disable all the escape-meta-alt-shift sequences to save myself a rage stroke?
- It's pretty widely understood that Emacs users leave the editor open for hours at a time. I'm far happier with the vi style of opening the editor only long enough to make the changes I immediately have in mind, then exiting back the the shell. Is that something I'd have to relearn to make Emacs worthwhile?
I detest out-the-box Emacs, for visceral alt-key-related reasons. I adore vi for probably pretty standard vi-user reasons. That pretty obviously means I use Vim for practically all my text editing (including typing out this post, as it happens). Recently though, I've started noticing Vim's shortcomings more and more - mostly the soykafty syntax highlighting and the all-around nightmare that is VimScript. Switching to Emacs+Evil seems a possible solution, but:
- Can I realistically remap or disable all the escape-meta-alt-shift sequences to save myself a rage stroke?
- It's pretty widely understood that Emacs users leave the editor open for hours at a time. I'm far happier with the vi style of opening the editor only long enough to make the changes I immediately have in mind, then exiting back the the shell. Is that something I'd have to relearn to make Emacs worthwhile?
>Can I realistically remap or disable all the escape-meta-alt-shift sequences to save myself a rage stroke?
Yes. Every single one of them. You might also want to try spacemacs, which is designed to be Emacs for the vi inclined.
> It's pretty widely understood that Emacs users leave the editor open for hours at a time. I'm far happier with the vi style of opening the editor only long enough to make the changes I immediately have in mind, then exiting back the the shell. Is that something I'd have to relearn to make Emacs worthwhile?
This is how I am used to do things too. Yes, you're going to have to relearn this.
For starters, you'll probably want to use the graphical version of emacs, if you are using X of course. And the workflow in emacs is kind of the opposite to that in vi(m): you spend most of your time in the editor, you do most of your tasks in the editor, even if they're not editing tasks (think of Emacs as a sort of desktop environment, computing environment, development environment, /.*/ environment for that matter), and when you need the shell, you open a shell inside Emacs. It has 3 shell modes for you to choose depending on your needs. There is dired mode for traversing directories, you can use M-x man to view a man page, etc.
Yes. Every single one of them. You might also want to try spacemacs, which is designed to be Emacs for the vi inclined.
> It's pretty widely understood that Emacs users leave the editor open for hours at a time. I'm far happier with the vi style of opening the editor only long enough to make the changes I immediately have in mind, then exiting back the the shell. Is that something I'd have to relearn to make Emacs worthwhile?
This is how I am used to do things too. Yes, you're going to have to relearn this.
For starters, you'll probably want to use the graphical version of emacs, if you are using X of course. And the workflow in emacs is kind of the opposite to that in vi(m): you spend most of your time in the editor, you do most of your tasks in the editor, even if they're not editing tasks (think of Emacs as a sort of desktop environment, computing environment, development environment, /.*/ environment for that matter), and when you need the shell, you open a shell inside Emacs. It has 3 shell modes for you to choose depending on your needs. There is dired mode for traversing directories, you can use M-x man to view a man page, etc.
You need to learn Emacs' corded keystrokes, they are infinitely superior to modal editing. However, modern-day keyboards are garbage as Emacs was designed with the Space Cadet layout. So what you need to do is remap the bottom row to the following:
Super | Alt | Control | Spacebar | Control | Alt | Super
Capslock can be whatever you want. I have it set to alt.
If you're using a *nix, I can share my .xmodmap with you.
Super | Alt | Control | Spacebar | Control | Alt | Super
Capslock can be whatever you want. I have it set to alt.
If you're using a *nix, I can share my .xmodmap with you.
>>20996
The answers to your questions are yes (you can change literally *anything*: this is Emacs), and yes. But relearning that isn't too hard.
You can use spacemacs, which is a prebuilt solution for this scenario, but spacemacs is fearsomely complex, and learning to use and modify vanilla Emacs is a better idea, IMHO. https://www.emacswiki.org/emacs/Evil is your friend, as is the Evil documentation, general emacs/elisp guides, and other people's configurations for Evil.
The answers to your questions are yes (you can change literally *anything*: this is Emacs), and yes. But relearning that isn't too hard.
You can use spacemacs, which is a prebuilt solution for this scenario, but spacemacs is fearsomely complex, and learning to use and modify vanilla Emacs is a better idea, IMHO. https://www.emacswiki.org/emacs/Evil is your friend, as is the Evil documentation, general emacs/elisp guides, and other people's configurations for Evil.
>>21000
No. Bad.
If you're on an IBM-style keyboard, Alt and Super (or at least alt) should be comfortably within your reach. This will move those keys further out of your reach.
Just swap ctrl and capslk and you'll be fine.
But if you have a Knight, Space Cadet, Symbolics (and have learned to type properly on the layout that the commenter I disagree with describes), or Sun Type 6 style keyboard, desregard all of this you lucky bastard: You've already got a near-ideal setup.
Although it should be noted for us less lucky folks that Unicomp does sell a gorgeous sun-layout keyboard, if you've got the cash.
No. Bad.
If you're on an IBM-style keyboard, Alt and Super (or at least alt) should be comfortably within your reach. This will move those keys further out of your reach.
Just swap ctrl and capslk and you'll be fine.
But if you have a Knight, Space Cadet, Symbolics (and have learned to type properly on the layout that the commenter I disagree with describes), or Sun Type 6 style keyboard, desregard all of this you lucky bastard: You've already got a near-ideal setup.
Although it should be noted for us less lucky folks that Unicomp does sell a gorgeous sun-layout keyboard, if you've got the cash.
The metaprogramming aspects of Lisps and the ease of implementing interpreters in them is widely known. Maybe it's high time I put a vimscript interpreter into Spacemacs.
>>20997
>Really? I've never had a problem with it.
Well... Ok, sure. It's fine. It does everything it sets out to do. But having used IDEs that know, say, 'def spam():' means spam() is now a functionlike any other and should highlight the same way print() does for the rest of the file, anything else feels pretty horrible.
>>21000
>You need to learn Emacs' corded keystrokes, they are infinitely superior to modal editing
....nah. This is a thread about potentially swapping sides and we've come three or four posts without Holy Warring, let's not start now. (btw modal 4 lyfe)
>>20998
>>21001
I realise I can in theory rebind everything - Emacs as a Lisp interpreter that happens to boot into a text editor is a cool idea, and probably worth playing with for that alone. What I really wanted to know was how much work it would take.
>>20998
>For starters[...]
Not going to lie, all of that sounds... ugh. I already have tmux and Awesome and am happy with them - I don't really want to develop a whole new workflow, never mind breaking all the task segregation habits I've picked up along the way. Although Emacs does have server mode, maybe I can connect in-terminal client sessions to that, the way I now use Vim?
>Really? I've never had a problem with it.
Well... Ok, sure. It's fine. It does everything it sets out to do. But having used IDEs that know, say, 'def spam():' means spam() is now a functionlike any other and should highlight the same way print() does for the rest of the file, anything else feels pretty horrible.
>>21000
>You need to learn Emacs' corded keystrokes, they are infinitely superior to modal editing
....nah. This is a thread about potentially swapping sides and we've come three or four posts without Holy Warring, let's not start now. (btw modal 4 lyfe)
>>20998
>>21001
I realise I can in theory rebind everything - Emacs as a Lisp interpreter that happens to boot into a text editor is a cool idea, and probably worth playing with for that alone. What I really wanted to know was how much work it would take.
>>20998
>For starters[...]
Not going to lie, all of that sounds... ugh. I already have tmux and Awesome and am happy with them - I don't really want to develop a whole new workflow, never mind breaking all the task segregation habits I've picked up along the way. Although Emacs does have server mode, maybe I can connect in-terminal client sessions to that, the way I now use Vim?
>>21005
Yes, but using emacs in tmux... uck.
IMHO, use the emacs daemon like you would use a detatched tmux session. Just run the shell from within emacs, and it should work 90% of the time. If not, you can always run a raw shell as a last resort.
Emacs should not replace awesomewm, though. Some people say that emacs can do window management: this is a lie. It can't, not really, not that you'd use.
So in summary, I would suggest dumping tmux for emacs and leaving your DE otherwise unchanged.
Yes, but using emacs in tmux... uck.
IMHO, use the emacs daemon like you would use a detatched tmux session. Just run the shell from within emacs, and it should work 90% of the time. If not, you can always run a raw shell as a last resort.
Emacs should not replace awesomewm, though. Some people say that emacs can do window management: this is a lie. It can't, not really, not that you'd use.
So in summary, I would suggest dumping tmux for emacs and leaving your DE otherwise unchanged.
>>21005
I understand your feelings regarding workflow.
There is one little thing I can't stand if I ever use emacs inside tmux: two mode lines. One for tmux and one for emacs, taking up space, and they're horribly distracting.
But hey, you can pretty much do all that as well. In theory, it should be okay. I don't know if emacs-server saves startup time, I've never used it but my guess is that it does.
Install evil-mode, alias emacs="emacs --client" and you're pretty much set.
also
>modal 4 lyfe
can't agree more
I understand your feelings regarding workflow.
There is one little thing I can't stand if I ever use emacs inside tmux: two mode lines. One for tmux and one for emacs, taking up space, and they're horribly distracting.
But hey, you can pretty much do all that as well. In theory, it should be okay. I don't know if emacs-server saves startup time, I've never used it but my guess is that it does.
Install evil-mode, alias emacs="emacs --client" and you're pretty much set.
also
>modal 4 lyfe
can't agree more
>>21008
>alias emacs="emacs --client"
"emacsclient -c" ?
I have this bound to super-e in my WM's config:
"if (ps -A | grep emacs); then (emacsclient -c) else (emacs) fi"
It's a pretty silly way of doing it but works for me. Yes, I'm aware of the obvious problems with this, none have actually come up in the ~year I've used this. I have my "terminal" keybind as running emacsclient and entering immediately ansi-term, and a separate keybind for the rare instances that I need a more sophisticated terminal emulator.
>alias emacs="emacs --client"
"emacsclient -c" ?
I have this bound to super-e in my WM's config:
"if (ps -A | grep emacs); then (emacsclient -c) else (emacs) fi"
It's a pretty silly way of doing it but works for me. Yes, I'm aware of the obvious problems with this, none have actually come up in the ~year I've used this. I have my "terminal" keybind as running emacsclient and entering immediately ansi-term, and a separate keybind for the rare instances that I need a more sophisticated terminal emulator.
>>21008
>There is one little thing I can't stand if I ever use emacs inside tmux: two mode lines.
You'd, eh, probably hate my screen layouts, then...
>I don't know if emacs-server saves startup time, I've never used it but my guess is that it does.
I've just run a Totally Scientific Experiment*, and it does improve load time. Significantly, in fact.
[*: time (emacsclient -cnw .vimrc) followed by an instant C-x C-cL 0.226 total.
time (emacs -nw .vimrc) followed by an instant C-x C-c: 0.787 total.
Not the end of the world, but enough that the delay on the second is noticeable.]
>There is one little thing I can't stand if I ever use emacs inside tmux: two mode lines.
You'd, eh, probably hate my screen layouts, then...
>I don't know if emacs-server saves startup time, I've never used it but my guess is that it does.
I've just run a Totally Scientific Experiment*, and it does improve load time. Significantly, in fact.
[*: time (emacsclient -cnw .vimrc) followed by an instant C-x C-cL 0.226 total.
time (emacs -nw .vimrc) followed by an instant C-x C-c: 0.787 total.
Not the end of the world, but enough that the delay on the second is noticeable.]
I've recently made the switch to emacs, when I first did I too wanted to keep my vim style commands so I tried evil. However I ended up having to learn emacs commands anyways and felt like it was a bastardization of both worlds, so I decided to just start over and learn plain emacs from the ground up. I haven't regretted a thing since; I think emacs is great compared to vim and I don't have a problem with any of the key bindings. It was kind of refreshing to develop new habits. REPL-in-editor developement is also especially nice.
If you truly do have qualms with M-* commands or if you honestly find modal commands that much better than emacs chords, then you probably won't be able to relate to this. What my major point in this post was to say that I found it better to learn emacs by using emacs, not by creating a "compatibility layer" through evil/spacemacs.
If you truly do have qualms with M-* commands or if you honestly find modal commands that much better than emacs chords, then you probably won't be able to relate to this. What my major point in this post was to say that I found it better to learn emacs by using emacs, not by creating a "compatibility layer" through evil/spacemacs.
>>20996
A few points, from someone that went through the same thing. I was using vim for some data entry and conversion, and vimscript wasn't cutting it.
Evil mode: It works, and it works better now than it did when I started. I used to have all kinds of issues in the unusual buffers - dired, magit, package-list - and had to work around them. These days I don't.
It's not perfect, but the problems are minor.
Remapping: There's a package called evil-leader that gives you the leader key. Bind it to the comma (or whatever) and map your functions through there. Easy-peasy.
Leaving the editor open: You don't have to do this. If you have a giant config with 200 packages, then yeah, it makes sense to leave the editor open all the time. In my experience, though, you don't want to start out with a bunch of packages. Use just the packages you need, and learn the built-in stuff. When you find yourself needing something new that's not built in, only then go find a package for it.
All this said, you will occasionally need to use Emacs keybindings (for instance, if you hork your config). Just learn the basics. Ignore all the crap about avoiding "special" keys like PgUP and the arrow keys - those work fine for 99.9% of people.
In the end, I use vi keybindings for editing and a mix of leader keys and native emacs bindings for everything else. Works great.
A few points, from someone that went through the same thing. I was using vim for some data entry and conversion, and vimscript wasn't cutting it.
Evil mode: It works, and it works better now than it did when I started. I used to have all kinds of issues in the unusual buffers - dired, magit, package-list - and had to work around them. These days I don't.
It's not perfect, but the problems are minor.
Remapping: There's a package called evil-leader that gives you the leader key. Bind it to the comma (or whatever) and map your functions through there. Easy-peasy.
Leaving the editor open: You don't have to do this. If you have a giant config with 200 packages, then yeah, it makes sense to leave the editor open all the time. In my experience, though, you don't want to start out with a bunch of packages. Use just the packages you need, and learn the built-in stuff. When you find yourself needing something new that's not built in, only then go find a package for it.
All this said, you will occasionally need to use Emacs keybindings (for instance, if you hork your config). Just learn the basics. Ignore all the crap about avoiding "special" keys like PgUP and the arrow keys - those work fine for 99.9% of people.
In the end, I use vi keybindings for editing and a mix of leader keys and native emacs bindings for everything else. Works great.
Anyone approaching emacs as just another hotkey editor like vim is totally missing what emacs is, which is an editing system. emacs is always in one and only one major mode and can be in many minor modes. Most of these minor modes are from packages (how plugins are referred to in emacs). Each one of these major and minor modes sets how emacs will behave and so makes emacs an entirely different editor compared to other modes. Trying to memorize hotkeys in emacs is stupid because each mode has its own set of hotkeys. And you have to understand the underlying functionality of each mode, trying to learn a mode just by hotkeys alone is also extremely stupid. Maybe 10% of people who say they use emacs actually understands and really uses emacs they way its supposed to be used, everyone else is just trying to use it like vim.
>>21025
>everyone else is just trying to use it like vim.
That's because we want to edit something, and vim is a good editor.
I don't recall anyone asking for my dissertation on emacs internals when I ran `apt-get install emacs24`. There's a reason for that.
We could waste days diving down the rabbit hole and learning every little thing about Emacs, but we've got work to do. So we learn the hotkeys we need at the moment and pick up the more advanced features along the way.
I don't think anyone is qualified to tell us how to "use emacs the way its supposed to be used" except maybe RMS, and he doesn't care as long as we keep it free.
>everyone else is just trying to use it like vim.
That's because we want to edit something, and vim is a good editor.
I don't recall anyone asking for my dissertation on emacs internals when I ran `apt-get install emacs24`. There's a reason for that.
We could waste days diving down the rabbit hole and learning every little thing about Emacs, but we've got work to do. So we learn the hotkeys we need at the moment and pick up the more advanced features along the way.
I don't think anyone is qualified to tell us how to "use emacs the way its supposed to be used" except maybe RMS, and he doesn't care as long as we keep it free.
tfw you declare emacs bankruptcy, rework your config files for the perfect scheme setup, and then have to go through your init.el and replace all the (define)s with (defun)s.
>>21028
It's not about learning every little thing, it's about understanding the system, and how and why it is that way. That's important in Emacs, moreso than in Vi, because Emacs isn't so much an editor with an extension language as it is a programming environment that happens to have an editor in it.
It's not about learning every little thing, it's about understanding the system, and how and why it is that way. That's important in Emacs, moreso than in Vi, because Emacs isn't so much an editor with an extension language as it is a programming environment that happens to have an editor in it.
>>21035
Well, yes, that's certainly true.
But if you don't pick up on that within a relatively short time of working with emacs, then you're probably not in the target demographic for emacs.
OP is coming from vim and needs something that can replace vim. At this point, he's mostly concerned with keybindings and muscle memory. Those are dealbreakers; if emacs can't handle those, then he won't bother learning it.
Once he's used emacs a while and experimented a bit, he'll discover the benefits of a programmable environment.
So yes, while emacs is a programming environment that happens to have an editor in it, if he can't use that editor he won't bother with the programming environment.
Well, yes, that's certainly true.
But if you don't pick up on that within a relatively short time of working with emacs, then you're probably not in the target demographic for emacs.
OP is coming from vim and needs something that can replace vim. At this point, he's mostly concerned with keybindings and muscle memory. Those are dealbreakers; if emacs can't handle those, then he won't bother learning it.
Once he's used emacs a while and experimented a bit, he'll discover the benefits of a programmable environment.
So yes, while emacs is a programming environment that happens to have an editor in it, if he can't use that editor he won't bother with the programming environment.
>>21036
>So yes, while emacs is a programming environment that happens to have an editor in it, if he can't use that editor he won't bother with the programming environment.
not to keep beating the drum, but the editor hotkeys wont make sense until you understand the mode youre in
luckily someone uploaded "Mastering Emacs" in the book thread, this is the first book to truly teach emacs as a system
https://lainchan.org/%CE%BB/res/14991.html#17549
>So yes, while emacs is a programming environment that happens to have an editor in it, if he can't use that editor he won't bother with the programming environment.
not to keep beating the drum, but the editor hotkeys wont make sense until you understand the mode youre in
luckily someone uploaded "Mastering Emacs" in the book thread, this is the first book to truly teach emacs as a system
https://lainchan.org/%CE%BB/res/14991.html#17549
>>21039
I completely agree with you regarding learning Emacs' system and structure, however suggesting that someone ought to read a book to get started with a text editor is probably going to scare people off more than it entices them.
I believe that it should be introduced first and foremost as a text editor. The power and flexibility of the interactive lisp environment will become apparent though using the help system, introspection, and the realisation that every key press is simply mapped to a function that can also be called with M-x. I've yet to see someone make it to this stage and not convert to the church of emacs.
I completely agree with you regarding learning Emacs' system and structure, however suggesting that someone ought to read a book to get started with a text editor is probably going to scare people off more than it entices them.
I believe that it should be introduced first and foremost as a text editor. The power and flexibility of the interactive lisp environment will become apparent though using the help system, introspection, and the realisation that every key press is simply mapped to a function that can also be called with M-x. I've yet to see someone make it to this stage and not convert to the church of emacs.
>>21025
>>21028
>>21035
>>21036
>>21039
>>21072
OP here. I've been playing around with Emacs+evil for the past couple of days. It's really, really nice - but... Well, I have tmux to do tmux-y things, so while it's cool that this one Lisp window can do them too*, I don't really need it to. I have shell-in-tmux to launch/manage/pipe/whatever my processes, so I don't really need the Lisp box to do that, either. And there are niggles - I'm used to using <C-h> not backspace and sometimes <C-j> over RET, and don't really want to unlearn either; I'm used to the way Vim's :registers behaves in relation to externally copied/pasted/selected text, which happens to be different from the way in-term or in-X evil's behaves (which are each different from each other, interestingly). In neither case is Emacs wrong, and in both cases I could no doubt Lisp-hack it do precisely what I want, but I already have the one I have. Seems like a big investment - surely there's an easier way to escape VimScript?
* - but it can't handle separate sessions like tmux, can it? That's basically a dealbreaker for me, and if I was going to convert full-time I'd still have to be running Emacs from within tmux.
>>21017
>If you truly do have qualms with M-* commands
It's more use-habits than anything - I have Alt and Super swapped, along with Ctrl and Caps. Muscle memory tells me that <M-[x]> means I'm talking to awesome; <C-a>[x] means I'm talking to tmux; anything else means I'm talking to whatever is in the active tmux window; Super means I'm talking to some awful-but-for-some-reason-unavoidable gui program that makes me use its menus, doesn't let me rebind keys, and isn't work moving to the mouse for (in practice, this tends to mean Firefox is misbehaving again). I realise I could easily unlearn all of this in about a weekend, just as I could learn to use Emacs' native bingings, but... unix grognard. I won't challenge your irrational habits if you let me keep mine.
You know what I'd really like? A shell that takes Emacs' "programmable environment" approach, giving me all that undeniable power and feeling of wizardry, and runs in all my tmux windows when I <C-a>c. Always accessible from within processes it launched - Vim, say - when I hit perhaps <C-x>. That would be really something. (Possibly I'm describing a tmux replacement rather than a bash replacement, which would also be nice.)
Failing that, at least a second attempt at NeoVim that doesn't replicate Vim's biggest failing (ie, the use of VimScript rather than literally anything else) just to save us writing new vimrcs.
>>21028
>>21035
>>21036
>>21039
>>21072
OP here. I've been playing around with Emacs+evil for the past couple of days. It's really, really nice - but... Well, I have tmux to do tmux-y things, so while it's cool that this one Lisp window can do them too*, I don't really need it to. I have shell-in-tmux to launch/manage/pipe/whatever my processes, so I don't really need the Lisp box to do that, either. And there are niggles - I'm used to using <C-h> not backspace and sometimes <C-j> over RET, and don't really want to unlearn either; I'm used to the way Vim's :registers behaves in relation to externally copied/pasted/selected text, which happens to be different from the way in-term or in-X evil's behaves (which are each different from each other, interestingly). In neither case is Emacs wrong, and in both cases I could no doubt Lisp-hack it do precisely what I want, but I already have the one I have. Seems like a big investment - surely there's an easier way to escape VimScript?
* - but it can't handle separate sessions like tmux, can it? That's basically a dealbreaker for me, and if I was going to convert full-time I'd still have to be running Emacs from within tmux.
>>21017
>If you truly do have qualms with M-* commands
It's more use-habits than anything - I have Alt and Super swapped, along with Ctrl and Caps. Muscle memory tells me that <M-[x]> means I'm talking to awesome; <C-a>[x] means I'm talking to tmux; anything else means I'm talking to whatever is in the active tmux window; Super means I'm talking to some awful-but-for-some-reason-unavoidable gui program that makes me use its menus, doesn't let me rebind keys, and isn't work moving to the mouse for (in practice, this tends to mean Firefox is misbehaving again). I realise I could easily unlearn all of this in about a weekend, just as I could learn to use Emacs' native bingings, but... unix grognard. I won't challenge your irrational habits if you let me keep mine.
You know what I'd really like? A shell that takes Emacs' "programmable environment" approach, giving me all that undeniable power and feeling of wizardry, and runs in all my tmux windows when I <C-a>c. Always accessible from within processes it launched - Vim, say - when I hit perhaps <C-x>. That would be really something. (Possibly I'm describing a tmux replacement rather than a bash replacement, which would also be nice.)
Failing that, at least a second attempt at NeoVim that doesn't replicate Vim's biggest failing (ie, the use of VimScript rather than literally anything else) just to save us writing new vimrcs.
>>21077
Yeah, evil's great, but it's not perfect. Emacs and vim are just too different under the hood - you're always going to be able to tell the difference.
That said, if you still want to play with Emacs:
>I have tmux to do tmux-y things, so while it's cool that this one Lisp window can do them too, I don't really need it to.
The big advantage to using Emacs' window system is when you're editing related files. You can dd in one buffer and y in other - no using the mouse. Also, things like dynamic abbrevs will search all open buffers to complete text. If you're editing unrelated files, there's less of an advantage.
>And there are niggles - I'm used to using <C-h> not backspace and sometimes <C-j> over RET
C-j should already do return.
For C-h, you can try this in your init.el, assuming you installed evil-leader:
That's not quite perfect; the backspace key maps to strange things sometimes (it scrolls the buffer for the into screen, for instance) and C-h won't pick up on that, but it should do what you want. Use your leader with h to get to the help system.
>I'm used to the way Vim's :registers behaves in relation to externally copied/pasted/selected text, which happens to be different from the way in-term or in-X evil's behaves
I didn't use registers heavily, so I can't help you here. Check into the kill ring. Also, for the gui, this helps with paste:
Bear in mind that the meaning of "yank" is completely opposite between Emacs and vim; in Emacs, it means paste.
>but it can't handle separate sessions like tmux, can it?
Depends what you mean. You can run multiple Emacs instances at once. You don't use C-a with evil (well, I do, but at this point I'm a hybrid keymap user). If you're trying to replace tmux with Emacs, that's doable too, but it'll take some work and maybe some external scripts (multi-shell.el maybe?). Also, check out TRAMP mode.
(I'm not trying to convert you, BTW - use whatever you like. But this might help if you decide to make the jump.)
Yeah, evil's great, but it's not perfect. Emacs and vim are just too different under the hood - you're always going to be able to tell the difference.
That said, if you still want to play with Emacs:
>I have tmux to do tmux-y things, so while it's cool that this one Lisp window can do them too, I don't really need it to.
The big advantage to using Emacs' window system is when you're editing related files. You can dd in one buffer and y in other - no using the mouse. Also, things like dynamic abbrevs will search all open buffers to complete text. If you're editing unrelated files, there's less of an advantage.
>And there are niggles - I'm used to using <C-h> not backspace and sometimes <C-j> over RET
C-j should already do return.
For C-h, you can try this in your init.el, assuming you installed evil-leader:
(global-set-key (kbd "C-h") 'delete-backward-char)
(define-key evil-normal-state-map (kbd "C-h") 'evil-backward-char)
(define-key evil-motion-state-map (kbd "C-h") 'evil-backward-char)
(evil-leader/set-key "hb" 'describe-bindings)
(evil-leader/set-key "hc" 'describe-key-briefly)
(evil-leader/set-key "hd" 'apropos-documentation)
(evil-leader/set-key "he" 'view-echo-area-messages)
(evil-leader/set-key "hf" 'describe-function)
(evil-leader/set-key "hF" 'Info-goto-emacs-command-node)
(evil-leader/set-key "hi" 'info)
(evil-leader/set-key "hI" 'describe-input-method)
(evil-leader/set-key "hk" 'describe-key)
(evil-leader/set-key "hK" 'Info-goto-emacs-key-command-node)
(evil-leader/set-key "hl" 'view-lossage)
(evil-leader/set-key "hm" 'describe-mode)
(evil-leader/set-key "hs" 'info-lookup-symbol)
(evil-leader/set-key "hv" 'describe-variable)
(evil-leader/set-key "hw" 'where-is)That's not quite perfect; the backspace key maps to strange things sometimes (it scrolls the buffer for the into screen, for instance) and C-h won't pick up on that, but it should do what you want. Use your leader with h to get to the help system.
>I'm used to the way Vim's :registers behaves in relation to externally copied/pasted/selected text, which happens to be different from the way in-term or in-X evil's behaves
I didn't use registers heavily, so I can't help you here. Check into the kill ring. Also, for the gui, this helps with paste:
(setq x-select-enable-clipboard t
select-active-regions t
x-select-enable-primary t
mouse-yank-at-point t)Bear in mind that the meaning of "yank" is completely opposite between Emacs and vim; in Emacs, it means paste.
>but it can't handle separate sessions like tmux, can it?
Depends what you mean. You can run multiple Emacs instances at once. You don't use C-a with evil (well, I do, but at this point I'm a hybrid keymap user). If you're trying to replace tmux with Emacs, that's doable too, but it'll take some work and maybe some external scripts (multi-shell.el maybe?). Also, check out TRAMP mode.
(I'm not trying to convert you, BTW - use whatever you like. But this might help if you decide to make the jump.)
>>21081
>(I'm not trying to convert you, BTW - use whatever you like. But this might help if you decide to make the jump.)
I didn't take it that way - your post is awesome, and helpful. It actually has put me closer to switching sides, or at least spending more time playing with Emacs. More people should discuss differences in software preference the way you have. Even if we never find tools we both want to use, knowing precisely what another person wants from or appreciates in their own environment is interesting.
>C-j should already do return.
Sort of - it gives a newline, not Enter. So :reg<C-j> in Vim would run the :registers command, but in Emacs it has to be :reg<C-m> - <C-j> in the command line inserts a newline into the command but doesn't 'feed' it to the interpreter. A cool thing to be able to do, but unexpected behaviour for me (this is a pretty trivial complaint, but still).
Both the codeblocks are helpful though, so thanks.
>Depends what you mean.
I often (usually?) have multiple tmux sessions running, with one or more disconnected. This is particularly useful for remote work. I managed fine for years before I started using tmux, so it's not reasonable to say I can't live without it, but I'm not willing to go back.
>>21084
>>21086
That's definitely something I'll look at, thanks!
>(I'm not trying to convert you, BTW - use whatever you like. But this might help if you decide to make the jump.)
I didn't take it that way - your post is awesome, and helpful. It actually has put me closer to switching sides, or at least spending more time playing with Emacs. More people should discuss differences in software preference the way you have. Even if we never find tools we both want to use, knowing precisely what another person wants from or appreciates in their own environment is interesting.
>C-j should already do return.
Sort of - it gives a newline, not Enter. So :reg<C-j> in Vim would run the :registers command, but in Emacs it has to be :reg<C-m> - <C-j> in the command line inserts a newline into the command but doesn't 'feed' it to the interpreter. A cool thing to be able to do, but unexpected behaviour for me (this is a pretty trivial complaint, but still).
Both the codeblocks are helpful though, so thanks.
>Depends what you mean.
I often (usually?) have multiple tmux sessions running, with one or more disconnected. This is particularly useful for remote work. I managed fine for years before I started using tmux, so it's not reasonable to say I can't live without it, but I'm not willing to go back.
>>21084
>>21086
That's definitely something I'll look at, thanks!
>it gives a newline, not Enter.
I never noticed that before. Had to dig a bit in evil-ex.el, but this works for me:
Sometimes finding the right keymap is a pain. The price of flexibility, I suppose.
>I often (usually?) have multiple tmux sessions running, with one or more disconnected.
That should work fine - is it causing problems? Again, I don't use tmux myself, but Emacs usually doesn't care if you have multiple instances running (some exotic modes like gnus might care, I dunno).
The "run only one instance of Emacs" thing is just a workflow. There's advantages to it - especially for programming - but you don't have to use it, and for your particular use case it sounds like tmux is a better solution. TRAMP lets you do remote editing (it's built in to Emacs, not an add-on), but it does it in a completely different way than tmux - there are no processes on the remote machine other than sshd or whatever.
I'm probably not the best person to talk to for this, though, since I generally use Emacs in GUI mode and use vim at the terminal for quick editing and sysadmin type stuff. It sounds like you're a much more advanced vim user than I ever was :) You might try asking over on freenode if tmux is giving you issues with Emacs.
I never noticed that before. Had to dig a bit in evil-ex.el, but this works for me:
(define-key evil-ex-completion-map (kbd "C-j") #'exit-minibuffer)Sometimes finding the right keymap is a pain. The price of flexibility, I suppose.
>I often (usually?) have multiple tmux sessions running, with one or more disconnected.
That should work fine - is it causing problems? Again, I don't use tmux myself, but Emacs usually doesn't care if you have multiple instances running (some exotic modes like gnus might care, I dunno).
The "run only one instance of Emacs" thing is just a workflow. There's advantages to it - especially for programming - but you don't have to use it, and for your particular use case it sounds like tmux is a better solution. TRAMP lets you do remote editing (it's built in to Emacs, not an add-on), but it does it in a completely different way than tmux - there are no processes on the remote machine other than sshd or whatever.
I'm probably not the best person to talk to for this, though, since I generally use Emacs in GUI mode and use vim at the terminal for quick editing and sysadmin type stuff. It sounds like you're a much more advanced vim user than I ever was :) You might try asking over on freenode if tmux is giving you issues with Emacs.
>>21098
Oh, another thing that drove me up the wall when I switched to Emacs:
Line wrapping is like kicking dead whales down the beach by default. You don't notice much with config files or stuff that's less than 80 characters, but if you're writing documents it helps to turn on global-visual-line-mode.
But evil acts... weird if you do that. It's hard to work with long lines.
I use this to make evil behave more sensibly:
Try it with and without and see what you like better.
Oh, another thing that drove me up the wall when I switched to Emacs:
Line wrapping is like kicking dead whales down the beach by default. You don't notice much with config files or stuff that's less than 80 characters, but if you're writing documents it helps to turn on global-visual-line-mode.
(global-visual-line-mode t)But evil acts... weird if you do that. It's hard to work with long lines.
I use this to make evil behave more sensibly:
(define-key evil-normal-state-map (kbd "<remap> <evil-next-line>") 'evil-next-visual-line)
(define-key evil-normal-state-map (kbd "<remap> <evil-previous-line>") 'evil-previous-visual-line)
(define-key evil-motion-state-map (kbd "<remap> <evil-next-line>") 'evil-next-visual-line)
(define-key evil-motion-state-map (kbd "<remap> <evil-previous-line") 'evil-previous-visual-line)Try it with and without and see what you like better.
>>21100
I do the second thing but not the global-visual-line. It actually isn't Emacs' behavior that makes it hard to work with long lines, it's Vi's, which acts the same as Emacs. In fact, Emacs' bindings (C-n, C-p etc) work the way you want. In Vim, you use the "visual line" things with g<movement key>, like gj, gk, etc.
I use M-x visual-line-mode when it's relevant and I'm working with English, but with programming and other things I prefer Emacs' default wrapping.
With English I actually prefer keeping it indented to below 80 characters, something that's easy with Vim's gq<movement key> binding. Try gqh to indent the line you're on, gq} to indent down a paragraph, etc. You can reindent lines that become messed up with editing easily this way! And joining to back together is easy with J.
I do the second thing but not the global-visual-line. It actually isn't Emacs' behavior that makes it hard to work with long lines, it's Vi's, which acts the same as Emacs. In fact, Emacs' bindings (C-n, C-p etc) work the way you want. In Vim, you use the "visual line" things with g<movement key>, like gj, gk, etc.
I use M-x visual-line-mode when it's relevant and I'm working with English, but with programming and other things I prefer Emacs' default wrapping.
With English I actually prefer keeping it indented to below 80 characters, something that's easy with Vim's gq<movement key> binding. Try gqh to indent the line you're on, gq} to indent down a paragraph, etc. You can reindent lines that become messed up with editing easily this way! And joining to back together is easy with J.
>>21104
That explains it. I was wondering why visual-line-mode was so awkward with evil, but then again I didn't use vim for writing long non-80-character-limited documents. Nowadays I do all my document creation in org-mode, and evil was driving me crazy.
I just tried those commands in vim. They're pretty useful - I will have to remember them for when I need to edit a long-lined document and don't have Emacs. Thanks for the heads up.
There's a way to set up Emacs to hard-wrap at 80 columns (autofill), but I don't use it myself. I prefer to do it manually while I'm typing and then use fill-region-as-paragraph if I need to add stuff in the middle of the paragraph.
That explains it. I was wondering why visual-line-mode was so awkward with evil, but then again I didn't use vim for writing long non-80-character-limited documents. Nowadays I do all my document creation in org-mode, and evil was driving me crazy.
I just tried those commands in vim. They're pretty useful - I will have to remember them for when I need to edit a long-lined document and don't have Emacs. Thanks for the heads up.
There's a way to set up Emacs to hard-wrap at 80 columns (autofill), but I don't use it myself. I prefer to do it manually while I'm typing and then use fill-region-as-paragraph if I need to add stuff in the middle of the paragraph.
The irony...
(What evolved into) The Emacs thread has a Vim logo on the OP
(What evolved into) The Emacs thread has a Vim logo on the OP