Comments (19)
I have just also seen this happen in sequential background compilation mode.
from pg.
from pg.
maybe related to #42?
from pg.
Do you still see the reported behavior? Can you give some more hints for reproducing?
@Matafou What do you mean with the "pg windows are messed up" ?
from pg.
I did not do very much work with Coq recently, so I can't really tell... I don't actively remember seeing this recently, but I also don't think that means much. Sorry :/
from pg.
I just saw this happen again, using (slightly outdated) PG 60dcd96
from pg.
What PG configuration do you use, especially how many windows? Is coq-compile-response usually in a separate window?
The issue descriptions sounds like some dedicated-window property is getting in the way. When it happens the next time, can you try evaluating
(set-window-dedicated-p (get-buffer-window coq-compile-response-buffer t) nil)
via eval-expression?
from pg.
Here's my custom-set-variables
:
'(column-number-mode t)
'(company-coq-prettify-symbols nil)
'(coq-compile-before-require t)
'(coq-compile-parallel-in-background t)
'(coq-one-command-per-line nil)
'(default-input-method "math")
'(electric-indent-mode nil)
'(fill-column 80)
'(global-auto-revert-mode t)
'(indent-tabs-mode nil)
'(inhibit-startup-screen t)
'(mf-display-padding-height 75)
'(proof-follow-mode (quote followdown))
'(proof-next-command-insert-space nil)
'(proof-splash-enable nil)
'(proof-three-window-enable t)
'(reftex-plug-into-AUCTeX t)
'(show-paren-mode t)
'(standard-indent 4)
'(tab-stop-list (quote (4 8)))
'(tool-bar-mode nil))
If "window" here means "X11 window", then the answer this that all the three buffers are in the same window, the left left of which is taken over by the .v
file, the right half is vertically split between *goals*
and *response*
. (Sorry I may not be using emacs terminology properly here.) This is what "Refresh Windows Layout" does here.
from pg.
So it just happened again and I did the eval
and it print nil
. After this, I was able to switch the buffer on the left again to the .v
file and use C-c C-l to get back to the normal view.
from pg.
OK, this seems to confirm that the dedicated flag is the problem.
How about using C-x 0 (which invokes delete-window) or C-x 1 (delete-other-windows)? This works at least for me when three-window-mode messes up.
from pg.
... I meant to use C-x 0 and C-x 1 until you have one emacs window left and then use C-x b to switch to you coq code and then use C-x 1?
from pg.
Yeah, "C-x 0 C-C C-l" works to fix the mess. (Btw, currently, the issue seems to be 100% reproducible.)
from pg.
Ralf Jung [email protected] writes:
(Btw, currently, the issue seems to be 100% reproducible.)
Would you mind telling how to reproduce?
from pg.
- Check out https://gitlab.mpi-sws.org/FP/iris-coq.git
- Open
prelude/orders.v
- Go to the first free line (the one right after the imports),
C-c C-Ret
(it will compile the dependencies) - Open
prelude/tactics.v
and break the file (e.g. I added ans
after the firstLemma
on line 9, turning it intoLemmas
) and save it - Go back to
prelude/orders.v
, go to the first free line again and doC-c C-Ret
I am now getting the following Coq error displayed in the window where the .v
file used to be:
-*- mode: compilation; -*-
/home/r/bin/coq-8.5/bin/coqc -Q ... iris .../prelude/tactics.v
File ".../prelude/tactics.v", line 9, characters 50-51:
Syntax error: '.' or '...' expected after [tactic:tactic] (in [proof_mode:subgoal_command]).
The layout is "messed up", I cannot switch buffers in this window, etc.
from pg.
Just to confirm, after doing the final C-c C-Ret the emacs frame
is split vertically with coq-compile-response on the left. The
right side is split horizontally again with goals on top and
response below. You see the same?
BTW, the proper PG way to fix broken window layouts is
proof-layout-windows, usually bound to C-c C-l and in the menu
PG->Buffers-layout windows.
I just pushed a partial fix that makes this issue a bit less
critical. The coq-compile-response buffer should now not be in a
dedicated window.
A proper solution is a bit more involved. We first have to decide
where the coq-compile-response buffer should show up in
3-windows-mode:
- in the window of the response buffer
- in a new window
- somewhere else?
Then of course it should disappear again at the right time.
from pg.
Just to confirm, after doing the final C-c C-Ret the emacs frame
is split vertically with coq-compile-response on the left. The
right side is split horizontally again with goals on top and
response below. You see the same?
I do.
BTW, the proper PG way to fix broken window layouts is
proof-layout-windows, usually bound to C-c C-l and in the menu
PG->Buffers-layout windows.
I know; however, that binding is not available when the coq-compile-response buffer is active.
I just pushed a partial fix that makes this issue a bit less
critical. The coq-compile-response buffer should now not be in a
dedicated window.
So this means I can just C-c C-b back to the buffer that I was in previously? That would indeed help a lot.
We first have to decide
where the coq-compile-response buffer should show up in
3-windows-mode:
I would think it should appear where Coq output always appears, in the bottom right quarter. I actually wasn't even aware that this is not the same buffer.
from pg.
Ralf Jung [email protected] writes:
BTW, the proper PG way to fix broken window layouts is proof-layout-windows, usually bound to C-c C-l and in the menu PG->Buffers-layout windows.
I know; however, that command is not available when the
coq-compile-response buffer is active.
But it is bound in Goals and response, you could do C-x o first, right?
You can also always do M-x proof-layout-windows.
So this means I can just C-c C-b back to the buffer that I was in
previously? That would indeed help a lot.
Yes.
I would think it should appear where Coq output always appears, in the
bottom right quarter. I actually wasn't even aware that this is not
the same buffer.
I agree. The problem is to ensure the response buffer will show up in the same window when there is some response from the toplevel later on.
There are good reasons to have two different buffers. One shows response from the toplevel and the other shows standard output from coqc or coqdep. The latter one is in compilation-mode to enable the next-error feature.
from pg.
But it is bound in Goals and response, you could do C-x o first, right?
I guess I could. Any reason it is not bound in coq-compile-response?
One shows response from the toplevel and the other shows standard output from coqc or coqdep. The latter one is in compilation-mode to enable the next-error feature.
I see. What is that next-error feature? If PG is able to automatically jump to where the background compilation error occurred, then I wasn't aware of that.
from pg.
Ralf Jung [email protected] writes:
I guess I could. Any reason it is not bound in coq-compile-response?
Good point - no there is no reason.
I see. What is that next-error feature? If PG is able to automatically
jump to where the background compilation error occurred, then I wasn't
aware of that.
Yes, it's C-x `. There is not always a line number, but if there
is, it jumps to the error location.
from pg.
Related Issues (20)
- `coq-accept-proof-using-suggestion 'always` incorrectly believes that `proof` is a proof directive HOT 4
- Hitting 'tab' to indent just throws an error HOT 6
- Broken link in Ch. 11 of User's Manual
- ProofGeneral does not handle "Proof term." directives HOT 11
- Feature request: sparate commands for jumping to current point with/without omitting proofs HOT 7
- *response* buffer only showing last output HOT 3
- Tons of warnings when using certain PG features HOT 11
- "Omit proof" on a Let in a section leads to warning HOT 14
- "Omit proofs" breaks other proofs because it also skips hints HOT 14
- whitelist for admissible commands inside proofs HOT 17
- PG incorrectly interprets `}.` as a single token, which results in incorrectly accepting files that coqc rejects
- test_wholefile.v incompatible with 8.17 HOT 1
- Scheme ... with is indented improperly HOT 1
- Merging the Abella fork of PG HOT 9
- Automatic indenting for Easycrypt HOT 1
- generic/pg-goals.el shouldn't be executable HOT 1
- confusing error on incorrect _CoqProject file
- Colors don't work in emacs-nox HOT 1
- Compile-before-require setting does not presist HOT 1
- `coq-insert-suggested-dependency` sometimes inserts unparsable statements
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pg.