f7b0f7444a
### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/1032-elevation-qol/doc/specs/%235000%20-%20Process%20Model%202.0/%231032%20-%20Elevation%20Quality%20of%20Life%20Improvements.md) ⇐ ## Summary of the Pull Request Despite my best efforts to mix elevation levels in a single Terminal window, it seems that there's no way to do that safely. With the dream of mixed elevation dead, this spec outlines a number of quality-of-life improvements we can make to the Terminal today. These should make using the terminal in elevated scenarios better, since we can't have M/E. ### Abstract > For a long time, we've been researching adding support to the Windows Terminal > for running both unelevated and elevated (admin) tabs side-by-side, in the same > window. However, after much research, we've determined that there isn't a safe > way to do this without opening the Terminal up as a potential > escalation-of-privilege vector. > > Instead, we'll be adding a number of features to the Terminal to improve the > user experience of working in elevated scenarios. These improvements include: > > * A visible indicator that the Terminal window is elevated ([#1939]) > * Configuring the Terminal to always run elevated ([#632]) > * Configuring a specific profile to always open elevated ([#632]) > * Allowing new tabs, panes to be opened elevated directly from an unelevated > window > * Dynamic profile appearance that changes depending on if the Terminal is > elevated or not. ([#1939], [#8311]) ## PR Checklist * [x] Specs: #1032, #632 * [x] References: #5000, #4472, #2227, #7240, #8135, #8311 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_ ### Why are these two separate documents? I felt that the spec that is currently in review in #7240 and this doc should remain separate, yet closely related documents. #7240 is more about showing how this large set of problems discussed in #5000 can all be solved technically, and how those solutions can be used together. It establishes that none of the proposed solutions for components of #5000 will preclude the possibility of other components being solved. What it does _not_ do however is drill too deeply on the user experience that will be built on top of those architectural changes. This doc on the other hand focuses more closely on a pair of scenarios, and establishes how those scenarios will work technically, and how they'll be exposed to the user.
73 lines
514 B
Plaintext
73 lines
514 B
Plaintext
apc
|
|
calt
|
|
ccmp
|
|
cybersecurity
|
|
Apc
|
|
clickable
|
|
clig
|
|
copyable
|
|
dalet
|
|
dcs
|
|
Dcs
|
|
dialytika
|
|
dje
|
|
downside
|
|
downsides
|
|
dze
|
|
dzhe
|
|
Enum'd
|
|
Fitt
|
|
formattings
|
|
ftp
|
|
fvar
|
|
geeksforgeeks
|
|
ghe
|
|
gje
|
|
hostname
|
|
hostnames
|
|
hyperlink
|
|
hyperlinking
|
|
hyperlinks
|
|
img
|
|
It'd
|
|
kje
|
|
liga
|
|
lje
|
|
locl
|
|
lorem
|
|
maxed
|
|
mkmk
|
|
mru
|
|
nje
|
|
ogonek
|
|
ok'd
|
|
overlined
|
|
postmodern
|
|
ptys
|
|
qof
|
|
qps
|
|
rclt
|
|
reimplementation
|
|
reserialization
|
|
reserialize
|
|
reserializes
|
|
rlig
|
|
runtimes
|
|
shcha
|
|
slnt
|
|
Sos
|
|
timestamped
|
|
TLDR
|
|
tokenizes
|
|
tonos
|
|
tshe
|
|
uiatextrange
|
|
UIs
|
|
und
|
|
unregister
|
|
versioned
|
|
We'd
|
|
wildcards
|
|
yeru
|
|
zhe
|