joostkremers
commented
1 year ago This looks pretty cool!
One question (which may be answered by the page you linked to, but I only skimmed it...): If you go back through the history, then go forward again, and then backward again, followed by a jump to another entry (i.e., not in the history), this to and fro is not reflected in the history, right? Not that I mind, I was just wondering.
So is this ready to merge, or do you want to test it yourself for a while first?
Hugo-Heagren
abdalazizrashid
I often find myself adding a new bib entry to my file, only to realise that I need to add a supporting entry of some kind first (like a
Collection, which I can refer to from anInCollection). If the two have different principle authors they won't be very close in my index, so its a hassle to move between them.I think it would be useful to add two features to deal with this and similar problems:
point-to-registerandjump-to-register, for storing and jumping to an entry's location. Those commands already kind of work for jumping between entries in the index, but because they are based on the location of point, they can't deal with jumping to an entry after changing the sort order, or adding a new entry. My proposed commands are based on jumping to an entry with a given key (the history commands would work similarly).This PR:
point-to-registerandjump-to-registerwith these commandsA few notes on my history implementation
My code is slightly modified version of the stack/head system described at https://gist.github.com/CMCDragonkai/d266a3055735545447439f0fa662a0e1 . In my implementation: - there is a list for the history (`:history` in `ebib--entry-history`). Elements nearer the front of the list are more recent in history. - there is a head pointer (`head` in `ebib--entry-history`). This is a number, a 0-based index into the history list, of where we are currently in the history. - to move back in history: - look up the entry before our current position in history (whatever is at `history-list[head+1]`). Error if there is no such entry. - goto that entry. - increment head - Importantly, going back does not mutate the history list. - to move forward in history: - look up the entry after our current position in history (whatever is at `history-list[head-1]`). Error if there is no such entry. - goto that entry. - decrement head - Importantly, going forward does not mutate the history list. - When doing anything else (jumping to an entry, going to the next/prev/first/last entry etc.) (in order): - take everything from the second to the `head`th element inclusive of the history list, reverse what you've got, and prepend that to the list. - prepend the entry we are going to to history - set head to 0 (we are at the end of history so far) So for example... We open a new database, at entry `@a`. This is pushed to the history list, so now `history` = `("a")` and `head` = 0. We move to next entry `@b`. `history` = `("b" "a")`, `head` is still 0. next entry again to `@c`, then `@d`, then `@e`. After this, `history` = `("e" "d" "c" "b" "a")`, `head` is still 0. Notice how the history list is reversed compared with our experience (we visited `@a` first, but "a" is last in the list). We move back in history (M-xebib-history-back). The current entry is now `@d`, `head` becomes 1, but the history list is unchanged as `history` = `("e" "d" "c" "b" "a")`. Move back again. Current entry is `@c`. Now `head` = 2, `history` is still `("e" "d" "c" "b" "a")`. And back again. Now `head` = 3, current entry is `@b`, `history` is still `("e" "d" "c" "b" "a")`. (Notice how `(nth head history)` is always the same as the key of the current entry.) We now jump to entry `@f` with `ebib-jump-to-entry`. head is 3, so everything from the second history to head will be the things at index 1, index 2 and index 3 (head), which is `("d" "c" "b")`. Reverse this list and prepend to the history list: now `history` = `("b" "c" "d" "e" "d" "c" "b" "a")`. Then add the entry we are jumping to: `history` = `("f" "b" "c" "d" "e" "d" "c" "b" "a")`. Finally, set `head` = 0 (once again, notice that we are at entry `@f`, and element of history at index `history` is "f"). To briefly demonstrate why this makes sense: going back through the description I have just given, a list of entries we have actually visited (in the order we visited them) would be: `a b c d e d c b f`. We are now at `f`. If we go back lots of times, our experience ,*should* just go back along that list. And looking at the `history` list, it will: `history` is just that list backwards. Currently there is only one history list, used for a whole ebib session, across multiple databases. Entries are located with their key and the current db, by `ebib--find-db-for-key`. I did consider building separate lists for different databases but: - this would have been more work - personally, I prefer one master list, so to implement separate lists I would really have had to implement both versions, and control which was used with a user option. This would be fine in terms of user experience, but it would be a *lot* more work, and (since nobody has built this before anyway) I feel there probably isn't the demand for it to be worth it. Currently, history persists between ebib sessions, so if I open database A, do some stuff, then quit ebib and later open B, my history from A will still be lying around. I'm not sure if this is a problem---it doesn't really effect the experience too much (and I for one mostly use a single huge database anyway), but I can see why some might not like it. What do you think?