Have them show their IDE's scripting environment and how they can quickly prototype an automation for something annoying without even going the distance to write a full plugin and then bind that automation to a key.

Then open org or something and show how you can write a version of Lispy for org outlines based on some predicates like org-at-heading-p.

Emacs is a programmable interface to a computer. While it is frequently used to program itself to program other things, it is a foundational bootstrap tool.

IDE's seek to present a set of features that fills that domain of work. You hit a ceiling in that world. With Emacs, you continue molding it to things you get value out of years and decades later, after that IDE went away when its most popular language or framework went into decline.

In the upcoming landscape of AI's with more well-defined type interfaces and symbolic representations, tools like Emacs will be at the forefront of composing these tools into the long tail of cottage industries of what will amount to a revolution in IP, programming, and human-computer interfaces.

Xenodium's Github repo for the dynamic module needs more stars and links so more people find it

I'll be collecting dynamic modules while deciding how to make a template for elisp repo kit (Rust).

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.

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.

Elisp manual. Helpful. Completions for variables, functions. Apropos.

I'm starting work on a video series called for Speedrunning Emacs in the "I want to hack everything in Elisp" sense. Emacs is a programmable interface to a computer, so my interpretation is that using Emacs and using Elisp are inseparable.

https://www.youtube.com/watch?v=QU30EZiHNQw

It's super new, so I'm recording right now and mainly covering things incidental to setting up casting for now and going over packages I've already published. Excited to get dug out of that hole and cover some of the things I want to.

Is this about Elisp threading or Emacs using threads to implement rendering and executing Elisp etc?

General is a package that really illuminates the tension that occurs when the user wants to integrate two packages. :after is okay for a quick solution, but for packages like general, you would end up with one ensured package implicitly depending on everything.

It's much less bad that you end up loading everything and much worse that the use-package declaration feels anything but modular or independent, instead incorporating symbols from all over Emacs and implicitly depending on other use-package hunks.

What is still a much deeper problem in my opinion is the lack of being able to superimpose and compose configuration. This is the reason why adopting random hunks of use-package declarations is not safe and why almost no two users can easily re-use large units of configuration.

The point is I like philosophy of Unix using like tmux + nvim + mutt .

Emacs is at least on the surface orthogonal to the Unix philosophy. It's a programmable interface to a computer. Instead of remixing a bunch of fixed tools using bash pipes and arguments, you do most of your lightweight automation and integrations in Emacs Lisp.

They're out of date, but it was a decent opinion before eat.

You want your primary interface to a computer to be a programmable programming environment, which provides extremely proficient interfaces for programming itself, as a force multiplier for automating things that require a varied composition of off-the-shelf and bootstrap-level integrations.

These days, prompting chat GPT is the way to go for generating small examples and asking about things with little background.

M-x elisp-index-search. The Elisp manual is not bad, almost pretty good. There's some examples in shortdocs, but I think shortdocs use case is dead because of generative AI's and will only get more dead.

Sometimes we write Elisp examples: https://github.com/positron-solutions/transient-showcase I have to update that because transient got some upgrades.

Use ielm and eval-last-sexp as well as eval-region.

Install the helpful package for useful commands like helpful-symbol.

I think once I got familiar with all of the various flavors of let binding and mapc and mapcar, even if what I was doing didn't seem like mind-blowing code, it also is pretty straightforward to read and write.

Now it should be pretty easy. You just need this configuration to avoid mispelling lambdas:

(defun pmx-greek-lambda ()
  (font-lock-add-keywords
   nil
   `(("\\"
      (0 (progn (compose-region (match-beginning 0) (match-end 0)
                                ,(make-char 'greek-iso8859-7 107))
                nil))))))

(add-hook 'emacs-lisp-mode-hook 'pmx-greek-lambda)
(add-hook 'inferior-emacs-lisp-mode-hook 'pmx-greek-lambda)