breadcrumbs icon indicating copy to clipboard operation
breadcrumbs copied to clipboard

FR: Option(s) so next/prev sequences are treated as separate groups of ordered siblings

Open abers opened this issue 3 years ago • 2 comments

Is your feature request related to a problem? Please describe. I am looking for a way to have next/prev sequences treated as ordered siblings, AND have different sequences with the same parent treated as separate groups. So you could have trees combining up/down and next/prev relations that look like the following:

  • 1
    • 1.1 (Group A)
    • 1.2 (Group A)
    • 1.3 (Group A) ~~- -~~
    • 1.a (Group B)
    • 1.b (Group B) ~~--~~
    • 1.A (Group C)
    • 1.B (Group C)
  • 2
  • 3

Rationale This enables a simple way to represent hierarchies that are more complex than up/down, but without radically changing the way breadcrumbs works.

My use-case, in particular, is for representing a zettelkasten with a folgezettel numbering system. This system uses alphanumerical codes where notes in a sequence go 1, 2, 3 OR a, b, c - switching between the two whenever a new sequence branches off from another. So, a new sequence branching from 1 would be 1a, 1b, 1c. If branching again from 1b, it'd go 1b1, 1b2, etc. I then use capital letters whenever multiple sequences branch from the same note. So, if there was a second branch from 1b the sequence would go 1bA1, 1bA2, ... and a third branch, 1bB1, 1bB2, ...

In order to achieve this using breadcrumbs, I use 'next' and 'prev' for sequences and then 'down' for any new branches. This mostly works using the matrix view. However, other views are pretty useless given next/prev and up/down aren't included within the same trees.

Describe the solution you'd like Ability to set the following options:

  1. Treat 'next' / 'prev' as ordered siblings
  2. Treat "same parent but not siblings'" as different groups
  3. Show 'next' / 'prev' as ordered siblings in up/down tree views and in the matrix
  4. Add lines between groups of ordered siblings in tree views.

So, if you had a codeblock for a tree going down, you could get the following:

  • 1
    • 1a (down from 1)
    • 1b (next from 1a)
      • 1b1 (down from 1b)
      • 1b2 (next from 1b1) ~~---~~
      • 1bA1 (down from 1b)
      • 1bA2 (next from 1bA1) ~~--~~
      • 1bB1 (down from 1b)
      • 1bB2 (next from 1bB1)
    • 1c (next from 1b) ~~---~~
    • 1Aa (down from 1)
    • 1Ab (next from 1Aa) ~~--~~
    • 1Ba (down from 1)
  • 2 (next from 1)

Then, using the same hierarchy, a matrix view of 1b would show:


Up

  • 1

Same

  • 1a
  • 1b
  • 1c

Down

  • 1b1
  • 1bA1
  • 1bB1

Next

  • 1c

Prev

  • 1a

abers avatar Jul 03 '22 16:07 abers

Thinking about this more, a simpler solution may be adding a 6th relation - series. That would possibly avoid conflicts with the way siblings and options for them are currently setup. It may also resolve the bugs when using same and next/prev. The first note in each series with the same parent could then also be siblings without causing any conflicts.

The matrix view would then show Up | Same | Down | Next | Series | Prev. Nesting next/prev within up/down trees could then be handled with a toggle option, or adding new types of tree dir: down-next and dir: up-prev.

Handling this through a 6th relation would also open up more options for representing complex hierarchies than the original proposed solution.

abers avatar Jul 04 '22 11:07 abers

This is now partly possible in the V4 beta. See here for more info about the changes in general: https://github.com/SkepticMystic/breadcrumbs/blob/master/V4.md And see here more details about the new feature that enables this: https://github.com/SkepticMystic/breadcrumbs/tree/master#list-notes I won't fully close this issue, but please see if the new feature is good enough for the moment

SkepticMystic avatar Mar 21 '24 17:03 SkepticMystic