Duplication when using entry editor

[sambo57u]

This is 4.1dev Oct.25 on Linux x86_64 with java 1.8.0_152.

1. Open a bib file
2. Double clck on an entry so that the source editor window opens up
3. Click into the editor source window
4. Then click onto one of the other bib entries shown in the table above the editor
5. The other entry is duplicated

I also had a problem with changes done via the source editor not being saved. It may be related to
above. Will investigate further.

[halirutan]

This is neat and it was an overlook by the reviewers (including myself) who approved the PR #3333 from @tobiasdiez. What happens is that on moving to a new entry we call bindToEntry which in turn creates a new source editor. This will call storeSource with the new entry here. The entry is already the new one but the code in the code area is the old one and it overwrites it.

It should be an easy fix and maybe the right time to review if the communication flow does really what we intend. What I would suggest is:

• if someone types into this field, the storeEntry method should be called after a tiny pause to make changes instantly visible if the code is correct
• switching tabs or moving to a different entry will ensure as well that modifications are reflected
• while typing, changes are only reflected when the parser says it's valid BibTeX code
• when switching tabs or moving to a different and the code is incorrect, we probably should send a warning instead of silently not saving the code

Currently, this does not work correctly. Making changes that invalidate the entry will be silently ignored when you switch tabs or entries.

[lenhard]

The source tab with its dependencies on the other tabs is always a problem... It would be good if this got fixed before we release 4.1.

Most of what you write seems reasonable, except for reflecting changes while a user is typing in the source tab. If we immediately store every character change (as was the case for some time during development between 3.8.2 and 4.0), then we really annoy all users who have autosave or a sync to a database enabled. I think it would be best if we store the contents every time the text area looses focus or the entry changes.

[Siedlerchr]

@lenhard didn't you implement the CoarseChangeFilter which only fires, if one leaves the field? Can't we re-use that here?

[halirutan]

@lenhard

If we immediately store every character change (as was the case for some time during development between 3.8.2 and 4.0), then we really annoy all users who have autosave or a sync to a database enabled.

I understand. I was just talking from experience with IDEA development where of course not each newly typed character triggers a sync with the lexer and parser. They have a very clever way of deferring this so that the user has a fluid typing experience. Nevertheless, the reparse is almost immediately available so that code correctness and highlighting can kick in.

There are additional flaws in the logic. One that I could identify is the following: Change something in the source editor and press Ctrl+S for saving the database. The changes from the source tab won't make it into the main table and won't be saved.

[lenhard]

I have implemented a quickfix for the problem described in the op's comment: #3360 The problem didn't come from the focus binding linked above, but from the binding that was triggered when an entry change happened. Essentially that binding is useless in the new structure, because the source tab gets the notification of an entry change via bindToEntry() anyway. So, I removed this binding. Also pushing around an entry is no longer needed, because there is now a currentEntry that can be used.

This gets rid of the critical issue of overriding the data of a different entry, but there are several other flaws still present in the source tab. Content in the source tab is not stored if you change it and save and quit or if you just move to a different entry. It is very easy to store the source for every character change, instead of binding to the focus property you just have to bind to the text property like this:

EasyBind.subscribe(codeArea.textProperty(), text -> {
      storeSource();
 });

The update might not be a problem, because as @Siedlerchr said if the listeners use the CoarseChangeFilter they will not immediately trigger an autosave. The problem is rather that the store operation will move the cursor to the end of the source tab. I could not find a quick solution, and really have to be doing something else now. I would be happy if someone else could look into this.

[tobiasdiez]

All the remaining issues should be fixed now with #3366