Struct View 

pub struct View { /* private fields */ }

The live view.

Implementations

impl View

pub fn new(tree: Tree) -> Self

A view of a scan that has not found anything yet.

pub fn showing_files(self) -> Self

Opens the view with gitignored files on screen, as --ignored-files asks for.

The walk claims them either way — see [super::spawn_walk] — so this decides only where the lens starts. It exists because a flag that reads “claim gitignored files” and then does nothing a reader can see is a flag that has lied about itself: the two front ends have to mean the same thing by it, and in the tree “show me these” is what it means.

pub fn found(&mut self, hit: Hit)

A claim the walk has just found.

pub fn pricing(&mut self, path: &Path)

A pricing thread has gone into this claim.

What the shimmer draws, and the reason it is worth drawing: the pool is bounded, so the rows lit at any instant are exactly the ones being worked on. A dash that is being measured right now and a dash that will be measured in four minutes are different facts about a row, and before this event the front end had no way to tell them apart.

pub fn priced(&mut self, path: &Path, size: Size)

A price for a claim that was published without one.

pub fn freeing(&mut self, path: &Path, bytes: u64)

Bytes the deleter has just given back from a target it is still working through.

This is what makes a row empty rather than merely disappear, and the reason it is an event rather than a timer: the number falling is the number of bytes that have actually left the disk. A fixed animation started after the fact would look the same for a target that took ten seconds and one that took ten milliseconds, which is the definition of motion that is not information.

pub fn removed(&mut self, path: &Path, bytes: u64, complete: bool)

A target the deleter has finished with.

Only a complete removal takes the row away. A target the sweep entered and did not finish — a checkout inside it, an unreadable subtree — is still on disk, and dropping its row would tell a reader something was deleted that was not.

A complete one does not take it away on this frame either. Its number is already at zero, having got there on the bytes reported by View::freeing; what it spends now is super::moving::DIM dimmed, so the row is seen to have emptied instead of vanishing on the same frame as its last byte. That beat is presentational and its consequences are not: the row is out of the batch and out of the marks from the moment the sweep first touched it.

pub fn swept(&mut self, path: &Path)

The deleter has moved off a target, whatever it managed to do to it.

This and View::removed answer different questions, which is why the progress counts here and the rows move there. A target that failed before unlinking a single entry, or that had already vanished, is one the deleter is no longer working on — it belongs to where the batch has got to, and to nothing else. Counting the position on removals instead would leave a batch that failed on every target reading 0% for its whole life and then vanishing, which reports the outcome under the guise of the position; and even one such target leaves the bar permanently short of where the deleter actually is.

It deliberately does not touch the tree. Nothing happened to that directory, so there is nothing for its row to say.

pub fn refused(&mut self, kept: &[Refused])

Directories a removal left standing, with the reason each one was left.

pub fn scanned(&mut self)

The walk is over.

pub fn repriced(&mut self, claims: &[PathBuf], notice: Notice)

A pricing pass is over, and these are the claims it was holding.

The prices themselves arrived one at a time through View::priced, exactly as the walk’s do; this hands the claims back, which is what lets the next double click on them mean something again. It is called on every way a pass can end, the worker dying included — an in-flight set that leaked would be a subtree the reader can never ask about again for the rest of the run, which is a quiet permanent no-op on a gesture they keep making.

pub fn deleted(&mut self, notice: Notice, freed: u64)

The removal is over, notice is what it did, and freed is what the session has given back across every batch it has run.

The two are the same event told from two ends and they hand over here, which is why they are set in one call. While the batch runs the rows and the counter carry it — bytes falling as they leave the disk, a position against the batch’s own size — and none of that survives the last target. notice is what is left saying anything at all, so it is the only place the counts a live row cannot show land: what the safety model refused, and what failed. How long it stays is picked from those same counts, by summarise. See Notice.

The freed figure is set rather than added to, and it is the batch report’s own arithmetic rather than a second tally kept here: the per-target totals the counter has been climbing on and crate::delete::Removal::bytes_freed are the same bytes counted by the same code, so keeping both would count each one twice. The running figures are dropped in the same breath that this one lands, which is why the counter hands over without so much as a flicker.

A target the sweep could not finish has to be reconciled into the tree first. Its row is staying — the directory is still on disk — and what it is worth is what survived, which until this point has only ever been said by the deleter’s progress. Progress is the thing being dropped here, so the reduction is made durable before it goes: a claim whose bytes went but whose row remains springs straight back to its original size otherwise, and the headline reclaimable figure rises after a partial delete while freed says those same bytes are gone. A complete removal needs none of this, because its claim leaves the tree outright when its dimmed beat is over.

pub fn ask(&mut self, plan: &Plan)

Opens the confirmation on a resolved plan.

The listing is built here rather than by the planner, because half of what a line says is a fact about the view — what kind of artefact this is, and whether the reader can currently see it — and the planner knows only paths and the safety model’s answers. The two halves meet exactly once, here.

An empty plan is not a question. It happens for a real reason — every marked directory was refused by the safety model — so it says so rather than putting up a box with nothing in it.

pub fn asking(&mut self, targets: &[Planned], kept: &[Refused])

The same question from the two lists a Plan is.

Taken apart because a plan can only be built against a real filesystem, and the rule this screen has to keep — that the batch is stated whole, hidden entries and refusals included — is a rule about the view rather than about the disk.

pub fn sync(&mut self)

Brings the rows back in line with the tree, if anything has changed under them.

Idempotent and cheap when nothing moved, so both the renderer and every keystroke can call it without either having to know whether the other did.

pub fn animate(&mut self, now: Instant)

Moves the frame on to now: the one place time enters this file.

Three things, in an order that matters. A drain that has run its course takes its row out of the tree first, so the rows this frame draws are the rows that exist. Then the view is brought back in line. Then every drawn row’s number is advanced toward what it is really worth — drawn rows, which is what keeps this O(the pane) rather than O(the tree), and the whole reason interpolation is affordable on a view holding 22,765 directories.

pub fn is_moving(&self) -> bool

Whether anything on screen is still in motion, which is what the event loop reads to decide how often to repaint.

pub fn allow_maps(&mut self, possible: Maps)

Whether this terminal can draw a map, and if not, why. Told every frame.

Not once at start-up, which is what #656 was: half the answer is the pixel size in the window, and a window can gain or lose that without the terminal changing — a tmux client attaching, a pane moving to a display the terminal measures differently. So the layout reads a fact that is re-taken as often as it is used.

Which makes the early return load-bearing rather than tidy: this runs ten times a second, and marking the view stale each time would re-fold every stamp in the tree to learn that nothing had changed.

pub fn maps(&self) -> bool

Whether the map pane is on the screen.

pub fn viewport(&mut self, page: usize)

How many rows the tree pane can draw. Set by the renderer, used by the page keys.

pub fn rows(&self) -> &[Row]

The visible rows, outermost first.

pub fn cursor(&self) -> Option<usize>

Which row the cursor is on, if any.

pub fn scroll(&self) -> usize

The first row drawn.

pub fn tree(&self) -> &Tree

The tree behind the rows, for the renderer to read names and hits off.

pub fn is_expanded(&self, id: NodeId) -> bool

Whether this row is open.

pub fn roll(&self, id: NodeId) -> Roll

What this row’s subtree is worth — under the current view, which is the only number a row is allowed to state.

pub fn drawn(&self, id: NodeId) -> Roll

What this row is drawing at this instant, which is the truth once it has caught up.

A rolled-up total climbing toward its real value is the one thing a count of directories cannot say: how fast the scan is finding them. It is also the same mechanism, running the other way, that empties a row the deleter has just finished with. Only the bytes move — the claim counts do not, because a count is a thing a reader reads off rather than watches.

pub fn drawn_total(&self) -> Roll

The header’s number, climbing.

pub fn drawn_freed(&self) -> u64

What this session has given back, climbing — the other of the two counters a removal moves, and the one that goes up.

pub fn has_freed(&self) -> bool

Whether anything has been freed this session at all.

True as soon as the first bytes leave rather than when the batch reports, so the counter that climbs is on screen for the whole of the fall it is the counterpart to.

pub fn freshness(&self, id: NodeId) -> f64

How lit a newly found row is, from 1.0 down to 0.0 over about a second.

pub fn is_pricing(&self, id: NodeId) -> bool

Whether a pricing thread is inside this claim at this instant.

pub fn is_freeing(&self, id: NodeId) -> bool

Whether bytes are leaving this row right now.

pub fn is_spent(&self, id: NodeId) -> bool

Whether this row has emptied and is spending its last moment on screen.

pub fn is_cascading(&self, id: NodeId) -> bool

Whether the mark cascade is passing through this row right now.

pub fn shimmer(&self, width: usize) -> usize

Which cell of a width-wide pricing shimmer is lit this frame.

pub fn kept_reason(&self, id: NodeId) -> Option<&str>

Why a removal left this directory standing, if it did.

pub fn mark_of(&self, id: NodeId) -> Mark

How much of this row’s subtree is marked, as the current view shows it.

Filter-relative, and that is a correctness property rather than a nicety. A directory can be entirely marked under dependencies and only partly marked under all, so a glyph computed against the whole tree would contradict the rows the reader can see directly underneath it. What the box says is a statement about this screen.

A row with nothing visible under it is Mark::None rather than Mark::All: an empty set is not something to draw as fully marked, and the row is not on screen anyway.

pub fn map_stamp(&self, id: NodeId) -> u64

What the map of id is drawn from, as one number.

Everything super::treemap reads under id and nothing else, so it changes when the picture would and does not when it would not. The distinction that matters is against Tree::stamp, which the tree keeps for free but which is lens-blind: a run opens on default, which hides the gitignored tier, so a tier-two claim arriving under the mapped directory moves the tree’s stamp while changing no rectangle at all. Answering that with a redraw is a megabyte down the pty to show the picture that was already there.

So it is folded on the one pass that is already lens-aware — [tally], which computes what every row is worth under the current view — rather than maintained beside it. An incremental version would have to be right about every arrival, every price and every deletion, which is the same argument this file already makes about the counts themselves.

Falls back to the tree’s stamp when there is no map, which over-reports rather than under-reports: [tally] does not fold what nobody is going to ask for, and a view that was never told a map is possible is a view with no pane to spend the redraw on.

pub fn mark_stamp(&self) -> u64

How many times the selection has changed since the view opened — the marks or the exclusions, either way round.

For a reader of the view that has to answer “is this the same picture as last frame” without rebuilding the picture — super::treemap, whose rectangles change colour on a mark. Nothing else says so: a mark moves no bytes and no claims, so the tree’s own Tree::stamp is silent about it.

A count and not a hash of what is marked, because the two states such a hash would most easily call equal — unmarking one directory and marking its equally sized neighbour — are the ones a reader is most likely to produce. It counts keystrokes rather than differences, so it can say a selection changed when it did not: that costs one redraw on a key the reader pressed, where the other way round is a picture that disagrees with the tree beside it.

pub fn share(&self, id: NodeId) -> f64

What share of this row’s subtree is marked, between 0.0 and 1.0.

By bytes, which is what a reader deciding whether a partial ancestor is worth opening actually wants: forty marked directories out of fifty means nothing if the other ten hold all the space. Claims are the fallback for a subtree nobody has priced yet, where bytes cannot answer and the count is the only thing that is true.

pub fn marked(&self) -> Roll

What is marked, all together — the selection counter.

The whole selection, not the visible part of it. Deleting acts on everything that is marked, so a counter stating only what is on screen would be the one number a reader checks disagreeing with the one thing the tool then does. What the view being narrowed changes is View::hidden beside it, which says how much of this the reader cannot currently see.

Net of the rows the deleter has already finished with, which are in the tree for another third of a second while they empty. They are out of View::batch, so they have to be out of the number that describes it.

pub fn hidden(&self) -> usize

How many marked directories the current view is hiding.

Zero on a view that hides nothing, which is where a run starts. Above zero it is the hazard orthogonal selection creates, stated on the footer before the reader ever reaches the confirmation that spells it out.

pub fn total(&self) -> Roll

The whole scan, as the header states it — under the current view.

pub fn out_of_view(&self) -> usize

How many claims the scan found that the current view is not showing.

The header says this, and that is what keeps a narrowed view honest. The run opens on default, which hides the gitignored tier — a real tier worth real bytes that no other tool finds at all — so the headline count is not the whole answer to “how much do I get back”. A number that is narrowed without saying so is the “silently keeps” failure the age floor was resolved against; saying so, on the line the number is on, is the difference between a filter and a lie.

pub fn filter(&self) -> Option<&str>

The applied filter’s pattern, if there is one.

pub fn preset(&self) -> Option<Preset>

Which named view the view is on, or None once the axis keys have taken it off all four.

Derived from the axes rather than remembered, which the four presets occupying four distinct points is what buys: a reader who toggles their way onto dependencies is on dependencies, and nothing has to keep a record of how they got there.

pub fn view_label(&self) -> String

What the footer calls the view: a preset’s name, or the two axes spelled out.

A lens the axis keys built has no name, and inventing one — or rounding it to the nearest preset — would tell the reader they are somewhere they are not.

pub fn lens(&self) -> &Lens

The whole of what decides visibility, for anything that has to say what is hiding something.

pub fn prompt(&self) -> Option<&Prompt>

The prompt, while it is up.

pub fn help(&self) -> Option<usize>

How far the help overlay is scrolled, while it is up.

pub fn clamp_help(&mut self, furthest: usize)

Holds the help overlay’s scroll inside the page that was actually drawn.

The renderer’s job because it is the only thing that knows how long the page is and how much of it fits, which is why G here means “as far as it goes” rather than a number: a view that guessed would scroll a help page off the top of its own box.

pub fn pending(&self) -> Option<&Pending>

The question waiting for an answer.

pub fn listing(&mut self, page: usize)

How many lines of the batch the confirmation has room for.

The renderer’s to say, exactly as View::viewport is, and for the same reason: the box’s height depends on the frame, and a page size the view guessed would scroll the listing past its own border.

pub fn is_scanning(&self) -> bool

Whether the walk is still running.

pub fn is_deleting(&self) -> bool

Whether a removal is in flight.

pub fn removing(&self) -> Option<&Removing>

Where the removal in flight has got to, if there is one.

pub fn notice(&self) -> Option<&str>

What just happened, for the footer.

pub fn notice_stands(&self) -> bool

Whether what the footer is saying waits to be dismissed rather than going with the reader’s next action.

Deliberately not something the frame draws differently: a sentence saying a subtree was left alone is the safety model working, and an alarm-coloured footer would teach a reader that correct behaviour is a failure. See Notice.

pub fn sort(&self) -> Sort

Which sort the levels are in.

pub fn overlay(&self) -> Option<Overlay>

Which surface has the keyboard.

Ranked rather than exclusive, because the globals can open a prompt or the help page over a question: the confirmation is bottom of the stack, not top.

pub fn apply(&mut self, action: Action) -> Effect

Carries out one action, and says what the event loop has to do about it.

pub fn wants_to_quit(&self) -> bool

Whether a quit that was held back by a removal can be honoured now.

pub fn batch(&self) -> Vec<Target>

Every claim the marks select, which is what a batch is.

The whole selection, and never only the visible part. A mark resolves through the lens it was made through, so narrowing the view afterwards takes nothing out of the batch — anything else would contradict the one promise the model makes, that toggling what is visible never changes what is selected. What the narrowing does instead is put entries on the confirmation marked as hidden, which is where a reader can act on the surprise.

A row that is draining away is out. It is on screen for another third of a second saying what happened to it, and offering a directory that is already gone to a second removal would report a failure for a target the first removal succeeded on. That is decided in [tally], with the counter, so the two cannot part company.

pub fn row(&self) -> Option<Row>

The row under the cursor.

Trait Implementations

impl Debug for View

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.