bug#14300: 24.3; comint-dynamic-complete-functions breaks

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Leo Liu]

This looks like a regression to me.

The semantics of comint-dynamic-complete-functions has changed between
emacs-24 and previous releases.

Previously entries are tried one after another to perform completion
i.e. actually perform the completion.

With the new semantics it only does the first one because it will always
(99% cases) succeed (getting the completion-table nearly always
succeeds).

This is unfortunate because a lot of modes rely on the previous
behaviour to provide rich completions for comint based modes.

I noticed this bug because file completion no longer works in
octave-mode.

Leo

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Stefan Monnier]

> The semantics of comint-dynamic-complete-functions has changed between
> emacs-24 and previous releases.

Indeed.

> With the new semantics it only does the first one because it will always
> (99% cases) succeed (getting the completion-table nearly always
> succeeds).

Then the code needs to be fixed not to succeed when point is somewhere
where that completion doesn't apply.

> This is unfortunate because a lot of modes rely on the previous
> behaviour to provide rich completions for comint based modes.

But that ad-hoc way to combine completions had many downsides (e.g. you
can't tell when to hide the *Completions* buffer, you can't provide
completion-help-at-point, and it interacts poorly with sophisticated
completion-styles).

> I noticed this bug because file completion no longer works in
> octave-mode.

Let's try to focus on this, then.


        Stefan

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Leo Liu]

On 2013-05-05 04:08 +0800, Stefan Monnier wrote:
>> I noticed this bug because file completion no longer works in
>> octave-mode.
>
> Let's try to focus on this, then.

Let's see if we can fix this just for octave.

How can I differentiate between an octave function completion from a
file completion if they don't have different delimiters?

Leo

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Stefan Monnier]

> How can I differentiate between an octave function completion from a
> file completion if they don't have different delimiters?

Good question.  Can file names really occur at the same places as
function names in Octave?


        Stefan

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Leo Liu]

On 2013-05-05 14:39 +0800, Stefan Monnier wrote:
> Good question.  Can file names really occur at the same places as
> function names in Octave?

F("arg1", "arg2", ...) can be written as F arg1 arg2 ... in octave. For
example 'help sin' and 'cd /usr'.

So there is no clear way to detect whether a position is file-completion
or function-completion given the fact that user can define a function
that does do both in the same position.

Leo

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Stefan Monnier]

>> Good question.  Can file names really occur at the same places as
>> function names in Octave?
> F("arg1", "arg2", ...) can be written as F arg1 arg2 ... in octave. For
> example 'help sin' and 'cd /usr'.

> So there is no clear way to detect whether a position is file-completion
> or function-completion given the fact that user can define a function
> that does do both in the same position.

While there are cases where there is ambiguity, there are many where the
ambiguity can be lifted:

You could prevent function completion within a string, so file name
completion still won't work after 'cd /u' but it will after 'cd "/u'.
Similarly you might disable function completion if the "current function
name" includes a / (assuming real functions don't include a slash in
their name).

In the worst case, you might want to use ":exclusive t", tho it means that
function completion won't be able to benefit from fancier completion styles.


        Stefan

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Leo Liu]

On 2013-05-06 10:38 +0800, Stefan Monnier wrote:
> While there are cases where there is ambiguity, there are many where the
> ambiguity can be lifted:
>
> You could prevent function completion within a string, so file name
> completion still won't work after 'cd /u' but it will after 'cd "/u'.
> Similarly you might disable function completion if the "current function
> name" includes a / (assuming real functions don't include a slash in
> their name).
>
> In the worst case, you might want to use ":exclusive t", tho it means that
> function completion won't be able to benefit from fancier completion styles.

It would be nice if there is a way I can provide completion-at-point
with two tables and it will just try them one after another if the
preceding table has no match.

In most cases path starts with no leading / and function completion
needs to work well in strings too due to its inline functions:

   f = inline("sin(x)^2 + 2");

Octave's syntax is eccentric.

A 80% solution might be to special-case 'cd', 'rmdir', 'source',
'unlink' etc.

Leo

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Stefan Monnier]

> It would be nice if there is a way I can provide completion-at-point
> with two tables and it will just try them one after another if the
> preceding table has no match.

That's what ":exclusive t" does.  Of course "no match" is tricky to
define: if you use a fancy completion style that tries really hard to
find a match (ido-flex style, maybe even with "typo-correction"), then
only trying the second table when "there's no match" for the first one
might end up meaning that it never tries the second one.


        Stefan

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Leo Liu]

On 2013-05-06 21:32 +0800, Stefan Monnier wrote:
> That's what ":exclusive t" does.  Of course "no match" is tricky to
> define: if you use a fancy completion style that tries really hard to
> find a match (ido-flex style, maybe even with "typo-correction"), then
> only trying the second table when "there's no match" for the first one
> might end up meaning that it never tries the second one.

I got a solution that seems good enough. Do you see any room for
improvement? Thanks.


diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index 138c1948..3118f49e 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -741,13 +741,19 @@ (defun inferior-octave-completion-table ()
 
 (defun inferior-octave-completion-at-point ()
   "Return the data to complete the Octave symbol at point."
-  (let* ((end (point))
+  ;; http://debbugs.gnu.org/14300
+  (let* ((filecomp (string-match-p
+                    "/" (or (comint--match-partial-filename) "")))
+         (end (point))
 	 (start
-	  (save-excursion
-	    (skip-syntax-backward "w_" (comint-line-beginning-position))
-            (point))))
-    (when (> end start)
-      (list start end (inferior-octave-completion-table)))))
+	  (unless filecomp
+            (save-excursion
+              (skip-syntax-backward "w_" (comint-line-beginning-position))
+              (point)))))
+    (when (and start (> end start))
+      (list start end (completion-table-in-turn
+                       (inferior-octave-completion-table)
+                       'comint-completion-file-name-table)))))
 
 (define-obsolete-function-alias 'inferior-octave-complete
   'completion-at-point "24.1")

bug#14300: 24.3; comint-dynamic-complete-functions breaks

[Leo Liu]

Fix in trunk for octave mode instead.