What don't dired buffers have a (buffer-file-name)?

I guess this is a rhetorical question because I doubt anyone knows why but it turns out that dired buffers return nil for `buffer-file-name` instead of the path to the directory they are viewing. I believe this has cost me a ton of time but I did learn a lot along the way. [lsp-docker](https://github.com/emacs-lsp/lsp-docker) highest level function is `lsp-docker-start`. It calls `lsp-workspace-root` which calls `buffer-file-name` which, if starting from a dired buffer, returns nil so `lsp-workspace-root` returns nil and the LSP server is not started. This is my first venture into LSP mode and I was doing something slightly different, a basic low level function was returning nil, so I assumed I was way off track in my set up, and I needed to dig deeper. And, indeed, I came up with a [solution](https://emacs.stackexchange.com/a/74030/14815). I was documenting what I had found for myself so I wouldn't forget and started asking myself more questions. I went back and tested `lsp-workspace-root` in a file that had LSP mode enabled and it returned the proper path for the workspace. I then restarted everything, loaded `lsp-mode` but didn't start it, and went to the directory of the project. Sure enough, `lsp-workspace-root` returned nil (as it had before). I then looked at the code and started to try and follow it step by step. That's when I discovered that dired buffers have no `buffer-file-name`. I opened TAGS (an arbitrary file within the project) and now `lsp-workspace-root` returns the proper workspace. I **think** I could have set up my LSP stuff with a simple YAML file had I tried `lsp-docker-start` from a file rather than a dired buffer and saved the time spent coming up with the solution I pointed to. Anyhow... live and learn I guess.

I guess the answer to my question is because, from the implementation point of view, `dired` buffers are not editing or viewing a file. Rather they are editing or viewing the output of the `ls` or similar command. Damn that cost me a lot of time and frustration. Oh well... onward through the fog!!!

Correct. The `default-directory` variable has the path to the directory being viewed.

Yea. It is interesting that `default-directory` is a variable which implies its value can be changed. I bet that would confused a lot of things.

> I guess this is a rhetorical question because I doubt anyone knows why but it turns out that dired buffers return nil for buffer-file-name instead of the path to the directory they are viewing. Not all buffers in Emacs have an associated file, since not all buffers are visiting a file. You can treat buffer-file-name as a boolean value that tells you if a buffer is visiting a file or not. You still have default-directory, but be sure you calling it from the dired-buffer in question. > I believe this has cost me a ton of time but I did learn a lot along the way. Yes, unfortunately, sometimes we assume how things work, but it turns are a bit different :). Haven't bumped into this one, but I had my own assumptions that cost me time and experimenting. It is a good idea to read docs :). Now, I often check what the function does and what arguments mean when I use some functions, especially for the first time. Just to be sure.

It's often useful to temporarily let-bind it to something else, to make a snippet of code orient itself from a different directory.

If you want to be sure to receive a path instead of nil, for code that works in all buffers, you can call `(or (buffer-file-name) default-directory)`. Maybe that tip could go in the docstring for buffer-file-name.

[It already is in the docs](https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-File-Name.html). Also, you can use any symbol as a bollean variable to test if you have something or not. That is in the nature of Emacs Lisp; the fine consequence of nil acting as both null pointer and falsehood, and anything else as truth value.

I mean...a directory *isn't* a file! You can't, e.g., call read(2) or write(2) on it! I can see what you were thinking, but really, it shouldn't have been all *that* big of a revelation to discover that a directory isn't a file. :)

I believe you can actually. It is a file. It is specially formatted but I believe the original Unix allowed you to muck about with them as you pleased. It has an inode, data. It grows and shrinks just like a file. etc. This goes back to Dennis Ritchie's original Unix premise that "everything is a file". A disk is a file (e.g. /dev/hd0. memory is a file (e.g. /dev/mem0). etc. Maybe I'm daft but that's how I remember things.

You seem to be confusing default-directory for buffer-file-name in some cases. Also look into ibuffer if you want buffer file name and buffer name in a single ui.

Yes, *most* Unix-like filesystems *implement* directories via a sort of hidden file, but aside from some very old systems, you cannot actually *access* that file. And if you could, it would not be something you would actually want to edit directly! And not all filesystems implement things that way.

There's also `dired-directory` for some reason

I agree you don't want to :-) I recall someone's lame test around 1991 or so failed because they did a diff between two directories. The diff happily showed the differences. This was back before diff said "Binary files differ" but just did the diff as usual spewing out binary yuck. You could cat a directory. It was useless but you could do it. And, I wouldn't call it "hidden" at all. It was the file. I believe the original versions of opendir, et. al. were library routines -- not system calls. Indeed, search for opendir. It turns out as `opendir(3)` (library) not `opendir(2)` (system call). Anyhow... I'm going to get back to my toys...

Raise a bug report for `lsp-workspace-root` ?

(`C-h f` tells you the "some reason".)

[removed]