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

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.

( Lacaa v | 2019. 09. 19., cs – 15:54 )

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

( Lacaa v | 2019. 09. 19., cs – 16:18 )

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ég jó, hogy ezt leírtam; mert elfelejtettem, aztán installáltam az openjdk-t (11 nélkül), aztán meg pislogtam, hogy mi baja van, hogy a JAVA_HOME-ban invalid java van.

Vissza kellett ezt nézni, és rájönni, hogy ki kell adni a flatpak override-ot is a 11 nélkül.

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

( Lacaa v | 2019. 09. 19., cs – 16:46 )

(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

( Lacaa v | 2019. 09. 19., cs – 16:55 )

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

Rákérdeztem: az sbt-ben az sbt-scalavista plugint kell használni a scalavista.json generálásához.

(Off: közben kiderült, hogy az sbt egy másik helyi repót használ az .ivy2 mellett (helyett?), a .cache/coursier -t.)

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

( zolti v | 2019. 09. 19., cs – 17:20 )

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

( Nyosigomboc v | 2019. 09. 19., cs – 17:33 )

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.

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.

( zolti v | 2019. 09. 19., cs – 19:27 )

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.

( KLaciBoy | 2019. 09. 20., p – 09:37 )

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

( pehsa | 2019. 09. 20., p – 11:41 )

É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"

( zolti v | 2021. 01. 01., p – 20:58 )

A napokban tettem fel a https://packages.microsoft.com/repos/vscode/ repo-ból és létrejött egy pár mappa és fájl a home alatt:

CachedData 'Crash Reports' languagepacks.json CachedExtensions 'Local Storage' rapid_render.json Templates Backups 'Code Cache' 'exthost Crash Reports' logs 'Session Storage' blob_storage Cookies Dictionaries log.txt 'Network Persistent State' TransportSecurity Cache Cookies-journal GPUCache machineid storage.json User

Úgy látom a vscode hozta létre őket. Hogy lehetne beállítani neki egy saját mappát ?

Előre is köszi.