Fix some comments (#8760)
Release Notes: - N/A Signed-off-by: geekvest <cuimoman@sohu.com>
This commit is contained in:
parent
a6dbaac653
commit
20d133322a
5 changed files with 5 additions and 5 deletions
|
@ -21,7 +21,7 @@ GPUI offers three different [registers](https://en.wikipedia.org/wiki/Register_(
|
|||
|
||||
- High level, declarative UI with Views. All UI in GPUI starts with a View. A view is simply a model that can be rendered, via the `Render` trait. At the start of each frame, GPUI will call this render method on the root view of a given window. Views build a tree of `elements`, lay them out and style them with a tailwind-style API, and then give them to GPUI to turn into pixels. See the `div` element for an all purpose swiss-army knife of rendering.
|
||||
|
||||
- Low level, imperative UI with Elements. Elements are the building blocks of UI in GPUI, and they provide a nice wrapper around an imperative API that provides as much flexibility and control as you need. Elements have total control over how they and their child elements are rendered and and can be used for making efficient views into large lists, implement custom layouting for a code editor, and anything else you can think of. See the `element` module for more information.
|
||||
- Low level, imperative UI with Elements. Elements are the building blocks of UI in GPUI, and they provide a nice wrapper around an imperative API that provides as much flexibility and control as you need. Elements have total control over how they and their child elements are rendered and can be used for making efficient views into large lists, implement custom layouting for a code editor, and anything else you can think of. See the `element` module for more information.
|
||||
|
||||
Each of these registers has one or more corresponding contexts that can be accessed from all GPUI services. This context is your main interface to GPUI, and is used extensively throughout the framework.
|
||||
|
||||
|
|
|
@ -35,7 +35,7 @@
|
|||
//!
|
||||
//! - Low level, imperative UI with Elements. Elements are the building blocks of UI in GPUI, and they
|
||||
//! provide a nice wrapper around an imperative API that provides as much flexibility and control as
|
||||
//! you need. Elements have total control over how they and their child elements are rendered and and
|
||||
//! you need. Elements have total control over how they and their child elements are rendered and
|
||||
//! can be used for making efficient views into large lists, implement custom layouting for a code editor,
|
||||
//! and anything else you can think of. See the [`element`] module for more information.
|
||||
//!
|
||||
|
|
|
@ -1328,7 +1328,7 @@ impl Buffer {
|
|||
self.edit(edits, None, cx);
|
||||
}
|
||||
|
||||
/// Create a minimal edit that will cause the the given row to be indented
|
||||
/// Create a minimal edit that will cause the given row to be indented
|
||||
/// with the given size. After applying this edit, the length of the line
|
||||
/// will always be at least `new_size.len`.
|
||||
pub fn edit_for_indent_size_adjustment(
|
||||
|
|
|
@ -83,7 +83,7 @@ impl LspAdapter for PythonLspAdapter {
|
|||
// Where `XX` is the sorting category, `YYYY` is based on most recent usage,
|
||||
// and `name` is the symbol name itself.
|
||||
//
|
||||
// Because the the symbol name is included, there generally are not ties when
|
||||
// Because the symbol name is included, there generally are not ties when
|
||||
// sorting by the `sortText`, so the symbol's fuzzy match score is not taken
|
||||
// into account. Here, we remove the symbol name from the sortText in order
|
||||
// to allow our own fuzzy score to be used to break ties.
|
||||
|
|
|
@ -4,7 +4,7 @@ Zed supports ways to spawn (and rerun) commands using its integrated terminal to
|
|||
|
||||
Currently, two kinds of tasks are supported, but more will be added in the future.
|
||||
|
||||
All tasks are are sorted in LRU order and their names can be used (with `menu::UseSelectedQuery`, `shift-enter` by default) as an input text for quicker oneshot task edit-spawn cycle.
|
||||
All tasks are sorted in LRU order and their names can be used (with `menu::UseSelectedQuery`, `shift-enter` by default) as an input text for quicker oneshot task edit-spawn cycle.
|
||||
|
||||
## Static tasks
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue