Surprenant, parce que l'auteur indique que clang est supporté (mais peut-être ta version est-elle trop vieille?). Quels étaient tes messages d'erreur?
C'est juste qu'il ne me trouve pas certains includes comme <cstdint> (clang 3.5), je ne pense pas que ce soit un bug. J'ai jamais fait de C++ sur OpenBSD, mais je suppose que pour quelqu'un qui sait, ça doit être juste lancer make avec un flag en plus.
Quel fichier, pour quel include? Il devrait être possible de faire ça plus proprement et de soumettre un patch.
Non, ça c'est dans file.cc, où une façon non portable pour récupérer le chemin de l'exécutable est utilisée, mais c'est pas un bug : c'était prévu pour lancer une erreur si l'OS n'est pas Linux, Cygwin ou OSX. Comme j'avais pas envie de réfléchir à comment on peut faire sur OpenBSD ça facilement, je l'ai mis en dur. A priori j'aurai pensé à argv pour ce genre de choses.
Ce que tu décris est plutôt une problématique d'encodage amha.
Pas vraiment, qu'un éditeur (ou langage) supporte utf8 pour beaucoup d'opérations ne veut pas dire que ça va être aussi le cas de ses expressions régulières, elles travaillent probablement au niveau des "bytes" sans se soucier d'encodage.
[^] # Re: lequel
Posté par anaseto . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. Évalué à 2.
C'est juste qu'il ne me trouve pas certains includes comme
<cstdint>(clang 3.5), je ne pense pas que ce soit un bug. J'ai jamais fait de C++ sur OpenBSD, mais je suppose que pour quelqu'un qui sait, ça doit être juste lancer make avec un flag en plus.Non, ça c'est dans
file.cc, où une façon non portable pour récupérer le chemin de l'exécutable est utilisée, mais c'est pas un bug : c'était prévu pour lancer une erreur si l'OS n'est pas Linux, Cygwin ou OSX. Comme j'avais pas envie de réfléchir à comment on peut faire sur OpenBSD ça facilement, je l'ai mis en dur. A priori j'aurai pensé à argv pour ce genre de choses.Pas vraiment, qu'un éditeur (ou langage) supporte utf8 pour beaucoup d'opérations ne veut pas dire que ça va être aussi le cas de ses expressions régulières, elles travaillent probablement au niveau des "bytes" sans se soucier d'encodage.