I'd like to add a note: time can't be only measured in hours, days, etc. To learn Emacs enough to decide that's the way I'd like to interact and use my desktop it take a very little time, in around three month I start using Emacs as WM (EXWM), MUA (notmuch-emacs) in around two months with a "false start" on Mu4e, main docs solution, tramp, personal finance (ledger) etc
But the real point is: I do it when I like to do, as much as I like, in my free time. In other words I can start easily and grow as I wont and need, and this knowledge will survive for decades to came.
With commercial software you need to invest time (and money) before start, and after having reached a certain amount of knowledge you can't go further, you have to keep yourself up to date following upstream changes and you new knowledge have a very little value in the long run.
That distinction is important because too many people say "hey it took too much time to proficiently use FOSS" completely ignoring the big picture. Good time to learn FOSS is at school, when you have plenty of time and (in theory) you are willing to learn, after you get the benefit for the lifetime. Another good time is when you feel the need, in free time. You do not have to pay something in advance, you do not have "training", "diplomas" etc, you grow at your speed and desire, limitless.
That's the real matter, not how many hours.
How's that different from learning to how use FOSS? Except the money investment part.
On FOSS normally software offer many evolution paths, which means you have to learn few thing and you can start, using the software issue or desire arise and you learn new things in an ever grown knowledge that regularly pay off. Also standard terminology is normally used, for instance you never find FOSS project to invent terms like "BIA" (Cisco name for MAC address of a nic, "burn-in address") or "Enable mode", "write terminal" and things like that.
- major and minor modes,
- special, regular, mini and read-only buffers,
- frames,
- backup files,
- dired,
- mark and kill rings,
- hooks,
- the difference between C-x and M-x,
- mode line,
- registers
- and whatever else there is in emacs' configs, packages etc.
I dunno. Perhaps in emacs lingo "standard" means "no one uses these terms anymore"?
Consider a thing: commercial always say "start with us is quick", and they do their best for that. Unfortunately they omit an important fact: start it's quick, if you already came from commercial environment witch is the most common case right now, but all the rest is a pain. And we normally start once in our life, but we have the entire life to live...
"no one but few do something" for me is not a bad thing per se, consider how many dictatorship exists around the world or in witch conditions most human live around the Earth: do you prefer being in the center of Gaussian which means being a poor man fighting for some bad food just to keep up in some dictatorship or you prefer western welfare and the least bit of democracy we have?
vs.
> Also standard terminology is normally used, for instance you never find FOSS project to invent terms like "BIA" (Cisco name for MAC address of a nic, "burn-in address") or "Enable mode", "write terminal" and things like that.
This is called hipocrisy.
There's nothing "intuitive" about emacs terminology.
> There's nothing "intuitive" about emacs terminology. And so what? Emacs is an OS not a small single-purpose apps, did you expect to being able to learn it an a day clicking around? In my personal experience, as a hardcore vimmer for more than a decade, as someone who have used different OSes (casually born on Irix thanks to a present by a family friend, evolved on FreeBSD, RH/Fedora/Debian/Gentoo, Solaris, OpenSolaris, Ubuntu/NixOS) I have seen anywhere "non intuitive" terminology, and I'm still there...
What about slices instead of partition? What about /dev/ notation in various unices? What about pfexec vs su vs sudo vs pkexec vs ...?
Of course, there are "recent" FOSS project with a design that take inspiration from commercial products, simply because that's the way authors think/know even if the code is free, but original FOSS software are another story.
The documentation isn't really very good due to the arcane terminology that often contradicts modern de facto standards in naming things (frames, buffers, windows) so that's a real barrier.
Plus the ecosystem is full of half-baked treatises on the One True Way to set up your init file that don't really explain why they made their choices.
But you can easily get by in emacs with just the basics. Then you just add commands to your repertoire when you're ready.
(require 'package)
(setq package-enable-at-startup nil)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(package-initialize)
;; Bootstrap `use-package'
(unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package))
(org-babel-load-file (expand-file-name "~/.emacs.d/myinit.org"))
then you can put your configs in an org file. using `use-package` means I can just copy/paste the file to new emacs and all my packages are auto installed etc..
#+BEGIN_SRC emacs-lisp
(use-package command-log-mode
:ensure t)
#+END_SRC
also, i highly recommend package `which-key` - it displays what commands are available along with their keypress.I also have a basic (text only) init.el for when solely working in a Terminal environment.
My advice would be to perhaps start with just what is recommended to use Poet theme and then add what you need when you need it.
The way I see it, most time invested is not lost because emacs will probably be a part of my workflow for most of my life. I just got tired of getting proficient in yet another tool/editor, setting up various plugins and configs, only to have to do it all over again a few years later.
That said, I can see myself using other tools like VSCode when they're more appropriate.
Every three months I spend a couple of hours thinking about what works and doesn't and going through my .emacs.d to make it better.
Basically, constant attention with heavy upfront costs.