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

281–290 of 306 posts

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

#281

Post by kllrnohj »

IshKebab wrote: post #245
kllrnohj wrote: post #157

Earlier quoted context omitted.

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.

"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 worth the work to avoid this anyway, after all faster is better if you're an engine/renderer, but it takes a lot for it to be an actual _problem_

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

#282

Post by leshow »

latexr wrote: post #256
MaxBarraclough wrote: post #242

Earlier quoted context omitted.

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.

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.

scoff how dare you use a mouse. In urxvt I have it mapped to ctrl+u

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

#283

Post by NoahTheDuke »

erikb wrote: post #272
RandomCSGeek wrote: post #253

Earlier quoted context omitted.

They say it's pronounced "Zigh". I am a non-native English speaker, so I am not even going to try to question this.

Thanks. However "z" is also not really a clear sound, right? "ds" or "ssss" or "tsss". Naturally I would interpret "zigh" very similar to "sigh" but since "sigh" is a real thing I think there is a reason why you write "zigh" instead. Anyway each hint is helpful. I'll google for that.

To help out, let me point you to the English phonology page on wikipedia: https://en.wikipedia.org/wiki/English_phonology . Specifically, look into the 'Voiced alveolar sibilant', the 'z' in English. That's the sound you're looking for, as it's the one used by Raph in the linked talk.

For completeness, the vowel is the dipthong 'aɪ', pronounced like the 'i' in the word 'price', discussed on the same wiki page.

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

#284

Post by bhoeting »

neoncontrails wrote: post #188
bhoeting wrote: post #169

Earlier quoted context omitted.

I tried it after reading this comment. You weren't kidding. Unfortunately, my Vim isn't rendering properly. About 10 lines in the middle of the screen are blank for some reason. Both in and out of Tmux. Oh well. I'm just happy that I can look forward to Metal rendering being merged into stable.

Not sure if it's the same issue I had recently with iTerm2 periodically going black, but consider disabling the Core Text renderer with the following command: $ defaults write org.vim.MacVim MMUseCGLayerAlways -bool YES This was the developers' suggestion and it solved my issue. There's an informative discussion of the root causes here: https://github.com/macvim-dev/macvim/issues/557 .

Hmm, that didn't see to work for me. I think I have a different issue. Thanks, though!

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

#286

Post by jhasse »

rdrey wrote: post #273
MaxBarraclough wrote: post #242

Earlier quoted context omitted.

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.

The killer feature for me was setting an "alarm" on a currently running process and getting a notification when it finished. It's not something I've seen in any other terminal. (Using Ubuntu now and missing it.)

Fedora has this, too.

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

#287

Post by haskal »

MaxBarraclough wrote: post #242
TheAceOfHearts wrote: post #221

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

1. When you exit a terminal it dumps irrelevant stuff rather than just closing the tab.

    ~ % exit 
    
    [Process completed]
2. Cmd + Arrow doesn't doesn't move to the next or last tab. (Cmd + number does work however, but it doesn't show numbers on the tab list like iTerm)

3. Comes with terrible defaults like the screen color.

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

#288

Post by [deleted] »

greglindahl wrote: post #217
alkonaut wrote: post #214

Earlier quoted context omitted.

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.

[deleted]

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

#289

Post by greglindahl »

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…

Hey, you edited your comment to remove what I responded to. Thanks for not labeling the edit.

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

#290

Post by alkonaut »

greglindahl wrote: post #217
alkonaut wrote: post #214

Earlier quoted context omitted.

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.

ok :)

My point was that if you want the best plugin (not good enough) then the editor must vary.

And secondly, if you do stick with one editor it’s surely one of those biggest ones as otherwise the chance is slim of even finding half decent plugins.

Post reply on HN