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

fix statement-end detection in qtconsole #22

Closed
stevengj opened this issue Jul 28, 2013 · 11 comments
Closed

fix statement-end detection in qtconsole #22

stevengj opened this issue Jul 28, 2013 · 11 comments

Comments

@stevengj
Copy link
Member

Currently, the qtconsole front-end is broken because it is using a Python heuristic for detecting whether the statement is ended (i.e. whether starts a new line in the same cell or completes the cell and requests execution).

@fperez mentioned this issue, but I forget where he said it had to be fixed. (Somewhere in the front end, though, not in the back-end kernel.)

@minrk
Copy link
Contributor

minrk commented Jul 28, 2013

The QtConsole uses an InputSplitter to determine whether the current input block is complete and should imply execute here.

The long-term fix (hopefully this Fall) is to add a message for this, so frontends can query the kernel for this information rather than all frontends having to know about all kernel languages.

The short-term workarounds are:

  • use ctrl-enter to skip the complete-input check
  • monkeypatch is_complete to always return False, which would force shift-enter to execute (like the notebook)

We can probably add a simple switch in IPython that lets you skip input-checking with a flag rather than a patch to the frontend.

@StefanKarpinski
Copy link
Sponsor Member

Fall seems awfully far away – is there some dependency or release policy that prevents this being done sooner?

@Carreau
Copy link
Contributor

Carreau commented Jul 28, 2013

Fall means it will probably be implemented by Fall, just a question of time.
That would mean that the code will not be into stable before December
(releases every 6 month). An now we are in feature freeze for 1.0 (due in
2weeks)

Le dimanche 28 juillet 2013, Stefan Karpinski a écrit :

Fall seems awfully far away – is there some dependency or release policy
that prevents this being done sooner?


Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-21687898
.

@minrk
Copy link
Contributor

minrk commented Jul 28, 2013

It might be next week if you live on master, I just think it will miss the 1.0 cutoff since it's technically a new feature.

@StefanKarpinski
Copy link
Sponsor Member

Fair enough. A feature freeze is a feature freeze.

@minrk
Copy link
Contributor

minrk commented Jul 28, 2013

For instance... ipython/ipython#3814

@Carreau
Copy link
Contributor

Carreau commented Jul 28, 2013

We'll try to add the ability to disable autoexec for 1.0 (we really love you guys), but changing the message spec for 1.0 might be a lot.

@StefanKarpinski
Copy link
Sponsor Member

That seems like a reasonable compromise – thanks!

@stevengj
Copy link
Member Author

stevengj commented Aug 6, 2013

Closing for now, since this is a reasonable interim solution pending spec updates.

@malmaud
Copy link
Contributor

malmaud commented Jan 2, 2014

@Carreau @minrk Any updates on this?
I'm trying to get IJulia qtconsole up to snuff: customizing the new FrontendWidget.lexer_class option is giving me good Julia syntax highlighting, but we still need statement-end detection and autoindenting.

@minrk
Copy link
Contributor

minrk commented Jan 3, 2014

No, there has been no progress on extending the statement parsing in frontends. A proposal has been made to add a message for querying the kernel, since that's where this knowledge actually resides.

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

5 participants