Visual Studio Code (vscode): szívások, hasznos infók

 ( Lacaa | 2019. szeptember 19., csütörtök - 12:45 )

Megy ez, csak okosítani kell, konfigurálni, extenziókat megtalálni, telepíteni; de ehhez úgy kell harapófogóval kihúzni a netből az infókat.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Remote-SSH kiegészítő: Tetszik. Csak tudni kell:
- a célgépen létrehoz egy ~/.vscode-server könyvtárat, ahova egy csomó mindent pakol,
- a másik gépet csak külön ablakba nyitja meg (új ablak nyitásról mindjárt) (a bal alsó sarokban a "><" (Open a remote window)-t kell megkattintani),
- ha nem akarom mindig bepötyögni, hogy 'laca@pici', akkor érdemes létrehozni egy konfigurációt (elsősorban a .ssh/config fájlt kínálja fel), hogy pl.
# vscode kedvéért
Host pici
 HostName pici

és akkor a 'pici' kiválasztható lesz.

--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

Új ablak megnyitás:
Az első ablak méretére emlékszik. De a másodikat (pl. másik gépet Remote-SSH-val) alapból középre picsányi méretben jeleníti meg.
A konfigját Window / New Window / New Window Dimensions alatt találtam meg. De csak ezek a választási lehetőségek vannak: Default (ez a picsányi), Inherit, Maximized, Fullscreen. Ebből nekem az Inherit a legjobb; ez ugyanoda egy ugyanakkora ablakot növeszt, mint az első ablak.

--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

Ennek van valami előnye `ssh user@host` a terminalba + sshfs megoldással szemben?

Annyi, hogy nem kell pötyögni, csak egerészni.
Ja, és az sshfs-sel szívtam régebben, zombi processzeket hagyott.
--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

Java a homokozóban (ez volt a legnagyobb szívás):
flatpak-ból működtetem a vscode-ot, és használom a scalavista extenziót, ami megköveteli, hogy a java installálva legyen, és a PATH-on megtalálható legyen.
No, hát az /usr/lib/jvm/default-runtime/bin természetesen nem látszik a homokozóban (még az /usr/lib sem), ill. /run/host/usr/lib/jvm/default-runtime/bin alatt látszik.
Egy ilyet kellett kiadni:
flatpak override --user --env=PATH=/app/bin:/usr/bin:/home/laca/.var/app/com.visualstudio.code/data/node_modules/bin:/run/host/usr/lib/jvm/default-runtime/bin com.visualstudio.code
De mire ezt kiderítettem...
Ja, és ezt a homokozóbeli PATH-ra alapozva írtam. Ha ez megváltozik, megint szívhatok.

--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

...Szívtam, de egész mástól. (OFF, mert a flatpak-ról szól.)
Frissült a scalavista kiterjesztés... és nem indult el. Aszongya, nem tudja megnyitni a /jre/lib/amd64/jvm.cfg fájlt.
Nem hát, mert a fenti módon be-PATH-olt javában az egy szimb.link /etc/java-8-openjdk/amd64/jvm.cfg-re. Az pedig a homokozón belül a kiskutya seggibe' van, /run/host/etc/... alatt.
...Végül installáltam az openjdk11 flatpak-csomagot. Ettől lett egy, a homokozóban látható /usr/lib/sdk/openjdk11 .
Közben arra is rájöttem, hogy a JAVA_HOME körny. változóban is meg lehet adni a java helyét, és akkor nem a PATH-on keresi; vagyis a fenti flatpak override hülyeség. Ez kell:

flatpak override --user --env=JAVA_HOME=/usr/lib/sdk/openjdk11 com.visualstudio.code

(vagy pedig bundle, vagy flatpak-builder, vagy a tök tudja, milyen "igazi" megoldása van egy flatpak-nak utólag függőséget (vagy runtime, vagy mi a tök) beépíteni). Így legalább attól nem fogok szívni, amit gondoltam.

--
[laca@artix ~]$ %blow
bash: fg: %blow: no such job

(másik példa az egerész hajlamomra:)
Mi az, hogy egy kódeditornak nincs megkattintható Visszacsinál, Újracsinál, Ment funkciója?!
Erre találtam a commands extenziót. Mondjuk, nem felülre, egy toolbar-félére, hanem alulra az állapotsorba lehet gombokat definiálni, de annyi baj legyen.
A fő konfigfájlban (settings.json) lehet konfigurálni, pl. így:
"commands.commands":
[
{
"command": "undo",
"text": "$(chevron-left) Vissza",
},
{
"command": "redo",
"text": "Újra $(chevron-right)",
},
{
"command": "workbench.action.files.save",
"text": "Ment"
},
{
"command": "workbench.action.files.saveAll",
"text": "MentMind"
}

] (a töké nem indentálja)
Itt is, mire megtaláltam a parancsneveket... (a Keybindings alatt találtam meg)
Hogy milyen $(ikonnev)-eket lehet használni, azt is megtaláltam, de most megint nem találom.
--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

[code]
   közé
      kell
         rakni
[/code]

Köszi (itt volt az is, hogy 'BBCode jelölők használata engedélyezett', de nem figyeltem).
--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

Ja, megvan (ikonnév): https://octicons.github.com/
--
[laca@artix ~]$ %blow
bash: fg: %blow: no such job

A scalavista-nak, úgy tűnik, saját dependencia-kezelője van, amit lehetne konfigurálni a scalavista.json-ban, de még nem nyúltam hozzá. A ./lib-et ismeri; egyszerűbb volt azt az egy jar-t odamásolni az .ivy2 alól (ahova az sbt tette), ami hiányzott.
--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

Js -hez használom vagy másfél éve. Szeretem, de az már nem érdekel, hogy 2 vagy 4 space az ident, mert kb. 20* beállítottam a 4-et, de bizonyos időközönként visszaáll 2-re. Eleinte nagyon zavart, de most már észre sem veszem. A .editorconfig így kezdődik:

root = true
[*]
charset = utf-8
indent_style = space
indent_size = 4
...

Ez vagy egy kiterjesztés, vagy nem is a vscode. Én még idáig csak json alakú konfigfájlokat találtam.

De ez eszembe juttatott még egy szívást:
Nálam az Editor: Tab Size alapból 4 volt, átállítottam 2-re. Tojt működni a settings.json-ban. Mint kiderült, azért, mert ki kell kapcsolni az Editor: Detect Indentation-t ahhoz, hogy egy meglévő, már valahogy indentált fájlban is érvényesüljön.
--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

Ott van a hszben, hogy editorconfig. Keress rá, hasznos kis cucc.

ez tényleg hasznos, tnx meg sub. :)

Ha jól értem, arra jó, ha az ember sok editort használ, és mind ugyanazzal akarja konfigurálni.
--
[laca@artix ~]$ %blow
bash: fg: %blow: no such job

meg arra, hogyha ugyanazt a kódbázist többen akarjátok különböző editorokból használni.
meg arra, hogyha ugyanabban az editorban különböző projecteket különböző módon akarsz formázni.

Ha ennyi szivas van vele, megeri hasznalni? Kate (KDE alatt default) eleg sokat tud, szeretem hasznalni. Miben jobb a vscode nala?

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Nem tudom, Kate-t még nem használtam. Biztos, hogy nem voltak vele kezdetben szívások?
Én ezt csak most kezdem használni. Hátha csak kezdetiek a szívások.
Amúgy KDE-tlen gépre tettem fel, ami amúgy is "tele van", többet nem akarok installálni rajta a csomagkezelőjével. Flatpak-os Kate meg nincs.
--
[laca@manjaro ~]$ %blow
bash: fg: %blow: no such job

Emiatt: https://langserver.org/

A Language Server Protocol segítségével szétválik a code completion, ellenőrzés stb. támogatása - bármely LSP-t beszélő szerkesztő azonnal okos lesz az X nyelvre.
Szép decoupling ez a szerkesztő és a nyelvi elemző között, platformfüggetlen módon.

Én a Javas LSPt néztem, s az így ránézésre tele van custom parancsokkal, meg a vscode is mintha mellé rakna millió kiegészítést. Szóval annyira nem meseszerűen válik szét, de jah, elsőre nem rossz elképzelés.

A Java LSP-t a Red Hat szállítja, egy az egyben az Eclipse-ben lévő JDT tudása van benen (Azt használják belül).
A Microsoft valóban csinál egy Java nyelv és ecosystem használatát könnyítő plugin metacsomagot, de az csak a RH-os LSP, a Maven támogatás, a debugger (LSP-t használ ez is) és ennyi talán.
Én amúgy nem szeretem a Javas LSP-t, mert az Eclipse-s plugint nem lehet leszoktatni arról, hogy ne hozzon létre .classpath és .project file-t (mindezt minden Maven modulhoz), szemetelve ezzel a filerendszert. Ezt az egészet (.project, .classpath) igazán kezelhetnék máshogyan.

Sok editorral kínlódtam a webes dolgaimhoz (a kate nem volt közte). A vscode-t kipróbáltam, felraktam pár extensiont és azóta azt használom. Ezzel vagyok a legproduktívabb még akkor is ha néha idegesít pár dolog.

Az én szememnek kicsi a behúzása a workspace tree -nek. Nem látom egyből, hogy melyik fájl melyik könyvtárban van. Lehet ezt növelni? Mikor rákerestem találtam másokat is ezzel a problémával de nem találtam megoldást.

Ha a baloldali cuccokra gondolsz, akkor lehet, kollégával megkerestük, holnap megnézem ha el nem felejtem :-)

Bal oldalt a projekt könyvtár szerkezete. Nekem kicsi a behúzás.

Settingsben a Workbench / Appearance alatt van egy Tee: Indent, ott lehet állítani.

thx.
8px volt, felvettem 16-ra de az sem tetszett. Most 32px, egyenlőre így marad. Köszönöm szépen.

nincs mit :)

Nekem teljesen jó az a 8px; az az oldalsáv úgysem lehet tudjisten milyen széles.
--
[laca@artix ~]$ %blow
bash: fg: %blow: no such job

Hello!

Főleg C fejlesztésre használom, s nagyon kényelmesnek találtam a grafikus debugger felületét. Mivel néhány projecthez Dockerben van a fordítási környezet, ezért jól jöttek az alábbi beállítások a launch.json-ban. S mint Lacaa kolléga megjegyezte: Ha nem javascriptet vagy css-t akarsz vele fejleszteni, akkor kb felejtsd el a neten található leírásokat...

- gdbserver megadása:

      "request": "launch",
      "miDebuggerServerAddress": "localhost:1234",

- A távoli útvonal mappolása a project-re. Így működnek a breakpoint-ok, és a struktúrák tagváltozóit (és annak értékeit) is jól mutatja.

      "sourceFileMap": {
        "/source" : "${workspaceRoot}"
      },

- További source-ok felvitele. Így nem esik kétségbe ha a host rendszerre nem telepített lib-el találkozik.

        "additionalSOLibSearchPath": "/path/glib/"

- Ha saját task van megadva a fordításhoz, akkor alapból nem tudja értelmezni a fordító kimenetét. Ehhez meg kell adni egy problemMatcher-t, ami regex groupokba pakolja a kimenetet. gcc-hez:

      "problemMatcher": {
        "owner": "cpp",
        "fileLocation": [
          "relative",
          "${workspaceFolder}"
        ],
        "pattern": {
          "regexp": "^/source(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
          "file": 1,
          "line": 2,
          "column": 3,
          "severity": 4,
          "message": 5
        }
      },

Üdv,
Laci

Én már jó ideje használom a VS Code-ot. Alap programok között van, amit saját gépre felrakok.

Kb minden fajta programozásra ezt használom, legyen az web vagy natív fejlesztés.

Munkahelyemen is ezt használom PHP (Symfony 2-3) fejlesztésre

Az elején kellett vadászni, hogy melyik kiegészítők is a legjobbak egyes feladatokra, de ha ezen túl van az ember, akkor nagyon kényelmes környezetet tud kialakítani magának.

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"