On 07/17/2007 05:37:17 PM, Enrico Tröger wrote:
On Tue, 17 Jul 2007 17:24:24 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 06/02/2007 11:12:58 PM, Dave Moore wrote:
A few other things I had in mind for it are:
- check to see if the pos were adding is already at navq[0] (to
avoid side by side duplicates)
- allow back and forward to be keybound
- add to nav queue when:
- clicking on a file in the compiler msgs window
- clicking on a symbol in the symbols list
- clicking on a line in the search results
- jumping to a line(?)
- clicking on a file in the open files tree (?)
- switching to a different tab(?)
- searching within a file(?)
I've added symbol list support, and preventing duplicates in the queue. I guess adding compiler and search results support might be good, although would they clutter up the queue? They seem to be temporary items, whereas tags are more likely to be returned to.
I'm not sure. Compiler messages could be nice but yes they are not that consistent. But maybe we could use some smart code which removes all navigation items in the queue from previous compiler messages. But to be able to do this, the queue items need some information about the source of the item. I don't know whether it is good idea at all. Seems like big overhead for little use.
I think if we add Previous Message and Previous Error commands then these should be sufficient, and that would keep the queue clean.
Also we might want to limit the queue length - e.g. discard the earliest item once we reach say 25 items.
I think so too. 25 seems like a reasonable limit although form me personally it could be a bit lower or we just make as a preference.
OK. I think queue items don't use much memory.
Regards, Nick