Vim comme idéal pour mql - page 9
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
pouvez-vous imaginer combien il est plus rapide d'écrire du code lorsque vos doigts ne s'arrachent pas aux flèches/souris pour copier/supprimer/coller/déplacer le curseur ? Bien sûr, ce n'est qu'un exemple parmi tant d'autres.
Veuillez enregistrer quelques vidéos avec une démonstration claire des possibilités. Merci.
Veuillez enregistrer quelques vidéos pour donner une démonstration claire des fonctionnalités. Merci.
Oui, il y en a déjà, par exemple
Les bases sont là, je pense.
Pas vraiment. Les premiers sont des programmeurs, ils sont peu nombreux. Ces derniers sont communément appelés codeurs, et ils sont légion.
Où, par qui, quand est-elle acceptée ?
Je voulais demander ce qu'est un vim...
Il y a des gens qui travaillent dans un style "hardcore only". Ils sont peu nombreux, ils n'imposent pas les leurs aux autres, ils partagent simplement. J'ai moi-même utilisé linux au travail (il y a longtemps) pendant des années. Mais il y avait beaucoup de problèmes avec MT sous le vin, et j'ai abandonné. Beaucoup de problèmes sont résolus maintenant, mais je ne veux pas y retourner.
Laissez les gens travailler et décrire, cela en aidera quelques autres. Bien sûr, tout dépend de l'amateur.
Le seul problème qui vous fait parfois penser "je vais tout laisser tomber et passer à linux", ce sont les éternels problèmes de Windows. Mises à jour tordues et imprévisibilité de la SEP.
Il en existe déjà, par exemple.
Les bases sont là, je pense.
Je pense que la plupart de ce qui est montré rappelle l'ablation des amygdales par le cul). Oui, peut-être que pour les rédacteurs, c'est utile, mais pour un programmeur, la vitesse de frappe n'est pas le facteur le plus important. Il serait plus intéressant de voir à quoi ressemble le processus de travail avec le code MQL, la compilation, la navigation des erreurs, etc.
Imho, la plupart des spectacles rappellent l'ablation des amygdales par le cul). Cela peut être utile pour les rédacteurs, mais pour les programmeurs, la vitesse de frappe n'est pas le facteur le plus important. Il serait plus intéressant de voir à quoi ressemble le processus de travail avec le code MQL lui-même, la compilation, la navigation à travers les erreurs, etc.
La plupart du temps du programmeur est consacré à des tâches stupides comme la saisie du code, les petites (correction des erreurs de frappe) et les grandes corrections du code (remaniement). La compilation et la navigation d'erreur sont de telles bagatelles.
Cela exclut bien sûr le processus de "réflexion avant d'agir" :-)
Lorsque vous connaissez la langue et l'environnement, vous écrivez d'emblée presque sans erreurs de syntaxe. Le code-complet aide, mais il est parfois gênant. Pourquoi diable MTEditor a-t-il décidé que int devait être étendu à interface ? Vous pouvez toujours bricoler des béquilles dans VIM ou EMacs, mais dans l'éditeur natif, c'est insurmontable - il suffit d'écrire au loto sportif.
Le débogage est une autre histoire - le débogueur est peu ou pas intégré dans l'éditeur, mais il est là ou il n'est pas. C'est la raison pour laquelle les impressions et les journaux sont tout ce qui nous intéresse :-)
code-complete aide, mais est parfois gênant
Eh bien, cela aide dans 99% des cas, donc toutes les fonctions et types MQL devraient être déclarés dans le fichier d'en-tête. Dans le fichier vim.mqh, comme je le vois, seule une petite partie des fonctions ont été déclarées jusqu'à présent.
Lorsque vous connaissez la langue et l'environnement, vous écrivez presque sans erreurs de syntaxe.
Au fait, Wima dispose-t-il d'un système de vérification automatique de la syntaxe à l'entrée ? Parce qu'il est très rare d'écrire aveuglément un fragment de code sans erreur).
Je pense que la plupart des images montrent qu'il faut couper les amygdales par les fesses.) Oui, c'est peut-être utile pour les rédacteurs, mais pour un programmeur, la vitesse de frappe n'est certainement pas le facteur le plus important. Il serait plus intéressant de voir comment le processus de travail avec le code MQL, la compilation, la navigation des erreurs, etc. se présente directement.
Eh bien personnellement, je suis juste ennuyé par les "éditeurs normaux", mes doigts pressent déjà automatiquement les combinaisons de vim. Je ne suis pas à l'aise avec le méta-éditeur.
Au fait, y a-t-il un contrôle automatique de la syntaxe dans vim ? car il est très rare d'écrire un fragment de code sans erreur à l'aveugle).
Bien sûr, et c'est bien mieux que le standard dans le méta-éditeur. Le clangd(lsp serveur) est responsable de cela, dans vim coc(lsp client), il n'est pas dérangé par des macros ou des modèles d'une quelconque complexité. Et en jetant les esperluettes lors du passage des tableaux et en déréférençant correctement le code, il a un effet positif sur la capacité de clang à inviter. Eh bien, les transitions vers les définitions, ..., sont là aussi.
Je n'ai pas de plugins on peut dire (seulement police et coc), mais vous pouvez mettre ce que vous voulez - par exemple un "navigateur" pour les fichiers sur la gauche.
Mais pour vim, vous avez besoin d'une formation. J'ai créé un lien sur la première page pour vous aider avec les commandes, il faut du temps pour s'y habituer.