-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conditional styling #365
Comments
Hi @jayhesselberth. I wonder if it is desirable to have source code with a lot of these comments in it. Personally, I think I would not like it that much. But there might be people who would find it useful. |
For your special use case, you can also use the option |
Quick stab at this. I may be off-base but once tokens are flagged then I think you just need to make the transformers aware of the style value (T/F). library(tidyverse)
library(Rcpp)
nostyle <- Rcpp::cppFunction(
'LogicalVector fn(DataFrame x) {
CharacterVector text = x["text"] ;
LogicalVector style(text.size()) ;
int nostyle = 0;
for (int i = 0; i < text.size(); i++) {
if (text[i] == "# nostyle start") {
nostyle++ ;
style[i] = false ;
} else if (text[i] == "# nostyle end") {
nostyle-- ;
style[i] = false ;
} else if (nostyle == 0) {
style[i] = true ;
} else {
style[i] = false ;
}
}
return style ;
}'
)
text <- c('
x <- "text"
# nostyle start
y<- "nostyle"
# nostyle end
z <- "text"
')
styler:::tokenize(text) %>%
mutate(style = nostyle(.)) %>%
select(token, text, style)
#> # A tibble: 20 x 3
#> token text style
#> <chr> <chr> <lgl>
#> 1 expr "" TRUE
#> 2 SYMBOL x TRUE
#> 3 expr "" TRUE
#> 4 LEFT_ASSIGN <- TRUE
#> 5 STR_CONST "\"text\"" TRUE
#> 6 expr "" TRUE
#> 7 COMMENT # nostyle start FALSE
#> 8 expr "" FALSE
#> 9 SYMBOL y FALSE
#> 10 expr "" FALSE
#> 11 LEFT_ASSIGN <- FALSE
#> 12 STR_CONST "\"nostyle\"" FALSE
#> 13 expr "" FALSE
#> 14 COMMENT # nostyle end FALSE
#> 15 expr "" TRUE
#> 16 SYMBOL z TRUE
#> 17 expr "" TRUE
#> 18 LEFT_ASSIGN <- TRUE
#> 19 STR_CONST "\"text\"" TRUE
#> 20 expr "" TRUE Created on 2018-03-07 by the reprex package (v0.2.0). |
Thanks for looking into this. Yes, I was thinking about a flag too but this would require to adapt large parts of styler, making things more complicated and probably lead to significant slowdown for An alternative approach would be to collapse all tokens between flags into a string (which would make it invisible for formatting in some sense), applying all rules and serialise. I guess that might be more pragmatic. You can even implement that yourself via transformer functions I think. Just put these transformer function first (see However, instead of implementing such functionality, I think I want to put my energy into changing styler so there are ways around flagging, i.e. by adapting rules such that they are flexible enough to accommodate edge cases. Have you given the Maybe @krlmlr can give his insights on the topic and whether it would be worth implementing conditional styling? If yes, maybe you could comment on my considerations. |
Yes I think the strict = FALSE approach is fine for some cases but is only useful when selecting and styling a few lines of a file. I was thinking of the more robust approach where you can conditionally turn styling off for sections and then style the whole file/package. The flattening approach sounds like it is worth exploring. I can take a look sometime soon. This isn't urgent but struck me as something that would improve styler utility. I increasingly use the the nocov start/end strategy and it saves a lot of time hand-picking where to apply rules. |
We have an issue for detecting alignment (and leaving it alone): #258. I agree with Lorenz that detecting and consistently styling aligned blocks of code is a better time investment. To me, the presence of markers contradicts the idea of improving code style. Maybe we could support turning off styling for individual functions with a configuration file? |
I don't think turning off and on for individual functions is meeting the requirements layed out by @jayhesselberth. If we do it, it should be comprehensive. |
@lorenzwalthert This would probably only be possible by a "no-style" tag or similar as proposed in this issue? Or is there another workaround besides turning off all the spacing rules? |
Have you tried |
This helps but also turns off other rules that we want to have applied. In the end I guess I've found the rule I was searching for now :)
|
We could modify that function to check if all other elements of the nest (that is, the context) are aligned are aligned and if so, not modify any spaces. So allignment would be preserved if it is already consistent. Not sure if it is as easy as it sounds though. Have to check. |
Sounds like a good idea! I guess this would solve the problem in this case. |
Let's continue over at #258. |
Opened because of a request by @michaelquinn32. |
Thanks!!! |
After giving it some more thought, I believe there could be a way to implement this feature without creating much complication and slow-down. Here is the proposal: The user should be able to supply code with like this: # stylerignore start
code = "like this"
# stylerignore stop And later on also Here is how to make sure this code does not get styled:
We need to take care of:
@krlmlr and others: what do you think? I believe this is much smarter than trying to check within every transformer / rule if a certain token should be modified. I still don't like the feature but since this seems not so complicated to implement and a few people think it's really helpful, why not? Related tools such as lintr or black also have it. |
I don't mind this feature, but I'm not sure I'd use it. |
This works for me, with two notes:
Thanks for working on this! |
Ok. I guess the comment format could be specified via an R option. |
We have a draft :-). Feedback welcome, please in the PR (#560), not here in the issue. remotes::install_github("lorenzwalthert/styler@stylerignore") |
It would be nice to be able to turn styling on and off for different sections of a file.
There are cases where the greedy behavior tries to "fix" intentional formatting. Consider this example, where many assignments are organized to emphasize the assignment value.
https://github.com/r-lib/pkgdown/blob/master/R/rd-html.R#L390
The
nocov start/nocov end
behavior of covr might be one approach. So styling of this:would generate:
The text was updated successfully, but these errors were encountered: