windows 7 + gvim

[richard]

încerc să fac gvimul să poată scrie cu diacritice.
pe windows 7, în orice aplicație, mai puțin cele "foarte" user
friendly merg corect cu altgr (spre exemplu, yahoo messenger, care
captează altgr+s și îl reinterpretează ca alt+s, activând meniul),
folosind, evident, keymapul romanian (programmers).

dacă deschid un fișier codat utf8, randat cu DejaVu Sans Mono, ș și ț
apar corect.
dacă încerc, în schimb, să tastez altgr+s sau altgr+t pentru a obține
ș/ț, apar semne de întrebare.
comanda ga confirmă codul caracterelor citit (539, respectiv 537).
semnele de întrebare sunt - evident - semne de întrebare, ga zice că
au codul 63.

în mod interesant chestia asta se întâmplă și în putty, indiferent de
locale-ul setat pe server.

am încercat și schimbând termencoding pe ucs-2le, ucs-2, utf-16 și
utf16-le (windows ar utiliza unul dintre ele în reprezentarea
internă). la fel de interesant, dacă pun encoding=iso-8859-16 în vimrc
(care ar avea toate diacriticele mapate) și pun encoding default -
romanian - în setările de localizare, gvim crapă (urât, cu send error
report).

o mapare de tipul următor dă rateu:
:imap <A-s> <C-v>u0219
pentru că alt+s va tasta ș doar din alt stânga, pe când alt dreapta va
fi interpretat direct de windows, și va tasta ?. chestia asta se
confirmă prin faptul că dacă trec pe engleză, unde alt dreapta
functionează ca alt, altdreapta+s tastează ș prin mapările de vim (cu
bonusul că nici un alt program nu mai poate tasta ș acum).

problema cred că se rezumă la: ce encoding folosește intern windows și
ce encodinguri trebuie să stabilesc în vim pentru a capta și
reinterpreta corect ș și ț din keymapul romanian (programmers) ?
aparent, doar ș și ț nu merg. €, â, î și ă merg.

[Cristian Adam]

2012/5/29 richard <izua.r...@gmail.com>

încerc să fac gvimul să poată scrie cu diacritice.
pe windows 7, în orice aplicație, mai puțin cele "foarte" user
friendly merg corect cu altgr (spre exemplu, yahoo messenger, care
captează altgr+s și îl reinterpretează ca alt+s, activând meniul),
folosind, evident, keymapul romanian (programmers).

Yahoo Messenger 11 are hardcodat alt+ctrl+s și alt+ctrl+t pentru anumite
operații și nu știe să facă diferența între altgr și alt+ctrl.

Problemele vin de la noua funcționalitate multi-tab/filă. Problemele
dispar dacă dezactivezi din opțiuni această funcționalitate.

dacă deschid un fișier codat utf8, randat cu DejaVu Sans Mono, ș și ț
apar corect.
dacă încerc, în schimb, să tastez altgr+s sau altgr+t pentru a obține
ș/ț, apar semne de întrebare.
comanda ga confirmă codul caracterelor citit (539, respectiv 537).
semnele de întrebare sunt - evident - semne de întrebare, ga zice că
au codul 63.

în mod interesant chestia asta se întâmplă și în putty, indiferent de
locale-ul setat pe server.

Pentru Windows XP am rezolvat problema cu gvim, emacs și putty
prin înlocuirea codării de pagină 1250 cu 28606 de la ReactOS.

Am pus un film de prezentare aici:
http://www.youtube.com/watch?v=X_q8H-dd1KI
 

am încercat și schimbând termencoding pe ucs-2le, ucs-2, utf-16 și
utf16-le (windows ar utiliza unul dintre ele în reprezentarea
internă). la fel de interesant, dacă pun encoding=iso-8859-16 în vimrc
(care ar avea toate diacriticele mapate) și pun encoding default -
romanian - în setările de localizare, gvim crapă (urât, cu send error
report).

o mapare de tipul următor dă rateu:
:imap <A-s> <C-v>u0219
pentru că alt+s va tasta ș doar din alt stânga, pe când alt dreapta va
fi interpretat direct de windows, și va tasta ?. chestia asta se
confirmă prin faptul că dacă trec pe engleză, unde alt dreapta
functionează ca alt, altdreapta+s tastează ș prin mapările de vim (cu
bonusul că nici un alt program nu mai poate tasta ș acum).

problema cred că se rezumă la: ce encoding folosește intern windows și
ce encodinguri trebuie să stabilesc în vim pentru a capta și
reinterpreta corect ș și ț din keymapul romanian (programmers) ?
aparent, doar ș și ț nu merg. €, â, î și ă merg.

Pentru Windows 7 nu există o soluție pentru programele venite din
lumea linux/utf-8.

Problema vine de la Windows, care nu găsește ș și ț în vreo codare
de pagină, iar aplicațiile gvim, emacs, putty Windows le vede ca
aplicații ANSI și nu reușește să înțeleagă ș și ț.

Am reușit să obțin un fișier cp28606.nls care mi-a funcționat pe
Windows 7, din păcate trucul care merge pe Windows XP nu
mai funcționează pe Windows 7.

Teoretic dacă substitui fișierul cp_1250.nls cu cp_28606.nls
totul ar trebui să funcționeze, dar trebuie să ai dreptul să
faci acest lucru. cp_1250.nls este marcat ca fișier de sistem
în Windows 7.

Pentru mai multe informații vezi și discuția:
http://groups.google.com/group/diacritice/browse_thread/thread/6e25a917812f6696?pli=1

Numai bine,
Cristian.

[richard]

Nu cred că se poate înlocui un fișier din system32 direct din windows,
dar da, presupun că așa ar funcționa. Citind discuția, văd și cam ce
implică.
Hmm, dacă le vede ca aplicații ANSI e nasol. Nu există un mod de a le
face să primească direct codarea unicode/16 biți sau ce o folosi
windows intern? vim și emacs sigur știu să convertească mai departe.
Cred că faza inițială ar fi un .manifest (asta, fără recompilare).

[Cristian Adam]

Se poate înlocui fișierul c_1250.nls din Windows. Pașii care trebuie urmați sunt
prezentați la [1].

Am încercat să înlocuiesc c_1250.nls cu c_28606.nls [2], dar rezultatul nu a fost
foarte satisfăcător :(

Se pare că aplicațiile grafice au probleme cu acest fișier nls pe Windows 7. Tot
semne de întrebare apăreau și în plus nu mai puteam scrie ş și ţ cu sedilă.

N-ar trebui să fie așa greu de modificat c_1250.nls și schimbate cele patru
caractere şŞţŢ? Din păcate nu am reușit să dau de acel editor de coduri de
pagină de care s-a pomenit la un moment dat pe listă.

--
Cristian.

[1] http://helpdeskgeek.com/windows-7/windows-7-how-to-delete-files-protected-by-trustedinstaller/
[2] https://dl.dropbox.com/u/15362616/C_28606.NLS

[Cristian Adam]

On 08.08.2012 11:24, Cristian Adam wrote:

On 29.05.2012 18:44, richard wrote:

Nu cred că se poate înlocui un fișier din system32 direct din windows,
dar da, presupun că așa ar funcționa. Citind discuția, văd și cam ce
implică.
Hmm, dacă le vede ca aplicații ANSI e nasol. Nu există un mod de a le
face să primească direct codarea unicode/16 biți sau ce o folosi
windows intern? vim și emacs sigur știu să convertească mai departe.
Cred că faza inițială ar fi un .manifest (asta, fără recompilare).

Se poate înlocui fișierul c_1250.nls din Windows. Pașii care trebuie urmați sunt
prezentați la [1].

Am încercat să înlocuiesc c_1250.nls cu c_28606.nls [2], dar rezultatul nu a fost
foarte satisfăcător :(

Nu a funcționat deoarece fișierul c_28606.nls era cel peticit de mine!
O dată testat fișierul c_28606.nls  de la ReactOS totul merge ca și pe Windows XP!

Am făcut filmul de prezentare aici: http://youtu.be/oqyAEFEpZlg (acum și în HD!)

Pe lângă programele prezentate în film (vim, emacs, putty) am mai testat și
programe ANSI gen FinalDraft și TextPad.

--
Cristian.