[MEGOLDVA] non-breaking space beszúrása CLI-s szövegszerkesztők alatt

Debian GNU/Linux

Sziasztok. Debian alatt hogyan állítható be, hogy mondjuk caps lock+space esetén non-breaking space-t szúrjak be cli-s szövegszerkesztők esetén (mcedit, nano, micro stb)?

Azt tudom, hogy létezik setxkbmap, amivel sok mindent lehet állítgatni, pl nbsp-t is, ami talán ezt a cél szolgálná, de nemigazán értem, hogy mi lenne az nbsp:level2 opció.

( Raynes | 2023. 01. 25., sze – 15:52 )

Az npsb:level2 az a Shift+space-re vonatkozik. Elvileg a level2 váltóbillentyűje változtatható, de csak relációs jelekre (kacsacsőr karakterekre), más billentyűre nem módosítható.

Ha a Caps Lockhoz ragaszkosz, akkor nbsp:level3,lv3:caps_switch, így működni fog. De nem javaslom a Caps Lock használatát, az egyik legidegesítőbb, leghaszontalanabb billentyű, ha rám hallgatsz, átállítod vagy Ctrl-ra (Emacs-felhasználók szokták), vagy Esc-re (vim/vi-t használók kedvence, nálam is ez van), vagy none-ra (ezzel letiltod), de akár compose key-t is lehet belőle csinálni. A részletekről a man xkeyboard-config alatt tudsz olvasni (ez érvényes nem csak X.org alatt, de Wayland alatt is általában ugyanezek az opciók).

Én a részemről a caps:escape,nbsp:level2 opciókat használom (és még másikakat is, de azok nem relevánsak a téma szempontjából).

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Örülök. Arra még figyelj, hogy nem minden alkalmazás és terminál alatt működik. Több mindennek össze kell jönnie hozzá, hogy működjön:
1) terminálnak tudnia kell (az elterjedtebbek támogatják, de pl. a tty nem)
2) shellnek tudnia kell (ezt azért szokták tudni a főbb shellek, pl. Bash, zsh, fish, stb.)
3) a lokalizációnak tudnia kell (Unicode)
4) az alkalmazásnak tudnia kell (szintén Unicode-támogatás), de olyan szinten, hogy valóban ne is törje tördeléskor

Ha ezek nem állnak fent, akkor nem minden esetben megy, lehetnek olyan alkalmazások, amik nem támogatják. Pl. nekem neovim-ben megy az nbsp, de nem megy readline-ban, ed-ben, calc-ban, azokban az alkalmazásokban csak normál, törhető szóköz lesz belőle.

A másik, hogy sokszor akkor sem érdemes nbsp-t közvetlenül beszúrni, ha az alkalmazás támogatja. Ennek az az oka, hogy emberek megnyithatják később a doksit olyan szoftverben, ami nem támogatja, sima szóközzel menti felül, stb.. Ezért nem magát az nbsp karakterét szokták beszúrni, hanem az escape-elt kódját, így nem csesződik el később, és mindenkiben tudatosul, hogy az ott egy speciális karakter, és nem egy normál szóköz:

HTML/XML/Markdown:  
TeX/LaTeX: ~
shellscript: \u00A0
vimscript: \%u00a0

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ezt nem egészen értem.

Egy sima Unicode karakterről van szó, ami koncepcionálisan semmiben nem különbözik például az "ő" betűtől. Vagyis a szoftvernek, illetve programozójának semmi extra teendője nincs a karakterrel kapcsolatban ahhoz, hogy pont úgy működjön, ahogy működnie kell (feltételezve, hogy támogatja a Unicode-ot, ami azért remélem elég alap mára).

Amit te úgy hívsz, hogy "támogatja", az az én szememben "működik, mert ez a default, és senki se nyúlt hozzá".

Amit te úgy hívsz, hogy "nem támogatja", az az én szótáramban "szánt szándékkal elcseszi". Én még nem találkoztam ilyen szoftverrel, és nem tudom alátámasztani azt az állításodat, hogy a readline sima szöközt csinálna belőle.

> semmi extra teendője nincs a karakterrel kapcsolatban ahhoz, hogy pont úgy működjön, ahogy működnie kell 

Ez így ebben a formában nem igaz. Minden Unicode karakterrel kapcsolatban van tennivaló, hogy úgy működjön, ahogy kell, például ki kell rajzolni. Minden egyes betű, amit elmentesz egy dokumentumba, mindaddig egy bithalmaz, amíg meg nem kell jeleníteni, és ki nem kell rajzolni ezeket a karaktereket.

Kétféle karakter létezik:

- amit simán csak meg kell jeleníteni (betűk, emojik, írásjelek, stb), ezek az "egyszerűbb" esetek, fogod a betűkészletet, megkeresed, hogy mi van rendelve az adott bitkódhoz, kiveszed a vektorgrafikus képet és kirajzolod. Valójában ez se ilyen egyszerű. mert egy csomó speciálisan kirajzolandó Unicode karakter létezik, de ezt most elegánsan léptessük túl.
- úgynevezett vezérlőkarakterek. Ilyenek például a szóköz, a sortörés, az oldaltörés, a kocsivissza, a BELL, a színváltoztató ANSI szekvenciák, stb. Ezeknek a működését külön le kell kódolni ahhoz, hogy maga a hatás, amire rendelve vannak, megvalósuljon.

Vegyük a legegyszerűbbet, a BELL-t, ugye ennek egy egyszeri pittyegést kell kiadnia. Igen ám, de hogyan? Egy grafikus alkalmazás esetén egyértelmű, hogy az aktuális default hang outputon, de Linux alatt ez ugye PulseAudio-tól JACK-ig bármi lehet. TTY alatt pedig még az is elképzelhető, hogy PC Speakeren kell. Ezt mind-mind le kell programozni - azaz van vele teendő. 

A legtöbb grafikus szövegszerkesztő például a kocsivisszát valójában kocsivissza+soremelésként valósítja meg, holott ennek terminálok esetén kritikus szerepe van, hogy az adott sort felül tudod írni akár a képernyő utolsó sorában is, anélkül, hogy görgetnéd a képernyőt. Másképpen kódolták le a grafikus szerkesztőkben ezt a hatást.

Aztán ott vannak példálul a színváltós ANSI szekvenciák. Magának a szoftvernek támogatni kell a színes karaktereket, és ezeknek állapotának szabad változtatását, azaz soron belül is meg kell tudni változtanti a karakterek színét, hátterét, stb, ami például függ attól is, hogy a keretrendszer, amiben megvalósítják magát a szerkesztő-megjelenítő eszközt, mire képes ezek kapcsán. Azaz, a szoftver programozójának itt is van extra teendője ezzel.

Ami a nem törő szóközt illeti, ez a legtöbb esetben a weben és tipográfiában értelmezett dolog, nem véletlen, hogy mindkét helyen speciálisan kell beilleszteni, és minden részt vevő alkalmazástól támogatottságot igényel. Alapból ugyanis a legtöbb szoftverben a szövegkezelés úgy van megvalósítva, hogy a legközelebbi whitespace karakternél tör, bármi is legyen az. Az nbsp pedig tulajdonképpen whitespace karakternek minősül (például szóhatároló karakter), de mégsem lehet ott eltörni a szöveget (hiszen ezért nem törő szóköz!), így megintcsak külön feladata van a programozónak ennek támogatásában.

Normál plain text fájlokban ez a karakter nem túl gyakori, emiatt sok szövegszerkesztő - pláne a konzolosok - egyáltalán nem, vagy csak részlegesen vannak rá felkészítve. Néhány szövegszerkesztő "egyszerűsíti", "normalizálja" a benyitott szövegfájlt, például automatikusan egységesíti a sortöréseket. Egy ilyen karakternél, mint az nbsp simán lehet, hogy mivel whitespace karakternek érzékeli, és nem sortörés, a normalizálás során kicseréli normál ASCII 32-es szóközre.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Alapból ugyanis a legtöbb szoftverben a szövegkezelés úgy van megvalósítva, hogy a legközelebbi whitespace karakternél tör, bármi is legyen az. Az nbsp pedig tulajdonképpen whitespace karakternek minősül (például szóhatároló karakter), de mégsem lehet ott eltörni a szöveget (hiszen ezért nem törő szóköz!), így megintcsak külön feladata van a programozónak ennek támogatásában.

A mai világban ez azért inkább úgy működik, hogy figyelembe veszik, hogy mi van Line Break táblában az adott karakternél. Szóval nem igazán külön feladat.

> Minden Unicode karakterrel kapcsolatban van tennivaló, hogy úgy működjön, ahogy kell, például ki kell rajzolni.

Ezen lépés a non-breaking space esetén semmi különös tennivalót nem igényel. Fogod a fontból, kirajzolod, és ha esetleg ténylegesen megjelent valami, az a font hibája, nem a programé.

> úgynevezett vezérlőkarakterek. Ilyenek például a szóköz

Szóköz mint vezérlőkarakter, ne vicceljünk kérem!

> úgynevezett vezérlőkarakterek. Ilyenek például [...] a sortörés, az oldaltörés, a kocsivissza, a BELL, a színváltoztató ANSI szekvenciák

Ezek mind teljesen irrelevánsak a jelen témában.

> Ami a nem törő szóközt illeti, ez a legtöbb esetben a weben és tipográfiában értelmezett dolog, nem véletlen, hogy mindkét helyen speciálisan kell beilleszteni

Szó nincs arról, hogy speciálisan "kell" beilleszteni. Be lehet illeszteni pontosan úgy, mint bármilyen más szimbólumot. Ha a billentyűzetkiosztásodról elérhető, akkor akár úgy is (erről szólt az eredeti post). Ha Unicode táblából kikeresve, akkor úgy. Ha copy-paste-elni támadt kedved, úgy. Ha mondjuk Ctrl+Shift+U és utána a hexa Unicode érték, akkor úgy. Történetesen az sem kizárt, hogy egy program nyújtson egy külön menüpontot is a bevitelére. De minden beviteli mód, ami betű bevitelére alkalmas, szükségszerűen alkalmas a nbsp bevitelére is.

> Alapból ugyanis a legtöbb szoftverben a szövegkezelés úgy van megvalósítva, hogy a legközelebbi whitespace karakternél tör, bármi is legyen az. Az nbsp pedig tulajdonképpen whitespace karakternek minősül (például szóhatároló karakter), de mégsem lehet ott eltörni a szöveget (hiszen ezért nem törő szóköz!), így megintcsak külön feladata van a programozónak ennek támogatásában.

Igen, a programozó feladata, hogy lekódolja a helyes viselkedést. Ha a helyes viselkedés az, hogy szóköznél törünk, de ő helyette azt kódolja le, hogy whitespace-nél (Unicode Zs kategóriánál) tör, akkor nem az nbsp-t felejtette el jól kezelni, mint valamiféle további kivételt, hanem a sortörés kezelését basszintotta el.

Persze ha nem sortörés a cél, hanem szóhatároló karakterek megtalálása (például helyesírás-ellenőrzés céljából, vagy a "keresés" dialóusban ha bejelölöd hogy egész szót keresel), akkor meg fel kell ismerni szóhatároló karakternek.

Ezekről szólnak az UAX #14, #29 meg talán még több is.

> Egy ilyen karakternél, mint az nbsp simán lehet, hogy [...] normalizálás során kicseréli normál ASCII 32-es szóközre.

Látod, én is pont ezt írtam, csak én ezt úgy fogalmaztam meg, hogy "szánt szándékkal elcseszi" ;)

Alkalmazásfüggő. Nem elég Unicode-karakterként megjeleníteni, még le is kell kezelni pl. tördelésnél. Persze ilyenkor lehet vitatkozni, hogy támogatja-e vagy nem, ha megjeleníti, de nem kezeli mégse teljesen helyesen. Trükkös műfaj. Az én szememben a részletes támogatás nem támogatás.

A Bell-karakter az más, az régi sztenderd terminálokon, azt minden támogatja. x86, x86_64-es platformokon a PC speakerre küldik ki az implementációk, persze egyes gépek, BIOS-ok ezt úgy implementálják mégis a PCM/DSP chipre küldik ki, de erről a szoftveres oldal nem tud.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Jah semmi extrához nem kellett. Csak terminál és micro szövegszerkesztő alá kell, de csak speckó esetben. Még mindig hegesztem az lf file manager-t. Most pl azt programoztam le benne, hogy figyelje hogy adott fileműveletek igényelnek-e root jogot, és annak megfelelően működjenek. No és itt ha új command-ot adok meg, akkor a névben nem lehet space, holott 3 esetben is kellett volna, viszont a non-breaking-et elfogadja. Csak ezért kellett nekem ez. Időlegesen a libreoffice-al bele tudtam illeszteni, csak az nem túl elegáns megoldás :)

Engem is érdekelne engem is, hogy mi ez. Alapszabály, hogy parancs nevébe semmilyen különleges karaktert ne tegyél. Egyébként meg de, lehet benne space, de akkor ki kell escape-elni, pl "\ " idézőjelek nélkül, de az se jó ötlet, nem praktikus. Talán az alsó kötjel az, ami a legközelebb van hozzá.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ebben a filekezelőben fel akartam programozni, hogy ha olyan helyen akarok könyvtárat, vagy filet létrehozni, ahol nincs jogom, akkor használja a sudo -A parancsot. De sajnos a program belső patancskészlete vagy hogy nevezzem csak akkor engedi, ha aszinkron módban vagyok, viszont akkor meg nem lehet simán szöveget kiírni, hanem csak a parancs neve jelenik meg, ergo, ha azt akarom kiírni, hogy New directory -> és bekérni a nevét, akkor bizony a parancs nevének is ennek kell lennie. Ez a jelenlegi program müködéséből kifolyólag megkerülhetetlen, vagyis csak a non-breaking space működik, mert az escapelés sem megy. Szal nem jókedvemben csináltam, hanem erre kényszerültem.

Nem teljesen világos, de kezdtem érteni valamennyire a probléma természetét. Ebben az esetben az lf fejlesztőjének kéne egy bug reportot vagy feature requestet betolni git issue-ba, hogy ilyen esetben implementálja, hogy a szabvány escape-elés is működjön, és a kedves usernek ne ilyen spéci nem tördelhető karakteres hekkeléssel kelljen gányolnia, mert iszonyat gáz.

Ötlet: printf "New directory: "; read blabla, és mindez meg egy shell scriptben futtatod lf-ben vagy lf-configban &szkriptem formában. Így elvileg ki is lehet írni (man lf szerint mennie kell a printf-nak), meg más parancsot is lehet futtatni. Nem biztos, hogy működik, de meg lehetne próbálni.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Sajnos nem ilyen egyszerű. A printf működik, de csak ha a command %-val van használva, ha &-vel akkor nem írja ki alulra, hisz olyan mintha a háttérben használná, viszont ebben a módban ha a felmapoelt billel hívom meg a command nevét, akkor acomnand nevét kiírja alulra, és vár egy billt. Nah ezért lett ilyen a command neve.

A fejlesztővel más okból kifolyóla beszéltem már, mert teljesen átvariáltam benne a másolás, mozgatás parancsot, és már akkor jelezte, hogy se ideje, se kedve nincsen foglalkozni mostanában vele, úgyhogy az a pár ember javítgatja, akinek van jogosultsága, de csak apróbb dolgokat helyeznek bele. De ez a probléma szerintem huszadrangú. Sokkal gázabb, hogy nem képes tabos megoldással működni, hanem server-client megoldást használ, ha több ablakra van szükség. Ez egy igen nagy faszság. Nem véletlen, hogy senki nem használ ilyet. Vagy dual pane, vagy tab-es megoldás.