[Konsole-devel] [Bug 179039] GUI for BASH (possibly other shells as well) autocompletion feature

[Roman Standzikowski]

http://bugs.kde.org/show_bug.cgi?id=179039





--- Comment #2 from Roman Standzikowski <romanujan gmail com>  2008-12-29 21:25:44 ---
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...


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.