I copied the modelist.js file from the kitchen sink demo and added doc
comments to the exported methods.
This module would be extremely helpful to anyone implementing a menu
system or who wanted to programatically switch rendering modes based on
the file extension of the file loaded into ace. I can think of several
use cases for it already. (1) in the settingsMenu branch. (2) in
supporting theme switching for anyone implementing drag and drop support
for loading files into the editor (3) in supporting theme switching for
sites implementing their own file picker dialogues and loading content
into ace through xmlhttprequest (4) in supporting filebrowser / editor
applications where a server could be set up to display file contents in
an ace editor as users browsed to arbitrary files. (5) etc. etc.
Had I known about it when I began writing the settingsMenu branch I
would have used it.
This branch now depends on the modelist being pulled in as a module. I'm
using the modelist to generate the menu options for switching modes
because it's redundant to have the same massive list in two places.
The modelist module also has some awesome features so I choose it over
my silly list. :D
When the editor takes up the entire window and the window is only half
the size of my screen, the menus get crunched up horribly. I'll provide
for closing the overlay by pressing esc in case the overlay's contents
take up the entire screen.
If ace is to be used in very small frames then implementors will need to
provide styling information in css to control how the settings menu
looks.
The overlay menu should remain visible when scrolling a long page. The
intention is to present information on demand and not leave the menu on
screen. If allowed to scroll away the remaining element could interfere
with the page.
I pulled the code for generating the menu out into its own module called
overlay_page. I pulled the code for generating a menu, using
overlay_page, out into its own module called show_keyboard_shortcuts.
The logic for getting a list of keyboard shortcuts pertinent to the
current operating system is by itself in the module
get_editor_keyboard_shortcuts. This should make it easy for anyone to
change the appearance of the menu without worrying about breaking the
code which fetches the data.
I'm not set on the keybinding or the aesthetics of this. please change
them at will. The main goal here is to provide some method to list all
the keyboard shortcuts dynamically. I mean that when new shortcuts are
added they should automatically be put into this menu without anyone
writing any extra code. The menu provides a way for end users to easily
discover the many built in functions accessible through the keyboard.
Admittedly the current keybinding to display this menu is not very
convenient or easily guessed. I like the way that the textarea version
of ace presents a single clickable corner that is easily identified by
users. It would be cool to make this pretty and obvious.
I lowercased the file names. I've separated the code to generate an
overlay menu out into a module called overlay_page, it is the same code
as is in my other pull request for the keyboard shortcuts menu. It
should be easy enough to change the way it looks and behaves without
worrying about breaking anything. I've pulled code out into a module
called element_generator because it is pretty generic and isn't
concerned with gathering data for the settings menu. The element
generator can be reused and augmented but there is the possibility that
modules depending on it could break. show_settings_menu depends on the
element_generator. As it collects data it generates generic elements and
attaches event listeners to them. The massive list of options has been
moved into its own module for two reasons (1) it makes maintaining
show_settings_menu much easier and (2) this is the only part of the menu
which has to be updated manually. We may be able to add something to the
build system to automatically generate this module based on which modes
and themes are found to alleviate us from having to remember to add said
options in when new themes and modes are added.
I'm not stuck on the keybinding or aesthetics of this, please change
them at will. All I really want is the ability to display a menu where I
can change the editor's settings from and I want the menu to be smart
enough to automatically know about new settings. This pretty much works
except there isn't a registry for themes and modes so every new theme or
mode has to be added to the internal list by hand...
Is this the right way to use the static highlighter with the
noconflict build?
Edit as necessary. This is about as good as I can get it...
loads modules from script tags
makes div visible after highlighting
fixes display (sort of)
codeEl margin & padding 0
editor overflow auto, gutter position relative
replace code element with div
mode can be specified as a string
mode and theme may be specified as strings
This preserves the behavior of this method when specifying mode and
theme as objects. It adds the ability to specify mode and theme as
module paths. When specifying mode and / or theme as a module path you
must provide a callback function. The callback function will receive the
same value as the return value previously returned when specifying mode
and theme as objects.
Good stuff.
multiple elements with different modes and themes
The example shows multiple elements highlighted with different modes and
themes all in the same page. The pre element isn't ideal.
The example shows how to transfer the computed width and height of the
element into its inline style so that it won't dramatically change shape
and disrupt the page once it's had highlighting applied. It would
probably be better to replace the elements entirely and apply sizing
styles to the replacement elements but that isn't always an option.
