Re: [code] Updated proposal for better ctags support

From: Mitchell <m.att.foicica.com>
Date: Thu, 3 Jul 2014 14:41:41 -0400 (Eastern Daylight Time)

Hi Carlos,

On Thu, 3 Jul 2014, Carlos Pita wrote:

>> I've some concerns regarding the possibility to implement this highly
>> interactive dialog using the pure lua api of textadept. Is it possible
>> to call the GtkBuilder passing it a glade file without writing C at
>> all?
>
> Well, I realized I was thinking in terms of a code browser but both
> autocompletion and jump-to-def uis could be stripped down to a simple
> filtered list gaining in simplicity and without sacrificing too much
> functionality. Here is a more concrete suggestion:
>
> 1) If a scope (class, type, table, etc.) filter is provided just list
> the symbols belonging to that scope.
>
> 2) If not, list the symbols for the current language in the following
> order: first the ones belonging to the file in the current buffer,
> next the ones belonging to files currently opened in some buffer, then
> the rest. Symbols with attached scope information are listed as
> <scope>.<symbol>.
>
> 3) There is a wildcard character * (or space, as in
> ui.dialogs.filteredlist) that allows you to type, say, ri*sp to match
> "string.split".
>
> 4) The final action (autocomplete or jump-to-def) depends on a
> parameter that is passed to the widget, presumably mapped to different
> key bindings.
>
> This is all pretty simple but I still want to ask for informed opinion on:
>
> i) A filteredlist dialog could be fine for jump-to-def but would look
> a bit awkward for autocompletion. If the same widget will fulfil both
> functions something like the autocomplete dropdown seems like a better
> choice to me, but I'm not sure if it supports any wildcard char at
> all.

I agree a filteredlist dialog is a good fit for jumping to ctag
definitions. For autocompletion, I think you should only display an
autocompletion list (thus the language module should do its best to
determine what symbols to display). Filtered-list pop-ups for
autocompletion would probably be too jarring for users.

Autocompletion lists do not accept wildcards.

> ii) The filtered list would allow to pass additional contextual
> information (for example, filename and signature) and still output
> only the relevant part of the selection (symbol name without the
> prefix). The autocomplete mechanism seems less flexible, but I think
> that chosing the appropriate prefix character count the "<scope>."
> portion could be removed at least, as part of the prefix.

The autocomplete mechanism is actually quite flexible. Not only do you
have control over what part of the selected item is inserted, but you can
also connect to the `events.AUTO_C_SELECTION` event in order to do stuff
before that text is inserted (or call `buffer:auto_c_cancel()` to prevent
insertion completely).

Cheers,
Mitchell

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Thu 03 Jul 2014 - 14:41:41 EDT

This archive was generated by hypermail 2.2.0 : Fri 04 Jul 2014 - 06:54:01 EDT