Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elisp high-priority #6

Open
4 of 8 tasks
psionic-k opened this issue Dec 5, 2022 · 2 comments
Open
4 of 8 tasks

Elisp high-priority #6

psionic-k opened this issue Dec 5, 2022 · 2 comments

Comments

@psionic-k
Copy link
Member

psionic-k commented Dec 5, 2022

Partial list of items being considered to focus on elisp IDE for Emacs and elisp-centric out-of-box experience:

  • Orderless completion at point via corfu with separator
  • Dabbrevvv
  • Rainbow delimiters with prism
  • Paredit Lispy
  • Fancy help transient
  • Shortdocs for most basic elisp Use GPT's
  • Scratch buffer upgrades, possibly favoring org literate guides as a basic way of life
  • De-emphasize non-elisp user workflows
@psionic-k
Copy link
Member Author

I'm more convinced by the lispy way at this point. Paredit just feels clunky. I still program half in file, half in repl, and I have paredit off when in repl because I don't get any extra indentation value out of it. Making syntactic structures part of the state of editing commands is definitely the right way.

Rainbown delimiters have not been super helpful except when hacking them to highlight certain structures. Probably a better job for tree sitter and variable vision modes depending on what we're doing. Otherwise, angry color spam is a real threat.

Shortdocs are good. Chat GPT (and of course successors that are quite inevitable and rapidly appearing) is filling a lot of gaps for finding type to type functions, or state to state like an ad-hoc Hoogle for Elisp.

Dashboard could use some org integration and project integration. Agenda isn't really my favorite org workflow, but I need to un-stall org-afterburner feature design to get to a better world.

The regular Emacs manual is a tremendous and horribly useless pain. Glossary is good. Elisp manual is ... kind of good, while retaining the mostly useless writing habits and lack of concrete Elisp expressions. Probably would be better if we just integrated it all with GPT summary and code snippet generation.

@psionic-k
Copy link
Member Author

Well, for de-emphasizing non-elisp workflows... It's really about non-sustainable workflows. For example, customize is good, but as it's frequently non-distributable, it's not sustainable.

Possibly do some content on speed-running Emacs and then consider how to work that in as an org-based manual and scratch area.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant