the most fast code to emulate vim's h/j/k/l behavior ?

[Sik]

I was talking about the editing portion anyway ¯\(o_º)/¯ Rendering is a whole different issue (and generally much easier in comparison).

Most of the operations work on a single line. Some operations work on multiple lines (but still can be internally handled as if you edited several lines separately). It makes perfect sense to treat the document as a list of lines instead of a single huge block, and it also makes sense to keep the whole document in RAM if there's enough for it (and in any even remotely modern system that's definitely going to be the case). That's the part I'm arguing about.

...OK, reading back I see Brendan brought up the rendering part. I'd be more worried about how much CPU power it'd take to redo those buffers (since you'd be moving a lot of data around, the whole document in the worst case). Not a big issue when you're working on individual lines, since in that case only a single line would be affected by this which isn't anywhere as bad in terms of performance.

[Schol-R-LEA]

Most of the operations work on a single line. Some operations work on multiple lines (but still can be internally handled as if you edited several lines separately). It makes perfect sense to treat the document as a list of lines instead of a single huge block, and it also makes sense to keep the whole document in RAM if there's enough for it (and in any even remotely modern system that's definitely going to be the case). That's the part I'm arguing about.

Whether you are right or not would take some testing to determine. What I can tell you is how existing text editors work, and as far as I know, they nearly all use gap buffers. Word processors are probably more split between those and piece tables, but I really don't know for sure.

I have started diving into the source code of vim on Github specifically, to see if I can figure out how it works, but unfortunately, like most large programs (especially C programs) the code is a huge mess filled with a lot of conditional compilation directives and not enough comments. If I am not back by Saturday morning, send a search party.

EDIT; Seriously, it's not pretty. OK, so it isn't Swampy level horrid (thread NSFW, source code Not Safe For Sanity), but... I mean, almost all the code and header files are in a single directory. That's just stupid with something this big. The ones which are in separate directories are, ah, opaque to say the least. Also, some of the preproc switches are... dated. I found one for Aztec C, and I'm pretty sure that hasn't been sold since the early 1990s (EDIT: Wikipedia says late 1990s, but still), so that says something by itself.

However, there is some file documentation in the folder's README, and the salient file does seem to be the sensibly named vim.h and buffer.c, which I will be exploring posthaste. I suspect that the tale is told in the name the latter, but better to be clear. Wish me luck.

[Sik]

OK, I'm starting to wonder if we're even arguing over the same thing. You can use a gap buffer at the line level after all (instead of having the buffering for the entire document, you just do it on the current line being edited).

Having it split in lines has the side effect of making travelling faster (when editing you can move directly to the specific line, when rendering you can easily get where the first line to display starts). I'm not sure how useful is a gap buffer on short lines, it may be way more important if you expect long lines or whole paragraphs (or "source" code where all newlines have been crushed away... looking at you, programs that output HTML).

Also yikes, all those #ifdefs indeed. Would be probably much easier to read without them.

[Schol-R-LEA]

Well, I found what seems to be the master struct type for the buffers, in the file structs.h. facepalm The struct is defined with the name file_buffer, which is reasonable enough, but then is typedef'ed to buf_T; this wouldn't be so bad, except that buf_T, which is used almost everywhere, is a forward declaration with only a small comment to indicate what it actually is.

The struct itself is a monster, 471 LOC long and filled with conditional directives and defines (yes, inside the struct itself, mostly inside of #ifdefs but even so...). It is commented extensively, but I wouldn't really say well as most of the comments are pretty much meaningless. I have extracted it and put into an attached file, as I wanted to make it clear what I was talking about but didn't want to post something that unwieldy into the message board proper.

As for the question of whether using a gap buffer necessitates loading a whole file (or section thereof) at once, well, there is no real reason you couldn't combine it with line-by-line editing, sure. As I said, I expect that a lot word processors use a gap buffer for active editing, but then use a piece table for tracking changes and the file as a whole. Going by line would be just a special case of that.

The question thus becomes, does a line - as opposed to, say, a word, a sentence, a paragraph, a section (in the case of something like an outline editor), or a function/block/enclosing tag/s-expression (Emacs can indeed break things down by sexprs, though I suspect it is at a different level than what we are discussing) - make sense as the chunk size when working with a piece table (or a rope, which would have similar properties)? I do not really have a good answer for that, though I would guess that the answer would depend on the particular sort of editing. In practice, I get the sense that most editors that have this as their fundamental data structure use other chunking rules, but what rules those might be for a given editor, and why they were chosen, I would not be able to say.

EDIT: I have taken a chainsaw to a copy of the struct, moving the non-conditional #defines out of the struct itself and paring out all the conditionals (most of which are for specific optional language-support features of the sort which I think are now mainly handled in the scripting, FFS!). This brings it to a slightly more manageable 189 LOC, of which some seem to be for specific features rather than things that really need to be in this God Object of a struct. I am attaching that, too.

Also, while you will note that the struct has pointers to allow it to be used as a node in a doubly-linked list, this seems to be for handling multiple files, rather than multiple sub-buffers for a single file. I may be wrong on this, however. I will keep trying to figure this out.

Still nowhere near as bad as Spectate Swamp Desktop Search is. If you want to see some truly awful code that would make a BrainF--- programmer say "WTF?!?!?!" follow the link above in earlier post. I got rather swear-y, but trust me, it was justified. My Little Swampy: GOTOs are Magic!

I'd compare SSDS to TempleOS, but that would terribly unfair - no matter what we think if Terry Davis as a person, or our opinions of his sanity or lack thereof, as a programmer he beats Doug Pederson like a drum. TempleOS actually runs without crashing, and doesn't use a programing style that would have seemed archaic in 1968, which is enough by itself to adjudge Davis the better coder.

[dozniak]

Take a look at https://github.com/arximboldi/ewig

[Brendan]

Hi,

Well, I found what seems to be the master struct type for the buffers, in the file structs.h. facepalm The struct is defined with the name file_buffer, which is reasonable enough, but then is typedef'ed to buf_T; this wouldn't be so bad, except that buf_T, which is used almost everywhere, is a forward declaration with only a small comment to indicate what it actually is.

The struct itself is a monster, 471 LOC long and filled with....

That's all nice I guess; but you've overlooked one crucial step: proving that the current VI code uses the best method. Until/unless you do that, how VI works internally isn't particularly relevant.

In fact, I'd go a step further and say that VI's code is likely to be "antiquated pile of puss (with a thick layer of bitrot on top)", and that it's extremely unlikely that whatever VI code uses is the best method now (even if it was the best method decades ago, when system RAM was smaller than modern L3 cache sizes and Unicode didn't exist).

In other words, if you prove VI uses "gap buffer", then that'd be evidence that suggests that "gap buffer" probably sucks.


Cheers,

Brendan

[Schol-R-LEA]

I did address that earlier, you know; I said that it would take testing. However, it seems to me that if you or I are going to test something... we would want to know what it is we're testing. Moreover, it seems likely that there has to be some reason beyond inertia why the method has persisted. Inertia can explain a lot of crappy code, but not the use of basically the same design in several places when a potentially better one (the list of lines model) would appear to be simpler on the surface.

As for the source code to vim itself...



But a lousy implementation of an idea does not necessarily imply that the idea is lousy.

(BTW, Brendan, I keep meaning to ask why you consistently spell 'pus' as 'puss'. I know it isn't a Commonwealth vs Merkin thing, as every British dictionary I have seen spells it with one 's' - though Wiktionary does mention it as an alternate spelling, so I guess it isn't wrong per se. I don't know why, but it has always bugged me a bit.)

Is this even worth continuing with? If it is, then I suggest we all (re-)read the Finseth book (it's free, after all, and not especially long) and see what his arguments are before deciding whether they make sense. Otherwise, it would be like arguing about a point on (say) FSA-driven lexical analysis when we haven't read the Dragon Book (or something equivalent).

In this case, it's even worse than that, actually, as The Craft of Text Editing is pretty much the only textbook on the implementation of text editors at all, AFAIK. Now, that doesn't mean that he was right, or that things haven't changed since 1991, but it does mean that it is worth at least seeing what it says before dismissing the arguments.

(Keep in mind that I have already mentioned that my earlier gloss on the topic was wrong in at least some particulars, and I gave a partial correction on that. I may be wrong in other parts as well. Arguing his points based on my incorrect recall of them isn't going to work here, which is why I need to read it again myself.)

If we still disagree, we can test then.

EDIT: Sorry to keep doing this, but... it just occurred to me that no one, including myself, mentioned something that should be obvious: the input module - which, like the renderer, needs to be separate from the editing engine - cannot use standard stream I/O functions if it is to work as a full-screen editor. This is a bit of a side issue, since the editing engine is what we (well, I anyway) are focusing on, but still a useful point.

Even for a single line of text, anything that is meant to use any kind of in-line editing has to be able to accept whatever input the keyboard or terminal provides directly (scan codes, or at least some sort of 'rare' key codes, in the case of the PC) in order to be responsive to anything other than inserts. Collecting the input into a simple buffer until the ENTER key is struck, and then sending it all as a stream, isn't feasible.

This is easily forgotten today, since most current shells and TUIs (and pretty much all GUI text entry windows) provide a certain amount of editing capacity for you - the input is still being read as raw by the shell or textbox mini-editor, it's just that it is then sent to the application via stdin or the equivalent (or via reading the textbox buffer in the case of a GUI).

Why do a mention this? Because I am re-reading the Finseth book, and he is going about explaining this in the first chapter, by presenting examples of successive incomplete models of this - for the purpose of then dissecting them and explaining why they are inadequate. While the examples all use a nebulous 'KeyGet()' function, they are shown initially just putting input into a buffer until the ENTER is pressed. Now that I am reading it again, this quasi-Socratic Method (he even describes it that way in the preface) seems familiar, and I am pretty sure that he does indeed address the questions already raised. I think, however, you will need to see for yourselves if you find his arguments convincing or not.

[Schol-R-LEA]

Sorry to post two messages in succession, but the previous post is already too long and unwieldy as it is, and there was too long a break in time since when I first wrote it. I simply want to mention that the relevant chapter, with his analysis of different models for holding and modifying the text being edited, is in Chapter 6, 'The Internal Sub-Editor'. I would recommend reading chapter 1 in detail, skimming chapter 2 (which mostly focuses on outdated hardware, but does have some points which are still relevant), skipping 3 entirely, reading 4, skipping 5, and finally, skimming 6 followed by a more careful re-read of the parts you think are relevant. You will probably want to read 7, 8 and 9 eventually, but they aren't directly relevant to this discussion.

Interestingly, he stated that at least some EMACS style editors (specifically those using Lisp as the implementation language, and/or incorporating a Lisp interpreter) use the hybrid 'Line List' model, using a list of chunks (not necessarily lines, but he does describe them as such) with a buffer gap when working on a specific section. As I said before, this is pretty similar to the piece table approach, as well.

Thus, I have to concede this to you, Brendan. My memory on this was definitely faulty, even if I still remembered his primary conclusion (that gap buffers were generally best).

I also incorrectly recalled - and hence misrepresented - his rationales for this. I horribly misrepresented the granularity at which buffer gaps operate, as well.

However, this doesn't mean that the discussion was in vain. The model he describes as 'line list' is more than just the simple 2-D array the OP described (an approach which Finseth does discuss in that chapter), or even the linked list of lines that was mentioned later; and more to the point, it should help the OP actually solve the problem they posted about.

Still, the way I answered this? That was all wrong, as was my explanation of what I was trying to describe. Mea Culpa.

[Solar]

As for the quality of Vim source code, I'd like to add this little historical info...

Vim is based (originally, in 1991) on the published sources for Stevie (1987), a vi clone on the Atari ST that was ported to Unix, OS/2 and AmigaOS. Vim later got backported to all the other platforms as it was (arguably) the best vi clone around.

Why were there so many vi clones and not that many straight ports?

Because the original vi code was awful. The author, Bill Joy, had a reputation for "getting things done", but doing so in a very ad-hoc and non-documented style...

So it's all relatively speaking, really.

And, @Brendan, you can say whatever you want, and I won't actually defend Vim's code quality, but Vim is easily among the most mature, complete, well-tested and well-performing editors out there. It's easy to challenge others to come up with "the best" solution for anything. Why don't you follow up Schol-R-LEA's work with presenting something that is, in your eyes, better-than-Vim?

[Brendan]

Hi,

As for the quality of Vim source code, I'd like to add this little historical info...

Vim is based (originally, in 1991) on the published sources for Stevie (1987), a vi clone on the Atari ST that was ported to Unix, OS/2 and AmigaOS. Vim later got backported to all the other platforms as it was (arguably) the best vi clone around.

Why were there so many vi clones and not that many straight ports?

Because the original vi code was awful. The author, Bill Joy, had a reputation for "getting things done", but doing so in a very ad-hoc and non-documented style...

So it's all relatively speaking, really.

"The best vi clone around (in 1991)" might sound like a good thing if nothing (in software algorithms, character sets, display technology, CPU speed, number of CPUs or amount of RAM) changed in the last 25 years. It's because all of these things have changed that "the best vi clone around (in 1991)" is an admission of inferiority.

And, @Brendan, you can say whatever you want, and I won't actually defend Vim's code quality, but Vim is easily among the most mature, complete, well-tested and well-performing editors out there. It's easy to challenge others to come up with "the best" solution for anything. Why don't you follow up Schol-R-LEA's work with presenting something that is, in your eyes, better-than-Vim?

I already did come up with a better solution.


Cheers,

Brendan

[Schol-R-LEA]

Your arrogance is going to get you in a lot of trouble some day, Brendan. This sort of attitude would get you banished from most fora, and were you not a mod yourself, it would probably have already gotten you bounced from here, too. You are one of the best coders and most knowledgeable members on this group, but that won't mean a thing if you piss off even the regulars for no good reason.

Seriously, just because you say something is better doesn't prove a damn thing. Hold yourself to the same standards you try to hold others to, for once.

I admitted my mistake about misrepresenting Finseth. You rightly called me out for what I said. Your argument is with what he said now, not with what I said. If you can demonstrate that his assertions were wrong - with a set of test programs showing the advantages and flaws of each approach - I will give you all the laurels you wish. I will even help write the demonstrations. But I have no more reason to take your word for that you did for me - and just because I was wrong doesn't mean you were right.

EDIT: The more I think about it, the more an 'editing model shootout' sounds like something that needs to be done anyway. The literature on the subject is sparse at best, and there doesn't seem to be a lot of hard numbers or even careful algorithmic analysis about them. Hell, you could probably get a paper published on it, if you cared to get the academic kudos on the subject (not that I expect you would, given your less than sanguine view of academic 'computer science'). Or at least an article about it on some site like Ars Technica. And as I said, I am willing to help, and I expect some others here would be too. We would need to agree on an implementation language, a test suite, the format for the text code, etc. but it might be worth it if you want to pursue the matter.

[Brendan]

Hi,

Your arrogance is going to get you in a lot of trouble some day, Brendan. This sort of attitude would get you banished from most fora, and were you not a mod yourself, it would probably have already gotten you bounced from here, too. You are one of the best coders and most knowledgeable members on this group, but that won't mean a thing if you piss off even the regulars for no good reason.

Seriously, just because you say something is better doesn't prove a damn thing. Hold yourself to the same standards you try to hold others to, for once.

I admitted my mistake about misrepresenting Finseth. You rightly called me out for what I said. Your argument is with what he said now, not with what I said. If you can demonstrate that his assertions were wrong - with a set of test programs showing the advantages and flaws of each approach - I will give you all the laurels you wish. I will even help write the demonstrations. But I have no more reason to take your word for that you did for me - and just because I was wrong doesn't mean you were right.

Have you considered that:

• Fools avoid confrontation, smart people surround themselves with people who disagree.
• I honestly don't care about text editors at all, and I see "plain text" as an indication of design flaws and inefficiency. For my OS project I doubt there will be any text editor - there will only be editors designed for specific purposes - e.g. a word processor for word processing (including inline images), an IDE for programming (that works on tokenised source code in a binary file format), dialog boxes for various configuration files (that work on binary file formats), etc.
• I hate vim because the user interface is far too "user unfriendly" and the learning curve is too steep for something that should be simple and require no learning at all. The fact is that I switch between different "text and text like" editors all the time (including edit boxes in various web browsers, word processors, IDEs, etc; plus actual text editors for both Windows and KDE); and every single one of these provide the same fundamental user interface elements (mouse, x/c/v for cut/copy/paste, scroll bars, cursor keys, end/home/pageup/pagedown keys, etc) that have become ubiquitous across almost every modern application on almost every modern (graphical) user interface.
• The original poster asked a question; and I gave a relatively clear and logical answer, including reasons, and without indirection (e.g. "go see something someone else wrote somewhere else"), and without letting my personal feelings towards text editors in general or vim specifically taint my answer. So far; not one person has criticised my solution or pointed out flaws or suggested ways to improve it.
• "It's old and/or someone else did it like this, therefore it must be good" is an invalid argument (non sequitur) that I will never knowingly accept.
• I didn't read Finseth's book (I quickly skimmed small parts of it) and doubt I ever will. I simple don't care enough to wade through a few hundred pages; especially when a clear and logical suggestion (including reasons) fits in less than 2 pages.
• My previous post in this topic was directed at Solar and not you, and I wrote it because Solar's post seemed to be directed at me (especially the last paragraph) and not you.

EDIT: The more I think about it, the more an 'editing model shootout' sounds like something that needs to be done anyway. The literature on the subject is sparse at best, and there doesn't seem to be a lot of hard numbers or even careful algorithmic analysis about them. Hell, you could probably get a paper published on it, if you cared to get the academic kudos on the subject (not that I expect you would, given your less than sanguine view of academic 'computer science'). Or at least an article about it on some site like Ars Technica. And as I said, I am willing to help, and I expect some others here would be too. We would need to agree on an implementation language, a test suite, the format for the text code, etc. but it might be worth it if you want to pursue the matter.

For the test suite, I'd define several categories of tests:

• Time between starting the text editor (to load a huge file), and displaying the relevant part of the huge file on the screen
• The performance of screen updates for the "frequently displaying different areas of the text file" case (e.g. "page down key repeat").
• The performance of cut and paste of large sections of the file (including screen updates)
• The performance of searching for exact string matches within a huge file (to get an idea of "iterate through everything" costs)
• The performance of "search and replace" for a substring that occurs very frequently (to get an idea of modification costs)

For each category, I'd have multiple tests:

• With single CPU only, and with multiple CPUs (to get an idea of scalability for each category)
• With text file using the same character set and encoding as the editor, and with text file using a different character set or encoding to the editor (to get an idea of conversion costs)
• With no idle time before a test is done, and with a lot of idle time before a test is done (to get an idea of whether there's efficient use of CPU idle time)

This would add up to a total of maybe "5*2*2*2 = 40" individual tests.


Cheers,

Brendan

[Solar]

Have you considered that: Fools avoid confrontation, smart people surround themselves with people who disagree.

I completely agree with Schol-R-Lea here. You need to tone it down, Brendan. Seriously.

I honestly don't care about text editors at all, and I see "plain text" as an indication of design flaws and inefficiency. For my OS project I doubt there will be any text editor - there will only be editors designed for specific purposes - e.g. a word processor for word processing (including inline images), an IDE for programming (that works on tokenised source code in a binary file format), dialog boxes for various configuration files (that work on binary file formats), etc.

That is somewhat funny, because virtually all experienced developers I know distinctly prefer "plain text" formats for just about everything -- because they can be handled with the plethora of text-handling tools available. Grep. Diff. Version control. Generic text editors. One of the reason why stuff like LaTeX is still around, for example.

I hate vim because the user interface is far too "user unfriendly" and the learning curve is too steep for something that should be simple and require no learning at all. The fact is that I switch between different "text and text like" editors all the time (including edit boxes in various web browsers, word processors, IDEs, etc; plus actual text editors for both Windows and KDE); and every single one of these provide the same fundamental user interface elements (mouse, x/c/v for cut/copy/paste, scroll bars, cursor keys, end/home/pageup/pagedown keys, etc) that have become ubiquitous across almost every modern application on almost every modern (graphical) user interface.

Again, this statement shines a curious light on you. The point is that Vim is geared toward people who work with text all day long. It's not about being easy to learn. It's about being easy to use, from the standpoint of an experienced user.

(Kind of like programming languages that are easy to learn but somewhat limited in what they can do, opposed to languages that are harder to master but more powerful once mastered.)

[Brendan]

Hi,

Have you considered that: Fools avoid confrontation, smart people surround themselves with people who disagree.

I completely agree with Schol-R-Lea here. You need to tone it down, Brendan. Seriously.

I express my opinions in a direct and honest manner. If you can't handle that you need to grow up, seriously.

Note that the line you've quoted is a paraphrased version of a well known quote, but there's multiple variations of this quote attributed to different authors. The most common seems to be "Stupid people surround themselves with smart people. Smart people surround themselves with smart people who disagree with them." (attributed to Aaron Sorkin).

I honestly don't care about text editors at all, and I see "plain text" as an indication of design flaws and inefficiency. For my OS project I doubt there will be any text editor - there will only be editors designed for specific purposes - e.g. a word processor for word processing (including inline images), an IDE for programming (that works on tokenised source code in a binary file format), dialog boxes for various configuration files (that work on binary file formats), etc.

That is somewhat funny, because virtually all experienced developers I know distinctly prefer "plain text" formats for just about everything -- because they can be handled with the plethora of text-handling tools available. Grep. Diff. Version control. Generic text editors. One of the reason why stuff like LaTeX is still around, for example.

Virtually all experienced developers (which is a small subgroup of "all users") distinctly prefer "plain text" formats over ... what? There is currently no viable alternative (that I'm aware of) that they could possibly prefer.

If you look at areas where there is an alternative (e.g. "WYSIWYG vs. something like LaTeX with plain text" for word processing, "comma separated plain text vs. Excel Binary File Format" for spreadsheets, etc) then it's fairly clear what experienced users prefer when there's an actual choice.

I hate vim because the user interface is far too "user unfriendly" and the learning curve is too steep for something that should be simple and require no learning at all. The fact is that I switch between different "text and text like" editors all the time (including edit boxes in various web browsers, word processors, IDEs, etc; plus actual text editors for both Windows and KDE); and every single one of these provide the same fundamental user interface elements (mouse, x/c/v for cut/copy/paste, scroll bars, cursor keys, end/home/pageup/pagedown keys, etc) that have become ubiquitous across almost every modern application on almost every modern (graphical) user interface.

Again, this statement shines a curious light on you. The point is that Vim is geared toward people who work with text all day long. It's not about being easy to learn. It's about being easy to use, from the standpoint of an experienced user.

I see the essential premise of vim as "lose productivity for ages while climbing the learning curve, then gain a theoretical tiny productivity improvement (that I don't think has ever been measured, and may be pure fiction) thereafter; such that maybe after a decade of continued use you reach a break even point where you've regained the time you lost during the learning curve; and from that point on it's potentially beneficial maybe".

Please note that:

• There are some features of vim (e.g. regex searches, command line integration, etc) that may improve productivity, but don't have anything to do with the user-interface itself (and could be added and/or may already exist in "non-vim user interface" editors) and are therefore irrelevant to what we are discussing.
• Often people cite "no need to use the mouse" as one of the benefits. Given that I've never seen a text editor where you have to use the mouse, this can not be considered a valid benefit on it's own.
• I do acknowledge that there is a potential "fingers move shorter distances" benefit by shifting various keys closer to the "home row" (and this is the "theoretical tiny productivity improvement" I'm talking about above). However I also acknowledge that vim's user interface requires "modes" and that there is a cost of switching between modes that reduces (and possibly eliminates) the "fingers move shorter distances" benefit.
• There is a difference between "perceived productivity" and "actual productivity"; and I think there's a psychological link between "cost of learning" and "perceived productivity" that causes vim advocates to over-estimate "actual productivity". I tried to find an actual scientific study that measures the productivity difference, and found none. I suspect it'd be easier to find "qwerty vs. dvorak" which might suffice as circumstantial evidence for the "fingers move shorter distances" benefit (without the "mode switching" costs).

Also I don't think experienced users use a text editor and nothing else, all day every day. For example; while programming, I'm frequently switching between text editor, web browser, PDF viewer, and/or Bochs (and occasionally less common apps like spreadsheets, and sometimes switching between different computers). It's this "switching between multiple applications" that comes with an additional potential cost (where almost all applications you're switching between have the same controls, same keyboard shortcuts, etc; except for vim, which sticks out like a bad note in an otherwise beautiful melody).

(Kind of like programming languages that are easy to learn but somewhat limited in what they can do, opposed to languages that are harder to master but more powerful once mastered.)

Yes (but I don't like "hard to master but more powerful once mastered" programming languages either).


Cheers,

Brendan

[Solar]

I completely agree with Schol-R-Lea here. You need to tone it down, Brendan. Seriously.

I express my opinions in a direct and honest manner. If you can't handle that you need to grow up, seriously.

Speaking your mind is not an excuse for unnecessary abrasiveness.

That's why I don't continue this discussion -- not because I don't think I could make interesting points for you and the general audience, but because you're talking down on people and do not even consider taking other people's view into consideration.

Which is a very poor thing to be said about a moderator.