Vim prank: alias vim='vim -y' | Hacker News Reader

Vim prank: alias vim='vim -y'

learnbyexample.github.io

341 pointsasicsp259 comments

I actually use Vim like this, in fact I wrote a plugin to go all the way and make it a completely "normal" editor [1].

It's endlessly surprising to me that still to this day Vim is most commonly considered through the lens of its keybindings. It's sooo much more than that! It's a lightweight terminal editor with one of the largest, if not the largest ecosystems of pioneering extensions. It really shouldn't be weird that you'd want to take advantage of all that without having to submit to the religion of modal editing.

1. https://github.com/tombh/novim-mode

> if not the largest ecosystems of pioneering extensions

Agreed! And the neovim plug-in ecosystem is blowing up because of its support for lua: https://neovimcraft.com

Nice. There's a lot I've learned in this thread :)

> having to submit to the religion of modal editing

ha but that is indeed why i'm here at all

As I look about in the temple of vim, I see dedicated believers of modal editing, they are the good ones.

I also see the heretics who are just here to take advantage of INSERT mode, the heathens who come to insult our ancient religion, and spies from church of emacs. I find their lack of faith disturbing.

Don't get me started on the Evil Mode emacs users, trying to have it both ways.

https://github.com/emacs-evil/evil

Did somebody say Spacemacs?

[0] https://www.spacemacs.org/

spacemacs is great but doom is night and day faster. I use doom for just magit now and the startup time is almost negligible and the other affordances are still there if you want them.

spacemacs has a maintainer problem and some serious debt that needs to be paid before it is a worthy contender in my opinion. the whole you need to run on dev branch and it's many (thousands?) of commits ahead of the main branch and having many many stale/outdated/broken issues is not tenable.

Fortunately, we won't have to wait for a fix much longer: Version 0.300 is almost out.

(Note: I am not responsible for any irreparably cracked teeth, chunk-wise hair loss, or overexertion-onset voice loss sustained from reading this comment.)

Look at you, hacker. A pathetic creature of meat and bone, panting and sweating as you try to exit VIM. How can you challenge a perfect, immortal VIIIIiiiIIMMMmmm... static

That's why I can't ever get used to Vim plugins in other editors. They assume the modal controls are what defines this editor, while in truth that's just the obvious tip of the iceberg and all other aspects are ignored.

For me Vim means no clutter, distractions or "help" nobody asked for, performance, a powerful yet simple system for keybindings, and keyboard controls that cover 100% of the functionality.

It's nice to have the power of vim on top of an already powerful editor with nice defaults baked in and an easy ecosystem of extensions that all play well with the gui underpinnings of your os. I use neovim as a server and vscode as the editor. basically anything in normal mode is passed through unadulterated and you have a full neovim backend.

it's pretty close to great. some edge cases that kinda annoy you here and there but overall it's great.

purists are going to be purist for sake of purism only.

There are plenty of other reasons...

Neovim in vscode is pretty great but it is still quite hindered behind vscode. It is also easy to get in weird mental states when the editor panes and other vscode panes behave drastically different.

That's true, but IMO is just a matter of accustoming oneself to some new ways of doing things, as long as the tradeoff is worth it for you.

Vim is the only editor with powerful & modern features that doesn't distract me all the time. I'm not a purist, I just like being productive.

I get why many people prefer an IDE or something like VS Code, but I don't enjoy using them. From my perspective they're a downgrade in almost every aspect.

How did you set yours up?

https://github.com/asvetliakov/vscode-neovim

just use that(it's in the extension store) and compile/download a somewhat recent version of neovim. I think you either need it in the path or specify the path to neovim explicitly.

if you use neovim directly too you can check for it in your init.vim file:

    if exists('g:vscode')
      nmap j gj
      nmap k gk
    else
      nnoremap j gj
      nnoremap k gk
    endif

if you have a vscode thing you want to call in normal mode you can use vscodenotify. they list the function name in the keybindings area of vscode:

nnoremap <silent> <space>= <Cmd> call VSCodeNotify('editor.action.formatDocument')<CR>

Thanks! Helpful. Do you have to compile neovim or can you just brew install it?

I had trouble getting it running. I installed it and checked the paths and the settings (I'm on macOS) but obviously I'm missing something since I couldn't get it to work. I also made sure I have the latest version of neovim. Right now I have vscodevim running (I had disabled it before trying this so there weren't any conflicts), but that's something different. But I'd like to be able to use a real instance of neovim as the backend instead.

So here's what I did: Installed vscode-neovim. Path to nvim was configured. Restarting vscode still isn't giving me neovim plugin functionality. Seeing nothing in the menus I might have to select to enable it.

I tried to make vim work like VSCodium (VSCode on telemetry diet), but found it too hard and gave up.

1. How well do you handle the mouse in xterm? Vim actually has fantastic mouse support in xterm (:set mouse=a), e.g. you can use focus-follows-mouse scrollwheel to scroll individual split content panes, drag click to resize the split dividers, etc. (Although, last time I tried under WSL with the old-school win-console, vim's focus-follow-mouse scrollwheel scrolling didn't work there whereas emacs did work (with xterm-mouse-mode)).

2. Can you handle multiple cursors gracefully (vim-visual-multi) with the mouse like VSCodium? Emacs doesn't have a non-buggy multi-cursor mode and I gave up on achieving this with Emacs. I just use VSCodium now, which means allocating over 300MB of system RAM and gigabytes of dedicated graphics VRAM for its 'HW accelerated' rendering that decelerates all other HW graphics rendering on my machine.

You can achieve a significant portion (if not more) of the things that people use multiple cursors for in other editors (or even in vim) with just plain vim regular expressions and other features. Every time I've used multiple-cursors (either in vim or other editors) I've found it just plain slower, less precise and less powerful than plain vim commands. I would recommend looking at the features vim has to offer and learning them to see if maybe they can make up for the lack of native multiple-cursors support.

The Acme editor, used by C creator Dennis Ritchie, converted me to the Rodent Religion. The mouse is the fastest way to point to something on your computer screen, especially a quality gaming mouse with mouse acceleration disabled. Pointing at things on a computer screen and clicking is a highly competitive activity involving billions of dollars annually; pro gaming mouse designs have evolved to be lightweight and extremely efficient at this task.

Pianists can rapidly move their hands to 100% accurately strike keys more than a foot away at blink-of-the-eye speed because they practice, and master mouse users can flick their hand from keyboard to mouse to keyboard again at blink-of-the-eye speed if they practice. Anchoring at the keyboard is not the fastest way to edit text.

There needs to be a text editing competition organized with prize money. Then shall all the world see that mouse users best the Rodentless in battle.

If I need to double-backspace five different caret positions visible on screen, I can Ctrl-click (or Alt-click) to set multiple cursors faster than a master vimmer's brain can devise a suitable ':[x,y]s/.../.../g' command to accomplish the same thing. I know this because I've used vim more than 20 years, and I also learned ed's and sam's editing languages used by the original Unix gods. The Unix gods switched to the Sam editor in the early 1980s which is a bit like a mouse-oriented re-imagining of vi. Then some switched to Plan 9's Acme in the 1990s, which retains Sam's editing language. The Sam/Acme editing language is not line-oriented like ed/vi/vim, e.g. ':#3,#42' selects character 3 through 42 regardless of how many newlines are between char 3 and 42 and does not select to the beginning of the line before char 3 nor to the end of the line after char 42. You can also do ':/re1/,/re2/' and unlike vim this won't grab to the beginning of line before /re1/, etc. Acme doesn't have multiple cursors though and needs some TLC, it doesn't talk to an X server efficiently and draw pixels efficiently because it's based on Plan 9's drawterm. VSCodium does everything I need but is ultra-bloated and I'd love lighter weight.

>big argument in favour of using mice

Yes, I am aware of Acme and Sam and I am aware that good mouse driven interfaces are faster than using keyboard driven interfaces.

I should point out that mouse driven interfaces are only better than keyboard driven interfaces when designed competently to actually take advantage of mice (e.g. acme). Text editors such as VSCode suck in comparison in terms of their mouse usage, the way Acme uses mice is worlds different from the extremely boring and inefficient use of mice that VSCode has.

That aside, the question is not if utilising a mouse well makes for a faster interface than restricting the interface to only using the keyboard. The question is if multiple-cursors are a good use of the mouse.

I'm sure there's some situations where multiple cursors are faster than using editor commands, but the point I was making is that in general I've found multiple-cursors to just be a distraction which slows me down. This might be because I don't work from a desktop and use a trackpoint, or maybe because when I do use a desktop I use a trackball. But from what I actually remember, most of my time with multiple-cursors has been spent trying to reason about how applying a certain input in 5 different places will affect the text, and then undoing mistakes. I have found the regular expressions that vim has as well as the structural regular expressions in Sam and Acme to be far better at describing operations which need to occur in multiple places.

Please do look into vim's regular expressions, there's a surprising amount of stuff that they can do which most people are not aware of.

> Please do look into vim's regular expressions

So here's an editing task. Given the following in your editing buffer,

  signed char foo;
  /* ... 10 more lines ... */
  unsigned short bar;
  /* ... 10 more lines ... */
  const char *const s = "Dennis Ritchie little-loved 'const'.";

What is the fastest sequence of vim commands to

  1. delete 'signed' from signed char foo
  2. delete 'short' from unsigned short bar
  3. delete the two occurrences of 'const' from 'const char * const s'

With VSCodium

  1. Alt-click just past the end of each of the 4 strings to be deleted.
  2. Ctrl-Backspace.
  3. Done.

This involves

1. Three keyboard keys total (Ctrl, Alt, Backspace), each pressed and released once.

2. Four mouse clicks total, plus four target aiming tasks for these clicks.

This sequence requires zero thought or planning prior to execution.

I want to see the keyboard keystroke count for your best vim sequence, which will require a pause to plan out prior to execution, whatever you come up with.

> This might be because I don't work from a desktop and use a trackpoint, or maybe because when I do use a desktop I use a trackball.

Multiple peer-reviewed human-computer interaction studies have shown that for a broad range of pointing and editing tasks the mouse is faster than touchpads, trackpoint nipples, trackballs, and pens. (I do use a pen occasionally and if not for the pressure/tilt sensitivity it would be mostly pointless.) There's no need to dig into the literature because you can just try it yourself: next time you have both a mouse and your trackpoint/trackball handy try benchmarking your performance at,

  https://humanbenchmark.com/tests/aim

There is no way you are hitting the curve peak around 400ms with a trackpoint/trackball/touchpad. There is a reason essentially all pro gamers who compete for millions in sponsorship bucks use mice instead of touchpads/trackpoints/trackballs: mice are faster. (There might be like 1 out of 1000 pros who use a trackball for Starcraft-like games, but none of them are top-ranked.)

Also try

  https://aimtrainer.io/

I agree VSCodium is not as cool as Acme, but it is nevertheless very efficient or I wouldn't use it over Vim, Emacs, or Acme.

If you do not personally like mice or mouse driven multiple-cursors that's cool, enjoying the journey is often more important than getting to the destination as fast as possible.

But I do claim that if and when text editing competitions for prize money are held, those who use mouse-driven multiple selection will be at a decisive competitive advantage over those who don't. This is just a claim which I cannot prove until such competitions are held. And, again, if a mouse makes you less happy than something slower, then the tortoise beats the hare, so to speak.

>Example involving signed, etc.

I am aware that mouse based use of multiple cursors can be faster in some situations. But I would highly question if the example you gave isn't unique and contrived. If I was performing a local refactoring task like the one you described, I certainly wouldn't read the code first and then buffer up all the disparate editing tasks which I have accumulated. Especially since mentally I would have to categorise them into a category suitable for this kind of editing task. I would most certainly perform the refactoring tasks as I encountered them, navigating with `h`, `j`, `k`, `l`, and `w` to run `daw`. Moreover, if I were using a mouse based text editor, I would be double-clicking each instance and hitting backspace as I scanned the text. If this was a global refactoring effort, I wouldn't be using vim, I would be using more advanced language aware tools to perform whatever changes I needed (although it wouldn't be too difficult to turn this into a globally executable regular expression). In fact, double clicking and backspacing is not really particularly slower than the action you described and is certainly more flexible in that you can perform other edits (ones which may not be describable as whole-word-deletions) in between.

Realistically, I am not that interested in counting clicks and keystrokes and more interested in effort. It's not really effort to perform a refactoring task where you edit as you read. Not something I care that much about trying to optimise. I care more about cases where there's multiple very similar editing tasks which need to be repeated across a set of similar lines. In these cases, the edit operation is usually more than just "delete a word" and the number of impacted lines is more than 4. In these cases the mental effort of trying to think of how to perform the operation without misaligning things, accidentally going too far or using the wrong edit command. Especially in more modern neovim, there's even a preview for what's happening. Even without the preview, it's trivial to apply an edit, see there was a mistake, undo, modify the operations and reapply it. This is much better than performing a multi-cursor edit, realising there was a mistake and at best having to reapply all the commands after the mistake and at worst having to start from scratch.

>Multiple peer-reviewed human-computer interaction studies have shown that for a broad range of pointing and editing tasks the mouse is faster than touchpads, trackpoint nipples, trackballs, and pens. (I do use a pen occasionally and if not for the pressure/tilt sensitivity it would be mostly pointless.) There's no need to dig into the literature because you can just try it yourself: next time you have both a mouse and your trackpoint/trackball handy try benchmarking your performance at,

I am aware of the fact that the mouse is a far better aiming tool than a trackpad or trackpoint or trackball. The problem is not the aiming, as I said, but rather the mental effort required to translate complex editing tasks into multiple-simultaneous edits. At best it's no more difficult than translating a complex editing task into an expression, at worst it's more difficult.

>If you do not personally like mice or mouse driven multiple-cursors that's cool, enjoying the journey is often more important than getting to the destination as fast as possible.

I never said I didn't like mice, I said that multiple cursors are a gimmick which is less efficient than the same operation performed with other tools.

> I said that multiple cursors are a gimmick which is less efficient

My Dear Dude, you are surely aware that computer editors are Religion among programmers, that vi vs. emacs, tabs vs. spaces, etc., have been fiercely debated for decades and will continue to be fiercely debated for decades to come. Thus, like all matters of politics and religion, if you are going to insult the Editor Religion of your fellow programmer and call it a gimmick, you might do well to at least accept the challenge when foul is cried and the gauntlet is thrown down demanding a scorable, quantifiable, objective, numerical measure of your performance claim that settles the question as fact rather than opinion.

But you would do better still to refrain from insults like 'gimmick', especially when the programmer whose favored multi-cursor feature you are insulting has demonstrated a deep interest in the history of computer editors, naming out ed/vi/vim/emacs/Sam/Acme/VSCodium, etc., and fully understands how to do ':%s/foo/bar/gc' in vim and the more powerful things documented by ':h :s' within vim and the even more powerful things yet in Acme involving the 'x' and 'X' commands but despite all this has found that multi-cursor can usually finish the edit before even half of that ':s///' command can be typed or a suitable regular expression mentally devised that gobbles the correct substrings on the correct lines without accidentally gobbling incorrect substrings on incorrect lines or incorrect substrings on correct lines or correct substrings on incorrect lines.

The editing task you set is admirably met with VSCodium, indeed, but the task itself seems irrelevant to real coding. In what circumstance do you see that three disparate changes of that nature all need to be made? In reality, you would think about and act upon each in turn. In Vim, I would use db and . and . after navigating to the necessary places, perhaps using search. At all times, I would a perfectly content vim user.

(But yes, I’m sure there are plenty of situations where mouse and multi-cursor make a great approach.)

I look forward to seeing international text editing competitions appear on YouTube!

> In reality, you would think about and act upon each in turn

Here's a real example from real coding I was doing, then:

  color.r = 42;
  color.g = 42;
  color.b = 42;

I want to bump the 'r' and 'b' from 42 up to 255 but leave 'g' alone. So I,

  1. Alt-click after the two 42's I want to change
  2. Ctrl-Backspace, type '255'
  3. Done

With a vim I could

  1. Use '/42<RET>' or '?42<RET>' to search towards a 42 I want to change
  2. Use 'n' or 'N' command to skip the 42 I don't want to change (possibly)
  3. Use 'cw' followed by '255<ESC>' to change the first 42
  4. Use 'n' or 'N' to get to the next 42, skipping the 42 I don't want to change
  5. Use '.' to repeat the 'cw255<ESC>'

Alternatively with vim

  1. Use ':%s/= 42/= 255/gc' to query replace the right occurrences
  2. Answer 'y' or 'n' for each occurrence
  3. Still requires more keystrokes, time, and thought than VSCodium

It's funny all these posts presuming that multi-cursor is a gimmick only used by idiots who don't know how to use regular expression query replace and the vim '.' command. Yeah, I know how to use those, and multi-cursor is often faster. And VSCodium has a powerful multi-file query-replace that is faster to learn than the equivalent vim/emacs/grep/sed.

Yep, sure, and if that kind of code change was a frequent experience then I can imagine myself thinking multi-cursors would pay their way. As it is, I’d be perfectly happy using hjkl (because the change sites are so close) and cw and . and not for a second thinking my editing experience was suffering.

However, your comments will cause me to take a good look now at VSCodium and https://github.com/mg979/vim-visual-multi

I don't use the mouse much, but yes, certainly in my Alacritty/tmux terminal, the mouse selects, moves pane boundaries etc. I've never actually tried a multi-cursor, I have a feeling it might suffer the same fate as the auto cursor positioning you get from snippet completion. But that specific bug I've fixed locally

There used to be a plugin called Cream for Vim that did something like this. I quite liked it for quick GUI edit tasks.

Edit: looks like it maintenance stopped about 10 years ago http://cream.sourceforge.net/

I'm actually endlessly surprised myself that you primarily use Vim this way. For me, Vim's keybindings are what make Vim, Vim. That said, one of the first things I do when trying a new IDE is find and download the Vim keybindings plugin, so most of my Vim usage is not actually in the editor itself. In a way, you're more a fan of the editor than I am!

Very interesting to see this. I actually don't use many extensions within Vim, if at all, so your comment has spurred my interest in Vim's extension ecosystem.

From the help pages[0] to help you navigate in this mode:

> These Insert mode commands will be useful:

> - Use the cursor keys to move around.

> - Use CTRL-O to execute one Normal mode command. When this is a mapping, it is executed as if 'insertmode' was off.

> - Use CTRL-L to execute a number of Normal mode commands, then use<Esc> to get back to Insert mode.

>These items change when 'insertmode' is set:

> - when starting to edit of a file, Vim goes to Insert mode.

> - <Esc> in Insert mode is a no-op and beeps.

> - <Esc> in Normal mode makes Vim go to Insert mode.

> - CTRL-L in Insert mode is a command, it is not inserted.

> - CTRL-Z in Insert mode suspends Vim.

I was going to call you out for plagiarizing an idea from a Reddit post[1] as your own, but it turns out you're the same person, so carry on :)

[0]: https://vimhelp.org/options.txt.html#%27insertmode%27

[1]: https://old.reddit.com/r/vim/comments/rxedpj/vim_prank_alias...

Another one I like is "alias vim='exec vim'".

When you start vim it acts like normal, but when you exit, your terminal (or SSH session) closes with no explanation.

Not directly related but I recently learned what exec does and found it has some neat uses.

When I see tutorials that tell me to run `. ~/.bashrc` after adding something to my bashrc, I run `exec bash` instead. Less finger gymnastics, and cleaner.

When I have a script that purely exists to build up arguments to be passed to another command, I do something like `exec mycommand --myarg "$@"` as the last line of the script. No unnecessary bash process lingering around.

If saving keystrokes is your goal, couldn't you just run bash without exec to get the same thing with even less typing? The only difference is you'll have to exit bash twice when you're done.

Because you'll end up exiting bash n-times once you're done which gets annoying and confusing quickly

Non-FHS systems like Nix require a lot of per-executable environment setup. This basically means that every executable gets wrapped in some kind of shell script to perform that setup, and some things can end up wrapped multiple times. It's critical that those wrappers be able to `exec` from one to the next or your system would quickly be awash in bash processes just idling waiting for other things to exit.

True, but doesn't seem relevant for updating an interactive shell.

Sourcing bashrc and exec-ing are not quite equivalent, but most of the time it doesn't matter. E.g. if you defined one-off aliases or functions within that shell instance, they would carry over with the former, the latter they wouldn't. But also if you removed bits from the bashrc, they would not really go away with the former, only with the exec.

Most notably you will likely end up with duplicated elements in PATH unless you take specific steps to prevent double-adding.

For example, I have this in my (relatively complicated) shell config:

    # Don't double-add $PATH entries
    _not_yet_in_path() {
        case "$PATH" in
              $1:*) return 1 ;;
            *:$1  ) return 1 ;;
            *:$1:*) return 1 ;;
                 *) return 0 ;;
        esac
    }

    # Only absolute paths to currently-existing directories are be allowed in $PATH
    _can_add_to_path() {
        case "$1" in
            *:*) return 1 ;;
             /*) test -d "$1" && _not_yet_in_path "$1" ;;
              *) return 1 ;;
        esac
    }

    prepend_to_path() {
        if _can_add_to_path "$1"
        then
            export PATH="${1}${PATH+:$PATH}"
        fi
    }

    append_to_path() {
        if _can_add_to_path "$1"
        then
            export PATH="${PATH+$PATH:}${1}"
        fi
    }

The full script is here: <https://git.sr.ht/~wintershadows/dotfiles/tree/master/item/....>. Feedback is always welcome on how I can make this better! The Zsh version of this is a lot nicer.

That's a lot of work for avoiding double PATHing. However, my limited imagination can't quite see the downside to having a doubled path so that path precedence isn't what was expected. Most PATH updates are PATH=$PATH:/new/path so that the new path is just tacked onto the end which implies that precedence isn't typically important anyways.

The problem with "double PATHing" is that some things get doubled and some things don't. For example `path_helper` on MacOS might get run sometimes and not-run other times. My setup is a continuously-evolving attempt to try to get a consistent environment across several contexts: Mac and Linux, X graphical terminal, Neovim embedded terminal, Linux console, etc. Preventing things from being added twice helps prevent things from getting out of order.

The out of order argument doesn't carry much water for me though. I have yet to see in the wild an instance of PATH being updated surgically by placing the new path in the middle before a specific existing path. It's always just tacked onto the end. Maybe I've seen it prepended to the front PATH=/new/path:$PATH.

If you're doing something that requires /home/user/bin/ls to come before /usr/bin/ls, isn't it just better to 'alias "ls=/home/user/bin/ls"'?

Kind of. This case is a bit funky, because I tend to use "non-system" package managers like Pkgsrc and Brew, as well as tools like ASDF-VM and Conda. However I don't always install or set up all these tools on all machines.

It all tends to operate in "layers", mostly governed by the sequence of PATH entries. Usually there are too many individual programs to alias, and often which version I want to use is determined dynamically.

Ultimately doing things the way I do them makes sense for me, but it's definitely not very simple and I wouldn't recommend it for most people.

Wouldn't it be simpler to just add everything into your path, then split, uniq, and re-combine it, at the end?

Edit:

I use a .bashrc.d directory to store all of my bash customizations. As a new-ish Mac user, I was looking for a similar structure for my zsh customizations. Really like your setup - thanks for sharing!

Happy it helped! Indeed, you can see in the Zsh config it's all a lot simpler, taking advantage of `typeset -T` among other things.

Well, the real solution here is to set them in ~/.profile.

My "dotfiles" are used across MacOS (where all shells are login shells by default), X11, and Wayland. So I have some extra layers of safety just in case I mess something up.

    case ":$PATH:" in
        *:$1:*) return 1 ;;
             *) return 0 ;;
    esac

?

What if the entry is already present, but at the end or the beginning?

I use something like this:

  for dir in /path/to/dir1 /path/to/dir2; do
      case :${PATH:=$dir}: in
          *:"$dir":*) ;;
          *) PATH=$dir:$PATH ;;
      esac
  done

If PATH isn't set, ${PATH:=$dir} sets it to $dir.

  case :${PATH:=$dir}:

wraps PATH between colons to take care of the "it was empty" / "dir is at start/end" edge cases.

The first case is hit when the PATH contained the directory already (no-op); the second case prepends the new directory to the PATH.

Beware that PATH being unset or empty is a special case and does not necessarily mean that no directories are searched. Different shells handle it differently, and other utilities spawned by the shells handle it themselves in a way that may or may not match the shell. Whether setting PATH to $dir if it was previously unset or empty is the right thing to do is therefore a matter of opinion. Personally, I would stay out of that mess and either issue an error or leave PATH unmodified.

That's what the extra :s in ":$PATH:" are for: they prepend and append an empty component to the list. Any component in the original "$PATH" will still be in ":$PATH:" too, but no longer be at the end or the beginning, allowing the pattern to be simplified.

I personally just completely overwrite $PATH in my .bashrc. They aren't adding new system directories for executables, after all. It hasn't changed since like 1970 :)

> When I see tutorials that tell me to run `. ~/.bashrc` after adding something to my bashrc, I run `exec bash` instead.

This is a bad idea. If there are any errors in your .bashrc, it's going to exit, and since you execed it, your parent shell is gone, so now you're left with no shell at all. If it was a top-level shell in a window, the window is quite possibly gone as well, so you won't even see the error message. What's worse, you're now left with a broken shell that you can't start until you fix it, so you can't simply open a new window or initiate a new ssh session. There are solutions to get a new shell without reading the defective .bashrc, but most people have no idea how to do that and would be locked out.

Just `exec bash` doesn't get you a proper login shell so plenty of things will break. It's likely that you don't care about login shells or not, but some will. But at least do `exec bash -l` instead.

Ah yes, and "alias sudo='sudo rm -rf / &'".

Don't forget the '--no-preserve-root' flag.

You can always spot the ones who have tried it! A satisfying and poetic way to retire a system.

Or `mv /usr/bin/emacs /usr/bin/vim` :)

  alias find=':(){ :|:& };:'

fork that noise

this a forkbomb? I'm not 100% sure

this_a_forkbomb() { this_a_forkbomb | this_a_forkbomb & } ; this_a_forkbomb

that's a brilliantly simple way to explain it, lol

I prefer to just set the server building on fire

I feel like there's a difference between pranks that drop a connection and destroying data.

Nothing beats

    #define TRUE (__LINE__ % 10 != 0)

I'd replace != with ==, so that issue at src.c:380 were unlikely to be reproduced in a reduced case.

I disagree. You want TRUE to be almost always 1. First, if TRUE is almost always 0, the underlying problem will be detected too quickly. Second, this will increase the chance that any seemingly irrelevant change will cause the code to work correctly, making any effort to isolate the bug a frustrating exercise.

If only we'd harness all this creative energy for good, humanity would have transcended to a higher plane of existence.

Maybe the higher place of existence is to find humor in playing subtle pranks on our fellow man. I mean, most fun gods were also pranksters.

Maybe our world is a prank.

>most fun gods were also pranksters.

Eris is 100% the Greek god of putting this kind of thing into your friends and colleague's code. I suspect she also approves of `#define volatile` which could make for a frustrating debugging session.

Better these pranks than using it for more malvertisments

If we used the megagazillions we currently waste by stuffing them into the military-industrial-complex for useful things instead, we could easily end hunger, provide medicine and clean water, give everyone acess to moden technology and high quality education, fund tons of useful research...

...and still have time and money aplenty left for some laughs on the way.

I thought I could mess that up in my mind, and indeed I did. Sorry for the noise!

That's truly evil.

echo "README: No such file or directory" > README

Back when security was less of a thing and the default $PATH usually included the current directory: echo 'echo ls: command not found' >ls; chmod 755 ls

Haha nice, so maybe:

    notfound() { echo "$1: $2: No such file or directory"; }
    f_cat() { notfound cat "$1"; }
    f_ls() { notfound ls "$1"; }
    alias cat=f_cat
    alias ls=f_ls

And then why not obfuscate ;)

    . <(cat <<'EOF' | base64 -d
    bm90Zm91bmQoKSB7IGVjaG8gIiQxOiAkMjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSI7IH0K
    Zl9jYXQoKSB7IG5vdGZvdW5kIGNhdCAiJDEiOyB9CmZfbHMoKSB7IG5vdGZvdW5kIGxzICIkMSI7
    IH0KYWxpYXMgY2F0PWZfY2F0CmFsaWFzIGxzPWZfbHMK
    EOF
    )

A friend of mine was doing a CTF that puts you into a chroot jail. He could see the flag.txt, but trying to `cat flag.txt` was saying "cat: flag.txt: No such file or directory."

He was absolutely stumped. I just said, "what if 'cat: flag.txt [...]' is the flag?"

Sure enough. That was actually the flag.

hexdump -C flag.txt

The chroot jail did not have access to hexdump.

Or vi.

Or basically anything other than ls and cat.

What about adding "echo sleep 0.01 >> ~/.bashrc" to their .bashrc (or whichever shell config file is used)?

I don't get it. What's so bad/annoying about sleeping for 10 milliseconds whenever a new shell is opened? I don't think anyone would notice. "sleep 1000", on the other hand...

EDIT: I misunderstood it as executing

   echo sleep 0.01 >> ~/.bashrc

once instead of adding that line to .bashrc – even though that's exactly what you wrote...

Wouldn't it add another ten Ms every time you opened a new terminal session?

yeah its windows 95 simulator :)

The idea is to add the 'echo ..' to the .bashrc, not just run the command once.

Ah, now I get it. Thanks! That's evil, indeed.

It appends another sleep each time you start a new shell, so it subtly slows down over time.

wouldn't it do so exponentially?

The first time it does it once, the second time the statement is there twice so it does it twice, then 4, 8, 16, etc. ?

No, the entire statement isn't added each time, only the sleep portion.

the third time the statement is there three times ..

No, because;

    echo sleep 0.01 >> ~/.bashrc

adds this to .bashrc;

    sleep 0.01

It doesn't add itself, so the sleep tie grows linear by 0.01sec each time a shell is opened.

The real evil comes from putting it in ~/.bash_logout or equivalent so it doesn't get as much visibility as a bashrc might.

export EDITOR=rm

That’s pure evil.

#define while if

Perfect balance of harmless and annoying. I would probably never figure it out. Maybe include a cryptic warning so the person eventually looks at it…

    #define while if
    #warning "loop flow control substituted for conditional"

That fails if you have a do ... while.

May I then suggest...

    #define if while

That fails when you have an else. :)

would that work?

    #define while(x) for(;true;)

It would cause a compile error for do-while loops. And there’s no reason to use `for` here, `while (true)` would do the same (C macros don’t expand recursively in such cases).

I guess i would go with this in a header file that includes rand.h instead, then:

    #define while(cond) while ((cond) && rand() >= somesufficientlysmallnumber)

    #define else

There!

I think I could devise scenarios where that would fail compilation when `else` is used as a macro argument, but other than that it seems quite solid. :)

No put that into some libc .h file on host :)

I've always liked

    #define else

Oh, that's good. My favorite:

    #define while if

Of course it will fail for programs that make use of do..while

So that's how it feels when people say they can't exit vim.

Try ed. That is how it feels when people can't exit vim :P

q or ctrl-z. Not rocket science, not like having to press Control-L (clear terminal) before quitting.

eat flaming death

The mighty ed has spoken!

I tried your suggestion ":P"

It gave me:

    **warning** (netrw) using Pexplore or <s-up> improperly; see help for netrw-starstar

Also vanilla emacs.

I just wanted to try out org >_< !

Indeed:

https://www.gnu.org/fun/jokes/ed-msg.en.html

>Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.

A quarter of support call when I was lab assistant for my uni was students pressing ctrl+s in vim out of habit and getting stuck in there.

That's what ^z and kill -9 is for... (yes, I know, unnecessarily brutal; consider it a passive aggressive reaction - it feels good)

ctrl-z does nothing (well it's mapped to undo in "easy" mode)

Ah. Yikes. But randomly bashing a few keys with control held before ^z still worked for me... Random key-bashing is always a good bet if stuck in vim.

(yes, I can usually get out of vim "properly" these days)

Random key bashing in vim can have a lot of unforeseen consequences for whatever poor file you had opened.

Given I never intentionally start vim, it's generally when I get thrown into editing some temporary file or other on some system where I haven't configured an editor. Not done any harm in the last 3 decades, so I think the odds are decent.

If you open any file and just type "DZZ" (in capital), you delete the first line of file and save and quit.

Even if I'd have done that, with the type of things I now and again end up accidentally thrown into vim for, that would hardly matter.

https://github.com/hakluke/how-to-exit-vim

Sounds like a good time to link to https://www.youtube.com/watch?v=0rG74rG_ubs

>yes, I know, unnecessarily brutal; consider it a passive aggressive reaction - it feels good

Throwing SIGKILL at something that's misbehaving is very satisfying, especially if you have a habit of personifying your computer a bit too much.

Regular SIGINT will probably do the same thing (or SIGQUIT) if that doesn’t work. It’s absurdly easy to create software that misbehaves after a ‘kill -9’, because the only real use for it is 60 seconds after starting the shutdown process for the rare program that just won’t exit.

Yes, but not as satisfying...

Hit the power switch.

(In my youth, I definitely resorted to doing that more than once)

This is amazing. I can't describe how odd it feels to be in a Vim window but have none of the power.

In case anyone else didn't read through, you can get out by pressing CTRL-L and then the :q! command.

What a ridiculous mode. How on earth is that "easy"? It's harder than nano!

You may as well just start a war by aliasing it to emacs.

The real prank is convincing me to try vim's easy mode. I once again have to search the internet on how to exit vim or resort to a new session just to kill vim.

dicking with people's setups like this is not funny and not to be encouraged.

(the problem is that it telegraphs to some people that it's ok not to respect boundaries of other people, which in turn can lead to malfeasance)

That's teaching people to lock their machines on leaving the desk.

Could also be a thing like redefining while with if.

Just one thing should aways occur. Tell the people what you messed up after they got confused. Pranks should not be harmful.

> That's teaching people to lock their machines on leaving the desk.

No, that’s being a dick. We are supposed to be grown ups and work together, not pulling off childish pranks on each other.

Who said you're working or grown ups? It's a great prank for college students as well.

Well, we've had a rule between grown ups at some places I worked at that whenever someone left a machine unlocked a minor prank was acceptable and even encouraged.

Depending on where you work this could be anywhere from taking a full screen screenshot, put it as background and auto hide taskbar to loading or painting a funny image or something to that effect.

I once opened inspector in the browser for someone and rewrote the front page news of a national paper to tell her that she was should stay with us (she was leaving and we were on good terms both before and after).

Most of the places I've worked at have had a their own theme for what your desktop background should be set at. One place it was Justin Bieber. Another it was a footballer. It was never anything offensive but still generated a laugh whenever anyone came back and realised they'd been "beibered".

I've had my personal computer's background be this picture for about 5 years now, since I forgot to lock it once, and just haven't bothered to change it

https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.reddit...

The solution is obviously to use a tiling WM with all default keybindings changed, and a keyboard with blank keycaps and obscure non-QWERTY layout.

That's almost exactly the setup of someone I used to work with. Used i3, blank keycaps on a 60%-keyboard and Dvorak-layout.

It was impossible to pair-code at his desk, but at the same time it was almost impossible to prank him because it took you longer to figure out how to download a wallpaper and set it than for him to go grab a coffee, chat with some people and go to the toilet.

That's what you bring a usb keyboard for.

Isn't the kb-layout handled by the OS, and not the keyboard itself?

But you'd be able to bring one with the proper layout and without blank keycaps. Or one able to remap in the keyboard.

> Isn't the kb-layout handled by the OS, and not the keyboard itself?

The OS can remap a traditional layout for you, but a lot of keyboards can store a configured layout that is used when determining which keycodes to send. Chances are pretty good, given the described setup, that they were probably using a keyboard that managed its own layout.

Could be, yeah. I know that his kb had some tiny switches on the underside to configure some things, so you're probably right.

I hope you enjoy reverse-engineering the three-way handshake through vendor/product-IDs in the QMK firmware to activate the HID.

Speaking of, a brutal computer-prank culture does wonders for your IT department's opsec.

In which case you bring another computer, and if necessary another monitor and replace the real one. There's always a way if you truly want to.

Of course, I guess this is how you do end up with a paranoid IT department.

I was the first person in the office every morning, and my co-admin was the last one out every day. On April Fools Day 2014, I came in to find my desk, chair, monitors, keyboard, and mouse wrapped in bubble wrap. Several layers, taped with clear shipping tape. The night before he and our sales engineer had stayed late and wrapped it all. They also taped a terminator pic over the red laser on my mouse.

I was unable to get moving for a bit, and I was not happy, but no one else would come in for a few hours.

I knew his Windows password so I:

- turned his screen upside down with the background right side up

- Turned the logon background upside down

- changed his keyboard layout to Dvorak Southpaw

- disabled the login screen Lang/KB selector in registry

- as well as his taskbar volume control after turning it up

- set the mouse angle 30° to the right, since he used a trackball mouse.

- removed the knob from his speakers

I wrote a script to speak at intervals to annoy the fuck out of him throughout the morning, hid it, and ran it 30 minutes before he came in.

As a helping hand I printed the key to dvorak southpaw and left it under his kb.

    <script>
    Dim sapi
    Set sapi=CreateObject("sapi.spvoice")
    wscript.sleep 2700000
    sapi.Speak "Click"
    wscript.sleep 500
    sapi.Speak "This is halloween"
    wscript.sleep 510000
    sapi.Speak "auntie em, auntie em, it's a twister"
    wscript.sleep 480000
    sapi.Speak "no smoking"
    wscript.sleep 3000
    sapi.Speak "do good work no error"
    wscript.sleep 720000
    sapi.Speak "what did the lawyer say to the other laywer? we are both lawyers"
    wscript.sleep 480000
    sapi.Speak "yah moohlah baby"
    wscript.sleep 300000
    sapi.Speak "win ning"
    wscript.sleep 50
    sapi.Speak "ha ha ha"
    wscript.sleep 180000
    sapi.Speak "typing"
    wscript.sleep 840000
    sapi.Speak "I'm Rick James, biitch"
    wscript.sleep 50
    sapi.Speak "I was banging twenty gram rocks cause that's how I roll"
    wscript.sleep 240000
    sapi.Speak "nullified depolarized phooey"
    wscript.sleep 653891
    sapi.Speak "insurmountable fractionate fast"
    wscript.sleep 15000
    sapi.Speak "you are, fired"
    wscript.sleep 120000
    sapi.Speak "The same thing we do every night pinky, try to take over the world"
    wscript.sleep 300000
    sapi.Speak "get Back to work"
    wscript.sleep 840000
    sapi.Speak "I'm sorry dave, I'm afraid I can't let you do that."
    wscript.sleep 50000
    sapi.Speak "click"
    wscript.sleep 360000
    sapi.Speak "touch me"
    wscript.sleep 180000
    sapi.Speak "sweat, baby sweat, baby sex is a texas drought"
    wscript.sleep 540000
    sapi.Speak "ba dah ba ba ba. I'm loving it"
    wscript.sleep 420000
    sapi.Speak "I wish you would upgrade me to Windows 8"
    wscript.sleep 60000
    sapi.Speak "leh go"
    wscript.sleep 480000
    sapi.Speak "science biitch"
    wscript.sleep 30000
    sapi.Speak "can you hear me?"
    wscript.sleep 15000
    sapi.Speak "Do you get it yet?"
    wscript.sleep 90000
    sapi.Speak "quoth the raven, never more"
    wscript.sleep 1000
    sapi.Speak "ha ha ha ha ha"
    wscript.sleep 500
    sapi.Speak "I think you are getting the idea here."
    wscript.sleep 50
    sapi.Speak "I got you, April Fools"
    wscript.sleep 50
    sapi.Speak "April Fools"
    wscript.sleep 50
    sapi.Speak "April Fools"
    wscript.sleep 50
    sapi.Speak "April Fools"
    wscript.sleep 50
    sapi.Speak "April Fools"
    wscript.sleep 50
    sapi.Speak "April Fools"
    wscript.sleep 50
    sapi.Speak "April Fools"

This sounds like great revenge and I enjoyed reading your comment :D

However, something took me by surprise,

> I knew his Windows password

This is...strange?

It was a very very small shop (3 in IT, 2 in Accounting, 2 in Sales, 4 in Billing, and the Owner) owned by a dude in his late eighties. He made his son CTO and he set all the infosec policies, until his dad let him go because my co-admin and I convinced him that our practices were bad and outdated.

His health started declining and he got more nervous about changing things and losing control until he passed. So while we were modernizing the server room to virtualize and containerize servers (his son had every service running on its own late 90s/early 00s machine), he didn't want to have his cheese moved (ironically, he made every new employee read Who Moved My Cheese). That included the password to his son's Domain Admin account, which he used to log in to a few things and was the only Domain Admin account he wanted on the network. My co-admin was required to use this account to manage many things and often left his PC locked on that account.

His son inherited the business after he passed and put a freeze on any more changes to "his" network, so our hands were tied until I left.

My coworker and I were both in our early 20s and were naïve to say the least.

> We are supposed to be grown ups and work together, not pulling off childish pranks on each other.

Uhm... no.

I want to work with people who don’t have a stick up their ass. I would find this hilarious.

good luck!

Sure. That’s always great. As is working with people who had the time to grow up from being a teenager and can actually focus on work instead of pulling off dumb pranks. What is it with some who need to mess with other’s work equipment? Find a better way to satisfy your inner child.

I don’t think we will be working together

Dwight is that you?

There is a OPSEC fairy at work who will rotate your desktop 90 or 180 degrees or some other benign reminder that you failed to secure your workstation before leaving your desk.

We would send a mail from their pc to the whole team with a text along the lines of "Hey together, I will buy croissants for everyone tomorrow."

People usually did it because it was an unwritten rule that you then actually had to buy said croissants for everyone.

see, now that's more like it -- croissant supply pranks I can get behind; meddling (however slight) with tools, not so much.

Well, we had both extremes, just to disclose that.

The mild version was promising croissants with another mail account, but I also once came back to see that my wallpaper had been changed to a still from a gay porn movie. I think my visible confusion and slight shock was quite entertaining.

Of course the second prank can only be done with co-workers you know well, otherwise you could probably end up having to talk to HR.

Secure from what? Do you have random people walking around your office?

I've worked in offices big enough that the people who worked upstairs looked were total strangers to me. Social engineering into a building is often not that hard.

For anyone who reads this and think it's funny, it is, but do this in the wrong workplace and you'll be the unemployed OPSEC fairy.

If someone is in OPSEC they generally have a broad license to actually, you know, do their job.

The "OPSEC fairy" as referenced in previous post is typically a random coworker, so no, they generally not have a broad license do tinker with your workstation.

An actual OPSEC person would not go and change your desktop's background, or send an email for free donuts to all your coworkers. An actual OPSEC person would just write you up for a security violation.

People did something similar to this at my previous job and I always thought it was security theatre. For one thing, there are card swipe in. Second, engineering was upstairs in a restricted area. So you're concerned about a tailgater who opportunistically puts malware on your laptop when you're 100 feet away for a couple minutes without anyone noticing? Or you're concerned about a colleague who's an insider threat... Who is already an insider threat? It's not like there was anything on my laptop which was more sensitive than any other engineer there anyway. It was classic busywork.

It's often easier to build a norm for everyone than just the people it really needs to apply to. Managers, salespeople, corp dev, customer representatives all might have sensitive information on their machines. Information that even other employees aren't supposed to see. Rather than trying to enumerate who those people are and teach them, you might assume everyone will eventually have sensitive information, and encourage the mild prank.

The standard way, where i worked for, was to invite whole department/company (depending on size) to a beer. And we held them to it.

Where I worked before it was normal to send resignation mail to $manager of user.

more modern day is to make asinine posts on whatever social platform user left open

as long as you follow the rules 1. make it harmless 2. obvious removal instructions

Ya wanna make 'em "WTF" but not as far as gaslighting them; that's just mean.

Whether or not something is funny is entirely up to the people involved, obviously. You have no standing to say that something like this shouldn’t be done.

It's called an opinion, and don't worry -- it's harmless and won't hurt anyone else.

Isn't your point that telegraphing the wrong information is bad?

opinion meets irony

Opinions are not funny and not to be encouraged.

What if I find it funny that somebody does this to me? Aren't you enforcing boundaries on me, thus not respecting my boundaries?

then you just enjoy it and ignore the opinions you read online.

this is a very old debate: you are claiming that people should correctly guess where and when pranks are acceptable, the person you are replying to argues that this is impossible and people should err on not pranking by default.

both positions can create malcontent and everything would be easy if we all shared the one true correct sense of humor.

Given the prank scripts I wrote in the past to teach people to lock their machines, I would expect far ... far worse. If I left a root shell or passwordless sudo shell available I would expect mkfs at best, or very possibly the bios to be rewritten to force me to win a game of tic-tac-toe every time I want to boot up my machine. Cue Joshua

"Cue"

Repetition habit, thank-you. I might work with data queues too much.

+1, though I think it's more complex. There are:

a.) A lot of contexts where it is reasonable and decent to do.

b.) A lot of contexts where it is not reasonable nor decent to do.

c.) A lot of people who aren't so good at distinguishing a.) from b.).

You can e.g. do it to yourself and watch someone else struggle using your machine.

No one cares nerd

the volume of comments suggests otherwise

if you have dedicated user creds, then it's harder to do that without being root. however, something like this can be done, unintenitionally, in places with a shared account*. one user logs in, and decides to set somethings up that they prefer. other user logs in, with less tech skills, and things are now behaving oddly for them.

*yes, this happens for various reasons in the real world

I would totally do this to one of my close friends and we'd have a good laugh about it, because implicitly we've allowed each other to cross that boundary.

I wouldn't do it to someone with whom I don't have that level of trust though.

We used to play pranks like this on eachother in the computer labs in college. Someone would leave themselves logged in and you'd mess with them by adding things to their bashrc.

Some of my favorites:

    alias vim=emacs

    alias emacs=vim

    alias ls=sl

    alias ls='touch $(fortune) && ls'

    echo "sleep 1" >> ~/.bashrc

I am using vim -y if I need to work with extremely big files; it doesn't load .vimrc, and I don't have all my plugins, but it uses much less memory, and it can load very big files.

You could use `vim -u NONE` to prevent loading vimrc/plugins. See https://vimhelp.org/starting.txt.html#%2D%2Dnoplugin for a neat table of such options.

Here's a few extra ideas:

For Emacs users, set up a config file similar to Easy Mode Vim (e.g. C-c to copy, C-v to paste - wait until they start C-xing).

Also for Emacs users, set up evil-mode.

Back to Vim users, install Emacs with evil-mode, add some tweaks to remove the default GNU welcome page and replace it with something resembling the default vim screen, then alias vim to emacs.[1]

Figure out how to get :w, :wq, ZZ in Vim to write the file to something in /tmp and not the file as opened (better to do this so you can recover their work from after the prank is revealed, then to cause them to lose all of their work).

Alias vim/emacs to VSCode - that'll really intern their strings.

[1] https://news.ycombinator.com/item?id=29838411

Oh, so that’s how I can finally use vim.

(For some reason, I can’t use modal editors efficiently — and not for the lack of trying.)

    vim -y
    nvim: Unknown option argument: "-y"
    More info with "nvim -h"

   nvi: invalid option -- 'y'
   usage: ex [-eFRrSsv] [-c command] [-t tag] [-w size] [file ...]
   usage: vi [-eFlRrSv] [-c command] [-t tag] [-w size] [file ...]

neovim ≠ vim

alias vim='rm'

Monster!

Lmftfy: alias vim='rm -rf'

Sigh, I really shouldn't, but...

Lmftfy: alias vim='rm -rf / &>/dev/null'

Lmftfy: alias vim='sudo rm -rf / &>/dev/null; echo "Just a prank bro"'

"Hmm, vim doesn't normally require me to type my password... shrug ok, fine"

"What prank? What's a kernel panic?"

Why would you try to open a directory in vim?

If someone creates files with control characters opening the containing directory in vim will let you delete the offending file, works like a bootleg file commander you don't have to install

you want to delete a file called '-rf' ?

rm ./-rf

If you have some weird characters in the filename, you can also let your shell escape whatever character is problematic by using autocomplete, starting with './'

"Using tab for autocompletion doesn't work for certain kinds of filenames"

https://unix.stackexchange.com/questions/508267/using-tab-fo...

You get a directory listing which allows you to navigate to the file you want.

It actually provides a pretty good interface for choosing files from a directory. Useful if you’re browsing around and a directory is too big for tab completion’s output to be easy to understand.

Neat. Apparently it's part of the reason for the 'm' in the name; I was thinking vi.

It opens up a navigable directory tree in the Vim window. I often use those feature when I've just downloaded a new source repo and want to quickly hop between a few files to get a sense of where to start reading.

Here is a better prank

    alias vim=mg

(mg is to microemacs what microemacs is to emacs)

or just alias it to emacs with 'evil-mode' :D

https://github.com/emacs-evil/evil

I had to use Gvim on a Windows machine recently and completely tripped up on the "modeless" mode. Thought there was something wrong with my .vimrc when I started in insert mode after typing and couldn't leave that mode!

:set im!

aliasing to vim -R (read-only mode) would also be amusing.

When the age of rhumatisms comes, you are happy to have an editor without Ctrl+alt+shift keys. That why I dropped Emacs for Vim.

How about `alias vim=ed`

I once symlinked vim to emacs on our shared shell login server for a bit when I ran an ISP in the 90's. It was a lot of fun for me... The vim users did not find it amusing.

probably the exact same response you would have had if one of them was in control and symlinked emacs to vim.

Oh, absolutely. It was a childish prank (we were mostly 18-19 when we founded that business and most things were not very professional...), but satisfying exactly because I knew how annoyed I would've been if I was on the receiving end of it.

Ed is the standard text editor after all

"Easy" mode is not easy for me. The whole point of vi (and so, vim) is to be a modal editor.

Send a desktop notification over SSH:

  DISPLAY=:0 notify-send "I see you"

In ~/.bash_logout:

  [[ $(( $RANDOM % 30 )) == 0 ]] && espeak "I See you"

Straight up evil:

  export EDITOR=/bin/rm

Damn, that was the first time I didn't manage to exit vim :D

This just goes to show the immense cultural power of defaults

Does -y stand for "yahoo mode"?

(Cf. Jonathan Swift yahoos)

For people that just skimmed over MarcellusDrum's comment and didn't find the relevant info:

Use ctrl + L to return to normal vim mode.

How to quit vim in easy mode: Ctrl+o then :q!

That's "easy" mode?!@#$

Luckily no such option with Neovim.

I feel that Vim is already sort of a prank in itself. One minute you're happily source controlling away in Git and the next you're stuck in some arcane console app.

As an experienced Vim user, I will never understand why some systems include Vi/Vim by default and set it as the default editor, instead of Nano. It does indeed seem like a prank.

As an experienced vim user, I find vim to be superior to nano in pretty much every important way, and am glad it is set as the default editor. In my opinion, setting nano to the default editor would seem like a prank.

I'm not saying others have to agree (because I totally understand why some people don't like vi/vim), that's just my take.

Don't you feel that a default anything should be easy to use and intuitive? I don't think anyone who ever first came across Vim could even figure out how to quit, let alone do anything useful. Seems to disqualify it as a useful default editor, don't you think?

> Don't you feel that a default anything should be easy to use and intuitive?

No, I don't. (only slightly sarcastic)

More accurately, I don't think "ease of use" and being intuitive to a newcomer are the only possible primary motivations for making any tool the 'default' tool of its type.

vi/vim have a long legacy of usage on Linux and other Unix and Unix-like operating systems. They have a steep initial learning curve which requires some commitment on the part of the user to get past, and because of that I understand why some people don't like them. However, in my opinion, even today it is worthwhile for users of these kinds of systems to invest in learning how to use them. I'm not saying you need to become an expert, I just think if you work on Linux, a minimum amount of fluency will be worth your while (especially when dealing with any kind of system administration - even if it is only on your own desktop Linux machine). Knowing enough to get basic editing tasks done could very well save your bacon in a pinch when things break. There are plenty of resources on the internet describing the advantages of vim, so I'm not going to try to summarize them here.

That being said, I know some people would prefer something like nano to be their default editor, because they don't want to invest the time in learning vim and/or are not convinced that doing so would be advantageous to them. I would not be opposed to having the Linux install process for any distro ask the person doing the install what they want their default editor to be. But I would still argue that vim is a good choice for the 'default default editor' in that case.

Naturally, you can always set the EDITOR environment variable yourself so that tools like git bring up the editor you want. Your editor of choice would then be the 'default' in one sense, but I believe you are arguing for 'default' at a higher level than that.

> I don't think anyone who ever first came across Vim could even figure out how to quit, let alone do anything useful. Seems to disqualify it as a useful default editor, don't you think?

It should be obvious by my above comments that I would say 'no', it doesn't disqualify it, but that's due to differing views on what properties should be used to determine what the default editor should be.

(I apologize for the late reply, I know this is a couple days old now, but I didn't see the response till now.)

That philosophy might make sense on enthusiast Linux distros, but not on macOS, or some pragmatic Linux flavour.

Doesn't git just use whatever your EDITOR is by default? So either it's your own fault for configuring it to vim, or your distro for having such a newbie-unfriendly editor as the default.

https://stackoverflow.com/questions/30024353/how-to-use-visu...

My "distro" is MacOS... I'm sure there's a way to change the default, but now I don't have to google "how to quit vim" that often anymore, so I haven't bothered.

In case it needs to be said... you can count on vi being installed on almost any unixy distribution, which is not true of nano, pico, emacs or other common visual editors. On many contemporary systems, 'vi' is an alias for 'vim' and there you go.

You can change the editor Git uses by editing git configuration or setting the shell variables $VISUAL or $EDITOR [1]

e.g.

    EDITOR="bbedit --wait --resume" git rebase -i 5f882cfdec^

[1] https://git-scm.com/book/ms/v2/Customizing-Git-Git-Configura...

Arcane and obsolete Unix systems aside - which the vast majority of users don't have to care about, or even know that they exist - what modern Unix-like does not include nano out of the box?

Can't answer that myself, but because vi is part of the POSIX standard, the Git folks don't have to worry about it either.

many would argue git is also an "arcane console app".

many would also argue they are two of the best tools in all of software development.

agreed. I use git every day and I still have to Google how to do anything that I haven't done in the last week, which is probably 98% of the total number of commands.

I took the plunge and got Fork, a Git UI, a few weeks ago. It's actually starting to make sense now. Sort of.

it seems neovim doesn't support `-y`.

prank? you just made my life easy

:q!:q!:q!

And it's still hard to exit.

Reply on news.ycombinator.com