Open

Open Issues

This page is about open issues in design and implementation.

Design

Cursor concept

There are a bunch of possible "current" items on the screen in a combined log view:

• current screen row;
• current logical line (aka fold) of the log entry;
• current log item;
• current file;
• current unit;
• current search match (may span lines; and one line can have multiple matches);
• current page shown of combined view (i.e. current top-bottom lines).

We have to pick how to assign commands to navigate these, and how to visually designate them, without the view getting cluttered.

The central concept in the combined view interface is that the screen is a "sliding window" view on a long piece of text; this text is the interleaved (in order of timestamp) list of items (aka log entries) of all log units in that view. We also have a "current item", which must be somewhere in that sliding window: if the user issues commands to slide the window so it would no longer contain the current item, the UI changes the current item to one that is contained; and if the user tells to UI to jump to a new current item outside the sliding window, the UI will slide it over to show the new current item. On the screen, we have visual distinction between the (label of the) current item and the other items. This is a simple principle, but has some edge cases:

• Some logs may be empty, so you can lack a current item to display.
• An item may have multiple logical lines, and a logical line may wrap to cover multiple screen rows. The total number of screen rows needed to fully display a single item may be more than the size of the sliding window.
• A search pattern may occur anywhere in a log entry (though we ignore the timestamp area, because we do not show that on the screen either). This means it can be split over more than one line, occur multiple times within the same item, or the same logical logical line, or even the same screen row.

To deal with items that do not fit on a single row, the UI actually uses a "current line" (meaning row) cursor. Problems with this are:

• only the first line of an item has a label that we can visually change as a cursor now, so we cannot indicate the current line position on other lines;
• navigation between multiple search pattern matches on the same line is hard to depict;
• if we allow folding (suppressed wrapping) in the UI, search match navigation is even messier;
• what if a pattern match does not fit on the screen;
• what about overlapping matches.

The wrapping of a single logical line over multiple screen rows is influenced by display settings (label format, unprintable character expansion, folding) and external factors (screen width: may change during window resize). For this reason, we express a "location" value as an offset (in bytes or characters) into a specific log item, which is independent of the rendering on the screen. A "mark" (in the sense used in less(1) and vi*(1)) is basically a named variable containing a location value; a search pattern match is a pair of locations, of the first and and last matching character.

Implementation

Issues in the current implementation.

Regex

We have a problem with C++ regex support. I'm currently compiling this on a Mint Rebecca (17.1) system, which by default uses GCC 4.8.2, in which the libc regex implementation is broken (partial implementation, as per its documentation apparently). This means I have to fall back to something else. For file format detection and scanning item headers, I decided to fall back to old C regex, which unfortunately requires null-byte terminated strings, meaning I cannot use memmap'ed input files, and other restrictions. For the log search feature I'm falling back to plain string matching in the initial version.

Growing file

Tracking a growing file has some issues:

• The last entry in a file may be incomplete, so we need to re-scan it when the file grows. This may, in turn, invalidate any cached information about it, or require changing the partial list of interleaved items already computed.
• Navigation in terms of percentages becomes strange if the underlying size changes. If we use the original size as the basis, percentage values can become very big if the original file was small, or even empty.
• If the growing file is the only one in its unit, it may not be possible to determine the format at the start, especially if it is empty.

We have similar issues if logrotate(1) decides to rename or compress files while we are viewing them.