I dont know if this is a bug of kile or kde in general, so I post it
here, also to see, if you can reproduce it or not.
I am using Version 2.0.85, Using KDE Development Platform 4.4.5 (KDE 4.4.5)
Customised shortcut settings for ambiguous shortcut reset if changing
the user-text ('apply').
There is already a short-cut defined for <Ctrl>-<Shift>-6 ('Select to
matching bracket'), which collides with the generic user-tag shortcut
for the 6th entry (these start from <Ctrl>-<Shift>-1 for the first entry
to <Ctrl>-<Shift>-9 [or -0, dont know])
Steps to reproduce:
- define 6 different user-texts in latex->user text
- use shortcut <Ctrl>-<Shift>-6 to insert text - a shortcut ambiguation
box will appear:
> The key sequence 'Ctrl+Shift+6' is ambiguous. Use 'Configure Shortcuts'
> from the 'Settings' menu to solve the ambiguity.
> No action will be triggered.
- configure shortcuts -> change shortcut for 'Select to matching
bracket' to something else (e.g. none)
- use shortcut 'Ctrl+Shift+6' to insert text: OK, working
- change any user text in latex->user text -> apply
- use shortcut 'Ctrl+Shift+6' to insert text: not OK, the shortcut
ambiguation box will appear, since the shortcut for 'Select to matching
bracket' was reset to default.
So I suspect the shortcut is set on 'apply' changes in user-text and
accidentially restores the wrong defaults?
My workaround is not to use the 6th entry...
Thank you for your work,
From: Nicolas Pavillon <nicos_pavlov@us...> - 2010-10-16 00:03:45
I am writing on the mailing list as I am not sure if this is a bug, or a normal behaviour. However, the pattern seems odd enough to me to think that it could be a bug. I am using latest kile svn (currently rev 1186350 on KDE svn), with KDE 4.4.5 installed on Mac.
I have a rather large project handled in Kile, where a main document calls various sub-documents (chapters) with \include. Then, each of those sub-documents call sub-sub-document (sections) with \input.
When opening the project, what I assume to be the correct behavior would be to have, in the project tree, the sub-sub-documents of chapter 1 listed below chapter 1. This behaviour can be obtained, but not in all cases. Everything goes fine if the project has no opened files, but in the case some files were opened when I quit Kile, the next time I open it some files are not at their right place in the project tree, and some labels do not seem to be registered for auto-completion, precisely from the files not correctly placed in the project tree.
If I close all documents, quit Kile, and reopen the project without any opened documents at start, everything comes back fine.
I assume that opened document interfere in a way or another with the project tree at program start. I also noticed that version beta4 seems to have a slightly (but also odd) behaviour.
I did not dig further at this point, but I would be happy to investigate further if I get some directions.