Dans le plug-in Visual Studio 2010 "Productivité Power Tools" (qui est génial), vous pouvez configurer des onglets de fichiers pour être codé couleur en fonction des expressions régulières.
J'ai une regex pour différencier la couleur de l'onglet des fichiers d'interface ( ImyInterface.cs) à partir de fichiers .CS réguliers: p> Malheureusement, cela code de couleur tout fichier qui commence par un capital "i" (informations.cs, par exemple). < / p> Comment cette regex pourrait-elle être modifiée pour inclure uniquement les fichiers où la première lettre est "i" et la deuxième lettre n'est pas minuscule? P> P>
5 Réponses :
Que diriez-vous:
IMyInterface.cs // matches, MyInterface IB.cs // B IBa.cs // Ba IC1.cs // C1 I.cs // don't Information.cs // don't
Votre regexp devrait fonctionner tel quel. Il est possible qu'il soit exécuté dans Ignorer le mode em>. Essayez de désactiver ce mode à l'intérieur de votre REGEXP avec (? - i) code>:
Votre idée est très bonne, mais l'expression de l'OP n'est pas correcte. En général, d'accord, mais devrait être réécrit: groupe de symboles inutiles; dépassé, des captures en double, etc.
@Abatishchev: Vous avez raison, ce n'est pas propre, mais cela fonctionne. J'ai fait une copie et une pâte paresseux. En ce qui concerne la partie «^» au début, tout le monde suggère, je ne peux pas apporter l'hypothèse que la chaîne d'entrée contient uniquement un nom de fichier et non le chemin de fichier complet (je n'utilise pas d'outils électriques).
Les noms de fichiers sous Windows ne sont pas sensibles à la casse, de manière évidente que les outils électriques utiliseront une correspondance insensible à la casse. P>
Essayez ceci définit la case insensible d'abord. P>
. * code> correspond aux espaces blancs et autres caractères inutiles
@Abatischev: BTW, si vous souhaitez être complètement conforme, vous devez considérer qu'un nom de fichier dans Visual Studio peut contenir n'importe quel caractère autorisé par Windows pour un nom de fichier, c'est-à-dire n'importe quel caractère qui n'est pas: /?: & *: & * " <> | #%, les caractères de contrôle unicode et les caractères de substitution, les noms réservés au système et ne sont pas "." ou "..". Cela permet aux espaces, aux traits de soulignement, etc. Dans ce cas particulier, il n'est probablement pas nécessaire de valider la complète Conformité du nom du fichier - Si le fichier existe, il est déjà conforme, tout ce dont nous avons besoin est de vérifier si cela commence par quelque chose et se termine par quelque chose.
i basé à la mienne des motifs par défaut placés là-bas et utilisé Et vous ne pouvez pas les redéfinir ou les supprimer, il est donc un peu fideux de bien faire fonctionner la commande ... p>
FWIW, je ne pense pas que la question de la sensibilité ( ^ i [az]. * \. CS [] * (\ [Lecture seule \])? $ code> - Je pense qu'il y a Est-ce qu'une question de priorité, cependant, de sorte que si vous laissez le correspondeur de modèle code> par défaut code> et ajoutez le vôtre à la fin, vous pourriez avoir le vôtre à la fin, car il correspondait au général un premier. p>
(? - I code>) fait toute différence. P>
Je ne suis pas pirate de pirate de regex, mais on dirait que cela devrait déjà - je suis surpris que ce ne soit pas. C'est-à-dire que si @ @ BoltClock's Modifier était d'ajouter dans la partie [A-Z] {1} de la regex ...
On dirait que le plugin fait une correspondance insensible à la casse, ne pensez pas que vous puissiez faire à ce sujet.
REGEX R = NOUVELLE REGEX (Modèle, Regexoption.ignorecase) Code>Oui, l'expression teste bien pour moi aussi. Cela pourrait être plus simple mais il n'y a rien de mal avec ça.
Non, je me trompe, je pense qu'il y a un moyen de le faire dans la tendance, je ne pouvais tout simplement pas se souvenir de la façon de le faire, pas sûr de la priorité. Voir la réponse.
@Zannjaminderson: Nah, tout ce que j'ai fait était Reag :)