Follow-up to #24887
Follow-up to #31510
This PR ensures that [this misalignment of the horizontal
scrollbar](https://github.com/zed-industries/zed/pull/31510#issuecomment-2912842457)
does not occur. See the entire discussion in the first linked PR as to
why this gap is there in the first place.
I am also aware of the general stance towards comments. Yet, I felt for
this case it is better to just straight up explain how these two things
are connected, as I do believe this is not intuitively clear after all.
Might also be a good time to bring
https://github.com/zed-industries/zed/issues/25519 up again. The
horizontal scrollbar seems huge for the edit file tool card.
Furthermore, since we do not reserve space for the horizontal scrollbar
(yet), this will lead to the last line being not clickable.
Release Notes:
- N/A
Previously disabled both scrollbars, but horizontal scrolling is still
needed when
lines exceed the viewport width. Now editors can disable a single scroll
axis, not just both.
Release Notes:
- N/A
(Late) Follow-up to
https://github.com/zed-industries/zed/pull/26893#discussion_r2073427393
The mentioned issue of needed zero-division for scrollbars is now fixed
via #30189.
However, whilst the linked PR fixed the issue for the layouting of the
scrollbar thumb, I sadly did not address the (somewhat rare) case of
`document_lines == visible_editor_lines` within the calculation of the
minimap top offset.
This PR adds coverage for that case and ensures that the
`minimap_top_offset` never ends up being `NaN`.
Release Notes:
- N/A
Fixes#14612
This was a feature I dearly missed from VSCode, so adding this helped me
migrate to Zed without disrupting my workflow. I found that `4.0` was a
nice goldilocks multiplier and felt close/the same as the speed in
VSCode.
Release Notes:
- Added faster scrolling in the editor while holding opt/alt
A user on Discord reported an issue where the minimap thumb was fully
opaque:
<img
src="https://github.com/user-attachments/assets/5049c6a3-f89a-4ceb-9d1b-ec06e7fe9151"
height="300">
This can happen because the scrollbar and its thumb might not
neccessarily be transparent at all.
Thus, this PR adds the`minimap.thumb.background` and
`minimap.thumb.border` colors to themes so theme authors can specify
custom colors for both here.
Furthermore, I ensured that the minimap thumb background fallback value
can never be entirely opaque. The values were arbitrarily chosen to
avoid the issue from occuring whilst keeping currently working setups
working. With the new properties added, authors (and users) should be
able to avoid running into this issue altogether so I would argue for
this special casing to be fine. However, open to change it should a
different approach be preferrred.
Release Notes:
- Added `minimap.thumb.background` and `minimap.thumb.border` to themes
to customize the thumb color and background of the minimap.
- Fixed an issue where the minimap thumb could be opaque if the theme
did not specify a color for the thumb.
Follow up to https://github.com/zed-industries/zed/pull/30140 and
https://github.com/zed-industries/zed/pull/31236
This PR introduces an inline code action indicator that shows up at the
start of a buffer line when there's enough space. If space is tight, it
adjusts to lines above or below instead. It also adjusts when cursor is
near indicator.
The indicator won't appear if there's no space within about 8 rows in
either direction, and it also stays hidden for folded ranges. It also
won't show up in case there is not space in multi buffer excerpt. These
cases account for very little because practically all languages do have
indents.
https://github.com/user-attachments/assets/1363ee8a-3178-4665-89a7-c86c733f2885
This PR also sets the existing `toolbar.code_actions` setting to `false`
in favor of this.
Release Notes:
- Added code action indicator which shows up inline at the start of the
row. This can be disabled by setting `inline_code_actions` to `false`.
Don't hard wrap interactively; instead, soft wrap in `Bounded` mode
(editor width or 72 chars, whichever is smaller), and then hard wrap
before sending the commit message to git.
This also makes the soft wrap mode and width for commit messages
configurable in language settings.
Previously we didn't support soft wrap modes other than `EditorWidth` in
auto-height editors; I tried to add support for this by analogy with
code that was already there, and it seems to work pretty well.
Closes#27508
Release Notes:
- Fixed confusing wrapping behavior in commit message editors.
Follow-up to #30138
In the linked PR, I enabled the content offset for all editors by
default. However, this introduced a small regression: There are some
editors where we do not want the text to be offset, most notably the
rename and the filename editor.
This PR adds a method to disable the content offset for specific
editors. I specifically decided on an opt-out approach, since I think
that having the small offset for most editors is actually a benefit
instead of a disadvantage. However, open to change that or to disable
the offset for all editors but full mode editors by default if that
should be preferred.
| `main` | This PR |
| --- | --- |
|
|
|
Release Notes:
- N/A
Follow-up to #30316
This PR adds the `editor: toggle diagnostics` action to the comand
palette so that it can also be invoked that way.
I also ensures this, the `toggle inline diagnostics` and `toggle
minimap` actions are only registered if these are supported by the
current editor instance.
Release Notes:
- N/A
Closes#30756Closes#30729
Follow-up to #28064
The issue arose because GPUI does still propagate mouse events to all
event handlers during dragging actions even if the dragging action does
not belong to the current handler. I forgot about this in the other PR.
This resulted in an incorrect hover being registered for the thumb,
which was sufficient to trigger scrolling in the next frame, since
`dragging_scrollbar_axis` did not consider the actual thumb state (this
was generally sufficient, but not with this incorrectly registered
hover).
Theoretically, either of the both commits would suffice for fixing the
issue. However, I think it is better to fix both issues at hand instead
of just one. Now, we will only start the scroll on actual scrollbar
clicks and not show a hover on the thumb if any other drag is currently
going on.
https://github.com/user-attachments/assets/6634ffa0-78fc-428f-99b2-7bc23a320676
Release Notes:
- Fixed an issue where editor scrollbars would start scrolling when
hovering over the thumb whilst already dragging something else.
Open inspector with `dev: toggle inspector` from command palette or
`cmd-alt-i` on mac or `ctrl-alt-i` on linux.
https://github.com/user-attachments/assets/54c43034-d40b-414e-ba9b-190bed2e6d2f
* Picking of elements via the mouse, with scroll wheel to inspect
occluded elements.
* Temporary manipulation of the selected element.
* Layout info and JSON-based style manipulation for `Div`.
* Navigation to code that constructed the element.
Big thanks to @as-cii and @maxdeviant for sorting out how to implement
the core of an inspector.
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Federico Dionisi <code@fdionisi.me>
Closes#16993
This PR fixes an issue where the vertical editor scrollbar was
overlaying with buffer headers. I fixed this by reserving space for the
scrollbar as needed which is provided by the recently introduced
`right_margin`.
Most of the diff consists of moving the `EditorMargins` creation out of
`render_block`, as the right margin is stored in this struct and moving
this out reduces the length of the parameter list of `render_blocks` by
one. I thought of this to be a small but nice side effect.
When it comes to the dividers, I decided against these considering the
margin as well, since it felt a bit off. However, I can see arguments
for these also considering the margins. I did include an image for
comparison in the list below. Happy to change this should it be
preferred the other way around.
| `main` |
|
| --- | --- |
| PR |
|
| Fix with shortened divider |
|
Release Notes:
- Ensured that the vertical editor scrollbar no longer overlaps with
buffer headers.
Follow-up of #30285
This PR ensures the action added in the linked PR also works when the
user does not have the minimap enabled via settings. Currently, the
toggle only works when the user has already enabled the minimap in their
settings.
This happens because in
b4fbb9bc08/crates/editor/src/element.rs (L7160-L7164)
as well as
b4fbb9bc08/crates/editor/src/element.rs (L1542)
we check for the user configuration before reserving space for the
minimap as well as layouting it and because in
b4fbb9bc08/crates/editor/src/editor.rs (L16404)
with
b4fbb9bc08/crates/editor/src/editor_settings.rs (L132-L134)
we would not even create a minimap when the user disabled it via their
settings.
---
This PR fixes this by ensuring a minimap is created on the toggle issue
as well as lifting some of the restrictions. Since we are always only
returning a minimap in
b4fbb9bc08/crates/editor/src/editor.rs (L16443-L16445)
when `show_minimap` is set to `true`, we can assume in the rendering
code that if a minimap is present, it should be layouted and rendered no
matter if `ShowMinimap` is currently set to `Never`. We can do this
since `show_minimap` always reflects the current user configuration, see
b4fbb9bc08/crates/editor/src/editor.rs (L18163-L18164)
I also removed the minimap deletion/recreation on the toggling of
`show_minimap`, since this is not really needed - once we have stored a
minimap editor within the editor, `show_minimap` is sufficient to ensure
that it is only shown when the user requests it. Notice that we still
will never create a minimap unless neccesary.
Lastly, I updated the `supports_minimap` check to account for the fact
that the minimap is currently disabled entirely for multibuffers.
---
One thing I ~~did not tackle here~~ tackled in the second commit is that
due to `show_minimap` now being exposed to the user, it is possible to
enable the minimap for all full mode editors, e.g. the agent text thread
editor
<img width="592" alt="grafik"
src="https://github.com/user-attachments/assets/5f6c0e8b-45f9-44e8-9625-9d51c1480f98"
/>
which should most likely not be possible when the minimap is
programmatically disabled.
Release Notes:
- N/A
* Adds a `diagnostics_max_severity: null` editor settings that has
previous hardcoded default, `warning`
* Make inline diagnostics to inherit this setting by default (can be
overridden with its own max_severity setting)
* Allows to toggle diagnostics in the editor menu and via new action,
`editor::ToggleDiagnostics`
Closes https://github.com/zed-industries/zed/issues/4686
Release Notes:
- N/A *or* Added/Fixed/Improved ...
As discussed and explained in
https://github.com/zed-industries/zed/pull/26893#discussion_r2074102719
This PR fixes an issue where we would have zero-divisions during
scrollbar layouting for small files.
This happened due to the fact that for small files,
9c1b2afa49/crates/editor/src/element.rs (L8562-L8563)
would be `NaN`, since `(total_text_units - text_units_per_page).max(0.)`
would return `0.`, which we would divide by.
However, this was neccessary to be in place, as this prevented the
scroll thumb from being rendered for small files: Due to this being
`NaN`, the thumb origin would be `Pixels(NaN)`, which prevented the
rendering of the scrollbar thumb.
This PR fixes this behavior by accounting for this scenario and changing
the thumb bounds to be an `Option<Bounds<Pixels>>` instead. This
furthermore has the advantage that we have to compute the thumb only
once and storing it in the layout, which was previously not possible.
Most notably, this enables scrollbar markers to show for smaller files:
https://github.com/user-attachments/assets/9fa5d240-8795-4fae-9933-aed144df4f5e
Currently, no markers are shown due to the fact that `Pixels(NaN)` is
set as the origin point.
Also, I changed that the cursor style will only be changed on the
scrollbar hitbox when we will actually show a thumb. This way, for small
files (where viewport > content size) the cursor will not change when a
user hovers with their mouse over the scrollbars hitbox.
Theoretically, I could also include the change mentioned in
https://github.com/zed-industries/zed/pull/26893#discussion_r2076316956
here. Given the introduction of the minimap as well as #29316 and the
cursor style taken care of here, removing the guard would not change
anything and creates the possibility to soon introduce scrollbars for
auto height editors. Please let me know whether we want to have this in
this PR or whether I shall create a seperate one.
Release Notes:
- Enabled scrollbar marker rendering for small files.
Follow-up to #28064
This PR adds the `scrollbar_thumb_active_background` to themes and uses
it for the editor scrollbars to color these whilst they are being
dragged. This way, we provide the best customizabiliy for the scrollbars
and enable theme authors to add good contrasts between all the three
states `ScrollbarThumbState::Idle`, `ScrollbarThumbState::Hovered` and
ScrollbarThumbState::Dragging`.
It also adds this to the VsCode theme importer so any future imported
themes will have this set as well.
Whenever the property is not set, I decided it is best to fall back to
the normal `thumb_background` for the time being, as this way the
distinction and contrast between hovered and active state is better than
having the same color for hovering and dragging the scrollbar.
Example with active color set via `experimental.theme_overrides` in the
settings:
https://github.com/user-attachments/assets/9934e75b-6e0a-4a41-90ba-bfffb89865e7
Release Notes:
- Added the `scrollbar.thumb.active_background` color to themes. Theme
authors can use this property in combination with
`scrollbar.thumb.hover_background` to customize the color of the editor
scrollbar thumbs while these are hovered or being dragged.
## Overview
This PR adds the minimap feature to the Zed editor, closely following
the [design from Visual Studio
Code](https://code.visualstudio.com/docs/getstarted/userinterface#_minimap).
When configured, a second instance of the editor will appear to the left
of the scrollbar. This instance is not interactive and it has a slimmed
down set of annotations, but it is otherwise just a zoomed-out version
of the main editor instance. A thumb shows the line boundaries of the
main viewport, as well as the progress through the document. Clicking on
a section of code in the minimap will jump the editor to that code.
Dragging the thumb will act like the scrollbar, moving sequentially
through the document.
## New settings
This adds a `minimap` section to the editor settings with the following
keys:
### `show`
When to show the minimap in the editor.
This setting can take three values:
1. Show the minimap if the editor's scrollbar is visible: `"auto"`
2. Always show the minimap: `"always"`
3. Never show the minimap: `"never"` (default)
### `thumb`
When to show the minimap thumb.
This setting can take two values:
1. Show the minimap thumb if the mouse is over the minimap: `"hover"`
2. Always show the minimap thumb: `"always"` (default)
### `width`
The width of the minimap in pixels.
Default: `100`
### `font_size`
The font size of the minimap in pixels.
Default: `2`
## Providing feedback
In order to keep the PR focused on development updates, please use the
discussion thread for feature suggestions and usability feedback: #26894
## Features left to add
- [x] fix scrolling performance
- [x] user settings for enable/disable, width, text size, etc.
- [x] show overview of visible lines in minimap
- [x] clicking on minimap should navigate to the corresponding section
of code
- ~[ ] more prominent highlighting in the minimap editor~
- ~[ ] override scrollbar auto setting to always when minimap is set to
always show~
Release Notes:
- Added minimap for high-level overview and quick navigation of editor
contents.
---------
Co-authored-by: MrSubidubi <dev@bahn.sh>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
This PR changes the way a horizontal margin is added in editors. It
removes the possibility to set a custom `horizontal_padding` for an
editor and utilizes the default `gutter_dimension` instead.
This change is made to ensure that no issues with soft-wrapping occurs
for any editor that has a `horizontal_margin` set (see #26893 for more
context on the implications here`. Furthermore, it ensures that the text
actually renders properly when scrolling horizontally and is not
cut-off.
### Horizontal padding:
| `main` | This PR |
| --- | --- |
| 
| 
|
### Editor horizontally scrolled:
| `main` | This PR |
| --- | --- |
| 
| 
|
Notice the difference at the horizontal borders.
The margin added for the `edit_file_tool` was 4 pixels. The `descent`,
whilst not exactly, is roughly the same here and also scales with the
font size nicely. Furthermore, it seems that the
`gutter_dimensions.margin` should be present anyway, given the following
comment
0b00256f58/crates/editor/src/element.rs (L6887-L6889)
so ensuring this property is actually set and not 0 seems to be
reasonable given the circumstances.
Please note though that this will apply to all editors in the app.
Again, this seems like it should be the case anyway, just wanted to
mention this again.
Should the fix like this not be wanted, I can change this here so that
the `horizontal_margin` is better accounted for when soft-wrapping in an
editor. Feel free to let me know in this case.
Release Notes:
- N/A
This conflicts for space with breakpoints, and seems borderline in terms
of utility.
We could consider bringing it back in a way that is closer to the
cursor, or be content with our right-click menu discovery.
Release Notes:
- Remove the code actions indicator from the gutter. It is still
available from the right click menu, or with the keyboard shortcut.
This PR fixes an issue where scrollbar hitboxes were still inserted for
editors despite scrollbars being programmatically disabled via the
`show_scrollbars`field. This is basically the same fix as in #27467.
The thought process here is that the motivation for `show_scrollbars` is
not to just hide the scrollbars in the editor, but to fully disable
scrollbars for the associated editor. However, this is currently not the
case, as a functioning hitbox for each scrollbar is stil inserted. For
example, the behavior with the old assistant panel can be seen below:
https://github.com/user-attachments/assets/18af6338-dd28-4794-a6a6-5b9691b243f2
Whilst the scrollbar is not visible, there is still a scrollbar hitbox
inserted which triggers hover events and is fully functioning.
This PR fixes this by fully skipping the scrollbar layouting whenever
`show_scrollbars` is set to false, preventing the hitboxes from being
inserted.
https://github.com/user-attachments/assets/b6bb6dc7-902f-4383-bf03-506d0a57ec77
Release Notes:
- N/A
Nathan here: I also tacked on a bunch of UI refinement.
Release Notes:
- Introduced the ability to follow the agent around as it reads and
edits files.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This PR prevents any unnecessary lines from being rendered in the edit
file tool card in the case of small diffs.
I think this (hopefully) addresses the last remaining task from
https://github.com/zed-industries/zed/pull/29448.
| `main` | This PR |
| --- | --- |
| <img width="634" alt="main"
src="https://github.com/user-attachments/assets/7c06394e-957a-4d36-a484-5974687041e9"
/> | <img width="634" alt="PR"
src="https://github.com/user-attachments/assets/84206d5a-a93a-4a42-99ca-7cdebb0d91bb"
/> |
(The last empty line in the second image is an empty line present in the
file itself)
---
n the second commit I also preemtively disabled vertical overscrolling
for full mode editors which are sized by content. This is basically the
same fix as in https://github.com/zed-industries/zed/pull/28471.
Strictly speaking, this is not needed for the fix here, but I thought it
might be nice to have for the future to prevent any issues from occuring
due to overscroll.
Release Notes:
- agent: Improved rendering of small diffs for the edit file tool card.
Adjusts the way `cargo` and `rust-analyzer` diagnostics are fetched into
Zed.
Nothing is changed for defaults: in this mode, Zed does nothing but
reports file updates, which trigger rust-analyzers'
mechanisms:
* generating internal diagnostics, which it is able to produce on the
fly, without blocking cargo lock.
Unfortunately, there are not that many diagnostics in r-a, and some of
them have false-positives compared to rustc ones
* running `cargo check --workspace --all-targets` on each file save,
taking the cargo lock
For large projects like Zed, this might take a while, reducing the
ability to choose how to work with the project: e.g. it's impossible to
save multiple times without long diagnostics refreshes (may happen
automatically on e.g. focus loss), save the project and run it instantly
without waiting for cargo check to finish, etc.
In addition, it's relatively tricky to reconfigure r-a to run a
different command, with different arguments and maybe different env
vars: that would require a language server restart (and a large project
reindex) and fiddling with multiple JSON fields.
The new mode aims to separate out cargo diagnostics into its own loop so
that all Zed diagnostics features are supported still.
For that, an extra mode was introduced:
```jsonc
"rust": {
// When enabled, Zed runs `cargo check --message-format=json`-based commands and
// collect cargo diagnostics instead of rust-analyzer.
"fetch_cargo_diagnostics": false,
// A command override for fetching the cargo diagnostics.
// First argument is the command, followed by the arguments.
"diagnostics_fetch_command": [
"cargo",
"check",
"--quiet",
"--workspace",
"--message-format=json",
"--all-targets",
"--keep-going"
],
// Extra environment variables to pass to the diagnostics fetch command.
"env": {}
}
```
which calls to cargo, parses its output and mixes in with the existing
diagnostics:
https://github.com/user-attachments/assets/e986f955-b452-4995-8aac-3049683dd22c
Release Notes:
- Added a way to get diagnostics from cargo and rust-analyzer without
mutually locking each other
- Added `ctrl-r` binding to refresh diagnostics in the project
diagnostics editor context
⚠️ Work in progress until all of the to-dos are knocked out:
- [x] Disable soft-wrapping
- [x] Make it foldable only after a certain number of lines
- [x] Display tool status errors
- [x] Fix horizontal scroll now that we've disabled soft-wrap
- [ ] Don't render unnecessary extra lines (will be added later, on a
follow-up PR)
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Co-authored-by: Michael Sloan <mgsloan@gmail.com>
Since around the time we shipped block diagnostics, we've been seeing an
out of range panic in the editor.
Although the code is heavily inlined, so the stacktrace is missing, this
seems like a likely place that indexing may have gone wrong.
Release Notes:
- Fixed a rare panic in the editor
This PR adds the `FeatureFlag` suffix to the feature flag types that
were missing them.
This makes the names easier to search in the codebase.
Release Notes:
- N/A
WIP!
In light of having more control over blame popover from editor.
This fixes: https://github.com/zed-industries/zed/issues/28645,
https://github.com/zed-industries/zed/issues/26304
- [x] Initial rendering
- [x] Handle smart positioning (edge detection, etc)
- [x] Delayed hovering, release, etc
- [x] Test blame message selection
- [x] Fix tagged issues
Release Notes:
- Git inline blame popover now dismisses when the cursor is moved, the
editor is scrolled, or the command palette is opened.
This PR implements the `ToolCard` for the edit file tool, which allow us
to display an editor with a diff in the thread view with the changes
performed by the model.
- [x] Fix buffer sometimes displaying empty
- [x] Stop buffer from scrolling together with the thread
- [x] Fix multibuffer header sometimes appearing
- [x] Fix buffer height issue
- [x] Implement "full height" expand button
- [x] Add "Jump To File" functionality
- [x] Polish and refine styles
Release Notes:
- agent: Added diff preview cards in the thread view for edits performed
by the agent.
---------
Co-authored-by: João Marcos <marcospb19@hotmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
TODO:
- [x] Make it work in the project diff:
- [x] Support non-singleton buffers
- [x] Adjust excerpt boundaries to show full conflicts
- [x] Write tests for conflict-related events and state management
- [x] Prevent hunk buttons from appearing inside conflicts
- [x] Make sure it works over SSH, collab
- [x] Allow separate theming of markers
Bonus:
- [ ] Count of conflicts in toolbar
- [ ] Keyboard-driven navigation and resolution
- [ ] ~~Inlay hints to contextualize "ours"/"theirs"~~
Release Notes:
- Implemented initial support for resolving merge conflicts.
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Closes#21684Closes#28463Closes#28264
This PR fixes Zed hanging when scrolling over single line input fields
with `scroll_beyond_last_line` set to `vertical_scroll_margin`. The
change here is to fix the calculations of available lines.
The issue only arises with the setting present because with all
overscroll settings and `max_row` being 1 for single-line editors, the
calculation would still return the correct value of available lines,
which is 1. However, with overscrolling set to `vertical_scroll_margin`
and that set to any value greater than 0, the calculation would return
that the single-line editor has more than one line, which caused the
issues described above (Actually, setting `vertical_scroll_margin` to 1
works for some reason, overscrolls "properly" and does not cause a
crash. But I really did not want to investigate this buggy behavior
further).
This PR fixes this by always reporting the number of available lines as
the line number value for single line editors, which will (mostly) be 1
(for more context see the discussion in this PR).
Release Notes:
- Fixed an issue where Zed would crash when scrolling over single line
input fields and `scroll_beyond_last_line` set to
`vertical_scroll_margin`.
Closes#27188
This PR fixes the issue where, when you drag the scroll handle of the
editor and your mouse hovers over the gutter of the next editor,
scrolling stops. I found no good reason to stop propagation on gutter
hover.
Release Notes:
- Fixed an issue where editor scrolling would stop when the mouse
hovered over another editor's gutter.
Closes https://github.com/zed-industries/zed/issues/19731
Adds `editor::GoToPreviousChange` and `editor::GoToNextChange` that work
the same as `vim::ChangeListOlder` and `vim::ChangeListNewer` as the
common logic was extracted and reused.
Release Notes:
- Added a way to navigate between changes with
`editor::GoToPreviousChange` and `editor::GoToNextChange`
Release Notes:
- "Block" diagnostics (that show up in the diagnostics view, or when
using `f8`/`shift-f8`) are rendered more clearly
- `f8`/`shift-f8` now always go to the "next" or "prev" diagnostic,
regardless of the state of the editor
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Julia Ryan <juliaryan3.14@gmail.com>
Closes#27731
Uses similar logic as other popovers for layouting signature help
popover.
Release Notes:
- Fixed case where signature help popover goes off the screen.
