>>>> * https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb4c4@xxxxxx/ >>>> https://lkml.org/lkml/2020/6/9/568 >>> >>> This one it complete nonsense. >> >> I hope that different views can be clarified for such a software situation >> in more constructive ways. > > You proposed essentially \( A \| B \) \( | C \| \) I suggested also another adjustment. Can additional minus characters be avoided if such a source code search pattern would be specified in a single line? > This is not valid syntax in the semantic patch language. I hope that a solution can be found by our discussion. > The branches of a \( \| \) have to be a valid expression, statement, type, etc, Such information can become more interesting for safe application of SmPL disjunctions. > not some random string of tokens. I got further imaginations in this software area. Will the handling of optional transformation parameters be clarified better? >> Patch reviews contain usual risks that suggestions are presented >> which can be still questionable. > > These are not "usual risks". You can easily test out your suggestion by > yourself to see if it produces valid code. Such an expectation can be reasonable in some cases. > If it doesn't, then don't make the suggestion. Would software limitations hinder any more improvements then? >>> like that putting all of the virtual declarations on >>> the same line would save space (it does, but who cares), >> >> It seems that you admit a possibly desirable effect. > > No, I don't consider the effect to be desirable. I propose to take another look at variations around source code verbosity. >> Your change acceptance is varying to your development mood >> (and other factors), isn't it? > > Not really. My "change acceptance" increases when the person reporting > them raises real problems that is blocking them in some work. I presented open issues accordingly. > And it decreases rapidly when the changes are almost all related to presumed > "efficiencies" that have no impact in practice. Change possibilities can get varying attention and corresponding development priorities. Regards, Markus
