is "vi" worth learning in 2022?

"Is vi worth learning in 202*?"
Hell yes, it is!
Pick any random Unix-like operating system and vi is there. Not sure about ee/nano/whatnot.
"Ooh! But what if Karen is a newcomer to FreeBSD? She only understands ee/nano/whatnot."
Well, Karen should do some homework before attempting an install.
Come on, guys. Just add to the Handbook a starting section, something like: "New to FreeBSD? Read this first!"
Let this mention that there are some system commands that need a Karen to know and understand the basics of vi.
A must read, before install. With this, you gave a hungry Karen not only a fried fish, but also a fishing line, a hook and some bait. And the whole pond, full of fish.
Learning how to fish is Karen's job.
Merging files, visudo are the first that came to mind, I'm sure there are more.
Yes, vi is very well worth learning, anytime. But lazy minds will be just that. Lazy.
 
I came across a quote recently that I liked. It was something like Honesty without compassion is cruelty. It's something I try to keep in mind.
 
… add to the Handbook a starting section,

We already have the six-page Preface and (chapter one) the Introduction.

something like: "New to FreeBSD? Read this first!" … basics …

The existing Basics (chapter three) does already include the EDITOR variable, amongst others.

… lazy minds will be just that. Lazy.

SilverC3ll I know that you're not a lazy person. As a newcomer, please, how would you rank these five options?
  1. ee (easy editor) as a default
  2. a concise, newcomer-oriented wiki page explaining the value of setting a default EDITOR (and how to do so; three or four lines)
  3. expansion of the book of frequently asked questions
  4. a minor change to FreeBSD Handbook section 3.9 to exemplify easy editor instead of emacs
  5. expansion of section 3.10 to include not only the link to vi(1) but also a vi tutorial that must be read before attempting installation of FreeBSD
 
Is Vim a part of the base? I don't see any mention of vi. Give Karen a good hint, before attempting to install (and pester the forum with funny questions).
And stop twisting my words, you know exactly what I meant when I mentioned "Starting section". Dedicate a portion of that to vi basic usage.
That should be at the very top of anything. Quote me only when you have something sensitive and accurate to say. I have a bag full of nasty words for you, common sense and manners won't let me unpack it all, but please, don't tempt me.

*Edit: actually there is 1 (one) mention of vi. That won't teach anyone how to edit, save a file and then quit the editor.
Just wondering, how many hits that man page got this year. Yet here we go, asking whether vi is still worth learning or not.
 
I prefer vi(m) to editors that need Ctrl-X Ctrl-C etc or editors that fill lines of the screen with help text.

For those wanting to use more globally used keybinds for copy, paste, etc. there is an `mswin.vim` plugin for editors/vim that does provide so. 'Globally' as in human beings on this planet Earth using so in other cases.

https://github.com/vim/vim/blob/master/runtime/mswin.vim as well as on vimawesome.com

Existence of a file with the abbrevation of that on a FreeBSD or FOSS computer is subject to ethical debate.
 
fernandel thanks, that got a thumbs-up in Discord.

Does anyone know whether the FreeBSD-provided Vi/Ex Reference Manual, from 1997, is still an ideal manual? Or should there be priority to a similar, more modern manual?
 
We already have the six-page Preface and (chapter one) the Introduction.



The existing Basics (chapter three) does already include the EDITOR variable, amongst others.



SilverC3ll I know that you're not a lazy person. As a newcomer, please, how would you rank these five options?
  1. ee (easy editor) as a default
  2. a concise, newcomer-oriented wiki page explaining the value of setting a default EDITOR (and how to do so; three or four lines)
  3. expansion of the book of frequently asked questions
  4. a minor change to FreeBSD Handbook section 3.9 to exemplify easy editor instead of emacs
  5. expansion of section 3.10 to include not only the link to vi(1) but also a vi tutorial that must be read before attempting installation of FreeBSD
Thank you for your considerate words; I have no experience yet with ee and well, as "prosthetic" as this might sound, vi is not so much of a challenge when one is assisted effectively by AI, a luxury contemporary beginners have in their learning process and feels very much like having a personal mentor. I do think, of course, that what you suggest in point one and two is very reasonable: you will be managing the entire operating system by editing configuration files, and first offering a mastery of whatever default text editor makes a lot of sense; and offering explanations of a few alternative editors as well. Vi is of course a challenge; I am presently gaining experience in the easier nano and I would wonder why one would want a more difficult editor to be a default, unless the more challenging editor is indeed more effective. Of course, I seem to understand everyone in the UNIX community appreciates intelligence; it is indeed a culture of intelligence, and therefore I can understand that making some things easier might come across as almost culturally offensive, as if it "lamifies" the use of the operating system and ultimately opens the floodgates to a Windows-like userbase, harming the culture. I think when such developments are resisted, it is because we honour the culture of intelligence (laziness was already mentioned in this thread). And yet, it cannot be denied that no effective operating system will intentionally make itself difficult to use! An effective operating system is one that is easy, stable, and everything just works. This means that it is ultimately desired to find a balance between intelligence and ease of use, basically leading to an Ubuntu or Mint-like evolution where the elite and your proverbial not-so-erudite grandmother co-exist. The culture of intelligence becomes a choice the moment you choose to open the hood and remove the gui; but ease of use remains the main objective, from an open-source mentality not in terms of being competitive necessarily, but certainly accessible and being able to serve humanity's technological advancements from an ethical and humane perspective (e.g. avoiding Microsoft-like data-theft; Bill Gates needs not know what your girlfriend looks like).

As to point three, concerning the expansion of the FAQ, my experience with FreeBSD is not yet thorough enough to make any meaningful statement about it. Everything seems rather accessible, and I just noticed the "cool joke" ;-). Of course, being as thorough as possible is always appreciated.
I think as to point four and five, that my above statements have expressed my humble neophyte view: why choose a difficult editor over an easier editor, unless the more difficult editor is more effective or versatile? I think if I were a developer, I would have to look at what features configuration-file editing needs in a text editor. If an easier editor possesses all those features, then why use a more complicated one? Again, as mentioned above, this might be a choice unconsciously motivated out of culture rather than a choice of efficiency, should vi be elected over a more user-friendly editor. This potential proclivity, of course, can harm the progress of FreeBSD's public accessibility.

I'm an author and turned to FreeBSD in order to increase my privacy, not wanting my voice persecuted or activities monitored for having a view the establishment might disapprove of (feeling warned by Edward Snowden; sharing some of the views of J.B. Peterson and Elon Musk). Though I write about Oriental philosophy, I think my ability of seeing conceptual coherences and communicate them with a certain measure of skill, if humility would allow me to say such, will enable me to turn my note-taking in my progression as a semi-IT neophyte into a documentation that will ultimately read much like a "FreeBSD for Dummies", which I think is a type of communication that is presently lacking. Yes, I know, "- for Dummies" can be a bit of an oxymoron, because there is realistically no such thing as "Quantum Physics for Dummies", like so there is also no such thing as "FreeBSD for Dummies." However, the "for Dummies" approach simply means as little jargon is assumed as understood, and is avoided as much as possible, speaking the language of the uninitiated.

My approach will be this:
  1. Not assuming any prior knowledge of computers while introducing basic computing from a FreeBSD perspective;
  2. This will leave no epistemic gaps while thoroughly explaining the FreeBSD operating system;
  3. Gamify the content of each chapter and header via interactive quizzes such as via quizizz.com, basically creating a "Duolingo" for FreeBSD concepts and scenarios. Interactive learning while utilising a "punishment and reward" system addresses a primitive survival mechanism of our psyche that correlates success or failure with a primal life/death scenario (the most basic form of punishment and reward). This means the concepts taught in this manner become emotionally relevant to certain aspects of the psyche; information that is emotionally relevant is information that is retained;
  4. I will attain a BSD certificate in order to possess enough authenticity;
  5. The written work will be subject to scrupulous feedback from the community; if the general consensus is that I have failed, then I would accept that judgement;
  6. I will only compose this document after a minimum of three-year-use of the FreeBSD operating system;
  7. The document will be published for free; gratitude can be expressed financially by donating to the FreeBSD Foundation.
In terms of improving FreeBSD education, I think it would be great if the FreeBSD platform would offer shells that have certain problematic FreeBSD configurations; assisted by a relevant tutorial, the user is guided in solving the problem, explaining every concept along the way. I would personally further empower this by supporting each scenario with a quiz to test apprehension of utilised concepts.
A next step would be setting up shells for FreeBSD pentesting and vulnerability patching. I noticed there are many legal hacking challenges but, if a quick glance allowed me to see this correctly, they all seem to be centred mainly around Linux, and a bit of Windows.
These two approaches, problematic FreeBSD configurations and vulnerable configurations, will greatly enhance the FreeBSD learning process and will, in my view, allow FreeBSD to reach the greater public. It even becomes a fun puzzle and will appeal to the culture of intelligence. There are virtually no (interactive) courses for FreeBSD for as far I could see; though I'm presently following an excellent course by UrbanPenguin on Udemy. His is the only one I could find. I hope that that will change in the future. Not even the BSD certification platform of Ipi.org, if I understand correctly, offers any actual education.

EDIT: I suppose the shell solution could also be replaced by an image/iso solution: offering certain installation files that have a respective maintenance challenge preconfigured in them, serving as downloadable course-modules in a way.

Sincerely,

SilverC3ll​
 
I am presently gaining experience in the easier nano and I would wonder why one would want a more difficult editor to be a default, unless the more challenging editor is indeed more effective.
Why I recommend ee as default (of course, keeping vi in-tree) is because ee is already in base. Editors other than ed, ex/vi and ee/edit must be installed from ports/pkgs so no one can assume it's always installed. Default editor SHALL BE IN BASE BY DEFAULT (say, forcibly). So nano is out of consideration for now (until it is incorporated in base and forcibly installed).
Unfortunately, nano is licensed under GPLv3 and should never incorporated in base. Editors in base must be licensed under BSD-compatible license.
 
Why I recommend ee as default (of course, keeping vi in-tree) is because ee is already in base. Editors other than ed, ex/vi and ee/edit must be installed from ports/pkgs so no one can assume it's always installed.
There are basically two commonly used editors in this world. vi and emacs.

In many ways, I find it odd that we have ee in base and not an emacs.

My proposal for those who really dislike vi, is actually to follow OpenBSD's solution of adding mg(1) (a vi-sized emacs clone) to FreeBSD base and strip out ee (why was ee even added to base a while back, it is not so popular so its hard to find info on it).
 
There are basically two commonly used editors in this world. vi and emacs.

In many ways, I find it odd that we have ee in base and not an emacs.
Because emacs is licensed under GPLv3+, which is NOT BSD-compatible, it would never be incorporated into base.

My proposal for those who really dislike vi, is actually to follow OpenBSD's solution of adding mg(1) (a vi-sized emacs clone) to FreeBSD base and strip out ee (why was ee even added to base a while back, it is not so popular so its hard to find info on it).
editors/mg seems to be considerable, at least in terms of license (Public Domain).
But I cannot agree with axing ee, as it is used for a long time in FreeBSD.
It depends on how FreeBSD developers think (I'm not one of them), but if switching from ee to mg is decided, it would be done by the process below.

  1. Adding mg into src tree and connect to build on main (current) branch.​
  2. Propagate the switch on FreeBSD mailing lists.​
  3. Announce deprecation of ee.​
  4. At least one new stable branch, then, releng branch is created for new release which include the deprecation notice.​
  5. Actually axe ee on main branch, but NEVER MFC'ed.​
  6. New stablebranch, then, releng branch is created for new release which no longer include ee.​
This should be most quicker steps. Maybe more steps would be added.
 
Because emacs is licensed under GPLv3+, which is NOT BSD-compatible, it would never be incorporated into base.
Indeed. Hence mg (and ultimately nvi I suppose too).

That said, we do have some GPL in base. Still in the process of removing it all but its getting close.
OpenBSD actually has more GPL stuff in base. For FreeBSD I did actually spot a tiny trivial GPL program lingering that may have been overlooked but I can't for the life of me remember what it was (the program was only 2 letters I believe).

I feel "full fat" emacs would not be ideal for heaviness, as well as licensing.
 
Thanks, I meant, something more like a manual. (Like the 1997 manual.)
In the beginning I collected many editors/vim and vi(1) how-to's, booklets, manuals and cheatsheets. Wanted to learn it all, and now.

I hardly use them.

The magic of cooking text with these editors?

Learn the basics, eg. doing vimtutor[(1) and just USE IT. For every text task you have.

Then, you day by day, task by task look for possibilities that best suit you: seach the net and add it to your skills. Just the things you need more often than once. Train it, make your fingers remember. One new possibility until you master it. Or just scroll up the command history and reuse.

A reference manual can be handy lying next to your keyboard, stickies marking the things you more often use. But that's all. Reading 'Practical Vim' all 300 pages is useless, just as finishing the 1081 pages of 'UNIX Power Tools'. It's for reference, silly.
 
SilverC3ll to go back to your question, why vi, rather than nano---I don't use nano, so don't really know what is good and bad about it--one person who has an incredible amount of knowledge, that I know, prefers nano--but once familiar with vi, it makes it very easy to navigate around the file, or multiple files, without taking your hands off the keyboard. (I don't know if nano has that, it may for all I know). I So, if you're happy with nano, I don't know if there's a reason to change, but, if you're going for certification, it sounds like you're planning on looking for work in the IT field, so having at least a working acquaintance with vi is useful. As for a BSD certification, I don't know how valid it is, nor how useful in finding a job--a RedHat certification is probably the best for getting a Linux job, but getting into the pros and cons of a certification is a whole other bikeshed thread. https://bikeshed.com/

And this thread has already gotten enough off topic to leave that aspect alone.
 
That said, we do have some GPL in base. Still in the process of removing it all but its getting close.
Exactly. ;)
So we shouldn't add new BSD-incompatible licensed software into base.
I feel "full fat" emacs would not be ideal for heaviness, as well as licensing.
Agreed. If I recall correctly, the first time I've tried emacs installing via ports, its source tarball contained "sumo" in its filename, maybe because of its heaviness.:)

I've tried tried editors/mg and unfortunately it cannot display CJK characters, unlike ee does. It's important for Japanese like me and would be Chinese and Korean, too. If I understand correctly, ee just leaves displaying characters for underlying terminal, including vty with, for example, b16.fnt loaded, 8bit-through. This (no support for UTF-8 character) is surely descrived at the bottom of mg(1) and I've just confirmed UTF-8 multibytes characters are shown in \nnn form. Unless this is properly supported, ee(1) shouldn't be dropped even if mg(1) is merged into base. And this would better including how ~/.mg should be written with examples. Maybe I've overlooked something (especially function to show default configurations usable in ~/.mg).
 
Back
Top