Xi: an editor for the next 20 years [video] • Hacker News Board

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

#211

Post by greglindahl » Wed, Jan 31, 2018, 6:16 AM UTC

alkonaut wrote: post #90

mattgreenrocks wrote: post #31

Earlier quoted context omitted.

How is it that text editors are all the sudden this weird competition where you have to win? I get what you're saying, but I think you worry too much about social proof and momentum. It's also grossly unfair to Xi, a project in its infancy. As you mentioned earlier, there is room for another great editor. If the same logic had been applied towards the Electron based editors a few years ago, you'd be arguing against t…

I wouldn't call it "winning" but you do need a big piece of the userbase to be relevant (when we are talking about text editors that are 90% plugins and 10% core, like Atom, Sublime, VsCode, Vim, Emacs...) When I write code in a language I don't find the best language plugin for language X in "my editor". Instead I search for "which editor has the best plugin for language X". And in most of the cases, the difference…

I have a different algorithm: Instead of asking "what editor has the best plugin for X", I just use emacs. If emacs isn't great at X when I start using it for X, it'll be there soon enough.

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

#212

Post by turndown » Wed, Jan 31, 2018, 6:19 AM UTC

kakarot wrote: post #192

kyrra wrote: post #190

Earlier quoted context omitted.

It is much easier as a Google employee to publish open source projects under Google's copyright[0] rather than getting them to grant the copyright to you. To have Google give you (the Google employee) full copyright of projects you work on while at Google, you need to go through a committee[1] that reviews the project to make sure it doesn't collide with some other project Google already is working on. As this is rea…

As a matter of principle this seems like a negative thing for open source. Can someone explain to my why it isn't?

I can't really see an argument to be had that it's not Google's property if it was worked while on the clock.

Considering how protective most companies are of IP, I'm shocked Google even has a mechanism by which a person can take back things they've worked on in office at Google.

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

#213

Post by bch » Wed, Jan 31, 2018, 6:39 AM UTC

I sure did like the corecore communicating idea for multiple users of a single document. It seemed like an easy trap to imagine X11 as the f/e, b/e, plugins, async were talked about, but not “just” using a remote f/e to communicate w a remote core was sort of enlightening (having fell into the X11 trap as the talk was progressing).

Question re: json communication though: is there a space for something like protocol buffers here, or is that a case of YAGNI, or simply ill-suited?

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

#214

Post by alkonaut » Wed, Jan 31, 2018, 6:51 AM UTC

greglindahl wrote: post #211

alkonaut wrote: post #90

Earlier quoted context omitted.

I wouldn't call it "winning" but you do need a big piece of the userbase to be relevant (when we are talking about text editors that are 90% plugins and 10% core, like Atom, Sublime, VsCode, Vim, Emacs...) When I write code in a language I don't find the best language plugin for language X in "my editor". Instead I search for "which editor has the best plugin for language X". And in most of the cases, the difference…

I have a different algorithm: Instead of asking "what editor has the best plugin for X", I just use emacs. If emacs isn't great at X when I start using it for X, it'll be there soon enough.

you picked one that is already in that top. Try that with the 100th most used editor.

I disagree it’s worth sticking to on text editor for programming tasks. The productivity boost of a good complex plugin is huge, way bigger than anything one gets from productivity in the text editing itself that comes from familitarity with the editor I think.

Look at the state of e.g Rust dev in Atom/VSCode/.. today. It will get there but it might be years for the one in spot #3 to reach the #1

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

#215

Post by Derbasti » Wed, Jan 31, 2018, 6:54 AM UTC

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.

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?

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

#216

Post by johnklos » Wed, Jan 31, 2018, 6:57 AM UTC

Nice ideas, but it's a shame that Rust is barely portable.

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

#217

Post by greglindahl » Wed, Jan 31, 2018, 7:01 AM UTC

alkonaut wrote: post #214

greglindahl wrote: post #211

Earlier quoted context omitted.

I have a different algorithm: Instead of asking "what editor has the best plugin for X", I just use emacs. If emacs isn't great at X when I start using it for X, it'll be there soon enough.

you picked one that is already in that top. Try that with the 100th most used editor. I disagree it’s worth sticking to on text editor for programming tasks. The productivity boost of a good complex plugin is huge, way bigger than anything one gets from productivity in the text editing itself that comes from familitarity with the editor I think. Look at the state of e.g Rust dev in Atom/VSCode/.. today. It will get t…

Your point exactly? You appear to either switch editors or consider switching on a regular basis, and I don't.

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

#218

Post by greglindahl » Wed, Jan 31, 2018, 7:10 AM UTC

euos wrote: post #35

ryanmarsh wrote: post #22

Earlier quoted context omitted.

Based upon momentum I believe the Electron based ecosystem has already won, yes. The momentum there eclipses... Eclipse, as well as many other closed and open source editors. If you don't see the Electron ecosystem as a winner today would you say they'll have won if all editors stay at their current momentum of new features and bug fixes?

10 years ago Eclipse was most popular editor and was considered the best. Java, C++, PHP. Aptana, IBM IDEs and many more. And now it is pretty much gone.

10 years ago everyone at my startup used emacs or vi.

Today those same engineers still use emacs or vi.

Did I miss something?

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

#219

Post by kokey » Wed, Jan 31, 2018, 7:14 AM UTC

hultner wrote: post #149

acoard wrote: post #144

Earlier quoted context omitted.

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…

I’d say it’s the opposite as an die hard tmux-user. I don’t really use the integration since I’m more comfortable with my terminal in full screen and my own tmux config. The integration services seems more appropriate for someone who doesn’t already have their tmux-bindings and workflow stamped into muscle memory but rather just want the benefits of detaching their terminal sessions from their terminal application wh…

I'm the same, but with screen. I usually have an iTerm2 tab for each screen session. I have a screen session on a work machine and one on a personal machine, each usually with close to 10 virtual terminals. I connect to both with mosh. I haven't seen a compelling reason for me to switch to tmux, yet.

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

#220

Post by drewm1980 » Wed, Jan 31, 2018, 7:40 AM UTC

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.

You made a decision to focus on GPU rendering for now. Do you think that architectural decision will impede high performance software rendering as a fallback?

Hardware rendering routinely breaks in Ubuntu (and probably other distros) because NVIDIA's driver still isn't packaged well enough to survive a kernel update, and doesn't work over ssh or on an many embedded systems anyway.