Re: [gedit-list] Completion

Perriman wrote:
Hi all,

With the new changes Do we need the add_provider and the
remove_provider? Currently there are no reasons to register providers,
only passing them on the gtk_source_completion_popup function is enough.
The only reason for that function is store the auto_providers, the
providers list is not used (only for check if the provider is registered
when popup function is called but it is not necessary).
Let me explain the rationale of the decisions we made regarding providers and triggers. There are basicly 3 types of 'triggers' that are useful:

1) Keybinding
2) Autocomplete
3) Custom invocation

Providers will be able to specify on what kind of event they should be included in the popup. They will specify whether they react to the global keybinding, and/or to the auto-complete-while-typing. This already covers many of the use cases for completions. Furthermore, you can easily switch between providers in the popup, showing only the proposals for that particular provider. Use case 3) is for example when you tab to a snippet placeholder, and want to show a list of possible default choices. Such a provider will neither respond to the general keybinding, nor to the auto-complete-while-typing, and will be invoked by calling gsc_show_completion. We found that all use cases are covered by implementing this like described, instead of building a special trigger framework. Note that plugins can still install their own keybindings, just as they do now, in ways provided already by Gtk+.
Sincerely, I don't like very much the changes. Currently the completion
decides that all proposals go to the "All" page. Why the completion
decides that? I don't like to have all proposals in the "All" page, I
want only my two pages with their proposals. I think the user (plugins
or application) must configure an "All" page if he wants that feature.
I disagree here, if you don't want some completions to be shown at all, then you arguably do not really want that particular plugin. We will add API that allows a provider to be ignored in the 'All' event.
I remember again we will need to show proposals in the same event from
different plugins. Currently I have four plugins for gedit using

1.- Document words completion - With three providers: words completion,
Open Documents Completion, Recent Documents Completion
2.- Snippets completion (Symbol completion and symbol goto)
3.- Symbols completion 4.- Universe commands completion

If I like to show 1, 2, 3 y 4 in the same <control>space event, I cannot
do it. I will need 4 keybindings (and other for open/recent documents
provider) or create an unique plugin managing all providers (a lot of
unnecessary dependencies). We will find these problems in a near future.
Why, if you have these plugins, and you want to show them all, then that is perfectly fine.
If you don't like the trigger/proposal registration, another way of
implement the completion is using the "population" technique like the
popup menu or something like that. It is only an idea because the
provider is losing the sense slowly.
Provider is not losing sense at all, it groups proposals in a meaningful way and provides ways to show customized context information about them. For what it is worth, in the context of gedit, you actually _will_ be able to show any combination of providers, even if they are provided by different plugins, by means of the GeditMessageBus.
That is only my opinion, you can do what you want, of course :)


gedit-list mailing list
gedit-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]