Tbx 10 - Changed Arrow and Return/Enter keys operation

[archurhh (Art Currim)]

I’m having a little trouble getting accustomed to the modifed key operations in Tbx 10 - I see that this change has affected my Note-renaming actions.

While renaming a Note:

1. If I press Shift-Cmd-Return and then the Up arrow key, it used to be that the cursor would hop to the beginning of the Note’s Name. Now, pressing the Up arrow completely abandons the current renaming operation, and skips to the Note above the one I’m currently on. Naturally, a similar anomaly occurs when pressing the Down arrow - Tbx abandons rename operation, and skips to the next Note.

2. If after completing whatever renaming I want to (for example I change a word in the middle of a Note’s Name), then hit “Return” to effect the name change - the result is messy. Rather than record the new Name, my Note splits out into the existing Name truncated at the cursor position, and whatever text followed the cursor position is split out into a new blank Note.

Of course, I could re-train my muscle memory to press cmd-Left arrow and cmd-Right arrow after pressing shift-Return in order to jump to the beginning/end of the Name field, but it’s an extra keypress and also doesn’t seem concordant with Mac renaming behavior.

Similar with completing the rename - what key would I now press under Tbx 10 (other than Up Arrow and Down Arrow) to effect my name change without having the Note split out?

Lastly, please note that since I don’t have my extended keyboard while on the road, the Cmd-8 toggle for "Enter Key: " does nothing for me - the MacBook Pro keyboard has a “Return” key. Therefore I wonder if the Ctrl- key could be deployed to offer the same options for situations where there is no extended keyboard available?

Thanks!

[mwra (Mark Anderson)]

Fn+Return sends the ‘Enter’ key value if your keyboard has no stand-alone Enter key.

[Maximus (Max)]

I’ve just tried to reproduce this. Pressing Fn+Return occurs the same action - splitting note title into two notes.

[mwra (Mark Anderson)]

I think we’re confusing two things. Formally, the Return key () and Enter key (⌤) are two discrete keys with potentially different effects. To confuse matters the Return key is often colloquially referred to as the Enter key. I think this was because some early keyboards had ‘Enter’ on that key. We forget that conventions take a while to settle. The Return key simulates the typewriter action of both advancing the paper up a line and returning the carriage to the start portion so the next key strike starts a line.

@Maximus

Pressing Fn+Return occurs the same action - splitting note title into two notes.

Thus a separate issue is whether Return and Enter do different things in given context: that relies on the app and/or OS. My notes on Editing note titles in Outline view make no mention of the Enter key so we can only assume what it might do. From the report above it turns out it does the same as Return.

The problem, as explained by @archurhh is that whilst the new method enables a neat mechanism for a subset of users with a particular need, it messes things up for others.

Also, such task-based behaviours can be quite nuanced. I generally work in the current beta and never mistakenly split a note since the change was made. But, that simply indicates I don’t often leave a title edit with the cursor not at the end. I’m guessing the (most) active beta testers are the same, which is why this only got raised post v10.0.0 public release. In a toolbox like Tinderbox it is really hard to test every key/task combo, especially things you don’t naturally do yourself.

Now this is raised, my 2¢ on this is perhaps Return should go back to its old behaviour (closing the edit) and a modified Return (or Enter) be used to split the title. The point being, especially as only extended keyboards have a physical Enter key), is the need to press an extra key to get the normal default result. IOW:

• Return () exits title edit—regardless of cursor position.
• Enter (whether as ⌤ or fn+↩) spilts the title at the cursor position

One could posit the new title editing as a separate mode, but I suspect it means few would discover it and so use it when pertinent.

In my article (link above) I realise the documentation of these new features make less sense than it should because they are tuned to a particular use that perhaps is not widespread. Adding a description of the designed-for use case might make the article more easily comprehended. Does anyone have a succinct description of the use being facilitated by the change? There is no good/bad here just different. But understanding why the app supports things we ourselves may not use/need can help explain what for our own style might seem annoying or an error.

I think back to the long period is v5 (v4?) when title edit in view got added and there were, ah, differing views on the delay period of click-hold before edit mode was triggered. Some things take a little bedding in.

[Edits. Sorry write the above this AM on the way out and didn’t proof well enough. Hopefully now better ]

[archurhh (Art Currim)]

Thanks for the context and your thorough analysis of the change, @mwra!

As mentioned in yesterday’s meetup, my feeling on it - other than the fact that I routinely rename (almost every one of!) my Notes - is that it seems more intuitive to use a modifier key when force-splitting a line, which is the convention even in general note-taking and text editor use.

I haven’t had occasion to split long Note names into separate Notes - in fact not ever, come to think of it. I can however see the facility of single key presses for Note name splitting when generating rapid Notes.

Still though, it is a little frustrating that there is at present no single key I can press to effect a name change, just as I would in say the Finder while renaming a file, or as I mentioned above in a text editor where I’d press Option-Return or Command-Return to force a line break; but that is just my personal and long-accustomed habit.