Tabulátor, Ön a leggyengébb láncszem, viszlát

Mármint a sok kis Nyomasek Bobónak hála, a \t avagy chr(9) karaktert el kell engedni (még akkor is, ha fix-szélességű fontot használunk, pl. programozásnál), ugyanis a derék emberek és a derék szoftverek saját jókedvük szerint csinálnak valamit, ha egy ilyen karakterrel találkoznak -- az, hogy ez korábban ez 8k+1 pozícióra lépést jelentett, az mára érdektelen.

Kieg: ja, hogy van-e ezzel kapcsolatban valamilyen javaslatom van megoldásom? Nincs. Ez is olyan dolog, amit csak elrontani volt könnyű, megjavítani nehéz/lehetetlen. Ott a szóköz, azt tessék szépen nyomkodni.

Hozzászólások

Én még nem láttam olyan editort ahol ezt nem lehetne konfigurálni... Vagy nem azokra gondolsz szoftverek alatt?

Egyrészt nem csak csupa editor a világ (most például Konfulence nevű csodaszoftverbe kell feltöltsek szöveget), másrészt meg épp arról van szó, hogy ki-ki olyan jóságot konfigurál, amit akar, szóval egységes megjelenést csak szóközök használatával lehet elérni.

hogy ez korábban ez 8k+1 pozícióra lépést jelentett, az mára érdektelen.

Valószínűleg azért, mert nem azt jelentette. Pontosabban, amikor éppen azt jelentette, akkor azon problémázhattak sokan, hogy miért annyi, miért nem 5, ami a megszokott volt, vagy miért nem lehet megadni a pozíciókat.

Note that it is difficult to enforce these conventions and
it is therefore recommended that horizontal tabs not be used
in document files.  - 19 December 1974

Akkor meg is van a lenyeg. Soha nem szerettem programozaskor. Attol meg az editor be van allitva, hogy a $COMPANY_STANDARD mennyisegu space-szel behuzza a sorokat tab gomb lenyomasara.

A strange game. The only winning move is not to play. How about a nice game of chess?

Ide kapcsolódik:  vim <tab>-ról <space>-ekre való csere, például Python3 kódban, amely nem szereti a <tab>-ot:

:set expandtab
:retab
:wq
Szerkesztve: 2023. 03. 24., p – 03:52

Amíg a tabulátort csak a sor elején használod és nem próbálod meg egy oszlopba rendezni normál szöveggel, addig nem számít, hogy a tabulátor hány karakter széles. Ebben az előadásban van egy jó példa, bár nem ez az oka, de az eredmény ugyanaz.

Például ezt elrontja a tabulátor szélesség változása:

{
------->"origin":------>{ "x": 0,------>"y": 0,>------->"z": 0->------->},
------->"somevector":-->{ "x": 42,----->"y": 420,------>"z": 4200------>},
------->"othervector":->{ "x": 1.41421,>"y": 2.71828,-->"z": 3.14159--->}
}

{
--->"origin":-->{ "x": 0,-->"y": 0,>--->"z": 0->--->},
--->"somevector":-->{ "x": 42,->"y": 420,-->"z": 4200-->},
--->"othervector":->{ "x": 1.41421,>"y": 2.71828,-->"z": 3.14159--->}
}

Ezt viszont nem:

{
------->"origin": {
------->------->"x": 0,
------->------->"y": 0,
------->------->"z": 0
------->},
------->"somevector": {
------->------->"x": 42,
------->------->"y": 420,
------->------->"z": 4200
------->},
------->"othervector": {
------->------->"x": 1.41421,
------->------->"y": 2.71828,
------->------->"z": 3.14159
------->}
}

{
--->"origin": {
--->--->"x": 0,
--->--->"y": 0,
--->--->"z": 0
--->},
--->"somevector": {
--->--->"x": 42,
--->--->"y": 420,
--->--->"z": 4200
--->},
--->"othervector": {
--->--->"x": 1.41421,
--->--->"y": 2.71828,
--->--->"z": 3.14159
--->}
}

Nyilván feladat függő, hogy ez a technika alkalmazható-e. Mivel írtad, hogy Confluence-re kell, ezért felhívom a figyelmed, hogy pl. diagramok rajzolására van egy rakás plugin, arra nem az ASCII art a legmegfelelőbb eszköz.

Dokumentumokban a space-szel formázás ősi rossz szokás, és teljességgel irtandó. Annak idején nagyon szerettem a Lyxet (aki nem ismerné: latex alapú grafikus szerkesztő), ott ha mondjuk két szóközt nyomtál egymás után, abból csak egy lett, hasonlóképpen a két soremeléshez.

Programozás más kérdés, ott valóban a megfelelő mennyiségű szóköz beillesztése szükséges.

A tabulátor már az írógépnél sem egy 8k+1 pozícióra ugrást jelentett, hanem a következő beállított pozícióra ugrást. Amelyik sw ezt nem tudja rendesen megvalósítani, azt el kell dobni, és használni helyette olyat, ami megfelelő. Azaz nem a tabulátor karakter a leggyengébb láncszem, hanem a rossz software (illetve időnként a user, pl. az, aki mondjuk forráskód szerkesztésére nem megfelelő programot használ).

> A tabulátor már az írógépnél sem egy 8k+1 pozícióra ugrást jelentett, hanem a következő beállított pozícióra ugrást.

A tabulátor az írógépnél nem egy 8k+1 pozícióra ugrást jelentett, hanem a következő beállított pozícióra ugrást.

> Amelyik sw ezt nem tudja rendesen megvalósítani, azt el kell dobni, és használni helyette olyat, ami megfelelő.

Itt van rögtön a böngésző, amit nézel. Azt hová és hogyan dobjam el? (Egyébként ez rossz példa, mert a böngésző a <pre> elemen belül default-ból a 8k+1 pozícióra ugrik a chr(9) hatására, ami a korrekt+szabványos eljárás.)

Az, hogy valaki kitalál egy más funkciót a TAB karakterre, még nem jelenti, hogy az a korrekt. És ha mondjuk a böngésző nem rendesen valósítja meg a TAB kezelést, az megint csak nem a TAB hibája, hanem a böngészőé. Viszont ha ennek kompenzálására te szóközökkel pozícionálsz, és bármely okból megváltozik a karakterkészlet, akkor minden szét fog esni.

A <pre> tagra való utalást nem láttad, vagy csak átsiklott rajta a figyelmed? Természetesen minden, amiről itt szó van, fix szélességű karaktek esetére vonatkozik.

Rant: az irógép azért nem releváns itt, mert az irógéppel (papíron) előállított szöveg minden felhasználónál ugyanúgy néz ki, az mindegy, hogy a felhasználónak van-e írógépe, és ha van, akkor azon hogy' vannak beállítva a tab-stoppok. Na ezzel szemközt ha a text-fájlban chr(9) karakterek vannak [pont erről szól ez a blob-bejegyzés, hogy nem érdemes használni őket], akkor a megjelenés a megtekintőprogram beállításain múlik.

Nem foglalkozom a különféle tag-ekkel, a tabulátor eredeti funkciójára utaltam. Az, hogy utána ki hogyan próbálta saját értelmezésére húzni az egészet, szintén nem érdekel. Ha ezek az átalakítások nem jók, akkor nem a TAB-bal van a probléma, hanem ezek különféle interpretációival.

A megtekintés meg mindenképpen a megtekintőprogram beállításain múlik, sokra mész a fix szóközzel behúzott karaktereiddel, ha a sor pl. nem fér ki.

Tab-stop-ok ugyanúgy vannak a wordben meg a legtöbb kiadványszerkesztőben. Ez nem csak írógép-specifikus funkció, a tabulálásnak - ahogy a neve is mutatja - táblázatszerű adatok egymás alá igazítására.

A böngészőben és az egyszerű szerkesztőkben azért nincs meg ez a funkciója, mert egy plaintext környezetben nincs hely ezt az információt rögzíteni, ráadásul a html-ben van konkrét táblázat komponens táblázatszerű megjelenítésre.

A böngésző azért is rossz példa, mert a legtöbb helyen, teljesen figyelmen kívül hagyja, hogy hány white-space van egymás után.

A fenti így néz ki:

<p>A böngésző azért is rossz példa,
  mert a legtöbb helyen, teljesen figyelmen kívül hagyja,
  hogy hány         white-space          van egymás után.
</p>

És ahogy bedobtam az 1974-es RFC-t, se akkor se azóta nincs egyezményes TAB méret. Az egy dolog, hogy a DOS-os szoftvernél megszoktuk, az egy dolog, hogy Linux pár klasszikus alkalmazásában megszoktuk. De nincs kőbe vésve és ezáltal sajnos nem szentségtörés az átdefiniálása.

Szerkesztve: 2023. 03. 24., p – 10:53

Most mar ott tartok, hogy a legszimpatikusabbak azok a nyelvek, ahol egyfajta formazas van eloirva (pl: Terraform), tehat minimalis szabadsaga van a fejlesztonek, hogy hogyan formazzon (elvalaszthatsz ures sorral, eldontheted, hogy megtorod-e a sort), de azontul karakterre pontosan ugyanugy kell ,hogy kinezzen, es egy verziokoveto rendszerbe megadhatom, hogy csak jol formazott kodot fogadjon be. (pl Gitlab pipeline futtatja a terraform fmt-t). 

Igy nincs vita, ha valakinek nem stimmel a kodja, akkor a commit nem lesz jovahagyva. 

(még akkor is, ha fix-szélességű fontot használunk, pl. programozásnál), ugyanis a derék emberek és a derék szoftverek saját jókedvük szerint csinálnak valamit, ha egy ilyen karakterrel találkoznak -- az, hogy ez korábban ez 8k+1 pozícióra lépést jelentett, az mára érdektelen.

A tabulátor eredeti funkciója pontosan ez volt, vagyis nincs változás. Csak az eredeti funkciót sem ismerted. Kivétel a 8k+1 pozíció, mert ez is opcionális. Etedetileg az írógép tabulátor pozícióit is lehetett programozni kis pöckokkel a az űrlapok (magyarul:form) kitöltéséhez. 

A fix szélességű font csak egy opció. Már az írógépen is létezett proporcionális írás.

És mi van akkor, ha egy bizonyos űrlapra beállított írógépből átrakod az űrlapot egy másik űrlapra beállított írógépbe?

Hát nyafizol, mert mindenki hülye! :-D

Pedig ugyanúgy működik a terminálra kiírt rögzített (!) form, amelynek az input/output mezői között lehet tab segítségével navigálni, vagy a nyomtatók VFU funkciója (variable formatter unit) - amikor pl. a sárgacsekkre a sornyomtató csak az adott pozíciókba írja az adatot. Vegyük észre, hogy ezekben az esetekben is van egy szabályrendszer és a TAB (vezérlő-) karakter csak azzal együtt értelmezhető.

No, ezzel az is kiderült, hogy a TAB nem betű. :-D

Meg az is, hogy a szabad asszociációk ellen csak az segít, ha a nyitó hsz-ben mindent alaposan (lehetőleg többször) leírok. Talán most utólag:

* text-fájlokról van szó, mint amilyen a *.txt, *.c, *.lisp

* ha a html is szóba került, akkor azon belül csakis a <pre> tagon belüli szöveg

* írógép, könyvszerkesztés, docx-fájlok, formázott képernyők nem relevánsak itt

Amikor a végén "a fő pozícióban" áll a hozzászólásom, az nem csak a topicnyinóra válasz, hanem - nagyképűen - az addigi hozzászólások figyelembevételévél készül. Ha nem gondoltad volna, akkor is! ;)

Azért, mert már van linux, Windows, html sőt xml is, attól még az írógép nagyon fontos!

Nem csak a TAB, hanem pl. a CR (kocsi vissza) és a LF (soremelés) vezérlőkarakterek is írógép funkciók. A pontos működésük még az írógépnél is szabályrendszer kérdése, ugyanis a CR használatakor (a kocsin jobb oldalon elhelyezkedő kar) az "auto LF" funkció kikapcsolható.

A TXT file extension (főként) MS DOS specifikus dolog. Bizony, tartozik hozzá egy szabályrendszer, amit elfelejtettél közölni. Ugyanis a DOS TEXT nagyjából:

- nyomtatható karakterek + CR + LF (ezek a "rekordok")

- ...

- ^Z (=EOF), ha <= MSDOS 2.0, de elmarad a >3.0 verziótól (és ha nem cseszted el a szoftvert)

Vagy unix-text-fájlokra gondoltál? ;)

Persze a sornyomtatóra is text fájl ment ki, nem lekváros kenyér.

A szabályra és a vegyes/hibás használatra gyönyörű példa a Windows only MPLAB IDE forráskód kezelése. A forráskód DOS TEXT, amíg észre nem veszed, hogy a debugger nem a megfelelő soron áll meg. Elcseszték!!

Sebaj, van egy bekapcsolható opció, amely a CR-LF, LF-CR, CR-LF-CR és ki tudja még milyen kavarodást legjobb tudása szerint igyexik javítani. Persze a kavarodási is az IDE okozta. ;) Így be tudok ulvasni unix-text forrást is.

Ha átadok egy forráskódot ([txt] - lehet pl. shell/awk/sed script is kiterjesztés nélkül, asm, c), akkor közlöm hozzá a szabályokat:

- valódi tabokat használok

- tabstop=4

- a rekordszeparátor előtt csak nyomtatható karakter állhat (tehát se space, se tab)

- a forráskódban nem állhat két space egymás mellett, csak idézőjelek között

- ha van, akkor pascal indentation

Ha nem tudod a szabályt, akkor nem tudod helyesen értelmezni a textet. Nekem működik már évtizedek óta, és semmi olyat nem használok, ami nincs a használt szövegszeresztóben vagy IDE-ben.

További ok, hogy miért ne használjunk tabulátort egy forrásprogramban (vagy más plain text fájlban): ha mondjuk egy compiler vagy más ellenőrzőprogram azt mondja, hogy a 20. sor 30. pozícióján van a hiba, akkor tabulátor-karakterek esetén honnan tudhatnánk, hogy hol keressük a 30. pozíciót? A szoftver valószínűleg nem találja ki, hogy a derék user a kedvenc editorában 3, 4, 8 vagy 9 és háromnegyed pozíciót állított-e be.

Ezt most találtam a `man cpp`-ben:

       -ftabstop=width
           Set the distance between tab stops.  This helps the preprocessor report correct column
           numbers in warnings or errors, even if tabs appear on the line.  If the value is less than
           1 or greater than 100, the option is ignored.  The default is 8.