Intro
A custom configuration with selected functionality preset, revised menu layout, and optimized input shortcuts.
Purely focused on enabling the ultimate power while retaining the ease of access, to unleash the full potential of UltraEdit to the maximum extent possible: shedding light on functionality that's been there for long but left in oblivion, the unseen potentials. A new vision.
Still blinking caret indicator(s) (on the editing document) with such context menus open.
Including when focused on those "floating" "docking" "dockable" windows whatsoever. (e.g. "Find and Replace" docked on the right)
Command palette open position references to the mouse.
When opened at the edge of the screen (due to mouse position): if the following mouse movement (in 2000 ms) was (largely) towards the screen center, the palette shall follow it (moving to the center) for an appropriate extent.
Afterward retain the current behavior (position remains fixed). Or probably making the palette somewhat resembles to the "floating" window? (maybe even configurable window size)
Note: the distance highlighted on the image is 32 px (both X,Y).
Like what's in "Find and Replace", "Regular expression builder":
(navigation via hovering/click on the button like item)
Off-Topic: Yes, it's apparently broken. (the \ character display escaping problem in the UI)
Highlighting the related items (if present) in the opened context menu at the same time.
Whether present or not, the item's description shall be reflected on the status bar.
Weird whim: possible to implement some sort of limited extent multi-select (via the typical Windows shortcut: Ctrl / Shift / Ctrl + Shift + Click / Arrow Up/Down) functionality, for those "order insensitive" / "non conflicting" options? (e.g. "Split window horizontally" and "Split window vertically")
The idea applies to other types of context menu too.
Multi-frame multi-caret editing support.
Active frame highlight indication. (in multi-frame view only)
Note: the right/bottom border should appear in full length, when the next adjacent frame is not highlighted.
The column ruler(s) shall correctly reflect the active column(s) for all frames.
The app failed to do so on the focus switch between frames. (bug likely)
Every pixel of available space shall be made of full use:
There shouldn't be any point for that "little gap" to exist, near the end of the document view (both the edit window and document map). (also near the start of the document map)
Two independent search inputs (non interfering), with shared search history.
"Search options" control from the main input ("Find and Replace": "Find").
"Find String List" adding a new sub-tab similar to the "1", "2" in "Output Window". (to handle the "Dual Find String")
Expanded bookmark tags for wrapped lines. (see also: Line wrap handling)
Probably color tinting on the column ruler(s) can also be utilized to represent bookmarks on the same line (of different column). (only when active on the bookmarked line, for the wrapped part only)
No default focus on the suggestion target. (optional?)
Pressing Arrow Up/Down (depending on the pop-up type: "high" / "low") once to focus, instead of auto focus. (to avoid input competing with suggestion from the input method)
Edge of the suggestion (start/end) Arrow Up/Down escape (quit from the pop-up).
No action for Page Up/Down. (people tend to spam them)
Caret(s) shall remain in the old position afterward. (unlike the Home/End, Arrow Left/Right escape)
The first press shall quit the box, only if not focused on a suggestion; else unfocus from the suggestion instead. (and pressing the opposite arrow key shall bring the focus back)
Likely unwanted: Esc escape moves focus to "Find and Replace" (docked, "Find what:"). (see: Input listening § "Esc" logic)
Toggle-style shortcut invocation. (when the pop-up is shown, pressing the shortcut again to hide it)
For "Focus to open address bar" (CommandID: 10012) too.
Off-Topic: "Focus to quick search bar"? Neither "Quick find" nor "Quick find switch focus" worked.
Mouse Over (hovering) auto focus.
As it doesn't focus to the suggestion box with mouse-over: Mouse Scroll in this case will cause the active document to scroll.
Off-Topic: and the box to collapse too, perhaps not a good design. (newly added Shift + Mouse Scroll causes somewhat different behavior, though again likely unwanted)
Mouse Click unfocus, shouldn't trigger a caret navigation.
The same for "Command palette".
Should behave just like the right-click context menu in the editing area.
Using negative lookbehind while removing * leads to another bug. (DOS line break exclusive: pattern match despite it shouldn't)
\s
Removing * leads to another bug. (DOS line break exclusive: pattern not match despite it should; with Unix line break (or replacing \s with a literal line break): back to the same symptom as without removing)
An option for confirmation before app exit, unconditionally? (as a workaround)
Accidentally closed the app may present some bad implication. (e.g. potentially losing the currently filtered view, bookmarks, highlight, etc.)
The optimal handling is not unconditional confirmation, but confirmation only when the potential of such unwanted scenarios exists. (if properly implemented, the behavior can be made default and enforced)
Tool bar buttons, "Classic" theme mouse-over tip:
Should be ported to other theme types too.
Note: the pop-up shall appear immediately upon mouse-over, and stay indefinitely (as long as the mouse remained within the icon).
Inability handling files of exceptionally long name. (any more than 200 characters, extension not counted)
Off-Topic: Probably there needs an option to limit the max allowed width of a single tab.
Note: the tab title omitting shall be placed at the center of the text. (not neither edge)
What's the point having the horizontal scroll bar fitted to handle more characters than the set "Maximum columns before line wraps:" (CommandID: 1188) could support?
"No highlighting" (CommandID: 34399), toggle-style switch? (attempts to switch back to the last used highlighting scheme, when invoked in "No highlighting")
