Possible next version

Principles of the Script-Plugin:

• Bring DrRacket closer to Emacs---empower the DrRacket user.
• Make it easy to modify and extend DrRacket.
• Writing a very simple script should be very simple and quick.
• No need to restart DrRacket after writing a new script or modifying an existing one.

List of ideas for the (maybe) next version of the script-plugin, so that it has a chance to be included in the main distribution:

• rename the 'examples' directory to 'scripts'.
• Probably no name is required if included in DrRacket. 'scripts' is probably fine.
• Add the possibility for /temporary/ scripts, that are even more easy to write, and get rid of, like an additional panel to parse the current file (not sure yet for what purpose though, maybe ).
• No rktd file? Maybe using submodules to have everything in the same page
• Think harder about how to make sure user defined scripts are untouched when new version of the plugin are available, but allow for modifying bundled scripts easily, possibly reverting to their bundled version. Possibility: Import/copy bundled script, plus Revert to bundled script (delete local copy).
• can scripts load/remove other scripts?

Questions (noting not all are sensible and some conflict with each other)

• Should all scripts be in one file like Emacs config?
  • L: I'd rather not, so that installing new scripts can be done automatically by copying files in the correct directory without having to modify an existing one (which is always a risky process)
• What should be the relationship be to the existing 'Add user defined keybindings'?
  • L: There are 2 different mechanisms (AFAIU) for keybindings in DrRacket: The first one is provided by the GUI, i.e., the OS through the menus---the script plugin uses that. The second one is via intercepting keys typed in the editor, which (I think) is what the user defined keybindings does. The latter should be more powerful and easier to handle by DrRacket than the first one. Alas, I think we have to stick with the first one.
• Identity
  • Should it have an nice icon? - a nice signals 'new' functionality
    • L: A nice icon would be nice, but that's not top of my priorities.
  • Would be nice to give it a name as it can be switched on or off - 'scripts' seem to generic but this is exciting
    • L: QuickScript is a good name I think.
• could 'examples' be named to something more descriptive than 'scripts'?
  • how about 'script-library'? other suggestions: ‘bundled-scripts’, ‘master-copies’ or ‘original-scripts’ as the scripts in the examples directory are not runabout copied to the users scripts folder
  • L: Yes, we could have a "bundled scripts" directory, for useful scripts that the user is likely to want. Another "user-scripts" directory for home made ones. And maybe a "demos" directory for scripts that are not useful but demonstrate the capabilities of the plugin.
• if you have a 'script-library' that implies being able to select the ones you want
  • e.g. 'tweet selection' is a powerful example, but you probably don't want it loaded as default.
  • L: Yes, there should be a simple way for the user to activate/deactivate scripts. Currently there is a active? attribute that can be set to #f in the rktd file.
• Does 'Add user defined keybindings' do anything that script-plugin can't?
  • L: It's more robust at least, as platform-independent.
• Should 'Manage scripts' be like the preference dialog?
  • Should it be part of the preferences dialog? (that generates .rktd files?)
  • should it have its own editor?
  • should it be replace to 'Add user defined keybindings' and 'add user defined keybindings from PLaneT'
  • L: Why not, that would simplify the menus, but not a priority I think.
• Should there be a #lang racket/script that imports some suitable default requires, and has macros that;
  1. lets you define configuration and scripts in the one file
     • new define construct (define/script (identifier "label" args) (/additional parameters?/) ...)
     • L: Yeah, I was thinking about that too. That may be necessary for one-file scripts.
  2. ??
• exporting script to GitHub/Gist/Pasterack?
• Should scripts have their own package-catalog?
  • L: I wonder how to facilitate the importation of other-users defined scripts. It would be nice if it worked just like a normal package.
• .rktd as a #lang like #lang info?
• importing scripts from scripts /package-catalog/
• should scripts always appear in a menu as a menu item?
  • L: How else to access them?
    • S: Keyboard, right-click (context menu), or a defined event (git commit if all test passed, plot data)
• add a list of scripts and supplied identifiers
• warn if redefining an existing script identifier

categories for scripts;

default script - these come bundled, work out of the box, and you are unlikely to change e.g. colour script template - these come bundled with the intention that they are modified. e.g. 'author-... library script - script you might not include be default, but unlikely to be customised. e.g. ??? library templates scripts - scripts that are intended to be customised e.g. 'tweet'