After a prolonged period of absence while one or more of the highlight expressions have been triggered there is no easy way (no way at all actually) to find out what exactly happened, what exactly triggered the highlight. Reproducible: Always Steps to Reproduce: Join a few crowded channels, setup a few highlight expressions, wait until one or more of them are triggered, then wait even longer until it has scrolled out of view and is buried in the noise. Actual Results: The tray icon is blinking but its not giving any clue which highlight in which channel was triggered, clicking it will present me the konversation window but the only information are the colored tabs of the channels that contain the highlights. Expected Results: The following things would help: * a keyboard shortcut to search backwards (cycle through) the highlights in the current channel, this could for example even be F3/shift-F3 when the search expression is empty * a window similar to URL grabber that lists all highlights and lets me click them to navigate to the channel window and exact position of the highlight instantly. * (optional) more information in the tray icon, maybe a menu that lists all recent highlights, so I can navigate to the relevant channel and position instantly. I'm not sure whether this could also be implemented as a plugin or an external program, it would need to be able to remote control the UI (navigate to a given line in a given window) or even create its own (pseudo-)channel window to emulate something similar to the URL grabber and then of course it also needs to be able to make these entries clickable to link them back to the original channels where they came from. I don't know how powerful the API is in this regard to implement this without ugly hacks but even if it needed ugly undocumented hacks and worked somehow it would already be an improvement over the current situation until its properly implemented in konversation directly.
Also relevant in this context is this https://bugs.kde.org/show_bug.cgi?id=155195 which essentially tries to address the same usability problem, maybe the final solution could combine these ideas.
*** Bug 341313 has been marked as a duplicate of this bug. ***