Re: Re: [nbdev] Question: Expand Abbreviations action in Java Editor

Sandip Chitale wrote:

> Tor Norbye wrote:
>
>> Sandip Chitale wrote:
>>
>>> Can anyone explain how the Expand Abbreviations [abbrev-expand] 
>>> action in Java Editor works?
>>>
>>> Here is the scenario:
>>> I bound a key stroke (Ctrl+Enter) to Expand Abbreviations 
>>> [abbrev-expand]  action in Java editor key bindings options.
>>> [I could not
>>>
>>> I have an abbrev:
>>>
>>> foria
>>>
>>> which should expand to:
>>>
>>> for (int i = 0; i < |.length; i ++) {
>>> }
>>>
>>> Now when I type:
>>>
>>> foria<SPACE>
>>>
>>> the abbreviation expands correctly. This seems to be an implicit key 
>>> binding.
>>>
>>> foria<Ctrl+Enter>
>>>
>>> the abbreviation expands correctly too.
>>>
>>> However if I type any char like backspace then the abbrev expansion 
>>> does not work e.g.
>>>
>>> foris<BACKSPACE>a<Ctrl+Enter>
>>>
>>> then the abbreviation does not expand.
>>>
>>> I think the Expand Abbreviations [abbrev-expand] should work as long 
>>> as the text (word?) before the caret matches  an abbreviation.
>>>
>>> Comments? 
>>
>>
>>
>> My guess is that this was done as a usability fix for those cases 
>> when you DON'T want the abbreviation. That's not likely with 
>> Ctrl+Enter but is likely with space.
>>
>> Let's say you wanted to type the phrase "we're " in a comment. Since 
>> "re " is an abbreviation for "return" you end up with "we'return ". 
>> Now you go back and delete it to "we're" and hit space to continue - 
>> if it always expanded this would become "we'return" again!
>>
> Yes. I understood that something like that might have been the 
> reasoning behind it. However there are several problems with the 
> approach. The SPACE to expand abbrevs as an *implicit* binding is not 
> good. IMHO that should be under user control. Secondly it is 
> inefficient.  (My agues is) the editor is trying to match the 
> expansion prefix almost every keystroke.
>
> Like you observed the problem you describe definitely apply to an 
> explicitly defined key binding like (Ctrl+Enter) as the user will have 
> to invoke it explicitly to trigger expansion.

Please read "definitely does not apply" in the above line.

>
> I have filed the following RFE here:
>
> http://www.netbeans.org/issues/show_bug.cgi?id=57856
>
> In it I have suggested use of the
>
> javax.swing.text.Utilities.getPreviousWord(JTextComponent editor, int 
> caretOffset)
>
> to look at the word before the caret to match the abbrev prefix, as 
> one way to solve the problem. That however assumes that abbrev 
> prefixes are words in that editor kit's type's domain.
>
> (X)Emacs solves this problem in several different ways:
>
> 1. User can globally/per file type/per file/per buffer control whether 
> abbrevs expand or not. This may be an overkill for NetBeans. A global 
> switch for each file type may be sufficient.
> 2. SPACE is not implicitly bound to expand abbreviations action.
> 3. There is a enter quoted following char mechanism using Ctrl+Q. I 
> think same is true in Vi.
>
> Finally, IIRC, Eclipse simply takes a unified approach to:
>
> 1. Code completion
> 2. Template expansion
> 3. Abbrev expansion
>
> I guess 2 and 3 are same in Eclipse.
>
> It is not a coincidence that abbrev bugs in NetBeans get filed again 
> code completion :-)
>
> Here is another RFE related to the above point:
>
> http://www.netbeans.org/issues/show_bug.cgi?id=56891
>
> -- 
> Sandip
>
>> So I'm guessing the abbreviations code is only doing abbreviation 
>> expansion if you type the abbreviation correctly - if you edit around 
>> it it doesn't.
>>
>> (This is just speculation but I don't want it to start expanding 
>> always for the case when space is used as the expand key)
>>
>> -- Tor
>>
>>
>>
>
>