[HN Gopher] Master Emacs in one year
___________________________________________________________________
Master Emacs in one year
Author : oumua_don17
Score : 119 points
Date : 2023-03-19 00:18 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| textread wrote:
| Since Steve Purcell loves new technologies and update his setup
| frequently, it may be a little harder to follow him for
| beginners. That's actually great. I'm lucky to stick
| to his setup because pulling from his git branch gets me
| updated with the latest cool things in community.
| When I say "on the shoulders of giants", I'm stressing that you
| need set your standard higher. I'm NOT saying the master's
| setup is "newbie friendly". If it happens to be "friendly",
| it's just the coincidence.
|
| I just perused through the tutorial. This is some horrible
| advice, IMHO.
|
| Also, cargo culting everybody to use the Evil mode for Vim
| bindings in Emacs is also probably bad advice, unless you are
| teaching emacs to a vim user.
|
| As a beginner, you are better off starting your emacs config from
| scratch.
|
| Some of the opinions of the author have been stated as facts:-
| ...every master uses the package smex to remember keybindings
|
| In my opinion, as of 2023, the best way to learn emacs the right
| way is through the textbook 'Mastering Emacs' by Mickey Petersen.
| Trust me, that book is well worth the price tag.
|
| Mickey walks you chapter by chapter, while you build your own
| emacs configuration as you learn new things.
|
| Once you have worked through that textbook, you will find it a
| piece of cake to study other people's configurations on github
| and learn more.
|
| If you are looking for motivation to learn emacs, watch the short
| 2 minute demo videos on the Youtube Channel @EmacsRocks
| avindroth wrote:
| Emacs from scratch is the way to go. Added abstractions are
| usually not good enough to completely replace fiddling around
| with vanilla Emacs.
| kickaha wrote:
| _In my opinion, as of 2023, the best way to learn emacs the
| right way is through the textbook 'Mastering Emacs' by Mickey
| Petersen. Trust me, that book is well worth the price tag._
|
| Strongly second this opinion!
|
| Mickey Petersen simply has no equal in explaining Emacs. His
| book and blog posts are a model of effective teaching, starting
| from zero. Yet somehow gently ceomprehensive. Hard recommend.
| akho wrote:
| The content here is that they've:
|
| - Done the built-in tutorial;
|
| - Picked up somebody else's Emacs and a few packages.
|
| That's two hours, maybe, if you go slow and have a few beers in
| the meantime. I wonder what they did for the rest of the year.
| deafpolygon wrote:
| Waste of time. Better off to master JavaScript and extend VS Code
| / Codium / et. al.
|
| At least the JS knowledge will carry over to something
| employable.
| G3rn0ti wrote:
| Well, that's a valid opinion and I am not telling anyone what
| tools to use.
|
| But as a senior I have seen many colleagues moving from one IDE
| du jour to the next and spending many hours of reconfiguring
| their tools while I just stuck to using Emacs all these years
| with a moderate shift of packages. I've been programming C,
| C++, Perl, JavaScript (and its various ECMA incarnations),
| React components, SQL and even Lua. Nowadays I am doing my
| terminal sessions from Emacs, too, and enjoy Tramp mode for
| tracing live bugs. Also, I started writing SQL change sets
| using org-mode which is really a killer for me now. Emacs is
| such a versatile programming tool and does not stop amazing me.
|
| VS Code looks so boring in comparison.
|
| Also my colleagues keep on whining about the CPU and memory
| consumption of their IDE that is quite large for, well,
| ultimately, text editing.
| precompute wrote:
| Writing functions in elisp is much easier than having to write
| JS for electron-based editors, and the elisp you write will
| usually work for a long time without being modified. Emacs is
| geared towards people that use it regularly, and its defaults
| hardly ever change.
| ColonelPhantom wrote:
| What makes it easier to write in ELisp compared to JS?
|
| Also, other text editors got on the 'real programming
| language' train too, like Neovim with its support for Lua.
| There's also Lite XL which is almost fully written in Lua
| itself. Does ELisp still have a big advantage there?
| precompute wrote:
| Sure. Elisp is very well-integrated with the editor itself,
| because that's what emacs is written in. There are some
| primitive functions that written in C that everything
| builds on top of. This makes writing functions an extension
| of the text editing process itself. This is why it's truly
| _extensible_. You don 't get penalized for writing your own
| functions, they exist at the same rank as what emacs ships
| with.
|
| Writing functions in lua is fine, but nvim and the like
| still suffer from being _just_ text editors, and most
| things that interact with the operating system / syscalls
| or change/traverse the UI require quite a lot of legwork.
| In Emacs, this is all very easy. Depending on what you
| need, you can be perfectly satisfied with vim and a couple
| of plugins. However, after realizing how easy it was to
| write functions in elisp, I more or less moved all my text
| / file editing to Emacs, along with most batch functions.
|
| For example, here's a function to insert a formatted date
| in the current buffer: (defun timestamp ()
| "Insert string for the current time formatted like '2:34
| PM' or 1507121460" (interactive) (insert
| (format-time-string "[%02y-%02m-%02d %02H:%02M:%02S] ")))
|
| You'd have to consult the docs for writing this trivial
| function in literally any other text editor. In emacs, you
| can `C-h` for everything, and this program will always run
| properly, because you're using functions that are used by
| emacs internally.
|
| Chaining functions: (defun org-id-create-
| copy () "org-id-get-create and then org-id-copy"
| (interactive) (org-id-get-create) (org-id-copy))
|
| Utilizing inbuilt syntax for a major mode in your custom
| function: (defun org-delete-subtree ()
| "Delete the current subtree" (interactive)
| (let ((org-heading-text (nth 4 (org-heading-components))))
| (save-restriction (org-narrow-to-subtree)
| (kill-region (point-min) (point-max)) (widen)
| (kill-whole-line 1)) (message "Heading deleted :
| %s" org-heading-text)))
|
| Using recorded macros as functions: (fset
| 'throwtext-c "x\C-w\C-wGp") (fset
| 'kindle-clippings-to-org-macro (save-excursion
| (kmacro-lambda-form [?d ?d ?$ ?d ?% ?O ?\s-p escape ?d ?s
| ?b ?O ?* ? escape ?J ?o ?* ?* ? escape ?J ?j ?^ ?d ?w ?d
| ?w ?l ?v ?e ?~ ?I ?* ?* ?* ? escape ?w ?d ?w ?f ?| ?r
| return ?d ?w ?d ?w ?V ? ?\; ?c ?o ?n ?v ?e ?r ?t return ?j
| ?d ?d ?V ?\C-s ?f ?n] 0 "%d")))
|
| Capturing (copying / appending to a certain location,
| depending on your config / provided template) highlighted
| text from a PDF file opened in Emacs:
| (defun org-capture-pdf-c (action) "Capture the
| active region of the pdf-view buffer." (let* ((pdf-
| buf-name (plist-get org-capture-plist :original-buffer))
| (pdf-buf (get-buffer pdf-buf-name))) (if (buffer-
| live-p pdf-buf) (cond ((=
| action 1) (with-current-buffer pdf-buf
| (buffer-name))) ((= action 2)
| (with-current-buffer pdf-buf (buffer-
| file-name))) ((= action 3)
| (with-current-buffer pdf-buf (if (pdf-
| view-active-region-p) (car (pdf-view-
| active-region-text)) (ignore-errors
| (buffer-substring-no-properties (region-beginning) (region-
| end)))))) ((= action 4)
| (with-current-buffer pdf-buf (number-to-
| string (pdf-view-current-page))))) (user-error
| "Buffer %S not alive." pdf-buf-name))))
|
| Traversing text programmatically: (defun
| comments-skip-c () "Skips to the line after the
| next comment ends" (interactive) (search-
| forward-regexp comment-start-skip) (while (string-
| match comment-start-skip
| (buffer-substring (line-beginning-position) (line-end-
| position))) (forward-line)))
|
| Making windows larger by a ratio: (defun
| make-window-larger-c (&optional ratio) "Makes the
| current window larger or smaller. RATIO is the ratio
| used, default is 0.618. It switches the width before
| the height." (interactive) (save-excursion
| (let\* ((postv (if olivetti-mode
| (progn (olivetti-mode -1) t)
| nil)) (wwidth (window-width))
| (wheight (window-height)) (fwidth
| (frame-width)) (fheight (frame-height))
| (ratio (if ratio ratio 0.618))
| (fl/fheight (floor (\* ratio fheight)))
| (fl/fwidth (floor (\* ratio fwidth)))) (if
| (window-full-width-p) (if (window-full-
| height-p) (message "Nothing to resize.")
| (if (>= wheight fl/fheight) (if (>=
| wwidth fl/fwidth) (message
| "Nothing to resize.") (enlarge-
| window (- fl/fwidth wwidth) t))
| (enlarge-window (- fl/fheight wheight)))) (if
| (>= wwidth fl/fwidth) (if (>= wheight
| fl/fheight) (message "Nothing to
| resize.") (enlarge-window (- fl/fheight
| wheight))) (enlarge-window (- fl/fwidth
| wwidth) t))) (if postv (olivetti-mode 1)))))
|
| Querying a SQLite DB for entries and showing them in a
| selectable list; selected entry is copied to clipboard.
| (require 'sqlite3) (defun kill-new-from-global-
| paste-c () (interactive) (let ((mylist
| '())) (let* ((dbh (sqlite3-open
| "/home/user/.local/share/zeitgeist/activity.sqlite" sqlite-
| open-readonly)) (stmt (sqlite3-prepare dbh
| "select * from text order by id desc limit 500")))
| (while (= sqlite-row (sqlite3-step stmt))
| (cl-destructuring-bind (id text) (sqlite3-fetch stmt)
| (setq mylist (nconc mylist (list text)))))
| (sqlite3-finalize stmt) (sqlite3-close dbh))
| (kill-new (let* ((vertico-sort-function nil)
| (rlist (completing-read-multiple " " mylist))
| (rstr "")) (while (length> rlist 0)
| (setq rstr (concat rstr (pop rlist) "\n")))
| rstr))))
|
| EDIT: Oh, and changing the "face" (appearance) of text is
| also very easy. It's easy to make your own syntax
| highlighting rules or even highlight stuff according to a
| regex temporarily.
| mkl95 wrote:
| Becoming productive with Emacs should take you a couple of weeks.
| At least that's what it took my dumb 19 year old self back in the
| day. Mastering emacs? I don't think you should be expected to do
| such thing.
| User23 wrote:
| Back in my larval stage I adopted Emacs because it was
| considerably more "intuitive" than vi and wasn't a joke like
| pine. I found it suitable for writing C and xpilots[1] configs
| out of the box and went from there. It did help that I was
| mostly in a college CS lab so there were people to ask
| questions.
|
| [1] http://www.xpilot.org/about/
| BeFlatXIII wrote:
| > At least that's what it took my dumb 19-year-old self back in
| the day
|
| That's the one thing I miss about being a teen: few enough
| other options that I'd stick to things to mastery instead of
| giving up and reverting to the tools I already know once things
| hit my frustration threshold.
| adastra22 wrote:
| There is something fundamentally wrong with a UI/UX that takes a
| literal year to master. I can't think of a better argument
| against learning emacs than the title of this submission.
| diffeomorphism wrote:
| Nonsense. Just like with any software you can be perfectly
| productive in an afternoon but actual mastery takes time. For
| instance, for Microsoft Excel the title would probably be
| "Master Excel in two years"
| spindle wrote:
| I agree. But you should learn Emacs anyway, because mastering
| such a powerful tool, even if it takes a long time - and even
| if you don't really need it - is FUN!
| adastra22 wrote:
| I did and I regret it.
| djaouen wrote:
| I guess programming [1] isn't worth learning, then?
|
| [1] https://norvig.com/21-days.html
| adastra22 wrote:
| "UI/UX"
| omnicognate wrote:
| "Mastering" emacs (certainly any version of "mastering" it
| that takes a whole year) requires learning a programming
| language, elisp. This is because emacs isn't an editor.
| It's a language and environment for rapiy developing
| textual user interfaces (TUIs) and "customising" or
| "configuring" it _is_ programming. To just learn to operate
| it as a text editor certainly doesn 't take a year, but if
| that's the approach you're going to take I wouldn't
| recommend emacs. Use VS Code or a JetBrains IDE or whatever
| instead.
|
| The linked article isn't very good, BTW. If you're
| interested in actually mastering emacs, the book "Mastering
| Emacs" [1], whose author comments here regularly, is the
| place to start.
|
| [1] https://www.masteringemacs.org/
| illiarian wrote:
| > To just learn to operate it as a text editor certainly
| doesn't take a year, but if that's the approach you're
| going to take I wouldn't recommend emacs. Use VS Code or
| a JetBrains IDE or whatever instead
|
| The way this sentence is constructed, it makes VS Code
| and Jetbrains IDEs sound like just text editors :)
|
| In all seriousness though, for the vast majority of
| programmers Emacs (or vim for that matter) has no value
| compared to, say, Jetbrains IDEs. You need dozens of
| plugins and an unknown number lines of arcane
| configurations just to have a semblance of a small part
| of functionality that those IDEs have out of the box.
| omnicognate wrote:
| That certainly wasn't the intention of that sentence.
|
| Re "has no value" - wevs. It has massive value to _me_
| and to a community large enough to have continually
| supplied me with new and useful functionality and
| resources for 20 years, most of which have been spent
| using it _alongside_ either Visual Studio (not "Code")
| or a JetBrains IDE (mostly Rider, some PyCharm). You use
| whatever tools you like and I'll decide what tools have
| value to me.
| bigpeopleareold wrote:
| I think a programming language can be viewed as a UI and
| having a UX: - UI: It's a text based UI that is lazily
| evaluated (that is, there is always some compilation and/or
| execution to specifically run for the commands to execute.
| This UI would fit a certain model of computation, itself
| being a domain and use-case. - UX: The ergonomics of a
| programming language, like it's usefulness, accessibility
| of concepts, its surrounding toolchain, is part of the
| experience of using this interface to the computer. There
| is also talk even here on HN about PL features and their
| utility. That, to me, is a form of user experience.
|
| I say this because I think about a programming language's
| toolchain as the make-or-break aspect of its utility of a
| language. Can I interface with it well enough without
| anxiety or anger? :) But, these "lazily evaluated" tools I
| think form in an aggregate as a user interface to me.
| blahgeek wrote:
| It's a productivity tool. It also takes months or years to
| master a professional video editing software like Adobe
| Premier, or 3D graphics software like Blender. People take time
| to learn because it's worth it.
| adastra22 wrote:
| It's a text editor, mail reader, todo manager, etc. none of
| those things should take a year to master, even in aggregate.
| diffeomorphism wrote:
| Yep, exactly. So obviously that is not the case.
| textread wrote:
| Would you please show me a tool with a better UI/UX that can do
| all the things that emacs can do?
|
| Orgmode Magit Dired EXWM . . . this rabbit hole is an endless
| pursuit of higher and higher efficiency.
|
| BTW, the UI/UX is quite customizable with basic elisp fu, using
| say Helm, Ivy etc.
| adastra22 wrote:
| For code editing, pick your IDE. For mail reading, pick your
| mail reader. For todo, pick your favorite todo app. They're
| all better UI/UX.
| oldsecondhand wrote:
| I prefer JEdit to Emacs for a programmable editor, but I
| mostly just use IntelliJ anyway. JEdit carries the philosophy
| of Emacs, but the UI isn't stuck in the 70s.
| raverbashing wrote:
| Yeah, do they really think "learn in one year" is a compliment?
|
| Interesting how they claim it's compatible with vim was an
| advantage, oh well but aren't you trying to get me away from
| it? Sure it's a "shorter learning curve" (if they somehow get
| rid of all the emacsism before getting to that mode and learn
| nobody has a "meta" key in their computer)
|
| I could learn a lot of more fulfilling things than emacs in a
| year. Guess I'll just stick with vim and vscode
| wolpoli wrote:
| I have read plenty of anecdotes on HN about people choosing the
| wrong platform. In my opinion, Emacs displays characteristics
| of a wrong platform to invest time in.
|
| I know that Emacs is a very powerful and completely open-source
| platform, but I have questions about its long-term viability.
| It's not commonly introduced in CS programs/bootcamps so it'll
| lead to a declining market share, and its most powerful
| capabilities require knowledge of LISP, which is not a popular
| language.
|
| Time and energy spent learning Emacs is also non-transferable
| as it has a one-of-a kind shortcut/user interface. The student
| will be locked in to Emacs.
|
| Students should invest time learning VSCode instead. At least
| it'll be easy to switch to other products.
| gjvc wrote:
| Do you also give reviews of books you've never read?
|
| What was the last version of Emacs you've used?
|
| This is one of the most FUD-like posts I've read on this site
| in a long time.
| Koshkin wrote:
| > _questions about its long-term viability_
|
| I guess people have been having them for the last 47 years
| now.
| ParetoOptimal wrote:
| > but I have questions about its long-term viability.
|
| Emacs has existed 40 years, do you assume it'll just go away?
| [deleted]
| jb1991 wrote:
| > it has a one-of-a kind shortcut/user interface
|
| The system-wide OS keyboard shortcuts for basic text editing
| in macOS are the same as emacs. I discovered this
| accidentally and people wonder why I can navigate basic stuff
| on the mac so well and my answer is "I used emacs for many
| years."
| leobg wrote:
| Which shortcuts? You have a link to a list? I only know
| Cmd-left/right to skip words. But anything more fancy?
| jb1991 wrote:
| if you are using left/right arrow keys, that is _not_
| emacs. Control with F, B, A, E, K, etc are the ones I 'm
| talking about.
| leobg wrote:
| Ok. Interesting. Where on macOS can I use these for
| navigating inside text? If I'm inside Textmate, for
| instance, typing F just... well, types an F. And it would
| seem to me that that's the case anywhere on macOS where
| there is a cursor, no?
| jb1991 wrote:
| anywhere you type text -- right now, while I'm typing
| this, or in a browser address bar, command line, anywhere
| the keyboard is functional and doing something with text
|
| You have to use Control with it, of course. F by itself
| is... F.
|
| if you swap caps lock with Control as most developers do,
| then it's a nice, simple, ergonomic addition.
| wolpoli wrote:
| Thanks! I was not aware of that.
| mvdwoord wrote:
| GNU readline is also all over the place and has emacs
| like keybindings.
|
| https://tiswww.case.edu/php/chet/readline/rltop.html
| gjvc wrote:
| You'd do well to start here
| https://en.wikipedia.org/wiki/Emacs and stop regurgitating
| half-understood opinions of others.
| shakow wrote:
| > It's not commonly introduced in CS programs/bootcamps so
| it'll lead to a declining market share
|
| Bootcamp a few years ago would have made me an expert in
| coding in Ruby/RoR under Atom with Ember.js; man, am I ready
| for those market shares!
| Barrin92 wrote:
| the best predictor of something's future lifespan is its past
| lifespan. Emacs has been around for 50 years, the likelihood
| that it's going to vanish is much smaller than whatever is
| new on the scene. You can fill an entire graveyard with
| bootcamp fads.
|
| And being locked into Emacs isn't really an issue because it
| does everything. It's like saying you're locked into the
| dotnet ecosystem. I mean, so what?
|
| And an important thing to note is that you may be locked into
| Emacs, but with every other tool you're locked out. What is
| there to learn about something like VSCode? You click on the
| marketplace and install extensions. Emacs might teach you
| things that aren't transferable (which I'd also question),
| but at least it's teaching you something.
| BeFlatXIII wrote:
| Why stick to what's popular? A larger ecosystem doesn't mean
| anything there is actually any better--or at least the better
| parts aren't guaranteed to be discoverable.
| u801e wrote:
| > There is something fundamentally wrong with a UI/UX that
| takes a literal year to master.
|
| You can learn basic navigation in about 5 to 10 minutes reading
| through emac's built in tutorial. Mastering it means finding a
| configuration that works for you, or writing your own
| implementation.
|
| I don't use emacs regularly (other than as an info page
| browser), but I have been using vim for the last 20 years and
| am still learning new things about it.
| Iridescent_ wrote:
| I would not imagine mastering VSCode or any Jetbrains suite
| product to take any less time.
| jb1991 wrote:
| This. Jetbrains is also awesome but you don't just pick it up
| and msater it in short time.
| otabdeveloper4 wrote:
| In reality, Emacs has the gentlest UI/UX of any Unix tool.
| Emacs has tutorials built-in, is 100 percent documented and all
| of the moving bits and pieces are discoverable.
| ParetoOptimal wrote:
| The problem is people don't use it's disoverability or built-
| in help.
|
| They do a web search that quickly gives bad to poor advice.
| posed wrote:
| I've been using vim for 3-4 years now, and I'm very comfortable
| in the vim ecosystem. Trying out emacs has been in my mind for a
| while, but I'm not sure if it's worth the time investment.
| phazy wrote:
| I've also been using vim for ~3yrs now, editing small
| programming projects and all kinds of text in it (like config
| files). Never had a need for emacs until a couple weeks ago I
| started working at a project involving a lot of meetings and
| writing a TeX report. I experienced that emacs, used in the
| auctex and org modes, is helping me a lot with that because the
| available commands simplify the workflow (like `reftex-
| citation`).
|
| Why has trying out emacs been on your mind, if I may ask? If
| it's just for fun, go ahead. If it's because you think aspects
| of your workflow could be optimized, take a look at the several
| modes emacs has to offer. Otherwise, I would just stay with
| vim, tbh.
| sph wrote:
| I moved to emacs (with its own keybindings) after using vim for
| a decade.
|
| Learning something new and very different to what you are used
| to is always worth the time investment. It doesn't mean you
| have to necessarily leave vim.
| ithrow wrote:
| You can just use it for note taking and as an outliner
| (orgmode) and keep using vim for programming.
| fsociety wrote:
| Start with Doom Emacs, you get sensible defaults out of the box
| and familiar vim bindings, but with all the emacs goodness
| chungy wrote:
| Once you go Emacs, you never go back.
| chongli wrote:
| I started on vim. Switched to emacs for a couple years, then
| switched back.
|
| The biggest issue with emacs for me is ergonomic. It relies
| way too much on the pinkie finger for everything and it gets
| really painful when you get RSI in your pinkie. It's fine if
| you're going slow and taking your time with things, but then
| why learn a complicated editor in the first place if you're
| just going to go slow?
|
| Yes, I tried evil mode for a while as well. The problem with
| that is that it's, well, evil. An unholy alliance of
| drastically different paradigms, the setup just becomes way
| too complicated. You lose the main advantage of emacs
| modelessness and are back to switching modes like vim, only
| now you also have all of the emacs key bindings to deal with.
| Why not just go back to vim and simplify your life? That's
| what I did!
| JonChesterfield wrote:
| It's really easy to use a different key for that. Pretty
| sure the keyboards it was written for had a different
| layout to today's off the shelf ones.
| G3rn0ti wrote:
| Well, if your pinky is such an issue why not bind ,,C-" to
| caps lock instead? I've heard many people doing that and be
| happy w/o the effort of learning the evil mode framework
| (which I wouldn't suggest beginners doing despite many
| prominent Emacs evangelists using evil).
| AugurCognito wrote:
| I have swapped "C-" key with "~". I can type all the
| "C-key" shortcuts with flat hand and it just feels right(at
| least to me).
| jmkr wrote:
| I used (and use) vim for over a decade.
|
| I've used emacs for probably over a year now.
|
| I'm glad I learned modal editing with vim, but with doom emacs
| there is nothing I miss from vim, except maybe `ctrl-p`,
| `projectile` isn't as good in certain cases, but it's good
| enough.
|
| In my opinion emacs is just better for everything, and if you
| know vim well enough doom will take 10 minutes to learn to use.
| Those 10 minutes are the install. Most vim commands will _just
| work_.
| SanderNL wrote:
| The focus on leaning on "giants" and not being creative is a bit
| too much for my taste.
|
| I kind of get it, but it feels off.
|
| "Those giants are more intelligent than me. They are harder
| working than me. How can I reach their level as quickly as
| possible?"
|
| Not by blindly copying everything I imagine, but I could be
| wrong.
| drichel wrote:
| "First, you copy the master. Then, you master the master"
|
| Can't find the source of the quote but it was about the Chinese
| approach to learning.
| SanderNL wrote:
| Yes, you copy it (do what they did). Not take photographs of
| their work.
| nsomaru wrote:
| To follow the path
|
| Look to the master
|
| Follow the master
|
| Walk with the master
|
| See through the master
|
| Become the master
| dkarl wrote:
| Copying the setup of an emacs guru sounds like a great idea to
| me. Think of it as using a Linux distro instead of building
| your own Linux from scratch. What turned me off of emacs as my
| daily driver, after using it from college through the first ten
| years of my career, was the large number of packages that came
| highly recommended by the community but which were half-baked
| or required debugging and subtle adjustments to coexist with
| other packages.
|
| When the author says:
|
| > Don't try to be "creative" at this stage.
|
| What he means by that is that if you try to configure emacs
| yourself, without yet being a master, half of the functionality
| you try to use will be broken, and you'll spend countless hours
| reading code and figuring out how to fix your broken setup.
| This is the traditional way to master emacs: by going back and
| forth between writing your own modifications and struggling to
| incorporate other people's code. Tackle every challenge head-
| on, and solve them one by one to make emacs do what you need.
| The daily effort to do turns you into an emacs master, like
| turning the wheel of pain turned the boy Conan into a 1970s
| bodybuilder.
|
| I don't think that's a wise or attractive route for new emacs
| users today. Nowadays, everything I could do in emacs I can do
| with other freely available software as well, and I have to ask
| myself whether it makes more sense to invest the time figuring
| out how to do it in emacs, or to install an easier and more
| polished special-purpose tool. When my workflow revolved
| entirely around emacs, it made sense to make the extra effort.
| But over time my workflow fragmented, until the extra effort
| never made sense, and my emacs setup stopped growing.
|
| Copying the setup of somebody who has already invest the time
| to get everything working together sounds like a nice
| compromise.
| precompute wrote:
| I doubt it'd take a year. Just remember, `C-h` is your friend,
| and there's no shame in using Doom / Spacemacs. Even if you're a
| vim devotee you can switch full-time to linux, thanks to `evil`.
| Emacs has a much better GUI than vim / gvim and related.
|
| Starting with vim keybinds, you can be very productive in just an
| afternoon, because `evil` is extremely comprehensive in mimicking
| vim. After that, you'd want to learn some elisp, and making small
| functions with the basic `let` and `interactive` forms will get
| you up to speed. A year is overkill. You can start being
| productive in emacs in less than a week.
| NelsonMinar wrote:
| Alternately, spend a weekend learning VS.Code and get on with
| doing real work.
|
| (I spent 20+ years with emacs, including writing one of the first
| popular HTML modes in 1993. We have better tools now!)
| Koshkin wrote:
| Often, I enjoy running emacs (and vim) in a terminal. (And, by
| the way, as we all know, "VSCode" stands for "Eight Gigabytes
| And Constantly Swapping.")
| dkarl wrote:
| I use VSCode and Jupyter for writing code, but I always have
| emacs open for doing edits that would be time-consuming and
| onerous in VSCode, Jupyter, or my rich database client. I feel
| caught between the failure of text editors to become rich
| tools, and the failure of rich tools to become good text
| editors.
| thiht wrote:
| More like 5 minutes. Install the extensions for your
| programming languages and frameworks of choice (who
| conveniently embed LSP), learn Cmd+Maj+P to get the global
| command palette, and start working.
| d0mine wrote:
| "real work" "better tools"
|
| Data point: I do real work in emacs (people pay me money for
| it). I haven't written any major emacs modes (use-package
| desired-feature) is it for me. I've looked at vs code (to get
| personal experience e.g., gitlens is nice though I mostly use
| magit plus several "feature" packages). Emacs is much better
| tool for me: I have an order of magnitude more notes than
| corresponding code (org-mode is life changing), say, 300 lines
| of notes per 30 lines of code.
|
| I have many of my colleagues use vs code--expectedly, I don't
| see the "betterness." Ultimately, I don't care what tools do
| you use as long as the results are acceptable.
|
| Though, I don't understand why someone would use less powerful
| tools long-term. Given your 20+ years experience, it is
| interesting to see some specific examples.
| Ferret7446 wrote:
| If you spent 20+ years with Emacs, you should probably know to
| not compare it with VS Code. Emacs is more comparable to Bash
| than IDEs.
| guidoism wrote:
| The Paul Nordstrom comment is so funny to me. I joined his team
| in (I think) late 2000 to build the distributed system that moved
| Amazon from the single (massive) monolithic binary. I was using
| vi at the time and I could see him physically cringe when he
| stood over my shoulders watching me move through code. It's like
| he was in pain.
|
| He told me (a 23-year-old) to pick an editor and learn it well.
| He said vi was fine but he didn't know it well and couldn't
| really help me. But if I wanted to learn Emacs he would help me.
| So, he brought me up to speed. He sat behind me and helped me
| through the basics. He helped me set up a usable .emacs file.
| When we would sit at his desk he would tell me what he was doing
| with Emacs so I could see how a ninja would do things.
|
| 23 years later I still use Emacs and I am still learning new
| things.
|
| It's people like Paul that really make a difference for junior
| engineers.
| rbc wrote:
| I'm not sure I agree with the necessity of mastering Emacs, or
| specifying a time frame for getting it done as the title of the
| article implies. I've used Emacs alongside of vi for editing
| since the 1990s. I'm no expert at using Emacs, but that's never
| really mattered to me.
|
| On the other hand Emacs is a key part of how I use computers. I
| read email, use the calendar, and edit text of all kinds. I use
| outline mode, and now Org mode to help organize and author text.
| I'm also a long time user of, and occasional author for info
| mode. I still tend to use vi for quick edits of line oriented
| text. For everything else I use Emacs.
|
| I'll suggest new users simply use the built-in tutorial to get
| started with GNU Emacs, and learn the new features as time goes
| by, and your needs change.
| anthk wrote:
| Emacs it's bearable with persp-mode. If you set the global
| keybind to C-c C-w (as it was with some former buffer manager)
| you'll find yourself using C-c -C-w b more than C-x b, because it
| will show you the isolated buffer per "pane" a la Screen/Tmux.
|
| You can use the first pane for editing, the second one for eww,
| another one for programming, one more for M-x calc (and the GNU
| info help page) and so on. Much better than cluttering your
| buffer list.
|
| C-c C-w s to create a new pane, and C-c C-w C to destroy it, and
| C-c C-w ? in order to get help. That's it.
| G3rn0ti wrote:
| I second ,,persp-mode.el" to be a great early addition to your
| default setup. I usually do that to separate front end from
| backend code or source files from remote terminals and/or error
| logs.
|
| Wherever I can I use default key bindings which actually helps
| me with remembering. In this case I stuck to ,,C-x x" as a
| prefix key combo.
|
| I would also suggest to first install ,,which-key.el" which
| will make Emacs display a list of possible key bindings from
| where from the key combo you just typed. This way hitting ,,C-x
| x" will give you a menu displaying all possible persp-mode
| actions and will become second nature.
| nurbl wrote:
| I find that with project.el (or projectile) buffer handling per
| repo works fine without having to separate things into frames.
| I often have hundreds of buffers open after a while and finding
| the right one is rarely a problem.
| dang wrote:
| Related:
|
| _Master Emacs in one year_ -
| https://news.ycombinator.com/item?id=16424934 - Feb 2018 (5
| comments)
|
| _Master Emacs in one year_ -
| https://news.ycombinator.com/item?id=8079083 - July 2014 (116
| comments)
___________________________________________________________________
(page generated 2023-03-19 23:02 UTC)