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

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

#301

Post by latexr » Fri, Feb 02, 2018, 6:12 PM UTC

bluerobotcat wrote: post #260

latexr wrote: post #256

Earlier quoted context omitted.

Probably not a big feature for most, but I work with URLs in the terminal a lot and ⌘+click to immediately open them in the browser is convenient. I prefer to open a new Terminal only when I need it instead of keeping one open all day (even if that sometimes happens) and I’ve never noticed an increase in CPU usage that’d made me want to check.

Terminal.app does that too

You have to double-click and pressing ⌘ gives no visual feedback. That explains why I didn’t find it before. Thank you for the tip.

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

#302

Post by lenkite » Fri, Feb 02, 2018, 7:15 PM UTC

vlovich123 wrote: post #164

amelius wrote: post #29

Earlier quoted context omitted.

Nice talk! I wonder, in the talk you say that you took some ideas from the design of Chrome; do you think that --in turn-- browsers could learn from the concepts in Xi? And another question: you are using multiple languages. Doesn't that make it needlessly difficult to express the same operations in different (concurrent) parts of the system? E.g. a character update is rendered on the screen (in Swift), and simultane…

I'm still learning the architecture but my understanding is that the way it works is that the frontend sends the character to the backend which incorporates it into the model & then generates a notification back to the front-end via the regular delta diff algorithm. The front-end then applies this delta to its data structures that represent the view & updates the rendering. All of this turns out to be super quick bec…

Well lots of little modifications being done quickly is what we use macros in vi/emacs for. However, I guess this can be solved by the frontend batching.

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

#303

Post by imron » Sat, Feb 03, 2018, 8:33 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.

I don't even know any C++ programmers who thought Eclipse was a good editor, let alone the best.

That Eclipse is now pretty much gone only strengthens that position.

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

#304

Post by IshKebab » Sat, Feb 03, 2018, 11:11 PM UTC

kllrnohj wrote: post #281

IshKebab wrote: post #245

Earlier quoted context omitted.

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.

"hundreds" is actually what I meant by insignificant to a modern driver. For example: https://images.anandtech.com/graphs/graph11223/86100.png Granted that's a 1060 but since we're looking at driver CPU overhead that shouldn't matter much. So 2.3 million draw calls per second in DX11 single threaded. It's not until you start getting into the 10k+ draw calls a frame that you are putting your 60fps at risk. It's often…

Yeah, so 2 million, cut that down by 10 for integrated graphics. Then you need 60 fps, that brings it down to 3000. If you're just doing empty draw calls and nothing else. Throw in WebGL and hundreds is really significant.

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

#305

Post by dmytrish » Mon, Feb 05, 2018, 5:01 PM UTC

eropple wrote: post #297

dmytrish wrote: post #295

Earlier quoted context omitted.

I don't use panes much, but Terminal.app seems to have panes too.

- Bafflingly, they split horizontally. I have a 4x4 pane setup, but my default is 2x1. - Cmd-W closes the window, not the pane. (I get why they do this. I feel that it is wrong.) - I can't send input to all panes, which is a pretty useful feature I probably use once a week. - iTerm2 happily maps my panes to tmux. This is by itself perhaps a killer feature.

Thanks! I feel the same about "tmux vs screen": tmux panes are just so much easier to use and more flexible than in screen, even though screen can split windows).

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

#306

Post by vlovich123 » Wed, Feb 14, 2018, 6:57 PM UTC

lenkite wrote: post #302

vlovich123 wrote: post #164

Earlier quoted context omitted.

I'm still learning the architecture but my understanding is that the way it works is that the frontend sends the character to the backend which incorporates it into the model & then generates a notification back to the front-end via the regular delta diff algorithm. The front-end then applies this delta to its data structures that represent the view & updates the rendering. All of this turns out to be super quick bec…

Well lots of little modifications being done quickly is what we use macros in vi/emacs for. However, I guess this can be solved by the frontend batching.

Macros seem to me like they would be trivially batch-able unless they're capturing actions outside the editor that might impact it. Even then, I suspect the performance won't be a huge issue. Remote applications are probably the bigger concern but I suspect the proposed model of running 2 core instances (1 local & 1 remote) & just synchronizing the state between them directly will work better than just trying to connect the frontend to a remote core instance.