aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/ugrid.c
Commit message (Collapse)AuthorAge
* refactor: follow style guidedundargoc2023-11-13
| | | | | | - reduce variable scope - prefer initialization over declaration and assignment - use bool to represent boolean values
* build: remove PVSdundargoc2023-11-12
| | | | | | | We already have an extensive suite of static analysis tools we use, which causes a fair bit of redundancy as we get duplicate warnings. PVS is also prone to give false warnings which creates a lot of work to identify and disable.
* refactor(grid): change schar_T representation to be more compactbfredl2023-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, a screen cell would occupy 28+4=32 bytes per cell as we always made space for up to MAX_MCO+1 codepoints in a cell. As an example, even a pretty modest 50*80 screen would consume 50*80*2*32 = 256000, i e a quarter megabyte With the factor of two due to the TUI side buffer, and even more when using msg_grid and/or ext_multigrid. This instead stores a 4-byte union of either: - a valid UTF-8 sequence up to 4 bytes - an escape char which is invalid UTF-8 (0xFF) plus a 24-bit index to a glyph cache This avoids allocating space for huge composed glyphs _upfront_, while still keeping rendering such glyphs reasonably fast (1 hash table lookup + one plain index lookup). If the same large glyphs are using repeatedly on the screen, this is still a net reduction of memory/cache consumption. The only case which really gets worse is if you blast the screen full with crazy emojis and zalgo text and even this case only leads to 4 extra bytes per char. When only <= 4-byte glyphs are used, plus the 4-byte attribute code, i e 8 bytes in total there is a factor of four reduction of memory use. Memory which will be quite hot in cache as the screen buffer is scanned over in win_line() buffer text drawing A slight complication is that the representation depends on host byte order. I've tested this manually by compling and running this in qemu-s390x and it works fine. We might add a qemu based solution to CI at some point.
* build: allow IWYU to fix includes for all .c filesdundargoc2022-11-15
| | | | | | | | | | Allow Include What You Use to remove unnecessary includes and only include what is necessary. This helps with reducing compilation times and makes it easier to visualise which dependencies are actually required. Work on https://github.com/neovim/neovim/issues/549, but doesn't close it since this only works fully for .c files and not headers.
* refactor(uncrustify): change rules to better align with the style guideDundar Goc2022-04-29
| | | | | | | | | | | | | Add space around arithmetic operators '+' and '-'. Remove space between back-to-back parentheses, i.e. ')(' vs. ') ('. Remove space between '((' or '))' of control statements. Add space between ')' and '{' of control statements. Remove space between function name and '(' on function declaration. Collapse empty blocks between '{' and '}'. Remove newline at the end of the file. Remove newline between 'enum' and '{'. Remove newline between '}' and ')' in a function invocation. Remove newline between '}' and 'while' of 'do' statement.
* refactor: format with uncrustify #15872dundargoc2021-10-02
| | | | * refactor: format with uncrustify * refactor: fix function parameter comments
* PVS/V1028 ugrid.c:76 (#10495)Ihor Antonov2019-07-14
| | | | * code review
* vim-patch:8.0.1496: VIM_CLEAR()Justin M. Keyes2019-05-25
| | | | | | | | Problem: Clearing a pointer takes two lines. Solution: Add VIM_CLEAR() and replace vim_clear(). (Hirohito Higashi, closes #2629) vim-patch:8.0.1481
* UI/TUI: improvements and cleanups for scrolling and clearingBjörn Linse2018-11-11
| | | | | | | | | | | | - TUI: _never_ rely on BCE for implicit clearing, only explicit commands. - TUI: use unibi_erase_chars when possible. - TUI: use end-exclusive ranges for invalid and cleared areas - screen: scrolling leaves scrolled in aree undefined. This is a conservative change, a client assuming the old semantics will still behave correctly. - screen: factor out vsep handling from line drawing. This is needed anyway for the multigrid refactor. - screen: simplifications of win_do_lines
* TUI: always use safe cursor movement after resizeBjörn Linse2018-10-06
| | | | | | | | | | | | | | | | The old code could lead to a memory error in the following situation: 0. The previous cursor position was row 50 since before, on a grid larger than 50 rows. 1. grid_resize changes the grid height to 40, and invalidly assumes the resize moved the physical cursor to row 0 2. Some event used a operation that could move the cursor (such as clear), and then reset the cursor to the "true" position row 50 (pointless after #8221, but I forgot to remove it) 3. raw_line/cheap_to_print is invoked, and tries to inspect the grid at row 50 (memory error) 4. grid_cursor_goto would have been called at this point, and set a valid cursor position 0-39.
* tui: eliminate scrolling region data structureBjörn Linse2018-09-27
| | | | | | | | | The scrolling region is always local to a single grid_scroll event, use local variables and parameters instead. The invocation of reset_scroll_region in grid_resize is cargo-culted to use margin reset under exactly the same circumstances, not sure if it is necessary though.
* tui: eliminate grid->attrs, use indexed cell->attrBjörn Linse2018-09-26
| | | | remove dead ugrid_put
* ui: fix glitches where scrolling region affects clearing of screenBjörn Linse2018-07-24
| | | | | | | | the first implemented UI protocol clients (python-gui and builitin TUI) allowed the cleared region to be restricted by setting the scroll region. This was never used by nvim though, and not documented and implemented by newer clients, to check we remain compatible with both kind of clients, ensure the scroll region is in a reset state.
* ui: use line-based rather than char-based updates in screen.cBjörn Linse2018-07-21
| | | | | | | | | | | | | Add ext_newgrid and ext_hlstate extensions. These use predefined highlights and line-segment based updates, for efficiency and simplicity.. The ext_hlstate extension in addition allows semantic identification of builtin and syntax highlights. Reimplement the old char-based updates in the remote UI layer, for compatibility. For the moment, this is still the default. The bulitin TUI uses the new line-based protocol. cmdline uses curwin cursor position when ext_cmdline is active.
* ui/tui: highlighting refactorBjörn Linse2018-02-11
| | | | | | | | Make HlAttr contain highlighting state for both color modes (cterm and rgb). This allows us to implement termguicolors completely in the TUI. Simplify some logic duplicated between ui.c and screen.c. Also avoid some superfluous highlighting reset events.
* ugrid.c: destroy_cells(): avoid double-freeJustin M. Keyes2018-01-16
| | | | https://github.com/neovim/neovim/issues/7572#issuecomment-345257295
* Adds nvim_get_hl_by_name/by_idMatthieu Coudron2017-09-30
| | | | | | | | | ...in order to retrieve highlights. Added test/functional/api/highlight_spec.lua HL_NORMAL is not really a good name, since it's more like an empty attribute than the normal's one. If one pays attention, syn_cterm_attr2entry is never called with attr=0 because it's always special cased before. I suggest in subsequent PRs we remove the ATTR_OFF and just insert an EMPTY ATTR/RESET_ATTR/UNINITIALIZED for id 0.
* *: Add comment to all C filesZyX2017-04-19
|
* tui: Move screen state tracking to new "ugrid" moduleThiago de Arruda2015-09-06
The ugrid module implements a unicode "drawing" grid and is used to store TUI screen state. Later this module will be reused in other layers.