Changing the rule for word-jumping navigation?

[Iritscen]

I use Option-left/right arrow to jump across words very frequently in BBEdit and everything else I edit text with.  Different apps have different rules for how the cursor will jump.  macOS itself (judging from TextEdit) counts punctuation as part of the adjacent word when jumping, but BBEdit insists on stopping on each side of punctuation when it comes across it.  For instance, the phrase "Option-left/right arrow" takes six presses of Option and an arrow key to move the cursor from one side to the other, but only four in TextEdit, Nisus Writer, and some other apps.  Is there an option to change this behavior in BBEdit so I don't feel like I'm constantly being hung up as I navigate this way?

[Rich Siegel]

On 5 Jul 2024, at 20:38, 'Iritscen' via BBEdit Talk wrote:

> I use Option-left/right arrow to jump across words very frequently in
> BBEdit and everything else I edit text with.

BBEdit's behavior predates the macOS intrinsic behavior by a couple of decades; there's an argument to be made that the upstarts got it wrong. :-)

That being said, there's an expert preference that can be set via Terminal command, which may do what you need:

defaults write com.barebones.bbedit Editor_ModernWordMovement -bool YES

(This takes effect immediately; there is no need to restart the application.)

It's unsupported and there's no guarantee that it'll do what you want without side effects, but it might be worth trying anyway.

R.

--
Rich Siegel Bare Bones Software, Inc.
<sie...@barebones.com> <https://www.barebones.com/>

Someday I'll look back on all this and laugh... until they sedate me.

[Iritscen]

Interesting, thanks!  This does "fix" (from my standpoint) the way word jumping works, though oddly not in all documents.  If I place the phrase "https://github.com/Some-Org/some-repo" in a .txt file, it takes 6 uses of Option-right arrow to navigate through it, but if I simply change the document suffix to .html, it takes 13!  (That is, the normal word movement kicks in.)  Not sure if this is intentional.  I tested a few other suffixes at random (.pl, .py., .md) and they all use "modern word behavior" like .txt files do.

[Rails Smith]

Such a cool question that revealed a very interesting detail.

Thanks for asking that. TIL!

[Tom Robinson]

I love tidbits like this, it's as interesting as reading some of the release notes :]

[Marshall Clow]

Back when bits were scarce (a floppy disk was plenty of storage), and dinosaurs roamed the earth, there were several development tools in common use on Mac OS,

with names like “Think Pascal”, and “Think C”, and “Macintosh Programmer’s Workbench”, and CodeWarrior, and (of course) BBEdit (and others)

Many of us used more than one of them, and they all had subtly different behaviors for keyboard shortcuts and navigation.

Some of us lobbied for all of them to behave the same way - that’s where the (unintuitive, but oh-so-useful) Cmd-F (ok that’s intuitive), Cmd-G, Cmd-H, Cmd-E command-key equivalents came from.

The start-of-line/end-of-line/start of file/end of file/next word/previous word/and many more behaviors were discussed heatedly about the same time.

Also the ones that scroll the window w/o changing the insertion point.

— Marshall

P.S. One of the reasons that I love BBEdit’s shell worksheets is that I can move around in the window w/o thinking about it - instead of remembering whatever the shell provides.  Ctl-E to move to end of line?