Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Mysteries of auto-completion

in Bugs Posts: 1,277

Sometimes it works, sometimes it doesn’t, I can never tell why. Some examples:

In 3.3.2 (270):


AutoCompletionTestClass = class() function init(x) self.autocompletesInsideInstanceFunction = true self.completionAfterInstantiationAtRoot = false self.autocompletesInsideARootFunction = false end function AutoCompletionTestClass:testInsideInstanceFunction() succeedsInAutocompletion = self.autocompletesInsideInstanceFunction end instance = AutoCompletionTestClass() doesNotAutocompleteHere = instance.completionAfterInstantiationAtRoot function rootLevelFunctionAutocompletionTest() theFollowingVariableNameActuallyDoesAutocompleteHereIfYouCanBelieveIt = doesNotAutocompleteHere butHereAgainAutocompletionFails = instance.autocompletesInsideARootFunction end

Sorry for the screwy indentations but that’s a current Codea bug.

Tagged:

Comments

  • dave1707dave1707 Mod
    Posts: 9,415

    @UberGoober What are you trying to do or what are we supposed to do.

  • dave1707dave1707 Mod
    Posts: 9,415

    @UberGoober If you’re just showing a bunch of long names and wondering how autocomplete works, here’s the 2 rules that I know of.

    1) when you start keying something, autocomplete will list whatever begins with that letter or string of letters/numbers.

    2) as soon as an exact match happens somewhere, autocomplete stops matching anything.

  • Posts: 1,277

    Autocorrect is extremely flakey.

    I was trying to figure out when it works and when it doesn't.

    This code demonstrates some cases where it fails, though probably not all.

    If the meaning of the variable names is not apparent to you, you may have to type the code in to understand what's happening, because then you'll see Codea's behavior as you type each letter.

    But reading the names over may help make it clear happening in each case, without you having to manually type in anything.

    In the cases of the variable names on the left side of the equals sign, they tell you whether the autocompletion attempted on that line succeeded.

    So the line beginning succeedsInAutocompletion shows an instance where the autocompletion worked, in other words, when Codea noticed the letters for the beginning of the variable name on the right side of the equals sign being typed in, it suggested the correct completion.

    The lines beginning with terms that indicate failure, such as doesNotAutocompleteHere and `butHereAgainCompletionFails," show instances where, when Codea noticed the letters for the beginning of the variable names on the right side of the equals sign being typed in, it did not suggest the correct completions.

    In the same vein, the line beginning theFollowingVariableNameActuallyDoesAutocompleteHereIfYouCanBelieveIt indicates an instance in which, when Codea noticed the letters for the beginning of the variable name on the right side of the equals sign being typed in, it suggested the correct completion, and doing so was somewhat improbable, given that it did not correctly suggest completion for the variables on the right side of the equals sign in either the previous case or the following case.

    So as you see, lines beginning with terms that indicate success signify that autocompletion performed correctly on them, and lines beginning with terms that indicate failure signify that autocompletion failed to perform correctly.

    As for the names of the variables on the right side of the equals sign, in other words the variables that themselves either correctly or incorrectly triggered autocompletion suggestions, they describe the circumstances in which completion is being attempted.

    So in the case of the line where self.autocompletesInsideInstanceFunction is on the right side of the equals sign, autocompletion is being attempted inside a function belonging to an instance of the class that declared the variable itself.

    In the line where instance.completionAfterInstantiationAtRoot is on the right side of the equals sign, autocompletion is being attempted at the root level, after instantiating the class, on that instance of the class.

    In the line where instance.autocompletesInsideARootFunction is on the right side of the equals sign, autocompletion is being attempted inside a root function, again on the same instance of that class.

    @Simeon I don't know if tuning-up autocompletion is any kind of priority, but personally, it sure helps a lot when it works. If that's on your list, hopefully this can help in debugging it.

  • dave1707dave1707 Mod
    edited April 20 Posts: 9,415

    @UberGoober I think I tried everything. I keyed single letters, and some specific words and here’s what I got with autocomplete. I think everything showed the way it should. If something is missing, show me what you keyed and what should have showed up in autocomplete.

    a           AutoCompletionTestClass
    b           butHereAgainAutocompletionFails 
    d           doesNotAutocompleteHere 
    i           instance
    r           rootLevelFunctionAutocompletionTest   
    s           succeedsInAutocompletion  
    t         theFollowingVariableNameActuallyDoesAutocompleteHereIfYouCanBelieveIt 
    
    instance.   instance.autocompletesInsideARootFunction
    instance.   instance.completionAfterInstantiationAtRoot
    
    self.       self.autocompletesInsideARootFunction
    self.       self.autocompletesInsideInstanceFunction
    self.       self.completionAfterInstantiationAtRoot
    
    
  • edited April 20 Posts: 1,277

    @dave1707 ...but you didn’t type it in the order I did.

    You didn’t follow the order and you also didn’t follow the context.

    My results happen when, for instance, rootLevelFunctionAutocompletionTest is typed in an actual root level function.

    That’s why I did it that way.

  • dave1707dave1707 Mod
    Posts: 9,415

    @UberGoober I’ll have to say that what you’re showing is correct. I took your above code and copied it into a new project. I then commented it out and tried to key it line by line. I gave up after about 8 lines because the variable names were so long and similar and I couldn’t keep track of what was supposed to work and what wasn’t. I’ll let @Simeon figure it out.

    Now I remember why I keep my variable names small.

  • Posts: 1,277

    @dave1707 ypu don’t have to use that exact combination of letters to see the effects I see, you just have to use names long enough to trigger autocomplete and use them in the order and contexts shown.

  • SimeonSimeon Admin Mod
    Posts: 5,693

    Thanks for such a thorough exploration @UberGoober, very helpful! Will debug it

  • Posts: 1,277

    @Simeon glad to help!

    @dave1707 I tried to cut down the wordiness here:


    AutoCompletionTestClass = class() function init(x) self.apple = 0 self.banana = 0 self.coconut = 0 end function AutoCompletionTestClass:instanceFunction() self.apple = 0 --autocompletes correctly end instance = AutoCompletionTestClass() bananaClone = instance.banana --does not autocomplete function rootLevelFunction() bananaClone = 0 --does autocomplete, surprisingly instance.coconut = 0 --does not autocomplete end
  • SimeonSimeon Admin Mod
    Posts: 5,693

    @UberGoober the behaviour you describe in the last comment is correct

    Lua is a dynamically typed language, so we have no idea what type instance is. However, I think we could probably just go the route of "complete everything" and expose every property to every dot-syntax completion weighted by how likely it is to be relevant

    In your example the type is very clear but consider:

    instance = AutoCompletionTestClass()
    
    function foo(x) 
        x.banana -- We would have no idea here what `x` is
    end
    
    function bar()
        foo(instance)
    end
    

    I think there are probably some better heuristics we could apply to figure this out, or maybe just showing every possible completion as a fallback could work well

  • dave1707dave1707 Mod
    Posts: 9,415

    @UberGoober Your cut down version makes it a lot easier to see the problem. As Simeon said, it’s too hard to figure out every name that should show for autocomplete. Because I use such small variable names when I code, the way autocomplete works now gets in my way more than it helps. If there was an option to turn off autocomplete, I would probably do it.

  • Posts: 1,277

    @Simeon I understand what you mean about the challenges, and I am willing to live with an incomplete system, I was just curious about why it works sometimes and why it doesn’t.

    Showing every possible combination would probably work well for small projects, and actually, since the results would get more accurate the more you typed, it might even work well for larger ones.

    A few other thoughts:
    * you could prioritize completion of names the were on the current tab maybe?
    * since the environment already treats classes as special cases, there must be some kind of tracking of which variables are classes and which are not, no? If that was the case, would that enable tracking separately the names of variables attached to classes? Or maybe just the class variables contained in the init() for that class? This already seems to work sometimes but I can’t tell why.
    * would it be non-trivial to separate names that are defined at the root level from names defined one level deep? So the environment could track foo separately from bar.foo, and make suggestions equivalently?

    Anyway it’s all up to you of course. I do think even just your omni-completion concept would be a huge help. Not having to switch to another tab when I can’t remember if a function was called selectFoo() or chooseFoo() would save a bunch of time.

  • Posts: 1,277

    The more I think about it the more it seems like doing every possible variable would be hugely helpful and a 1000% improvement on what we have now.

  • Posts: 1,089

    leading underbar on asset name foils autocomplete

  • Posts: 2,348
    All - out of curiosity, since I have an impression (that may be wrong). Is autocomplete context sensitive ?

    I ask because I have seen variables in function searches in the past. The recent graphics images associated with autocomplete menus do help but tend to be scrollably long so many menu items may not be seen.
  • Posts: 1,277

    @dave1707 your single-letters work for me because you favor short-and-sweet code that doesn’t take me too long to decipher.

    Something like SODA, on the other hand, is full of one-and-two letter variables floating unmoored amidst a sea of daunting complexity, at least to me.

    I have an exceedingly poor memory, and I prefer verbose names, not just because it helps me understand other people’s code, but also because it helps me remember what the heck my own code is supposed to be doing. ;)

  • dave1707dave1707 Mod
    Posts: 9,415

    @UberGoober The reason I use simple, small variable names is because I only write code while I’m watching TV. My iPad is sitting on the table next to the couch. If I’m on the couch then I’m watching TV and if I respond to a forum question or write code, then I’m doing it with the TV on. Right now I’m watching a rerun of Blue Bloods. If I write something that I think is important and fairly large, when I’m done I’ll go thru the code and expand on the names with something more appropriate. Also, small variable name lets me write code faster since I’m using the built in keyboard and one finger to type. I can probably type faster with one finger than most people can using as many fingers as they want.

  • Posts: 1,277

    @dave1707 makes sense. Also: impressive.

  • Posts: 1,089

    I'm finding the new auto-completion odd, in that it seems less useful, in many cases, than the old one. It seems to be offering all kinds of things that couldn't possibly be useful. I suppose it's just not context-sensitive, at least in some cases, but I'm glad there aren't very many words other than aardvark that start with two letter a's. :D

  • Posts: 1,089

    @Simeon

    Here's a weird one. I have two member variables .moving and .movingIndex. While I'm typing m o v i n, both show up. When I get to moving, moving vanishes and only movingIndex is offered, and it is highlighted. The upshot is, I'm done typing, I'm not even looking at the offered values, and when I hit enter, it replaces my perfectly good typing with the wrong thing.

    I suggest it shouldn't drop an offering until AFTER one types past its last character.

    Picture available if this wasn't clear.

  • dave1707dave1707 Mod
    Posts: 9,415

    @RonJeffries My understanding of how autocomplete works is it will show all suggestions but then not show the exact match when matched. At that point you either press a space or other action or you select from the autocomplete. I pressed enter and the cursor just went to the next line and didn’t mess up moving. When you hit an exact match it expects you to either keep keying, select something from autocomplete, or key some action (+,-,=, etc). As I started keying moving, it brought up the two options and I could have selected one of them at that point. Autocomplete isn’t perfect, but I guess it’s getting better.

  • Posts: 1,089

    when i've typed the g and then type enter, as it is the end of the line, it does movingIndex. That is not what I want. I think it shouldn't prefer the next one while it has one that is right. I could touch movingIndex if I wanted it.

    It always seems to have too much stuff, but, yes, it's improving.

  • Posts: 2,348

    @RonJeffries - just posted this in another post, I was looking for textMode typed tex and when I added the following t menu disappeared. But repeating this textMode was visible when tex had been typed. Not sure if that will always be the case though.

  • SimeonSimeon Admin Mod
    Posts: 5,693

    @RonJeffries I see what you mean, hitting return on the hardware keyboard enters the selected autocomplete result, which happens to be movingIndex if moving is fully typed

    I think we should actually be hiding the entire autocomplete bar in this case — once .moving has been typed, the bar should disappear under default editor settings and only come back if you start typing further possible completion. Noted it down as a bug to fix

  • Posts: 1,089

    thanks!

Sign In or Register to comment.