On Thu, 3 Dec 2020, Sven Schreiber wrote: > This is a quite distracting PITA. Is this a GTK problem? An obvious > workaround is to switch off auto-completion, or get used to typing a > superfluous space at the end before the return. This "service" is provided by gtksourceview. It seems to work not too badly with gtksourceview-3.0 (companion of GtK 3) but on Linux using Gtk 2 + gtksourceview-2.0 I can replicate the broken behaviour you describe. (Regardless of further problems, it's already broken to offer "series" as a completion of "da".) I suppose we need to either backport a fix from gtksourceview-3.0, if possible, or remove the autocompletion option for gretl builds that use Gtk 2.

I can't say I find this facility very useful even in Gtk 3: it has no notion of hansl context and just works with a flat list of previously typed words.

Am 03.12.2020 um 23:02 schrieb Allin Cottrell: > On Thu, 3 Dec 2020, Sven Schreiber wrote: >> This is a quite distracting PITA. Is this a GTK problem? An obvious >> workaround is to switch off auto-completion, or get used to typing a >> superfluous space at the end before the return. > > This "service" is provided by gtksourceview. It seems to work not too > badly with gtksourceview-3.0 (companion of GtK 3) but on Linux using > Gtk 2 + gtksourceview-2.0 I can replicate the broken behaviour you > describe. (Regardless of further problems, it's already broken to > offer "series" as a completion of "da".) > > I suppose we need to either backport a fix from gtksourceview-3.0, if > possible, or remove the autocompletion option for gretl builds that > use Gtk 2. I don't think it's worth the effort to do a backport - also perhaps someday even the Windows build might use Gtk 3. > > I can't say I find this facility very useful even in Gtk 3: it has no > notion of hansl context and just works with a flat list of previously > typed words. Well yes, it could work better. (Remember also the other problem that keyboard shortcuts to select among several proposals don't seem to work.) But if you have a bunch of longer identifiers it's still useful and avoids typos I'd say.

On Fri, 4 Dec 2020, Sven Schreiber wrote: > Well yes, it could work better. (Remember also the other problem that > keyboard shortcuts to select among several proposals don't seem to > work.) But if you have a bunch of longer identifiers it's still useful > and avoids typos I'd say. OK, we'll not give up on it. Plus, I think -- though it's difficult to tell since the API is under-documened -- it should be possible to offer completion on hansl function-names (commands too, if wanted).

On Fri, 4 Dec 2020, Sven Schreiber wrote: > A related gtksourceview language spec thing: In a thread called > "external editors (gtksourceview)" in January we said it would be good > to put gretl.lang into the system-wide shared gtksourceview dir on > Linux. (That would be /usr/share/gtksourceview-3.0/language-specs and > /usr/share/gtksourceview-4/language-specs from what I'm seeing here on > Ubuntu 20.04.) But apparently that never happened, at least I don't see > the file there (again, on Ubuntu). Should I open a ticket for that? Hmm, not sure about that. A standard gretl "make install" probably shouldn't be writing files into "someone else's" share directory. That could be a problem for packagers. But maybe there should be some option to do so.

On Fri, 4 Dec 2020, Sven Schreiber wrote: > Am 04.12.2020 um 16:22 schrieb Allin Cottr >> Hmm, not sure about that. A standard gretl "make install" probably >> shouldn't be writing files into "someone else's" share directory. That >> could be a problem for packagers. But maybe there should be some >> option to do so. >> > Well, when I asked the gtksourceview people (back in January) if they > could distribute our .lang file, they said they'd rather not do that, > but that instead that share directory is the official place for > additional contributed language-spec files at installation time. Because > that's where apps like gedit which are using gtksourceview would look > automatically. And indeed we got gretl/hansl syntax highlighting in > gedit like that. Oh, alright, I'd forgotten about that exchange. Then I guess we can see about writing our lang files on install.

This should now be fixed in current git and shapshots. I backported an update for the completion-suggestion mechanism from gtksourceview-3.0 and I'm no longer seeing the problem Sven noted (tested on Linux and Windows, but I've still to test on macOS).

* If multiple suggestions appear and you wish to accept one other than the first, use down-arrow then Tab.

At present there are two sources of suggestions: (a) words typed previously in the editor and (b) names of built-in gretl functions.

On Mon, 7 Dec 2020, Sven Schreiber wrote: > thanks for this effort, Allin! By coincidence I just had installed the > latest (yesterday's, it seems) snapshot today. > > But it doesn't seem to have the new feature, does it? For example the > News button in the about dialog doesn't show it, while I see that > gui/NEWS has it. It does have the new feature. The change log just lagged a little.

On Mon, 7 Dec 2020, Sven Schreiber wrote: > OK thanks. Then I still the behavior that hitting return inserts the > current suggestion, not a line break. But now this can only happen if > the newly typed word matches the beginning of a previous longer word (or > a function name), of course. Not sure if that problem is simply beyond > the scope of the fix. Like Tab, the Return/Enter key is bound to "activate-proposal" in gtksourceview (versions 2.0 and 3.0). That could be removed in our patched version for Windows and Mac, but the approved procedure would be: hit Esc to dismiss the proposal(s), then Enter. It seems quite natural to me that Enter should accept a proposal.