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.
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.
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:
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.
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.
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.
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.
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
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.)
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.
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.
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.
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.
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.
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.
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
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.
> 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.
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.
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!
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 :)
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.
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.
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.
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.
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.
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...
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?"
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
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. :)
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 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 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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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"
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.
> 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.
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 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.
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
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
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.
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.
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.
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.
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
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 './'
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!
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.
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.
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.
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^
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?
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.)
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.
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.
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.
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