Filename conventions error stays after renaming

[ElsLommelen]

I'm not sure if my problem is related to checklist or RStudio, that's why I put it in the discussions section.

My package has a name including a symbol, and the project had the same name. As checklist gave a filename conventions error (File extension must be all lower case or numbers.), I changed the filename of the .Rproj file to a name that is allowed (but I kept the original name for the project folder and package name). I first restarted RStudio and ended up restarting my computer to make sure no leftovers of the original project name are present, but the error keeps appearing, and strangely it keeps mentioning the old .Rproj filename that doesn't exist anymore (as I changed it).
As in the header of RStudio the old name is also still present, I'm not sure this is an RStudio or a checklist issue. So I'm wondering: what is the best way to solve this? Is there a way to do it without changing the package name or folder name (which are more drastic changes).

As an additional test, I ran function check_package() in RGui, but this gave problems building the vignettes as Pandoc is apparently not available there.

[ThierryO]

Note that the error mentions the file extension not the filename. .Rproj is an allowed exception on this rule.

[ElsLommelen]

Good you mention, I hadn't noticed!
But why is the error showing up if this is an allowed exception?

[ThierryO]

That's hard to know without your code. At a minimum please provide the exact and complete error message. Another option is that you debug checklist::check_filename().

[ElsLommelen]

Ok, solved it:

• the error shows up because this regex can't deal with a . in a filename (so the wrong message is given, it is in fact the filename that is having an unaccepted character, not the extension), and
• the error kept coming back after removing this . in the filename because this line kept giving the filename with a . because I didn't commit the change yet (I wanted to test first before committing, which works fine in case of modifications in a file, but apparently not when renaming files)
• So after committing the error has gone

(When I was asked to give a package name with a dot, I was just curious how far I could go with it and which troubles I would encounter, but surprisingly, except for this dubious error that could be solved in the end, I didn't get any problems... Of course I will certainly discuss this name again before finalising the package, as it seems rather confusing for users. It was an interesting experiment, but I prefer to get rid of it before people start using it. ;-) )