Je commence à me documenter sur le sujet mais dors et déjà je
souhaiterais avoir un maximum d'informations concernant les
text-properties et les overlays.
Dans quel(s) cas est-il préférable d'utiliser l'une ou l'autre
des solutions ? Quels sont les impacts sur les performances
globales ?
Bref, à tous ceux qui en connaissent assez sur le sujet, qu'ils
s'expriment ;)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
drkm
Xavier Maillard wrote:
Dans quel(s) cas est-il préférable d'utiliser l'une ou l'autre des solutions ? Quels sont les impacts sur les performances globales ?
Il y a d'abord une différence fondamentale entre les deux. Les tprops [1] sont aux caractères ce que les plists [2] sont aux symboles. Je dirais que les overlays sont leur généralisation aux régions. C'est à dire qu'une tprop est affectée à *un* caractère, quand un overlay caractérise un suite de caractères dans un buffer (je ne pense pas que les overlays soient applicables aux strings, contrairement aux tprops).
La différence fondamentale se situe donc ici. Tu peux avoir deux overlays qui "se touchent" dans un buffer, tout en pouvant les distinguer toujours, même s'ils représentent les mêmes properties. Par exemple si le permier couvre les position 1 à 10 et le second de 11 à 20. Avec les tprops, par contre, tu peux juste savoir que les caractères de 1 à 20 ont les mêmes properties.
Imagine que tu utilises une property pour identifier le résultat de l'analyse syntaxique d'un buffer (Semantic utilise effectivement des overlays). Imagine également que tu as la même classe syntaxique pour les chaînes et leurs délimiteurs. Si ton buffer contient :
"une chaîne""une seconde"
avec les tprops, tu verras juste qu'à l'ensemble est affectée la même classe. Avec des overlays, tu en verras deux.
Et les tprops sont à cet égard des fois lourdes à manipuler. Il faut toujours rechercher l'endroit suivant où une ou plusieurs des properties changent. Avec les overlays, tu peux obtenir les positions de début et de fin d'overlay.
Au niveau des performances, je ne sais pas. Il me semble avoir vu quelques fois que les overlays n'étaient pas très performants. Mais Semantic, qui les utilise intensivement, n'a pas l'air d'en soufrir énormément. C'est en effet une chose que j'aimerais regarder dans les sources (l'implémentation des overlays vs/ celle des tprops), mais je n'en ai pas encore eu le temps.
Intuitivement, d'après ce que j'imagine naïvement de leurs implémentations respectives, il ne devrait pas y avoir de /grandes/ différences.
ÀMHA, il faut d'abord savoir ce que tu veux faire. Si le but est d'assigner des properties à de grandes régions, ou que le fait de pouvoir aisément et sans ambiguïté identifier les bornes des régions auxquelles s'appliquent les properties, alors les overlays sont tes amis. Si le but est d'assigner des properties à des caractères pris individuellement, et que le problème des bornes ne devrait pas se poser, les tprops sont toutes désignées.
Est-ce une recherche académique, ou as-tu une utilisation précise derrière la tête ?
[1] C'est une abréviation que j'utilise pour désingner les text properties. Je ne l'ai jamais rencontré autre part, mais elle est bien pratique lorsque l'on parle souvent de text properties. Je me permet donc de l'utiliser ici.
[2] Les property list. Là, je pense qu'il s'agit de l'abréviation consacrée.
--drkm
Xavier Maillard wrote:
Dans quel(s) cas est-il préférable d'utiliser l'une ou l'autre
des solutions ? Quels sont les impacts sur les performances
globales ?
Il y a d'abord une différence fondamentale entre les deux. Les
tprops [1] sont aux caractères ce que les plists [2] sont aux
symboles. Je dirais que les overlays sont leur généralisation aux
régions. C'est à dire qu'une tprop est affectée à *un* caractère,
quand un overlay caractérise un suite de caractères dans un buffer
(je ne pense pas que les overlays soient applicables aux strings,
contrairement aux tprops).
La différence fondamentale se situe donc ici. Tu peux avoir deux
overlays qui "se touchent" dans un buffer, tout en pouvant les
distinguer toujours, même s'ils représentent les mêmes properties.
Par exemple si le permier couvre les position 1 à 10 et le second de
11 à 20. Avec les tprops, par contre, tu peux juste savoir que les
caractères de 1 à 20 ont les mêmes properties.
Imagine que tu utilises une property pour identifier le résultat de
l'analyse syntaxique d'un buffer (Semantic utilise effectivement des
overlays). Imagine également que tu as la même classe syntaxique
pour les chaînes et leurs délimiteurs. Si ton buffer contient :
"une chaîne""une seconde"
avec les tprops, tu verras juste qu'à l'ensemble est affectée la
même classe. Avec des overlays, tu en verras deux.
Et les tprops sont à cet égard des fois lourdes à manipuler. Il
faut toujours rechercher l'endroit suivant où une ou plusieurs des
properties changent. Avec les overlays, tu peux obtenir les positions
de début et de fin d'overlay.
Au niveau des performances, je ne sais pas. Il me semble avoir vu
quelques fois que les overlays n'étaient pas très performants. Mais
Semantic, qui les utilise intensivement, n'a pas l'air d'en soufrir
énormément. C'est en effet une chose que j'aimerais regarder dans
les sources (l'implémentation des overlays vs/ celle des tprops), mais
je n'en ai pas encore eu le temps.
Intuitivement, d'après ce que j'imagine naïvement de leurs
implémentations respectives, il ne devrait pas y avoir de /grandes/
différences.
ÀMHA, il faut d'abord savoir ce que tu veux faire. Si le but est
d'assigner des properties à de grandes régions, ou que le fait de
pouvoir aisément et sans ambiguïté identifier les bornes des
régions auxquelles s'appliquent les properties, alors les overlays
sont tes amis. Si le but est d'assigner des properties à des
caractères pris individuellement, et que le problème des bornes ne
devrait pas se poser, les tprops sont toutes désignées.
Est-ce une recherche académique, ou as-tu une utilisation précise
derrière la tête ?
[1] C'est une abréviation que j'utilise pour désingner les
text properties. Je ne l'ai jamais rencontré autre part,
mais elle est bien pratique lorsque l'on parle souvent de
text properties. Je me permet donc de l'utiliser ici.
[2] Les property list. Là, je pense qu'il s'agit de
l'abréviation consacrée.
Dans quel(s) cas est-il préférable d'utiliser l'une ou l'autre des solutions ? Quels sont les impacts sur les performances globales ?
Il y a d'abord une différence fondamentale entre les deux. Les tprops [1] sont aux caractères ce que les plists [2] sont aux symboles. Je dirais que les overlays sont leur généralisation aux régions. C'est à dire qu'une tprop est affectée à *un* caractère, quand un overlay caractérise un suite de caractères dans un buffer (je ne pense pas que les overlays soient applicables aux strings, contrairement aux tprops).
La différence fondamentale se situe donc ici. Tu peux avoir deux overlays qui "se touchent" dans un buffer, tout en pouvant les distinguer toujours, même s'ils représentent les mêmes properties. Par exemple si le permier couvre les position 1 à 10 et le second de 11 à 20. Avec les tprops, par contre, tu peux juste savoir que les caractères de 1 à 20 ont les mêmes properties.
Imagine que tu utilises une property pour identifier le résultat de l'analyse syntaxique d'un buffer (Semantic utilise effectivement des overlays). Imagine également que tu as la même classe syntaxique pour les chaînes et leurs délimiteurs. Si ton buffer contient :
"une chaîne""une seconde"
avec les tprops, tu verras juste qu'à l'ensemble est affectée la même classe. Avec des overlays, tu en verras deux.
Et les tprops sont à cet égard des fois lourdes à manipuler. Il faut toujours rechercher l'endroit suivant où une ou plusieurs des properties changent. Avec les overlays, tu peux obtenir les positions de début et de fin d'overlay.
Au niveau des performances, je ne sais pas. Il me semble avoir vu quelques fois que les overlays n'étaient pas très performants. Mais Semantic, qui les utilise intensivement, n'a pas l'air d'en soufrir énormément. C'est en effet une chose que j'aimerais regarder dans les sources (l'implémentation des overlays vs/ celle des tprops), mais je n'en ai pas encore eu le temps.
Intuitivement, d'après ce que j'imagine naïvement de leurs implémentations respectives, il ne devrait pas y avoir de /grandes/ différences.
ÀMHA, il faut d'abord savoir ce que tu veux faire. Si le but est d'assigner des properties à de grandes régions, ou que le fait de pouvoir aisément et sans ambiguïté identifier les bornes des régions auxquelles s'appliquent les properties, alors les overlays sont tes amis. Si le but est d'assigner des properties à des caractères pris individuellement, et que le problème des bornes ne devrait pas se poser, les tprops sont toutes désignées.
Est-ce une recherche académique, ou as-tu une utilisation précise derrière la tête ?
[1] C'est une abréviation que j'utilise pour désingner les text properties. Je ne l'ai jamais rencontré autre part, mais elle est bien pratique lorsque l'on parle souvent de text properties. Je me permet donc de l'utiliser ici.
[2] Les property list. Là, je pense qu'il s'agit de l'abréviation consacrée.
--drkm
Xavier Maillard
On 7 aoû 2005, drkm wrote:
Xavier Maillard wrote:
> Dans quel(s) cas est-il préférable d'utiliser l'une ou > l'autre des solutions ? Quels sont les impacts sur les > performances globales ?
ÀMHA, il faut d'abord savoir ce que tu veux faire. Si le but est d'assigner des properties à de grandes régions, ou que le fait de pouvoir aisément et sans ambiguïté identifier les bornes des régions auxquelles s'appliquent les properties, alors les overlays sont tes amis. Si le but est d'assigner des properties à des caractères pris individuellement, et que le problème des bornes ne devrait pas se poser, les tprops sont toutes désignées.
Je pense que je suis dans la première situation. Pour tout dire je suis en train d'écrire une sorte de client dans le genre de ERC mais pas pour l'IRC.
A ce propos, ERC semble utiliser des tprops, c'est pourquoi je me suis poser cette question.
Est-ce une recherche académique, ou as-tu une utilisation précise derrière la tête ?
Un peu les deux. Disons que j'ai quelques projets en stocks dont deux qui vont réclamer ce genre de choses.
Et comme je veux comprendre avant de faire quoique ce soit, je me renseigne ;)
En lisant le elisp manual (ah qu'est-ce que j'aimerais m'en trouver une copie papier...), j'ai cru aussi comprendre que les tprops "traversaient" les buffers et pas leurs homologues overlays.
J'essaierai de répondre au reste du message un peu plus tard mais je te remercie déjà pour cette longue explication. -- ,--. Xavier Maillard, Reims, France ,= ,-_-. =. / ,- ) http://www.emacsfr.org/ ((_/)o o(_)) `-' `-'(. .)`-' `-. Debian, a variant of the GNU operating system. _/
On 7 aoû 2005, drkm wrote:
Xavier Maillard wrote:
> Dans quel(s) cas est-il préférable d'utiliser l'une ou
> l'autre des solutions ? Quels sont les impacts sur les
> performances globales ?
ÀMHA, il faut d'abord savoir ce que tu veux faire. Si le but
est d'assigner des properties à de grandes régions, ou que le
fait de pouvoir aisément et sans ambiguïté identifier les
bornes des régions auxquelles s'appliquent les properties,
alors les overlays sont tes amis. Si le but est d'assigner des
properties à des caractères pris individuellement, et que le
problème des bornes ne devrait pas se poser, les tprops sont
toutes désignées.
Je pense que je suis dans la première situation. Pour tout dire
je suis en train d'écrire une sorte de client dans le genre de
ERC mais pas pour l'IRC.
A ce propos, ERC semble utiliser des tprops, c'est pourquoi je me
suis poser cette question.
Est-ce une recherche académique, ou as-tu une utilisation
précise derrière la tête ?
Un peu les deux. Disons que j'ai quelques projets en stocks dont
deux qui vont réclamer ce genre de choses.
Et comme je veux comprendre avant de faire quoique ce soit, je me
renseigne ;)
En lisant le elisp manual (ah qu'est-ce que j'aimerais m'en
trouver une copie papier...), j'ai cru aussi comprendre que les
tprops "traversaient" les buffers et pas leurs homologues
overlays.
J'essaierai de répondre au reste du message un peu plus tard mais
je te remercie déjà pour cette longue explication.
--
,--. Xavier Maillard, Reims, France ,= ,-_-. =.
/ ,- ) http://www.emacsfr.org/ ((_/)o o(_))
`-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. _/
> Dans quel(s) cas est-il préférable d'utiliser l'une ou > l'autre des solutions ? Quels sont les impacts sur les > performances globales ?
ÀMHA, il faut d'abord savoir ce que tu veux faire. Si le but est d'assigner des properties à de grandes régions, ou que le fait de pouvoir aisément et sans ambiguïté identifier les bornes des régions auxquelles s'appliquent les properties, alors les overlays sont tes amis. Si le but est d'assigner des properties à des caractères pris individuellement, et que le problème des bornes ne devrait pas se poser, les tprops sont toutes désignées.
Je pense que je suis dans la première situation. Pour tout dire je suis en train d'écrire une sorte de client dans le genre de ERC mais pas pour l'IRC.
A ce propos, ERC semble utiliser des tprops, c'est pourquoi je me suis poser cette question.
Est-ce une recherche académique, ou as-tu une utilisation précise derrière la tête ?
Un peu les deux. Disons que j'ai quelques projets en stocks dont deux qui vont réclamer ce genre de choses.
Et comme je veux comprendre avant de faire quoique ce soit, je me renseigne ;)
En lisant le elisp manual (ah qu'est-ce que j'aimerais m'en trouver une copie papier...), j'ai cru aussi comprendre que les tprops "traversaient" les buffers et pas leurs homologues overlays.
J'essaierai de répondre au reste du message un peu plus tard mais je te remercie déjà pour cette longue explication. -- ,--. Xavier Maillard, Reims, France ,= ,-_-. =. / ,- ) http://www.emacsfr.org/ ((_/)o o(_)) `-' `-'(. .)`-' `-. Debian, a variant of the GNU operating system. _/
drkm
Xavier Maillard wrote:
Argh ! Je dois pour l'instant utiliser Google Groups et vient de perdre l'article que j'étais en train de rédiger :-(. J'espère ne rien oublier en le réécrivant.
Je pense avoir oublié de mentionner une autre différence fondamentale entre les deux. Les tprops sont considérées comme faisant partie intégrante du texte, alors que les overlays sont plutôt attachés à un buffer.
Si tu copies du texte, les tprops seront conservées. Mais pas les overlays. Cela est assez logique. Que signifierait copier du texte d'un endroit à un autre du buffer ? Faut-il créer un autre overlays ? Si les deux régions sont mitoyennes, faut-il fusionner les deux overlays ? Etc.
Je me demande également si toutes les properties spéciales que l'ont peut attribuer aux tprops (genre 'face', 'intengible', etc.) sont reconnues sur les overlays.
Je pense que je suis dans la première situation. Pour tout dire je suis en train d'écrire une sorte de client dans le genre de ERC mais pas pour l'IRC.
Mais quelle est l'utilisation précise que tu veux en faire, dans ce cadre ?
A ce propos, ERC semble utiliser des tprops, c'est pourquoi je me suis poser cette question.
Quelle utilisation en fait-il ? Je suppose qu'indirectement au moins il utilise la tprop 'face' (via font-lock). Utilise-t-il des properties particulières ? Peut-être as-tu un lien vers une page présentant cette utilisation, ou un lien vers un fichier source ?
En lisant le elisp manual (ah qu'est-ce que j'aimerais m'en trouver une copie papier...), j'ai cru aussi comprendre que les tprops "traversaient" les buffers et pas leurs homologues overlays.
Que veux-tu dire par "traverser les buffers" ?
--drkm
Xavier Maillard wrote:
Argh ! Je dois pour l'instant utiliser Google Groups et vient de
perdre l'article que j'étais en train de rédiger :-(. J'espère ne
rien oublier en le réécrivant.
Je pense avoir oublié de mentionner une autre différence
fondamentale entre les deux. Les tprops sont considérées comme
faisant partie intégrante du texte, alors que les overlays sont
plutôt attachés à un buffer.
Si tu copies du texte, les tprops seront conservées. Mais pas les
overlays. Cela est assez logique. Que signifierait copier du texte
d'un endroit à un autre du buffer ? Faut-il créer un autre overlays
? Si les deux régions sont mitoyennes, faut-il fusionner les deux
overlays ? Etc.
Je me demande également si toutes les properties spéciales que
l'ont peut attribuer aux tprops (genre 'face', 'intengible', etc.) sont
reconnues sur les overlays.
Je pense que je suis dans la première situation. Pour tout dire
je suis en train d'écrire une sorte de client dans le genre de
ERC mais pas pour l'IRC.
Mais quelle est l'utilisation précise que tu veux en faire, dans ce
cadre ?
A ce propos, ERC semble utiliser des tprops, c'est pourquoi je me
suis poser cette question.
Quelle utilisation en fait-il ? Je suppose qu'indirectement au moins
il utilise la tprop 'face' (via font-lock). Utilise-t-il des
properties particulières ? Peut-être as-tu un lien vers une page
présentant cette utilisation, ou un lien vers un fichier source ?
En lisant le elisp manual (ah qu'est-ce que j'aimerais m'en
trouver une copie papier...), j'ai cru aussi comprendre que les
tprops "traversaient" les buffers et pas leurs homologues
overlays.
Argh ! Je dois pour l'instant utiliser Google Groups et vient de perdre l'article que j'étais en train de rédiger :-(. J'espère ne rien oublier en le réécrivant.
Je pense avoir oublié de mentionner une autre différence fondamentale entre les deux. Les tprops sont considérées comme faisant partie intégrante du texte, alors que les overlays sont plutôt attachés à un buffer.
Si tu copies du texte, les tprops seront conservées. Mais pas les overlays. Cela est assez logique. Que signifierait copier du texte d'un endroit à un autre du buffer ? Faut-il créer un autre overlays ? Si les deux régions sont mitoyennes, faut-il fusionner les deux overlays ? Etc.
Je me demande également si toutes les properties spéciales que l'ont peut attribuer aux tprops (genre 'face', 'intengible', etc.) sont reconnues sur les overlays.
Je pense que je suis dans la première situation. Pour tout dire je suis en train d'écrire une sorte de client dans le genre de ERC mais pas pour l'IRC.
Mais quelle est l'utilisation précise que tu veux en faire, dans ce cadre ?
A ce propos, ERC semble utiliser des tprops, c'est pourquoi je me suis poser cette question.
Quelle utilisation en fait-il ? Je suppose qu'indirectement au moins il utilise la tprop 'face' (via font-lock). Utilise-t-il des properties particulières ? Peut-être as-tu un lien vers une page présentant cette utilisation, ou un lien vers un fichier source ?
En lisant le elisp manual (ah qu'est-ce que j'aimerais m'en trouver une copie papier...), j'ai cru aussi comprendre que les tprops "traversaient" les buffers et pas leurs homologues overlays.
Que veux-tu dire par "traverser les buffers" ?
--drkm
Xavier Maillard
On 8 aoû 2005, drkm wrote:
Je me demande également si toutes les properties spéciales que l'ont peut attribuer aux tprops (genre 'face', 'intengible', etc.) sont reconnues sur les overlays.
C'est une des questions que je me pose aussi (j'ai déjà dit que j'aimerais assez bien avoir une version papier du elisp manual ? :))
> Je pense que je suis dans la première situation. Pour tout > dire je suis en train d'écrire une sorte de client dans le > genre de ERC mais pas pour l'IRC.
Mais quelle est l'utilisation précise que tu veux en faire, dans ce cadre ?
En fait tant que je n'aurais pas le basique en te, je crois que je serai bien incapable d'expliquer clairement ce que je souhaite en faire ;)
Le but premier est d'attacher des faces particulières sur des choses particulières (faire simplement du font-lock dans un premier temps). Par la suite les choses pourraient bouger en fonction de ma compréhension des deux concepts.
Que veux-tu dire par "traverser les buffers" ?
Ce que tu expliques plus haut concernant la possibilité de conserver les tprops en copiant du texte par exemple. -- GnusFR (http://www.gnusfr.org) EmacsFR (http://www.emacsfr.org)
.emacs: Because customisation is fun!
On 8 aoû 2005, drkm wrote:
Je me demande également si toutes les properties spéciales que
l'ont peut attribuer aux tprops (genre 'face', 'intengible',
etc.) sont reconnues sur les overlays.
C'est une des questions que je me pose aussi (j'ai déjà dit que
j'aimerais assez bien avoir une version papier du elisp manual ?
:))
> Je pense que je suis dans la première situation. Pour tout
> dire je suis en train d'écrire une sorte de client dans le
> genre de ERC mais pas pour l'IRC.
Mais quelle est l'utilisation précise que tu veux en faire,
dans ce cadre ?
En fait tant que je n'aurais pas le basique en te, je crois que
je serai bien incapable d'expliquer clairement ce que je souhaite
en faire ;)
Le but premier est d'attacher des faces particulières sur des
choses particulières (faire simplement du font-lock dans un
premier temps). Par la suite les choses pourraient bouger en
fonction de ma compréhension des deux concepts.
Que veux-tu dire par "traverser les buffers" ?
Ce que tu expliques plus haut concernant la possibilité de
conserver les tprops en copiant du texte par exemple.
--
GnusFR (http://www.gnusfr.org)
EmacsFR (http://www.emacsfr.org)
Je me demande également si toutes les properties spéciales que l'ont peut attribuer aux tprops (genre 'face', 'intengible', etc.) sont reconnues sur les overlays.
C'est une des questions que je me pose aussi (j'ai déjà dit que j'aimerais assez bien avoir une version papier du elisp manual ? :))
> Je pense que je suis dans la première situation. Pour tout > dire je suis en train d'écrire une sorte de client dans le > genre de ERC mais pas pour l'IRC.
Mais quelle est l'utilisation précise que tu veux en faire, dans ce cadre ?
En fait tant que je n'aurais pas le basique en te, je crois que je serai bien incapable d'expliquer clairement ce que je souhaite en faire ;)
Le but premier est d'attacher des faces particulières sur des choses particulières (faire simplement du font-lock dans un premier temps). Par la suite les choses pourraient bouger en fonction de ma compréhension des deux concepts.
Que veux-tu dire par "traverser les buffers" ?
Ce que tu expliques plus haut concernant la possibilité de conserver les tprops en copiant du texte par exemple. -- GnusFR (http://www.gnusfr.org) EmacsFR (http://www.emacsfr.org)
.emacs: Because customisation is fun!
drkm
Xavier Maillard wrote:
Le but premier est d'attacher des faces particulières sur des choses particulières (faire simplement du font-lock dans un premier temps).
A priori, pour ce genre d'utilisation, les font-lock keywords sont souvent suffisant. Du moins si tu peux développer facilement des expressions rationnelles simples décrivant les keywords (ce n'en est pas la seule utilisation possible, mais si c'est le cas, c'est alors tout désigné).
La docstring de l'une des fontions de font-lock décrit les keywords en détail. De mémoire, je pense qu'il s'agit de 'font-lock-add-keywords'.
De plus, fixer soi-même la property 'face' ne marche pas toujours. Il y a des interactions avec font-lock, mais je ne m'y connais pas en détail (genre il écrase inconditionnellement la property 'face'). A priori, ce problème ne devrait arriver qu'avec les tprops et pas les overlays.
--drkm
Xavier Maillard wrote:
Le but premier est d'attacher des faces particulières sur des
choses particulières (faire simplement du font-lock dans un
premier temps).
A priori, pour ce genre d'utilisation, les font-lock keywords sont
souvent suffisant. Du moins si tu peux développer facilement des
expressions rationnelles simples décrivant les keywords (ce n'en est
pas la seule utilisation possible, mais si c'est le cas, c'est alors
tout désigné).
La docstring de l'une des fontions de font-lock décrit les keywords
en détail. De mémoire, je pense qu'il s'agit de
'font-lock-add-keywords'.
De plus, fixer soi-même la property 'face' ne marche pas toujours.
Il y a des interactions avec font-lock, mais je ne m'y connais pas en
détail (genre il écrase inconditionnellement la property 'face'). A
priori, ce problème ne devrait arriver qu'avec les tprops et pas les
overlays.
Le but premier est d'attacher des faces particulières sur des choses particulières (faire simplement du font-lock dans un premier temps).
A priori, pour ce genre d'utilisation, les font-lock keywords sont souvent suffisant. Du moins si tu peux développer facilement des expressions rationnelles simples décrivant les keywords (ce n'en est pas la seule utilisation possible, mais si c'est le cas, c'est alors tout désigné).
La docstring de l'une des fontions de font-lock décrit les keywords en détail. De mémoire, je pense qu'il s'agit de 'font-lock-add-keywords'.
De plus, fixer soi-même la property 'face' ne marche pas toujours. Il y a des interactions avec font-lock, mais je ne m'y connais pas en détail (genre il écrase inconditionnellement la property 'face'). A priori, ce problème ne devrait arriver qu'avec les tprops et pas les overlays.
