Excuse me but I don't think this is a good idea:

1. Regular folder names can start with a '$'
2. No clear use case
3. Bookmarks can already be changed through scripts AFAIK
4. Adds a bunch of new edge cases (folder with "$name" already exists) and complexity for questionable gain

Felix, I generally agree with your sentiment.  However, I do think there is some value here for your consideration.

Honestly, just support for a small subset like HOME and USER might be a good first step. I did this with qwe bash bookmarks app (https://github.com/olafurw/qwe), and now users can share a config file, which is very handy. I would suggest only support of UPPER_CASE variable names using brace expansion and a YAML escape back slash like so:

<bookmark href="file:///\${HOME}/Data/\${CURRENT_YEAR}"> ...

1. Conflicts with literal labels issue: Probably mitigated by escaped bash-style brace expansion.
2. Use Cases: 1. Users create config files that can be shared without modifications; 2. Developers can rely on static configs that do not need to be rewritten for every user; 3. Apps can abstract a greater number of default settings through a central default config expressed in $XDG_CONFIG_DIRS. 
3. Bookmarks can be changed via scripts :  yes, but this hard-codes configs and does not capture intent like environment variable expansion can. Rewriting is pretty much a hack to get around that intent isn't captured.
4. Cost vs. benefit: I defer to you on that. I did want to illustrate, however, that I do certainly see some benefit. Using the escape character might mitigate much of the risk. Admittedly, environment variable are often not set in various contexts, so perhaps just a very limited subset as discussed above would be a good start.

I hope that is useful.

(In reply to Michael Mikowski from comment #2)
> Felix, I generally agree with your sentiment.  However, I do think there is
> some value here for your consideration.
> 
> Honestly, just support for a small subset like HOME and USER might be a good
> first step. I did this with qwe bash bookmarks app
> (https://github.com/olafurw/qwe), and now users can share a config file,
> which is very handy.
[…]
> 2. Use Cases: 1. Users create config files that can be shared without
> modifications;

Excuse me if I have missed a detail here: Config files for what?

> 2. Developers can rely on static configs that do not need to
> be rewritten for every user;
> 3. Apps can abstract a greater number of
> default settings through a central default config expressed in
> $XDG_CONFIG_DIRS.

When I talk about use cases I generally have use cases of end-users in mind. I don't think we should add code that might or might not simplify the work of developers of other software. Otherwise we add complexity that should live with the software that needs that complexity.
I am sorry if I am being a bit dense here but I don't understand why software might rely on the links in the places panel in the first place. There is already a standard why to retrieve typical locations in Qt ( https://doc.qt.io/qt-6/qstandardpaths.html#StandardLocation-enum ). Why would any software read out the places panel links of users to capture an intent? That seems extremely non-portable. I might be totally missing your point though.

> 3. Bookmarks can be changed via scripts :  yes, but this hard-codes configs
> and does not capture intent like environment variable expansion can.
> Rewriting is pretty much a hack to get around that intent isn't captured.

I think it is fine. Again, I don't think most applications really need to mess with the places panel links in the first place. I believe you might have a different perspective than most users here because you are trying to improve the user experience of your application. But even then, I am not quite sure if this would enable software like yours to do new things or if this would merely simplify the implementation.

> 4. Cost vs. benefit: I defer to you on that. I did want to illustrate,
> however, that I do certainly see some benefit. Using the escape character
> might mitigate much of the risk. Admittedly, environment variable are often
> not set in various contexts, so perhaps just a very limited subset as
> discussed above would be a good start.

Well, for one thing, the code of the places panel is also shared with Gwenview's side bar and KDE's default file picker, so whatever functionality we add here affects a lot of other applications. This means that any more expert feature we add increases complexity even for applications that want to be extremely simple. On the other hand if we don't explain this feature to users somewhere, it generally might as well not exist because users will not know about it. So it is a bit of a damned if we explain and damned if we don't situation IMO. To me it seems like it would make more sense not to increase complexity of any of that unless there is a problem users can't solve otherwise.

Hi Felix: 

> Excuse me if I have missed a detail here: Config files for what?
I should have read the initial bug a little more closely. I incorrectly assumed that places were read from a config file dropped in ~/.config. However, on closer examination, I see this is found in `~/.local/share/user-places.xbel`. My interest was in seeing variable expansion generally supported for YAML-like KDE config files using a single shared read-write library.  

I agree that the additional abstraction for this specific file is almost certainly not worth it. Sorry for the misunderstanding.

>I agree that the additional abstraction for this specific file is almost certainly not worth it. Sorry for the misunderstanding.

At least I know have a second opinion on this bug report, that also agrees that it is most likely not a good idea if we implement the suggested feature as it stands. ^^ I'll resolve this as intentional then.