Fa uns mesos vaig publicar a Habr. Potser alguns de vosaltres notareu que el codi de l'article està acolorit d'una manera inusual i, el més important, està acolorit correctament, malgrat que l'editor de text integrat al lloc no admet el marcatge de codi original i sovint destaca incorrectament els seus elements. Al mateix temps, el codi no s'insereix amb una imatge, com fan alguns escriptors completament desesperats.
En el meu cas, desar l'etiquetatge era especialment important, ja que l'article era una descripció del treball en el codi. Per resoldre el problema que vaig crear , que us permet transferir el ressaltat de codi en un esquema seleccionat d'IDEA a un article sobre Habré. Parlaré del procés de creació de l'eina i de les característiques del seu ús.
Per a què serveix tot això
A primera vista, pot semblar que això s'està fent per entremaliadura, simplement perquè la il·luminació estàndard implementada a través de l'etiqueta no és satisfactòria <source>.
En cert sentit, això és, per descomptat, cert, però no del tot.
En primer lloc, la il·luminació interior <source> no pot treballar amb fragments de codi, ja que no hi haurà prou informació per pintar. Tots els elements declarats fora de l'àmbit de la peça es pintaran a l'atzar. Aquest problema no té solució, ja que, pel que jo sé, cap dels serveis de pintar en línia us permet fer alguna de les accions següents:
- Inseriu el codi del projecte complet a l'article sense mostrar-lo sencer o inseriu un enllaç a una confirmació a GitHub. En llocs específics de l'article, utilitzeu fragments de línia del codi complet (indicant l'interval). En aquest cas, el ressaltat s'ha de determinar en funció del codi complet, és clar.
- Proporcioneu metainformació explícitament per a elements no definits. Un camí força difícil per a l'usuari, però hi estaria d'acord.
En segon lloc, la il·luminació interior <source> mai coincidirà amb el nombre de tipus d'elements diferents amb un IDE normal. I a causa del problema descrit anteriorment, no té sentit fer coloració avançada: ningú insereix el codi complet del projecte a l'article, de manera que aquesta funcionalitat no podrà funcionar.
Al mateix temps, la realitat és que cal inserir fragments de codi als articles, i com més petits siguin, millor.
Podeu llegir el codi sense retroil·luminació, però per què?
Característiques del marcatge "Habr".
IntelliJ IDEA té suport integrat per exportar codi a HTML. La còpia normal del codi col·loca el codi de colors al porta-retalls, que es pot llegir com a HTML.
Malauradament, Habr no permet utilitzar el marcatge HTML directament als articles. Les raons d'això són un misteri, envoltat de foscor, però potser això es deu a la unificació del tipus d'articles. En permetre l'ús d'HTML als articles, serà possible compensar qualsevol problema de visualització que pugui sorgir.
En general, recolzo la idea de prohibir HTML als articles, però hi ha un matís. És estrany un recurs per a especialistes informàtics on sovint es parla de codi i no hi ha manera d'inserir-lo correctament en un article.
Així doncs, tenim etiquetes a la nostra disposició <b>, <i>, <font>. A més, tot això funciona dins de l'etiqueta <code>, que és necessari per al format. Bé També l'hem desat, que és útil per a llargues línies de codi i sagnats.
No cal dir que totes les maneres estàndard d'obtenir codi HTML d'IDEA produeixen HTML completament diferent, de manera que hi ha molta feina de conversió per endavant.
Enfocament
En primer lloc, val la pena dir una paraula d'agraïment a l'autor. per la seva sobre aquest tema. No vaig utilitzar directament l'eina proposada a l'article, i és poc probable que hagués funcionat, però gràcies a aquest material vaig entendre tota la profunditat del problema i, al mateix temps, vaig sentir el vent de l'esperança.
L'únic negatiu d'aquesta publicació és la gran quantitat de codi combinada amb una explicació molt escassa de què fa i per què.
Intentaré corregir la situació i descriure què haureu de fer amb el vostre codi de marcatge HTML si voleu portar-lo a un formulari llest per inserir-lo a Habr.
- Abans d'exportar, heu d'establir l'esquema de colors desitjat a IDEA, per exemple . El codi s'exportarà amb l'esquema seleccionat. És millor triar un esquema amb fons blanc (ja que el fons no es pot configurar a Habr) i sense subratllats. No vaig saber com arrossegar-los fàcilment, perquè realment no volia fer-ho.
- Treballem només amb l'interior de l'etiqueta
<pre>. Fins i tot si utilitzeu l'exportació no des d'IDEA, sinó una altra, probablement hi haurà aquesta etiqueta a l'etiquetatge HTML, ja que sense ella és difícil formatar el codi correctament. Traiem l'etiqueta en si, substituint-la per<code>. - El text probablement es presentarà com una llista
<span>amb diferents estils. Ens haurem de desfer de tots. Molts serveis de pintar redueixen els estils en un full d'estil, que és lògic, i utilitzen referències a noms d'estil. IDEA encara no ho fa específicament, cosa que fa que la tasca sigui una mica més fàcil (la configuració d'estil es troba correctament a<span>). - Estableix el color de la lletra amb una etiqueta
<font>. Malauradament, no és possible definir el color de fons. - Propietat
font-style:italicconvertir-lo en un parell d'etiquetes<i></i>Ifont-weight:bold- dins<b></b>. - Substitueix tots els espais per
. - Traduccions de cadenes en forma
<br>substituir pern. - El marcatge HTML a IDEA produeix línies buides amb estils i línies d'espais amb estils. És millor llençar aquests estils: això reduirà molt la longitud i augmentarà la comprensió del codi.
- Ens assegurem que els salts de línia no tinguin cap estil. En cas contrari, hi haurà problemes amb les línies buides.
Il·lustraré l'últim punt amb un exemple:
<code>
1<font color="000000">
</font>2
</code>
Aquest codi serà convertit per Habr en 12. El mateix passa amb les etiquetes <b> и <i>, així com qualsevol combinació d'aquests. Els salts de línia no haurien de tenir un estil, i llavors tot anirà bé.
Implementació
Al principi, la tasca d'escriure un convertidor per a codi HTML arbitrari em va semblar força difícil. Tanmateix, si feu una solució per a una variant HTML específica, aleshores tot no és tan dolent. Vaig aconseguir fer-ho tot fent servir RegExp pura, és a dir, fins i tot sense anàlisi HTML. El principal problema va ser identificar les característiques del marcatge Habr.
Per evitar que els salts de línia tinguessin estils, vam haver de fer algunes substitucions força complicades, que probablement són les més incomprensibles (vegeu la funció popupBr). La idea és que les etiquetes <br> després de cada substitució van "aparèixer" des de les profunditats de les etiquetes de format cap a l'exterior. Així, després de tots els reemplaçaments d'etiquetes <br> apareix fora de format.
A més, va resultar que IDEA posa no només text enriquit al porta-retalls, sinó també objectes més aviat complicats com ara application/x-java-jvm-local-objectref. El problema és que la presència d'aquests objectes al porta-retalls provoca errors constants a la meva consola sobre la construcció de DataFlavor. Malauradament, no hi podeu fer res: així és com funciona el JDK amb el porta-retalls. Va ser una revelació per a mi tenir . Pel que sembla, els nois intel·ligents que van escriure això pensen que anirà bé. En general, no tingueu por dels errors que es poden produir quan es treballa amb l'eina.
El projecte està escrit en Kotlin i segueix viu.
Els suggeriments de millora són benvinguts! Per exemple, estaria bé dissenyar aquesta eina com a connector per a IDEA. Encara no he trobat una manera senzilla de fer-ho: malauradament, les fonts del complement Copia com a HTML estan tancades i esbrinar com escriure aquest complement des de zero triga massa.
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Us importa la coloració correcta del codi als articles sobre Habr?
No, normalment no llegeixo el codi
No, el color estàndard és suficient
Sí, vull pintar codi com en els IDE populars
Sí, vull personalitzar jo mateix els esquemes de colors quan llegeixo un article
Han votat 154 usuaris. 16 usuaris es van abstenir.
Font: www.habr.com
