Opened 12 years ago

Closed 15 months ago

#7618 closed enhancement (invalid)

notebook -- make it easy to configure keyboard shortcuts

Reported by: was Owned by: was
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: notebook Keywords:
Cc: chapoton Merged in:
Authors: Reviewers: Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges


>> It's really easy to configure the keyboard shortcuts -- perhaps that
>> should be an entry in the settings page?

> Yes, definitely.  Could you post some remarks in an email about how
> you think adding keyboard shortcut configuration should be
> implemented... and probably I'll implement it as a result.

Tom Boothby:
Well, right now there's some functionality to statically change the
keyboard shortcuts through  IIRC, there's a global
dictionary of keyboard shortcuts which establishes a mapping

'name' -> [(modifier1, key1), (modifier2, key2), ... ]

and when the user requests the main javascript file, this is compiled
into javascript.

I think that it'd be easy to implement this for users -- from their
settings page, they could override the server's  If the
user had a dictionary  similar to the above, that would be loaded
after the global config.  This would give the user an opportunity to
add or override shortcuts.

For example, say the global configuration results in

Shortcuts = { 'eval' : [('shift', 'enter')], 'break cell':

But, the user also wants shift-tab to break cells.  So, they go to the
shortcuts settings page, scroll down to the "break cell", and add that
entry.  Now, their settings would contain (for example... I have no
idea how the settings are implemented)

user.settings['shortcuts'] = {'break cell' : [('ctrl','semicolon'),

Note that they haven't modified 'eval', so that doesn't get put into
their settings.  This way the user's settings dictionary is spliced
into the global settings when we render the javascript (so new
features will work without the user manually adding them).

Note that the input handler (I think) always returns once it's
identified a shortcut as having been pressed, so we don't need to
check if a particular shortcut is unique.  Otherwise, it could be
great fun to map everything to a master "do everything always" key.
Maybe an unmodified spacebar.

I think that the actual input form for this should be pretty
self-explanatory -- but I can describe what I'm thinking for that too,
if you want.

Change History (7)

comment:1 Changed 8 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:2 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:3 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:4 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:5 Changed 16 months ago by mkoeppe

  • Cc chapoton added
  • Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
  • Status changed from new to needs_review

Proposing to close all sagenb tickets as outdated, so that all remaining open tickets in the notebook component are about the Jupyter notebook.

comment:6 Changed 16 months ago by dimpase

  • Reviewers set to Dima Pasechnik
  • Status changed from needs_review to positive_review

comment:7 Changed 15 months ago by chapoton

  • Resolution set to invalid
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.