Jest taka klasa problemów, których anglojęzyczne poradniki nie opiszą, bo dla nich nie istnieją. Ten jest najlepszym przykładem: piszesz komentarz po polsku w IntelliJ, wciskasz AltGr i L, żeby dostać „ł” — a edytor formatuje cały plik. Litera się nie pojawia.

Mechanizm: AltGr to nie jest osobny klawisz

Na Windowsie prawy Alt w układzie polskim nie jest samodzielnym modyfikatorem. System raportuje go aplikacjom jako Ctrl + Alt. To nie jest błąd ani obejście — tak działa mechanizm AltGr od czasów, gdy trzeba było zmieścić trzeci poziom znaków bez dokładania klawisza.

Konsekwencja jest natychmiastowa: każdy polski znak diakrytyczny jest dla aplikacji akordem Ctrl+Alt+litera. Jeśli program ma pod tym akordem własny skrót, wygrywa skrót — bo aplikacja widzi go pierwsza, zanim system zdąży złożyć literę.

co widzi aplikacja
naciskasz:            AltGr + L
system raportuje:     Ctrl + Alt + L

edytor tekstu:        → wstawia „ł”      (nie ma skrótu pod tym akordem)
IntelliJ / WebStorm:  → Reformat Code    (ma skrót — i wygrywa)
To jest cała przyczyna. Nie ma tu żadnej wady układu klawiatury ani systemu — jest kolizja przestrzeni nazw, w której polski alfabet i skróty edytora sięgają po ten sam akord.

Trzy kolizje, które bolą najbardziej

W domyślnym zestawie skrótów JetBrains (IntelliJ, WebStorm, PyCharm, Rider) trzy skróty trafiają dokładnie w polskie litery — i to nie w byle jakie:

domyślne skróty JetBrains vs polskie znaki
Ctrl+Alt+L   Reformat Code       ⟷   ł
Ctrl+Alt+O   Optimize Imports    ⟷   ó
Ctrl+Alt+S   Settings            ⟷   ś
Zestaw skrótów bywa różny między wersjami i keymapami — sprawdź swój w Settings → Keymap. Ale akurat te trzy są domyślne od lat i to one odpowiadają za większość zgłoszeń „nie mogę napisać ł”.

Skala: 43% polskich znaków, co siódme słowo

Można by uznać, że to drobiazg dotyczący trzech liter z dziewięciu. Policzyliśmy to na własnym korpusie — 4 973 znaków diakrytycznych w prozie tego bloga — i wychodzi coś innego:

ę

19.3%

ł ⟷ Reformat

17.4%

kolizja

ą

13.6%

ó ⟷ Optimize

13.1%

kolizja

ś ⟷ Settings

12.8%

kolizja

ć

11%

ż

9.7%

ń

2%

ź

1.1%
Trzy kolidujące litery to 43% wszystkich polskich znaków w tekście — bo trafiło akurat na ł, ó i ś, a nie na ń i ź, które prawie nie występują. W przeliczeniu na słowa: co siódme słowo (14%) zawiera przynajmniej jedną z tych trzech liter.
lib/komunikaty.ts
export const BLEDY = {
  pusteHaslo: 'Hasło nie może być puste.',
  zaKrotkie: 'Hasło musi mieć przynajmniej dwanaście znaków.',
  zajetyAdres: 'Ten adres jest już zajęty — spróbuj się zalogować.',
  brakZgody: 'Zaznacz zgodę na regulamin, żeby przejść dalej.',
  sesjaWygasla: 'Sesja wygasła. Zaloguj się jeszcze raz.',
} as const;

Osiemnaście ogonków na 333 znaki — co osiemnasty znak to akord z prawym Altem. Sam kod jest po angielsku; polskie znaki siedzą w tym, co widzi człowiek. Otwórz plik w edytorze i zobacz, gdzie dokładnie wypadają.

Cztery wyjścia, od najlepszego

  1. Przemapuj trzy skróty w IDE

    Najprostsze i najbezpieczniejsze. W JetBrains: Settings → Keymap, wyszukaj Reformat Code, Optimize Imports i Settings, i przypisz im coś bez Ctrl+Alt. Zajmuje dwie minuty, działa na zawsze i nie rusza niczego poza edytorem.

  2. Sprawdź, czy Twoje IDE w ogóle ma ten problem

    VS Code jest tu znacznie łagodniejszy — większość jego domyślnych skrótów siedzi pod Ctrl+Shift, nie Ctrl+Alt. Zanim zaczniesz cokolwiek zmieniać, napisz w edytorze ł, ó i ś i zobacz, co się stanie.

  3. Rozważ osobny keymap dla pracy po polsku

    Jeśli piszesz dużo komentarzy i dokumentacji po polsku, a skróty Ctrl+Alt masz w palcach z innych powodów, JetBrains pozwala trzymać kilka keymapów i przełączać je. To rozwiązanie dla osób, które naprawdę pracują w dwóch trybach.

  4. Ostateczność: zmiana zachowania prawego Alta w systemie

    Da się sprawić, żeby prawy Alt przestał być raportowany jako Ctrl+Alt. Odradzamy — to wyłącza AltGr globalnie, więc rozwiązuje kolizję kosztem możliwości pisania polskich znaków w ogóle. Rozwiązanie problemu przez usunięcie funkcji.

Co z macOS i Linuksem

Na macOS problem wygląda inaczej: polskie znaki powstają przez Option (Alt) + litera, a Option nie jest raportowany jako Ctrl+Alt. Kolizje istnieją, ale z innym zestawem skrótów — i jest ich zwykle mniej, bo macOS opiera skróty na Cmd. Na Linuksie zachowanie zależy od środowiska i konfiguracji układu; sama zasada jest ta sama co na Windowsie, ale zestaw kolizji bywa inny.

Niezależnie od systemu diagnoza jest ta sama i zajmuje dziesięć sekund: napisz ł, ó, ś w edytorze i zobacz, co się dzieje. Jeśli litery się pojawiają, nie masz problemu i nie musisz niczego zmieniać.

Dlaczego to w ogóle warto wiedzieć

Bo najczęstszą reakcją na ten problem jest przestanie pisać po polsku — komentarze i commity lecą po angielsku „bo tak wygodniej”. To wybór, który wygląda na techniczny, a jest wymuszony przez trzy domyślne skróty, które da się zmienić w dwie minuty.

Sam koszt pisania diakrytyków — niezależny od IDE — policzyliśmy osobno: to około 6% więcej pracy palców, i znika po zautomatyzowaniu akordu. Który palec obsługuje który znak, pokazuje mapa palców, a resztę znaków, które spowalniają pisanie kodu, rozkłada przewodnik po symbolach programisty.

Osobna sprawa to prompty do modeli — tam polskich znaków bywa więcej niż w kodzie, bo pisze się pełnymi zdaniami: dlaczego AI nie zastąpi klawiatury. Jeśli Twoim wąskim gardłem jest samo tempo, a nie kolizje skrótów, zacznij od pomiaru: ile WPM naprawdę potrzebuje programista i gdzie jesteś dzisiaj. Ćwiczenia na polskich znakach i symbolach są w darmowym kursie.