This is possibly too narrow a feature request, so I understand if it’s not applicable. I know about the indent and outdent options bound to ⌘[/⌘], and I know that in another thread you mentioned that you don’t like overriding typing-key behaviour.
My proposal is that an exception be made for indenting-outdenting with Tab or Shift-Tab when the cursor is in a bulleted or numbered list. Or even just at the start of a line in a list. The current problem is that, when editing a list, pressing Enter creates a new list item, and places the cursor after the bullet, where pressing Tab to indent the item doesn’t work. Indenting either requires doing ⌘[/⌘], or moving the cursor to before the bullet, adding or deleting tabs, and moving back. The helpful functionality of adding a bullet or number automatically makes changing indentation less usable that it would be without adding a new bullet or number.
Would changing functionality so that, if Tab or Shift-Tab is pressed when the cursor is right after a newly-inserted-bullet, it indents/outdents the item, be possible? I think it’s much more likely that that’s what the user would want to do in that scenario than insert an actual tab character (or 2-4 spaces), and inserting a tab with the tab key would still be available in all other contexts.
This is a huge pain point for me. Virtually every editor I’ve ever used in the last 10 years works this way and the lack of this ability really, really slows me down. Using an odd keyboard combination doesn’t really help either. @TroyHurts suggestion seems like a valid middle ground. Please implement this.
Technically, this is possible on iOS right now, by changing the keyboard shortcut assignments of your indent/outdent actions to tab and shift-tab. You have to copy/paste in a tab character. That does not work in the Mac version because you cannot assign a shortcut without a modifier at the moment…and I’m not sure I’d recommend it on iOS.
Drafts leans heavily toward plain text editor conventions. The ⌘-[ & ⌘-] shortcuts assigned to the default indent/outdent actions are just that, defaults. You can re-assign shortcuts for any installed actions. But these are the standard “shift left” / “shift right” keyboard shortcuts in most plain text editors (Apple Notes, BBEdit, TextMate, VS Code, Xcode, etc.)…and relearning those allows you still be able to type a literal tab character, which is handy at times.
I’m a coder and heavily use markdown daily. So, to clarify, I’m speaking primarily about Drafts on the Mac and using markdown …
The difference between a text editor like VS Code and Drafts is that VS Code does not automatically insert a bullet point when building lists. When you hit enter, you go to the beginning of the next line but there is no asterisk auto-inserted, so it’s easy to hit TAB and type the asterisk for your indented item. Drafts, on the other hand, auto-inserts that asterisk and places your cursor to the right. So it is not behaving as normal text editors do in this situation. Since it inserts the asterisk, it really needs to behave more like other markdown editors (Ulysses, Bear, etc.) and allow you to TAB immediately after starting a new item to create a sub-item.
Similarly, Drafts should handle numbered lists better - regardless of whether we use the CMD + ] shortcuts. When indenting a numbered list, it should re-number the item. If I have 1 item, hit ENTER, Drafts inserts the number “2.” on the next line. If I then indent with the keyboard shortcuts, it simply indents the number 2 rather than renumbering it to “1”.
Perhaps this can be an option set in the markdown settings of Drafts? I would like to either 1) enable the standard TAB behavior of other markdown editors or 2) prevent Drafts from auto-inserting the asterisk/number on list items. Right now Drafts hovers somewhere between a text editor and markdown editor and the result, in this use case, is not conducive to quick typing and maintaining the writer’s flow
Yes, on iPhone and iPad. See Greg’s previous comment. You just need to be sure to paste in the tab character. Note also that this will not function on a Mac.
It is possible to mitigate this by using third-party apps (I just confirmed this using a Keyboard Maestro macro with that trigger to open a Drafts URL to trigger the action by name), but that isn’t a recommendation that it should be done; simply a statement that it could be made to work.
I think I would not want automatic renumbering for numbered lists. I use 1. for all my numbered list items so that I can reorder them and it not look silly. However, if reordering fixed the numbering up that might be OK. But I often export my Markdown to eg BBEdit and then I lose the benefit of 1. throughout.
So automatic renumbering would have to be an option.
I’ve installed and abandoned Drafts over the indent/outdent “problem” several times already. This time I went with a pro-subscription so I can hopefully fix the problem myself. Is there a way to remove the [expletive deleted] modifier key restriction from the indent action and use tab to indent?
Using 1. for all ordered list entries is my convention as well, as it gives the greatest interoperability across the Multimarkdown tool chain I use, and also gives flexibility in re-ordering list items without the need to renumber - everything gets renumbered in rendering anyway. (Though I’ll admit seeing a mis-numbered list bugs me more than it should.)
My one pain point on indentation is getting the correct number of spaces at the start of a line to create a nested (indented) sublist. It has to be more than three spaces in the CommonMark standard, but four produces more reliable list nesting, at least in my tool chain. Would tab->space conversion need to be a settable option?
that’s the reason why I abandoned the German layout for good some years ago. The idea to put the german umlauts on that keys is a typewriter decision from ages ago. But I should not start getting me into this topic again.
But a nice solution is the international and swiss keyboard way to put them as a special character if typed after double quotes.
This is a bit getting used to (you have to teach you “ + space for quotes) but it is really lovely to have all brackets and braches where they should be - at least if you do as much programming like me.
Also you can go nuts and buy yourself an Ergodox - then place it wherever you like.