Additional check if values have changed in bindToEntry#6528
Conversation
|
Not yet mergeable, it's still in testing. I'm not sure if this really solved the problem. I'm waiting for @gianlucabaldassarre to answer in the issue thread. |
|
Seesms not to work. |
|
@Siedlerchr : OK, so I wait for updated versions.
… Seesms not to work.
Type randomly in the comment field and create new lines etc and type again
hit ctrl + s cursor jumps again to the beginning
|
|
@Siedlerchr just put me on a track. The issue occurs now, if you save after creating a new line... In saving, the fields are trimmed of whitespaces... |
|
This should do the trick. Let's wait for the deployment. |
|
Mhhh, this looks dangerous. Not sure what consequences could arise when the field value and textfield value are different (even if it just whitespace difference). What about moving the Another idea: preserve the caret position by hand as in https://stackoverflow.com/a/45334996/873661 (if they really differ only by trimmed whitespace, the new caret position should be easy to calculate) |
|
Tested it from eclipse, does not change anything, caret still jumps to the beginning |
|
System: ...If it can help with the problem (sorry if this is naive!): Moreover, I just discovered that typing into the multi-line fields as "Abstract" and "Comment" (those with the problem) you have you have a lag for which if you type fast you cannot see what you are typing: a problem you do not have when directly typing within "{} biblatex source" where typing is a much smoother (normal) experience. |
|
Next round of testing: https://builds.jabref.org/pull/6528/merge/ 😁 |
|
Expected behaviour should be now after 8bcc65b: @gianlucabaldassarre Thanks for the note. The source editor is using a different kind of entry editor, called richtextfx (or to be exact CodeArea). This editor has higher demands on memory and processor time. So we try to use this only when necessary. |
|
Hm. I tested your latest changes on this branch, for me it's still happening |
|
I really don't get it. It worked for me, maybe you something I don't see yet. |
|
I recorded a gif I started JabRef from eclipse with addtional command line parameter
|
|
@Siedlerchr can you set a breakpoint in the binding code, and see if it's called (and if yes with which values of before/after) |
|
Okay, debugging reveals: newValue: |
|
Ahhh...the textarea always uses |
|
Oh no... That raises more problems. |
|
Thinking about it, it might also be the reason for some of the "Library has been modified by another application." issues. #4877 Maybe we should rethink the newline handling on save... |
|
Should we always save in the OS specific format and rework it on loading? I think this demands a more serious discussion... |
The reason for the lag could be the preview window. Could you please try to deactivate the Preview Window in Preferences->Preview, restart JabRef and try again? |
|
Yes, I confirm that typing is smooth if I "deactivate the Preview Window in
Preferences->Preview", as you suggested.
However, having the preview on the right of each field-tab is quite
annoying (at least for me) for two reasons:
1) It takes a lot of space from the field windows (and why should I need to
continuously see the preview?)
2) The preview flickers while you type anything, your corner-eye sees it,
and this is highly annoying/distracting (indeed, peripheral vision has
evolved to be strongly sensitive to changes! : )
An observation/suggestion that maybe might be used to solve both the
problem of flickering and of the updating of the Preview Window creating a
horrible lag on typing: you could change the program so that the content of
the preview is updated only when you change field (or when you do a similar
operation that means you have finished to update the field), rather than
each time that you type something. Indeed, updating the previouw is
computationally complicated and causes the problems above, and one does not
actually need a preview that is always updated.
I understand that the on-line update of the preview "looks cool", but if it
impairs the key functionality of being able to type the fields smoothly
(!), and it prevents the use of the handy "Preview Window" functionality,
it is surely not worth it!
…On Thu, 28 May 2020 at 20:59, Carl Christian Snethlage < ***@***.***> wrote:
Moreover, I just discovered that typing into the multi-line fields as
"Abstract" and "Comment" (those with the problem) you have you have a lag
for which if you type fast you cannot see what you are typing: a problem
you do not have when directly typing within "{} biblatex source" where
typing is a much smoother (normal) experience.
The reason for the lag could be the preview window. Could you please try
to deactivate the Preview Window in Preferences->Preview, restart JabRef
and try again?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6528 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADNLQD743E7744BIK5TA7WTRT2YCRANCNFSM4NKTOARQ>
.
|
* upstream/master: (243 commits) fix checkstyle mEDRA DOI fetcher implementation. (#6641) Bump bcprov-jdk15on from 1.65.01 to 1.66 (#6676) Bump appleboy/ssh-action from v0.0.6 to v0.1.2 (#6674) Add localisation strings and renamed formatter Bump gittools/actions from v0.9.2 to v0.9.3 (#6675) Skip non-working sourcespy site Let dependabot update github actions Add three formatters to fix new lines in abstract and digits in editors Update src/test/java/org/jabref/logic/importer/fetcher/CollectionOfComputerScienceBibliographiesParserTest.java Fix to imports Make fetcher test more specific by checking each field explicitly Use builder instead of "setField" statements (docs) fix styling Update jpackage notes Fix automerge workflow fix markdown Bump org.beryx.jlink from 2.20.0 to 2.21.0 Bump unirest-java from 3.8.00 to 3.8.06 Fix to dependency on Global ...
|
@Siedlerchr I think the build currently fails because of merging this PR (architecture violation) |
Fixes #5904