Re: new completion behaviour version 2

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 9, 10:04am, Sven Wischnowsky wrote:
} Subject: Re: new completion behaviour version 2
}
} Bart Schaefer wrote:
} > 
} > That is, the widget can say "here are the completions, and here is where
} > you insert them" but then let hardwired code take over cycling through
} > the menu if there are multiple matches.
} 
} Interesting point of view. I thought we wanted to give the user the
} possibility to build widgets that have full control

Well, yes, that's why I said I could easily be convinced otherwise; but:

} > Listambiguous can be a flag attached to the generated
} > list of matches, can it not?
} 
} Yes. The question is: should the completion code do this automatically 
} or should the user request it explicitly.

It's quite a burden on the widget writer to check for LISTAMBIGUOUS and
spit out the listing if so.  On the other hand, the widget ought to be
able to emit a listing (and have zle deal with it properly) even when
the LISTAMBIGUOUS is not set.

It seems to me there are three ways to deal with this:

1. The widget function always produces the entire list of matches, with
   an annotation for how and where to insert them.
   + Returning a single value forces recexact.
   + The function always executes in the same way and always returns
     the same values, so its easier to write.
   + Efficient, compiled builtin code handles menus and listings, and
     tests for menucomplete, automenu, autolist, and listambiguous.
   + There's only one call to interpreted user code per set of results.
   - The annotations have to describe prefix/suffix removal, replacement,
     or addition for correct insertion on the command line.
   - It may be unclear exactly what to display in a listing, i.e., what
     if any prefix/suffix changes to perform on the returned strings.

2. The widget function always produces one match at a time, with an
   annotation for how and where to insert it.
   + Builtin code still tests for menucomplete, automenu, autolist, and
     listambiguous.
   + The function can change the insertion annotations on every match.
   - The function has to be told which match to produce; it's harder to
     write efficient functions because it's necessary e.g. to branch on
     whether the full list has previously been generated and on whether
     the prefix has changed.
   - Lots of calls to interpreted code when generating listings and when
     cycling through menus.
   - It requires either an annotation or two calls to the function to
     force recexact.
   - It still may be difficult to determine what to display for a listing.

3. The widget function not only produces the matches, but also either
   inserts them or produces a listing as appropriate.
   + The function can drive zle directly (e.g., through $BUFFER) to do
     complex insertions/changes.
   + No annotations are needed.
   + The function can produce exactly what should appear in the listing.
   - The function has to be told what match to produce or to produce a
     complete list of possible matches; it's even harder to write simple
     efficient functions.
   - Lots of calls to interpreted code when generating menus.
   - The widget writer has to figure out all the prefix/suffix changes
     to perform on every insertion, including dealing with menus (but an
     implicit "undo" of the last insertion before calling the function
     for the next item could make that easier).
   - The widget itself has to test automenu, autolist, and listambiguous.

There are of course points somewhere in between each of these choices, but
they all have something of those flavors.  I think the choice of which to
provide depends on what we can come up with in terms of the annotations
needed by the first two.

} > 	compadd $disabled
} > instead of
} > 	compadd -dFB
} 
} I like this. But I wouldn't like to have to do
} 
}     compadd $(compinfo -disabled)

I agree; if the choice is between that and something like

	compadd disabled

then I'd take the latter.

} > [[ ]] to mean "test completions", e.g., [[ -C index -1 / ]] for the
} > above.)
} 
} I didn't think about changing [[...]], interesting. (Although that
} would require changes in completely differnt parts of the code, of
} course.)

Yes, but I've been thinking that perhaps the tests supported by [[ ]]
should be extensible through the modules mechanism anyway.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com