Ah, that only happens if SideKick is docked. I use it floating. Yeah,
that needs to be taken out. However, I still have an issue with a
floating SideKick where loading the parser removes focus from the text
field. When SideKick gets focus I would like the text field to be
focused. Is that an issue? If not, any suggestions on how to achieve
On Sun, Sep 28, 2008 at 11:04 PM, Alan Ezust <alan.ezust@...> wrote:
> Focus goes to the filter textfield now after any parse, when before
> there was no filter text field.
> That means sidekick grabbed focus. It shouldn't do that.
> You will only see it in the svn version of sidekick.
> On Sun, Sep 28, 2008 at 7:05 PM, Matthew Gilbert <gilbert@...> wrote:
>> I have "parse on buffer switch" and "parse on save" enabled and have
>> never had sidekick steal focus from the textarea? If it is doing that,
>> that is absolutely a bug. I'm surprised I've never seen it. Can you
>> tell me what Java and what parser? I'd like to be able to reproduce
>> that behavior.
>> On Sun, Sep 28, 2008 at 9:59 PM, Alan Ezust <alan.ezust@...> wrote:
>>> I have "parse on save".
>>> If I do "ctrl-s" to save, and that causes a reparse, and my focus was
>>> in the textarea before, I don't want my focus to be changed to the
>>> sidekick after.
>>> On Sun, Sep 28, 2008 at 6:34 PM, Matthew Gilbert <gilbert@...> wrote:
>>>> Those are my changes. For me, the text field makes the most sense for
>>>> the default component and for the component that receives focus after
>>>> a parse. Up/down arrows and pgup/pgdown still work to scroll through
>>>> the nodes. What other UI components use the keyboard? I'm happy to
>>>> change it, but would like to understand what use-case I'm not thinking
>>>> of in case I can make everyone happy. I've only used the ctags, java,
>>>> keyboard? Thanks _matt