5 ms·

It's confusing you're replying to two different threads in this > For my own part I'm fine with falling back > That's perfectly fine. That's for you. I want t

by Ygg2 5y ago

It's confusing you're replying to two different threads in this > For my own part I'm fine with falling back > That's perfectly fine. That's for you. I want to open a huge XML file and edit it with autocomplete. I mean you could just say. I'm ok with Notepad. Ok. Sure. I'm not. > My editor uses just a plain array of lines represented as strings. Any naive approach is going to run into edge cases quickly[1]. Any more sophisticated approach is going to run into performance issues. > It will break horribly on huge files. I suspect it will break waaaay before that. Even using some language with greater complexity would cause issues. [1] For example using regex to color syntax. Reasonably fast yes, but fails in any moderately complex scenario.

vidarh 5y ago
> It's confusing you're replying to two different threads in this I get that, which is why I specified what it was I had replied to in order to clear it up. > That's for you. I want to open a huge XML file and edit it with autocomplete. That's fine. My editor is for me, not for you. To me, if you have to do bracket matching on a 2GB XML file an editor is the wrong tool. I'd work with that in a REPL. But that's me. You're totally free to pick your editor based on the need to handle 2GB files, just as I'm free not care one iota about opening 2GB files. Hence my point that a lot of people don't seem to think about whether or not they actually need this. I decided I don't need it, and it let me simplify things a lot. It won't work for everyone, and that's fine. > I mean you could just say. I'm ok with Notepad. Ok. Sure. I'm not. Well, if I'd been ok with notepad, I'd have used notepad. I wrote my own editor because I'm not ok with Notepad. Or Emacs. The tradeoffs I care about are very different. > Any naive approach is going to run into edge cases quickly[1]. Any more sophisticated approach is going to run into performance issues. For large files, yes. It's more than fast enough to run just fine - even in pure Ruby - on files of the sizes I pointed out are the sizes I've decided I care about. > [1] For example using regex to color syntax. Reasonably fast yes, but fails in any moderately complex scenario. Which is why I'm using Rouge for the syntax-highlighting for my editor. It uses Regex for low level lexing where people choose to, but it supports state machines and multi-layered lexing or your own custom code. It supports all the languages I care about and dozens more just fine. My approach of caching the lexer state works just fine with Rouge and the approach I've outlined to e.g. parse my Ruby code with a precise Ruby mode, switch to a Markdown mode inside comment blocks, and feed the output of that into a layer that applies further custom rules based on my preferences. All without needing to build an AST for any of those. > I suspect it will break waaaay before that. Even using some language with greater complexity would cause issues. It handles every language supported by Rouge [1] just fine, and that's far more than I have need for. [1] https://github.com/rouge-ruby/rouge/blob/master/docs/Languages.md https://github.com/rouge-ruby/rouge/blob/master/docs/Languag...
- Ygg2 5y ago
  > That's fine. My editor is for me, not for you. To me, if you have to do bracket matching on a 2GB XML file an editor is the wrong tool. I'd work with that in a REPL. But that's me. You're totally free to pick your editor based on the need to handle 2GB files, just as I'm free not care one iota about opening 2GB files. Ok. But tbh I hate REPLs and/or CLI. Text is just better served by a visual text editor. Then you can't really compare something for general use case to something used for you. > Which is why I'm using... It was an example how naive approaches failed. Your personal editor doesn't particularly interests me.
  - vidarh 5y ago
    My point was exactly that it's not necessary for every editor to aim to support the general case, because not everyone need that, and aiming to support the general case adds a lot of complexity. I'm glad some editors do that, because some will need it. For my part I love a repl. My editor has a repl too. Different needs. > It was an example how naive approaches failed. Your personal editor doesn't particularly interests me. You made pronouncements about how things would fail that you implied would affect a simplified model. I've pointed out why those assumptions don't hold under the design constraints I stated in my first comments. I get that you replied on the basis of the general case. That's fine - we simply talked past each other in that respect. In that respect my editor serves as an example of viability, that's all. Nobody is asking you to be interested in it. If anything I'm explicitly warning people against expecting it to be usable for them. That your needs from an editor are different is fine. I'm not questioning the validity of your needs for you.
    - Ygg2 5y ago
      > You made pronouncements about how things would fail that you implied would affect a simplified model. And you said, they do fail? Can I load a several GB of data from weather or LHC? I haven't really heard of Rouge or if something else that uses it. But some of the choices you mentioned (like external services doing code analysis) is some of the stuff I've seen as dead ends when making a code editor (see Lure of Modular software). https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h... ------ Like ok, you made a toy editor that works in your case. Ok. Good for you, but for me and probably 90% of people, if it can't open large file, can't automcomplete, can't reference XSD schema, can't reference, can't give good overall structure, can't refactor, can't recognize SQL in strings, can't deal with macros, source gens, debugging etc. It's not that useful.

by Ygg2 5y ago

vidarh 5y ago

> It's confusing you're replying to two different threads in this I get that, which is why I specified what it was I had replied to in order to clear it up. > That's for you. I want to open a huge XML file and edit it with autocomplete. That's fine. My editor is for me, not for you. To me, if you have to do bracket matching on a 2GB XML file an editor is the wrong tool. I'd work with that in a REPL. But that's me. You're totally free to pick your editor based on the need to handle 2GB files, just as I'm free not care one iota about opening 2GB files. Hence my point that a lot of people don't seem to think about whether or not they actually need this. I decided I don't need it, and it let me simplify things a lot. It won't work for everyone, and that's fine. > I mean you could just say. I'm ok with Notepad. Ok. Sure. I'm not. Well, if I'd been ok with notepad, I'd have used notepad. I wrote my own editor because I'm not ok with Notepad. Or Emacs. The tradeoffs I care about are very different. > Any naive approach is going to run into edge cases quickly[1]. Any more sophisticated approach is going to run into performance issues. For large files, yes. It's more than fast enough to run just fine - even in pure Ruby - on files of the sizes I pointed out are the sizes I've decided I care about. > [1] For example using regex to color syntax. Reasonably fast yes, but fails in any moderately complex scenario. Which is why I'm using Rouge for the syntax-highlighting for my editor. It uses Regex for low level lexing where people choose to, but it supports state machines and multi-layered lexing or your own custom code. It supports all the languages I care about and dozens more just fine. My approach of caching the lexer state works just fine with Rouge and the approach I've outlined to e.g. parse my Ruby code with a precise Ruby mode, switch to a Markdown mode inside comment blocks, and feed the output of that into a layer that applies further custom rules based on my preferences. All without needing to build an AST for any of those. > I suspect it will break waaaay before that. Even using some language with greater complexity would cause issues. It handles every language supported by Rouge [1] just fine, and that's far more than I have need for. [1] https://github.com/rouge-ruby/rouge/blob/master/docs/Languages.md https://github.com/rouge-ruby/rouge/blob/master/docs/Languag...

Ygg2 5y ago
> That's fine. My editor is for me, not for you. To me, if you have to do bracket matching on a 2GB XML file an editor is the wrong tool. I'd work with that in a REPL. But that's me. You're totally free to pick your editor based on the need to handle 2GB files, just as I'm free not care one iota about opening 2GB files. Ok. But tbh I hate REPLs and/or CLI. Text is just better served by a visual text editor. Then you can't really compare something for general use case to something used for you. > Which is why I'm using... It was an example how naive approaches failed. Your personal editor doesn't particularly interests me.
- vidarh 5y ago
  My point was exactly that it's not necessary for every editor to aim to support the general case, because not everyone need that, and aiming to support the general case adds a lot of complexity. I'm glad some editors do that, because some will need it. For my part I love a repl. My editor has a repl too. Different needs. > It was an example how naive approaches failed. Your personal editor doesn't particularly interests me. You made pronouncements about how things would fail that you implied would affect a simplified model. I've pointed out why those assumptions don't hold under the design constraints I stated in my first comments. I get that you replied on the basis of the general case. That's fine - we simply talked past each other in that respect. In that respect my editor serves as an example of viability, that's all. Nobody is asking you to be interested in it. If anything I'm explicitly warning people against expecting it to be usable for them. That your needs from an editor are different is fine. I'm not questioning the validity of your needs for you.
  - Ygg2 5y ago
    > You made pronouncements about how things would fail that you implied would affect a simplified model. And you said, they do fail? Can I load a several GB of data from weather or LHC? I haven't really heard of Rouge or if something else that uses it. But some of the choices you mentioned (like external services doing code analysis) is some of the stuff I've seen as dead ends when making a code editor (see Lure of Modular software). https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h... ------ Like ok, you made a toy editor that works in your case. Ok. Good for you, but for me and probably 90% of people, if it can't open large file, can't automcomplete, can't reference XSD schema, can't reference, can't give good overall structure, can't refactor, can't recognize SQL in strings, can't deal with macros, source gens, debugging etc. It's not that useful.