[Top][All Lists]

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

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

From: Eric Ludlam
Subject: Re: completion-at-point + semantic : erroneous error
Date: Sun, 27 Oct 2019 18:31:19 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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.



Attachment: optflags.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]