lispy VS melpa

Some killer features in Emacs, which I would recommend checking out, is imenu and movement by s-expression (functions like forward-sexp). These are built into Emacs and make navigating across or inside blocks of code very easy. I have also seen that lispy, which is usually used for Lisp code also supports Python. Again I can't speak to any specifics about how well these things work for Python devs.

While writing other programming languages with LSP, it formats the buffer once I hit save. Is there any way to make https://github.com/abo-abo/lispy do some equivalent behaviour?

Without any order magit, lispy and minions.

I don't know cider, but...I found lispy mode a revelation in making the easy, easier.

The level of interactivity in your emacs determines how easy trying emacs-lisp becomes. I suggest checking out https://github.com/abo-abo/lispy, it makes it easy to look up documentation (C-c 1 I believe) and evaluate S-expressions on the fly (keybinding is e). Also C-h f, C-h k, C-h v are always very helpful. Also check out helpful (the package), selectrum, marginalia, prescient, etc.

Emacs seems to attract quite a lot of people who want structural code editing. We now have * paredit * smartparens * evil-cleverparens * lispy * symex * combobulate (more?)

Obviously, we have packages like Paredit and Lispy, recently we got SymEx, but these are all for the Lisp family of languages, where syntactic redundancy is very high because of the homoiconicity.

Watch the new pull requests to melpa: https://github.com/melpa/melpa/pulls

(require 'package) (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t) (package-initialize) (package-install 'use-package) (use-package exec-path-from-shell :ensure t :config (exec-path-from-shell-initialize)))

MELPA is definitely the biggest package archive, probably mostly on account of the lower barrier to entry compared to GNU ELPA (maybe the difference would have been less pronounced if NonGNU ELPA had been there from the beginning, but one can only speculate). MELPA has its own requirements for packages, but indeed copyright assignment to the FSF is not one of them.

I would suggest to start at reading the manual first. Then I would recommend reading the Melpa guidance, even if you do not plan to contribute your package to Melpa, since it contains very useful info about linting, writing your code etc.

The mxtoolbox link checks for SMTP blacklisting.. People won't be able to send mail from host with the IP address 178.128.185.1(which is the melpa.org webserver, not their mailserver, so everything's fine there).

Xah asked for his packages to be removed from MELPA a while back: https://github.com/melpa/melpa/issues/7755

Observe that package.el compile files when they are installed, and they are not compiled in any particular order (actually whatever directory-files returns, which is what OS returns). So if you have multiple files that depend on each other, it is something to think of. There are also some guidelines on how to structure your project on Melpa.