[Bug] The colors never work if Vim is opened with just `vim`. Rainbow *only* works if opened with `vim file.ext`.

Describe the bug

Yesterday I spent several hours trying to get this Vim plugin working, since I've been thinking of potentially doing my next project using Common Lisp (which would benefit greatly from it). However, no matter how I changed the settings or approached the installation or troubleshooted anything the plugin never did anything at all (as far as I could discern).

However, after giving up entirely (but having still left the plugin installed in case it worked after rebooting my computer the next day), I stumbled upon the real problem by accident/luck:

This plugin only ever works if vim is opened using a command of the form vim file.ext where ext is a known file extension such as .txt or .c or .lisp or .cl and so on. If Vim is started using just vim then the plugin will never activate (even if :set syntax=lang is used) and neither will the :RainbowToggle command ever do anything at all.

When testing Vim (and in many other contexts) I very often will just use vim to open it and I often do not specify a file name or extension until long after via the :saveas file.ext command. Many other Vim users do likewise (they never or seldom specify the file name or extension when opening vim) and therefore all such users (of which there is likely a large proportion) will get the impression that this plugin is completely broken and never works.

Many reported issues with this plugin "not working at all" hence may actually just be caused by programmers opening Vim without passing a filename with known extension.

This counterintuitive quirk of the plugin's behavior is (as far as I can tell) not documented anywhere either.

The plugin has likely been programmed in such a way that it tries to grab the filename and/or file extension at some point when loading up and then crashes or bugs out in some way anytime that Vim hasn't been opened with vim file.ext.

The plugin should be modified so that none of its syntax highlighting logic depends upon the filename and/or extension already having been specified, since Vim is often used without specifying that yet.

To Reproduce

Install the rainbow plugin.
Run vim by just writing vim in the command prompt or shell.
Type nested parentheses and see that the plugin never activates.
Try using :set syntax=lang (e.g. :set syntax=lisp) and :RainbowToggle and see that still the plugin never activates.
Instead try opening Vim with any known file extension, such as via vim file.txt and see that the plugin now works.

Expected behavior

There is little to no reason why a Vim user would expect the plugin to never work unless a file name and extension has been given.

Vim is designed to not depend upon that, which is why you can use it that way and can also manually tell syntax highlighting to turn on or off regardless of whether a file exists yet.

The plugin should be modified to correspond with expected Vim behavior and with very common Vim workflows involving not specifying the filename and extension. Unless Vim is strangely engineered regarding this point, there's no logical reason why this dependency should exist.

Additional context

I'm not using any other plugins than this (rainbow) currently, though I do have many custom Vim keybindings.

Try :set ft=txt and read README about the "separately" part

I don't understand why you've closed this issue. The main point of the issue (the fact that the current behavior will mislead a large proportion of users into thinking the plugin never works and/or waste many hours of their time) hasn't been addressed at all.

I was unaware of the :set ft=ext command for Vim and that does indeed cause the rainbow parentheses plugin to start working (unlike the :set syntax=lang command). However, there is no sign of this information being added to the documentation so that other users don't get confused.

I've also read the "separately" part of the README.md file (and in fact already did before submitting my issue report) but it still seems largely irrelevant and unhelpful for the actual issue I reported. For example, the txt isn't listed anywhere in the file list and yet the rainbow colors still apply to the parentheses of txt. This implies that the '*' = {} clause of the 'separately': {...} config setting is already handling all unlisted file types such as txt but in light of the way the plugin doesn't respond as expected this is highly confusing and/or comes across as broken or inconsistent or unpredictable behavior.

By closing this issue without adding anything to the README.md documentation about the need to use :set ft=ext at a minimum (or much more ideally by making it work regardless of whether a file name and extension has been given) you are essentially ensuring that a huge proportion of Vim users will continue to falsely be given the impression that the plugin is completely broken and doesn't work and/or waste many hours trying to see any visible effect.

I suggest actually fixing the problem instead of just saying that there is an easily missable Vim command that can be used like a temporary bandaid and assuming that all users will know about it or think to use it when testing the plugin. They won't. Closing this issue prematurely will harm your plugin's adoption/usage rate quite a lot and so I am quite surprised that you've already done so without fixing the actual issue (which is how the current state of it misleads a huge proportion of users into thinking the plugin is completely broken).

A real Vim user can solve this by read the source code or just use au command to trigger things easily, if you cannot do this, just don't use vim please, just use vscode will be a better choice

The souce code is here and the doc about au command is inside vim via :h au

A real Vim user can solve this by read the source code or just use au command to trigger things easily, if you cannot do this, just don't use vim please, just use vscode will be a better choice

I have been using Vim everyday for many years (perhaps a decade) now and do not intended to stop any time soon. I've read multiple reference documents from front to back and even have at 3 different Vim reference and memorization quiz apps on my phone, which I've also been using for many years.

It is very easy to overlook any specific individual feature of the software, or indeed of any complex software, and thus it is not expedient to leave unnecessary barriers in place that could be removed, especially if those issues are likely to confuse a large proportion of users (which this issue definitely is).

Considering that I already solved the issue for myself, as stated even in my original report, my submission of this issue to you repo has been almost entirely for your benefit. This is exactly the kind of usability and accessibility issue that causes the most harm to how widely used a tool becomes. The current behavior is highly misleading whenever anyone tests the plugin.

Telling me to not ever use Vim just because I suggested entirely for the benefit of your own project that you automated this issue away instead of leaving it sitting around to confuse lots of users is a very over-the-top and frankly rude response. Considering I mostly only ever took the time and effort to report this because I wanted to do so for your benefit I was quite shocked to see such a toxic response from you about it.

You are basically implying that I am too stupid to ever be a Vim user, despite me using it for almost all my text editing for probably almost a decade. I do sometimes use VS Code but always have Vim mode enabled when I use it and I use the console/terminal version a lot too though. One of my community submissions to an Android Vim self-quizzing app concerning obscure ways of editing text in Vim was even one of the most popular community-made question-answers pairs ever submitted to that app. Does that sound like I don't use Vim? It is extremely easy to not be aware of entire subsets of any complex software.

I have throughout this process sought to be constructive and thorough at every moment...

I will certainly be far less inclined to submit helpful information to you in the future though, and likewise will be far less likely to recommend your plugin(s) or any of your other work, given that this is apparently how you might treat people for merely earnestly trying to do their best to help your project(s) work as well as it can.

If you'd rather continue confusing lots of users and/or not documenting any likely pitfalls for users then that is your choice of course. I just do not understand why you would not do anything at all about it. Even just documenting the pitfall would be very easy.

Anyway though, regardless of all that, thanks for your time and efforts at least and have a good night/day.

This plugin has also existed for over 10 years, and you are the first one who consider this behavior as an issue. A grammar plugin relies on filetype being detected, and I don't see where this is unintuitive. I don't think it's a good default behavior to start the extension before ft detection takes effect, but if you need to, you can easily do it yourself, that's all I wanted to express. If you find this a significant obstacle, then Vim may not be recommended for you, and this advice is purely for your own good too. Of course, I was unaware that you have been using Vim for 10 years, and I apologize if my advice was inappropriate.

Thank you for responding and for the apology and such. Likewise, I certainly don't intend to cause you any trouble and am grateful that your plugin exists and works.

Regarding the plugin issue again though:

Many of the reports of users not being able to get the plugin working at all (which I saw multiple of in your issue tracker) may have actually originated from people opening Vim via vim for a quick test without realizing that it would cause the highlighter to break and not respond to the syntax language setting without :set ft=ext also being set.

Bugs are often not reported in a form that directly mirrors what the real cause is. Missing or misleading documentation can often be the cause of "bugs" and bugs interact with each other in complicated ways.

There is also the fact that the proportion of people who view or use something vs those who take the effort to comment or report something is very high. For example, on YouTube videos tens of thousands may watch something but only a couple dozen may comment on it. The same is true for all things in software and in other areas of life. There is a funnel effect where extremely common issues that are secretly eroding a program's audience reach may not be reported for a very long time or (sadly, most commonly probably) may not ever be reported at all.

Reiterating that you think I shouldn't use Vim just because of one single thing overlooked for one single person's Vim plugin is also not productive I think. No other editor comes close to being as effective for editing text for me, especially considering that I sometimes use obscure languages that have no viable support in other editors/IDEs and Vim is the only editor I've found with sufficient expressive capacity to still make working with languages that aren't supported much still pleasant and pragmatic.

When a programmer makes a habit of giving up on something the instant there's a problem with one thing then that is a recipe for getting much less done. Indeed, I have made that mistake before in the past out of my own sometimes misguided perfectionism (such as switching programming languages too often) and it is certainly not a practical way of living.

You could just add a couple sentences of documentation to the README.md or wherever else in order to prevent this confusion in the future and to ensure people aren't mislead when trying to quickly test the plugin. Just tell them they need to use :set ft=ext if testing via just vim without a file name. Why leave the issue unattended so that it can just recur in the future for some unknown (and I suspect probably large) number of users?

Users shouldn't be expected to be complete Vim masters, otherwise they could have written your plugin themselves already. Expecting mastery of Vim is thus circular. The whole point of plugins is to make things easier for people who don't know how to do something themselves (yet, at least) or don't want to take the effort.

This also reminds me of how the BSD operating systems have much better user documentation than Linux, to the point that sometimes I've read man pages for FreeBSD or OpenBSD just because the Linux docs were so opaque that the purpose of many commands wasn't even clear. This is despite the BSDs not even being the same operating system, which speaks volumes of the problem with Linux developers often having the attitude that documentation should be geared towards experts (which is completely backwards and creates a "chicken and egg" problem similar to requiring that all entry level programming jobs require 3+ years of already existing experience and so on). This kind of attitude towards things like documentation and ease of installation only harms the reach of your software and certainly doesn't make the software "smarter".

Strong communication and user empathy is perhaps the quality most correlated with true genius in software design in my experience. I do not understand why you would want to harm your own software's reach by delibrately not documenting it in a way that shows empathy and foresight for users who don't already understand every nook and cranny of the software... software they by definition cannot be expected to be experts in since they are only just now encountering it whenever they reach the landing page of any such software.

In any case though, continuing this conversation is becoming a fruitless drain on my time it seems.

I conclude by merely reiterating once more: You could write 1-3 sentences of documentation onto the plugin page to prevent this issue from recurring, since you don't want to change the way the software behaves to account for it automatically.

Anyway, sorry for my verbosity (that is my natural inclination), and have a great day/nigh/etc.

I'm grateful for your plugin's help but I am just very tired of this kind of highly prevalent attitude of disregard for empathy for users and for accessibility and usability.

In fact, I would like to point out that your accusation of my lack of user empathy is also inappropriate. You can review all my code repositories; I always design software from the user's perspective. I have never refused any improvements. If you submit a PR (that does not change default behavior but adds documentation or options), I would be happy to accept it. What I am unwilling to accept are users reporting bugs incorrectly due to a lack of understanding of vim's features (instead of first understanding the reasons and then proposing improvements).

In fact, I would like to point out that your accusation of my lack of user empathy is also inappropriate.

I never said your software was lacking in empathy as a whole, only that this specific point (lacking documentation or some automated system for this point) is analogous to a lapse of user empathy, by which I merely mean not accounting for accessibility and usability as fully as one could. There is certainly no intent to imply that that means hostility to users or anything else of that nature.

I do not understand why you are interpreting that as an accusation. There is nothing it my previous reply, nor indeed in any of my other comments whatsoever on this entire issue thread that imply that even slightly.

I am simply trying to communicate that there is a high chance that the lack of this issue being documented and accounted for is likely to have result in people falsely thinking the plugin is broken when in reality it seems to work well and is reliable and very useful. Do you not want as wide an audience as possible to use and benefit from your work?

My entire participation here on your issue tracker has always been and still is purely for your benefit. The issue is no longer a problem on my end, as I indicated already on my very first post of this issue.

As I have said multiple times now, I thank you for your time and efforts and am grateful for you making this plugin available to the public.

I have already spent an inordinate amount of time on what is an extremely trivial point by discussing this here, pure out of a sense of duty for following through on what I started and trying to be helpful and pay back my gratitude for the useful software you have created.

What I am unwilling to accept are users reporting bugs incorrectly due to a lack of understanding of vim's features (instead of first understanding the reasons and then proposing improvements).

As I said in my previous response (very clearly), I never implied that this was necessarily even a bug. I only said that this issue is a very easy way that someone could accidentally mislead themselves into thinking the highlighter isn't working when it actually is, by simply typing vim without a filename and thus making it not work.

This issue report is not a false report, since as I have stated from the very first post I made that it is merely a likely way by which many users are likely falsely being led to believe the plugin is broken when they test it.

Don't mischaracterize my constructive efforts here just because it is rhetorically/politically convenient for you response.

If you submit a PR (that does not change default behavior but adds documentation or options), I would be happy to accept it.

There is no chance that I will ever attempt to contribute to any of your projects or work in the slightest way in the future.

You have already waste an enormous amount of my time over a triviality that amounts to nothing more than fully documenting the basics of testing that your plugin works for users.

The fact that you are fighting me over such a trivial point indicates to me that staying away from you in the future is likely to be the wisest course of action.

I will not expose myself to any more of this absurdity.

I again (as I have repeatedly tried to make clear) thank you for your efforts and for the plugin, but I am done wasting my time talking to you.

Life has taught me (at great cost) to strictly avoid programmers who demonstrate this kind of interpersonal dynamics

I once spent literally years unable to even open a compiler without panicking due to what it was like in one of my prior programming jobs and I have been extra "allergic" to all forms of programmer toxicity ever sense. I will not expose myself to such psychologically harmful environments ever again if I have any power to avoid doing so.

You make demands of me, while I make no demands of you, yet you accuse me of wasting your time, shrug

luochen1990 / rainbow