Could you elaborate on the rationale for this change? Even if Name.Namespace is not fully correct, it may have been chosen in order to allow styles to highlight it in a different color than other names. This sometimes happens because it's impossible to design a set of token types that covers all relevant concepts in such a variety of languages as that of those Pygments supports.

I'm not sure how useful Name.Namespace is in the case of Ada. (I personally don't see a big advantage in highlighting the name in cases such as with System;.)

In any case, the current parsing is simply wrong when it comes to Ada aspects. Take this code, for example:

   procedure Initialize (Size : Integer)
     with
       Import        => True,
       Convention    => C,
       External_Name => "registerInterface_Initialize";

Here, the current version of the parser highlights the first name (Import) and doesn't highlight the remaining aspects. With the change I'm proposing, the mismatch disappears.

Sorry for the delay. I'm still not understanding this change well: the use keyword takes you in a state called 'import', but that state is not necessarily an import? Wouldn't at least a renaming be warranted? What is the 'import' state useful for now?

Is it possible to recognize the syntax better? Just looking at your example, it looks like a lookahead assertion [\w.]+(?!\s*=>) could do the trick. Is the syntax richer than that?

Another example of Ada aspects could be this:

   procedure Update (X : in out Integer)
     with Inline;

In this case, the lookahead you're suggesting wouldn't work.

OK. Then what is the 'import' state for now?

I'm not sure. I guess import can still be useful if full support for parsing Ada aspects gets implemented (which is not what this PR is doing here: it's just fixing a nasty highlighting issue in the least intrusive way possible).

Could you please let me know what's the next step from here?

This seems to be removing a feature in order to fix a bug related to the feature. I'm honestly not sure this is a good approach. It can be if the feature has no chance of being fixed.

Does it take a lot of work to fix this fully while retaining the special Name.Namespace special highlighting? If so, I'd rather see the 'import' state removed and a comment that parsing that is too tricky and thus not done.

Actually, before submitting this pull request, I already tried to come up with a solution that would include full support for Ada aspects. However, it seemed much more complex than anticipated.

Today, I tried to find a way to minimize the impact of my PR, but I haven't succeeded in that. To be honest, I doubt there's an easy way to solve this issue without a major refactoring of the Ada lexer.

SGTM now, but fails testing. Should test_ada2022.adb.output be test.adb.output?

Sorry, I just tried out removing the import state, but it just makes it worse. (When removing it, names such as Ada.Text_IO aren't recognized anymore; instead, it's tokenized to Name, Punctuation, Name, which is confusing IMHO.)

I'll merge this and add a comment.

Thanks!