|
|
[[!meta title="Moldable Emacs, a step towards sustainable software"]]
[[!meta copyright="Copyright © 2021 Andrea"]]
[[!inline pages="internal(2021/info/mold-nav)" raw="yes"]]
<!-- You can manually edit this file to update the abstract, add links, etc. --->
# Moldable Emacs, a step towards sustainable software
Andrea mailto:andrea-dev@hotmail.com - pronouns: he/him -- https://ag91.github.io
[[!inline pages="internal(2021/info/mold-schedule)" raw="yes"]]
We could learn about things better. Mountains of knowledge hide in
places we cannot access or use. The more we write down, the more it
takes to find and understand things we find useful.
Knowledge (web, software, books) keeps growing faster and faster! This
is not sustainable: we cannot keep up with it! What if we repeat the
error of somebody else, only because it would take too much reading to
know? What if that knowledge is in some code we work with everyday?
Moldable development is a paradigm shift that attempts to solve this
problem. In a gist, the tool you use should let you create special tools
to learn smartly from what you have already.
Since we use Emacs, let's make our great editor moldable!
This talk shows my progress in making Emacs closer to such a tool. We
are going to see how we can mold structured (and maybe even natural)
text to learn better, how we can inject notes in our projects and how
self documenting this tool is!
I aim to inspire you to find a quicker way to learn from our digital
world!
You can learn more about this at: <https://github.com/ag91/moldable-emacs>
# Discussion
IRC nick: `andrea
Pad:
- Q1: How to find a balance between «generic» molds that do not
provide specific enough info vs writing a new mold for every new
query/question?
- A: You can write molds that are private for your special
problem. I created molds for my work that I don't share: like
find the stories I am working on and how long time I spent on
tasks lately. Also, moldable-emacs is to make these tools easy
to write, so you should free to throw away tools when you need
them once only. If I believe a tool is a good start for many
other tools, I put them among the core molds, else if I use them
often I store them as contrib. If it is a one off, I throw it
away.
- Q2: How would you evaluate this workflow for package managemnt in
large independent codebases. Can one integrate it with code sematic
analyzers to make for a better work flow?
- A: moldable-emacs is about creating custom tools you can apply
to your situation. I started experimenting with molding NPM json
packages + security data from OWASP to view/display security
issues in my packages to my colleagues in the past.
moldable-emacs gives me the infrastructure to answer my question
about security, and I now started asking myself about
architecture coherence, so I have scaled up tree-sitter over
projects to check that modules don't use packages from other
modules. By that I mean that as long as your code semantic
analyzers output data, you can mold that (context) data to tell
your story (answer the question you have). Does this answer your
question?
- You answered it very well. I am also a security auditor for
multiple development teams. And I am incharge of code analysis
in an understaffed security team. So your usecase example got my
usecase spot on.
- Cool! For now you can define insecure patterns using tree-sitter
expressions (for example, I find a variable called "password"
in the code set to a string. For the package.json I linked to
OWASP API and looped through the packages using tree-sitter
tokens. I didn't get there, but I wanted to see an Org Mode
buffer with the list of the most vulnerable deps highlighted by
color + how to solve them: so I could pass them to developers to
resolve them (I am a dev, but sometimes others don't know about
security risks).
- Often molds are to tell stories to others.
- This is probably the most important thing for my personal
usecase. Thank you very much. Now it's my turn to learn it and
use it well.
- Please open issues or email me, and I will try to help if you
like how it works :)
- I'll do so.
IRC:
- cool...so essentially you are developing a text based version of Glamorous Toolkit.
- `andrea: yup, but only because I don't have good imaging in Emacs yet (but with tui.el...)
- your talk helped a lot with that though. I'd been seeing posts from you for a little while, but now I "get it"
- `andrea: yeah sorry, I am still building my vision: it may look I have been all over the place (image recognition, editing css, parse English lately), but the common thread is the easing of creation of micro tools that help me tell the stories I need
- I love your approach of mining other 'nuggets' from other contexts and bringing them to Emacs. I really look forward to looking in to your work and see if I can implement some of it. Thank you so much for your talk.
Links:
- Telling a story about code using buffer views <https://moldabledevelopment.com/>
# Outline
- 5-10 minutes: quick demo of moldable-emacs
<!--- 20 minutes: same as above but going more in depth for the vision of the package, how it fits with my code-compass talk of last year and some features
- 40 minutes: same as above and explanation of how you can extend the features available
-->
[[!inline pages="internal(2021/captions/mold)" raw="yes"]]
[[!inline pages="internal(2021/info/mold-nav)" raw="yes"]]
|
