Title as first element causes shell problems due to leading `--` about denote

[mankoff]

I note a comment here #361 (comment) says

I don't see a way around this. If you have a file "some-file@@20240505T111111.org", is "some-file" a title, a keyword or a signature? We could allow one of the component to drop its delimiter if it is in the first position, but this cannot be done for all components at the same time.

But it seems like you could determine what 'some-file' is from the variable denote-file-name-components-order. But even without that introspection, I think I'm asking if the feature suggested above, drop delimiter from first position, exists.

[mankoff]

And one more comment. in #332 all of the examples of title-first have no leading --. It makes me think I'm doing something wrong, but have not found mention of this in the manual.

[protesilaos]

From: Ken Mankoff ***@***.***> Date: Wed, 17 Jul 2024 22:24:53 -0700 I'd like to use this `(setq denote-file-name-components-order '(title signature keywords))` as my file name scheme. I note that if identifier is not included or not first, it adds `@@` as a field separator, but does not include this if it is the first field.

Indeed, the identifier gets a delimiter when it is not the first component. We did this to still make it possible to find it directly.

I suggest when `title` is the first field, it should also drop the `--` separator. Currently, files are named, for example, `--foo@@20240717T222108.org`, which is a problem for a lot of bash shell commands.

Does it work if you quote the file names? I guess it can still be tricky.

Is it possible to remove the leading `--` ?

We had discussed this during the development of this feature. I think it makes sense, though we have to consider how best to do it. What if someone wants the signature to be first: should it also drop its delimiter? And, if so, how do we disambiguate them in a scenario like this: SIGNATURE@@DATE.org TITLE@@DATE.org Inside of Emacs we can rely on the denote-file-name-components-order to determine the current preference, but even then we cannot know what the previous preference was and if any files were created using that one. For shell scripts, this get trickier because the file name alone does not tell us what the component is and then we need some other heuristic. I would personally be inclined to make it so that the TITLE is the one that can drop its delimiter, though I know there are people who would like the SIGNATURE to do that, to have Luhnmann-style name. Overall, I am open to ideas. If we can have an elegant solution, I am all for it.

…

-- Protesilaos Stavrou https://protesilaos.com

[mankoff]

Does it work if you quote the file names?

No. Both "bar" and 'bar' produce --bar.

we cannot know what the previous preference was and if any files were created using that one.

You stress the importance of never changing it enough that one option would be to leave it to the user to adjust files if they change order. Or provide a convenience function to assist in renaming. If the old and new orders are provided, I think this is trivial. If I'm missing something about the complexity here, I vote for adding support for only TITLE. Seems fairly elegant to me.

For shell scripts, this get trickier because the file name alone does not tell us what the component is and then we need some other heuristic.

I'm not even trying to do anything that complicated at the shell. Just grep fails.

[protesilaos]

From: Ken Mankoff ***@***.***> Date: Wed, 17 Jul 2024 22:59:39 -0700 > Does it work if you quote the file names? No. Both `"bar"` and `'bar'` produce `--bar`.

Indeed, I tested it now. For relative paths, the "./" prefix seems to work: $ grep -E "test" ./--testing-the-merge@@20240626T212048__denote_hello_one_testing.org

> we cannot know what the previous preference was and if any files were > created using that one. You stress the importance of never changing it enough that one option would be to leave it to the user to adjust files if they change order. Or provide a convenience function to assist in renaming. If the old and new orders are provided, I think this is trivial. If I'm missing something about the complexity here, I vote for adding support for only TITLE. Seems fairly elegant to me.

One thing I forgot to mention is how all this affects the Denote functions that read the file name to find the relevant component. Whatever decision we make here will need to be reflected there, so hopefully we do not make it too complex.

> For shell scripts, this get trickier because the file name alone does > not tell us what the component is and then we need some other > heuristic. I'm not even trying to do anything that complicated at the shell. Just `grep` fails.

Hopefull the "./" is an option for you. Otherwise, you have to rely on absolute file system paths.

…

-- Protesilaos Stavrou https://protesilaos.com

[mankoff]

Does it work if you quote the file names?

I (obviously) misunderstood the question. I tried to quote the title when creating the note, not the filename when accessing. Yes, most (all?) bash commands have options to work with leading `-`. Either a `\` or `--` to denote end-of-args, quotes, leading path elements, etc.

One thing I forgot to mention is how all this affects the Denote functions that read the file name to find the relevant component. Whatever decision we make here will need to be reflected there, so hopefully we do not make it too complex.

Yes. I mostly work in Emacs where this is only an aesthetic issue. It just seems... inelegant to see the leading `--` a dired listing and elsewhere in emacs, and adds complication elsewhere outside of emacs. But it does work as-is. It's very good software. Thank you.