I'm trying to define custom format rules, and for some reason clang-format reverts to the default rules, despite my file having no discernable mistakes.
More precisely, I'm trying to define use detailed rules for AlignConsecutiveDeclarations. This .clang-format file works :
AlignConsecutiveDeclarations: true
UseTab: "Always"
IndentWidth: 4
TabWidth: 4
And this one, which should give the exact same result, breaks and reverts to default format :
AlignConsecutiveDeclarations:
Enabled: true
UseTab: "Always"
IndentWidth: 4
TabWidth: 4
Am I doing something wrong ? Or is the extension broken ? My file seems completely valid to me, but I very well could be wrong. Also please note this is a deliberately reduced example, even when specifying more options, the rule still breaks the entire file.
I'm using VSCodium 1.75.0 on macOS 13.2.1, with the clangd extension version 0.1.23 ; as far as I have checked those are the latest versions of everything.
Looking at clangd's output in the console, this is what it says about the affected rule :
/Users/crysambrosia/Developer/Project/.clang-format:2:2: error: unknown enumerated scalar
Enabled: true
This changes to whatever the first variable is, no matter which one it is.
This option is available in clang-format 15. You seem to use the older clang-format. It's unclear from your question what clang-format do you uses. VSCode, macOS, clangd all their versions are unrelated to clang-format. Compare https://releases.llvm.org/14.0.0/tools/clang/docs/ClangFormatStyleOptions.html and https://releases.llvm.org/15.0.0/tools/clang/docs/ClangFormatStyleOptions.html in two browser tabs. You will see the difference.
Related
When Pylint warns me about something, how can I know what settings it's applying? And what section of .pylintrc this setting goes in?
For example:
Used builtin function 'map'. Using a list comprehension can be clearer. (bad-builtin) is because bad-functions in [BASIC] contains map.
Missing function docstring (missing-docstring) is conditional on docstring-min-length in [BASIC].
invalid-name obeys several [BASIC] settings: variable-rgx, method-rgx, module-rgx, etc.
I expected to find this information in the Pylint documentation but it generally doesn't provide this information. For example, there's no link from the documentation of missing-docstring or invalid-names to the applicable options. With bad-builtin, the information is easy to find, but only because it's from a specific extension. The Pylint message wiki has explanations about what the message means, but not what brought it up. The comments in pylint --generate-rcfile don't relate the settings to warning codenames either (nothing there explains that e.g. bad-functions influences the bad-builtin message).
The reason I'm asking this is that in many cases, Pylint's conventions don't match my project's needs and conventions, and I want to tune it rather than ignore specific instances or ignore messages wholesale (so I'm not looking for disable=!). So how do I find what to tune?
How do I find what to tune?
So it seems like you're asking about how you can determine the combination of factors that lead to a pylint message being raised. Using the bad-builtin example, a warning message that is not listed at all in the .pylintrc, a helpful verbose message would be:
bad-builtin: Used builtin function 'map'. Using a list comprehension can be clearer.
---> (Hypothetical) VERBOSE OUTPUT:
bad-builtin was raised because the bad-functions setting in your .pylintrc under the [BASIC] section contains the function map. If you want to "tune" this behavior look here.
Short answer: I am not sure this exists.
When you run pylint my_file.py the first thing it should tell you is the configuration file it is using. From there, you want to find the .pylintrc in use or else you want to create it. Otherwise it will be using the default configuration. If pylint does not tell you what config you are using you can figure out your current pylintrc configuration by running something like:
pylint --generate-rcfile &> output.txt
When you inspect output.txt it should look like this example pylintrc. It is organized into different categories. You can get more info on this without generating an rcfile by running pylint --long-help. The sections include:
[MASTER]
[MESSAGES CONTROL]
[REPORTS]
[BASIC]
[ELIF]
[TYPECHECK]
[FORMAT]
[MISCELLANEOUS]
[VARIABLES]
[LOGGING]
[SIMILARITIES]
[SPELLING]
[IMPORTS]
[DESIGN]
[CLASSES]
[EXCEPTIONS]
I am not sure what you mean by, "The Pylint message wiki has explanations about what the message means, but not what brought it up." When I run pylint on a file or in a code base it tells me exactly where the offending line is.
Then I usually either:
Fix the warning
Disable the warning
Modify the .pylintrc to meet my needs
If you want to tune a specific message type but you are not sure how to do so, then I think you are right that is something that could be better documented. The question: Is XYZ warning message 'tunable'? Or is the only option to fix OR disable? This page lists the pylint features but I do not see anything about bad built-in, for example, let alone the options that are available to apply to a message type.
UPDATE: I am not sure what version of pylint you are on, but it looks like the bad-builtin was specifically addressed in pylint version 1.6. I was going to say we should look at what is going on in the actual source code to generate this message, but I think that requires figuring out what version of pylint you are on first, then digging into the code, then figuring out how to tune it? I agree that the docs can be more clear on how to tune specific warnings:
The bad-builtin check was moved into an extension.
The check was complaining about used builtin functions which were
supposed to not be used. For instance, map and filter were falling
into this category, since better alternatives can be used, such as
list comprehensions. But the check was annoying, since using map or
filter can have its use cases and as such, we decided to move it to an
extension check instead. It can now be enabled through
--load-plugins=pylint.extensions.bad_builtin.
scholdoc (see scholarlymarkdown.com) is a fork of pandoc that has !FINALLY! easy referencing of figures/code blocks etc. build in - a central missing piece in pandoc.
Is there any straight forward way to force usage of scholdoc instead of the shipped pandoc binary when using knitr/rmarkdown in rstudio?
When I set in .Rprofile
options(
rstudio.markdownToHTML = function(inputFile, outputFile) {
system(
paste(
"~/.cabal/bin/scholdoc",
shQuote(inputFile),
"-o", shQuote(outputFile)))
})
as indicated here, this seems to work, but, as it is missing all manner of command line options used by the internal pandoc, produces HTML out of the box and will lead me down a painful way of getting all the CLI options right.
After studying some rmarkdown code, I have also tried to set the environment variable RSTUDIO_PANDOC to contain the path of scholdoc - to no avail.
Can anyone point out an easy way to do this with up-to-date rstudio/scholdoc installations?
I asked this long ago an thought that for completeness sake, I'd point out, that bookdown has stepped into the arena to provide cross referencing of figures etc. within rmarkdown documents.
after issuing install.packages('bookdown'), RStudio may be coerced to use it by adding the following to the YAML header of a document:
output:
bookdown::pdf_document2:
I am trying to create custom syntax highlighting for Kivy '.kv' files in the Geany editor. Although the specific filetype seems irrelavant to the issue I'm having, as any efforts I make at getting syntax highlighting to work for a custom filetype results in a completely non-highlighted file. I believe I have done my homework on this, and nothing seems to work.
I have added the following to ~/.config/geany/filetype_extensions.conf
Kivy=*.kv;
I also have a custom type definition file named 'filetypes.Kivy.conf' in ~/.config/geany/filedefs/. I have tried basing this file off several of the stock type definition files in /usr/share/geany/ and the file never gets any syntax highlighting applied in Geany. Right now, just for experimentation's sake, my 'filetypes.Kivy.conf' file looks like this:
# For complete documentation of this file, please see Geany's main documentation
[settings]
# default extension used when saving files
extension=kv
# single comments, like # in this file
comment_single=#
[keywords]
# all items must be in one line
primary=size canvas
secondary=pos size
[indentation]
width=4
# 0 is spaces, 1 is tabs, 2 is tab & spaces
type=0
This is very loosly based on the stock XML definition file, but like I said I've tried many other stock files. In many cases I only changed the 'extension=' value to kv and still no highlighting was applied, even though going to Document>Set Filetype in Geany and choosing virtually any random filetype (besides my custom entry) would yeild some sort of highlighting within my .kv file. This is even the case when using the unmodified contents of a stock definition which otherwise works fine on my .kv file when specifically selected in Geany!
Also, the Kivy filetype is listed and selected by default in Document>Set Filetype within Geany, so I must be doing something right here!
I realize this similar question has been asked, but the solutions seem irrelavent to my case, as I've tried every related topic on this and many other sites. My Geany version is 1.22 and I'm running Arch Linux. This is driving me nuts - any suggestions?
Thank you!
Set lexer_filetype= property in the [settings] section of your filetype file. Working highlighting requires that there is a lexer that could be used for highlighting the .kv-files.
For more info see http://www.geany.org/manual/#lexer-filetype
There are three important things to obey:
the configuration file should be placed in "~/.config/geany/filedefs"
the configuration file must have the extension ".conf" - otherwise it won't show up at all (the files in "/usr/share/geany/filesdefs", where I copied my base file from, do not have a ".conf" extension!)
you must set the "lexer_filetype" to an existing (presumably builtin) configuration; e.g. "lexer_filetype=Python"
Did a MediaWiki upgrade from 1.15.1 to 1.20.2 by following the simple update instructions (basically a new installation, copying over the old LocalSettings.php, update script and copying over images). Weird thing now is that all of the File: prefixes don't work. Instead the internal links to images is a "file:name of image" URL rather than "http://mediawiki address/index.php/File:name of image".
Anybody else getting this. Assuming it is something wrong with the old LocalSettings.php.
Ran the refreshLinks and refreshImageMetadata maintenance scripts without fixing the problem.
In the comments, you wrote that you have file: added to $wgUrlProtocols. This is very likely what's triggering the problem.
It looks like something has changed in the parser between MW 1.15 and 1.20 so that it's now parsing file:whatever as an external link (since it matches the file: prefix you've defined in $wgUrlProtocols) even if it's inside square brackets.
The obvious workaround would be to change the $wgUrlProtocols entry from file: to file:// so that it will only match if the slashes are there (as they should be, according to standard file: URL syntax). Since your on-wiki filenames are, presumably, very unlikely to begin with double slashes, they should not match this more specific prefix.
That said, this could still be considered a bug in MediaWiki. You may want to file a bug report about it, if there isn't one yet.
(Edit: Looks like Mark A. Hershberger filed one already.)
I'm trying to script the creation of a hyrbid (iso/joliet/hfs) iso with hdiutil. I can, for example, build an iso that hides things on the mac side like so:
hdiutil makehybrid -o foo.iso -hfs -joliet -iso -hide-hfs "{foo/bar.txt,foo/other.rtf}" foo
That's just an example of course, but the point is I can get it to hide say seven or eight example files I specify like that, with spaces in the filenames and verious dots and underscores.
But for my actual real-deal script I need to list in the neighborhood of 70 files, which does not seem to work when I test it. The whole string is being passed in correctly, I know this because when you turn on '-verbose' it prints the string and says it doesn't match anything.
So my best guess is it has something to do with the length of the string passed in, but I don't see anything in the docs indicating that. Any ideas? Think it's a bug? An alternative way of accomplishing this?
This is on Mac OS X 10.5.8, btw.
Two [UPDATE, make it Three] (untested) suggestions:
use the -plistin option to
specify all the parameters;
(better) try organizing the files to be
hidden into directories, if
necessary, so you can easily hide
them by directory-specific globs
rather than having to spell out each
file.
[UPDATE] you could try using mkisofs from cdrtools to make the ISO image. MacPorts has a supported port of it. It could be that the code in hdiutil was originally based on an earlier version. In any case, you have the advantage of access to the source code and perhaps figuring out what the limitations are.
P.S. There seems to be a couple of minor nits with the MacPorts port. In particular, the
man pages are installed in the wrong directory. [UPDATE: fixed in 3.00_1]