Forum Archive

I've taken a look through the Python script but with my limited knowledge I'm unable to workout how I would adapt this script to only function on the current document.

This may on the surface seem a superfluous question seeing as Editorial already has a current doc search function but there is a method to my madness as I'd like to adapt the script to be able to function as a more useful 'table of contents' workflow than the two that are currently available in the repository.

Create TOC

TOC Preview

As useful as these are, neither functions in the same manner as 'Global Search'. The great thing about the global search function is that the search results sends you directly to an 'anchor' within the editor. If I could only work out how to limit the 'Global Search' workflow to the current doc, it would be fairly simple to adapt the workflow so that it presents a TOC in the preview but anchors back to the editor when you pick the header of your choice.

My inspiration here is the way that 'CMD + L' functions in FoldingText ('Go to Heading' function).

I've made a little demo workflow that does something similar with almost no Python:

→ Interactive TOC

It's not very polished, so there's no styling of the output etc., but I hope it's helpful as a starting point for your own experiments. Here's what it does:

• It repeats a block for all matches of a regex in the current document (markdown headers here).
• For each match, an HTML link is generated that points to an editorial:// URL that runs the same workflow. The input parameter of the URL contains the range of the regex match. Note that if you rename the workflow, you have to adapt the last action in the repeat block.
• The final list of links is shown via Show HTML

At the beginning of the workflow, it checks whether it's run with any input. This will be the case when you tap a link within the TOC (because of the input parameter in the editorial:// URLs). It then simply selects the given range in the editor and hides the preview panel (this is the only part for which Python is needed).

As is, the workflow isn't very useful because you could achieve the same by using the built-in TOC (when tapping the filename), but since you could use other regular expressions for matching the entries, it's more flexible.

Thanks for this Ole. It's definitely a great start point for something more powerful (and something that works on other elements of the doc structure not just headings). But with regard to headings I'll be able to indent/style the different heading levels through CSS so that the preview pane provides an overview of the doc structure as well as the anchor links.

It's also very useful for me to see how you structured your workflow as it may inspire a few other 'hacks'. :)

jm

@omz

Here's my first adaption which searches the open doc for Blockquotes and achor links directly to that part of the doc.

Interactive Blockquotes

Very useful for me as I often use Blockquotes to create comments on longer documents when I'm working on research projects. (Although I use a leading space character after the > so as not to confuse them with standard Blockquotes).

The included CSS is overblown for the task at hand but it's very adaptable to whatever element is being queried via the RegEx (for those who want to adapt it for other purposes).

It's not public at the moment but I'll upload a public version in the morning.

@omz

Thanks for kicking this off for me, your solution is both elegant and highly adaptable. :)

All I can muster as this point is a visceral "woo hoo!" :-)

@MartinPacker - Such a simple solution but the combination of tweaking the RegEx to your specific needs coupled with the elegant anchor links in the preview window makes for a very powerful combo. I'll upload the final workflows publicly tomorrow but I see these very much as starter workflows that people can adapt to their hearts content (as long as they've got a modicum of RegEx skills).

@jonmoore "as long as they've got a modicum of RegEx skills"... :-)

I have been wondering this, and was getting ready to learn python just so I could write the workflow - thanks so much! I can't wait to see the final results (and I think I'll just learn python anyway...)

Question: is there a way to include a comment, at the front, or end, of a Regex expression line that will be ignored when the expression is fed to the pythonista code in this workflow ...or do I have to roll my own line parser? (I don't know Regex and am simply cribbing from other sources at this point so any pointers in the right direction would be greatly appreciated.)

OK I found answer here: http://omz-software.com/pythonista/docs/library/re.html
(?#...)
"A comment; the contents of the parentheses are simply ignored."

If anyone interested this was my use case:

I've created a front end to display many different Regex patterns and "select from list" action to give multipurpose use of this workflow.

Two entries, for example, are:

eMail Addresses:
\b[!#$%&'*+./0-9=?_`a-z{|}~^-]+@[.0-9a-z-]+.[a-z]{2,6}\b
ToC:
^#{1,6}\s([^#].+?)$

The title lines do nothing but, with more than a handful of expressions being used, I simply can't trust that I will remember what each pattern extracts when I come to use some of the less frequently used entries. It would obviously be much nicer to have a line read this way:

^#{1,6}\s([^#].+?)$ # table of contents

Where everything after the # is ignored as being a comment.

So now I use:
(?# Table of Contents ) ^#{1,6}\s([^#].+?)$

@Bricoleur You could also achieve this in a different way. When you use a tab character in the Select from List action, the text before the tab will be the visible text in the list, and everything after it will be the actual output when the entry is selected.

So you could for example use an entry like Table of Contents <tab> ^#{1,6}\s([^#].+?)$", which will show just "Table of Contents" in the list, but pass the actual regex to the next action.

Great. Thanks @omz .... Much more elegant!