Known Issues

and Workarounds

 

Below are categories of known issues (bugs, design flaws, incompatibilities).

Please let us know if you should find more issues and make a comment in the appropriate area of our forum. We are working hard to improve Iron with your help.

darkviking.com/forum

Thanks much!

It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better.

 The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.

Theodore Roosevelt

26th President of the United States, Delivered in Paris, April 23, 1910

Mouse Interface

Note:  The mouse interface is experimental and under-developed. The mouse interface will get more attention soon and have a traditional mode that works similar to other popular editors and operating systems.

A bit of history on Iron’s development and early goals may help explain why the mouse interface is under-developed.


First off, Iron was built as a virtual space editor that supported only block column and line selections sighting that the traditional stream selection for working with prose is a poor mechanism for working with the repetitive nature of source code. Hence, the mouse currently manipulates only column and line selections.

<back>


Given Iron’s native propensity for line and column selections, when dragging the caret and moving the mouse cursor over the line numbers, this changes the selection style to line selections. Moving the mouse cursor off the line numbers reverts the selection to the column style. There is no means currently to coax mouse style changes to stream selection. Hence, the mouse does not manipulate stream selections currently.

<back>


Iron’s Traditional Mode and stream selection are relatively new additions. In Traditional Mode, stream selections are (too) easily canceled by simply moving the caret or (too) easily deletes selected text when inserting text (a conflict of actions). Hence stream selections are non-sticky, they go away as a result of most any activity. Column selections on the other hand only make sense if they work in virtual space and remain sticky. For example, deleting a block column selection and then inserting a single character on one line isn’t useful. Deleting a block column and then inserting the same character on each line of the column is useful. So is using Delete or Backspace and keeping the column selection active. Thus column selections become a hybrid in Traditional Mode being both sticky and always existing in virtual space. Since column selections and Traditional Mode are new, column selections are not yet consistently sticky in Traditional Mode.

<back>


Though native to Iron, the line selection style makes no sense in Traditional Mode. The expectation in Traditional Mode is that inserting a character will delete currently selected text. So if there are a bunch of lines selected and a character is inserted, all the lines are deleted in Traditional Mode and the line selection is canceled in a non-sticky fashion where in Iron Professional Mode line selections are sticky and only Ctrl+X Cut will delete them. Unlike column selections, line selections make no sense in Traditional Mode.

<back>


Iron’s interface purposely does not include scroll bars (and initially no fixed menu) so as to devote as much screen acreage to source code. In virtual space editing mode, moving the primary caret outside the caret box determines when, how much and how fast the text scrolls to keep the primary caret on-screen at all times. This is accomplished with the mouse by holding down the left button and dragging the caret in virtual space. In traditional editors, this action creates a stream selection. Since stream selections are a new addition to Iron, this mouse interface had worked well until recently. Also to note, non-virtual space editing is newly supported. Hence, selecting text with the mouse and scrolling with the mouse are incompatible at present and has not been remedied to work well in non-VSE Traditional Mode.

<back>


Iron, from the beginning, strives for consistency and simplicity to elicit greater efficiency and less fatigue for the experienced programmer. So many of the auto-delete and auto-cancel features associated with traditional stream selections were not carried forward (until recently). In particular, moving the caret does not cancel a selection in Iron Profession Mode, only using the Escape key ESC or Ctrl+X Cut or Ctrl+C Copy cancels a selection. Hence, there is no means to cancel a selection with the mouse.

<back>


Iron Professional Mode using Virtual Space Editing is Iron’s native mode, developed for experienced programmers who typically rely on the keyboard interface and avoid use of the mouse as being exceptionally slow and cumbersome. Hence, our motto: More keyboard, less mousing around.

<back>


Since Iron’s author works exclusively in VSE Iron Professional Mode and avoids use of the mouse entirely while developing software in all tool, Iron does not yet support dragging and dropping of selected text with the mouse.

<back>

 

International Fonts and UTF-8 Support

Iron’s goal is to support international fonts via UTF-8 multi-byte format. Iron’s keymap files, parsers, scrap/clipboard, Copy/Cut/Paste and other fine editing utilities all support UTF-8 left-to-right (LTR) manipulation. However, Iron’s font glyph atlas management routines that render clear type fonts via OpenGL are naive and, in some circumstances, too quickly runs out of graphics memory. This will be remedied. Ligature support is also uncertain at this point. Hence, Iron at this time, supports only the ASCII character set.

<back>


As mentioned above, Iron’s font glyph management system is a bit naive. Thus, when changing font sizes, the amount of graphics memory consumed by the font system grows rapidly. Eventually the font system cannot create the glyph atlas texture map to accommodate a large font size and renders blocks instead of text characters.

Workaround:  Revert to the stand font size with Ctrl+0 or revert to a previously visible font size Ctrl+-. Another option that may allow rendering of larger font sizes is to simply delete the font resources or the entire font directory: /Documents/DarkViking Software/Iron vmm.xx/user/shared/fonts. Iron will rebuild the minimum glyph atlas for the current font size.

<back>

Fine-Editing

Support for the horizontal tab character is new to Iron. Iron’s author, the majority of experienced programmers as well as the bulk of GitHub projects avoid use of the horizontal tab character for numerous reasons (and is blog discussion not appropriate here), hence Iron’s support for the horizontal tab character, using it appropriately for padding inserted text, is not yet 100% consistently implemented.

<back>


We recommend using the Virtual Space Editing mode which is native to Iron. In VSE mode, Iron avoids placing extra whitespace (padding in the form of spaces or horizontal tab characters) where not needed. So the Tab key only moves the caret into virtual space to the nearest tab stop without padding. Padding is added only when inserting a character (or text from the scrap). Shift+Tab will move the caret or delete whitespace back to the nearest tab stop or first non-whitespace character. Thus, the Tab key rather than the horizontal tab character is used for source code vertical alignment.

<back>


Since Iron natively works with virtual space and controls tab stop alignment with the Tab key and Shift+Tab, there was no need to support the horizontal tab character early on. Though we strongly discourage use of the horizontal tab character in source code, we do recommend horizontal alignment and horizontal code chunking for easier comprehension and subsequent refactoring. Since the horizontal tab character presents a variable width of tab virtual space, this of course introduces conceptual editing conflicts with the Virtual Space Editing mode. For example, when moving the caret vertically, can the caret move into the tab character space or does it move to the beginning or end of the tab virtual space as is common in non-VSE editors? In Iron, when in Virtual Space Editing mode, the caret is allowed to move into tab virtual space. This then introduces several issues for cutting and pasting and inserting text. First, for inserting text, does that occur at the caret’s location or before or after the horizontal tab character? When deleting text and the caret or a selection edge resides in tab virtual space, is the tab character deleted, cut or copied? Iron’s solution is to treat tab virtual space like other virtual space, essentially unoccupied or undefined that gets padded with spaces as needed. Hence, Iron’s horizontal tab character rule: Preserve horizontal tabs characters where used but convert tab virtual space to the equivalent number of spaces before the edit operation.

<back>

 

Selections and Multi-Selections

As described above, stream selections are relatively new to Iron and their compatibility with the Multi-Selection feature is not thoroughly implemented or tested. In Iron’s native Iron Professional Mode, column and line selections are sticky and allowed to overlap. In Traditional Mode, allowing stream selections to overlap makes little sense but has not yet been addressed. Hence, stream selections and bare carets do not currently merge and are allowed to overlap which may lead to unexpected Copy/Cut/Paste or text insertion results.

<back>


Iron’s Multi-Selection feature is designed to allow multiple selections of different selection styles including bare carets. Since bare carets and streams selections to not merge yet, it is easily possible that bare carets will coincide and if latched will produce unusual results like inserting the same character multiple times.

Workaround:  When canceling multi-selections, press and hold the Escape key ESC until all the selections and bare carets have been canceled. Bare carets and selections will render in different colors (and shapes) when there is latched multi-selection. An alternate good habit when using multi-selection is to Cancel All with Ctrl+Shift+Delete (or even Cancel Everything Shift+ESC though that could be overkill and close popup panes).

<back>


As described above, stream selections are relatively new to Iron. When using multi-selections, column and line selections can overlap and envelope another selection. Given the order of creation of multi-selections defines the order which Cut and Copy and text insertion will be applied, enveloping of one selection by another selection can mean the enveloped (smaller) selection is completely deleted before it’s copied. Overlapped selections, though possible and occasionally useful, they do not always produce intuitive editing results. Keeping the interface simple and predictable is an Iron goal, hence column and line selections never merge automatically (can be done manually with Ctrl+Shift+M) though one selection can in essence delete another selection it completely envelopes. Column and line selections are both a block, stream selections are not. Hence, currently overlapped column and line multi-selections incorrectly envelope stream selections and vise versa.

<back>


As described above regarding stream selection enveloping problems due to its non-block shape, combining and splitting multiple stream selections using Ctrl+Shift+M is not working in Traditional Mode. Column and line selections work properly.

<back>

 

Menu System

One of Iron’s early design goals was to avoid being “menu’ed or dialog’ed to death” as is common in too many editors and IDEs. Along with a strong desire to emphasize keyboard interaction and avoid use of the mouse, Iron incorporates a Command Palette and originally was not intended to have a menu system. There was also a strong desire to maximize screen space to source code and not devote any to a menu or scrolls bars. But that leaves Iron inaccessible to beginners and novice Iron users. The menu system is the best or most commonly used means to discover functionality within a software application. So Iron’s menu system is relatively new and under-developed, hence there is currently no keyboard subsystem that interacts with the menu system.

<back>


Iron’s user-interface is meant to be easily customizable via Zinc formatted text files. This is true for the menu system via the iron.menu file. A long time goal of Iron is to support the notion of continuous compilation recognizing that programmers are slow input devices that typically manipulate one file at a time. A modern build system and compiler suite should be able to compile a project faster than a programmer can press the Compile button. That’s true for Iron’s Zinc compiler. It compiles and syntax highlights as-you-type and the Compile button is really just a Commit button. Making a long explanation no shorter, Iron processes input asynchronously to its rendering thus committing to Zinc file changes presents a synchronization conundrum not adequately solved. Hence, occasionally the main menu bar does not render though it is present and drop-down menus function normally.


Workaround:  Just restart Iron, recompile and commit any Zinc file or toggle the Menu Auto-Hide.

<back>


As described above, the menu system rendering has a conflict the keyboard processing thread. The main menu may not display at session startup when holding down some keys or mouse buttons before the main menu displays initially.


Workaround:  Press the Escape key ESC. Or restart Iron, don’t hold down a button.

<back>


Since rendering a menu drop-down is not instant but a smooth, graphical transition, a menu item may not be rendered, fully opaque or simply not ready to be selected when releasing the mouse button for the Menu Recall Last feature. Thus, when using Menu Recall, releasing the mouse button before the drop-down menu the recalled menu item is a member of may or may not be selected.

Workaround:  Move slow when using Menu Recall Last by pressing and holding Ctrl+Mouse_Left until the entire drop-down menu is rendered.

<back>


The Menu Recall Last feature automatically positions the mouse cursor over the location where the last menu item was selected on the screen and then renders all the appropriate drop-down menus. Important is that the features uses the last selected menu item which would be the Menu Recall Last menu item everytime if it was not disabled. Hence, the Menu Recall Last menu item is never selectable itself, its only present in the menu to expose the shortcut key binding Ctrl+Mouse_Left.

<back>


Iron uses the OpenGL graphics library within a Windows window. With the advent of HDPI (high-density or high dots per inch) monitors, Windows allows applications to operate as an HDPI-aware app (a new thing) or as a non-HDPI-aware app. In using OpenGL and not employing Windows widgets, Iron is somewhat between in its HDPI-awareness. Technically, its not aware which means it gets composited or upscaled before its rendered to an HDPI monitor. Not being aware can affect the clarity of Iron’s clear type font rendering but because the density is so high, it’s not noticeable. However, there is one instance we’ve discovered where not being HDPI-aware (and that’s to change in the future) is using a laptop with an external USB monitor with the laptop lid closed. Windows reports its window-size incorrectly in this weird case so Iron attempts to render in a space not matching composited window’s size. Thus the OpenGL drivers renders outside the composited window and the mouse cursor location no longer aligned with the graphics elements. Hence, the main menu seems to be nearly off the top of the screen and the mouse cursor picking location does not coincide with the drop-down menu items.

Workaround:  We added some poor adjustments that compensate roughly for the compositing disparity but its not a true solution. Enable the Tools|Advanced Controls|HDPI Menu option and the main menu and cursor functioning will improve. The other option is to open the laptop lid or run the laptop screen and the USB monitor at the same screen resolution. Our intent is to have Iron be fully multi-monitor HDP-aware in the future (and clear type font correcting for vertical versus horizontal LED elements).

<back>

 

Command Palette

Iron’s Command Palette is highly experimental. It can perform quite a number of functions including loading files, searching for text, going to specific line and character locations and disabled functionality. The Command Palette makes use of parsing precedence rules and a grammar for interpreting it’s colon syntax. The interpreter does not always know your intent when colons are not used, for example it may load a file of the same name as the text pattern you’re searching for. There’s also quirks about repeating successful and unsuccessful searches and other commands. Hence, sometimes Find and Find Quick fails to search.

Workaround: Proceed your search pattern with a colon. Or use the Find-in-File command which is “ff <pattern>” (without quotes, space required). Neither of the FF and FIF commands employs the colon syntax so the search <pattern> is not interpreted in any way hence all characters after the separating space, including horizontal tabs, leading and trailing whitespace are maintained as part of the pattern.

<back>

 

Rendering

One cardinal rule with Iron is that the primary caret is always on-screen. This is accomplished by defining a caret box which is, for most panes, smaller than the pane, that is, defined x number of lines or percentage from the stop and bottom and y number of characters or percentage from both edges of the pane. When the caret is moved above the caret box, the pane smoothly scrolls down so the primary caret is x number of lines from the top of the pane. In smart scrolling, if the caret jumps down a page, the new line should be smoothly scrolled to the same screen location. And if a search matches to a file location well off-screen, that line will be smoothly and quickly scrolled to the center of the pane. The intent with the smart/smooth scrolling is to get the programmer a relational notion between the old and new caret locations while also minimizing the amount of scrolling and scrolling to a natural location within the pane and not always at the very bottom or very top line of the pane. The center location can be adjusted if the programmer is more comfortable if the working line is, say, ⅔ down from the top of the pane. The algorithm to determine the scroll location is just simply broken so the “smart” part of the scrolling and centering text is currently disabled.

<back>


In preparation for fixes to Iron’s Undo System to better accommodate lexer and syntax highlighting, scrolling information was removed from the undo/redo queues. Iron’s goal is that the undo/redo will restore the scroll location to its previous position so it looks familiar and not undone at a different location in the pane. Hence, smart/smooth scrolling does not undo/redo the scroll offset to the proper location.

<back>


Iron is a highly-threaded application. Rendering and keyboard input are processed asynchronously. The intent is to get the most response when editing text where the change in a line of text is not forced to wait for the next complete frame update. That is if the edit completes and parses before the rendering thread attempts to render edited line, it will be rendered, syntax-highlighted in the current frame. There is a quirk in the asynchronous processing where, if there is no animation and the rendering thread is not continuously producing new frames, the caret position is adjusted after the edit and lexing may complete after the rendering thread supposedly renders the changed line — the engine fails to recognize it needs to generate another frame because the caret has moved after the frame completed. The caret internally has advanced, it just was rendered at the old location so subsequent edits will be in the correct location. Hence, when not animating, the primary caret fails to advance after inserting a character.


Workaround:  Keep some element, like the Steampunk globes, animating and the caret will be rendered correctly in the next frame. Or press or release any modifier key (Ctrl, Shift, Alt) which will cause a new frame to be generated. Remember, all the cool kids want the animation all the time ‘cause it’s fun.

<back>

 

Audio

Iron’s audio cues are experimental and hope to expand the use of audio in the future. At the present time, Iron uses the OpenAL audio library which offers some 3D audio capability and cross-platform capability. We’re likely to migrate to another audio library in the future but until that time Iron will not run (crash at session startup) without OpenAL audio drivers (DLLs) installed.

Workaround: Install the OpenAL audio drivers. They’re rather innocuous, very light and can be easily uninstalled via the Control Panel. The drivers can downloaded directly from the OpenAL website or re-install Iron which will install the OpenAL drivers.

<back>