schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
I learned enough of vi (not Vim) in an hour or so from a coworker to get started after learning about Escape.
Then I read more documentation.
There are many powerful features in Vim, but you can easily forget about them if you do not use it every day.
Totally random thought: would I be able to do the Gilded Rose kata using only the ed text editor in a reasonable time?
Goals:
1) have fun,
2) look like a fool,
3) learn enough ed to later be able to script complex text changes across files,
4) also level up in sed and vim
Reason: ed(1) is the standard Unix text editor.
I was driving myself nuts wondering why my #vim was not installing plugins or setting up my keymaps. until I realized I forgot to setup the symlink to my .dotfiles
Recently started learning #morsecode , although it's completely useless to me. Sometimes it helps to understand why things developed like they did when you go back in time, when remote communication started. And I love having a #lowtech fallbacks.
It's like learning #ed in order to understand concepts of #vim.
The more I think about it, the more it seems to me that in this day and age with all the modern threats having a text editor that is capable to not only connect to the Internet, but also install some code packages from repositories (and probably do dependency resolving) is a recipe to catastrophe. Sooner or later.
It's probably one thing when you use a curated list of half a dozen addons that you can even personally peruse (or even contribute to). It's a whole other thing when you use some huge "distro" with probably hundreds of packages that also receive constant updates you cannot possibly control.
It's mostly about #Emacs, of course, but #vim is fully capable of it too. I won't even mention the likes of #VSCode.
We had a fair share of supply chain attacks in the recent years (npm, pip, even xz in some way). No reason to think no one's gonna use this channel of attack.
Maybe it's just my fibs. But there is some uneasy feeling about the fact that you edit, perhaps, extremely private, personal or sensitive texts while your editor runs some background code doing who knows what. It's one thing to trust people who wrote vim or Emacs and a whole other thing to trust a hundred other unknown parties at the same time.
Dumb #vim trick:
Have a bunch of files open in multiple windows and want to jump to the first (or last) line in all of them?
:windo 1
or
:windo $
and done.
If you use tabs instead of windows, you could use :tabdo instead.
or you can jump to the next instance of /pattern/ in all open windows/tabs with
:windo /pattern
:tabdo /pattern
or the first/last (assuming you have 'wrapscan' set) with
:windo $/firstpattern
:windo 1?lastpattern
I've been looking at the source code of #Microsoft 's new #edit tool after @bsletten mentioned it.
This comment saddens me:
https://github.com/microsoft/edit/blob/main/src/framebuffer.rs#L72
It's untrue in two ways.
First, #VIM, and its predecessors, very much *did* work this way, and have done since the 1980s.
It's how #ncurses works. Anything using ncurses works this way, and even most full-screen programs that just use termcap/terminfo directly do things this way.
It was an important thing to do back in the days of 9600 BPS terminals. If one didn't, one's full-screen program was painfully unusable. *Of course* programs did things this way.
Second, reading further down the code shows that the comment is exactly backwards. It is in fact Microsoft's new EDIT that writes the unnecessary stuff; lots of it, especially if your terminal window is a wide one.
Getting it to do limited updates (of less than entire screen lines at a time) is a to-do item:
https://github.com/microsoft/edit/blob/main/src/framebuffer.rs#L430
I need help again with #vim scripting.
For some particular files (you can probably guess it from the minimal example to reproduce the problem) I want to set swap directory (the vim directory setting) to a particular location.
So, I have a function:
function SetLocalSwapForRemoteFilesystems()
call mkdir("/tmp/swapfiles","p","0o700")
setlocal directory=/tmp/swapfiles//
echo "Swapdir: " . &directory
endfunction
which I call from autocommand:
autocmd BufRead * call SetLocalSwapForRemoteFilesystems()
The function is being called, as for any existing file being opened, I see the message:
Swapdir: /tmp/swapfiles//
but the swapfile is still created in the . directory, which is based on the original (default) version of swapfile setting.
I thought, that perhaps the swapfile location is being established before BufRead event, so I've tried to replace the autocommand with:
autocmd BufReadPre * call SetLocalSwapForRemoteFilesystems()
But right now my function is not even being called.
Any idea where is the problem and how to solve it?
Do you know why most sysadmins & experienced DevOps folks like to use #Vim ? It's because learning all of Vim's (A-Z) commands actually grants the user temporary telepathic abilities. You see it all the time. All hardcore Vim users, like those sysadmins, often seem to anticipate your needs before you even type them. They can practically fix server /cloud issues by editing text config files or deploy Ansible playbook before they even happen! Vim gives them superpower. I have spoken #unix #linux
It’s not meant to be exhaustive, just a practical guide to help get things done with a lighter touch.