-
Notifications
You must be signed in to change notification settings - Fork 327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rich Indexing #3113
base: master
Are you sure you want to change the base?
Rich Indexing #3113
Conversation
This was modeled off the pattern for links. This generates an HTML Anchor in the active paragraph. The intent is to use a snippet to generate the final index by scanning all pages and ordering the index accordingly. Format: @Index Entry Name@(Index Parent Entry 1| Index Parent Enry 2|..) Key: Index Entry Name: This is the label in the index the reader will look up. Index Parent Entry: This is an optional list of parent index entries that the anchor could be a child of. Example: @fireball@(Fire Spells|Ranged Spells) This could/should output something like: ... Fire Spells Fireball p 16 ... ... Ranged Spells Fireball p 16 Entries without parents shhould be treated as top level. Notes and other lunacy: Any characters valid for links except @ are permitted. This may not be the best set of delimiters for this purpose. Open to suggestions. Does not currently prevent duplicate anchors. Anchor target values are created by removing whitespace and lowercasing the Index Entry Name. To Do: Add a Page level anchor to the \page code Create a Snippet to generate the actual index Determine a sane way to do a light index ( list of words ) Determine a sane way to merge both Index styles
Needs hyperlinks.
Oh. Wow. I just learned a new thing. I had no idea that the anchor behavior also applied to any ID'd tag. That's got to have been there for years?! 🤯 |
This changes the index page level links to use #p325 isntead of #page325 where the reference page is 325. Thanks Eric!
Yes, but due to how rendering works this is funky, Id for headers are not unique between pages, and Partial Page Rendering(PPR, which applies to 50+ pages brews) blocks them altogether. We are working on some fixes for that. |
Fair, but as long as the ones for the pages are, it works for this purpose so long as someone doesn't manage to construct a collision between tags. I considered concatenating the page number with the munged label ( i.e. p1-thisismylabel ) but I didn't see an elegant way to grab that... |
If/when #3089 goes live, each Markdown token will be contained inside |
I am unsure what is going wrong with this conflict |
Remove unneeded console.log in tests
- Changes @*.@(*.) pattern to @[*.]() - Updates editing color coding for leading @ to colormatch ! on images. Sample Document. ``` @[](This|That|The other) Page 1 \page Page 2 @[here](there2) @[onehere](there1) \page Page 3 @[ore](there3) @[here](there1) this that \page Page 4 this the other \page ``` When the Rich Index is run, generates: ``` {{index,wide - That ... pg. [1](#p0), [3](#p2) - there1 - here ... pg. [3](#here) - onehere ... pg. [2](#onehere) - there2 - here ... pg. [2](#here) - there3 - ore ... pg. [3](#ore) - This ... pg. [1](#p0), [3](#p2), [4](#p3) }} ```
I'm going to respond to these individually where I do.
I probably could explain that more clearly. The section on using optional additional Indices doesn't do a great job of spelling out that they will be rendered distinctly.
I think that's kind of an "a or b" decision where one value isn't any better or worse than the other as a default. I think we can push this decision off to be part of deciding the final default styling. |
There should be an implicit id generated for the H#. If not, we should add one. |
C through E are really just styling thoughts. The styling is incomplete. It is the existing index styling with no tweaks. This tool should be style agnostic beyond the very minimal. Style should go in the theme.
That isn't doing a join, but there isn't a solid reason for not doing one.
Are you using https://homebrewery-pr-3113.herokuapp.com/edit/vtI5G0Zl_fan or https://homebrewery-pr-3113.herokuapp.com/edit/PXQAJqD9pVbK Both should have them. |
Semi-Dynamic Index building for Markdown+
Build simple, rich, or hybrid indexes with internal links.
Usage
Both usage cases center around the use of the index marked extension.
Multiple Indices
This system is capable of tracking multiple indices. Entries without a declared index in their formatting will be placed in the default index
Index
. An index marker is a block-level marker.Simple Index
Anywhere in the document add an index marker with no label and a list of terms to be indexed. Terms will be searched for in a case and whitespace insensitive manner.
Complex Index Entry
There are a number of variations that can be employed here. The only requirement is the line starts with a
#
, has no space, and contains a Topic - and Index and a Subtopic are optional.This generates an entry for
Fireball
under the topic ofElemental Spells
in theAppendix: Magic
index.This generates the topic of
Elemental Spells
in theAppendix: Magic
index.This generates the topic of
Elemental Spells
in the default index.This generates an entry for
Fireball
under the topic ofElemental Spells
in the default index.This generates an entry for
Fireball
under the topic ofElemental Spells
in the default index.Crossreferences
This system supports crossreferencing index entries. Crossreference hyperlinks link to the crossreference target rather than a page number. Crossreference targets do not need to exist in the brew prior to being referenced; missing targets will result in the references being silently dropped on index generation.
Crossreferences are implemented by appending
|
followed by an optional key and then the index entry to reference.Examples:
The optional keys are:
The reference type is prepended to the target. The code does not enforce any particular style guide.
The above example would generate:
Generating the Index
The rich index snippet, when executed, combines the simple and rich index entries into a single, alphabetized index.
If you have simple and rich entries, rich entries will be folded under the simple entries as follows:
{{index,wide }}
container. If muliple indices exist, they will appear in alphabetical order separated by a\page
.Known issues.
Other notes
I'm not the most efficient JS coder. I'd be very unsurprised if some of this could be condensed.
Test Brew ShareID: https://homebrewery-pr-3113.herokuapp.com/share/vtI5G0Zl_fan