Parsing entry with unbalanced braces doesn't show error message

[AEgit]

JabRef 3.8.2
windows 10 10.0 amd64
Java 1.8.0_121

I think this is not actually a bug (although I'm not sure), but I just wanted to report it as a reference in case someone comes across this problem.

Steps to reproduce:

1. Add the following entry to your JabRef database:

@Article{Redding2006,
  author   = {Redding, David W. and Mooers, Arne {\O}.},
  title    = {{Incorporating {evolutionary} {measures} into {conservation} {prioritization}}},
  journal  = {Conservation Biology},
  year     = {2006},
  volume   = {20},
  pages    = {1670--1678},
}

2. Check the entry in the entry preview. It is correctly displayed as:

Redding, D. W. & Mooers, A. Ø. Incorporating evolutionary measures into conservation prioritization Conservation Biology, 2006, 20, 1670-1678

3. Now change the special character of the second author's name. Change {\O}. to {\{O}}.. You end up with the following entry:

@Article{Redding2006,
  author   = {Redding, David W. and Mooers, Arne {\{O}}.},
  title    = {{Incorporating {evolutionary} {measures} into {conservation} {prioritization}}},
  journal  = {Conservation Biology},
  year     = {2006},
  volume   = {20},
  pages    = {1670--1678},
}

4. Save the database and close JabRef.
5. Restart JabRef and reopen the database. The entry preview of the article is no longer correctly displayed. Instead, the following is shown:

Redding, D. W. & Mooers, A. Ø#.#.

Indeed, the BibTex source panel also shows just:

@Article{Redding2006,
author   = {Redding, David W. and Mooers, Arne {\{O}}.}

6. Close JabRef and open the bibtex file with a text editor of your choice. Search for Redding2006. As you can see, the article entry is still complete. Change the author's name back to {\O}. The entry should look again like this:

@Article{Redding2006,
  author   = {Redding, David W. and Mooers, Arne {\O}.},
  title    = {{Incorporating {evolutionary} {measures} into {conservation} {prioritization}}},
  journal  = {Conservation Biology},
  year     = {2006},
  volume   = {20},
  pages    = {1670--1678},
}

7. Restart JabRef and open the database. The entry is again correctly displayed.

It appears that using {\{O}} instead of {\O} causes issues with the entry preview of JabRef. As far as I can tell {\O} is the proper way of writing the respective character in Latex/BibTex (http://www.bibtex.org/SpecialSymbols/), but sometimes it is suggested to use the additional set of braces. While this works for many special characters, it does not in this case. I just wanted to point out this behaviour, but, as mentioned at the beginning, I don't think this is a bug with JabRef. In fact, JabRef is probably working as intended, as this wrong (?) special character is a user mistake.

[Siedlerchr]

It would be interesting to see if this is handled by the new Latex2Unicode lib as well.

[stefan-kolb]

Can you please try the most recent version from the master branch?

[AEgit]

Same behaviour with JabRef 4.0.0-dev--snapshot--2017-02-16--master--ebbeb1d24.
(I had to use the the jar version, as the exe threw some errors).

[koppor]

Could you post us the errors, please? ☺️ Am 17.02.2017 13:48 schrieb "AEgit" <notifications@github.com>:

…

Same behaviour with JabRef 4.0.0-dev--snapshot--2017-02- 16--master--ebbeb1d24. (I had to use the the jar version, as the exe threw some errors). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2561 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABTafvEO0lrDfm6oL8DNDpARuO-xUw5zks5rdZcHgaJpZM4MEAxG> .

[AEgit]

Yes, sorry - I was in a hurry and could not immediately upload it. Here the error messages.

[Siedlerchr]

The installer should be fixed in a couple of minutes. It was pointing to the old class name before rename

[AEgit]

Ok, the new exe works (JabRef 4.0.0-dev--snapshot--2017-02-17--master--62514b64b).

The behaviour, however, is still the same (as described above). But, as mentioned, I guess this behaviour is intended (?).

BTW: There are a couple of things, that don't seem to work in the current development version+there's a performance slowdown (which, however, might be just related to the things that don't work). I was just wondering, whether I should report these, or not, as you are currently actively developing and such things are therefore expected to happen. Or to put it another way: Is there going to be a stage, where you are relatively happy with the code, so that a sort of a beta phase can be entered, where users report issues with the new development version?

[stefan-kolb]

@AEgit Report everything that doesn't work.

[AEgit]

Ok, I'll do that ;)
Thanks again for your great work. It's probably better if I open new tickets for the problems I'm encountering with the new development version.

[tobiasdiez]

I think it is a problem with the parser. If I follow the steps above, after restarting JabRef I end up with Redding, David W. and Mooers, Arne {\{O}#.# in the author field and a damaged code in the biblatex source panel.

The problem, however, is kind of expected since \{ signifies an escaped brace and thus there are only one real opening but two closing brackets in {\{O}}. I would expect that JabRef gracefully reports this error on load. I will be so free and assign this to our leading parser expert.

Yes, please report all bugs and anything with performance degradation (except for groups).

[lenhard]

So what I take from this and #2552 is that we should throw errors more explicitly into the faces of users, right?

I guess this can be done, although I have to look at how exactly. And I won't make a promise regarding a timeline for a fix.

[lenhard]

Related #1212

Ok, I just had a look at this. I think we cannot really fix this. The problem is that this entry:

@Article{Redding2006,
  author   = {Redding, David W. and Mooers, Arne {\{O}}.},
  title    = {{Incorporating {evolutionary} {measures} into {conservation} {prioritization}}},
  journal  = {Conservation Biology},
  year     = {2006},
  volume   = {20},
  pages    = {1670--1678},
}

is read into the valid entry (based on bracing):

@Article{Redding2006,
  author   = {Redding, David W. and Mooers, Arne {\{O}.}

Everything outside is just comments according to the semantics of BibTex and is ignored until the next entry is found. If we modify this behavior during parsing, we are not following the semantics of BibTex. Hence, reporting an error on parsing is a non-option.

Rather, an error should be thrown (prefereably) when a field in the entry editor contains unmatched braces or (less prefereably) when trying to save the file.

[Siedlerchr]

When I recall it correctly there is already an integrity check triggered when you a) entered wrong braces, e..g the braces mismatch and you try to leave the field in the entry editor b) on save

[tobiasdiez]

This should be fixed in the latest development version. Could you please check the build from http://builds.jabref.org/master/. Thanks!

[AEgit]

Hmmm, I've tried the new version JabRef 4.0.0-dev--snapshot--2017-02-28--master--bf12dff24.

When trying to save the database with the proposed changes to the author name, the following error message is displayed:

Error: Braces don't match.

and the respective field is displayed in red.

This allows the user to correct the field and solves the problem.

Another issue arises, however, which is probably related to this solution. Say we want to capitalize some parts of our title. E.g.: Let's change the title from our initial example from

{Incorporating {evolutionary} {measures} into {conservation} {prioritization}}

to

{Incorporating evolutionary {Measures into Conservation Prioritization}}

This should work, but it gives us the same error message:

Error: Braces don't match.

This also happens, when the title contains contains {\O} and we want to capitalize certain parts of the title.

So I guess this issue still needs to be solved and should be kept open (?).

Thank you very much for your help!

[lenhard]

You are correct, Incorporating evolutionary {Measures into Conservation Prioritization} should not give a warning and I am surprised that it does. This needs to be covered in automatic tests and should be fixed.

[lenhard]

@AEgit Could you have a check with a version from here http://builds.jabref.org/braces-checking-followup/

This should hopefully fix the errors you reported above. Let me know if it works for you and if you notice any new errors with regards to braces checking :-)

[AEgit]

JabRef 4.0.0-dev--snapshot--2017-03-01--braces-checking-followup--488825af5

I've tried the new build and, as far as I can tell, it does indeed fix the reported issue. Something I noticed, however, is that saving the (huge) database takes now much longer than before (with 3.8.2. it was saved nearly instantaneously), especially when the entry preview is open. Indeed, the usage of the CPU suddenly spikes to nearly 100% and it takes several seconds for JabRef to save the database. In the meantime it behaves as if JabRef had crashed. Now, I can't say, whether this is related to the new fix or whether this was introduced earlier on in the development of version 4.

It could also have to with the current implementation of the groups in version 4, which is:
a) slower than the old one
b) does not allow to hide the number of entries (which might cause some performance issues on large databases)
c) cannot be opened with all subgroups expanded as default
d) displays group titles with underscore, e.g. "Alpha_taxonomy" as "Alpha_(t)axonomy", i. e. brackets are added to the first character following the underscore
e) does not offer the same options that were available with the old group panel, when rightclicking onto one of the groups

Having said all of this, I have to say, however, that, indeed, the new group panel does look much nicer, than the old one and that - once those issues are solved - I'm looking forward to the (potential) new capabilities of the new groups panel (e.g. #1904).

I did not report these issues so far, as the groups of version 4 are, as far as I understand, in active development. Therefore it is expected that some things won't work as they should, I guess.

Again, thank you very much for your quick help!

[lenhard]

@AEgit I have noticed the performance degradation in relation to groups as well and remarked it in group-related PRs, e.g. #2588 #2587 I use your bib file to test such things and that is a great help :-) I guess we will have to look into group performance and this will most likely defer the release of v4.0 by some time.

Since this issue is about the braces checking, I'll close it now. We will follow up on group related problems elsewhere.

[AEgit]

@lenhard : Glad to hear that my database is somewhat useful :D
Indeed, as the problem itself has been addressed, this issue can be closed. Thank you very much again for your help!

[tobiasdiez]

By the way, the degraded performance of the groups is kind of expected at the moment since the old code still runs in parallel to the new one...
@AEgit can you please open a new issue for the groups related things. Some old features are still missing but I wasn't aware of some of the problems you mentioned. Thanks!

[AEgit]

@tobiasdiez : Done, see #2599! Thank you very much for your help!