Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In the opposing vein, as an Emacs user the best configuration I ever made was to rebind C-x C-c to execute-extended-command instead of kill-emacs. It was way too easy to (even accidentally!) kill emacs with a sweep of a finger. And I probably use a few hundred execute-extended-command calls for each kill-emacs (which I now have to type manually as 'C-x C-c kill-emacs' - no problemo).

A similar optimisation was with tmux to bind the prefix to C-z. It's in a handy location next to ctrl and I very rarely use suspend anyway (which is still available as easily as C-z z). Stretching your fingers between ctrl and b (the default prefix key) merely made me wonder who the heck thought of something like this?

As for vi, I made a point of learning to use it enough to do useful work editing config files and small texts. Every once in a while another application brought up 'vi' for some reason (maybe I lost VISUAL or EDITOR while sudoing or the app was looking for another variable) and I could never exit the damn thing.

So instead of just learning :q and figuring out how to make the particular program or script relaunch another editor I thought it's the path of least resistance to just edit with vi directly. It has been an incredibly handy skill: I never use vi for anything larger but these days I actually do 'vi /etc/fstab' myself instead of calling for emacsclient.

However, I've been toying around with the idea of eventually writing a minimal 'vi' clone that you cannot exit. I'm sure there's pent-up demand just waiting for one!



I think emacs is the winner here. It's true beauty is that most users have remapped everything so all you can do is bruteforce your way to the exit.

And where do you get exiting an OS? We don't know... maybe another OS...


Usually people don’t remap the menus much so I think if you clicked around the modeline enough you could pull up some help and eventually figure out the binding for kill-emacs or execute-extended-command.


  | However, I've been toying around with the idea
  | of eventually writing a minimal 'vi' clone that
  | you cannot exit. I'm sure there's pent-up demand
  | just waiting for one!
If a user space program can be truly unexitable without restarting (including the possibility of killing it through another shell, of course), then would you consider it to be a bug in the operating system? Seems a reasonable conclusion to me.


I once played a maze game on X where the maze would literally not allow the mouse cursor to go through the walls so it would be taken hostage. The only way to continue your X session was to solve the maze. That was quite funny. Oh, well, there could have been some other keys that would have done something about it but it was fun anyway.


It would indeed be a bug, which is why any self-respecting operating system should include uninterruptible vi in the kernel /s


Alt+SysRq+k

(read linux/Documentation/admin-guide/sysrq.rst before you try this)


Emacs is so dynamic and easily configurable, that people can actually rebind a lot of things when their colleague go to the bathroom as a prank.

Just open a scratch file, enter some s-expressions, evaluate them, then kill the buffer.


The last time I went to the bathroom as a prank HR had to have another talk with me.


Never go to the bathroom as a prank.


Would serve the victim right.

Never leave your unattended keyboard and screen unlocked.


At some place I worked there was a policy that a small prank was allowed if the workstation was not locked when someone left. I'd almost recommend that policy for some places.

Acceptable pranks would be things like:

- innocent videos (annoying videos for toddlers etc)

- change Spotify playlist from rock to childrens songs or rickroll or something

- open MS Paint and draw something (those pranks weren't necessarily small, we got three huge monitors side by side on those workstations)

- etc

Unacceptable pranks:

- anything that wasn't possible to revert in a hurry

- anything a customer couldn't see (we were on display :-/ )

At another place I know someone sent a mail to the team from someone elses account that they would bring cake the next day.

I once burned myself by doing what I thought was the obvious thing: leaving a message in a text editor and locking the machine. Turns out for some reason he couldn't unlock it after it had been locked that way and he needed to leave the campus to have IT at the main site unlock it. (When he locked it he always did it by closing the lid instead of through the system menu.)


That's why my scratch buffer is by default NOT in elisp mode


You can evaluate an elisp expression anywhere in any mode.


As an aside you can also make a (non-elisp) scratch buffer on the fly: when you switch buffer just enter a name that isn’t taken (I usually use b, bb, bbb, ...)


> A similar optimisation was with tmux to bind the prefix to C-z. It's in a handy location next to ctrl and I very rarely use suspend anyway.

I think gnu screen has the right idea here: ctrl-a.

And you say z is close to control - does that mean you use emacs without shift lock as control?! (I mean sure, still closer than b...).


C-a is the worst default keybinding ever, since like, going to the beginning of a line is one of the most common operations.


Well, not with proper key bindings ;) (set -o vi)


In the rest of the universe, going to the beginning/end of the line is mapped to the Home/End keys (fn+left/fn+right on Macs), and I do prefer it when my thing does things in ways that roughly correspond to how the rest of the universe does them if there's no compelling reason to do otherwise.


> (fn+left/fn+right on Macs)

When I used Mac in 2009 to 2012 it depended on the application you were using:

Some used fn+left/fn+right, some used CMD+left/CMD+right and I think ctrl and/or alt + arrow keys were an option too.

ctrl a/ctrl e would work everywhere I think but I didn't use those as they didn't work with shift to select to the start or end of the line.

As a keyboard type of person this was a major part of what drove me away from Mac despite its many advantages :-(


Caps lock isn't shift lock though.

I know, because I have triple-shift-press mapped to shift lock on my Ergodox. It's... usually better, but sometimes I type a @#$%@#$% swear word when I mean to enter a number.


I have remapped capslock to be an additional ctrl so I hit C-z easily with my pinky + ring fingers.

C-a (like in screen) would be even better but as others have pointed out it masks going to the beginning of line which is very common.

C-z is very rarely needed. C-q/C-s would be good candidates also as I don't think I've ever needed flow control in this century nor the last one, for that matter.


> And you say z is close to control - does that mean you use emacs without shift lock as control?! (I mean sure, still closer than b...).

Presuming Shift Lock means Caps Lock, that and Control are both close to Z on my (Apple) keyboard.


I use ctrl-a quite a lot on the command line, though.


'screen' uses C-a as a prefix shortcut so developers of 'tmux' decided to use the next available key to avoid clash.


I don't understand the logic there. In what non-contrived scenario would you run both simultaneously, such that they would conflict?

C-a does annoyingly conflict with readline's "move to start of line", though.


My understanding of the history is that the developers of tmux were using screen to develop tmux, because tmux didn't exist yet, so they needed a non-conflicting keystroke.

Obviously they could have switched before a general release, but I guess they had gotten used to it.


1. Outer tmux on local/primary machine, for your usual daily use-case (i.e. managing multiple terminal sessions).

2. In outer tmux, ssh to some other machine you need to administrate.

3. screen because you need multiple terminal sessions on that machine, or need detachability/reconnectability for some long-running process.


Also, many older production machines don't have tmux, so nesting a screen session happens. This is starting to not be a thing, but it was a thing for the trailing 10 years.


At work, my desktop has tmux, but the servers we deploy on only have screen.


Hitting C-a twice sends it to the terminal.


Close... "C-a a" sends a real "C-a", while "C-a C-a" swaps with your most recent window (it's fast and convenient to type).


How do you exit, then, if you never learned :q?


He never did, some say he's still in vi to this day.


The story of every 2 out of 3 vim users


4 out of 3* FTFY

Or perhaps it's 5, or 6.


Switch to a different terminal, log in, find the process, kill it.


ctrl-z to background it. Then `kill` it.


That was how I'd exit vi for a long time. Often "killall vi" because any other vi instances running would in any case be by accident.

I once caused a near rebellion of vi users when I was running an ISP and symlinked vi to emacs on our shell server because I was sick and tired of it...


Had the same issue with C-x C-c; I remapped mine to C-x C-c C-t because it worked for me as a mnemonic (assuming a "soft c"): "ex-s-t" => "eckst" => "exit"). Major productivity boost!


Nice.

I did something similar w/ tmux: map the prefix key to C-a and map CapsLock key to Ctrl (never found real use for it). So Ctrl-a (actually CapsLock-a) is very ergonomically pleasant.


What about moving to the beginning of a line?


I did the same thing but I also mapped Ctrl-\ to send the "prefix" (helpful for neated tmux sessions), so I just hit Ctrl-\ for beginning of line.

(Although this seems to have broken in recent tmux releases on Debian (3.x?) and I haven't looked into yet.)


Ctrl-a + Ctrl-a, works like a charm :)


command wq <nop> command w <nop> command q <nop>


Unfortunately:

  E183: User defined commands must start with an uppercase letter


command W <nop>

cabbrev w <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'w')<CR>

cabbrev q <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'q')<CR>

cabbrev q! <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'q!')<CR>

cabbrev wq <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'wq')<CR>




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: