No way to escape keyword separator characters

[sauliusg]

JabRef version 5.0-dev (commit db96f88 master) on Ubuntu-16.04 x86_64

[x] I have tested the latest development version from * master db96f88 Fix problem with search and switching between libraries (#5326) from https://github.com/JabRef/jabref.git and the problem persists

Hierarchical keywords use '>' as a default "hierarchy delimiter", configurable as per keyword group. There seems to be, however, not way to escape that character if it is included in a keyword itself"

@Article{id3,
title = {Some title},
keywords = {human > languages, more-or-less \<\> values, interlinguistics},
}

In this example, the third '>' character is treated as herarchy separator, producing

> kwds
  > more-or-less \<\
    > values

instead of the intended

> kwds
  > more-or-less \<\ values

hierarchy.

Steps to reproduce the behavior:

1. Start JabRef
2. Load the test-keyword-groups.bib.txt library
3. Switch on the group interface.

A currently obvious workaround to change the default keyword separator character > to somthing else may not work if all characters are used in keyword values, and on may receive unexpected keywords when reading in external entries into the library.

The solution could be

• either introduce an escape character, could be backslash (\) by default, that could escape the special meaning of >;

• or use encoding of the > in a similar way how XML uses it, for example by setting special codes > and &amp to mean > and '&', respectively.

The same issue is of course valid to the comma (,) keyword separator character.

[sauliusg]

I could offer a PR in about a month's time...

[tobiasdiez]

Cool! I hope we developers find the time to discuss until then which of the solutions you propose is the best one.

You can also try to use latex command such as $\geq$ as the escape mechanism.

[sauliusg]

Great! Pls. keep me posted about the discussions. I'll think about your suggestions and I guess I can offer some thoughts on the pros/contras of each approach...

It would be good to agree on the idea which approach JabRef should follow since implementing each of them takes some work.

[koppor]

+1 for escaping. This feels most natural.

[github-actions]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!