🥇Como colorear o código correctamente en Habr e por que é tan difícil

Hai uns meses publiquei a miña primeira publicación En Habr. Algúns de vós podedes notar que o código do artigo ten unha cor inusual e, o máis importante, ten a cor correcta, a pesar de que o editor de texto integrado do sitio non admite o código orixinal e, a miúdo, resalta os seus elementos incorrectamente. Ademais, o código non se insire como unha imaxe, como fan algúns escritores desesperados.

No meu caso, preservar o código foi especialmente importante, xa que o artigo era unha descrición de como traballar no código. Para resolver o problema, creei ferramenta, que che permite transferir o resaltado de código nun diagrama IDEA seleccionado a un artigo en Habr. Falarei do proceso de creación da ferramenta e dos detalles do seu uso.

Por que todo isto?

A primeira vista, pode parecer que isto se fai por malicia, simplemente porque a retroiluminación estándar implementada a través da etiqueta non é satisfactoria. <source>.

Nun certo sentido, isto é certo, pero non totalmente.

En primeiro lugar, a iluminación interior <source> Non pode funcionar con fragmentos de código porque non haberá información suficiente para colorear. Todos os elementos declarados fóra do fragmento serán coloreados aleatoriamente. Este problema non ten solución, xa que, polo que eu sei, ningún dos servizos de colorear en liña che permite facer ningunha das seguintes accións:

Insire o código completo do proxecto no artigo, sen mostralo na súa totalidade, ou inclúe unha ligazón ao commit de GitHub. En lugares específicos do artigo, usa extractos do código completo (cun rango especificado). O resaltado debe basearse no código completo, por suposto.
Proporciona metadatos explícitos para elementos non definidos. É unha ruta bastante complicada para o usuario, pero estou de acordo con ela.

En segundo lugar, a iluminación interior <source> Nunca coincidirá co número de tipos de elementos diferentes dun IDE estándar. E debido ao problema descrito anteriormente, non ten sentido implementar a coloración avanzada: ninguén pega o código completo do proxecto nun artigo, polo que esta funcionalidade non funcionará.

Ao mesmo tempo, a realidade é que os artigos deben incluír anacos de código, e canto máis pequenos sexan, mellor.

É posible ler o código sen resaltalo, pero por que?

Características do marcado Habr

IntelliJ IDEA ten compatibilidade integrada para exportar código a HTML. Simplemente copiando o código, o código coloreado engádese ao portapapeis, que se pode ler como HTML.

Desafortunadamente, Habr non permite o marcado HTML directamente nos artigos. As razóns disto son un misterio, pero probablemente estea relacionado coa estandarización dos formatos dos artigos. Permitir HTML nos artigos probablemente levaría a problemas de visualización.

En xeral, apoio a idea de prohibir o HTML nos artigos, pero hai unha advertencia. Un recurso para profesionais de TI onde se adoita falar de código, pero non hai xeito de inserilo correctamente nun artigo, é un pouco estraño.

Entón, temos etiquetas á nosa disposición , , Ademais, todo isto funciona dentro da etiqueta. <code>, que é necesario para o formato. Ben, e   Tamén o gardamos, o que é útil para liñas de código longas e sangrías.

Non fai falta dicir que todos os métodos estándar para obter código HTML de IDEA producen HTML completamente diferente, polo que o traballo de conversión requirirá moito traballo.

O enfoque

En primeiro lugar, paga a pena dicir palabras de gratitude ao autor. bloqueos de maiúsculas para o seu material sobre este tema. Non empreguei directamente a ferramenta proposta no artigo, e é pouco probable que fose capaz de facelo, pero grazas a este material, comprendín toda a profundidade do problema e ao mesmo tempo sentín un alento de esperanza.

A única desvantaxe desta publicación é a gran cantidade de código combinada con moi pouca explicación do que fai e por que.

Tentarei arranxar a situación e describir o que terás que facer co teu código HTML se queres que estea nun formato listo para pegalo en Habr.

Antes de exportar, debes definir a combinación de cores desexada en IDEA, por exemplo do sitio web de Color ThemesO código exportarase co esquema seleccionado. É mellor escoller un esquema cun fondo branco (xa que os fondos non se poden configurar en Habr) e sen subliñados. Non puiden descubrir como arrastralos facilmente porque non quería facelo.
Traballamos só cos compoñentes internos da etiqueta <pre>Mesmo se estás a usar unha ferramenta de exportación diferente a IDEA, é probable que o teu código HTML conteña esta etiqueta, xa que é difícil formatar o código correctamente sen ela. Elimina a propia etiqueta e substitúea por <code>.
O texto presentarase probablemente en forma de lista  con diferentes estilos. Terás que desfacerte de todos eles. Moitos servizos de coloración combinan estilos nunha folla de estilo, o cal é lóxico, e usan referencias a nomes de estilos. IDEA aínda non o fai, o que facilita algo a tarefa (a configuración de estilo está situada directamente en ).
Definimos a cor da fonte coa etiqueta Desafortunadamente, non é posible definir a cor de fondo.
Propiedade font-style:italic convertámolo nun par de etiquetas E font-weight:bold - dentro .
Substitúe todos os espazos por  .
Saltos de liña no formulario   substituír por n.
Ao crear código HTML en IDEA, obterás liñas baleiras con estilos e liñas con espazos con estilos. É mellor eliminar estes estilos: isto reducirá significativamente a lonxitude e mellorará a claridade do código.
Asegurámonos de que os saltos de liña non teñan ningún estilo. Se non, xurdirán problemas con liñas baleiras.

Ilustrarei o último punto cun exemplo:

<code>
1
2
</code>

Este código será convertido por Habr en 12O mesmo aplícase ás etiquetas.  и , así como calquera combinación dos mesmos. Os saltos de liña deberían non ter estilo e, nese caso, todo irá ben.

Implantación

Ao principio, escribir un conversor para código HTML arbitrario parecía bastante difícil. Non obstante, se adaptas a solución a unha variante específica de HTML, as cousas non están tan mal. Conseguín facelo todo usando RegExp pura, é dicir, sen sequera analizar HTML. O principal desafío resultou ser identificar os detalles específicos do marcado "Habr".

Para evitar estilos nos saltos de liña, tiven que facer algunhas substitucións bastante complicadas, que probablemente sexan as máis confusas (consulta a función popupBr). A idea é facer que as etiquetas   Despois de cada substitución, "emerxían" das profundidades das etiquetas de formato. Así, despois de todas as substitucións, a etiqueta   parece estar fóra do formato.

Ademais, resultou que IDEA coloca no portapapeis non só texto enriquecido, senón tamén obxectos bastante complexos como application/x-java-jvm-local-objectrefO problema é que ter eses obxectos no portapapeis provoca erros constantes na miña consola sobre a construción de DataFlavor. Desafortunadamente, non hai nada que poida facer ao respecto: así é como o JDK xestiona o portapapeis. A presenza de ese códigoAo parecer, os listos que escribiron isto pensan que isto servirá. En resumo, non te alarmes polos erros que poidan xurdir ao traballar coa ferramenta.

O proxecto está escrito en Kotlin e continúa vivo GitHub.

As suxestións de mellora son moi benvidas! Por exemplo, sería xenial implementar esta ferramenta como un complemento para IDEA. Aínda non atopei unha forma sinxela de facelo: o complemento Copy as HTML é, por desgraza, de código pechado, e descubrir como escribir un complemento deste tipo desde cero levaría demasiado tempo.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.