12.0.0-alpha.3

• Users are advised to recreate the index DB

• Adjusted SQL indices and swapped to specialized SQL queries
  for exact and prefix search terms, e.g. 'hello, ^worl

  • Handling of these terms is now 10-20% faster depending on the document

• Fixed command history recomputation not using the reloaded version
  of document store

  • This issue is most noticeable when you've edited a text file after hitting Enter in Docfd (after which Docfd reloads the file for you),
    and you hit h to modify the command history

  • The replaying of the command history would use the old copy of the file instead of the new edited version of the text file

• Added missing SQL transaction in code path for reloading a single document

  • Previously, reloading a single document was incredibly slow, which was very noticeable if you edited a text file
    after hitting Enter in Docfd, unless the text file was very small

• Updated --paths-from argument handling

  • Added --paths-from - for accepting list of paths from stdin

  • Adjusted to accept comma separated list of paths, e.g. --paths-from path-list0.txt,path-list1.txt

• Removed builtin piping to fzf triggered by providing ? as a file path, e.g. docfd ?

  • The --paths-from - handling makes this obsolete and a lot less flexible by comparison

• Fixed interaction between search and filter

  • Previously, starting a search would incorrectly cancel an ongoing filtering operation.
    Now only a new filtering operation can cancel an ongoing filtering operation.
    A new search still cancels an ongoing search.

  • Starting a new filtering operation also still cancels any ongoing search. This is fine since the search results
    are refreshed after the filtering has been completed.

    • The refreshing of the search results also means that the following sequences of events are still handled correctly,
      namely they still arrive at the same normal form of the document store:

      • Example 1:

        • (0) Filter f_exp0 (filtering is canceled by step (2), but the updating of filter expression is never canceled)
        • (1) Search s_exp0 (search is canceled by step (2), but the updating of search expression is never canceled)
        • (2) Filter f_exp1 (refreshes search results using s_exp0)

      • Example 2:

        • (0) Search s_exp0 (search is canceled by step (1), but updating of search expression is never canceled)
        • (1) Filter f_exp0 (this stage is canceled by step (2),
          either during the filtering or during the
          refreshing of search results, but the updating
          of filter expression is never canceled)
        • (2) Filter f_exp1 (refreshes search results using s_exp0)

• Renaming query expression/language to filter expression/language in help text and documentation

• Added a separate loading indicator for filter field

• Fixed concurrency issue where an update of document store may cause the
  filter field and search field in UI to be out of sync with the actual
  filter expression and search expression used by the underlying document store

  • Suppose we have the following sequence of events:

    • (0) Document store store0 carries filter expression
      f_exp0 and search expression s_exp0, which we write
      as pair (f_exp0, s_exp0)

    • (1) User initiates filter/search operation by placing (f_exp1, s_exp1) into the input fields.

      We name the document store resulting from this filter/search operation as store1a,
      which carries (f_exp1, s_exp1) when finalized.

    • (2) While filter/search operation is ongoing,
      user drops a set of documents from the
      current document store. Since store1a is not
      finalized yet, the current document store is still store0, thus the new document store encoding the result of the drop operation, store1b, is computed from store0 instead of store1a.

      In other words, both store1a and store1b share
      store0 as their parent.
      Note that store1b carries (f_exp0, s_exp0) as
      inherited from store0,
      since a drop operation does not alter the filter expression or search expression.

    • (3) As a drop operation immediately updates the document store
      and cancels ongoing filter/search operation, step (2) canceled the computation of store1a, and instead places store1b as the current document store.

  • However, this means the input fields are (f_exp1, s_exp1)
    while the current document store store1b actually carries
    (f_exp0, s_exp0).

    The fix in this update is then to add an
    extra "sync from input fields" step whenever a document store
    is updated. To illustrate, we continue from the above
    sequence of events, where the updated version of Docfd
    carries out the following step missing from previous
    versions.

    • (4) Update input fields to (f_exp0, s_exp0)

  • This addresses the mismatch between the underlying document store and the UI input fields.

  • In practice this is very unlikely to occur with human input, as the modes that update document store
    are disabled if document store manager is carrying out any ongoing filtering or search.

    However, since the UI is async, there will be gaps in timing between UI input/feedback and actual updates of values,
    opening up to TOCTOU problems.
    So there is always a chance that a document store update will be requested before the modes are are disabled.

• Made interrupted filter/search operation to not yield a document store at all instead of yielding an empty document store
  to simplify reasoning about filter/search cancellations and UI fields being in sync