3 ms·

Text editing is a solved problem. It's not about the style of cursor, or if rope is used or not. We already have answers to that. It's about remote editing, L

Text editing is a solved problem. It's not about the style of cursor, or if rope is used or not. We already have answers to that. It's about remote editing, LSP support.

boxed 1mo ago
You can prompt yourself all the way to that. I don't have remote editing in my custom IDE because I never need that personally, but LSP/DSP, syntax highlighting, a built-in lazygit clone, git blame, soft wrap, find-in-files, etc all there: https://github.com/boxed/TurboKod https://github.com/boxed/TurboKod
- self_awareness 1mo ago
  By "LSP support" I didn't mean "editor should call this API over HTTP and interpret whatever LSP server responds". It's a lot more than that, and LSP support in editors if often times broken. It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP. For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.
  - boxed 1mo ago
    Hmm. I guess there needs to be some kind of general test suite editors and LSPs can validate against?
    - artyomsv 1mo ago
      [dead]
rfgplk 1mo ago
> Text editing is a solved problem. Not even close. Obvious from the fact that about >90% of text editors out there have visible _lag_ when inputting or modifying text. Visible _LAG_. (see emacs, nvim in certain configurations, vscode, sublime, etc) A text editor should be running at DRAM read/write speeds nowadays (amortized), which effectively means that any form of edits you do should be imperceptible to you.
- Mashimo 1mo ago
  And then there is me, working on large java codebase with IDEA through remote desktop on wifi, on a 7 year old windows laptop that is slowed down by corporate crap.
- self_awareness 1mo ago
  https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ It only means that >90% of text editors use the wrong UI toolkit for the job. We already had faster editors on the Amiga 500 (CygnusEd) than we have now. The fact that we don't have them now is that we regressed. We had it, and we lost it. It's an entirely different matter from not knowing how to do it!
- tmtvl 1mo ago
  I use Emacs and the edits I do seem imperceptible to me. Do you know of any test I should try to see whether the lag is notable and intrusive? Emacs does start fairly slowly, though, takes about 0.6 seconds.
  - self_awareness 1mo ago
    I would love to see your config!
    - tmtvl 1mo ago
      I'll try to remember to put it on Codeberg, though it's a little bloated and idiosyncratic (that means 'made by an idiot', right?).

Text editing is a solved problem. It's not about the style of cursor, or if rope is used or not. We already have answers to that. It's about remote editing, LSP support.

boxed 1mo ago

You can prompt yourself all the way to that. I don't have remote editing in my custom IDE because I never need that personally, but LSP/DSP, syntax highlighting, a built-in lazygit clone, git blame, soft wrap, find-in-files, etc all there: https://github.com/boxed/TurboKod https://github.com/boxed/TurboKod

self_awareness 1mo ago
By "LSP support" I didn't mean "editor should call this API over HTTP and interpret whatever LSP server responds". It's a lot more than that, and LSP support in editors if often times broken. It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP. For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.
- boxed 1mo ago
  Hmm. I guess there needs to be some kind of general test suite editors and LSPs can validate against?
  - artyomsv 1mo ago
    [dead]

rfgplk 1mo ago

> Text editing is a solved problem. Not even close. Obvious from the fact that about >90% of text editors out there have visible _lag_ when inputting or modifying text. Visible _LAG_. (see emacs, nvim in certain configurations, vscode, sublime, etc) A text editor should be running at DRAM read/write speeds nowadays (amortized), which effectively means that any form of edits you do should be imperceptible to you.

Mashimo 1mo ago
And then there is me, working on large java codebase with IDEA through remote desktop on wifi, on a 7 year old windows laptop that is slowed down by corporate crap.
self_awareness 1mo ago
https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ It only means that >90% of text editors use the wrong UI toolkit for the job. We already had faster editors on the Amiga 500 (CygnusEd) than we have now. The fact that we don't have them now is that we regressed. We had it, and we lost it. It's an entirely different matter from not knowing how to do it!
tmtvl 1mo ago
I use Emacs and the edits I do seem imperceptible to me. Do you know of any test I should try to see whether the lag is notable and intrusive? Emacs does start fairly slowly, though, takes about 0.6 seconds.
- self_awareness 1mo ago
  I would love to see your config!
  - tmtvl 1mo ago
    I'll try to remember to put it on Codeberg, though it's a little bloated and idiosyncratic (that means 'made by an idiot', right?).