when Linux user edits /etc/* configure files there is a need for information about the fields of the configuration file. when a program outputs something to terminal window in graphical user interface, user may need an explanation about fields. (for example top (dynamic fields) or w (static fields)) second window in graphical user interface tells about unknown fields in first terminal window when user points a field by mouse pointer in first terminal window. when user points with mouse pointer a second field, help window tells information about the second field. when mouse pointer is outside any fields or terminal window, second window clears. if user points with a mouse pointer a filename in ls list, second window tells meaning of the filename. (for example pointing by mouse /etc/hostname file opens a window that tells this is storage place for name of the Linux machine). when user points with mouse pointer /etc/fstab field in editor window, last field in line is told about in second window. in this case 0 means 'check file system in every bootup if this field is zero'. second window tells what happens with the current zero value and what happens with a value one (no filesystem check in bootup). all this decreases reading of man and info pages and saves time a lot. Linux user does not need to read man or info pages so much anymore. Reproducible: Always https://plus.google.com/112754225451566107654/posts/p/pub?hl=fi
If I understand you correctly, you want "context help" in Konsole. This is impossible, because Konsole only displays text, it has no idea that the text it displays are file names or input fields with a certain meaning. You would need a special text console application which knows how to interpret the fields you are editing. I suggest to resolve this as WONTFIX.
program knows commands which are given. bash has environment variable which stores last given command and another environment variable which stores current working directory. command history can be read from ~/.bash_hístory. implementing this context help feature helps Linux novices a lot.
mika, an environment variable which stores the last given command tells quite a bit less than you think. First of all, it's _not_ an environment variable, but a shell variable. It's an internal data stored only in bash, other programs can't get to it. Even if bash exported it as an environment variable, it doesn't actually set its own environment, only in its children. And even if it did set it in its own environment, it wouldn't be reliably readable by Konsole. Reading other processes' environments than your own is not a portable or reliable activity. What if the running program is as root (e.g. via sudo), but konsole is running as a normal user? Finally, even if Konsole could reliably get access to "the last command bash ran", how would that help it to do what you asked? Your feature request not only requires that Konsole know the command currently running right now (that is, "the last command" is way too late), but how it operates, and what the semantics are of everything it draws to the screen. Even if Konsole had a database of all the possible editors you could use (which would be huge) and how they work, it'd still be difficult for Konsole to do that - the only real, working way, is if the running application had a means to _tell_ Konsole what it's doing and where. In other words, it would be a huge and fragile project that's far outside actual scope as a terminal emulator. HOWEVER: there is at least one project that does things similar to what you're asking for (not the editor stuff, though - that's just really too hard). Like, allowing you to click on a file listed from "ls" in order to perform some action on it. As far as I know, it doesn't give a lot of contextual information by hovering over filenames, but they probably have the capability to do so, and might be open to a feature request like that. It is experimental and incomplete, and can't do it for everything. It mostly works through a combination of tools that talk to it explicitly about what they're doing, and some programs (like ls?) whose output format is unambiguous enough that it can be parsed for information. Unfortunately, I've forgotten the name of this project, and don't know if it's even still maintained (a project like that would be quite daunting, and require rewrites of most standard Unix tools to make their own versions that can work with it). Maybe you'll have better luck than I at finding it again... but it's not something that really falls within the range of things KDE could realistically do. I did find this, which _might_ be what I was thinking of: https://github.com/black-screen/black-screen As I say, it's far from complete, and I don't even know if it actually had the features I was thinking of (clickable ls listings, etc). But basically anything that does what you say would probably have to be a combination terminal+shell+utils, not just a terminal. Good luck.
I'll close this as unlikely to be implemented.