> I'm almost positive the failing line of code is this one: https://github.com/rubberduck-vba/Rubberduck/blob/next/Rubberduck.Core/Navigation/CodeExplorer/CodeExplorerItemViewModel.cs#L44

I suspect what is happening is that a `Declaration` is passing the equity test there that shouldn't be. That would prevent the node from being removed from the active tree, and since the context on the `Declaration` is the one that is being evaluated against the now current parse tree, the context search f

Merge pull request #4817 from comintern/next

Settings hot-fix.

> Pretty self explanatory. We have the UI cultures hard coded in a lookup without a check, so if the xml file uses a culture that isn't available in RD, the binder fails and the settings form doesn't load.

Can be reproduced with a settings file containing something like `<Language Code="fu-br" />`

> Should have thought of it sooner - in SSMS, I quite like how they have those extra buttons:

Though Windows messagebox are already copy-able, it makes for better discoverability and provide a way for linking documentation.

> This might already be known but I could not find how to search known bugs:

When I try to rename standard module "Z-ObjectFactory" to "Z-Object-Factory" (or the other way around) the ok button in the rename-dialog is not shown.

Its seems like rubberduck dont want me to use "-" in any module name while ms-access has no problem with this.

> While dashes are legal, they would require the name to be bracketed:

```
Module-1.x() 'Syntax error
[Module-1].x() 'OK
Module_1.x() 'Doesn't need bracketing
Module1.x() 'Neither this
```

Wouldn't you rather have names that doesn't require bracketing?

> This is a standard module which I usually dont want to use the module name anyway.

And this is often not a matter of choice. If there are tons of legacy code which work with exactly this naming convention then Its not as easy to change.

Anyway: Rubberduck should not try to force me to do things just because it thinks its better for me.

> This is a standard module so I usually dont want to use the module name anyway.

And this is often not a matter of choice. If there are tons of legacy code which work with exactly this naming convention then Its not as easy to change.

Anyway: Rubberduck should not try to force me to do things just because it thinks its better for me.

> This is a standard module so I usually dont want to use the module name anyway.

And this is often not a matter of choice. If there are tons of legacy code which work with exactly this naming convention then its not as easy to change.

Anyway: Rubberduck should not try to force me to do things just because it thinks its better for me.

> This is a standard module so I usually dont want to use the module name anyway. I use "x()"...

And this is often not a matter of choice. If there are tons of legacy code which work with exactly this naming convention then its not as easy to change.

Anyway: Rubberduck should not try to force me to do things just because it thinks its better for me.

> This is a standard module so I usually dont want to use the module name anyway. I use "x()"...

And this is not a matter of choice. If there are tons of legacy code which work with exactly this naming convention then its not as easy to change.

Anyway: Rubberduck should not try to force me to do things just because it thinks its better for me.

> I agree that we should allow all legal names that do not cause a conflict sith an existing name.

Still, I would suggest to ask the user for confirmation for choices that require brackets in code.

> I agree that we should allow all legal names that do not cause a conflict with an existing name.

Still, I would suggest to ask the user for confirmation for choices that require brackets in code.

> Currently the code for validating the name looks like this:

https://github.com/rubberduck-vba/Rubberduck/blob/e5baebd879f0846e42b0aa76fa6bb299bffc8efb/Rubberduck.Core/UI/Refactorings/Rename/RenameViewModel.cs#L66-L70

The line `!NewName.Any(c => !char.IsLetterOrDigit(c) && c != '_')` is a bit too restrictive.

We most likely need a separate property `IsRestrictedName` which will then present the user with a yellow exclamation icon instead of red cross icon and thus bring the attention

> Implementations MUST support <Latin-identifier>. Implementations MAY support one or more of
the other identifier forms and if so MAY restrict the combined use of such identifier forms.

> This is host specific. From **3.3.5 Identifier Tokens**:

> Implementations MUST support <Latin-identifier>. Implementations MAY support one or more of
> the other identifier forms and if so MAY restrict the combined use of such identifier forms.

In Excel, identifiers containing `-` are restricted, so implementing this would require name validation for each VBA host. If this _is_ implemented, I'd propose adding a `NonPortableIdentifierInspection` that would flag uses of identifiers tha

> This is host specific. From **3.3.5 Identifier Tokens**:

> Implementations MUST support <Latin-identifier>. Implementations MAY support one or more of
> the other identifier forms and if so MAY restrict the combined use of such identifier forms.

In Excel, identifiers containing `-` are illegal, so implementing this would require name validation for each VBA host. If this _is_ implemented, I'd propose adding a `NonPortableIdentifierInspection` that would flag uses of identifiers that f

> "that would flag uses of identifiers that fall into the "MAY" category of the specification."

I think it would also make sense to warn against using them because of reasons (as specified in chat).

> This is host specific. From **3.3.5 Identifier Tokens**:

> Implementations MUST support &lt;Latin-identifier>. Implementations MAY support one or more of
> the other identifier forms and if so MAY restrict the combined use of such identifier forms.

In Excel, identifiers containing `-` are illegal, so implementing this would require name validation for each VBA host. If this _is_ implemented, I'd propose adding a `NonPortableIdentifierInspection` that would flag uses of identifiers tha

> I reclassified this because, first, it really requires to know how to handle the change in a lot of places in RD and, second, because this is not a bug but a know and at one point probably intentional quirk of the setup of the type enums in RD. (It also applies to user forms.)

That no test broke is not surprising since we generally do not add tests regarding document modules to test fixtures not explicitly sealing with host specific features.