Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xi: an editor for the next 20 years [video]

recurse.com

Post reply on HN
Print view View original

151–160 of 306 posts

Re: Xi: an editor for the next 20 years [video]

#151

Post by FullyFunctional »

zeveb wrote: post #137
cmyr wrote: post #129

Earlier quoted context omitted.

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.

> > Emacs and vim are native apps. > 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. I daresay that the single most common way to deploy emacs is as an X11 editor, followed by a macOS editor, followed by a vt100 console editor. Emacs is a fully GUI programme, and has been for decades at this point.

I'd be careful about such conclusions without a study. It certainly doesn't fit my usage. I'm at least twice as likely to hit "emacs -nw" for a quick edit than launch the GUI version. Being useful in a terminal is a critical requirement for me.

Re: Xi: an editor for the next 20 years [video]

#152

Post by jarpineh »

acoard wrote: post #144
jarpineh wrote: post #123

Earlier quoted context omitted.

I'll add my thank you. I'm also backer at Patreon. With tmux control mode it's already very good and now with faster rendering coming...

I've got an unrelated question about tmux/iTerm2 - hope you don't mind me asking. I'm a heavy iTerm2 user and always been curious about tmux. Is there any reason to try out tmux integration if I'm already comfortable with iTerm2's features and panelling? I kind of got the impression tmux integration was largely for people who love tmux and are migrating to iTerm2, so it just makes it more familiar. Or is it something…

Not at all, if only to tell about virtues iTerm2 and tmux to wider audience!

Short version: iTerm with tmux control mode (tmux -CC flag) is still iTerm, only now with tmux benefits like persistent shell sessions. iTerm translates regular commands like new window and split pane into tmux commands and acts otherwise like regular iTerm. Mac might crash or SSH get disconnected and tmux stays running to save you from losing anything (well, if it's running on a server..).

In addition you tmux gives you shell sharing and allows using different devices alltogether. I sometimes use iPad or iPhone with Blink.app to connect to my always running sessions. You can connect to existing tmux session attaching with CC mode and iTerm will open windows and panes to accommodate.

One caveat if you require Mosh for network issues: it and tmux control mode aren't compatible. Also, I'd like to open tmux windows as tabs instead of separate iTerm windows, but that's a minor thing.

This page on iTerm's wiki explains things in detail: https://gitlab.com/gnachman/iterm2/wikis/TmuxIntegration

Re: Xi: an editor for the next 20 years [video]

#153

Post by kazinator »

avshyz wrote: post #82
kazinator wrote: post #76

> modern text editor with uncompromising performance Solution in search of a problem. I haven't run into an editor performance issue in more than twenty years. I will gladly trade a hundred text editor performance fixes for one web browser performance fix .

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 browser engine and dev tools.

I.e. it's not obvious from the unchangingly crappy browser experience itself, so we have to convince ourselves by believing the changelog.

Re: Xi: an editor for the next 20 years [video]

#154

Post by inferiorhuman »

patrickaljord wrote: post #143
pier25 wrote: post #128

Just today I was trying to edit a 15MB JSON file and it was so terribly slow with Sublime Text and wondered if there was something faster out there. Edit: So I built Xi-Mac and the file opens in a fraction vs ST3 but once it's open performance is just as bad or maybe even worse.

A 15MB json file is more like a mini database, it'd be faster to run a quick script to import it in a nosql json database and then query from there. It may take 5 minutes but then you won't want to throw yourself out of the window when trying to edit/query it.

Why? jq should be able to make quick work out of it, or Postgres if you need more complex queries.

Re: Xi: an editor for the next 20 years [video]

#155

Post by ivrrimum »

frou_dh wrote: post #102
cortesoft wrote: post #75

Earlier quoted context omitted.

I am guessing he works at a place that has a lot of servers that he connects to, and he wants to be able to use his editor on whatever server he is on. I know this is an issue where I work. We have 40 thousand plus servers, and we aren't going to have everyone install their editor of choice on all those machines. If I have an issue I need to check on a server that requires some text editing, I have to use one of the…

This is the appeal of sshfs - to be able to easily mount remote filesystems and use local tools against them.

Yeah, but sshfs has been working pretty slow to me.

There is actually this neat hack you can use(if you use VIM) with rsync.

https://github.com/IvRRimum/rsync-vim

I know it's kind of Hacky, but the performance improvement is worth it IMO.

Re: Xi: an editor for the next 20 years [video]

#156

Post by cmrdporcupine »

brucephillips wrote: post #109
avshyz wrote: post #82

Earlier 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. Can you provide an example? Because I've worked on > 1MM line projects in IntelliJ with no performance issues, or at least none related to text editing.

Holy crap, try bringing the Chromium codebase into CLion. UI freezes up constantly while the C++ indexing engine does... stuff. Then eventually hangs untill SIGKILLed. Even after giving the JVM 48 gigs on my 64gig dual Xeon 36 core workstation.

Which is a great argument for Xi's architectural choice to disentangle syntax highlighting and display out into separate processes.

Re: Xi: an editor for the next 20 years [video]

#157

Post by kllrnohj »

jwilm wrote: post #141
raphlinus wrote: post #114

Earlier quoted context omitted.

I'll have to try this out. My experiments indicated that DirectWrite could not keep up with drawing on a 4k monitor at 60 Hz, though was ok at a smaller window. I think it might depend a lot on driver too. I'll see if I can instrument the xi-win prototype to give performance numbers. I do note that your lines aren't very wide, but still, in my tests I wasn't seeing anything like 500fps. DirectWrite does at least seem…

> 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.

Re: Xi: an editor for the next 20 years [video]

#158

Post by kllrnohj »

vardump wrote: post #101
c-smile wrote: post #98

"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter ( https://sciter.com )... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen tex…

> On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. Sure, 500 fps, but that's not the important part. Latency would be. So at 500 fps with how much output latency to the display?

It would be dependent on how deep the pipeline is. In the fairly common case of 1 to 2 app threads (ui + rendering) + GPU work you're looking at a pipeline depth of 3, so if it's doing 500fps that must mean no stage of the pipeline is taking longer than 2ms. With 3 pipeline stages that puts your worst-case latency at 6ms.

Re: Xi: an editor for the next 20 years [video]

#159

Post by tootie »

patrickaljord wrote: post #143
pier25 wrote: post #128

Just today I was trying to edit a 15MB JSON file and it was so terribly slow with Sublime Text and wondered if there was something faster out there. Edit: So I built Xi-Mac and the file opens in a fraction vs ST3 but once it's open performance is just as bad or maybe even worse.

A 15MB json file is more like a mini database, it'd be faster to run a quick script to import it in a nosql json database and then query from there. It may take 5 minutes but then you won't want to throw yourself out of the window when trying to edit/query it.

I could open a 15mb file in Eclipse 10 years ago. Idk why we're reinventing the wheel when we have flying cars. If you're not just using a JetBrains editor then you're being a masochist.

Re: Xi: an editor for the next 20 years [video]

#160

Post by CuriousCosmic »

brucephillips wrote: post #109
avshyz wrote: post #82

Earlier 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. Can you provide an example? Because I've worked on > 1MM line projects in IntelliJ with no performance issues, or at least none related to text editing.

A lot of people refer to atom and vscode when complaining about the performance of modern text editors and while they are not the only modern text editors by far, they are definitely some of the more popular ones at the moment.

I can definitely say that atom has performance issues. I get lockups and stutters working on small and medium sized files (hundreds to thousands of lines) and it is infuriating. It is unfortunate because there are a lot of great new plugins for these platforms but they consistently cause me all kinds of trouble.

Old school editors(like vim or emacs) or modern IDEs perform much better as text editors nowadays compared to plain modern text editors.

Post reply on HN