Skip to main content

Convert Selection to New Transcluded File

Comments

3 comments

  • Fletcher Penney

    The main problem with this idea is the exact problem you ran into in describing your workflow -- steps 2/3/4.

     

    The editor window in nvUltra is just that -- an editor window.  It is not a command line shell.  So *hoping* that the user types the new filename inside the editor, and hoping that it is unique, is unreliable and breaks the idea of what an editor window is for.  A key facet of which is that the user can stop typing at any time, and the editor contents are still valid (they might not do what the user wanted if they didn't finish typing, but they are still valid nonetheless.)

     

    An alternative that *might* be feasible would require popping up a dialog window that asks the user for a filename and handles confirming it is available, etc.

     

    However, the reality of any of these is that the workflow is not going to be that much faster/shorter than the way you described doing it currently.  The cognitive effort there is primarily in choosing a new file name.  Creating a new note is trivial (Cmd-L, type new name, hit enter) and won't really be any shorter in any other approach.  Cutting/Pasting the contents is trivial (you have to highlight them no matter what, Cmd-C, Cmd-V is trivial).  The only thing you really have to remember to do is type in the transclusion for the new file.

     

    So all told, a new workflow:

    1. Might save a couple of keystrokes out of a process that requires on the order of 10s of keystrokes either way (assuming a non-trivial filename length)

    2. Requires users to discover/learn/remember a new workflow, instead of the normal workflows they are already familiar with (copy/paste, creating a new note)

    3. Requires a moderate amount of development, and more importantly testing, on our part (which isn't a huge deal, but does mean that something else isn't being worked on.)

     

    I'm not sure it is worth the trade-off.

     

    What I think is a better idea is to focus on the one part of the process that does add "unnecessary" keystrokes -- retyping an existing filename into the transclusion marker.  Which is better solved by treating transclusion markers like WikiLink markers, and offering autocompletion based on available files.  Which helps with this workflow, but also with any workflow involving transclusion.  

     

    And I think that part is a better use of development time/priorities.

     

    Thoughts?

    0
  • Fletcher Penney

    Added autocompletion for transclusion in a manner similar to WikiLink autocompletion.  (And while I was at it, fixed the recent issue of prepending autocompleted wikilinks with `./`)

     

    This will be in the next release.

    0
  • Fletcher Penney

    So now, the workflow can be:

     

    1. Select desired text

    2. Cut text

    3. Create new note with desired filename

    4. Paste text

    5. Return to initial note, type `{{` -> this autogenerates `{{}}` assuming you have smart pairs enabled

    6. Type some characters from the new filename you just created, and it should appear in the autocomplete suggestions for you.  Select and hit return.

    0

Please sign in to leave a comment.

Powered by Zendesk