Allow repeat use of item in a citation

[fbennett]

citeproc-js supports back-references within the same citation. In some note styles (legal styles, Chicago fullnote) this is a fairly common practice -- if a source at one location says one thing, say, and the same source at another location something different, you would normally use two separate references with explanatory text to point out the anomaly.

The attached patch is a first-cut attempt to get repeat items within a citation working. It's not been heavily tested. A couple of notes:

(1) The patch disables the locator/prefix fields entirely when focus is in the item tree. This is necessary because the item to the right cannot be determined unambiguously.

(2) The patch does not attempt to sort items in the selection list. There are some notes in the patch -- I'm not sure it's desirable to sort the selected items list itself, although an immediate restore of the sort ordering in the preview display when the "Keep items sorted" tick-box is ticked would probably be a nice touch.

[fbennett]

Revised patch for repeat items in a single citation.

[fbennett]

I've put up a revised patch, which implements what would be my preferred UI treatment of sorting. Ticking and unticking the Keep Sorted box has no effect on the selected items list box, but a change in the tick-box state is instantly reflected in the preview/editor if it is open, snapping to sorted form when ticked, reverted to possibly jumbled selected items listing when unticked.

See what you think.

[fbennett]

There are bugs in the patch (both versions) that manifest when switching between single and multiple modes. When it's fixed, I'll post another as revision 3.

[fbennett]

Things seem to have finally come right in the third version of these changes (allow-repeat-item-in-citation3.patch). This is a complete patch: please ignore the previous ones. Notes (1) and (2) above apply to this as well (no locator or affix editing from the left pane, sorting applied in the preview only). A few additional notes:

(3) The original code was attempting to change the width of the popup when switching between single and multiple entry mode, by setting the width attribute on the dialog element. This only took effect in the next instance of the popup, so user would get the popup at the size appropriate to the last mode used, regardless of whether the next edit was of a multiple or a single citation. That is fixed in this patch. The popup will open at the correct dimensions for the mode used at startup, and it will resize immediately when the user changes the input mode.

(4) To prevent accidental data loss when editing in multiple mode, the single-mode switch button is disabled so long as two or more items are in the selection list. No attempt is made to reselect a single last remaining item when switching from multiple to single (which seems inevitable, given the complexity of the tree), but the locator and affix field content are preserved for reuse when the user selects the appropriate item.

There might be cosmetic buglets in there, but the data handling part seems to be reasonably solid. The interface seems intuitive and friendly to me, but I'm biased, of course; the opinion of others is what counts. Give it a try and see what you think.

[simon]

Frank, this looks good. I've played around with it and have a couple of comments. Let me know if you'd rather I handle any/all of these.

1) Although I'm not particularly adamant on this point, I do think there's some value to sorting the items in the box on the right. I see your point re: drafting, but I think that, now that we have the up and down buttons thanks to your patch, it seems somewhat inconsistent for pressing them to change the entire order of the citation, as it does with this patch. Additionally, there are use cases like (A, C, D, but see B) where the current behavior makes generating citations easier. Finally, I think that changing the behavior has the potential to confuse existing users. I would like to consult with the dev list and/or the forums before making this change.

I didn't see any sorting issues with the previous code, although it's possible there were some. At least in theory, it's impossible for Zotero to call processCitationCluster for purposes besides the preview command while the add citation dialog is open, so unless the sortedItems field gets modified before the processCitationCluster command returns, it should be okay to use.

2) Editing the prefix/suffix/pages of newly added items now requires additional mouse clicks. When a new item is added from the tree, does it make sense to select it in the references listbox so that the "Pages" box is enabled?

3) Regarding (5) above, it shouldn't be difficult to select an item in the tree by ID—I haven't tried it, but in principle, you can do itemsView.wrappedJSObject.selectItem(id).

4) There is some weirdness with the window sizing. You've removed the position and size persistence (which may or may not be desirable), the height of the window is now larger (which is probably desirable, although it should not be made that large on screens that are too small to handle it), and pressing "Single Source..." and "Multiple Source.." repeatedly now moves the window across the screen, at least on my machine (which is definitely not desirable). Feel free to ignore this—I can refine the behavior with #1592.

[fbennett]

A few more little glitches have turned up in testing. I'll get them sorted out and put up a version 4 patch.

I don't use sorted styles myself, and I take your point re changes to existing behavior. I'll look at restoring the sorting behavior (and the other issues) in the next revision. If I get stuck, I'll report to the ticket and move aside. Thanks for looking!

[fbennett]

Here goes with allow-repeat-item-in-citation4.patch. In the revision, I've adopted your suggestions entire (or tried to, barring glitches).

Re sort behavior, sorting in the UI is back in, and seems to work okay. Unticking the Keep Sorted box no longer causes a potential reshuffle, which I agree might be a little alarming to some. The only possible gotcha case I can think of would be a user who has a document that is in a non-sorting style with detailed prefix/suffix notes in a particular order, who then selects a sorting style and edits a citation. The entry order of the citations would be permanently changed by the sort (because the sortedItems ordering feeds back into citationItems).

On the other hand, (a) this will be a rare event, and (b) they should recognize the behavior in the first affected citation. If it turns out to be an issue, we might consider defaulting to unsorted behavior in citations that have prefix/suffix fields set for one or more items. Eventually.

Re selecting items, the focus and highlight now move to the inserted item in the right-hand panel, which saves that extra mouse click.

Re shifting back to single mode, the highlight will appear on the item in the tree if it's available in the current tree view.

Re window sizing, I've restored persistence, added a check block that forces a meaningful size on the popup if it has none, and eliminated the code that attempted to center things. Positioning and sizing is now pretty much under the user's control, which I agree is how things ought to be.

I'll turn over to you for any further adjustments. If any of the stuff I've introduced proves to be thorny, feel free to give a shout; it's all pretty familiar now, after crawling around in the tubes and wires of the thing for the past couple of days.

[simon]

(In [6212]) closes #1680, Allow repeat use of item in a citation (patch due entirely to Frank)
see notes at referenced ticket for information re: modifications in behavior