Bug 179039 - GUI for BASH (possibly other shells as well) autocompletion feature
Summary: GUI for BASH (possibly other shells as well) autocompletion feature
Status: RESOLVED LATER
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-29 12:21 UTC by Roman S.
Modified: 2009-01-10 16:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman S. 2008-12-29 12:21:22 UTC
Version:            (using KDE 4.1.3)
Installed from:    Unspecified

I think most of the AmigaOS know a program called KingCON - it is a console handler (something like terminal emulator in Unix/X11, but not quite), which brings some nice features over the standard AmigaOS handler - one of them is filename autocompletion. This is how it works on Amiga (well, more or less):

- user types some command and (possibly) a part of filename
- user presses the TAB key (just like any BASH user would)
- if there is just one possible match - it is autocompleted, just like in Unix
- if there is more than one possible match - a dialog box (requester in Amiga terminology) with all the possibilities is displayed - user is able to pick a file or even browse into directories

I think it would be nice to have such a dialog box in KDE (of course, as an optional feature - some people might prefer the old way). The question is, how to implement it properly. I can think of two ways:

1. Intercept TAB key in terminal emulator, display dialog box (check what the user has already written to provide all the possible choices), 'type' the choice into shell

Pros:
- does not need any change in the BASH, ZSH, etc.

Cons:
- hacky solution
- needs vast knowledge in Konsole - about different shells, and processes running on the terminal
- any mistake may be very annoying, i. e. for user pressing TAB in the Midnight Commander

2. Provide a DBus interface for communication between shell and terminal emulator

Pros:
- more elegant, 'unixish' design
- DBus interface can be used in any shell, and by any terminal emulator, like the Gnome Terminal
- such an interface could probably be used to deliver more interesting features in the future (console app could explicitly tell the terminal emulator when it displays the HTTP hyperlink, so no more guessing would be needed, etc.)

Cons:
- need some changes in the shell itself (but I think if BASH developers could be convinced, the rest will follow sooner or later) - this will certainly need a lot of social skills to accomplish :P
- changes to the shell needs to be done carefully - it should still be possible to run BASH if DBus fails to operate for any reason, or even if it mas deleted from the system
Comment 1 Robert Knight 2008-12-29 18:41:56 UTC
I like the feature itself - code-completion style popups for auto-completion in the shell.  I have thought about this before - the first suggested approach is I think unfeasible for reasons you have already listed.  The second suggested approach (using D-Bus or some similar protocol for shell <-> terminal communication) would work locally but what about through network connections (SSH etc.)?  

I also do not think it would be a good idea to add D-Bus based communication to traditional shells like zsh or bash.  These programs have operated the same way for decades and I can well imagine that people have come to depend on this behaviors or would be upset if major new dependencies were added to them.  Plus their code-bases are written in fairly low-level C and therefore not that efficient to prototype or experiment with.  For these reasons I think it would be better to start with a new shell, either from scratch or maybe by adapting an existing project like ipython, ossh or the hotwire core.
Comment 2 Roman S. 2008-12-29 21:25:44 UTC
The SSH is a real problem - maybe even impossible to solve in an easy way. AFAIK, on the Amiga it does not work over a telnet too. I guess the system administrators will have to stick to the old way. Still, it would be a nice addition to people tampering with their local machine (I think this is the most common shell usage).

> These programs have operated the same way for decades

That's why I think it is a great time to change it. This behavior simply does not suit modern GUI desktop. It still does work well if we have just few possibilities, but today we can have thousands of them - in this case it is a real pain to use a console to find needed file, without any hints regarding its type, whether it is executable or not, without any ability to sort the list by file creation time, etc.

> and I can well imagine that people have come to depend on this behaviors

I don't think this is a problem at all - you can always provide a way to disable this functionality and revert to the old way. Possibly dialogs can be enabled by default, but each dialog box could provide 'do not show me again and revert to traditional autocompletion' option. Or, alternatively, the first time the user sees the dialog, he may be presented with a short guide about its usage and instruction how to disable the new functionality.

> or would be upset if major new dependencies were added to them

I don't think adding new dependencies will be necessary (in fact, I would be upset also...). I think about some dynamically-loaded library (a kind of 'dlopen' loaded 'plugin'), exposing just a simple, standard, pure-C API to the shell, and doing all the communication to the terminal emulator by itself. An environment variable (my preferred solution) or some configuration file (or both) could be used to inform the shell where to find this library. Or the library could be located in some standard place. No new dependency to the shell would be needed at all, just some (I hope minor) code changes to the shell.

I have another idea - in case the GUI is not available, the library could use ncurses to display some dialog :D

> I think it would be better to start with a new shell, either from scratch or maybe by adapting an existing project like ipython, ossh or the hotwire core.

This way we would lose the compatibility with existing scripts, we would have to completely change the way we are working. A lot of manpower would be needed, this could take years to develop and mature. And we would still need some open and well-defined way to communicate with the terminal emulator...
Comment 3 Robert Knight 2008-12-29 22:58:03 UTC
> That's why I think it is a great time to change it

You miss my point.  If people start bash or zsh they expect it to work a certain way, have certain features and configuration methods etc.  If you take a lesser-known shell as a starting point you won't have that problem.

> No new dependency to the shell would be needed at all, 
> just some (I hope minor) code changes to the shell. 

That might work - show me a prototype and we'll see. 

> This way we would lose the compatibility with existing scripts

Scripts have a line at the top which specifies what to run them with and if they don't, 'sh' is assumed.

> in this case it is a real pain to use a console to find needed file

I can honestly say that I rarely have much difficulty finding files - though I work mostly with source code in a variety of languages so its just a case of switching to the top level and recursively searching the text using Vim's built-in tools, possibly using a tag file - since I'm usually interested in a specific definition or function rather than a particular file itself.  Can you give me a more specific example of when you find it difficult to locate something?
Comment 4 Roman S. 2009-01-01 12:31:33 UTC
Prototype? OK, I guess I may try to write some kind of 'proof-of-concept'.

> You miss my point. If people start bash or zsh they expect it to work a
> certain way, have certain features and configuration methods etc. If you
> take a lesser-known shell as a starting point you won't have that problem. 

That's true, but if we take some less-known shell, than hardly anyone will even notice the new feature, because hardly anyone uses such a shell... Still, I think the change would be rather minor comparing to, for example, the new way of placing icons on the desktop in KDE 4.1 (however I like the idea, despite it works differently from all the mainstream systems used during the last 20 years), or the Kickoff menu (which I find unacceptable, even launching apps from the command line is more convenient to me).

> Can you give me a more specific example of when you find it difficult
> to locate something? 

I have a directory full of pictures downloaded from the Internet (thousands f them), some of them have really long filenames. I wanted to pick one of those for a CLI command, but I did not remember the exact name (I remembered, that I have downloaded it about moth ago). Probably this could be located using some fancy CLI command, but I am not a console guru - for me it was easier to launch Krusader.

Another example - I wanted to launch some command. I used it some time before, but I wasn't sure about its name - in fact, I only remembered for sure, that it starts from 'x'. Reading all the output from 'TAB' press using a GUI window (which would disappear as soon as it was not needed anymore) would be much more pleasant. I had to clutter the console output with hundreds of command names, which only made my work more difficult, when 5 minutes later I wanted to look back for output of some previous command.
Comment 5 Robert Knight 2009-01-01 20:19:10 UTC
> That's true, but if we take some less-known shell,
> than hardly anyone will even notice the new feature,
> because hardly anyone uses such a shell...

Any new or lesser-known 'brand' (commercial or not) will have that problem and yet there ones which succeed.  I personally am unsure whether trying to wrestle bash or zsh into shape would be sufficiently productive.  If I were just trying to add popup auto-completion and absolutely nothing else then maybe - but given the use cases you outlined above I think you need more than that.  

> I have a directory full of pictures downloaded from 
> the Internet (thousands of them), some of them have really long filenames.

If you're trying to find a picture or music without suitable tagging or some other text mapping then a text based terminal really isn't the right tool.  I would use Dolphin or Gwenview for this - both of which support image previews and simple image manipulation.  Dolphin can sort and group files by date/type/size etc. as well and in KDE 4.2 the preview size can be scaled interactively via a slider bar at the bottom of the window.  Alternatively you can use a program like imgseek which provides content-based searching (I believe Digikam has this as well in very recent versions) where you can find a picture using a crude sketch of the content.

Although to be quite frank, if I wanted to find a picture again which came from a public source on the web then using Google/flickr/MSN Live image search might well get the quickest results.

> Kickoff menu (which I find unacceptable, even launching apps
> from the command line is more convenient to me). 

How are you using it?  Normally I would just click on the K-Menu button and select the icon from the favorites list.  If it isn't in the favorites list then just typing in 'movie', 'music', 'burning', 'game', 'terminal' or similar finds appropriate applications and you can then launch them with the mouse or the keyboard.  If I wanted to browse through a selection (eg. to find a game to play for a few minutes) then I go to the Applications menu.

> Reading all the output from 'TAB' press using a GUI window (which would 
> disappear as soon as it was not needed anymore) would be much more pleasant

> when 5 minutes later I wanted to look back
> for output of some previous command. 

In which case showing command help in a separate window is not going to be enough because you'll still need to skip past the output of previously executed commands other than auto-completion help.  You're right that the current shell UI is not very good in this respect - which is why people tend to execute similar queries over and over, possibly applying different filters each time.  A couple of options here would be 'folding' the output of commands so you could hide output from commands you're not interested in or the ability to recall the output of a previous command - some shells (sadly not bash as far as I know) provide this facility, for example http://hotwire-shell.org/.

I'm not saying that your suggestion (finding a way to display command help in a different window - like 'man <command>' does) wouldn't help but I don't think it would really address the problem either.
Comment 6 Roman S. 2009-01-09 21:11:23 UTC
You will have to wait some time for the demo - I don't have much time, but have some problems. For some strange reason I cannot use QFileDialog from within the bash context (prototype Qt4 plugin loaded using the same routines, in exactly the same way, but from within other task context seems to work). I wonder why... Probably I will have to use DBus (which I have never worked with) in my prototype. Or just use some temporary dumb low-level IPC for now :P

As regarding HotWire, I don't think it is a good solution:

- It is a Gnome application, and I do not like using Gnome applications in KDE just like I don't like running Wine programs - unless I use something rarely, usually I either choose native software or change the platform. It would be like canceling Konqueror, because everyone can use Galleon, which is also free and works under KDE.
- It is an all-in-one-solution - shell and GUI in the same project. You cannot change the shell, you cannot change the GUI that interacts with it. Definitely not an unixish approach.
- It does not work without XWindow (and it has a lot of other dependencies). You can't use it if X does not work, you have to learn TWO tools that does mostly the same.
- It does not integrate well with terminal emulation, it can only launch a terminal session - not for me, I still use Midnight Commander a lot...
- It will probably take years, before it will stabilize. Or it might be as well abandoned, like similar KDE project long time ago...

However, it may be nice to test new ideas :)

BTW. I do not think about command help, for now I just want some GUI for the path autocompletion. More complicated features, like exporting KDE/Gnome VFS to Midnight Commander, or making the glibc (maybe the kernel?) Nepomuk-aware, may come later :P
Comment 7 Robert Knight 2009-01-10 16:03:09 UTC
> - It is a Gnome application, and I do not like using Gnome
> applications in KDE just like I don't like running Wine programs

That's not important - we're interested in ideas and concepts here.  The actual implementation doesn't matter too much at the moment.  If you had something working and you wanted to make a big push for it to be adopted then implementation would be important.  Something like a terminal lends itself well to a core/ui split where the core is cross-platform and the UI is written in one toolkit or another - that's effectively what we have with existing Unix terminals.