I think it's sort of possible in some cases, but not out of the box.
Spoiler alert : I did not write any code, sorry!
Roughly, when you're going to evaluate some lisp (e.g. from a buffer), three things happen:
- Reading, which converts the buffer content into Lisp objects
(Macro-expansion implies some evaluation, so it's not a clear
#() construction happens when reading, while the backtick construction is a macro which does most of its job during macro expansion.
So we could try to surround the string literal with a backtick-like macro that will evaluate things during its expansion phase. Unfortunately the existing backtick will not dissect a string (it will only dissect a list or a vector, see the function
backquote-process for more on this), so you would have to write the code yourself.
Another problem is that once a string literal was read, there's no guarantee that we can recover how properties were actually written within the literal. Consider the following:
#("foo" 0 3 (bar baz) 1 2 nil)
It is equivalent to:
#("foo" 0 1 (bar baz) 2 3 (bar baz))
How de we tell them apart ? We can't, they are
So now we already must impose conditions on what the string literal can contain, and even though this can be considered ok, it isn't super nice either.
Now let's look at another example:
#("foo" 0 2 (bar baz))
#("foo" 0 1 (bar baz) 1 2 (bar baz))
Again these two strings are
equal-including-properties, so again it's not guaranteed that we can tell them apart from elisp [Side note: the lisp reader does not seem to "simplify" the first version to the second version in my current emacs, but that's lightly tested and not future-proof.]
Of course we can pretend these problems do not exist, but if
baz is in fact code to be evaluated, that code might get evaluated once (first version) or twice (second version) depending on how we access the properties. Now that's pretty bad in my opinion.
Given the above, I now believe that implementing such a macro would be wasted effort.