Als git een 3-way merge uitvoert en een conflict heeft het kan “niet oplossen, het markeert dat gedeelte van het bestand als volgt:

No unresolvable conflicts here <<<<<<< HEAD xyz ||||||| parent of ... abc ======= 123 >>>>>>> ... 

Is er een manier (en zo ja, hoe) om te veranderen de achtergrondkleur van deze 3 “secties”:

  • <<<<<<< HEAD door de regel vóór ||||||| parent of ...
  • ||||||| parent of ... door de regel vóór =======
  • De regel na ======= door de regel >>>>>>> ...

(EDIT: de vraag draait om of er een manier is om bepaalde regels te markeren, afhankelijk van andere regels. xyz zouden normaal gesproken niet worden gemarkeerd, maar aangezien het “tussen <<<<<<< en ||||||| het zou worden gemarkeerd.)

Met het ook kunnen omgaan met andere sets conflictmarkeringen?

De meest recente versie van vim gebruiken die beschikbaar was op het moment van een opmerking. Dus vanaf nu 8.1.1183.

Ik gebruik een zwarte achtergrond en 256 kleuren in mijn terminal. Ik dacht dat het leuk zou zijn om deze secties te geven met de donkerste R / G / B / C / M / Y-kleuren, dus ze veroorzaakten niet echt een probleem met syntaxisaccentuering. (Over ANSI-kleuren 52, 22, 17, 23, 53 en 58 – niet de 1-6 kleuren.)

Opmerkingen

  • Een simpele Google-zoekopdracht zou voldoende zijn geweest: github.com/rhysd/conflict-marker.vim
  • @klaus, ik had moeten zeggen dat ik naar die plug-in heb gekeken terwijl ik veel deed Google zoeken. Die plug-in markeert de conflictmarkeringen zelf. De plug-in markeert niet ' ook de tekst waarmee deze markeringen zijn geassocieerd, op andere regels. Ik denk dat het grote probleem is of er ' is een manier om bepaalde regels te markeren, afhankelijk van andere regels. Dit betekent dat in mijn voorbeeld xyz normaal gesproken niet zou worden gemarkeerd, maar omdat het ' s tussen <<<<<<< en ||||||| Ik zou het graag gemarkeerd willen zien.

Answer

In je Vim-configuratie kun je het volgende doen (verander de kleuren en styling naar wens):

function! ConflictsHighlight() abort syn region conflictStart start=/^<<<<<<< .*$/ end=/^\ze\(=======$\||||||||\)/ syn region conflictMiddle start=/^||||||| .*$/ end=/^\ze=======$/ syn region conflictEnd start=/^\(=======$\||||||| |\)/ end=/^>>>>>>> .*$/ highlight conflictStart ctermbg=red ctermfg=black highlight conflictMiddle ctermbg=blue ctermfg=black highlight conflictEnd ctermbg=green cterm=bold ctermfg=black endfunction augroup MyColors autocmd! autocmd BufEnter * call ConflictsHighlight() augroup END 

Wat als volgt wordt weergegeven:

voer de beschrijving van de afbeelding hier in

Is dit wat je zoekt?

Reacties

  • Dat ' is absoluut wat ik ' m na. Ik ' heb echter een aantal eigenaardigheden met het vimscript. Als ik je voorbeeld typ, lijkt het precies op de afbeelding die je hebt gepost. Als ik je voorbeeld opsla en vim opnieuw start met het bewerken van het nieuwe bestand, wordt het vreselijk uit de hand gelopen. (vim 8.1.1186.) Nog vreemder, als ik dan alle regels in een bestaand bestand verwijder en de inhoud ervan opnieuw plak, ' is nog steeds fout. i.ibb.co/jvGMH6t/wtfvim.jpg
  • Het gebruik ervan in een echt samenvoegscenario veroorzaakt een nog vreemdere kleur dan de afbeelding die ik gelinkt, met: conflictStart correct gemarkeerd; het ||||||| deel van conflictMiddle in rood, maar de rest van de regel in blauw zoals het hoort; de ======= in rood; de >>>>>>> .* regel in geel (waar kwam geel hierin voor, er is geen geel); en de rest van het bestand dat in het groen niet ' deel mag uitmaken van het conflict, maar nog steeds wordt opgepikt als conflictEnd volgens de SynStack() functie van stackoverflow.com/questions/30247603
  • Evenzo, met behulp van de werkelijke samenvoegscenario, als ik de inhoud naar een nieuw bestand kopieer / plak, wordt het weergegeven zoals verwacht, maar zodra het ' is opgeslagen en vim opnieuw is gestart, wordt het verkeerd weergegeven.
  • In een echt samenvoegscenario kunt u de oorspronkelijke diff-kleuring uitschakelen met :diffoff, waardoor alleen het bestandstype ' s syntaxis hoogtepunt. Ik zal een beetje spelen om te zien voor je eerste geval.
  • Ack, sorry, ik was vergeten dat ik de conflict_marker-plug-in had laten staan nadat ik het had geprobeerd voor mijn bericht, wat tegenstrijdig was en het probleem veroorzaakte. Dat verwijderen en dat probleem niet meer hebben.

Antwoord

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *