Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new hyps not proposed for completion when in diff mode. #250

Open
Matafou opened this issue Jul 2, 2021 · 6 comments
Open

new hyps not proposed for completion when in diff mode. #250

Matafou opened this issue Jul 2, 2021 · 6 comments

Comments

@Matafou
Copy link

Matafou commented Jul 2, 2021

Hi
When a new tactic appear, it gets surreounded byt tags when in diff mode. It makes company-coq not recognize its name and hence it is not proposed as completion.
To reproduce:

(* Enable company-coq and diff-mode from here. *)
Goal forall n:nat, True.
Proof.
  intro n.
  induction n as [|x H_ind_hyp];[auto|].
  H_i (* no completion proposed *)

The last goal in *coq* is like this. I suppose that this misleads the hyp name recognition mechanism.

  <diff.added.bg><diff.added>x : nat</diff.added></diff.added.bg>
  <diff.added.bg><diff.added>H_ind_hyp : True</diff.added></diff.added.bg>
  ============================
  True
@Matafou
Copy link
Author

Matafou commented Jul 2, 2021

From the number of issues raised by the diff mode for company-coq I suspect it relies too much on the *coq* content and should maybe migrate to looking more into *goal* and *response* instead?
Until we switch to some good protocol of course (I should have this disclaimer in my signature...).

@cpitclaudel
Copy link
Owner

Ah, good catch. I think your analysis is almost right… except I actually tried to avoid relying on buffer contents as much as possible and instead used variables like proof-shell-last-goals-output. I'm not too eager to depend on the contents of *goals* instead, because that sounds less robust; WDYT?

@Matafou
Copy link
Author

Matafou commented Jul 2, 2021

Right, relying on this variable seems better. Maybe we could try to clean that variable from the tags in PG instead. Would it make other features fail? Otherwise we just provide a function removing these tags.

@cpitclaudel
Copy link
Owner

Would it make other features fail?

I'm not sure :) It would make it harder to implement features that need the tags. Maybe adding a filtering function is the right way to go.

@Matafou
Copy link
Author

Matafou commented Jul 2, 2021

Yes probably. Hopefully we don't get into efficiency problems.

@erikmd
Copy link
Contributor

erikmd commented Jul 11, 2021

BTW, I guess this is related to this other issue: #239

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants