Le séparateur divisé dans vim peut-il avoir moins d'une largeur de colonne complète?

J'utilise un gestionnaire de fenêtres en mosaïque (génial) + un multiplexeur de terminaux (tmux) + se divise à l'intérieur de vim. Je n'ai pas de décoration de fenêtre du tout, donc il n'y a pas de séparation visuelle entre eux si le contenu du programme ne le révèle pas. Je suis assez à l'aise avec ce paradigme car j'utilise de toute façon plusieurs moniteurs et des tâches de groupe par écran. Si deux fenêtres n'avaient aucune raison d'être côte à côte, elles ne seraient pas là en premier lieu.

Cependant, cela crée un peu de dissonance visuelle où la séparation visuelle la plus évidente est la moins significative sémantiquement.

• Fenêtre Xorg ‹|› window = rien du tout
• Volet Tmux ‹|› pane = ligne de séparation 1px
• Vim split ‹|› split = colonne colorée de 1 caractère

Voici un exemple montrant une fenêtre côte à côte, des volets et des séparations de vim:

Même sans cliquer sur la version pleine résolution, la ligne de séparation blanche que vous voyez est la division la moins significative à l'écran, les volets vim. (Notez que la colonne grise à droite de la session vim est en fait un surlignage de la 80e colonne, pas un diviseur d'aucune sorte bien que je travaille souvent à cette taille.)

Je sais comment changer le caractère dessiné dans la division ou réduire le contraste du jeu de couleurs. Ce que je voudrais faire, c'est utiliser la même barre de séparation que tmux qui ne prend aucune largeur car elle est dessinée entre les colonnes plutôt qu'en une seule. Est-ce possible avec un terminal basé sur vim? Gvim? Neovim? À moins de créer un séparateur visuellement discret, la colonne de séparation peut-elle être complètement désactivée?

PS La raison d'utiliser un séparateur visuellement similaire est logique parce que j'utilise les mêmes raccourcis clavier pour naviguer entre les volets tmux et les séparations vim. Les mêmes touches naviguent parfaitement entre elles, cela n'aurait de sens que si les limites visuelles étaient également les mêmes.

Vous avez tort sur tmux. Comme tout programme basé sur un terminal - y compris Vim - il ne dessine que des éléments à l' intérieur des cellules. Cela signifie que Vim et tmux utilisent tous les deux la même méthode pour dessiner des bordures verticales: ils utilisent simplement un caractère de type pipe.

Tmux utilise │( U+2502) par défaut tandis que Vim utilise |( U+007C).

Si vous voulez le même séparateur dans Vim, vous pouvez simplement utiliser le même caractère:

set fillchars+=vert:│

Notez que votre schéma de couleurs définit probablement la couleur d'arrière-plan de la séparation verticale. Si tel est le cas, vous pouvez supprimer la couleur de fond directement dans votre schéma de couleurs:

hi VertSplit ctermbg=NONE guibg=NONE

Non, cela ne peut pas être fait dans Vim, et serait probablement très difficile à implémenter dans GVIM.

Vim s'en tient à l'adressage cellulaire utilisé dans le terminal; dans un tampon, ceci est crucial pour une navigation verticale cohérente avec j/ k. Cet adressage par coordonnées x et y basées sur les cellules est tellement ancré dans l'implémentation de Vim, je suppose qu'il est très difficile à surmonter.

Notez également :help design-not:

• Vim n'est pas un éditeur GUI sophistiqué qui essaie de paraître joli au prix d'être moins cohérent sur toutes les plateformes.

Même dans ma propre capture d'écran, tmux n'utilise aucune magie, le fractionnement est toujours une colonne d'un seul caractère. L'effet visuel le moins gênant est l'utilisation d'un caractère de dessin de boîte Unicode qui est moins maladroit que le défaut ASCII de vim, et l'absence d'une couleur d'arrière-plan en surbrillance.

Presque le même effet est possible dans vim en ajoutant quelque chose comme les lignes suivantes au fichier rc:

" Set split separator to Unicode box drawing character
set encoding=utf8
set fillchars=vert:│

" Override color scheme to make split the same color as tmux's default
autocmd ColorScheme * highlight VertSplit cterm=NONE ctermfg=Green ctermbg=NONE

L'utilisation de autocmdgaranties garantit que le dépassement de surbrillance reste effectif si vous changez de jeu de couleurs. Vous pouvez ou non souhaiter ce comportement car certains modèles de couleurs ont des valeurs sensibles pour ce groupe de couleurs.

Notez également qu'il cterm=NONEest nécessaire de contourner certains schémas de couleurs qui définissent cette valeur sur reverse, ergo jouant avec les valeurs fg / bg que vous essayez d'utiliser.