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

181–190 of 306 posts

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

#181

Post by kakarot »

yla92 wrote: post #177
kakarot wrote: post #172

Earlier quoted context omitted.

This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google Would you mind elaborating on this?

not the op. just my understanding is that it is raphlinus's code. It means Google has literally nothing to do with it, other than happening to own the code. (IE it's not an experimental product, it's not a product at all. It's just raphlinus releasing some code)

You repeated the phrase different words.

The question begged is Why does Google own the code?

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

#182

Post by raphlinus »

gnachman wrote: post #170
vlovich123 wrote: post #161

Earlier quoted context omitted.

There's caching all over the place so that you don't end up redoing the expensive stuff (ie creating attributed strings & CTLineRefs). It seems to work pretty well in terms of maintaining 60fps.

Caching is great but it doesn’t help you when paging through a big file where the entire screen contents get replaced on each update. Is that not what you benchmark?

That is correct. I'm measuring scrolling at low to medium speeds, where the majority of the text hasn't changed (this also corresponds to most editing tasks). I don't want to make the claim that I'm keeping up when scrolling at very high speeds. I think my assumptions are reasonable for an editor, but for a terminal scrolling at high speed is much more common. I have certainly considered fast-pathing monospaced font rendering (it would certainly be easy in the current architecture, and in fact we're doing that for the gutter numbers), but it hasn't seemed absolutely necessary, and going forward I want to make sure that rich text and i18n aren't treated as second class wrt code.

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

#183

Post by dikaiosune »

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…

The author of alacritty suggests that there's an IPC performance issue with tmux/nvim on macOS: https://github.com/jwilm/alacritty#faq

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

#184

Post by jnordwick »

ryanmarsh wrote: post #14

Xi looks great, has a very clever design, and clearly is a next generation platform for building a useful and powerful editor. I'd love to see this project continue and be a success. I think there is plenty of room for yet another text editor. Here's where I'm going to be a bit of a party pooper. Pragmatically speaking all of the great stuff Raph is talking about doesn't really matter. What Raph cares about are the k…

Dear HN users,

Please stop voting down comments you disagree with when they are clearly written well and express an coherent opinion. Realize that you may not always be correct, or even if you think something is wrong, it can still deserve tobe at the top of the page.

I have to scroll to the bottom and highlight the comment because it is so greyed out (I'm guessing it is sitting below -4).

Diversity of constructive opinion is important to site quality.

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

#185

Post by Myrmornis »

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…

Exactly. For people who already use tmux heavily, and use it on linux as well as macos, the iterm2 integration isn’t going to be an attractive direction. Partly because it will lose the uniform experience across OSs, and partly because they’re happy with session/window/pane management using tmux’s UI.

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

#186

Post by eadmund »

FullyFunctional wrote: post #151
zeveb wrote: post #137

Earlier quoted context omitted.

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

> 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 fact, I have 'vi' aliased to 'emacsclient -t' these days for just that reason. It's awesome to have a powerful, extensible editor available in the terminal.

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

#187

Post by eadmund »

jjrh wrote: post #94
sgillen wrote: post #52

Earlier quoted context omitted.

Even emacs is not installed by default on most operating systems. Even worse a lot of people customize their emacs setup so much that using the default setting can be painful.

A emacs-tiny would be nice. Emacs package is just too large to be a default. On servers I usually just install mg/zile/jed.

> On servers I usually just install mg/zile/jed.

I normally just use TRAMP. For those who've not used it, it's an incredible little emacs package which gives one a very Plan-9-esque feeling, in the sense that all the different systems one connects to feel like one whole.

As an example, when one is editing a remote file shell-command runs commands on the remote system, and of course find-file and friends work exactly like normal — only looking at files on the remote system.

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

#188

Post by neoncontrails »

bhoeting wrote: post #169
Philipp__ wrote: post #32

Earlier quoted context omitted.

Wow, just gave iTerm2 Nightly with Metal renderer a spin! Holy shiet it's fast and smooth! FINALY! Opened 20k C file in Vim (stock vim 8 that comes with macOS High Sierra), pushed that scroll down and let it roll, it was soooo smooth! Amazing!

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.

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

#189

Post by eadmund »

pnathan wrote: post #21

> Separation into front-end and back-end modules. That solves a lot of the Emacs trouble iiuc. (Same for the Async first design). > The xi editor will communicate with plugins through pipes, letting them be written in any language, That's caused a lot of trouble for vi/vim, has it not? I get the separation of concerns, but intermingling the concerns has helped emacs in a certain way.

> > Separation into front-end and back-end modules.

> That solves a lot of the Emacs trouble iiuc.

True enough. Despite the fact that it's IMNSHO the best editor out there, emacs is not without its problems. It has a lot of historical baggage.

> I get the separation of concerns, but intermingling the concerns has helped emacs in a certain way.

I agree. One of the huge features of emacs is that (above a very low level) everything is implemented in a fairly decent Lisp, and everything is available to Lisp code. How much will plugins be able to dig into one anothers' internals in order to get work done? Yes, monkey-patching is bad — but it's better than not being able to monkey-patch. Relying on plugin authors to expose extension points is probably not going to work in the long run: it really helps being able to define advice on functions, wrap functions, replace functions, mutate internal variables when one knows what one's doing &c.

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

#190

Post by kyrra »

kakarot wrote: post #181
yla92 wrote: post #177

Earlier quoted context omitted.

not the op. just my understanding is that it is raphlinus's code. It means Google has literally nothing to do with it, other than happening to own the code. (IE it's not an experimental product, it's not a product at all. It's just raphlinus releasing some code)

You repeated the phrase different words. The question begged is Why does Google own the code?

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 really hard to do for many projects, it's easier to just let Google keep copyright ownership of it and have it opensource under them.

[0] https://opensource.google.com/docs/releasing/

[1] https://opensource.google.com/docs/iarc/

Post reply on HN