Re: completion-at-point + semantic : erroneous error

[Eric Ludlam]

On 10/23/19 4:18 PM, Stefan Monnier wrote:
> > As a followup, I started using the shorter version of your patch, and found
> > there are additional errors thrown from
> > semantic-analyze-possible-completions-default (what will be a method in
> > your patch).  I had to eliminate those errors to fully clean up the original
> > problem that started this thread.
> [ Sorry for taking so long to get back to it.  ]
>
> After fighting for a while with your patch (it was full of NBSP chars
> and wrapped lines) and then looking at it some more, I decided to
> install the patch below instead which replaces the `catch` with
> a `with-demoted-errors` (and places it in the caller instead).
> Maybe those errors should indeed all be replaced by silently returning
> nil, but the code currently goes through the trouble of building
> more precise error messages, so I felt like maybe we should preserve
> that info.

Hi Stefan,

I pulled down the latest, and ran against a more extensive test suite 
I'm working on.  I found that the new version is always pushing down the 
optional 'flags input to overrides, which makes sense.  Several override 
methods don't accommodate this.  The attached patch adds that optional 
'flags' input to fix the error and allow the make, texi, and grammar 
modes run their specialization.

> Ah, right.  I too have debug-on-error non-nil of course.
> The `error`s should be turned into `user-error`s to avoid this problem.

> Tho of course, if the corresponding messages are not useful, returning
> nil is a better choice, indeed.

user-error sounds like the shortest path here.  The original purpose of 
the error was to provide a fine-grained reason for why something may 
have failed to complete.  I think most completion engines don't care 
about that.

Thanks

Eric

optflags.patch
Description: Text Data