🥇Sådan farvekoder du korrekt på Habr, og hvorfor det er så svært

For et par måneder siden udgav jeg mit første indlæg på "Habr". Måske vil nogle af jer bemærke, at koden i artiklen er farvet på en usædvanlig måde, og vigtigst af alt, at den er farvet korrekt, på trods af at den indbyggede teksteditor på webstedet ikke understøtter den originale kodemarkup og ofte fremhæver dens elementer forkert. Samtidig er koden ikke indsat som et billede, som nogle fuldstændig desperate forfattere gør.

I mit tilfælde var det særligt vigtigt at bevare markup'en, fordi artiklen var en beskrivelse af, hvordan man arbejder med koden. For at løse problemet oprettede jeg инструмент, som giver dig mulighed for at overføre kodefremhævningen i det valgte skema fra IDEA til artiklen om "Habr". Jeg vil fortælle dig om processen med at oprette værktøjet og funktionerne i dets anvendelse.

Hvorfor alt dette?

Ved første øjekast kan det virke som om, at dette er gjort af ren og skær bedrag, simpelthen fordi den standardbaggrundsbelysning, der er implementeret gennem tagget, ikke er tilfredsstillende. <source>.

På en måde er dette bestemt sandt, men ikke helt.

Først, belysningen indeni <source> kan ikke arbejde med kodestykker, da der vil være utilstrækkelig information til farvelægning. Alle elementer, der er deklareret uden for stykket, vil blive farvelagt tilfældigt. Dette problem har ingen løsning, fordi, så vidt jeg ved, tillader ingen af online farvelægningstjenesterne dig at gøre noget af følgende:

Indsæt den fulde projektkode i artiklen uden at vise den i sin helhed, eller indsæt et link til commit'en på GitHub. Brug linjeklip fra den fulde kode (som angiver området) på bestemte steder i artiklen. I dette tilfælde bør fremhævningen naturligvis bestemmes ud fra den fulde kode.
Angiv eksplicit metainformation for udefinerede elementer. Det er en ret kompliceret proces for brugeren, men jeg er enig.

For det andet, belysningen indeni <source> vil aldrig være sammenlignelig i antallet af forskellige typer elementer med et almindeligt IDE. Og på grund af det ovenfor beskrevne problem er der ingen mening i at lave avanceret farvning: ingen indsætter hele projektkoden i en artikel, så denne funktionalitet vil ikke kunne fungere.

Samtidig er realiteten, at du skal indsætte kodestykker i artikler, og jo mindre de er, jo bedre.

Det er muligt at læse koden uden at fremhæve, men hvorfor?

Funktioner ved "Habr"-markering

IntelliJ IDEA har indbygget understøttelse af eksport af kode til HTML. Blot at kopiere koden vil også placere den farvede kode i udklipsholderen, som kan læses som HTML.

Desværre tillader Habr ikke brugen af HTML-markup direkte i artikler. Årsagerne til dette er et mysterium indhyllet i mørke, men måske hænger det sammen med ensartetheden af artikeltypen. Hvis vi tillader brugen af HTML i artikler, kan vi kompensere for så meget, at der vil være problemer med visningen.

Jeg støtter generelt ideen om at forbyde HTML i artikler, men der er en nuance. En ressource for IT-specialister, hvor kode ofte diskuteres, og der ikke er nogen måde at indsætte den korrekt i en artikel, er på en eller anden måde mærkelig.

Så har vi tags til rådighed , , Alt dette fungerer også inde i tagget <code>, som er nødvendig til formatering. Nå, og   Vi gemte den også, hvilket er nyttigt til lange linjer kode og indrykninger.

Det siger sig selv, at alle standardmetoder til at hente HTML-kode fra IDEA producerer helt forskellig HTML, så der er meget arbejde at gøre med konverteringen.

tilgang

Først og fremmest er det værd at sige taknemmelighed til forfatteren store bogstaver for hans materiale om dette emne. Jeg brugte ikke det værktøj, der er foreslået i artiklen, direkte, og det ville næppe have virket, men takket være dette materiale forstod jeg problemets fulde dybde og følte samtidig håbets vind.

Den eneste ulempe ved dette indlæg er den store mængde kode kombineret med meget lidt forklaring på, hvad det gør, og hvorfor.

Jeg vil forsøge at løse situationen og beskrive, hvad du skal gøre med din HTML-kodemarkup, hvis du vil lave en formular, der er klar til at blive indsat på Habr.

Før du eksporterer, skal du indstille det ønskede farveskema i IDEA, for eksempel fra FarvetemaerKoden vil blive eksporteret med det valgte skema. Det er bedre at vælge et skema med en hvid baggrund (da baggrunden ikke kan indstilles på "Habr") og uden understregning. Jeg fandt ikke ud af, hvordan man nemt kan trække dem, da jeg egentlig ikke ville.
Vi arbejder kun med taggets indre dele <pre>Selv hvis du bruger en anden eksport end IDEA, vil der sandsynligvis være dette tag i HTML-markup'en, da det er vanskeligt at formatere koden korrekt uden det. Vi fjerner selve tagget og erstatter det med <code>.
Teksten vil højst sandsynligt blive præsenteret som en liste.  med forskellige stilarter. Du bliver nødt til at slippe af med dem alle. Mange farvelægningstjenester kombinerer stilarter i et stilark, hvilket er logisk, og bruger referencer til stilnavne. IDEA gør specifikt ikke dette endnu, hvilket gør opgaven noget nemmere (stilindstillingerne er placeret lige i ).
Indstil skriftfarven via tagget Det er desværre ikke muligt at indstille baggrundsfarven.
Ejendom font-style:italic blive til et par tags Og font-weight:bold - ind .
Erstat alle mellemrum med  .
Linjeskift i formularen   erstatte med n.
Når HTML-markup udføres i IDEA, opnås tomme linjer med stilarter og linjer med mellemrum med stilarter. Det er bedre at kassere sådanne stilarter: dette vil reducere længden betydeligt og øge kodens klarhed.
Sørg for, at linjeskift ikke har nogen typografi. Ellers vil der være problemer med tomme linjer.

Jeg vil illustrere det sidste punkt med et eksempel:

<code>
1
2
</code>

Denne kode vil blive konverteret af Habr til 12Det samme gælder for tags.  и , samt enhver kombination deraf. Linjeskift bør ikke have en typografi, og så vil alt være fint.

implementering

I starten virkede opgaven med at skrive en konverter til vilkårlig HTML-kode ret vanskelig for mig. Men hvis man laver en løsning til en specifik HTML-variant, viser det sig at alting ikke er så slemt. Jeg formåede at gøre alt på ren RegExp, det vil sige selv uden HTML-parsing. Hovedproblemet var at identificere funktionerne i "Habr"-markup'en.

For at undgå stilarter til linjeskift, måtte vi lave nogle ret vanskelige substitutioner, som nok er de mest obskure (se popupBr-funktionen). Ideen er, at tagsene   Efter hver udskiftning "kom de frem" fra formateringstaggenes dybder og udad. Således, efter alle udskiftningerne, blev tagget   ser ud til at være uden for formateringen.

Derudover viste det sig, at IDEA ikke kun placerer Rich Text i udklipsholderen, men også ret vanskelige objekter som f.eks. application/x-java-jvm-local-objectrefProblemet er, at det at have sådanne objekter i udklipsholderen forårsager konstante fejl i min konsol om konstruktionen af DataFlavor. Desværre er der intet, jeg kan gøre ved det: det er bare sådan, JDK'en fungerer med udklipsholderen. Det var en åbenbaring for mig at have sådan kodeTilsyneladende tror de kloge fyre, der skrev dette, at det her nok skal fungere. Generelt set skal man ikke være bange for fejl, der kan opstå, når man arbejder med værktøjet.

Projektet er skrevet i Kotlin og lever videre GitHub.

Forslag til forbedringer er velkomne! For eksempel ville det være godt at designe dette værktøj som et plugin til IDEA. Jeg har endnu ikke fundet en simpel måde at gøre dette på: kildekoden til Copy as HTML-pluginnet er desværre lukket, og det tager for lang tid at finde ud af, hvordan man skriver sådan et plugin fra bunden.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.