4 ms·

Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "sim

Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance. Maybe text editors with an extensible feature set really are more complex than we've been led to believe?

tomc1985 9y ago
A longer version of my first comment originally admitted that Notepad's tech stack probably looks a lot like Xray's.... But then I would bet the Notepad engineers didn't wag their dicks on a blog post telling the world how special they are because they figured out how to make the Win32 message pump performant.... I'm happy they're finally treating Electron performance seriously... oh wait, they aren't! Just writing the hard parts in Rust instead :/ It would seem Electron adds far more complexity to projects than its adopters are lead to believe. Perhaps I am biased against Electron and web-tech-on-the-desktop but there are far better ways to skin this particular cat, to say nothing of the fact that it has already been skinned a thousand times before. Does the world really need another extensible text editor?
- lpghatguy 9y ago
  Editing large pieces of text efficiently is a Hard Problem, especially collaboratively without conflicts. In the case of editors like Xi and XRay, they use CRDTs, which doesn't look anything like how Notepad would represent text. There's real work here that's actually useful, it's not just "another extensible text editor".
  - tomc1985 9y ago
    Yay, new products for a few bulletpoint features. Not to discount the technical chops of the work they are doing, CRDTs sound sufficiently fancy. But as long as it touches Electron, they are building on a foundation of mud. Popular, pretty mud, sure, but mud nonetheless.
    - moosingin3space 9y ago
      See, I thought you were complaining about software complexity when you posted your original comment about "why does a text editor need so much abstraction". Nope, turns out it's just another run-of-the-mill anti-Electron rant.
  - redspectre 9y ago
    If you really need to collaborate on the same file, can't you just share a session in tmux?
  - jachee 9y ago
    I have never, even once, in my nearly-20-year career had the desire to collaboratively edit a single, specific text file. Isn't collaboration without conflicts what version control systems are made to do?
    - codedokode 9y ago
      I even think it would be annoying if someone would just move cursor around when I edit something. And there definitely would be conflicts if they would try to edit the file at the same time. Who needs this feature?
      - tomc1985 9y ago
        Google Docs gives everyone their own cursors
      - catach 9y ago
        The way it generally works is that each user has their own cursor.
    - skybrian 9y ago
      Proof by personal experience isn't all that convincing. Maybe you've never done pair programming, but other people have.
- bluedino 9y ago
  >> Does the world really need another extensible text editor? People said that when Sublime was released
- zrb05293 9y ago
  Ahaha hahahahaha ‘wag their dicks..’ hahahahah
bluedino 9y ago
What's the memory footprint of Terminal.app and vim + plug-ins?
- Prefinem 9y ago
  Not sure, but I have had vim lock up my MacBook Pro with 16GB of RAM and force me to do a hard reboot
  - PrimHelios 9y ago
    That sounds like an OS/hardware problem, honestly. There's no reason vim with any setup should lock up a machine.
    - Prefinem 9y ago
      The linter was the issue. I actually have better performance with Sublime Text and JavaScript than I do with vim and JavaScript. I wish that weren’t the case. If you know if any better ways to get vim working with Syntastic for linting (eslint), I would love to know.
      - dkns 9y ago
        Switch syntastic for ale: https://github.com/w0rp/ale https://github.com/w0rp/ale It's asynchronous if you're running vim8+
        Prefinem 9y ago
        Awesome, thanks for this!
      - tomc1985 9y ago
        Agreed, if anything will slog a text editor it is usually the linter Also, you can choke vim with large (>5gb) test files. Or is that fixed now?
boomlinde 9y ago
Messy and simple are orthogonal characteristics. A terminal is simple in that cursor movement, colors and style are all the result of a bunch of escape sequences. Once you have a list of the escape sequences you want to parse or emit, implementing a terminal or an application targeting the terminal is not hard. It's messy because there are historically a bunch of different terminals that implement different escape sequences. It's not easy and it's not clean and beautiful, but it's still simple. It's a bit weird to bring up scripting languages. The problem is that people want a customizable and scriptable editor. Solving that problem by providing a script language to its users is not overengineering, it's simply meeting a demand. Looking at this, it uses some native facilities simply to setup a web browser view. Within that, it doesn't even use the built-in functionality of a browser to render the text you're editing, but resorts to custom rendering and layout using webgl. This isn't simple or clean. It's a convoluted waste of resources in that regard. Why not use one of the smaller cross-platform OpenGL wrappers? Maybe it'll be a fine editor, but it's much more complex than it needs to be. I guess that because they set a "Web-compatible build artifact" as a goal on the roadmap, it makes sense, but is that really an interesting goal? What problems will be solved once the editor is a tab in Chrome?

tomc1985 9y ago

A longer version of my first comment originally admitted that Notepad's tech stack probably looks a lot like Xray's.... But then I would bet the Notepad engineers didn't wag their dicks on a blog post telling the world how special they are because they figured out how to make the Win32 message pump performant.... I'm happy they're finally treating Electron performance seriously... oh wait, they aren't! Just writing the hard parts in Rust instead :/ It would seem Electron adds far more complexity to projects than its adopters are lead to believe. Perhaps I am biased against Electron and web-tech-on-the-desktop but there are far better ways to skin this particular cat, to say nothing of the fact that it has already been skinned a thousand times before. Does the world really need another extensible text editor?

lpghatguy 9y ago
Editing large pieces of text efficiently is a Hard Problem, especially collaboratively without conflicts. In the case of editors like Xi and XRay, they use CRDTs, which doesn't look anything like how Notepad would represent text. There's real work here that's actually useful, it's not just "another extensible text editor".
- tomc1985 9y ago
  Yay, new products for a few bulletpoint features. Not to discount the technical chops of the work they are doing, CRDTs sound sufficiently fancy. But as long as it touches Electron, they are building on a foundation of mud. Popular, pretty mud, sure, but mud nonetheless.
  - moosingin3space 9y ago
    See, I thought you were complaining about software complexity when you posted your original comment about "why does a text editor need so much abstraction". Nope, turns out it's just another run-of-the-mill anti-Electron rant.
- redspectre 9y ago
  If you really need to collaborate on the same file, can't you just share a session in tmux?
- jachee 9y ago
  I have never, even once, in my nearly-20-year career had the desire to collaboratively edit a single, specific text file. Isn't collaboration without conflicts what version control systems are made to do?
  - codedokode 9y ago
    I even think it would be annoying if someone would just move cursor around when I edit something. And there definitely would be conflicts if they would try to edit the file at the same time. Who needs this feature?
    - tomc1985 9y ago
      Google Docs gives everyone their own cursors
    - catach 9y ago
      The way it generally works is that each user has their own cursor.
  - skybrian 9y ago
    Proof by personal experience isn't all that convincing. Maybe you've never done pair programming, but other people have.
bluedino 9y ago
>> Does the world really need another extensible text editor? People said that when Sublime was released
zrb05293 9y ago
Ahaha hahahahaha ‘wag their dicks..’ hahahahah

bluedino 9y ago

What's the memory footprint of Terminal.app and vim + plug-ins?

Prefinem 9y ago
Not sure, but I have had vim lock up my MacBook Pro with 16GB of RAM and force me to do a hard reboot
- PrimHelios 9y ago
  That sounds like an OS/hardware problem, honestly. There's no reason vim with any setup should lock up a machine.
  - Prefinem 9y ago
    The linter was the issue. I actually have better performance with Sublime Text and JavaScript than I do with vim and JavaScript. I wish that weren’t the case. If you know if any better ways to get vim working with Syntastic for linting (eslint), I would love to know.
    - dkns 9y ago
      Switch syntastic for ale: https://github.com/w0rp/ale https://github.com/w0rp/ale It's asynchronous if you're running vim8+
      - Prefinem 9y ago
        Awesome, thanks for this!
    - tomc1985 9y ago
      Agreed, if anything will slog a text editor it is usually the linter Also, you can choke vim with large (>5gb) test files. Or is that fixed now?

boomlinde 9y ago

Messy and simple are orthogonal characteristics. A terminal is simple in that cursor movement, colors and style are all the result of a bunch of escape sequences. Once you have a list of the escape sequences you want to parse or emit, implementing a terminal or an application targeting the terminal is not hard. It's messy because there are historically a bunch of different terminals that implement different escape sequences. It's not easy and it's not clean and beautiful, but it's still simple. It's a bit weird to bring up scripting languages. The problem is that people want a customizable and scriptable editor. Solving that problem by providing a script language to its users is not overengineering, it's simply meeting a demand. Looking at this, it uses some native facilities simply to setup a web browser view. Within that, it doesn't even use the built-in functionality of a browser to render the text you're editing, but resorts to custom rendering and layout using webgl. This isn't simple or clean. It's a convoluted waste of resources in that regard. Why not use one of the smaller cross-platform OpenGL wrappers? Maybe it'll be a fine editor, but it's much more complex than it needs to be. I guess that because they set a "Web-compatible build artifact" as a goal on the roadmap, it makes sense, but is that really an interesting goal? What problems will be solved once the editor is a tab in Chrome?