Can somebody give me a quick rundown on what the "#f()" syntax in Emacs-Lisp is doing?

user_4545535 0
Viewed 66

Today, as I was once again traipsing through the Emacs Manual, I got a little tired and decided to pop into the Org Mode manual for something a little lighter, and I was reading about link handling, and ended up reading (and rereading) the Help documentation for 'org-file-apps.

Well, when I peeked at the related variable 'org-file-apps-windowsnt, I was surprised to see some syntax in its value that I didn't recognise.

To be clear, I've read the elisp manual virtually cover-to-cover, so while it's not uncommon for me to not feel comfortable with a particular bit of syntax, it's fairly rare these days that I don't recognise it at all.

The syntax in question is in the following expression

((remote . emacs)
 (system . #f(compiled-function
          (file path)
          #<bytecode -0x47e8150df949387>))
 (t . #f(compiled-function
     (file path)
     #<bytecode -0x47e8150df949387>)))

Specifically, the #f() syntax.

I tried searching across my Info manuals in Emacs, but only came up with entries related to colour values (e.g., #FFFFFF for white), next I tried DDG and Google, but since all generalised search engines have decided that even something quoted is subject to fuzziness, I haven't turned up anything there.

So, yeah, I'm just hoping somebody can explain the #f() syntax in this bit of Emacs-Lisp code, and what it's doing, and maybe why it's used. I assume it must have something to do with the use of compiled bytecode, but beyond that I'm stumped.

Apologies for what is no doubt a basic question that I've simply forgotten from reading the elisp manual, but searching, including that manual, is getting me nowhere.

bytecode elisp syntax emacs
1 Answers

I submitted Emacs bug #55853 for this, asking that the f#(...) syntax be documented.

The bug was closed as "fixed" with this explanation. Apparently this is not Lisp-readable syntax but is instead intended to be for human consumption as "pretty-printed" output. I leave it to you whether you think it serves that purpose well. This is the bug-closure explanation:

It's from:

(cl-defmethod cl-print-object ((object compiled-function) stream)
  (unless stream (setq stream standard-output))
  ;; We use "#f(...)" rather than "#<...>" so that pp.el gives better results.
  (princ "#f(compiled-function " stream)

I.e., it's from the "pretty" version of prin1, and is not meant to be readable by the Lisp reader.

[Emacs maintainer Lars has] now mentioned this in the Special Read Syntax node in the lispref [he means the Elisp] manual in Emacs 28.2.

In other words, this is apparently "special read syntax", i.e., Lisp reader syntax that's not readable by the Lisp reader but is meant to communicate something to humans.

That description "explains the syntax" - the idea behind it. But it doesn't really tell you what the syntax is supposed to communicate to users, i.e., how to read it as a human.

I'd guess it's trying to be a placeholder, in this case, for a (compiled) function that takes arguments FILE and PATH.

What the source code for the function is; what the function does (e.g., it's doc); or where it's defined -- nothing like that is conveyed in the "pretty"-print. And whether "compiled" there means byte-compiled or "native"-compiled also isn't made clear.

Hopefully someone else may be able to add more light with another answer here. And perhaps the 18.2 doc will make things more clear.

user_7299070
Related