I’m having trouble getting Agenda to do a kind of basic thing that a text note should allow me to do. I have copied data from a spreadsheet, and need to keep it in columnar form in a text file. In every other text/note app I can copy-paste, then use tabs to realign the text (it paste into every app a bit differently). But in agenda, when I hit tab, no matter where the cursor is, it adds a level of indention. Also, when I paste in the text, it restricts the line length for some reason, putting in a hard return. I can backspace and get the data to end up in one line, but then I can’t edit and re-align the text into orderly columns due to the inability to tab. It seems like Agenda wants to treat every piece of text as, essentially, an item in a list. But sometimes I need a note to be a note and to behave like a regular text editor.
We can look into possibly supporting standard tabs using alt-tab or something like that.
In the meantime, you might find it useful to use preformatted paragraphs. You can then use spaces to align columns, because all text is equally spaced.
If you need a line break without breaking the paragraph, you can use CTRL-Enter.
Thanks Drew. I was also, as part of this effort to get the result I wanted, importing text which I had formatted and pefectly aligned in another app, which does work as you say, but is quite inelegant and time-consuming, especiallyl if you’re going to be going in and editing the text at all. Thanks for considering the functionality.
Here’s something buggy though: while spending too much time on this, I noted a few things that there is an unsually long lag of various durations when using command-z, command-x, and command-shift-z. Also, while when using the delete key to delete a block of text the note block shrinks back to size immediately, when using command-x it takes a few sometimes very long seconds. Then when you use command-z to undelete, cursor and focus shifts to the note above.
Re: undo, while we could improve things in the 2.0 update, the undo system is still not where we’d like it to be. This is high up on our todo-list but non-trivial and requires some significant work that we’ll only get to after the iOS version is out and we have delivered the inline images support most likely.
I would strongly support the use of option-tab or similar to insert tab characters in text. This is universal and built into my muscle memory so quite surprising it doesn’t work in Agenda. Preformatted text is a rather clunky work-around (too many space characters). Tab functionality is not exactly new, has been around since typewriters were invented
We aren’t using standard tabbing behavior, because we are using it for indentation of paragraphs and lists, which is very important in a note taking app like Agenda.
We do plan to add option-tab or similar for standard tab characters.
Could you please reconsider this? In every other text based app I use, tab simply aligns text, makes a tab character. As far as I can tell, there is no need for this non-standard behavior of Tab, since you already have:
Format -> Indentation -> Increase ⌘[
Format -> Indentation -> Increase ⌘]
So why not have Tab just do what it always does?
Not actually the case. In most note taking apps, tab indents like in Agenda. Try it in Apple Notes or Bear.
But you have a point that it would be good to also be able to add a tab character. We will do that.
Thanks for the feedback!
That is decidedly not true. Let me demonstrate with a GIF. In this demo I am aligning all elements after a colon i Apple Notes with tabs, which doesn’t work Agenda:
Note that Agenda indents the WHOLE LINE, while Apple Notes + Bear + Any other notes editor under the sun I’ve ever tried, inserts a tab character, i.e. indents only all content to the right of the cursor.
With the current Agenda behavior, it’s impossible to align text elements using tabs in-app.
We’ll take a look at it.
Investigating a bit more, it’s not as simple as you think. Take Apple Notes. What you say for body text, ie, normal paragraphs, is true. It does insert a tab wherever you are.
But try it in a list style. You will find you can’t insert a tab, no matter where the cursor is. It controls indentation.
So the truth is somewhere in between. We will see what we can come up with.
I have no issue with Tab doing indentation of whole line in a list structure, that is even preferable. But we need the normal tab functionality in the body text.
Tab doing conditionally tab in body, indent in list etc. can always come as extra sugar later because we already have a dedicated command and hotkey for doing the exact same thing as Tab is doing right now, namely:
Format -> Indentation -> Increase ⌘[
Format -> Indentation -> Increase ⌘]
We will discuss this internally. I personally am not a fan of keys behaving differently based on where the cursor is. Indentation of body text is just as important in Agenda as indentation of list items, so why would the shortcut be different?
My preference is to allow alt-tab to get a real tab character. But that is just my take. We will discuss it and see what we come up with.
Thanks for the feedback.
Ok. I do hope you will reconsider. You already have indenting on ⌘[ and ⌘], I can’t see why you need to steal the Tab key for an additional hotkey to doing this. Conversely, it’s always quite jarring when text editing apps screw with the fundamentals of text input, e.g. ⌘←, ⌘→ not navigating to line beginning/end, tab not inserting tab characters / aligning text etc. Likewise ⌥+⇥ would be very weird for making tabs; If one gets used to it in Agenda, you just start making mistakes in all other text apps where it’s just ⇥ (which is the majority.
You gave Bear and Apple Notes as examples earlier. I hope this is an indication that you care about conforming to text editing conventions on Mac, despite your current preference. Hope you think about it
Alt-tab is a standard convention. Take Apple Notes, and try to put a tab at the end of a list item. No go. Then try Alt-tab.
So I am all for having standard key combinations, what I don’t like is having them behave completely differently in different circumstances. Eg. Apple notes: tab in body text, you get a tab character, even though it can indent. Tab in a list item, it indents, even though it could enter a tab character. So you end up having to think: what sort of paragraph is this? Do I tab or alt-tab. Bad, bad, bad.
I think my essential questions really is:
If tab normally have two different functionalities depending on circumstances and you don’t like this, having to choose one of them, why do you choose it to have the one that is already covered by another command (Indentation > Increase / decrease) and keyboard shortcut (⌘[, ⌘])? I can already indent in a different way; I have no way of inserting a tab! And it would be incredibly annoying to use Tab to do this in every other text editor out there, but remember to use Opt+Tab in Agenda.
Btw why does it matter that tab has multiple functionalities if this is a behavior that’s conventional across all text editing apps? I don’t get why the multi functionality of tab is so bad? It’s really clear under which circumstances it indents inserts tabs (when cursor is in list) or tab character (all other cases). Plus it’s a long-standing convention, so it surprises no-one. Is it because you’d like to be able to insert tab chars, i.e. align things in lists?
When I need to indent, I use tab. It is quite a lot more convenient, being a single character, than CMD-]. So there is another way, but for something so common in a note taker as controlling indentation, you want a really easy way to do it. (That’s no doubt why all the others changed the standard tab behavior too.)
I think this is basically a legacy issue that has crept over and polluted a nice UX design. Namely, in the beginning, tab was a tab character, full stop. Then apps with lists thought it good to use it for indentation, and so they branched the behavior, without giving it too much thought, and ended up with confusing UI. (If I had to guess, I would say this is probably MS Word, a beacon of great design.)
Anyway, the moment we stop trying to improve things, all is lost. I think we should take back the legacy, and have a consistent set of key combinations. Indentation is fundamental in Agenda, so it should get the easiest key combination. Tab characters are rarer, so we should assign option-tab for those.
I agree that we shouldn’t put too much effort into preserving legacy stuff of all kinds in general. But one man’s legacy is another man’s long-standing convention. I’m not completely dismissive about Opt+Tab for tabs, I just get very uneasy with convention on something as basic as text input being broken in any Mac app that is about text input. I just haven’t seen his Opt+Tab anywhere else in any other text based app, so that does make me uneasy.
I think I just don’t share your discontent with the dual functionality because I’m used to it being like that everywhere. I always know whether I’m in a list or not, so I know what to expect if I press Tab.
Anyway I hope you have a good discussion about it internally, and I’ll just have to live with whatever you choose. I just hope I’ll like it too
Oh and merry Christmas
Thanks, gandalfsaxe, for keeping this thread alive and spurring on this further, helpful conversation about somethign that’s important to me, too. I too didn’t know about alt-tab, but I think that must be because I rarely have a situation where I want to make internal tabs in a list, so say in Bear or in Notes, when I use tab its either to indent (expected) or to align items on different lines within a text block (expected), as you have illustrated above. The way all of these editors behave when test in a list is tabbed is not what I would expect, anyway: if I have a cursor placed halfway down a line of list text, why would I think that hitting a tab (based upon a lifetime of understanding how a tab works, from the cursor forward) would indent the entire line or text block? I would never even think to try that. What I do is back the cursor up to the start of the line and tab over (or, in the presence of a key combination such as Agenda has, use that). The simplest solution, it seems to me, is to let tab operate as a tab in those situations where reasonable people with 40 years of keyboarding in their muscle memory would expect a tab to work (indenting, and aligning text in a text block) and let those with edgier cases (putting a space in the middle of a list item) discover the exception (alt-tab). I’m all for being opinionated, but saying that the same key, like tab, can’t have two functions this late in the history of tab having two functions, seems user-unfriendly.
There are things I do in Bear, and did in Notes before that (the use case I described in the first post, aligning tables copied from excel into orderly text, for one) that I’d like to move to Agenda, and it seems a small capitulation to the-way-things are to adopt conventional behavior in this way, even if now how you’d design it from scratch. (now we are overthinking it!). No one wants an app to over-dictate how it’s used, expecially one so flexible in so many other ways, but Agenda seems biased toward the list, and doesn’t especially welcome being used as a text editor, although that’s how some (many?) of us want to be able to use it, when that’s what the occasion calls for. I keep returning to Bear for things, I guess, now that I think about it, because it puts up few-to-no obstacle to me putting text where and I want it (and undoing itself when I don’t — please please fix Undo!)
Because as you say, inserting a tab in a list item is very rare, and the chance that you want to indent is much much bigger. I think that’s exactly why for example both Notes and Pages indent, like Agenda, also when mid-sentence in a list item.