F.el: Modern API for working with files and directories in Emacs | Hacker News Reader

F.el: Modern API for working with files and directories in Emacs

github.com

74 pointsmemorable29 comments

I loath these and related libraries. They promote a style that diverges from regular Emacs Lisp code that makes it hard to read if you are not familiar with the additional language, and on top of that frequently promote a wasteful and inefficient style (e.g. instead of searching a buffer it is converted into a string, split on newlines, filtered and then checked if the filtered list is nil). I've sent out numerous patches to remove these leftpad-esque dependencies from projects that often only make use of one or two functions, that more often than not are just alii for built-in functions. Of all these libraries dash has some kind of a legitimation, but all the rest I consider code smell and makes me question if using the package is even worth it.

Also note that (besides dash), emacs-devel decided against adding any of these packages to the ELPAs. This has made it harder to add a number of packages to NonGNU ELPA, but has been a good excuse to get rid of the dependencies. If anyone is looking for some good Elisp exercise consider sending a patch to replace f/s/... with built-in functionality.

In case dash/f/s/... provide functionality that is not available on older releases of Emacs that one still intends to support, consider using compat (https://elpa.gnu.org/packages/compat.html), a library that I have been developing that attempts to backport recent developments for older releases.

When it comes to f and s. Yes. Definitely, I do not want them and I do not need them.

I like dash because it gives me the convenience of threading macros and anaphoric functions. Are there options for those in compat/emacs standard?

Dash is weird because it is both a list library and and bundles macros. Conventional Emacs Lisp does not use anaphoric macros, and to my knowledge the ideomacy their usage is generally contested.

Threading macros and stuff like if-let & co. have been available for a while and are backported by compat.

Most of the time when I am just coding on my personal or small emacs lisp packages I really like the convenience of anaphoric functions.

I have never seen an example of if-let that made me understand it, but I see thread-first and thread-last, those may be useful.

Thanks!

> I have never seen an example of if-let that made me understand it, but I see thread-first and thread-last, those may be useful.

They are often useful when you have a computation that might fail at any step, sort of like with Maybe monads in Haskell. Eg. if I want to retrive a password from auth-source, it might be that no entry exists, or that the entry has no password entry. In that case I do:

    (if-let* ((auth (auth-source-search :host "domain.org"
                                        :create t))
              (func (plist-get (car auth) :secret))
              (pass (funcall func)))
        (use-to-login-to-some-service pass)
      (user-error "Cannot find password"))

Emacs has `thread-first' and `thread-last'.

What is an anaphoric function / macro? I've seen this term floating around and I don't know what it means!

Page 189 of Paul Graham's "On Lisp" [1] introduces for the first time such a function. At least that is what I remember, and also what Wiki [2] seems to say.

[1] http://ep.yimg.com/ty/cdn/paulgraham/onlisp.pdf

[2] https://en.wikipedia.org/wiki/Anaphoric_macro

Neither did I and so I searched for it and got prompted to post this offtopic reply (hopefully interesting for future debates on search engines.)

I looked for anaphoric functions elisp on both DDD and Google. I believe that DDD uses Bing so TL;DR: Bing is not good at searching stuff, only basic queries. After maybe a couple of years of DDD I intuitively knew that I would have had to ask that question to Google.

What is an anaphoric function and why would I want it?

If I remember correctly, these packages are the straw that broke the camel's back on creating NonGNU ELPA. emacs-devel decided against adding these libraries because they are non-idiomatic, and also because they would be polluting the namespace--I recall the emails specifically said that the s-* prefix would not be given up, as it is such a convenient one letter prefix.

NonGNU ELPA was created so that they can alias these packages to something else, and keep using them as dependencies, without giving up the prefixes f-* and s-*.

I used to love these libraries coming from a functional programming background, but with more emacs experience I find it hard to decide between using them or the idiomatic elisp.

My biggest problem with most of these libraries is the complete lack of care for efficiency, and some packages use more of these functions than builtins. eg. -map is identical to mapcar (a C primitive), but instead of defining it as a defalias, its defined as a defun that just calls mapcar on its args. Function calls, especially of bytecode, are very slow, so now instead of just a single primitive funcall, there's a second bytecode funcall that does nothing. this is done in a lot of places in dash and especially in s.el. plus, while the compiler will warn when mapcar is called for effect and advise using mapc, it doesn't know about -map, and ive seen it called for effect a lot.

PRs to correct these dependencies is a great idea, thanks for the tip!

f.el and friends are useful, and add a lot of value. But elisp's function naming is all over the place and that can make it harder than it needs to be to find what you're looking for. That is also why people turn to libraries like f.el.

Emacs 28 adds a builtin Elisp cheat sheet command that collates a lot of Emacs's elisp functions into neat categories along with examples and hyperlinks to the manual. So, if you don't want a third-party library like f, dash, or s, you can give it a try first:

I wrote about it here:

https://www.masteringemacs.org/article/emacs-builtin-elisp-c...

What makes an API modern? Almost all projects posted on HN say they are modern.

It doesn't really mean anything, it is just a modern thing to say when announcing a software project.

Emacs is 40-odd-plus years old, and so are many of the names of functions in it. As a result, they may not have intuitive or obvious names. Emacs also does not use namespaces. That makes discoverability even harder.

In f.el and so on, the functions are consistently named and prefixed with `f-'; this is indeed what makes it modern.

TIL that we can have around 26 modern APIs in emacs.

Faux-namespacing by convention looks appealing on first glance/in isolation, but I think it falls apart in the context of the overall emacs package ecosystem.

...and lightweight and small

"minimalist" (aka unfinished)

In this case, it is due to emacs having it's own way of modelling a lot of things for a long time. Modern only means "like the other API we tends to use elsewhere these days".

In this case, it seems to mean "what I'm used to"

"Modern" roughly means "familiar to someone born in the 21st century, and who has only ever seen computers with glossy, composited desktops".

Modern to me in that context means "recent." Good luck writing an ancient API today.

I like these libraries cause they add to emacs something that is missing more than the functionality, consistency. Even though I used to avoid dependencies and write my own little functions. Sadly I had to give up emacs after 3 years of wasting a lot of my time in elisp, before that i used vim for a decade. I still love both of these tools but I just don't have the time and energy to spare anymore for configuring, debugging and learning packages. The power that comes with emacs is amazing but I realized that it's also an incredible time sink and I would rather spend this time on other stuff like learning a new language. I am evaluating both VSCode and CLion atm as my next goto IDE, I can't say I'm excited with any of these but I guess I value opinionated tools with defaults that "just work" if they save me time.

There are a number of these 1-2 char libraries for working with common primitives in elisp -- I love them: https://github.com/neeasade/emacs.d/blob/055ddb2a2f442ee207e...

I prefer dired mode, it’s pretty easy to get a handle of https://ashok-khanna.medium.com/introduction-to-dired-mode-9...

This is an API, not a file manager. They're not really comparable.

Reply on news.ycombinator.com