Re: comint-filename-completion and :exclusive completion bugs

[Stefan Monnier]

>> The ":exclusive 'no" solves this dilemma by only allowing prefix
>> completion.  I think that for filename completion, non-prefix completion
>> is important, so while I can agree that comint-filename-completion often
>> isn't really sure whether it should take responsibility (because it
>> doesn't actually know that there should be a filename at point),
>> preventing things like partial-completion on filenames would be sad.
> I don't really understand how :exlusive 'no prevent partial completion
> (in case you mean the obsolete package complete.el).

This is a limitation due to the way it's currently implemented.

Hopefully the implementation will be improved, maybe by taking various
"completion data" and combining them along the lines of what
completion-table-in-turn does (so if you have three non-exclusive
completion data like files, tags, and whatnots, the completion would
first try prefix completion on files, then on tags, then on whatnots,
and then partial-completion on files, than on tags, then on whatnots,
...).  But this opens up various other problems:
- what if the beg..end of those completion data are not the same?
- what if the completion `category' of those completion tables is not
  the same, and hence the completion-styles and/or cycle-thresholds to
  use are not the same?

Another approach is to first try all completion styles for files, then
all completion styles for tags, then all completion styles
for whatnots.  But this will require less localized changes in
minibuffer.el.
  
> So if there is no partial expansion of foo_bar|, doesn't :exlusive
> pass the handling over?

No, I'm saying that if you typed "fo/ba" it will pass the handling over
before trying "foo/bar".

> comint-filename-completion is active in all comint buffers, and it
> prevents the completion UI to reach the global
> tags-completion-at-point-function.  And this is a bit of a limitation.

Indeed, it's a limitation.

> In other modes than comint, file completion of 'sdfdsf, or anything else
> not prefixed by "/", or even not quoted, is not a filename, and should
> be passed over.

At least for shell-mode, there are really very few cases where we can
*know* that a given shell argument is not a file name.  The only
exceptions I can think of are when we know it because we know what the
command is and what its arguments can be.
Otherwise, pretty much anything may be a valid file name, e.g. "'The",
"The\ ", and friends can very much be the prefix of a file or
directory name.

>> Maybe we could provide a comint-maybe-filename-completion which would
>> set the ":exclusive 'no", for situations like yours where you prefer
>> falling back on some other completion data if the text isn't a prefix of
>> a valid filename.
> That would be great, for the simple reason that hacking
> comint-filename-completion, in order to be used in other modes, is a bit
> difficult.  A real example:

> (defun ess-filename-completion ()
>   "Return completion only within string or comment."
>   (when (ess-inside-string-or-comment-p (point))
>     (comint-filename-completion)
>     ))

If you need to modify the return value of comint-filename-completion in
non-trivial ways, I recommend

 (pcase (comint-filename-completion)
   (`(,beg ,end ,table . ,props)
    <blabla>))
    
> Comint-filename-completion returns a list of length 2 or 3 depending on
> filesuffix.

Hmm... AFAICT, it's either 0, 3, or 5.

> So to tweak it, I have to check for the length, if 2, append, if
> 3 insert :exclusive into the last list.  Ugly as far as I am concerned.

If you only want to add :exclusive, (append <data> '(:exclusive no))
should work (except for the case where <data> is nil).


        Stefan