I would like to see something like a $edit:cmd-duration variable introduced. This should not be in the builtin namespace because we don't want, or need, to measure the elapsed duration of every statement by default. This is an interactive REPL feature primarily meant to be used in the interactive prompts or related command hooks.

Also, note that the solution used by https://github.com/zzamboni/elvish-modules/blob/master/long-running-notifications.elv has a resolution of seconds. The proposed $edit:cmd-duration variable should have millisecond, or better, resolution. And the @zzamboni implementation requires running the external date command. Which shouldn't be necessary. But that's a separate issue.

I'd rather we introduce an after-cmd hook and supply this information as part of the hook, which localizes the information instead of making it a global variable.

Before #1030 is resolved, I am open to an experimental API that exposes this information as a global, perhaps named edit:-last-cmd-duration-sec.

An after-cmd hook might be a good idea but creates some questions. In particular, it would be an expensive mechanism to solely capture the execution duration of the most recent interactive command.

I agree that assigning a float64 of the elapsed fractional seconds to a edit:-cmd-duration-sec var (I don't see the point of including last- in that var name) is better than a nominal integer scaled by milliseconds or microseconds.

FWIW, On my primary macOS server using the @zzamboni approach, but using date '%s.%N' for nanosecond resolution, consistently results in a command duration of 6 to 8 ms when simply pressing [enter]; i.e., not running any command at all. Which shows that using the existing hooks is unexpectedly expensive.

I agree that it might be better for precision that the shell itself measures and exposes how much a command took. Display/reporting can then of course be done by hooks.

Though honestly, I don't think this is a must - I can't really think of a good use case (other than the kind of thing long-running-notifications does) for having this measurements. So I would consider it as a low priority.

Finally, a question based on the discussion above: isn't the existing before-readline hook effectively the same as the proposed after-cmd hook? What am I missing?

isn't the existing before-readline hook effectively the same as the proposed after-cmd hook?

No, since the after-cmd hook would only fire when a command was actually run. Simply displaying a new prompt, such as from pressing [enter] on an empty command line, wouldn't trigger it. Also, it wouldn't be tied to interactive prompts, making it usable from a script. Which means that a after-cmd hook would eliminate the need for the time command.

What arguments would be passed to a after-cmd hook? Obviously the statement that was run and the elapsed time in seconds. A third argument could be a list of exceptions thrown by the statement or an empty list if there were no exceptions. A fourth argument could be the getrusage data for any external commands. A fifth argument could be the getrusage delta for the shell itself.

I started working on a resolution for this issue and realized that simply pressing Enter should not affect the recorded duration of the most recent command since no command was executed. Also, introducing an after-cmd hook might be useful but is not needed to resolve this issue and needlessly complicates capturing the duration of an interactive statement. The resolution I'm working on introduces a edit:command:duration float64 variable.

I'd rather we introduce an after-cmd hook and supply this information as part of the hook, which localizes the information instead of making it a global variable.

I've been using a change that introduces the $edit:command:-duration variable for a few days. Along with a related change to my ~/.elvish/rc.elv that displays that var in my right prompt. I'm pretty happy with the behavior. Especially that it captures the cost to source ~/.elvish/rc.elv before the first prompt is rendered. Which, on my primary server, is on the order of 400 ms. It also ignores any code block that consists entirely of whitespace. This means that simply pressing Enter does not modify the value of that variable (assuming only whitespace characters were entered before pressing Enter).

I am also working on a change to introduce a edit:after-command hook. It is still unclear if the value of that hook justifies the cost(s) but it does open other possibilities such as capturing any error from executing a code block.