Do you know you can press F1 to open the query pane, and write there Show Proof?
Re executing the query (by pressing enter) is not as quick as hitting CTRL-SHIFT-R, but is way less painful than writing Show Proof.

I did not know that! Thanks for the tip, that will be way better indeed.
I guess I'll close this PR then.

Personally, I'm also missing a quick way to do Show Proof in coqide. After all, only half of the template-query space is in use, so we don't have to refrain ourself of populating it with most common queries.

What do you mean by half? The template menu is already too huge. The query one is indeed short. To my understanding what @cmangin was asking for is a key binding for Show Proof, not just an entry in one of the drop down menus.

IIRC, F1+RETURN should pretty much behave as "run last query". If not, we could add a shortcut for that as a sort of "meta shortcut" for the favorite, non already key-bound, query of any user.
Alternatively, we could add a "automatically run checkbox" in the query pane/tab so that you can detach it, and see it being automatically updated every time the goal window is.
I'm just brainstorming here, but I'd rather avoid having a shortcut reserved for each query, since their frequency seems to be pretty personal. E.g. I never, ever, do Show Proof... the proof I want to see is the text in the text buffer, not the lambda term; ditto for people using a lot of Ltac automation; but I guess it is the converse for HoTT people, since their proofs are transparent, or you and cmagin. BTW, why do you need to look at the proof term?

What I'm asking for is also a key binding for Show Proof (optionally with an entry in the query menu so that we can remember what is the key).

Maybe this is not an enough general-purpose request, and the question of not cluttering the menu is then relevant. I could live with a key which is not explicitly public (but then I'm sure some users will tell that we are hiding features).

I use Show Proof for various reasons. Often maybe just for developing purpose (what some high-level feature or tactic produced as a proof term). Sometimes to compare differences in the proof built when debugging a proof which behave differently from a version of Coq to another. Sometimes to be sure that what a tactic does is what I intend it does. Sometimes to understand the proof. Sometimes to see what refine has inferred alone. Actually, I don't know always why. I'm just used to use it.

I also use Show Proof quite often, mainly when I'm trying to understand what went wrong when building a proof term with an OCaml tactic, or to do a proof with tactics and then try to simplify it manually.

Another idea could be to just add the possibility to add user-defined queries/shortcuts. To make things simple, it would be easy to restrict it to queries without arguments.

I don't use CoqIDE frequently, but I would be in favor of being able to customize keybindings to arbitrary queries.

In theory GTK+ applications are able to let the use assign a key binding to any menu entry:

• at run time, by just pressing the key binding when the item is selected (this needs to be activated somehow, it is not the default, see: http://askubuntu.com/questions/107849/can-i-assign-custom-keyboard-shortcuts-for-menu-items-in-applications)
• by writing a conf file, see: https://developer.gnome.org/gtk2/stable/gtk2-Bindings.html

The first option requires the menu entry to exist, but not necessarily to have a shortcut.
Maybe we can make everybody happy by using this gtk feature. Can someone test it?

Should Show proof be in some right click menu? It is a contextual
information linked to each (not each actually) command (as the goal, the
ast, etc). I would definitely have a right click menu for this kind of
things, especially in async mode. And of course each menu command should be
shorcutable by the psychotic users like me.

P.

2015-07-01 23:19 GMT+02:00 Hugo Herbelin [email protected]:

What I'm asking for is also a key binding for Show Proof (optionally with
an entry in the query menu so that we can remember what is the key).

Maybe this is not an enough general-purpose request, and the question of
not cluttering the menu is then relevant. I could live with a key which is
not explicitly public (but then I'm sure some users will tell that we are
hiding features).

I use Show Proof for various reasons. Often maybe just for developing
purpose (what some high-level feature or tactic produced as a proof term).
Sometimes to compare differences in the proof built when debugging a proof
which behave differently from a version of Coq to another. Sometimes to be
sure that what a tactic does is what I intend it does. Sometimes to
understand the proof. Sometimes to see what refine has inferred alone.
Actually, I don't know always why. I'm just used to use it.

—
Reply to this email directly or view it on GitHub
#67 (comment).

Hi,

Afaik it works in some cases at least, I use this feature to rebind
navigation keys. The idea of user-given queries is appealing but I doubt it
would be trivial to implement...
-- Matthieu
Le jeu. 2 juil. 2015 à 09:59, Enrico [email protected] a écrit :

In theory GTK+ applications are able to let the use assign a key binding
to any menu entry:

• at run time, by just pressing the key binding when the item is
  selected (this needs to be activated somehow, it is not the default, see:
  http://askubuntu.com/questions/107849/can-i-assign-custom-keyboard-shortcuts-for-menu-items-in-applications
  )
• by writing a conf file, see:
  https://developer.gnome.org/gtk2/stable/gtk2-Bindings.html

The first option requires the menu entry to exist, but not necessarily to
have a shortcut.
Maybe we can make everybody happy by using this gtk feature. Can someone
test it?

—
Reply to this email directly or view it on GitHub
#67 (comment).

I made an attempt at user-queries, do you want me to update this PR, or to open another one, since the feature is different?

test build

Following @herbelin's advice, I have updated this branch with this feature.
In short, it allows one to add queries to the "Queries" menu, with a custom keybinding attached to it.

A few more detailed comments:

• It is configurable in the "Preferences" menu. Just like the modifiers, any change to the user-defined queries won't be taken into account until CoqIDE is restarted.
• The configuration interface is very raw for now (it opens one dialog to configure the query itself, and then one more to configure the key attached to the query) because it is the only simple way I found to implement this. With a little bit more work, I should be able to have a better interface, but it would require to learn about GTK...
• Again for simplicity reasons, the modifier for user-defined queries is the same as for pre-defined queries (<Maj><Ctrl>), which is not configurable (why?).
• The only allowed queries are simple ones, without any arguments. In fact, it doesn't check for it, it will just send to Coq what the user wrote very plainly, it's up to the user to make sure it is a correct query.
• The only allowed keybindings are simple letters (a-zA-Z). Anything else will result in the query not having a keybinding.
• Finally, something about the implementation: CoqIDE configuration file doesn't seem to be as typed as it looked at first. By that I mean that it can only store lists of strings (correct me if I'm wrong), whereas I needed to store a list of pairs. What I did (which is somewhat ugly), is to store each pair (q, k) as the string "q$k".

Any of these points is open to discussion and any comment is welcome, of course.

I just tried the patch. I could add "Show Proof" to the view menu but did not manage to add a binding (I tried W but it did not seem to have had an effect). The interface looks however a bit complicated to me: without explanation in the preference:User queries tab on the syntax of modifiers, on not being able to add arguments, on the need to restart (but 8.6 will be ok iiuc). I have nothing against adding more configurability and extensibility of bindings (1), on the contrary, but I feel it starts to be a different project than the initial simple objective (2) to have a "Show Proof" menu or binding or right-click directly available by default. So, maybe I'm wrong, but it looks to me there are still two relatively independent requests: (2) which is specific and simple and (1) which would require more work so that it is well put together (some help, format of coqide.keys, ...). And I would certainly be ok with both!

I've tried it out, it works. I'd suggest to merge the "shortcuts" and "user queries" pages into a single one and make the query menu modifier configurable too (as the view, ..navigation ones)

@gares: alright, I've implemented both suggestions (it was easy and quick anyway).

I would still like to understand why it did not work for @herbelin. Also, about your concerns, I agree that this change is more general than the original one, but I think it is a better one, so I've just changed the name of the PR.
I also agree that it would probably need some more work, especially some explanations for the user. On the other hand, it was already unclear to the user that you needed to restart CoqIDE for the modifiers to be taken into account, so maybe it is a problem which is not specific to this feature (the lack of documentation).

(Edit: well, I just saw that there was a notice about restarting now, so I guess that's better.)