buffer-file-name can return propertized text?

Question

Once upon a time I was surprised to see buffer-file-name sometimes return propertized text like #("/tmp/foo" 1 4 (face flx-highlight-face)) instead of "/tmp/foo".

I got in the habit of defensively "cleansing" when I need the filename as a simple string, e.g.:

(and (buffer-file-name)
     (substring-no-properties (buffer-file-name)))

---

Thinking about this more recently, the flx-highlight-face suggests this might (?) be a little bug in flx-ido-mode -- maybe it ought to strip the properties?

One tiny question is, should I report this as a bug? I think I can self-answer: Yes; worst case they can explain why I'm wrong. :)

My real question is: How broadly do I need to keep this in mind? Is buffer-file-name just one of many Emacs functions like this? Every time I think "string", should I slap myself and say hey, never assume an Emacs Lisp string is "simple", it could always have properties?

Answer 1

Report it as a bug: M-x report-emacs-bug. Emacs-devel will let you know if they think it is not.

To report it you will need to anyway need to narrow it down - show a recipe to repro what you see.

Trying to come up with that minimal recipe you will find out where/how whatever code is propertizing the string. As comments to your question have indicated, that does not come from buffer-file-name itself.

The first step is to try to repro it when starting Emacs using emacs -Q (no init file).

---

To your broader question: No, you generally do not need to worry about unexpected propertization of strings. However, whenever text is picked up from a buffer you can expect to look out for it perhaps having text properties. That's why there are functions such as buffer-substring-no-properties: because it is so common for buffer text to have text properties.