5 ms·

Huh, apparently Xi is actually a Google project? I didn't realize anyone at Google was even touching Rust. https://github.com/google/xi-editor https://github.c

by eridius 10y ago

Huh, apparently Xi is actually a Google project? I didn't realize anyone at Google was even touching Rust. https://github.com/google/xi-editor https://github.com/google/xi-editor Edit: Well, not actually an official Google project, but it's still on their GitHub account. The last line of the README says > This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

sooheon 10y ago
> The editor should never, ever block and prevent the user from getting their work done. A thousand times this. Emacs and vim are both guilty of failing this most basic principle. It frustrates me to no end that a text editor will hang while font locking text, or printing repl results.
- qwertyuiop924 10y ago
  ...I have never had that problem. Well, okay. I did once. But still, it's uncommon.
  - sooheon 10y ago
    Maybe eval'ing to the repl is almost a tic of mine. But as a contrived example, (range 100000) is instantaneous in a clojure repl in the terminal, and interminably slow in cider (emacs package for clojure). There's also SO questions like this[1], and I've personally come across it a lot as well. Anytime lines get long emacs grinds to a halt. [1]: http://emacs.stackexchange.com/questions/598/how-do-i-prevent-extremely-long-lines-making-emacs-slow http://emacs.stackexchange.com/questions/598/how-do-i-preven...
    - qwertyuiop924 10y ago
      Huh. That might be a problem with CIDER, because it never happens to me with Geiser.
      - sooheon 10y ago
        Geiser might just be adding a lot more newlines by default. There is a setting in CIDER to pretty print everything, which alleviates the issue. The core problem is emacs is terrible at displaying/wrapping/navigating/editing long lines.
        qwertyuiop924 10y ago
        No, it isn't. So maybe my configuration is different? Or maybe the lines aren't long enough. Because it's usually no problem. The one time it was a problem was when emacs decided to randomly coredump.
        quotemstr 10y ago
        > The one time it was a problem was when emacs decided to randomly coredump. Please report these issues.
        qwertyuiop924 10y ago
        I will do that. However, I'll have to do it next time (if there is one). The core file is missing, the circumstances were vague, and I can't reproduce.
- daenney 10y ago
  A lot of what used to cause trouble for Vim was fixed with Neovim and the new async stuff Vim 8 introduced. This mainly ensures plugins don't have to block (though a lot still do). That said, there's still parts of Vim that don't benefit from this and especially on large files can get annoying. But since switching to Neovim I've had a significant drop in the amount of times I have to wait for vim to do something and sit there screaming "oh come on" at my monitor.
busterarm 10y ago
...And I just found the Rust project I want to get my hands dirty on...
AceJohnny2 10y ago
Interesting. For me the killer feature of Emacs is its customizability. That's not quite the right word, because Emacs's integration with ELisp lets you do things that almost nothing else does. The ability to modify existing functions live is central to its power, and the boundary between "The Editor" and "Extensions" is extremely fuzzy. Xi seems to take a harder approach to customization, which means that customizers will always be subject to the limitations of the plug-in interface. There will always be a hard boundary between "The Editor" and "Extensions", and I believe that will ultimately limit its usefulness.
- eridius 10y ago
  Modifying existing functions sounds like a recipe for plugin incompatibilities. Vim doesn't let you modify any built-in functions but it seems to be just as powerful.
  - AceJohnny2 10y ago
    Indeed, architecturally it's just asking for trouble. However it also lets user extend the system in ways that aren't previously planned for. Pros and cons...
    - agumonkey 10y ago
      Am sure all emacs lisp students have had the pleasure to kill it because they rewrote eval without realizing the implications.
- sooheon 10y ago
  I agree with you. Having tasted the emacs way, I'm constantly frustrated (actually I just simply avoid) by interactions with software that isn't so inspectable, and malleable. Still, never blocking user input is a respectable goal for an editor, and a design philosophy I wish emacs would seriously pursue. I would not mind a "feature" freeze on emacs for the remainder of the decade if it meant absolute responsive editing with asynchronous operations.
- agumonkey 10y ago
topspin 10y ago
> I didn't realize anyone at Google was even touching Rust. There is also TensorFlow Rust written primarily by Adam Crume at Google. https://github.com/tensorflow/rust https://github.com/tensorflow/rust Actually, the following /google repos are all Rust: xi-editor, pulldown-cmark, hat-backup, rspirv, tarpc, rustcxx, font-rs and rust-multihash.

by eridius 10y ago

sooheon 10y ago

> The editor should never, ever block and prevent the user from getting their work done. A thousand times this. Emacs and vim are both guilty of failing this most basic principle. It frustrates me to no end that a text editor will hang while font locking text, or printing repl results.

qwertyuiop924 10y ago
...I have never had that problem. Well, okay. I did once. But still, it's uncommon.
- sooheon 10y ago
  Maybe eval'ing to the repl is almost a tic of mine. But as a contrived example, (range 100000) is instantaneous in a clojure repl in the terminal, and interminably slow in cider (emacs package for clojure). There's also SO questions like this[1], and I've personally come across it a lot as well. Anytime lines get long emacs grinds to a halt. [1]: http://emacs.stackexchange.com/questions/598/how-do-i-prevent-extremely-long-lines-making-emacs-slow http://emacs.stackexchange.com/questions/598/how-do-i-preven...
  - qwertyuiop924 10y ago
    Huh. That might be a problem with CIDER, because it never happens to me with Geiser.
    - sooheon 10y ago
      Geiser might just be adding a lot more newlines by default. There is a setting in CIDER to pretty print everything, which alleviates the issue. The core problem is emacs is terrible at displaying/wrapping/navigating/editing long lines.
      - qwertyuiop924 10y ago
        No, it isn't. So maybe my configuration is different? Or maybe the lines aren't long enough. Because it's usually no problem. The one time it was a problem was when emacs decided to randomly coredump.
        quotemstr 10y ago
        > The one time it was a problem was when emacs decided to randomly coredump. Please report these issues.
        qwertyuiop924 10y ago
        I will do that. However, I'll have to do it next time (if there is one). The core file is missing, the circumstances were vague, and I can't reproduce.
daenney 10y ago
A lot of what used to cause trouble for Vim was fixed with Neovim and the new async stuff Vim 8 introduced. This mainly ensures plugins don't have to block (though a lot still do). That said, there's still parts of Vim that don't benefit from this and especially on large files can get annoying. But since switching to Neovim I've had a significant drop in the amount of times I have to wait for vim to do something and sit there screaming "oh come on" at my monitor.

busterarm 10y ago

...And I just found the Rust project I want to get my hands dirty on...

AceJohnny2 10y ago

Interesting. For me the killer feature of Emacs is its customizability. That's not quite the right word, because Emacs's integration with ELisp lets you do things that almost nothing else does. The ability to modify existing functions live is central to its power, and the boundary between "The Editor" and "Extensions" is extremely fuzzy. Xi seems to take a harder approach to customization, which means that customizers will always be subject to the limitations of the plug-in interface. There will always be a hard boundary between "The Editor" and "Extensions", and I believe that will ultimately limit its usefulness.

eridius 10y ago
Modifying existing functions sounds like a recipe for plugin incompatibilities. Vim doesn't let you modify any built-in functions but it seems to be just as powerful.
- AceJohnny2 10y ago
  Indeed, architecturally it's just asking for trouble. However it also lets user extend the system in ways that aren't previously planned for. Pros and cons...
  - agumonkey 10y ago
    Am sure all emacs lisp students have had the pleasure to kill it because they rewrote eval without realizing the implications.
sooheon 10y ago
I agree with you. Having tasted the emacs way, I'm constantly frustrated (actually I just simply avoid) by interactions with software that isn't so inspectable, and malleable. Still, never blocking user input is a respectable goal for an editor, and a design philosophy I wish emacs would seriously pursue. I would not mind a "feature" freeze on emacs for the remainder of the decade if it meant absolute responsive editing with asynchronous operations.
agumonkey 10y ago

topspin 10y ago

> I didn't realize anyone at Google was even touching Rust. There is also TensorFlow Rust written primarily by Adam Crume at Google. https://github.com/tensorflow/rust https://github.com/tensorflow/rust Actually, the following /google repos are all Rust: xi-editor, pulldown-cmark, hat-backup, rspirv, tarpc, rustcxx, font-rs and rust-multihash.