Path Completion Using Tab Key Like in Bash on Linux

Maybe the 'CLI QUICKGO' could be modified to behave like that and the path field could be left alone?

(As an aside, this kind of hyperbolic writing, about something like the choice of one key vs another, is a great way to make people stop listening.)

Have you used Windows? The way it works in Opus, a Windows application, is the way it works in Windows generally, including the similar address bars in Internet Explorer and File Explorer / Windows Explorer.

It may not be exactly what you are used to, coming from another operating system, but it works well once you give it a chance, and is the standard on Windows. Unless you find the up and down arrow keys difficult to press for some reason.

+1 for this feature. I would prefer nothing to happen as opposed to erasing my progress.

There is a bit of difference between DOpus and BASH though. BASH is a console you have no where to tab to, DOpus has a UI and tab in UI and web applications move you to the next or previous filed. So this is/was a rather logical choice.

However I also think this could be improved. Modern browsers don't allow tab out of the address bar once you start typing. This works quite well and would be a welcome change to DOpus.

Hi Leo,

I don't mean to beat you up. :slight_smile: I care a lot about great software design, and I think that DOpus badly needs two fixes.

I understand that you want to be consistent with File Explorer. But I wonder if you've read this:

It's all about efficiency. It's fine to be consistent with the default way that File Explorer works, but since DOpus is supposed to be an improvement--and a highly configurable one at that--it should have the option of working the way that most of us want and expect, from our experiences with some form of UNIX. This isn't an arbitrary request, but one that comes from decades of experience from many users. This is why I urge you to look very closely at how bash works on Linux. There's an enormous opportunity here that involves a lot more than a mere change of one key, from backslash to tab. When we press tab, we don't want the directory path that we've tried to construct to disappear because the focus has moved to another field in the UI!

I urge you to always ask two questions:

  1. What are the most common use cases?
  2. What's the most efficient way of enabling the user to perform them?

I believe that the way that File Explorer works by default is extremely inefficient, and that the way that bash auto-completion works represents a superior solution that you can easily implement. I'm not asking you to change the default, only to make an improvement that can be optionally enabled.

Please, investigate this for yourself. You'll never believe me until you convince yourself, and unless you try bash for yourself and really play with and study it, I don't think that you'll be able to appreciate the genius design.

Also, DOpus advertises spring-loaded folders in the folder tree view, but this isn't really true. I have a dozen favorites folders that appear in the tree view. When I drag a file over one, nothing happens. There's no spring-loading. It's true that this happens for non-favorites folders, but why doesn't it happen for favorites folders? It should all work the same--consistently. Also, it doesn't make sense to have (partial) spring-loaded folders in the folder tree view, but no spring-loading of folders in the actual lister views to the right of it. It's not just that Mac OS does this that's relevant; it's good design and saves a lot of time. See questions 1 and 2.

No offense intended, guys. I just want DOpus to be the great product that it can, and should, be. Please make these improvements ASAP. All of us will benefit greatly because of them!



It turns out File Explorer (always) uses tab and shift-tab as synonyms for down and up in its own path completion UI, at least in Windows 7 and Windows 10 that I have tested on.

Accordingly, we have added the same in Opus for the next update.

I don't think the option in the article you linked is relevant. It doesn't change how the tab key is treated or turn path completion on; it makes it so the first match is automatically typed for you as soon as you type a prefix of it.

FYI we are very familiar with Linux and several other OS, including Windows itself, where command prompts / text-mode shells / CLIs cycle through path completion matches via the tab character. This is not esoteric knowledge. :smiley:

Not that it has anything to do with this thread (FAQ: Ask one question per thread), but favorites in the folder tree cannot be expanded at all, by design. The favorites branch of the tree is intended to be a fixed list of shortcuts that stays at the top of the tree, so the list is always in the same place and structure for you to pick a favorite from. If it expanded, it'd become a mess and no more use than the main parts of the tree. As you navigate to another folder from a favorite (e.g. the child of a favorite), the tree jumps to the real location of that folder. So the spring-loaded option doesn't apply there as those nodes in the tree don't expand. I guess they could just when doing drag & drop, but it's not something anyone else has asked for so far. (If you want to complain about this further, I suggest your Spring-Loaded Folders thread instead of here. That way, if someone else wants the same thing, they might find the discussion and add their vote.)

Hi Leo,

Yes, you've got it!

I pointed out the registry hack because I think that adding it in addition to tab/shift-tab would maximize efficiency. (I think about principles such as: Don't make the user type a single character more than absolutely necessary to get something done. Save the user time and effort wherever possible, and always try to minimize cognitive load. I think about these principles because I work with physicians who use electronic health record systems with screens that show all sorts of complicated fields that require lots of data entry; you'd be surprised by how much effort they go to to get IT to minimize scrolling, tabbing, clicking, mouse movement, etc. And that reminds me of another principle: Don't make the user have to reach for the mouse when the keyboard is available.)

I'll reply to your comments about spring-loaded folders on the other thread.



Nice, thanks @Leo.


(((Cheers from the bleachers!)))


Please keep one more thing in mind.

Open up DOpus. In the path bar, type:

C:\Program Files\ (Enter)

Now, type:

F4 (to select the path bar)

Then, type:


Notice that the whole path bar line is replaced with \ ! But I think that the \ should be appended to the selected path, so that auto-completion will continue. Currently, one has to press the right arrow, and then \ , to make auto-completion work in this case.

Since Windows doesn't recognize \ as a reference to a path, it doesn't really make sense for the selected path to simply be replaced by \ . Instead, it really ought to be appended to the end of whatever is selected, IMHO.

It'll be nice to have all of this working properly with tab/shift-tab and the windows registry hack feature, etc. The little details really do make a huge difference when you keep repeating an operation all the time; the time savings add up. Keeping the frustration (nuisance) level low is really important. Users don't like workarounds and extra key presses because they're frustrating and unnecessary with the right design.



Then it would be very difficult to type UNC paths which begin with \\.

In the next version we will add a Breadcrumbs Configuration argument, EditEnd, which positions the cursor at the end of the path, instead of selecting the whole path, when you start editing it. That should give you what you want without breaking UNC paths.

Gotcha. Fantastic!



Maybe this is almost irrelevant now. If you get features that you want, great, but what makes you think that most of us (Windows users) want them or have experiences with some form of UNIX?


As Leo said, DOpus, today, does not work in a manner consistent with how File Explorer works in Windows 10.


  1. In Windows, it's generally the case that pressing tab will move from one UI element to the next; but

  2. There is an exception: in address bars (e.g. in File Explorer), pressing tab does not advance to the next UI element. It auto-completes within the address bar.

Today, DOpus does not take account of 2, and Leo intends to fix it.

It's all about enabling users to achieve goals easily and efficiently. That assumption underlies all of my requests and suggestions.

And for the record, I'm a Windows user, but one who has used Mac OS, Linux, and many other OSes. The OS doesn't matter. Getting work done easily and efficiently does.



With the latest changes to the path bar, is there a way now to get down into the next folder and get the next dropdown of subfolders without pressing "\"? This character is still hard to reach on a german keyboard since it requires to press the AltGr qualifier as well, always requiring you to switch hand position. I tried tab and cursor-right, space, end and whatever seems to make sense, but navigating the folder structure down/up by using the path-bar/autocompletion is still not possible without that arqward "\" key-qualifier combo here, should it? I understood your upcoming changes would make that possible, if it wasn't. o) Confused! o)

You can use a / if that is easier to type than \ on your keyboard.

Thank you. o) Unfortunately this key-combo isn't any better. o) In the other thread I mentioned the use of the "CURSOR-RIGHT" key or pushing END to "accept" the currently autocompleted/selected folder, while the dropdown would present subfolders to continue the navigation. TAB would also work, if you could detect these keystrokes happen with the cursor at the right edge of the path field or the foldername still being highlighted. In case I use cursor keys to select the subfolder, it would also make sense to use tab for "accept" right away. If the tab key is used after using the cursors to find a folder, it will choose just another folder now. To wrap this up, this still is not there yet from my point of view.

Using "\" or "/" to accept the highlighted folder.. it kind of makes no sense at all to me, especially since it will work opposite if the highlighting was made by me, so it actually has a whole different aspect to it if you started to edit and mark in the path field on your own. I remember Jon being a fan of this, I never really understood why. o) The necessity to twist your hand to reach this key is the other thing for me.

I hope you realise that fundamentally the issue here is your weird keyboard :slight_smile:

I've made it so pressing END twice will turn into a path-slash. That seems fairly safe to me (unlikely to interfere with anyone's "muscle memory"). See how you find it in the next version.

I'm really not to blame for the german keyboard layout. o) Yours probably also requires to move the hand away from the cursor keys, no qualifier here, but probably also not the most convenient situation? o) Anyway, bet I'll check that double END thing! Thanks! o))

On a UK keyboard, \ and / are at the bottom left and bottom right of the keyboard, making them very easy to type, even when hands on the cursor keys.


US keyboard has / in the same convenient place, and \ just above the return key, which is also fairly easy to reach:


Seems the DE keyboard requires you to push AltGr + ß or Shift + 7 for either type of slash?


ES keyboard is similar:

A huge pain for keys that are needed constantly when dealing with filepaths on any OS. I'd be driven mad by that everywhere else, let alone specifically in the path completion of Opus's location field.