I wonder if the name is a tip of the hat to China and their leader. Anyone know?
Xi: an editor for the next 20 years [video]
241–250 of 306 posts
Re: Xi: an editor for the next 20 years [video]
#242Xi creator did an amazing work implementing ropes ( https://github.com/google/xi-editor/tree/master/rust/rope ) The design documents ( https://github.com/google/xi-editor/tree/master/doc/rope_sci... ) explaining the concepts and implementation details is a must for those who want to understand its core. But I still have my regards regarding input latency being accredited only to the text editor. I recently switched b…
Have you tried Terminal.app recently? A lot of people seem to rush immediately to iTerm2... And I used to be one of those, a few years back. But eventually I gave the built-in Terminal.app a serious chance and found it met all my requirements. Although I also stopped customizing my theme, and I keep as many defaults as possible. SF Mono is a great font!
I did the same thing a few years ago. Terminal.app has had tab support for years now. What's the killer feature of iTerm these days?
I also recall finding Terminal.app to have lower CPU consumption, matching postit's experience.
Re: Xi: an editor for the next 20 years [video]
#243Earlier quoted context omitted.
That is correct. I'm measuring scrolling at low to medium speeds, where the majority of the text hasn't changed (this also corresponds to most editing tasks). I don't want to make the claim that I'm keeping up when scrolling at very high speeds. I think my assumptions are reasonable for an editor, but for a terminal scrolling at high speed is much more common. I have certainly considered fast-pathing monospaced font…
Keep in mind a lot of less-sophisticated users will just mash navigation keys (or click-drag the scrollbar) instead of using more sophisticated navigation commands. If high-speed scrolling isn't reasonably optimized, it will be noticed.
Yeah also I recently tried Xi-mac and the first thing I did to see how fast it was was to drag the scroll bar quickly. Based on my experience of other editors that is where they usually get slow (no editor seriously has problems inserting one character at a time).
Unfortunately Xi was quite laggy in the scrolling department. Slower than VSCode for example.
Re: Xi: an editor for the next 20 years [video]
#244Re: Xi: an editor for the next 20 years [video]
#245Earlier quoted context omitted.
> Skia is definitely capable of good performance, as it resolves down to OpenGL draw calls, pretty much the same as Alacritty, WebRender, and now xi-mac. This claim is a bit surprising to me. I was under the impression Skia is an immediate mode renderer which ends up issuing a lot GL calls that could be avoided with a retained mode renderer.
An immediate-style API does not mean the work is performed immediately. Skia defers and reorders internally to batch commands so minimal GL state changes are required. That said a "lot of GL calls" for a 2D UI is actually a trivially insignificant number of GL calls to the actual GPU/driver for most cases. That's basically never the bottleneck unless you've done something insanely wrong.
I wouldn't be so sure. A single draw call is surprisingly slow. If you drew each glyph with one draw call that could be hundreds which will definitely cause slowness.
Re: Xi: an editor for the next 20 years [video]
#246Earlier quoted context omitted.
How powerful are you planning your extensions to be? On a scale from Textmate (shortcuts that run shell scripts) to Emacs (you can implement Vim in Emacs), where would Xi's extensions stand?
Considering plugins can be written in any language and communicate via JSON, I'd posit they can be whatever you prefer. Turing-complete, even.
Consider the following quedtions: Can they overload arbitrary key presses? Can they modify what is on the screen? Can they change the screen's content without changing the file's content? Can they call the editor's own editing functions? Can they be called by the editor's own editing functions?
Textmate can bind shell scripts to shortcuts, but letter keys always insert letters, and the editor always shows the file's content.
Emacs can execute arbitrary code on arbitrary keys, which enables you to implement vim-style key bindings. Also, Emacs can display stuff that is not a file, which enables mail clients, git clients, and terminal emulators.
Re: Xi: an editor for the next 20 years [video]
#247Xi creator did an amazing work implementing ropes ( https://github.com/google/xi-editor/tree/master/rust/rope ) The design documents ( https://github.com/google/xi-editor/tree/master/doc/rope_sci... ) explaining the concepts and implementation details is a must for those who want to understand its core. But I still have my regards regarding input latency being accredited only to the text editor. I recently switched b…
A more interesting approach would be to use persistent data structures. While possibly slower for some operations, undo is more efficient and there are really interesting opportunities for concurrency. See: https://github.com/arximboldi/ewig/blob/master/README.md
Thanks willtim, for mentioning Ewig/Immer :)
As Ralph and others have pointed out, their rope is fundamentally a persistent data structure.
I think that one of the fundamental differences between how Rust and C++ deal with value and reference semantics make the two approaches look more different than they are. The C++ API is allowed to look a bit more "immutable", where one can always use the same functional looking API even though sometimes the performance of an operation is gonna depend on the category of the reference you are operating on (l-value, r-value). Rust forces the user to be explicit about everything all the time, making it very explicit when intend to "branch" or "snapshot" the persistent data structure and where do we wanna allow "in place" updates.
I am still undecided about which approach I like most, and I do think that there merits to each approach. But maybe just because I never really wrote anything serious in Rust. The C++ approach has the problem that it becomes unsafe once you introduce `std::move` (but if the C++ type system was not a crazy evolutionary monster one could imagine a similar approach with moves being inserted automatically and safely by the compiler.)
Re: Xi: an editor for the next 20 years [video]
#248Earlier quoted context omitted.
That's because you (probably) haven't used a modern text editor. If you'd follow either chrome's or firefox's changelog you'd also read about constant progress in optimizing their browser engine and dev tools.
> That's because you (probably) haven't used a modern text editor. So first I have to create a problem for myself by using a "modern" editor, and then instead of fixing the problem in the obvious way (going back to the normal editor that works efficiently) I should wait around for something like this. > If you'd follow either chrome's or firefox's changelog you'd also read about constant progress in optimizing their…
> So first I have to create a problem for myself by using a "modern" editor, and then instead of fixing the problem in the obvious way (going back to the normal editor that works efficiently)
I've been working on LA*P based systems for almost 20 years. Been the head cheerleader of the Unix is the IDE camp and thought I'd never need any editor other than vim. Up until about 6 months ago.
The sad truth is because of the way modern software is engineered and this even includes web sites written in PHP (try magento 2) some modern code bases are really difficult to traverse without a decent IDE and a couple of plugins specific to the stack. Other kinds of development (android, iOS) there are IDEs (principally text editors with a few developer centric features) that add so much convenience it would be pretty dumb to sit there suffering away on the command line and vi for three weeks to accomplish poorly what I could do a lot better in a day with xcode.
Sure its doable by a talented developer but we're talking about an order of magnitude loss of efficiency and I question the brilliance of any developer who makes that call based on their religious notions about text editors.
The point is without an i7 and about 16 gigs of ram most modern IDEs are close to unusable so yeah a light, extensible text editor with some modern features is something a lot of serious software developers get pretty wet about
While I'm sympathetic to arguments that these software projects are poorly architected in violation of UNIX principles right now that doesn't pay the bills.
> I.e. it's not obvious from the unchangingly crappy browser experience itself
Unfortunately web developers's unceasing efforts to slow the web down (with massive frameworks that require custom built software and special IDEs to make and in turn leverage dozens of other such frameworks) outpace browser developers' efforts to speed it up ;)
Of course there are browsers which refuse to support all teh silliness that makes the web slow. They're not very popular though.
Re: Xi: an editor for the next 20 years [video]
#249Earlier quoted context omitted.
Have you tried Terminal.app recently? A lot of people seem to rush immediately to iTerm2... And I used to be one of those, a few years back. But eventually I gave the built-in Terminal.app a serious chance and found it met all my requirements. Although I also stopped customizing my theme, and I keep as many defaults as possible. SF Mono is a great font!
I did the same thing a few years ago. Terminal.app has had tab support for years now. What's the killer feature of iTerm these days? I also recall finding Terminal.app to have lower CPU consumption, matching postit's experience.
Quake-style console. I'm too addicted to it unfortunately.
Re: Xi: an editor for the next 20 years [video]
#250Earlier quoted context omitted.
> My main goal is to build something that feels entirely like a native app. It's not clear to me how this relates to the question. Emacs and vim are native apps.
Maybe we're using different definitions of "native". In the most common case, both of these editors use the cross-platform "VT-100 UI Toolkit" (e.g. ansi escape codes in your terminal emulator), regardless of platform. Some exceptions do exist. But native as it's being used in relation to this project refers specifically to whatever frontend framework is 'the standard' for a given platform, where one exists.
Indeed. To me "native" implies that the app will also use the typical keyboard shortcuts that are native to the OS. For example, copy to clipboard via Ctrl+C on Windows and Cmd+C on macOS. Is that the case with Xi?