Well, seems this is one of those discussions that can go on forever and no one can really make a solid enough argument to support their point of view. As Emacs 26.1 is out this can't really be changed for about a year - Joao made a good point here. Frankly, I don't really care at all whether you decide to change this or not. I don't use flymake and I don't plan to use it, so it's all the same to me. I like the current state of affairs, as I'm passionate about exposing more people to good programming style, but I don't really have time to waste on this debate. I'd rather spend my time elsewhere fixing some actual problems. On Sat, 16 Jun 2018 at 22:47, Petko Bordjukov wrote: > > So, you're basically saying that it's a big deal to write class > documentation and that it's just some noise (!!!) and that some default > line length (which is 80 by default in so many languages and you can > obviously change) is some big problem. > > No. I am not saying that. I am saying that Emacs is by default > enforcing an unofficial and intrusive (as I illustrated -- every > single line of the simple data model is underlined because there is no > class documentation) style guide on all files in projects, > _irregardless if they've chosen to adopt said style guide_. This is > the key here. I am not commenting on the RuboCop config and if it > should raise such warnings. If I were, I'd have filed an issue with > RuboCop. As per this, I will not address your comments on whether > writing class documentation and adhering to 80 chars per line is 'a > big deal'. > > > Frankly, as far as I'm concerned you're making some counter arguments to > your points. I acknowledge that some aspects of the default config are > controversial and that's going to addressed soon, but I think that also > applies to most non-trivial lint tools. In the end of the day the value you > get out of project consistency always outweighs some small initial > investment in a tweaking some config. > > I am not arguing for/against general linter use or specifically > RuboCop use, so I'm not sure this is relevant in this discussion. > Maybe you could clarify? > > > > > Why would have RuboCop installed and not what to use it? > > > > Because you are working both on projects that have adopted RuboCop and > > > projects that have not? In my experience the latter are more than the > > > former. > > > But that's only your experience, so your comment is subjective by > default. :-) > > I was not opining -- I was giving you an example why you'd have > RuboCop installed without wanting to use it in a particular project. > > > I haven't seen almost any projects that don't use RuboCop (especially in > a professional setting) in recent years and looking at its rising > popularity I guess the usage will grow. > > While this is actually a subjective opinion, an objective one is that > pretty much each project that uses RuboCop has their own version of a > style guide. Why then should the default RuboCop style guide be > enforced by default for projects that have not adopted RuboCop at all? > > > That's not true. I'm an Emacs user (obviously) and I've carefully > checked that layout config is Emacs compatible. > > Though it is somewhat outside this discussion, I am really not making > this up: https://social.petko.me/@petko/100216195543129951 > > Cheers, > P. > > On Sat, Jun 16, 2018 at 12:36 PM, Bozhidar Batsov > wrote: > > Btw, I forgot to comment on the screenshot. So, you're basically saying > that > > it's a big deal to write class documentation and that it's just some > noise > > (!!!) and that some default line length (which is 80 by default in so > many > > languages and you can obviously change) is some big problem. > > > > Frankly, as far as I'm concerned you're making some counter arguments to > > your points. I acknowledge that some aspects of the default config are > > controversial and that's going to addressed soon, but I think that also > > applies to most non-trivial lint tools. In the end of the day the value > you > > get out of project consistency always outweighs some small initial > > investment in a tweaking some config. > > > > On Sat, 16 Jun 2018 at 12:31, Bozhidar Batsov > wrote: > >> > >> > >> > >> On Sat, 16 Jun 2018 at 12:07, Petko Bordjukov > wrote: > >>> > >>> > So... First of all, there is the variable > >>> > ruby-flymake-use-rubocop-if-available, to satisfy the individual > preference > >>> > to turn Rubocop off. > >>> > >>> I know, I propose this to be changed to off by default. > >>> > >>> > Why would have RuboCop installed and not what to use it? > >>> > >>> Because you are working both on projects that have adopted RuboCop and > >>> projects that have not? In my experience the latter are more than the > >>> former. > >> > >> > >> But that's only your experience, so your comment is subjective by > default. > >> :-) > >>> > >>> > >>> > You know this thing is configurable, right? > >>> > >>> I am aware of that, yes. I propose the default setting to be changed. > >> > >> > >> Or you can simply use `.dir-locals.el` per project as you just agreed > that > >> some project use RuboCop and some don't. I haven't seen almost any > projects > >> that don't use RuboCop (especially in a professional setting) in recent > >> years > >> and looking at its rising popularity I guess the usage will grow. > >>> > >>> > >>> > The vast majority of checks are actually pretty much community > standard > >>> > - Ruby produces only a minimal amount of lint warnings, RuboCop has > extended > >>> > linting but also a lot of code style checking functionality. > >>> > >>> I do not agree, especially with the 'pretty much community standard' > >>> part. If they were, they'd be part of the warnings incorporated in > >>> Ruby. > >> > >> > >> That's a pretty flawed reasoning. I've seen no programming language that > >> would incorporate this upstream, as this would tie the language > development > >> cycle to the tooling development cycle. Linters are supposed to be > >> downstream projects that can evolve independently (it's the same with > all > >> Java linters, Python linters, ES linters, etc). > >> > >>> > >>> To add to that, many of the style-related warnings are in > >>> conflict with ruby-mode's default behaviours, which makes this issue > >>> even more annoying (eg hash indentation). > >> > >> > >> That's not true. I'm an Emacs user (obviously) and I've carefully > checked > >> that layout config is Emacs compatible. > >> > >>> > >>> > >>> Here is an example of the modifications necessary for even a simple > >>> file in a project that does not adopt RuboCop's style guide: > >>> https://social.petko.me/@petko/100213685659065450 > >>> > >>> Again, I appreciate this feature, but do not leave it on by default -- > >>> it will be just another bad Emacs default. > >> > >> > >> Flycheck has used the very same default for 5 years now and people have > >> been fine with this (which leads me to believe that the default is > liked by > >> most people, as flycheck is super popular these days). You should really > >> understand that we can't be making decisions based on the > >> opinion of a single person. If there are enough reports that something's > >> problematic, we'd certainly try to address this, but right now it just > seems > >> that we have your highly subjective POV. > >> > >> I'm happy that flymake is following the example of Flycheck and that > we're > >> putting some useful tools in the hands of Emacsers - that's quite > different > >> from what we've been doing historically here and there. > >> > >>> > >>> > >>> Cheers, > >>> P. > >>> > >>> On Fri, Jun 15, 2018 at 8:54 PM, Bozhidar Batsov > >>> wrote: > >>> > Why would have RuboCop installed and not what to use it? > >>> > > >>> > I think the check is perfectly fine in its current state, especially > >>> > given > >>> > the fact that you can simply disable RuboCop with the defcustom > >>> > mentioned. > >>> > > >>> >> Since most if not all of the warnings that > >>> >>> Rubocop generates are not raised by Ruby I consider them not > adopted > >>> >>> by > >>> >>> the Ruby community by default. > >>> > > >>> > You know this thing is configurable, right? ;-) The vast majority of > >>> > checks > >>> > are actually pretty much community standard - Ruby produces only a > >>> > minimal > >>> > amount of lint warnings, RuboCop has extended linting but also a lot > of > >>> > code > >>> > style checking functionality. > >>> > > >>> > I don't really want us to check for RuboCop config files (those are > >>> > hierarchical and won't necessarily be in the root of your current > >>> > project > >>> > anyways) - I think the current check + config is sufficient. > >>> > > >>> > On Fri, 15 Jun 2018 at 17:16, Dmitry Gutov wrote: > >>> >> > >>> >> On 6/8/18 9:42 PM, João Távora wrote: > >>> >> > Petko Bordjukov writes: > >>> >> > > >>> >> >> Emacs 26.1 enables flymake-rubocop by default if the rubocop > >>> >> >> executable > >>> >> >> is present in the system. Since most if not all of the warnings > >>> >> >> that > >>> >> >> Rubocop generates are not raised by Ruby I consider them not > >>> >> >> adopted by > >>> >> >> the Ruby community by default. Based on that, I propose that > either > >>> >> >> using Rubocop by default is turned off, or at least a more > >>> >> >> inteligent > >>> >> >> per-project Rubocop detection scheme is implemented. > >>> >> >> > >>> >> > Paging Dmitry :-) > >>> >> > >>> >> So... First of all, there is the variable > >>> >> ruby-flymake-use-rubocop-if-available, to satisfy the individual > >>> >> preference to turn Rubocop off. > >>> >> > >>> >> Second, what kind of per-project detection scheme? I suppose we can > >>> >> abort if no ruby-rubocop-config file is found. That would certainly > >>> >> work > >>> >> for me, but would maybe conflict with the general usage of Rubocop > out > >>> >> there (but probably not). > >>> >> > >>> >> Maybe Bozhidar has something to say on this? >