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

231–240 of 306 posts

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

#231

Post by virgilp »

raphlinus wrote: post #11

Presenter here, feel free to ask questions. Also thanks to the awesome Recurse Center for inviting me to speak and making the recording, and the audience for their great questions.

Would you say Xi is usable for "real-life end users"? If yes, what are the best-supported usecases? If not yet - do you have a plan for getting there, or is it still mostly a research project?

(FWIW, I tried compiling Xi on OSx & opening a large file in it. To its credit, it worked, but there are issues; e.g. horizontal scrollbar is wrong, word wrapping is not working etc)

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

#232

Post by kranzky »

yla92 wrote: post #179
kranzky wrote: post #176

Great stuff, and awesome to see this coming from Google (and in Rust instead of Go). Interesting historical note: The author of Sublime Text left Google to work on it by himself when he couldn't get it approved as a 20% project.

It is not "coming" from Google despite it is under Google GitHub organization. There is a disclaimer[1] at the bottom of the repo README, stating that "This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.". It's my understanding that it's Raph code and Google has nothing to do with it other than having to own the code. [1] : https://github.com/google/…

Oh. Well, damn. I guess Steve Yegge was right. Anyway, wouldn't it be great if Google launched a kick-ass text editor?

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

#233

Post by akmittal »

xyproto wrote: post #223

I'm so conflicted about this. On one hand, having the "engine" written in Rust, and the frontend written in language suitable for writing a GUI, per platform, is a sound architectural choice. On the other hand, if there's one type of open source applications we have enough to choose from already, it's editors. If it's for fun and the educational process, then by all means, that's swell. Bui if it's because the world…

We have plenty of editors to choose from but we might use a Editor which has VSCode/Atom features+customization and vim performance.

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

#234

Post by vidarh »

Jyaif wrote: post #118
kazinator wrote: post #77

Earlier quoted context omitted.

Text editors shouldn't have a "core" and "front end" and "protocol". Monolithic machine executable that fits into under a meg of RAM and comes up in a fraction of a second from a cold invocation.

I've got bad news for you: vim and the other editors you are thinking about also have a core (vim), front end (whatever terminal you use), and a protocol to talk in between them.

Not just that, but many editors have a client/server architecture for the editor itself as well.

Quickly scanning Emacs "NEWS" files, the first mention I found of emacsclient dates back to between '86 and '92. I'm pretty sure it's older. This was added as an option exactly because it is more efficient and leaner to start a separate UI than starting a separate editor instance each time, and adds very little bloat (on my system, emacsclient is a 23KB binary), and it adds so little latency as to not be noticeable.

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

#235

Post by sametmax »

akmittal wrote: post #233
xyproto wrote: post #223

I'm so conflicted about this. On one hand, having the "engine" written in Rust, and the frontend written in language suitable for writing a GUI, per platform, is a sound architectural choice. On the other hand, if there's one type of open source applications we have enough to choose from already, it's editors. If it's for fun and the educational process, then by all means, that's swell. Bui if it's because the world…

We have plenty of editors to choose from but we might use a Editor which has VSCode/Atom features+customization and vim performance.

Sublime text is quite close to that.

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

#236

Post by PurpleRamen »

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.

15 MB seems too small for making problems in any mature editor. Was it perhaps lacking newlines? Pretty much every editor sucks when you have very long lines.

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

#237

Post by dsego »

xyproto wrote: post #223

I'm so conflicted about this. On one hand, having the "engine" written in Rust, and the frontend written in language suitable for writing a GUI, per platform, is a sound architectural choice. On the other hand, if there's one type of open source applications we have enough to choose from already, it's editors. If it's for fun and the educational process, then by all means, that's swell. Bui if it's because the world…

Probably none of them got it quite right then. There are people who want a lightweight but extendable GUI editor. The fact that people, including me, pay for Sublime Text, when there are powerful open-source alternatives around, kinda proves that there is a demand for such a thing.

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

#238

Post by rkangel »

eadmund wrote: post #186
FullyFunctional wrote: post #151

Earlier quoted context omitted.

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.

> I'm at least twice as likely to hit "emacs -nw" for a quick edit than launch the GUI version. I think that alone marks you as an unusual emacs user; the standard pattern for using emacs is to leave it running all the time (either in a window, or as a dæmon), not to launch new instances. But yes, it would be interesting to have numbers. > Being useful in a terminal is a critical requirement for me. Oh, certainly; in…

What do you find that achieves for you that an X11 emacs running a server doesn't?

I have EDITOR set to emacsclient (and some other aliases) and I find it far more convenient than an in-terminal editor, especially when combined with sudoedit.

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

#239

Post by erikb »

Never I would have guessed that "xi" is pronounces "gsai". I would pronounce it "shee" (like chinese) or "ksai" (english) or "ksee" (german).

Also, I don't thin we need another editor with a pluggable focus. It's not true that you need plugins to a text editor. It is plugged into an environment that also contains all the other things you need. It interacts via "open file", "read file", "write file" and "close file" with the other tools. It basically _IS_ the plugin for editing files.

And if you really want an editor containing plugins, then there's a load of it out there. You can start with all the IDEs, you can start with Emacs, you can start even with Neovim or Atom. This is not a feature that needs another project.

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

#240

Post by spinningarrow »

TheAceOfHearts wrote: post #221
postit wrote: post #9

Xi 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 still can’t get 256 colours working properly in tmux in Terminal.app - any idea if that’s supported?
Post reply on HN