Add doc on commits and comments
This commit is contained in:
parent
2a0d2fea52
commit
f7ee93eac0
2 changed files with 30 additions and 9 deletions
|
@ -42,14 +42,14 @@ When a buffer is active, it has an `Editor` attached to it; an editor
|
|||
might have associated tree-sitter support, given the file type detected,
|
||||
and offers common services that are aimed to be used by `Commands` to
|
||||
manipulate the contents of a buffer at a higher level, the selections,
|
||||
cursors and the `View`. The commands are used by `Modes` with
|
||||
`Keybindings`. The main mode is Flow and the keybindings can be used
|
||||
to map to a mode built up entirely on solely calling already created
|
||||
commands. An example of a mode created by command composition is
|
||||
`Emacs` mode, for instance, it's possible to create a nano mode with
|
||||
just keybindings. In the other hand, `Vim` and `Helix` modes have
|
||||
particular definitions for commands that interact with the buffers,
|
||||
being modal editors.
|
||||
cursors, cursor selections `CurSel` and the `View`. The commands are
|
||||
used by `Modes` with `Keybindings`. The main mode is Flow and the
|
||||
keybindings can be used to map to a mode built up entirely on solely
|
||||
calling already created commands. An example of a mode created by
|
||||
command composition is `Emacs` mode, for instance, it's possible to
|
||||
create a nano mode with just keybindings. In the other hand, `Vim` and
|
||||
`Helix` modes have particular definitions for commands that interact
|
||||
with the buffers, being modal editors.
|
||||
|
||||
## Text user interface
|
||||
|
||||
|
@ -75,7 +75,7 @@ time. For example, tree-sitter queries to highlight the current
|
|||
file of a particular language, LSPs, git, running a `shell`
|
||||
command via a `task`.
|
||||
|
||||
## Programming languages
|
||||
## Programming languages support
|
||||
|
||||
There are plenty of programming languages that use tree-sitter via
|
||||
[flow-syntax](https://github.com/neurocyte/flow-syntax) and whose
|
||||
|
@ -84,6 +84,9 @@ Currently one Language Server is supported for each language.
|
|||
|
||||
## Facilities
|
||||
|
||||
The clipboard is used for copy, paste operations and there is also
|
||||
support to use the system clipboard, copying and pasting to/from it.
|
||||
|
||||
Logging support offers various levels to give feedback for various
|
||||
actions that ease developing Flow itself and also are used to offer
|
||||
feedback via `logview`.
|
||||
|
|
|
@ -70,6 +70,24 @@ if you find something inaccurate in those docs or others, do open an
|
|||
issue or jump in [Discord](https://discord.com/invite/4wvteUPphx)
|
||||
and comment.
|
||||
|
||||
### Commit comments
|
||||
|
||||
It's better to use commits for different purposes, even if they look small and
|
||||
there is a temptation to include on the same new code, fixes and refactors. Making
|
||||
concise and self contained commits make review easier and future fixes possible,
|
||||
in case of need.
|
||||
|
||||
Use these prefixes as much as you can, doing so helps when identifying the features
|
||||
and eases the process of letting others know about what's new, fixed and help
|
||||
communicate better when releasing.
|
||||
|
||||
* `feat:` when there is a new feature, if specific to a mode, please use
|
||||
`feat: [mode]`.
|
||||
* `refactor`: when reorganizing code, usually when you make something clearer
|
||||
for future readers and commiters.
|
||||
* `fix:` When something changed to a more expected behaviour.
|
||||
* `build`: the commit doesn't change code at all.
|
||||
|
||||
### Testing
|
||||
|
||||
It's possible that the test set grows as the project evolves, given
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue