Inconsistent saving behaviour of fields and comments

mjthoraval
1) If I edit the Abstract from the Info pane of the parent item in My Library (or any other field), and press Escape, the content disappears. This is the same behaviour as when writing annotation comments in Adobe Acrobat, and probably the expected behaviour by some users.
2) If I do exactly the same from the right side pane of the PDF Viewer, the content is saved. This is the same behaviour as in Foxit PDF Editor for example.
I guess they should behave consistently? Which one is correct? Probably saving, to be consistent with editing comments of PDF annotations in the Zotero PDF Viewer?

I have tested this in Windows 10, Zotero 7.0.0-beta.26+6dcc70f53 (64-bit), but I saw the same also with Ubuntu 23.04, Zotero 6.0.26 and also Zotero 7.0.0-beta.26+6dcc70f53 (64-bit).

The shortcut Shift+Enter works in both Info tabs, for Abstract or Extra fields, as described in the Zotero keyboard shortcuts page. However, it is probably not the best shortcut, as it is usually reserved to go to next line in formatted text, as it is the case in Zotero for PDF annotation comments.
It would be nice to be consistent also on this shortcut.

See previous discussion here.

  • dstillman
    edited August 3, 2023
    (1) is correct. Nothing special about Abstract — that's how you cancel all fields in the Info pane. It's just a bug that it doesn't cancel in the PDF reader Item pane. We'll fix — thanks.
    The shortcut Shift+Enter works in both Info tabs, for Abstract or Extra fields, as described in the Zotero keyboard shortcuts page. However, it is probably not the best shortcut, as it is usually reserved to go to next line in formatted text
    Shift modifies the default action. In a single-line field, Enter closes the field and Shift-Enter creates a newline (if that's even an option, which it isn't in the Info pane). In a multi-line field, Enter creates a newline, so Shift-Enter closes.

    Sticking to Enter=Close and Shift-Enter=Newline would be fine in Abstract, where newlines are rarely used (and people aren't usually typing anyway), but I think it would cause trouble in Extra, where people often want to create multiple lines by hand. The Extra field is the reason we do this. Everyone knows other ways to close the field, but I suspect only advanced users really know that Shift-Enter sometimes creates a newline.
    as it is the case in Zotero for PDF annotation comments
    Shift-Enter isn't actually doing anything in annotation comments — both Enter and Shift-Enter are just inserting newlines. If anything, Shift-Enter should exit edit mode.
  • mjthoraval
    edited August 3, 2023
    It's just a bug that it doesn't cancel in the PDF reader Item pane.
    Just to confirm here: is it also a bug that it doesn't cancel for the edition of comments to annotations in the left pane of the PDF reader (not only the edition of fields in the Item pane)?
    Shift-Enter isn't actually doing anything in annotation comments — both Enter and Shift-Enter are just inserting newlines. If anything, Shift-Enter should exit edit mode.
    I was actually hoping that this was by design, in anticipation of getting mardown text editions in the annotation comments, in the same way in notes.
  • dstillman
    edited August 3, 2023
    Just to confirm here: is it also a bug that it doesn't cancel for the edition of comments to annotations in the left pane of the PDF reader (not only the Item pane)?
    No. It's a different kind of field, where people are writing potentially large amounts of text, and where you can't see the full text (or see the text at all in the PDF view) when it's closed, so losing all changes on Esc is too dangerous. The same widget is also used when the sidebar is closed, and Esc is fairly natural for closing a popup.

    But if we support Shift-Enter to close, you can just not use Esc if you're used to it doing something destructive in other apps.
    I was actually hoping that this was by design, in anticipation of getting mardown text editions in the annotation comments, in the same way in notes.
    You mean getting the real note editor there? (Nothing to do with Markdown. The note editor supports some Markdown syntax to trigger rich-text formatting, but that's unrelated to Enter/Shift-Enter.) That's probably unlikely for technical reasons, but yes, that would be one reason not to add close-on-Shift-Enter now.
  • mjthoraval
    edited August 3, 2023
    I see the point that annotation comments and metadata fields are different. But I just find it very confusing to keep different behaviour in the left and right panes of the PDF reader.
    Is there any real benefit in keeping a destructive Esc behaviour? If you really want to cancel an edit while editing, the natural choice for me would be to use Ctrl+Z instead of Esc. I don't remember ever using Esc as a destructive behaviour on purpose. And the constructive behaviour of Esc in the Item pane of the PDF reader is probably this way for some time already, and nobody has ever complained about it.

    From my perspective, I would prefer to stay safe and consistent as much as possible. So:
    1) Keep only a constructive Esc behaviour everywhere, so save and exit, as it is already the case for annotation comments.
    2) For single line fields, it makes sense to use Shift+Enter to save and go to the next line (consistent with the current choice "Add Another Author/Creator when Editing Creator" as indicated in the Zotero keyboard shortcuts page, but it could also be extended to other fields).
    3) But for multiple lines fields, I would stay consistent everywhere and keep the new line behaviour for Shift+Enter. This shortcut is usually associated with making a new line, not saving and exit.
    4) I would choose another keyboard shortcut to save and exit when editing a multiple lines field (Abstract, Extra or Annocation Comment), which should also work to save and exit when editing a single line field. Probably Ctrl+S, as it is the natural shortcut for saving, and it also works in Acrobat and Foxit.
Sign In or Register to comment.