I’m trying to use a single Drafts document for a glossary of approximately 100 terms (subject irrelevant). It would be handy to be able to refer to the glossary on the iPad as well as the Mac.
Each term is a markdown heading and its definition is body text subordinate to the heading. I want to make heavy use of within-document links based on the headings as navigation markers.
On the iPad, with the onscreen keyboard closed, when I tap on a link. the document is scrolled to the relevant marker but the keyboard is activated. In (preferred) landscape mode, it takes up half the screen depth. Drafts scrolls the document intelligently to the marker but the text for which the marker is the header is typically multi-line and all but the top couple of lines are covered by the keyboard.
I can of course dismiss the keyboard with a single tap but I would like not to have this inconvenience.
In portrait mode, the k/b occupies about 1/3 of the screen depth. With the drafts list hidden, the greater editor width reduces the number of lines needed to display an entry.
Is there a way to achieve the behaviour I’m looking for? Can the editor be put into a mode in which it responds to taps on links but doesn’t activate the keyboard?
In the Editor settings, I see “Edit on draft selection” but both its settings don’t seem to affect the current behaviour. I also tried in Preview but the navigation-marker-based links are inactive. I guess what I’m after is something like “Activate k/b on jump to navigation marker”; it would be false for the behaviour I’m after.
I’m happy to do some scripting if someone can kickstart me but it’s hard to imagine a scripted interaction as simple as tapping on a link. Sorry about the essay! On Drafts Pro 31.2 and iPadOS 15.4.
Goot point. That behavior should probably respect the “Edit on selection” setting. I dont think it makes sense to add another separate option for it, but it should follow that behavior.
Good get! Though the documentation for Link Mode doesn’t explicitly mention “navigation-marker-based” links, I guess they would qualify under “most common link types”.
The scrolling behaviour in Link Mode is different from the behaviour with Link Mode turned off.
In Link Mode, when the link target is earlier in the document than the link, Drafts scrolls the document to the point where the target is the first line in the editor window (see Shot 1). This is probably the optimum choice for my use case as it gives the full window depth to view the subordinate block of text (the glossary term’s definition).
However, when the link target is later in the document, Drafts’ scrolling behaviour seems more variable. It always does the minimum, i.e. display the link target/ markdown header (glossary term) at the foot of the window but sometime does (Shot 2) and sometimes doesn’t (Shot 3) display all the lines of the definition. I think the optimum in this case would be to display the next markdown header, thus guaranteeing all the definition text of the target term is visible (subject to the length of the definition text and the depth of the window).
I realise that my use case is a simple one: all navigation markers/ markdown headers at the same level, a simple block of text between the headers. The scrolling algorithm will presumably have to address more complex scenarios.
But Link Mode as it stands is definitely more convenient than the currently unavoidable keyboard activation in “editor active” mode.
I see in Greg’s post that he is going to extend the scope of the “Edit on draft selection” setting to accommodate landing on a navigation marker link target. It will be good to have two options to suppress keyboard activation.
