You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature Request] Ability to hide line in Highlight rules #338
changed the title [-][Feature Request] Ability to hide line in Highlight configuration[/-][+][Feature Request] Ability to hide line in Highlight rules[/+]on Mar 12, 2025
These features must use consistent line identities and navigation behavior. Implementing them together does not require one large PR, but their integration must be verified before release.
This brief defines hidden-line behavior for both related features.
Current behavior
The reporter confirmed that the request is to hide entire matching lines, rather than disable their highlighting.
HighlightEntry has styling and trigger options but no hide-line property. Inverted filtering provides a separate filtered view; it does not implement this request.
The main grid currently uses row indexes as log-line indexes in many operations. Hiding lines introduces a distinction between a visible row and its original logical line.
These findings are based on source inspection. Runtime and performance verification remain part of implementation.
Required behavior
Highlight settings
Add a per-entry “Hide line” checkbox.
Default it to false, including when reading existing configurations.
Preserve it through editing, cloning, save/load, and import/export.
A line is hidden when any matching entry in the active Highlight Group has this option enabled.
Use existing case-sensitivity and regex matching semantics.
A word-highlight rule with “Hide line” enabled hides the entire matching line.
A matching coloring rule cannot override another rule's hide decision.
Temporary search highlights do not become hide rules.
Display and recovery
Hide matching lines from the main log grid without removing them from the reader or modifying the file.
Keep displayed line numbers tied to the reader's original logical line numbers. Gaps are expected.
Show the hidden-line count and provide an obvious per-window “Show hidden lines” override.
The override bypasses hiding without modifying Highlight Entries.
Treat the override as transient window state; do not persist it for this initial implementation.
Handle all-lines-hidden and empty-file cases without invalid selections or exceptions.
Changing the active Highlight Group or its rules refreshes visibility.
Preserve the selected original line when it remains visible. Otherwise select the next visible line, falling back to the previous one; leave selection empty if none exists.
Line identity and navigation contract
Keep these concepts distinct:
Original logical line: A line index in the Logfile Reader, before highlight-based hiding. This is not necessarily a physical- file line number when preprocessing or combined-file mode is active.
Visible row: A row in the main grid after hiding is applied.
Maintain a shared mapping between them. Reader access, bookmarks, timestamps, source-file lookup, and persisted positions must continue to use original logical lines.
For explicit navigation to a hidden line:
Temporarily enable “Show hidden lines” for that Log Window.
Select and reveal the exact requested original logical line.
Clearly reflect the enabled override in the UI.
Do not remove or modify the matching hide rule.
Apply this policy to Go to Line, bookmark navigation, Log Search results, explicit timestamp navigation, time synchronization, and overview-marker navigation.
For #58, the CLI line number identifies the original logical line. Apply its navigation after loading, restoration, and visibility initialization. Retain #58's requirement to disable follow-tail.
Ordinary scrolling and tail-follow updates must not enable the override. Follow-tail should follow the last visible line.
Visibility changes must not corrupt marker positions or change bookmark/search/filter line identities.
Filtering, triggers, and selection
Initially, apply hiding only to the main grid of each Log Window.
Keep the secondary filter-result grid governed by its existing Window Filter.
Hidden source lines remain eligible for search and filtering.
A Filter Pipe Log Window applies its own active Highlight Group to its own logical lines.
Preserve existing tail-trigger behavior on hidden lines, including audio, plugins, bookmarks, stop-tail, and LED behavior.
Visibility scans and rebuilds must never invoke those triggers.
Copying or exporting a selection of visible rows includes only the selected visible rows.
Preserve existing source-oriented and filter-result export semantics.
Map selection, bookmark operations, columnizer callbacks, and source-file actions to the correct original lines.
Relevant implementation points
Locate these types and methods in the current codebase before editing:
HighlightEntry and HighlightEntry.Clone
Add and preserve the hide flag with a backward-compatible false default.
HighlightEntryDialog, Highlight Group editing, and localization resources
Expose the option and ensure edits invalidate visibility in affected Log Windows.
HighlightEvaluator
Reuse existing matching semantics for hide decisions. Keep evaluation free of trigger side effects.
LogWindow main-grid data retrieval and painting
Translate visible rows to original lines before reader access, prefetching, columnizer callbacks, and painting.
LogWindow.SelectLine, GotoLine, and navigation callers
Accept original logical line identities and resolve them through the shared visibility/navigation policy.
Selection, clipboard/export, bookmark, timestamp, and source-file lookup paths
Audit direct uses of main-grid row indexes as reader line indexes.
The existing filter-view _filterResultList mapping
Use it as a reference for the row/line distinction. Do not repurpose the Window Filter or overwrite its results to implement hiding.
Load completion, Tail Follow Sink callbacks, reload, and rollover handling
Initialize, update, or rebuild visibility while preserving correct line identities.
Session Snapshot capture/restoration and SessionFileComposer integration
Persist original logical positions rather than transient visible-row indexes.
Keep visibility evaluation and row/line mapping testable independently of WinForms. Centralize the mapping rather than spreading independent conversion logic throughout event handlers.
Performance and lifecycle requirements
Do not evaluate hide rules in paint handlers or scan entire files on the UI thread.
Use cancellable background work with stable rule snapshots.
Tag results with the applicable file/load generation and rule revision; discard stale results.
Evaluate newly appended lines incrementally.
Rebuild or shift visibility correctly after rollover, truncation, and reload.
Publish visibility changes coherently so the grid never observes mismatched row counts and mappings.
Preserve the reader's existing memory-lifetime and prefetch guarantees.
Cancel work and release subscriptions when the Log Window closes.
Handle regex failures without publishing a misleading partial visibility state.
Avoid allocating a heavyweight UI object per source line.
Acceptance criteria
The hide flag defaults to false and survives editing, cloning, serialization, and import/export.
Any matching hide rule removes the entire line from the main grid.
Rule order does not allow ordinary coloring rules to cancel hiding.
Original logical line numbers remain stable and are displayed correctly.
Hidden-line counts and the per-window visibility override behave correctly.
Empty files and all-lines-hidden results have valid empty-selection behavior.
Selection is preserved or relocated according to the defined policy after rule changes.
Search, bookmarks, timestamps, source-file lookup, and columnizer callbacks address the correct original lines.
Explicit navigation to a hidden line reveals and selects that exact line.
Performance measurements record scan duration, memory overhead, and UI responsiveness for representative large logs.
Scope boundaries and caveats
Hiding is reversible display state. It does not delete file contents, drop lines from the reader, or alter Columnizer preprocessing.
This issue does not add ordered “show again” rules, physical-file line mapping, or suppression of triggers on hidden lines.
The checkbox is a small change, but the current main grid assumes row indexes and logical line indexes are interchangeable. Auditing and correcting that assumption is the main implementation risk: missed conversions can act on the wrong line.
Estimated difficulty: Substantial. Rough estimate: 2–4 developer weeks for the visibility layer, affected-path integration, regression tests, and Windows UI/performance verification. Coordinate estimates with #58 and #27 to avoid counting shared work twice.
Decisions made while implementing this in #718. They refine the brief:
Time synchronization: only the window the sync starts from reveals a hidden target line. Windows following the sync select the nearest visible line and don't turn on "Show hidden lines".
Stop Tail: the trigger still fires on a hidden line, but the selection moves to the nearest visible line instead of revealing it, since tail updates must not turn on "Show hidden lines".
Matching: hide rules match the whole line with the existing case-sensitivity and regex semantics, the same as tail triggers. For word-mode rules the painting only highlights matches inside columns, so a match spanning a column boundary hides the line without being painted.
Load: the grid shows no rows until the first visibility scan finishes, so hidden lines never flash up. Explicit navigation during that time (Go to Line, bookmark window, marker clicks, the -line target) is queued and applied once the scan finishes.
Queued navigation during the first scan: a newer request from the user (Go to Line, bookmark window, …) replaces a queued one, including the -line target. A time sync arriving from another window never replaces the user's own queued navigation.
Activity
[-][Feature Request] Ability to hide line in Highlight configuration[/-][+][Feature Request] Ability to hide line in Highlight rules[/+]Hirogen commentedon Mar 12, 2025
is this hide for the highlight or for the line if it matches?
msmilkshake commentedon Mar 12, 2025
Hirogen commentedon Sep 7, 2026
Implementation brief
Category: Enhancement
Summary: Add a “Hide line” option to Highlight Entries that reversibly removes matching lines from the main log view.
Release coordination
Coordinate this work with:
These features must use consistent line identities and navigation behavior. Implementing them together does not require one large PR, but their integration must be verified before release.
This brief defines hidden-line behavior for both related features.
Current behavior
The reporter confirmed that the request is to hide entire matching lines, rather than disable their highlighting.
HighlightEntryhas styling and trigger options but no hide-line property. Inverted filtering provides a separate filtered view; it does not implement this request.The main grid currently uses row indexes as log-line indexes in many operations. Hiding lines introduces a distinction between a visible row and its original logical line.
These findings are based on source inspection. Runtime and performance verification remain part of implementation.
Required behavior
Highlight settings
Display and recovery
Line identity and navigation contract
Keep these concepts distinct:
Maintain a shared mapping between them. Reader access, bookmarks, timestamps, source-file lookup, and persisted positions must continue to use original logical lines.
For explicit navigation to a hidden line:
Apply this policy to Go to Line, bookmark navigation, Log Search results, explicit timestamp navigation, time synchronization, and overview-marker navigation.
For #58, the CLI line number identifies the original logical line. Apply its navigation after loading, restoration, and visibility initialization. Retain #58's requirement to disable follow-tail.
Ordinary scrolling and tail-follow updates must not enable the override. Follow-tail should follow the last visible line.
Integration with overview markers (#27)
Filtering, triggers, and selection
Relevant implementation points
Locate these types and methods in the current codebase before editing:
HighlightEntryandHighlightEntry.CloneAdd and preserve the hide flag with a backward-compatible false default.
HighlightEntryDialog, Highlight Group editing, and localization resourcesExpose the option and ensure edits invalidate visibility in affected Log Windows.
HighlightEvaluatorReuse existing matching semantics for hide decisions. Keep evaluation free of trigger side effects.
LogWindowmain-grid data retrieval and paintingTranslate visible rows to original lines before reader access, prefetching, columnizer callbacks, and painting.
LogWindow.SelectLine,GotoLine, and navigation callersAccept original logical line identities and resolve them through the shared visibility/navigation policy.
Selection, clipboard/export, bookmark, timestamp, and source-file lookup paths
Audit direct uses of main-grid row indexes as reader line indexes.
The existing filter-view
_filterResultListmappingUse it as a reference for the row/line distinction. Do not repurpose the Window Filter or overwrite its results to implement hiding.
Load completion, Tail Follow Sink callbacks, reload, and rollover handling
Initialize, update, or rebuild visibility while preserving correct line identities.
Session Snapshot capture/restoration and
SessionFileComposerintegrationPersist original logical positions rather than transient visible-row indexes.
Keep visibility evaluation and row/line mapping testable independently of WinForms. Centralize the mapping rather than spreading independent conversion logic throughout event handlers.
Performance and lifecycle requirements
Acceptance criteria
Scope boundaries and caveats
Hiding is reversible display state. It does not delete file contents, drop lines from the reader, or alter Columnizer preprocessing.
This issue does not add ordered “show again” rules, physical-file line mapping, or suppression of triggers on hidden lines.
The checkbox is a small change, but the current main grid assumes row indexes and logical line indexes are interchangeable. Auditing and correcting that assumption is the main implementation risk: missed conversions can act on the wrong line.
Estimated difficulty: Substantial. Rough estimate: 2–4 developer weeks for the visibility layer, affected-path integration, regression tests, and Windows UI/performance verification. Coordinate estimates with #58 and #27 to avoid counting shared work twice.
Hirogen commentedon Sep 26, 2026
Center the hidden-line count beside the Show hidden lines check box (#…
Address review of hide-line PR (#338)
Hirogen commentedon Sep 27, 2026
Decisions made while implementing this in #718. They refine the brief:
-linetarget) is queued and applied once the scan finishes.Extract hide-line grid logic out of the LogWindow partial (#338)
Address second review of hide-line PR (#338)
Address third review of hide-line PR (#338)
Address fourth review of hide-line PR (#338)
Hirogen commentedon Sep 27, 2026
Two more decisions from the review of #718:
-linetarget. A time sync arriving from another window never replaces the user's own queued navigation.-linetarget, asReload()already did before [Feature Request] Ability to hide line in Highlight rules #338.Tidy hide-line navigation queue after fifth review (#338)
Add hide-line flag and Core line visibility map/tracker (LogExperts#338)
Hide matching lines in the Log Window main grid (LogExperts#338)
Never read lines under the visibility tracker lock (LogExperts#338)
Show no rows until the first hide scan; time-sync followers stay hidd…