omz:forum

    • Register
    • Login
    • Search
    • Recent
    • Popular

    Welcome!

    This is the community forum for my apps Pythonista and Editorial.

    For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.


    Could the bundled 'global search' workflow be adapted to only work on the current document?

    Editorial
    5
    12
    6612
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • jonmoore
      jonmoore last edited by

      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).

      1 Reply Last reply Reply Quote 0
      • omz
        omz last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • jonmoore
          jonmoore last edited by

          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

          1 Reply Last reply Reply Quote 0
          • jonmoore
            jonmoore last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • jonmoore
              jonmoore last edited by

              @omz

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

              1 Reply Last reply Reply Quote 0
              • MartinPacker
                MartinPacker last edited by

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

                1 Reply Last reply Reply Quote 0
                • jonmoore
                  jonmoore last edited by

                  @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).

                  1 Reply Last reply Reply Quote 0
                  • MartinPacker
                    MartinPacker last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • wezlo
                      wezlo last edited by

                      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...)

                      1 Reply Last reply Reply Quote 0
                      • Bricoleur
                        Bricoleur last edited by

                        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([^#].+?)$

                        1 Reply Last reply Reply Quote 0
                        • omz
                          omz last edited by

                          @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.

                          1 Reply Last reply Reply Quote 0
                          • Bricoleur
                            Bricoleur last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Powered by NodeBB Forums | Contributors