Re: [CBLX] BRLTTY et le routage du curseur par les curseurs routines

[Dominique Asselineau <asseline@xxxxxxxxxxxxxxxxxxxx>]

Samuel Thibault wrote on Sat, Aug 29, 2009 at 12:24:57PM +0200
> Dominique Asselineau, le Fri 28 Aug 2009 17:35:09 +0200, a écrit :
> > > Ça le fait y compris au bête prompt de bash ?
> > 
> > J'ai à peu près cerné les cas et la situation la plus défavorable,
> > c'est en utilisant Emacs à distance,
> 
> Tu ne réponds pas à la question :)
> 
> Est-ce que ça le fait aussi au bête prompt de bash ?

Non, apparemment jamais, et exceptionnellement dans vi.

> 
> > > Sinon ça peut être un problème d'occupation processeur, tu peux
> > > essayer de changer ROUTING_INTERVAL dans routing.c, lui donner la valeur
> > > 1.
> > > 
> > > Pour enlever complètement l'aspect adaptatif, tu peux essayer d'enlever
> > > les deux lignes
> > > 
> > >       routing->timeSum += time * 8;
> > >       routing->timeCount += 1;
> > > 
> > > de routing.c.
> > 
> > Bon, je n'ai pas fait de détail, j'ai appliqué tout ça et ça marche
> > très bine maintenant, et dans tous les cas.
> 
> Il faudrait pourtant essayer le détail pour savoir précisément où se
> situe le problème, sinon on ne pourra pas avancer.

Bon, je viens de repasser en BRLTTY fourni dans Lenny.

Lorsque je me connecte en SSH sans contrainte particulière, tout se
passe plutôt bien.  Le routage du curseur se bloque de temps en temps
dans Emacs mais comme dit précédemment, depuis Etch, ça l'a toujours
un peu fait, en local ou à distance d'ailleurs.  Quant au prompt ou
avec Vi, raisonnablement je ne remarque rien.

Maintenant si je lance ssh à travers le filtre luit pour me connecter
à une machine en ISO depuis mon portable en UTF-8, ou même si je crée
une session Bash à travers ce filtre, les problèmes sont clairement
significatifs :
 - au prompt toujours rien d'anormal ;
 - avec Vi, c'est toujours exceptionnel ;
 - avec Emacs, en baladant le curseur sur une même ligne :
    . quand on cherche à ramener le curseur en arrière, même en traversant 
      l'écran dans toute sa largeur, ça se passe toujours bien,
    . quand on cherche à le faire avancer, sur toute la largeur de l'écran 
      ou même au-delà d'une trentaine de caractères, ça bloque à peu près 
      systématiquement et il peut se positionner sur le caractère précédent 
      sans émettre de signaux sonores.

Donc apparemment ce filtre luit pourrait bien être une des causes du
problème, ou du moins le révéler, un catalyseur en quelque sorte.

> 
> >  - Avec Etch, BRLTTY 3.7.2, le problème de routage du curseur devenait 
> > plus fréquent sans être encore vraiment gênant.
> 
> C'est le moment où le routage adaptatif a été introduit.
> 
> >  - Et avec Lenny, BRLTTY 3.10, là ça devient agaçant,
> 
> La principale différence est essentiellement une meilleure gestion du
> des lignes débordant à droite. Quand tu as des problèmes, est-ce que ton
> curseur est déjà sur la ligne où tu veux router ?

Sur la même ligne comme décrit plus haut.  À vrai dire, je ne savais
pas qu'on pouvait utiliser les curseurs routing sur une ligne repliée.
Quand ce mécanisme est arrivé il y a une vingtaine d'années, ça ne
marchait pas dans ce cas.  Il faut dire que la gestion des fins de
lignes était différente d'un éditeur à l'autre.

En résumé :
 - ça se passerait mal qu'en faisant avancer le curseur.
 - En utilisant les réglages pour désactiver l'adaptabilité du routage 
   du curseur, ça marche très bien, y-compris à travers des lignes repliées, 
   j'ai effectivement essayé.

J'espère que ces explications sont à peu près claires.

a+

dom
--

---
--
   CarrefourBLinuX MailingListe
   Pour obtenir de l'aide, envoyez le sujet  help  à:
   carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
   Archives:
   http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux