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...
