Analyseur de productivité pour vim

Question

Contexte

Je cherche à construire un analyseur de productivité pour vim qui pourrait afficher silencieusement une solution plus efficace pour une tâche particulière et répétitive de l'utilisateur. Le conseil pourrait être affiché dans le growl, la ligne d'état, etc.

Ne riez pas, mais l'idée vient de Clippy : http://en.wikipedia.org/wiki/Office_Assistant Bien sûr, je ne veux pas construire un autre truc amusant comme vigor, mais plutôt une analyse sérieuse de l'efficacité qui pourrait être particulièrement utile pour les débutants en vim.

La question

Cela a-t-il un sens et existe-t-il une théorie couvrant cette analyse ?

Answer 1

En haut de ma tête :

• Cela nécessiterait une bonne dose d'IA/de classification floue. Il est difficile d'analyser ce que l'utilisateur "essaie de faire" (souvent, l'utilisateur n'est pas clair et se laisse distraire) : Oh, réparer cette coquille pendant que je suis là ; aligner ce commentaire... ok, maintenant sur l'autre tâche).
         Ironiquement, je pense qu'en faisant les choses à la manière de 'Vim Pro', cela deviendrait plus facile (mais alors il ne serait pas utile de le repérer parce que c'est déjà optimal !)

• De même, TIMTOWTDI, vous ne pouvez pas vous contenter de dire "voici la meilleure façon de faire". Cela dépend des goûts, de la position de la main, de la disposition du clavier, de la disponibilité des plugins, etc.

• Je pense que la meilleure façon d'apprendre ce genre de choses, c'est en

  • lecture de la documentation
  • débordement de pile suivant [vim]

---

Le scepticisme laissé de côté, je peux voir un bon marché pour un plugin de comme un indice caractéristiques :

Je penserais à des indications "permanentes", un peu comme celles que l'on voit dans les moteurs d'échecs ringards (montrant les champs atteignables, les champs attaqués, les risques, les brochettes, les fourchettes et une visualisation du résultat d'une combinaison d'échange) :

• Vous pourriez indiquer la position des marqueurs dans la marge (pour que les gens en prennent conscience, surtout dans les cas suivants <, > et autres). Un plugin qui fait cela maintenant est ShowMarks : dans la capture d'écran, notez les marques pour a y b mais aussi (chouette !) les emplacements pour les éléments suivants { y ( et des motions de texte similaires (j'ai vu > , . et d'autres à l'instant) . 1

  

• :set relativenumber est déjà utile en faisant penser aux utilisateurs 13j au lieu de jjjjjjjjjjjjj - mais voir ma préférence ici Déplacement du point entre les caractères par recherche rapide

• Je pourrais imaginer un plugin de coloration syntaxique où les objets textuels environnants (mot, MOT, phrase, paragraphe ou identificateur, bloc de paraboles, bloc d'accolades) seraient mis en évidence dans des nuances croissantes de la couleur de fond. Si nous pensons à un moyen de superposer une indication utile (quelle touche utiliser pour le mouvement de l'objet texte), vous obtiendriez une très bonne indication, IMO.

• Je pourrais voir une astuce pour appuyer sur 'o' afin de déplacer le curseur à l'autre extrémité d'une sélection visuelle.

• le matchit standard est déjà très utile en indiquant les parenthèses correspondantes (bien qu'il n'indique pas dans le style clippy actuel que vous pourriez utiliser % pour y arriver)

• d'autres utilisations inspirantes de la +signs caractéristiques sont : marqueur d'erreur.vim (qui utilise des info-bulles en plus de l'affichage d'un signe graphique) ; je peux voir que cela peut être utilisé à bon escient (ne serait-ce que pour pointer certains sujets de la documentation).

En ce qui concerne le surligneur d'objets textuels, je pense qu'il existe peut-être déjà. Je vais y jeter un œil maintenant

---

_{¹Je pense que pour avoir plus de points, je devais faire ( ?)}

 :let g:showmarks_include+="<>[]"
 :ShowMarksOn

Je recommande également de régler updatime sur quelque chose de rapide (disons 500ms).

Answer 2

Je trouve votre idée très intéressante. Avec le bon ton, une telle fonctionnalité serait probablement utile et pas seulement pour les nouveaux venus.

Mais je vois un tas de difficultés :

• Montreriez-vous "la bonne façon" d'effectuer la tâche précédente ou une façon plus courte sans tenir compte de son exactitude ? Par exemple, un nouvel utilisateur de Vim pourrait faire Vjjjd pour supprimer 4 lignes, proposez-vous V3jd o 4dd ou peut-être dip si cela convient ou toute autre solution ?
• Comment définiriez-vous "la bonne façon" de toute façon ? Par consensus ici sur SO ou sur une liste de diffusion ou en demandant à un groupe d'experts réputés de Vim ?
• Comment définiriez-vous la tâche que vous analysez ? Quelles sont les limites d'une tâche ?

Peu importe, c'est une idée géniale.

Answer 3

Mon expérience personnelle opinion sur ce point est qu'un outil de type clippy est très difficile à manipuler. Comme les gens l'ont mentionné plus haut, je pense que la partie la plus difficile est de comprendre les intentions des utilisateurs lorsqu'ils écrivent du texte. Si vous mettez cela de côté et que vous avez un moyen clair d'ajouter de la sémantique à vos intentions, votre vie pourrait devenir beaucoup plus facile !

Ainsi, au lieu de suggestions en direct, je pense que, dans un premier temps, un flux de travail entrée-sortie-séquence pourrait être plus facile à tester et à obtenir des résultats.

Je pensais programmer un front-end vi généralisé pour l'appliquer à toutes sortes d'éditeurs/boîtes de texte (ex : pidgin).

L'un des résultats de ce processus de réflexion est que le langage d'entrée doit être quelque peu régulier (ou sans contexte au maximum). Ainsi, l'entrée d'une instance vi peut être représentée par une machine à états. Ceci n'est pas entièrement prouvé, mais plutôt une vague supposition ! Il est clair que plus d'efforts doivent être faits pour savoir si les commandes de répétition (par exemple : 13j) ne pourraient pas amener le langage à des grammaires sans contexte.

Si le langage d'entrée vi est régulier, vous aurez peut-être la possibilité d'utiliser le contrôle de modèle limité pour calculer une séquence de transitions d'état dans ce graphe d'état qui aboutit à la sortie requise. Je pense qu'actuellement, les moyens les plus efficaces de faire du model-checking borné sont les contre-exemples et la réduction du problème à une instance sat (il suffit de chercher sur Google).

J'aimerais connaître votre opinion à ce sujet, alors n'hésitez pas à commenter et, s'il y a quelque chose de plus, nous pourrons essayer d'en discuter.

edit

Je pense que vous pouvez essayer de faire le travail d'optimisation standard que font les compilateurs.

mais pas spécialement les macros q[a-z] @[a-z] pourrait être difficile à trouver et à remplacer. Je suppose qu'il s'agit de la NP complète.