Comment changer la taille des onglets sur GitHub?


275

Lorsque je visualise des fichiers sur GitHub, les onglets apparaissent sous la forme de 8 espaces.

Exemple:

exemple

Est-il possible de changer cette configuration en 2 ou 4 espaces?


6
Vous pouvez également consulter les réponses fournies dans le numéro 170 depre { tab-size: 4 }
KyleMit

1
Je pense que vous devriez changer la réponse acceptée par celle de @rofrol sur l'utilisation de la .editorconfig, je pense que sa réponse comprend les meilleures méthodes actuelles pour définir la configuration de manière à ce que d'autres personnes voient le code tel que vous le souhaitiez, et modifier l'apparence du code des autres lorsque vous le lisez.
f1lt3r

@ f1lt3r Je ne suis pas d'accord. Si les gens veulent vraiment voir mon code avec 8 espaces plus de pouvoir pour eux. Je ne veux pas les restreindre de cette façon pour que je puisse le voir avec 4 espaces sur github pour moi. Si la réponse va changer, ce devrait être la réponse de mortenpi
Assimilater

@Assimilater - la réponse de rofrol n'empêcherait personne d'afficher la largeur de son choix. Convenez que la réponse de mortenpi est bonne mais assez frustrante d'avoir à ajouter le param pour chaque fichier que vous regardez.
f1lt3r

3
Quelqu'un peut-il expliquer la logique derrière l'utilisation de 8 espaces par défaut? Je ne peux pas imaginer un scénario où 8 espaces auraient l'air autre chose que ridicule - pourtant c'est le défaut sur github? Ce qui donne?
PandaWood

Réponses:


24

Mettre à jour

Oui . Comme indiqué par mortenpi, cela peut être fait via un paramètre de requête supplémentaire. Voir sa réponse pour plus de détails.

Réponse originale

Est-il possible de changer cette configuration en 2 ou 4 espaces?

Non. Il n'est disponible que dans le cadre de la fonction d'édition via l' éditeur Ace et le changement n'est pas conservé.

Cet article de blog donne plus d'informations sur l'IDE intégré.

Cependant, à condition que vous connaissiez l'URL du blob (fichier) que vous souhaitez consulter, vous pouvez facilement passer en mode édition en changeant le segment blob avec un segment d' édition et utiliser la liste déroulante pour sélectionner la taille d'onglet que vous préférez.

tabSize


20
Excellente idée, mais le problème est qu'une fois que vous passez en mode EDIT, vous FORCEZ également ladite archive. Peut devenir un peu excessif après une cinquantaine de modifications en
lecture

2
D'accord. Mais cela pourrait être une bonne incitation à commencer à contribuer ;)
nulltoken

13
Comme @chrisdembia l'a mentionné, ce n'est plus correct; github vous permet de changer la taille des onglets en passant la valeur comme ?ts=4
paramètre de

Existe-t-il un moyen pour la communauté de remplacer la réponse sélectionnée?
chrisdembia

1
@chrisdembia Merci pour les rappels;) Mise à jour de la réponse pour pointer celle de morenti.
nulltoken

354

Vous pouvez ajouter ?ts=2ou ?ts=4à l'URL pour modifier la taille de l'onglet.

Exemple: https://github.com/jquery/jquery/blob/master/src/core.js?ts=2

Il semble que la valeur puisse aller de 1 à 12. Cependant, cela ne fonctionne pas sur Gists ou sur les vues de fichiers brutes.

Source: Feuille de triche GitHub


97
C'est bien que cela soit possible, mais ce serait bien s'il y avait un moyen facile de choisir la largeur de l'onglet plutôt que de devoir se souvenir du paramètre URL.
aross

75
Il serait également intéressant que github vous permette d'enregistrer cette préférence afin que vous n'ayez pas besoin de le remettre dans l'URL.
FrustratedWithFormsDesigner

3
@PhilDennis Fonctionne pour moi avec Chrome (sous Linux).
mortenpi

1
@ NikolaMihajlović C'est un peu subtil, mais l'argument ts doit être avant le fragment # dans l'URL. Par exemple github.com/jquery/jquery/commit/…
mortenpi

2
belle solution. ne fonctionne malheureusement pas sur les différences dans les RP.
bbjay

280

Définir la taille d'onglet affichée par défaut pour votre référentiel

Lorsque vous avez un .editorconfig dans votre référentiel, il le respectera lors de l'affichage du code sur GitHub.

indent_style = tab et indent_size = 4 affiche les onglets avec 4 colonnes au lieu de 8 https://github.com/isaacs/github/issues/170#issuecomment-150489692

Exemple .editorconfig pour plusieurs extensions qui fonctionne dans les produits JetBrains:

root = true

[*]
end_of_line = lf
insert_final_newline = true

# Matches multiple files with brace expansion notation
[*.{js,jsx,html,sass}]
charset = utf-8
indent_style = tab
indent_size = 4
trim_trailing_whitespace = true

[*.md]
trim_trailing_whitespace = false

Modifier la façon dont vous voyez les onglets sur d'autres référentiels

Installez Stylus dans votre navigateur, plutôt que d'installer GitHub: des onglets de meilleure taille dans le code .

Il existe également des extensions Google Chrome:


2
Il semble que github ne respecte pas le fichier editorconfig pour les fichiers sans nom (.gitconfig, etc.). Une idée pourquoi ou est-ce un bug? Ex github.com/rmandvikar/git-setup/blob/tabs/.gitconfig
hIpPy

7
les dotfiles ne semblent pas être respectés avec le [*](sur github). J'ai dû ajouter une autre entrée avec [.*].
PotatoFarmer

Cela devrait être de loin la réponse acceptée! Je suis étonné que Github suive les règles de configuration de l'éditeur.
Maurício Giordano

1
Ce n'est pas respecté dans les commits :-(
Nikola Mihajlović

1
@rofrol Je pense que je me suis trompé. La taille de l'onglet fonctionne correctement dans le code et les différences, mais pas dans les README.mdextraits de code. Ceci est une nouvelle observation; Je ne sais pas si les README.mdextraits de code ont déjà fait des tailles d'onglets autres que 8 espaces.
Redsandro

68

Il est en fait possible de le faire, avec une extension de navigateur. Installez Stylish (dans Firefox ou Chrome ), puis installez ce style d'utilisateur: " GitHub: onglets de meilleure taille dans le code ».

Cela pourrait ne pas fonctionner pour certaines langues. Par exemple, je consultais un fichier JavaScript et je n'ai remarqué aucun changement. J'ai donc supprimé le style de l'auteur et y ai ajouté les lignes suivantes:

.tab-size {
  -webkit-tab-size: 4 !important;
     -moz-tab-size: 4 !important;
       -o-tab-size: 4 !important;
          tab-size: 4 !important;
}

Et cela a fonctionné sur Chrome ( capture d'écran ).

Comme vous pouvez le voir sur la capture d'écran, j'ai également activé le mode écran large et changé le jeu de couleurs en Solarisé. J'ai donc trois styles d'utilisateur fonctionnant sur les pages GitHub via l' extension Stylish pour Chrome . J'espère que ça aidera quelqu'un.


18
J'ai écrit ce style d'utilisateur . Je suis content que vous l'ayez trouvé utile. Je l'ai corrigé et testé dans Chrome, et cela fonctionne maintenant sans votre modification.
Rory O'Kane

2
Vous aimerez peut-être aussi mon style d'utilisateur « Tout le code a une taille d'onglet 4 », qui modifie la taille d'onglet des <code>éléments sur tous les sites Web.
Rory O'Kane

1
Github remplace chaque \tpar 8 &nbsp;. Merde.
Rudie

2
Oui, ils ne l'ont pas fait avant et je n'ai aucune idée pourquoi ils le font maintenant :( Je suppose qu'une solution peut être quelqu'un qui écrit un script qui remplace disons ... 4 consécutifs & nbsp; avec deux ou autre chose. Mais cela doit être un "script utilisateur" je pense.
aledujke

1
Notre style utilisateur GitHub Dark Stylish vous permet de définir la taille de l'onglet. Et il est activement maintenu.
Mottie

0

Si vous aimez les UserScripts, cela l'a fait pour moi:

// ==UserScript==
// @name         GitHub Tabs
// @namespace    http://foldoc.org/
// @version      1
// @description  Set sensible tabs on GitHub
// @author       Denis Howe
// @match        https://github.com/*
// ==/UserScript==

document.querySelectorAll('table').forEach(t => { t.dataset.tabSize = 2 });

J'aurais préféré cette alternative mais cela semble fonctionner plus ou moins au hasard: si les données n'ont pas été chargées avant l'exécution du script utilisateur (par exemple, liste des fichiers puis cliquez pour ouvrir le fichier), cela ne fonctionne pas.
dix

-3

J'ai fait ça pour les réparer http://valjok.blogspot.com/2014/07/indentation-correction-for-exposing.html .

Une autre option est lors de l' intégration de votre essence , remplacez tous les onglets par le nombre d'espaces requis

<div id="willReplaceTabs">
 <script src="https://gist.github.com/valtih1978/99d8b320e59fcde634ad/cf1b512b79ca4182f619ed939755826c7f403c6f.js"></script>

 <script language="javascript">
  var spaces = "  "
  willReplaceTabs.innerHTML = willReplaceTabs.innerHTML.replace(/\t/g, spaces)
 </script>
</div>

-6

Si c'est une option pour le projet sur lequel vous travaillez, changer votre éditeur pour traiter les onglets comme des espaces résoudra le problème.

Ainsi, par exemple, dans Visual Studio Code, la configuration ressemble à ceci:

{
    "editor.tabSize": 2,
    "editor.insertSpaces": true
}

Dans Sublime, c'est:

{
    "tab_size": 2,
    "translate_tabs_to_spaces": true
}

Jusqu'à récemment, j'insistais sur des onglets non espacés. Après la commutation, cela a corrigé l'étrangeté du rendu Github, et je n'ai remarqué aucun inconvénient significatif dans mon flux de travail.


-20

La meilleure solution est, si possible, de convaincre les responsables du code source que vous recherchez de remplacer tous les onglets par le nombre correct d'espaces.

L'utilisation d'onglets est problématique dans le code aujourd'hui étant donné que vous le voyez souvent sur le Web, où la décision de "combien d'espaces par onglet" dépend de l'endroit où il est affiché.


7
Ceci est la bonne réponse et ne mérite pas d'être déclassé. Il y a beaucoup trop de logiciels qui ne vous permettent pas de changer la largeur des onglets pour que "les onglets soient configurables" pour être autre chose qu'un vœu pieux. Et si jamais vous indentez quelque chose à une distance qui n'est pas un multiple de votre largeur de tabulation préférée, vous avez maintenant un mélange de tabulations et d'espaces et le réglage de la taille des tabulations ne fonctionne même plus.
zwol

8
Lisez l'article Wikipédia sur l'origine de l'onglet à 8 espaces. "Une taille de tabulation horizontale commune de huit caractères a évolué, en dépit de cinq caractères étant un demi-pouce et l'indentation de paragraphe typique de l'époque, car en tant que puissance de deux, il était plus facile de calculer en binaire pour l'électronique numérique limitée disponible." Votre réponse utilise un raisonnement circulaire (c'est-à-dire que la norme est de huit caractères parce que c'est la norme) pour fermer la porte à la question. Le demandeur n'est pas satisfait de cette norme et a peu de raisons de l'être.
Adam

4
@mrjedmao Oui, vous pouvez le faire ?ts=4.
Ben

5
Je préfère la tabulation à l'espace, car cela accélère mon édition entre 4 et 8 fois lorsque je déplace mon curseur sur un espace.

4
"Sauf la personne qui paie le développeur, hmm?" L'IDE de votre cerveau a-t-il utilisé sa fonction de déplacement par ligne pour ignorer la phrase suivante? J'ai explicitement déclaré que les conventions appliquées d'un projet ont priorité sur les préférences individuelles. || "Pourquoi faites-vous cela à vous-même, alors que tous les éditeurs ont une fonction de déplacement par mot / champ / ligne?" Oui, vous sous-entendez qu'il est plus facile d'utiliser la fonctionnalité d'un éditeur pour parcourir le code que de simplement appuyer sur une touche pour parcourir une colonne entière. De plus, tous les éditeurs n'ont pas dit ces fonctionnalités, et certains fonctionnent même différemment. Arrêtez de penser que le monde entier utilise Sublime.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.