One of the behaviours of emacs that I want to avoid as I build edlib (my answer to emacs) is modal dialogs. I recently saw mention of Oberon and this link in particular: https://pdfs.semanticscholar.org/d48b/ecdaf5c3d962e2778f804e8c64d292de408b.pdf. It also mentions an aversion of modal dialogues. I don’t find myself completely convinced by the example given, but I do support the idea. This is as good an excuse as any to clarify my thoughts on the topic.
Emacs doesn’t have a lot of dialogues, and what it does have mostly make use of the “minibuffer” – a one-line buffer at the bottom of the frame (aka “window” in non-emacs speak). This minibuffer is special. You cannot switch into it or out of it using “C-X o” which is the standard command for moving to an “Other” window (or “pane” in edlib-speak). You can sometimes use the mouse to click to get out of the minibuffer, but that tends to confuse emacs. So edlib doesn’t use a minibuffer like emacs does. The bottom line of each frame is reserved and is used for displaying messages, but not for receiving input.
Instead, edlib has “popup” panes. These can appear over normal panes, obscuring what is underneath them. My favourite example is for search. When I start a search, a pop-up appears at the top-right of the pane and I can enter a search string there. As I do, the first match is displayed and highlighted, and any other matches that are visible are also highlighted. This popup acts in many ways like a normal pane with a normal document. I can edit it with all the normal keystrokes. A couple of keystrokes are repurposed, so for example “Enter” doesn’t start a new line, but instead completes the search. But most editing works as expected.
Pane movement behaves as normal where there are popups, so “C-x o” will cycle around all displayed panes, including any popups. If there are multiple documents in tiled panes, then each one can have its own active search. A document being searched can be navigated and edited while the search is active. As you move around the document, if new matches appear they will be highlighted.
With emacs, it is possible to activate a “recursive edit” while searching and edit the document without aborting the search. I suspect this is useful, but I never became familiar with the process. In edlib, nothing special is needed. If you want to edit, you just do that. This works because the search dialog is not “modal” – it does not take control. It just provides a service.
Confirmation Dialogs.
Probably the most annoying modal dialogs are confirmation dialogs. These interfere when you ask to do something that the editor thinks is unusual or dangerous, so the editor asks you to confirm “Yes or no?”.
I see two different approaches to preserving the safety, but removing the dialogue. One is to have distinct commands for unusual actions. So when I enter a name to open a file I have two options for completing the request. If I type “Enter” – the easiest action – the file must exist, or I get an error. If I type “Alt-Enter”, the file must not exist. The error I get if I just type Enter reminds me that Alt-Enter is an option. This isn’t directly comparable with emacs as emacs allows “Enter” to be used to create a new file, though sometime it asks you to “Enter” again just to be sure.
The other approach is to support undo. One behaviour of emacs that often bothers me happens when a file being edited changes without emacs changing it. For me this often happens when I use “git” to manipulate a source code tree. emacs notices the change and asks me if it should reload the file. I don’t want to be asked – just do it. So edlib will reload the file if it doesn’t currently have any updates. If it does have updates, it displays that the file is “changed” and will make a backup if I save. This is mostly what I want but not always. Sometimes I really want to keep the content in the editor even though it has been written out. My plan – not yet implemented – is to support “undo” across a file reload. So if I save a file, then accidentally destroy it with git or some other command, the file might get auto-reloaded by edlib, but I can just “undo” and get back to where I was.
Save-as dialogs
Lastly I need to discuss save-as, as this is the use case mentioned in the document about Oberon. Apparently with Oberon you can click on the document name displayed in a title bar, type in a new file name, and the document will be saved there. This seems nice, but a similar interaction would make sense for “rename”, so it isn’t clear which action should be performed by that interaction. So I doubt I’ll follow this pattern too closely.
I haven’t implemented Save-as yet so I don’t know what it will look like, but I suspect there will be a per-pane popup with the file name, probably at the bottom. Like with “Search”, the popup can stay there indefinitely. Options for the action are “Save-as”, “Save-a-copy” (save, but don’t change the preferred file) or rename. I think all of these are useful, but I don’t yet know how I’ll choose between them. In all probability I’ll just implement something and wait for it to annoy me. Then fix it. As long as the dialog isn’t modal and allows me to move away and come back, I’m happy to have a dialog box with options.
