3 ms·

I just, can't imagine what benefit you get from opening an X gigabyte file. Maybe I don't fully understand the context, but... why shouldn't you open a big fil

by narag 4y ago

I just, can't imagine what benefit you get from opening an X gigabyte file. Maybe I don't fully understand the context, but... why shouldn't you open a big file? I haven't read the whole article, but I did read that the author complains that a 172 kb text file makes the editor slow. It seems that the syntax highlighting is the culprit. I have a similar problem with my current editor of choice. I used to have a "raw" visualizer for all kind of files. Sometimes the file format is just unknown and it's useful to take a look at its contents (does it start with PK?) or you want to make a quick overwriting edit (to change some binary flags) or edit text in a huge machine-generated text file without any formatting beyond line feeds. If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming. I agree wholeheartedly. It's a clear-cut case of the "don't repeat yourself" principle.

scruple 4y ago
Where's the pragmatism? I personally don't open GB size files (that's not true, I sometimes do but it depends on the format and I tend to use vim (which is a very minimal configuration on my system these days, since I've moved to Emacs) for them because I'm typically already in a terminal munging the thing anyway). I prefer to use the terminal to deal with these things because those tools can help me decompose the problem to a more reasonable space. That seems like a more useful way to spend my time than complaining that a massive file of text won't open on my editor for $REASONS, when it's, IMO, most likely that I wouldn't be able to make sense of the damned thing if I had it all opened in front of me anyway.
- narag 4y ago
  I believe the author of the article is criticizing Emacs for being a jack-of-all-trades that use neither the best approach for plain text (keep it simple, Syd) nor the best approach for code that I swear it's structured editing, after some time working in a system very similar to what some-mthfka describes in a sibling comment.
  - scruple 4y ago
    It's not Emacs fault that CSV is a garbage format. Anyone who has spent time dealing with CSV understands the hell that is lurking in it's shadows. I don't think the rants solution, though I did not finish reading it because I frankly got bored, is going to fix any of this, either.
    - lanstin 4y ago
      That isnt the problem he is describing tho, it is that you have no primitives in emacs that correspond to a rectangle of text entry boxes like the semantics of csv. You only have sequence of chars. The author wants people to rewrite emacs as a design system for arbitrary structures of data, with hooks for moving around the structure and editing the structure and i guess contents
      - scruple 4y ago
        I see. I thought the rant was a mess, personally, so I stopped reading it. Theres some irony to be found in an unstructed rant about... structured editing. Anyway, if that's the point, then maybe tree-sitter can help us get there in the future? I still fail to see how this is an Emacs problem to solve. The vim/neovim model is also using what are essentially string dumps in the form of buffers. I'm sure every other editor is, too, but without going as far as actually having buffers, though I'm not invested enough into anything else to know what it's doing.
some-mthfka 4y ago
> It seems that the syntax highlighting is the culprit. In that case, it was the fact that adding a bullet point to a list would rescan the whole list (so it could simply update a bullet count in the header). You would need to implement incremental parsing for that, and that's not very easy. And certainly not natural. > If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming. Absolutely, that's one of the points. I must add something, though. It's not just about speed. And, in fact, it's not even just about editing. Most exciting possibilities of the structural approach stem from the fact that you can start thinking in terms of objects: then you write textual interfaces for those objects, for the purposes of textual (or even graphical) interaction. The bare-bones example is that if you had a table, or a tree in a note-taking application, then you could query that tree, but you would still retain the textual interface. Even better: you could embed any editor within any other editor, which would directly correspond to a compound structure at hand. To give you an idea of a note in a KR (knowledge-representation, prototype OO) system: (create-schema power-of-structure (:is-a kr-note) (:title "The Power of Structure") (:tags '("seamlessly-structural editing" "power")) (:introduction '("Welcome to Project Mage!" "The purpose of this article is [...]")) (:table-of-contents nil) (:sections (create-schema)) (:related-links nil) (:footnotes nil)) This note [1] could have any other structure, any other slots, of course. But it's just an object in memory. Now, all you would have to do is lens that object, aka, construct a tree of embedded editors for it (which Rune will also do via KR, just like the object above). Another example: code. A large comment block? View and edit it via a note-take application, or a markdown application, or what have you. Another example (leaving some details aside): attach comments to any piece of code (up to a character). That comment doesn't even have to be a part of the editing workflow. I think that's pretty powerful (and there are more use cases, see Alchemy in [1]). [1] This example is directly from https://project-mage.org/the-power-of-structure https://project-mage.org/the-power-of-structure
- narag 4y ago
  I had not realized that you wrote the fine article. As I told scruple in a sibling comment, I've been working in a pretty similar system for... some time :) So I have some reading to do about that Mage Project...
dsm9000 4y ago
I’ve used emacs to open and edit binaries back in the old days - basically one long line. We often needed to install proprietary software in non standard locations so changing the embedded strings within binaries worked great and better than using vi (pre vim era). Always best if the new path had a length less than that of the existing one. In any event I guess the whining about editors will never stop but meanwhile they seem to be GoodEnough(tm) for me and most things. Emacs used to be mocked for being bigger than the OS but now I think most editors are much larger. I used to work at a University lab helpdesk of sorts where first time users of UNIX systems would ask us for help getting started entering their first CSCI programs on a Sun or other UNIX-like os and my unscientific but high n observation is that vi, emacs, ed or cat all worked and occasionally people would find a way to get confused equally on any method when starting out. Level of education didn’t seem to make a difference. Editor ergonomics seem to be very personal, like furniture so I’m glad we have so many options. On another side note I am glad that most text input fields across many operating systems and applications usually do the right thing with Emacs cursor control sequences e.g. CTRL-a, CTRL-n, CTRL-p, CTRL-e. So hopefully that legacy lives on
- narag 4y ago
  Editor ergonomics seem to be very personal, like furniture so I’m glad we have so many options. A long time ago I read some piece by Groucho, about how it's impossible to find a beef (or ham, or turkey, not sure which it was) sandwich any more. He goes to some sandwich shop and ask for a beef sandwich and they offer him a beef + hard boiled eggs + lettuce sandwich with mayo, cherry tomatos and oregano, or a beef + cheese + spinachs + nutmeg sandwich or whatever. But he can't just buy a simple roastbeef sandwich, maybe with a pinch of mustard. I used Notepad in Windows for simple text, that used to work OK. Then I changed to some free editor created by a guy as a programming exercise with some interesting extras. Now both have the same problem: if I need to open big text files for some reason, it takes forever. Edit: big as in ~ 1 MB, sometimes smaller.
  - TeMPOraL 4y ago
    > A long time ago I read some piece by Groucho, about how it's impossible to find a beef (or ham, or turkey, not sure which it was) sandwich any more. (...) But he can't just buy a simple roastbeef sandwich, maybe with a pinch of mustard. I need to find that piece, because it resonates. For me, it's hot dogs. I can't find plain hotdogs anywhere anymore. All I want is a bun, a sausage, and some ketchup and mustard on top. But no, everyone has to add at least cucumbers and fried onions, and if you're not careful, you'll end up with bread full of a large assortment of veggies, with barely a sausage in sight. I imagine the reason for this is economics: this green stuff is probably dirt cheap relative to the sausage, but lets the vendor triple the price of a hot dog without making you feel they're price gouging you. For the past decade in my area, IKEA was the last bastion of pure, unadulterated hot dogs. But even they recently took that off the menu - the basic hot dog now comes loaded with useless greenery.

by narag 4y ago

scruple 4y ago

Where's the pragmatism? I personally don't open GB size files (that's not true, I sometimes do but it depends on the format and I tend to use vim (which is a very minimal configuration on my system these days, since I've moved to Emacs) for them because I'm typically already in a terminal munging the thing anyway). I prefer to use the terminal to deal with these things because those tools can help me decompose the problem to a more reasonable space. That seems like a more useful way to spend my time than complaining that a massive file of text won't open on my editor for $REASONS, when it's, IMO, most likely that I wouldn't be able to make sense of the damned thing if I had it all opened in front of me anyway.

narag 4y ago
I believe the author of the article is criticizing Emacs for being a jack-of-all-trades that use neither the best approach for plain text (keep it simple, Syd) nor the best approach for code that I swear it's structured editing, after some time working in a system very similar to what some-mthfka describes in a sibling comment.
- scruple 4y ago
  It's not Emacs fault that CSV is a garbage format. Anyone who has spent time dealing with CSV understands the hell that is lurking in it's shadows. I don't think the rants solution, though I did not finish reading it because I frankly got bored, is going to fix any of this, either.
  - lanstin 4y ago
    That isnt the problem he is describing tho, it is that you have no primitives in emacs that correspond to a rectangle of text entry boxes like the semantics of csv. You only have sequence of chars. The author wants people to rewrite emacs as a design system for arbitrary structures of data, with hooks for moving around the structure and editing the structure and i guess contents
    - scruple 4y ago
      I see. I thought the rant was a mess, personally, so I stopped reading it. Theres some irony to be found in an unstructed rant about... structured editing. Anyway, if that's the point, then maybe tree-sitter can help us get there in the future? I still fail to see how this is an Emacs problem to solve. The vim/neovim model is also using what are essentially string dumps in the form of buffers. I'm sure every other editor is, too, but without going as far as actually having buffers, though I'm not invested enough into anything else to know what it's doing.

some-mthfka 4y ago

> It seems that the syntax highlighting is the culprit. In that case, it was the fact that adding a bullet point to a list would rescan the whole list (so it could simply update a bullet count in the header). You would need to implement incremental parsing for that, and that's not very easy. And certainly not natural. > If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming. Absolutely, that's one of the points. I must add something, though. It's not just about speed. And, in fact, it's not even just about editing. Most exciting possibilities of the structural approach stem from the fact that you can start thinking in terms of objects: then you write textual interfaces for those objects, for the purposes of textual (or even graphical) interaction. The bare-bones example is that if you had a table, or a tree in a note-taking application, then you could query that tree, but you would still retain the textual interface. Even better: you could embed any editor within any other editor, which would directly correspond to a compound structure at hand. To give you an idea of a note in a KR (knowledge-representation, prototype OO) system: (create-schema power-of-structure (:is-a kr-note) (:title "The Power of Structure") (:tags '("seamlessly-structural editing" "power")) (:introduction '("Welcome to Project Mage!" "The purpose of this article is [...]")) (:table-of-contents nil) (:sections (create-schema)) (:related-links nil) (:footnotes nil)) This note [1] could have any other structure, any other slots, of course. But it's just an object in memory. Now, all you would have to do is lens that object, aka, construct a tree of embedded editors for it (which Rune will also do via KR, just like the object above). Another example: code. A large comment block? View and edit it via a note-take application, or a markdown application, or what have you. Another example (leaving some details aside): attach comments to any piece of code (up to a character). That comment doesn't even have to be a part of the editing workflow. I think that's pretty powerful (and there are more use cases, see Alchemy in [1]). [1] This example is directly from https://project-mage.org/the-power-of-structure https://project-mage.org/the-power-of-structure

narag 4y ago
I had not realized that you wrote the fine article. As I told scruple in a sibling comment, I've been working in a pretty similar system for... some time :) So I have some reading to do about that Mage Project...

dsm9000 4y ago

I’ve used emacs to open and edit binaries back in the old days - basically one long line. We often needed to install proprietary software in non standard locations so changing the embedded strings within binaries worked great and better than using vi (pre vim era). Always best if the new path had a length less than that of the existing one. In any event I guess the whining about editors will never stop but meanwhile they seem to be GoodEnough(tm) for me and most things. Emacs used to be mocked for being bigger than the OS but now I think most editors are much larger. I used to work at a University lab helpdesk of sorts where first time users of UNIX systems would ask us for help getting started entering their first CSCI programs on a Sun or other UNIX-like os and my unscientific but high n observation is that vi, emacs, ed or cat all worked and occasionally people would find a way to get confused equally on any method when starting out. Level of education didn’t seem to make a difference. Editor ergonomics seem to be very personal, like furniture so I’m glad we have so many options. On another side note I am glad that most text input fields across many operating systems and applications usually do the right thing with Emacs cursor control sequences e.g. CTRL-a, CTRL-n, CTRL-p, CTRL-e. So hopefully that legacy lives on

narag 4y ago
Editor ergonomics seem to be very personal, like furniture so I’m glad we have so many options. A long time ago I read some piece by Groucho, about how it's impossible to find a beef (or ham, or turkey, not sure which it was) sandwich any more. He goes to some sandwich shop and ask for a beef sandwich and they offer him a beef + hard boiled eggs + lettuce sandwich with mayo, cherry tomatos and oregano, or a beef + cheese + spinachs + nutmeg sandwich or whatever. But he can't just buy a simple roastbeef sandwich, maybe with a pinch of mustard. I used Notepad in Windows for simple text, that used to work OK. Then I changed to some free editor created by a guy as a programming exercise with some interesting extras. Now both have the same problem: if I need to open big text files for some reason, it takes forever. Edit: big as in ~ 1 MB, sometimes smaller.
- TeMPOraL 4y ago
  > A long time ago I read some piece by Groucho, about how it's impossible to find a beef (or ham, or turkey, not sure which it was) sandwich any more. (...) But he can't just buy a simple roastbeef sandwich, maybe with a pinch of mustard. I need to find that piece, because it resonates. For me, it's hot dogs. I can't find plain hotdogs anywhere anymore. All I want is a bun, a sausage, and some ketchup and mustard on top. But no, everyone has to add at least cucumbers and fried onions, and if you're not careful, you'll end up with bread full of a large assortment of veggies, with barely a sausage in sight. I imagine the reason for this is economics: this green stuff is probably dirt cheap relative to the sausage, but lets the vendor triple the price of a hot dog without making you feel they're price gouging you. For the past decade in my area, IKEA was the last bastion of pure, unadulterated hot dogs. But even they recently took that off the menu - the basic hot dog now comes loaded with useless greenery.