tools: allow explicitly opting in to low-fi status display #9341
Conversation
I think this was originally designed for Emacs shell but at some point Emacs or Node improved so that Node finds columns for Emacs shell and switches to the full display. Switching to the status-only display leads to massive speedups when doing builds in my Emacs shell.
|
Hmm. @abernix suggested trying METEOR_HEADLESS and it seems to work about as well. That said, I do think that ProgressDisplayStatus is effectively dead code, which isn't great. |
|
Thank you for looking at this! Another hack week success story! We currently have I'd like to make this process better, in general but especially for Emacs usage, right now, without the need to opt in. While I had previously thought that Would you be able to check how performance is if you:
? Depending on the outcome, perhaps we can replace the manual |
|
I don't think Meteor looks at |
|
Apparently INSIDE_EMACS was introduced as a replacement for EMACS in Emacs 22 in 2007, and EMACS was dropped in Emacs 25 in 2016. |
This adds a memoized helper function for detecting Emacs throughout the CLI tool and automatically resorts to "ProgressDisplayStatus" mode when Emacs is enabled. In my tests with both Emacs 22 and 27, this nearly doubled performance when using Meteor from within the Emacs shell (i.e. `M-x shell`).
To avoid any unintended inheritance of non-"own" properties.
| @@ -71,7 +71,6 @@ build_machine_environment: &build_machine_environment | |||
|
|
|||
| # These, mostly overlapping, flags ensure that CircleCI is as pretty as | |||
| # possible for a non-interactive environment. See also: --headless. | |||
| EMACS: t | |||
There was a problem hiding this comment.
With METEOR_HEADLESS enabled, we're not really gaining anything by using this setting in CircleCI.
| // clearLine() and cursorTo(...). | ||
| // It's important that we only enter status message mode | ||
| // if this._pretty, so that we don't start displaying | ||
| // status messages too soon. |
There was a problem hiding this comment.
I removed this as it seemed a bit verbose, but in hindsight, I guess this comment was referring to the importance of this being later on in the conditional chain (after the else if on 1180). Happy to add it back if its removal detracts from the readability.
There was a problem hiding this comment.
I'm okay with leaving it out! 👍
abernix
requested review from
benjamn and
hwillson
and removed request for
benjamn
| @@ -16,6 +16,7 @@ var catalog = require('../packaging/catalog/catalog.js'); | |||
| var buildmessage = require('../utils/buildmessage.js'); | |||
| var httpHelpers = require('../utils/http-helpers.js'); | |||
| const archinfo = require('../utils/archinfo.js'); | |||
| import { isEmacs } from "../utils/utils.js"; | |||
There was a problem hiding this comment.
We better add a isVi function in utils.js just to be safe ... 🔥😱
There was a problem hiding this comment.
For the record, the speed is almost/exactly as fast as a native terminal session when running vi/vim split-screen with a terminal in tmux or screen. 😉
| // clearLine() and cursorTo(...). | ||
| // It's important that we only enter status message mode | ||
| // if this._pretty, so that we don't start displaying | ||
| // status messages too soon. |
There was a problem hiding this comment.
I'm okay with leaving it out! 👍
To fix my typo from the previous commit.
I think this was originally designed for Emacs shell but at some point Emacs or
Node improved so that Node finds columns for Emacs shell and switches to the
full display.
Switching to the status-only display leads to massive speedups when doing builds
in my Emacs shell.