Hacker News Reader

Comment by salgernon | Hacker News Reader

Back in 1991 I was at Sun and tasked with implementing type-to-complete for file dialogs in OpenWindows. Coming from a Mac background, I naturally implemented... type to complete. But the OpenWindows Spec declared it should be "first letter, keep typing first letter".

That method requires you to very explicitly look at what is selected each time you press 'B', as opposed to just typing 'bagend' or 'bilbo'. Maybe it makes sense if you can't type? In any case, I added a secret preference to do it the right way, and then quit.

Imagine if the web browser incremental search worked that way...

View on HN

I agree.

That's the behaviour that I programmed for the listbox in the Address Book for Microsoft's email product, which you should see in MS Outlook (they might have changed the behaviour since then).

The main difference for that address listbox versus most listboxes/listviews is that the address listbox will update the display to show the sublist of matching items (and do the hard work of updating the scrollbar to show the size of this sublist and how many items are in view).

The expectation was the user would move the cursor with arrow keys or type more or the desired substring if the cursor wasn't placed on the desired item.

It's crucially useful for menus, where the items are always the same, arranged in the same order. When you use a certain menu item often, you know to press (say) Alt+M-C-C. And it's not unusual to have several menu items with a long common prefix, so typing a prefix wouldn't be efficient. This is particularly useful in long menus that ran out of accelerator keys, or in extensible menus like the Explorer context menu where not all extensions care to define one, or do conflict with each other.

This is also the case when navigating folder hierarchies in Explorer, which, using letter navigation, is similar to navigating nested menus. After a while I know that a certain folder is L Enter C Enter S S Enter P P Enter, and that way is offen quicker than going by prefix sequence (second method), also because you can hit the same key in sequence faster than different keys.

> And it's not unusual to have several menu items with a long common prefix, so typing a prefix wouldn't be efficient

Especially not on systems where companies think your file system and the start menu are advertising space. That gets you multiple entries starting with “Microsoft ”, “Adobe ”, “Google ”, etc.

Yes, it may (still) be possible to rename those (for third party applications, you can on MacOS, for example), but I bet most users won’t do that.

While it's key sequence specific, you can't (in genera) hit the same key faster since you can only hit it the second time after it's been released while you can hit another key while the first one is still down

Another more intuitive solution for menus with long common prefix is to simply type the next unique letter: pa or pb in

PrefixA

PrefixB

No need to type the full PrefixA

If you run out of accelerator keys, any key you type will activate an accelerator, so you wouldn't even have a way to do a sequence? So there is simply mode 2 possible

And folder hierarchies aren't stable unlike menus, so you loose precision if another folder is created /deleted.

Though if you really have to frequently use such long sequences it might be easier to add this folder to a custom favorites panel and use two keys: shortcut to invoke a panel, P accelerator for the name

> In any case, I added a secret preference to do it the right way

It's harder to do these sort of guerrilla things when every line is code-reviewed. Or maybe you snuck it past your peer?

There wasn't a lot of code review going around our group in 1991 - but you're absolutely right that it would be harder to get away with today. There are a lot of hidden knobs in various places across various systems, and they are a potential liability since they're frequently untested and may even be a vector for an exploit...

sudo dtrace -qn 'pid$target::getenv:entry { printf("getenv ( %s )\n", copyinstr(arg0)); }' -c "/bin/ls -l"

> That method requires you to very explicitly look at what is selected each time you press 'B', as opposed to just typing 'bagend' or 'bilbo'. Maybe it makes sense if you can't type?

It makes sense if you can type: that is, if you can type while looking at the screen instead of the keyboard because why would you look at the keyboard? To find the keys you want to press, one by one?

Remember Mitch the XView guy who always wore Hawaiian shirts?

Reply on news.ycombinator.com