this post was submitted on 22 Nov 2023
4 points (100.0% liked)

Emacs

311 readers
1 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Rules

  1. Posts should be emacs related
  2. Be kind please
  3. Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

founded 1 year ago
MODERATORS
rglullis@communick.news
raphael@communick.news
4
How rewarding learning Elisp can be? (alien.top)
submitted 11 months ago by Fate_sc@alien.top to c/emacs@communick.news
43 comments fedilink hide all child comments
 

I'm a new emacs user and I've been using doom emacs for a while now and i'm willing to learn Elisp, but found out that it might not be as easy as it might seem at first, because as i found out, lisp is quite different from other programming languages that i'm used to, especially knowing that i'm not a programmer by any means and my programming knowledge is very little, not mentioning that elisp is pretty old so the learning resources might not be as much as other more popular programming languages

so my question is, Is it worth it?

like what is the level of mastery do i need to achieve to start implementing custom elisp in my configs to enhance my emacs experience?

and how exactly can i improve my emacs experience if i learned elisp?

in other words, how rewarding it would be

you are viewing a single comment's thread
view the rest of the comments
[–] Psionikus@alien.top 1 points 11 months ago (3 children)

It's pretty tiny compared to a lot of languages considering that most of what you use it for is working with Emacs, which has a small number of intrinsic types like buffers, windows, frames, text properties etc.

Compared to being the kind of person who reads use-package like JSON and treats it like a declaration language, you will be light years ahead at configuration if you just know lists, quoting, alists, plists, and writing functions. Users who don't go at least that far will be constantly shooting themselves in the foot and spending much more time with minor, novice level bugs that are completely obvious.

[–] deaddyfreddy@alien.top 1 points 11 months ago

Compared to being the kind of person who reads use-package like JSON and treats it like a declaration language, you will be light years ahead at configuration if you just know lists, quoting, alists, plists, and writing functions.

Hey, use-package user here. I switched from my half-baked NIH init framework with a bunch of functions and other stuff you're talking about, and never looked back.

My 1670kLoC config doesn't contain any definitions and mostly declarative. If I need to defun something (so, there's no package with similar functionality) - there's definitely time to start another package. I don't even need to publish it on MELPA, since installation from git sources hasn't been an issue since Quelpa appeared (like 10 years ago).

Users who don't go at least that far will be constantly shooting themselves in the foot and spending much more time with minor, novice level bugs that are completely obvious.

Debugging use-package forms is very easy if you know about macro expansion.

[–] need_a_nick@alien.top 1 points 11 months ago (1 children)

Do you have a good resource for learning this?

[–] Psionikus@alien.top 1 points 11 months ago

I'm making what I believe to be a better one.

The elisp manual is not bad. Between shortdocs and that, using the scratch buffer or ielm, it's pretty fast to get going. I would save an elisp buffer to a file at first. Scratch is ephemeral by default. Like anything, reinforcement and consistent effort go farther than having the perfect approach.

[–] invsblduck@alien.top 1 points 11 months ago

It's pretty tiny compared to a lot of languages

Correction: It's actually rather sprawling and one of the least "compact" languages. [1] Doesn't mean we shouldn't read and write it, though.

[1] See section 2, "Compactness and Orthogonality", in Chapter 4 of The Art of Unix Programming, by Eric Raymond (2003).