xi-editor / xi-win

xi-win

Xi editor for Windows

This project is currently a seedling, which I am hopeful will grow into a useful front-end for xi editor.

It makes some decisions which are fairly unusual for GUI software written in 2017. It targets winapi directly, rather than using a toolkit, and is written in Rust. The main reason is so that we can target performance; winapi has api's for Direct2D rendering that may enable significantly lower latency and smoother scrolling than accessible through a toolkit. Part of the reason for taking on this project is to quantify the relative performance.

Other important dimensions of performance are startup speed and executable size.

Given the goals of this project and the (current) flux in the xi protocol, I expect the focus of this project to be input and rendering pipelines, with less emphasis on features; it may be a while before this is really useful as an editor. That said, I certainly welcome any help in getting there sooner.

Contributions

We gladly accept contributions via GitHub pull requests. Please see CONTRIBUTING.md for more details.

If you are interested in contributing but not sure where to start, there is an active IRC channel at #xi on irc.mozilla.org. There is also a subreddit at /r/xi_editor.

Authors

The main author is Raph Levien.

xi-win's Issues

Development is temporarily moved

The master branch is now https://github.com/raphlinus/xi-win until I can get permissions sorted out. Hopefully when that happens, we'll merge that branch back here and this issue will be closed.

File Opening & saving seems to crash on windows 7

Alternative solution to "fn layout needs to mut borrow several nodes"

Hi! I've just seen your awesome talk about data-driven UI's in Rust, and got intrigued by the problem of traversing a ECS-style tree while borrowing nodes mutably.

I think I have a similar problem in other domain: structured editing of syntax trees. Don't want to go into details about it, but if you want to code stuff "find or create node X and add A, B and C children to it", you also sort-of want two mutable borrows of different indices.

I'd like to share my solution, which is different from yours "implement trampoline/state machine by hand". I think it is actually worse for your use case due to interactions with object safety, but it's still interesting.

The idea is that instead of passing a &mut Node, one uses &mut Tree, NodeId. That way, it's possible to reborrow &mut Node as &mut tree[node_id] several times, and use borrowing via other indices in between. Now, this does have to go a number of additional contortions to actually work for dyn Widget state: you need to explicitly separate widget's state and behavior, and then introduce an additional trait to make that object safe, but it does work out in the end, and result looks like this:

https://play.rust-lang.org/?gist=2075f9638163ba4e6187238861d15cba&version=stable&mode=debug&edition=2015

struct Counter;

impl Widget for Counter {
    type Data = usize;

    fn layout(
        ctx: &mut LayoutCtx, // insead of passing &mut Self, we pass an index and `&mut Ctx`
        me: TypedId<Self>,
        children: &[Id]
    ) -> usize {

        for &id in children.iter() {
            let child_layout = ctx.layout(id);
            *ctx.data_mut(me) += child_layout;
        }

        *ctx.data_mut(me)
    }
}

On to re watching Flutter rendering pipeline talk! :)

[Question] Would a dark mode / light mode be wanted?

I have just come across this project and think it's great. I would like to help, but many of the issues I don't know how to fix (e.g. how to implement 'Astral Plane Characters'). So, after reading through the code, I realised that adding another colour palette wouldn't be too hard as it would only require changing:
fg: SolidColorBrush::create(rt).with_color(0xf0f0ea).build().unwrap(),
bg: SolidColorBrush::create(rt).with_color(0x272822).build().unwrap(),
sel: SolidColorBrush::create(rt).with_color(0x49483e).build().unwrap(),

So my question is: Is this wanted by the people in charge of this project?

I would understand if it isn't, and I am working on copy and paste functionality, but this seemed like a fun side-feature.

Rework xi-win to be on top of xi-win-ui

Right now xi-win is implemented directly on top of xi-win-shell, and implements its WinHandler trait. This won't scale, and should be reworked to be a xi-win-ui app. Note: I did this work, but seem to have lost the git branch in the confusion of the repo move. Here I'll try to outline the major pieces of work needed.

The main work is changing EditView to implement xi-win-ui's Widget trait. This trait is roughly similar to the existing code - both are concerned with consuming mouse, kb, and other events (including resize), and painting the edit view. Of course, there are other tricky bits.

The central tricky bit is handling the Core state and plumbing it to the EditView so the latter can send notifications (implementing various edit commands) and also receive updates. The most straightforward way to do this is to wrap it in an Arc<Mutex<>> so that all EditView instances share a reference. There may be other, more "data-oriented" ways to do it, or it's possible to use a non-thread-safe shared reference, but doing it this way is most similar to xi-mac.

For the EditView to receive updates from core, there needs to be a way to send events into the UI from the outside. In my lost patch, I had an ext_listener which was parallel to the existing command_listener, and it was also thread-safe. One of the subtasks is to recreate that. (Note that it's required for the synthesizer as well, so the UI can respond to external MIDI and possibly to events generated by the synthesis thread).

Another tricky bit is implementation of the file commands. The file dialogs themselves are in a bit of a hacky state, as they're implemented in xi-win-shell but not xi-win-ui, and require a raw HWND handle. This can be hacked, but it should be made cleaner.

We should anticipate multiple EditView instances. There will be a "current" instance (similar to focus, but it's possible there's a current EditView even if, for example, there's a find dialog open that has focus), and commands should be forwarded to the current instance.

I'm happy to have help on this, and also happy to answer questions. I can take on any chunks that seem daunting though; it's certainly not a trivial refactor, and it intersects with a bunch of other things needing work (see #44 for example).

Provide a precompiled binary?`

It'd be nice.

Building in windows seems to require gcc?

I get this error in windows 10 building release build with cargo build --release.

   Compiling bincode v1.0.1
error: failed to run custom build command for `miniz-sys v0.1.11`

Caused by:
  process didn't exit successfully: `C:\Users\jesse\source\repos\github\xi-editor\xi-win\target\release\build\miniz-sys-201f847f1e1c804d\build-script-build` (exit code: 101)
  --- stdout
  TARGET = Some("x86_64-pc-windows-gnu")
  OPT_LEVEL = Some("3")
  HOST = Some("x86_64-pc-windows-gnu")
  CC_x86_64-pc-windows-gnu = None
  CC_x86_64_pc_windows_gnu = None
  HOST_CC = None
  CC = None
  CFLAGS_x86_64-pc-windows-gnu = None
  CFLAGS_x86_64_pc_windows_gnu = None
  HOST_CFLAGS = None
  CFLAGS = None
  DEBUG = Some("false")
  running: "gcc.exe" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-DMINIZ_NO_STDIO" "-DMINIZ_NO_ARCHIVE_APIS" "-DMINIZ_NO_ARCHIVE_WRITING_APIS" "-DMINIZ_NO_TIME" "-DMINIZ_NO_ZLIB_COMPATIBLE_NAMES" "-o" "C:\\Users\\jesse\\source\\repos\\github\\xi-editor\\xi-win\\target\\release\\build\\miniz-sys-c81999ae0ba5eca0\\out\\miniz.o" "-c" "miniz.c"

  --- stderr
  thread 'main' panicked at '

  Internal error occurred: Failed to find tool. Is `gcc.exe` installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)

  ', C:\Users\jesse\.cargo\registry\src\github.com-1ecc6299db9ec823\cc-1.0.25\src\lib.rs:2260:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

My compiler version:

$ rustc --version
rustc 1.46.0 (04488afe3 2020-08-24)

Give Instruction of installation and run command in readme File

Consider using crates.io/crates/xrl?

Hey Raph,
I've been working on xrl trying to get it ready to start working on my front end over the next couple of months, but i'd like to see Xrl used by as many front ends as possible, at least the one's written in rust. I found in my early experience's with Xi writing the Update logic to be a bit tedious and error prone. Xrl handle's all of that logic(or it will after my PR is accepted) just requiring the user to pass a 'Update' to there line cache and Xrl handle's it appropriately. Multiple front ends using xrl would reduce duplication of work throughout the Xi community.

It is already in use by little-dude/xi-tui and i plan on having my front end bytebuddha/Zen running by the end of this year(cant work on it until then, I've got a busy couple of months ), so i'm looking for smaller project's in the Xi ecosystem to work on in my free time.

I chose to try and convert xi-win first because:
- It is small
- Not much development going on at the moment
- It's written in rust
- As far as i know Xrl has never been tested on any OS other than Linux and i would prefer to get testing on both Mac & Windows.

So with that in mind a have a few question's:

• What do you think of using Xrl as a common library for xi front ends
  - If not why?
• Is xi-win in to early a stage to switch to using xrl?
• Have you ever thought about a seperate(or internal in the xi repo?) library to handle all of xi-core front end protocol? (from a front ends point of view)
  - If you have could you share your thoughts on it?

Thank you so much for creating Xi, I've found it to be the perfect project to play with in my free time and has taught me alot!

Doesn’t handle astral plane characters

When I use my fancy Compose key to enter 😀 (or via the Win+. emoji panel), I just get this on stdout:

invalid code point 0xd83d
invalid code point 0xde15

Not sure whether not supporting unmatched surrogates is a bug or a feature—for a text editor I’d lean towards “bug”. But the two should be joined together, anyway.

vim/vim#2800 may be of assistance in resolving this.

release

it would be helpful if a built release was available:

https://github.com/xi-editor/xi-win/releases

ETW Tracing using rusttrace crate

Hi,

I've wired up rusttrace(https://github.com/flowerinthenight/rusttrace) crate in xi-win ui.
It's a small mess to setup(can make a powershell script to automate it), but can be handy for debugging, in absence of println!, also ETW events can be used by tools like perfview for profiling.

Was wondering if you see any value in a pull request for this, if not so I could avoid the trouble of signing google license agreements.

Here's an example trace as displayed in the command line by mftrace.

Listening to ETW events (CTRL+C to end)
           __M_F_T_R_A_C_E___LOG__

PID, TID    Time (UTC)    TraceMessage
--------- --------------  ------------
19264,5614 20:26:32.28073 RustTrace Generic @xi-win-ui
19264,5614 20:26:32.32400 RustTrace Generic @Request {"method":"client_started","params":{}}
19264,5614 20:26:32.32405 RustTrace Generic @Request {"id":0,"method":"new_view","params":{}}
19264,3F9C 20:26:32.36444 RustTrace Generic @Response {"method":"available_themes","params":{"themes":["InspiredGitHub","Solarized (dark)","Solarized (light)","base16-eighties.dark","base16-mocha.dark","base16-ocean.dark","base16-ocean.light"]}}
19264,3F9C 20:26:32.36506 RustTrace Generic @Response {"id":0,"result":"view-id-1"}
19264,3F9C 20:26:32.36515 RustTrace Generic @Response {"method":"available_plugins","params":{"plugins":[],"view_id":"view-id-1"}}
19264,3F9C 20:26:32.36545 RustTrace Generic @Response {"method":"config_changed","params":{"changes":{"auto_indent":false,"font_face":"InconsolataGo","font_size":14,"line_ending":"\r\n","plugin_search_path":[],"scroll_past_end":false,"tab_size":4,"translate_tabs_to_spaces":true,"use_tab_stops":true,"wrap_width":0},"view_id":"view-id-1"}}
19264,3F9C 20:26:32.36580 RustTrace Generic @Response {"method":"update","params":{"update":{"ops":[{"lines":[{"cursor":[0],"styles":[],"text":""}],"n":1,"op":"ins"}],"pristine":true},"view_id":"view-id-1"}}
19264,3F9C 20:26:32.36585 RustTrace Generic @Response {"method":"scroll_to","params":{"col":0,"line":0,"view_id":"view-id-1"}}
19264,5614 20:26:35.02702 RustTrace Generic @Request {"method":"edit","params":{"method":"insert","params":{"chars":"a"},"view_id":"view-id-1"}}
19264,3F9C 20:26:35.02806 RustTrace Generic @Response {"method":"update","params":{"update":{"ops":[{"lines":[{"cursor":[1],"styles":[],"text":"a"}],"n":1,"op":"ins"}],"pristine":false},"view_id":"view-id-1"}}
19264,3F9C 20:26:35.02812 RustTrace Generic @Response {"method":"scroll_to","params":{"col":1,"line":0,"view_id":"view-id-1"}}
19264,5614 20:26:36.15279 RustTrace Generic @Request {"method":"edit","params":{"method":"insert_newline","params":[],"view_id":"view-id-1"}}
19264,3F9C 20:26:36.15366 RustTrace Generic @Response {"method":"update","params":{"update":{"ops":[{"lines":[{"styles":[],"text":"a\r\n"},{"cursor":[0],"styles":[],"text":""}],"n":2,"op":"ins"}],"pristine":false},"view_id":"view-id-1"}}
19264,3F9C 20:26:36.15371 RustTrace Generic @Response {"method":"scroll_to","params":{"col":0,"line":1,"view_id":"view-id-1"}}
19264,5614 20:26:36.91523 RustTrace Generic @Request {"method":"edit","params":{"method":"delete_backward","params":[],"view_id":"view-id-1"}}
19264,3F9C 20:26:36.91603 RustTrace Generic @Response {"method":"update","params":{"update":{"ops":[{"lines":[{"cursor":[1],"styles":[],"text":"a"}],"n":1,"op":"ins"}],"pristine":false},"view_id":"view-id-1"}}
19264,3F9C 20:26:36.91623 RustTrace Generic @Response {"method":"scroll_to","params":{"col":1,"line":0,"view_id":"view-id-1"}}
19264,5614 20:26:37.50286 RustTrace Generic @Request {"method":"edit","params":{"method":"delete_backward","params":[],"view_id":"view-id-1"}}
19264,3F9C 20:26:37.50363 RustTrace Generic @Response {"method":"update","params":{"update":{"ops":[{"lines":[{"cursor":[0],"styles":[],"text":""}],"n":1,"op":"ins"}],"pristine":true},"view_id":"view-id-1"}}
19264,3F9C 20:26:37.50369 RustTrace Generic @Response {"method":"scroll_to","params":{"col":0,"line":0,"view_id":"view-id-1"}}
19264,5614 20:26:38.98490 RustTrace Generic @cleanup

additional character deleted after pressing backspace or delete

If I hit delete in the middle of a word/sentence/line, it deletes the next two characters, and if I hit backspace, it deletes the previous and next character.

Commenting out lines 269 and 279 in edit_view.rs seems to fix this problem, but then I need to press delete/backspace twice when I want to remove the newline (the character '\n').

I hope this is not the wrong place to open the issue. I didn't know where to report it elsewhere

Line display issues

Summary

xi-win sometimes seems to have trouble displaying more than 12 contiguous lines

1. File save/open
2. Using the mouse to move the cursor
3. Selections

Steps to reproduce

1. Open file with more than 12 lines
2. Hold shift + down arrow keys and watch the fireworks

There seem to be a lot of ways you can make lines disappear. I've noticed that sometimes when I click on a line with the mouse, an arbitrary line elsewhere in the file will go blank.

Incorrect extraction of the mouse Y coordinate for mouse move

On line:
https://github.com/google/xi-win/blob/master/xi-win-shell/src/window.rs#L495

I believe that should be:

let y = HIWORD(lparam as u32) as i16 as i32;

Also, in Microsoft docs the suggested way to get the X and Y coordinates is using these macros(https://docs.microsoft.com/en-us/windows/desktop/inputdev/wm-mousemove#remarks).

It seems to be implemented in winapi-rs(https://retep998.github.io/doc/winapi/windowsx/fn.GET_X_LPARAM.html), but looking at the implementation it doesn't differ much from the current approach, seems to work though.

Build issue

c:\Dominic\programming\repos\git\xi-win\xi-win-shell>cargo build
Compiling winapi-x86_64-pc-windows-gnu v0.4.0
Compiling winapi v0.3.6
Compiling num-traits v0.2.6
Compiling num-integer v0.1.39
Compiling rustc-serialize v0.3.24
Compiling num-iter v0.1.37
Compiling version_check v0.1.5
Compiling boolinator v2.4.0
Compiling either v1.5.0
Compiling libc v0.2.43
Compiling lazy_static v1.1.0
Compiling num-complex v0.1.43
Compiling rand v0.4.3
Compiling wio v0.2.0
Compiling time v0.1.40
Compiling directwrite v0.1.4
Compiling num-bigint v0.1.44
Compiling num-rational v0.1.42
Compiling num v0.1.42
Compiling dxgi v0.1.7
Compiling direct2d v0.2.0
Compiling xi-win-shell v0.1.0 (C:\Dominic\programming\repos\git\xi-win\xi-win-shell)
error[E0432]: unresolved import winapi::um::handleapi
--> src\util.rs:33:17
|
33 | use winapi::um::handleapi::*;
| ^^^^^^^^^ Could not find handleapi in um

error[E0425]: cannot find value INVALID_HANDLE_VALUE in this scope
--> src\util.rs:275:22
|
275 | if stdout != INVALID_HANDLE_VALUE && GetFileType(stdout) != FILE_TYPE_UNKNOWN {
| ^^^^^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find value INVALID_HANDLE_VALUE in this scope
--> src\util.rs:291:24
|
291 | if chnd == INVALID_HANDLE_VALUE {
| ^^^^^^^^^^^^^^^^^^^^ not found in this scope

warning: unused import: winapi::um::handleapi::*
--> src\util.rs:33:5
|
33 | use winapi::um::handleapi::*;
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_imports)] on by default

error: aborting due to 3 previous errors

Some errors occurred: E0425, E0432.
For more information about an error, try rustc --explain E0425.
error: Could not compile xi-win-shell.

To learn more, run the command again with --verbose.

c:\Dominic\programming\repos\git\xi-win\xi-win-shell>

CLA still necessary?

I noticed today that Contributing.md still references the Google CLA.
I would like to update that for you, but am not sure what you would prefer instead. Should we just refer to the one in xi-editor, maybe?

Issues with Ctrl + C etc.

Trying to use ctrl + c or ctrl + v results in the following being logged (also no copying/pasting happens):
unexpected cmd 262
unexpected cmd 264

with regards to the selected code page:
$ chcp
Active code page: 775

problem building on Windows

Windows 10 x64
Rust 1.45.2

warning: trait objects without an explicit `dyn` are deprecated
   --> src\edit_view.rs:144:38
    |
144 |     fn poke(&mut self, payload: &mut Any, ctx: &mut HandlerCtx) -> bool {
    |                                      ^^^ help: use `dyn`: `dyn Any`
    |
    = note: `#[warn(bare_trait_objects)]` on by default

warning: trait objects without an explicit `dyn` are deprecated
  --> src\rpc.rs:34:32
   |
34 |     pending: BTreeMap<u64, Box<Callback>>,
   |                                ^^^^^^^^ help: use `dyn`: `dyn Callback`

warning: use of deprecated item 'winapi::core::str::<impl str>::trim_right_matches': superseded by `trim_end_matches`
  --> src\textline.rs:42:33
   |
42 |         let trimmed_text = text.trim_right_matches(|c| c == '\r' || c == '\n');
   |                                 ^^^^^^^^^^^^^^^^^^ help: replace the use of the deprecated item: `trim_end_matches`
   |
   = note: `#[warn(deprecated)]` on by default

warning: associated function is never used: `rebuild_resources`
   --> src\edit_view.rs:257:12
    |
257 |     pub fn rebuild_resources(&mut self) {
    |            ^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(dead_code)]` on by default

warning: associated function is never used: `clear_line_cache`
   --> src\edit_view.rs:261:12
    |
261 |     pub fn clear_line_cache(&mut self) {
    |            ^^^^^^^^^^^^^^^^

warning: associated function is never used: `mouse_wheel`
   --> src\edit_view.rs:448:12
    |
448 |     pub fn mouse_wheel(&mut self, delta: i32, _mods: u32) {
    |            ^^^^^^^^^^^

warning: 6 warnings emitted

    Finished dev [unoptimized + debuginfo] target(s) in 2m 10s

Build failure

I cloned the repo and did a cargo build. I got the error below. Do I need to update a dependency?
( I know this is an early version, but I would love to play with it.)

error[E0554]: #[feature] may not be used on the stable release channel
--> C:\Users\epotter.cargo\registry\src\github.com-1ecc6299db9ec823\direct2d-0.0.6\src\lib.rs:2:1
|
2 | #![feature(slice_patterns, const_fn)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error(s)

error: Could not compile direct2d.
Build failed, waiting for other jobs to finish...
error: build failed

32-bit builds not supported

   Compiling xi-win v0.1.0 (file:///E:/prj/rust/xi-win-master)
error[E0425]: cannot find function `SetWindowLongPtrW` in this scope
  --> src\window.rs:40:9
   |
40 |         SetWindowLongPtrW(hwnd, GWLP_USERDATA, wndproc_ptr as LONG_PTR);
   |         ^^^^^^^^^^^^^^^^^ did you mean `SetWindowLongW`?

error[E0425]: cannot find function `GetWindowLongPtrW` in this scope
  --> src\window.rs:42:23
   |
42 |     let wndproc_ptr = GetWindowLongPtrW(hwnd, GWLP_USERDATA) as *const Box<
WndProc>;
   |                       ^^^^^^^^^^^^^^^^^ did you mean `GetWindowLongW`?

error[E0425]: cannot find function `SetWindowLongPtrW` in this scope
  --> src\window.rs:53:13
   |
53 |             SetWindowLongPtrW(hwnd, GWLP_USERDATA, 0);
   |             ^^^^^^^^^^^^^^^^^ did you mean `SetWindowLongW`?

error: aborting due to 3 previous errors

error: Could not compile `xi-win`.

To learn more, run the command again with --verbose.

after some search, refer to gabdube/native-windows-gui#18 , it says:

I've just checked the winapi rs docs for the definition of Get/SetWindowLongPtrW and it is only exported for "x86_64" aka 64 bits Windows.
So, not support 32 bit now?

Figure out presentation strategy

Currently the presentation strategy is hwnd render targets, which are older. A swapchain will provide better performance, but my experiments with swapchains (currently in the dxgi branch) show problems, especially with things like smooth window resizing.

I've written up my explorations, and have also created a thread on gamedev.net, as I've observed others struggling with this problem. In fact, artifacts and lag on window resize is an extremely common problem.

I'm offering a bounty of $2500 for a complete solution to this problem, see the blog for details. I've spent a lot of time on this (so much so it's gotten in the way of other progress), and, while I've learned a lot, feel like I'm getting to the end of that.

Please help test smooth window resizing logic

As I've described in #17, I'm trying to figure out how to get good performance on resizing and also scrolling. It turns out to be quite tricky. I have a couple of approaches, and I'm trying to collect data on how close either is to being acceptable. Please test on your hardware and respond as a comment.

All testers

Let me know OS version, graphics card, monitor size, DPI scaling. Please test master (or #18, if that hasn't been merged yet). The test procedure is:

git clone https://github.com/google/xi-win
cd xi-win/xi-win-shell
cargo run --example perftest --release

Does the spinner spin smoothly? Does the frame interval hold steady at 16-17ms? Does it still perform well if the window is nearly fullscreen?

Grab the left side of the window and resize. Does the window frame track the mouse? Is it smooth or is there jank? Does the diagonal line stay glued to the upper right corner or does it judder?

Don't worry too much about the spinning when resizing - for some reason it can get stuck when starting a move gesture. I also don't expect the frame interval to be consistent while resizing, though smoother is better.

Windows 8.1 and higher

Also try the flip_hwnd branch. Master just uses hwnd render targets, but flip_hwnd uses a more sophisticated approach. In steady state, it uses DXGI swap chains (in the FLIP_SEQUENTIAL swap effect). However, flip presentation is not synchronized with window resize, so it switches to hwnd when resizing, then back to flip.

Do git checkout flip_hwnd then the same tests as above. Is there flashing or any artifact when entering and exiting sizing? Is performance roughly comparable?

Multiple monitors / multiple GPUs

My main laptop is a Gigabyte Aero 14, which has integrated HD 630 and a GTX 1060 in an Optimus configuration. The laptop display is connected to integrated graphics, and the external monitor to discrete. It matters which GPU is selected (which is generally the "make this my main display" in display settings); performance is always degraded when crossing between the two.

Based on testing, I think I always want to draw with discrete graphics, at least in flip mode (in hwnd mode I don't seem to have the choice). How is performance affected when "make this my main display" is selected?

Higher frame rate monitors are also trickier? Does the frame interval hold steady at the faster rate?

Thanks in advance to the testers!

Resize the viewport depending on the window size

Resize the viewport depending on the window size. Add support for tracking the current start line for the view and request required number of lines based on the window height.

Logging (Core errors are ignored)

Currently errors emitted by the error! macro from core is ignored in xi-win.
According to the log package, binaries using libraries which use macros from the log package need to have a logger which can receive the logs. The silent errors then make sense, as Core is used as a library by xi-win, which at the present uses no logger itself.

The fix seems to be initializing a logger early in the program.

I suggest just using something simple, like env_logger to receive the logs from core until a more complicated solution is needed.

Conveniently, we could also use this logger for tracing of commands, etc.