Vim as ide for mql - page 12
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
By the way, today I discovered the possibility of screwing in semantic highlighting (i.e. it won't be the vim who knows nothing about types, but the LSP server that does the colouring), which is fun in principle. If anyone is interested, do as instructed herehttps://github.com/clangd/coc-clangd. As a result, my coc-settings.json has degenerated into this:
{ "signature.maxWindowHeight": 20, "clangd.semanticHighlighting": true }all server settings removed, coc-clangd (which is a coc extension) configures the coc client itself.
In general, it makes sense to make a language server (https://langserver.org/) for mql. Then it will pick up equally in vim and emacs. And visual studio and eclipse. But this volume is substantial and 90% made by MQ developers, i.e. it is a rework of someone else's work with new bugs and misconceptions.
I think it would be better to take another way, making a converter of C++ code into MQL, so that you could code directly on pluses (with some restrictions), and MQL could be used as an intermediate layer to generate executable .ex5 code. I.e. actually then MQL itself could be forgotten like a bad dream.
In fact, Vict is partially going in this direction, trying to replace some constructs with crutches. But it is better to solve this problem in a system way. Maybe it should be done on the basis of source code of some plus-size compiler. I could take part in such an undertaking.
I think it would be better to make a converter of C++ code into MQL, so you could code directly in pluses (with some restrictions), and MQL would be used only as an intermediate layer to generate executable .ex5 code. I.e. in fact, then you can forget about MQL itself like a bad dream).
In fact, Vict partially goes in this direction, trying to substitute some constructs with crutches. But it's better to solve this problem systematically somehow. Probably it should be done on the basis of source code of some plus compiler. I might take part in such an undertaking.
You are strange. You must be very young. You want to participate in what you are ready to destroy.
You guys are being heroic, God forbid you get involved in something like this for the sake of proprietary software. To wait until some clever manager decidesto make more money to make our lives easier and release NewRevolutionarySoft-1.limited.edition and completely accidentally break backwards compatibility, with talk about how we can't live like this anymore, the world is moving forward, grab bags and run. A set of crutches that aren't much of a burden is the ceiling. Let these managers write the LSP server themselves, they have experience, statistics and all that.
I think it would be better to make a converter of C++ code into MQL, so that you could code directly in pluses (with some restrictions), and MQL could be used only as an intermediate layer to generate executable .ex5 code. I.e . you can forget about MQL itself like a bad dream.
In fact, Vict is partially going in this direction, trying to replace some constructs with crutches. But it is better to solve this problem in a system way. Maybe it should be done on the basis of source code of some plus-size compiler. I could take part in such an undertaking.
Maybe you won't be here then? Why do you need to have a scary waking dream? Maybe other places are not so scary? You should think over the meaning of your activity - maybe it's not yours. Maybe it's yours elsewhere. Where it's not scary. Where flying...
Maybe you shouldn't be here then. Why do you need to have a scary waking dream? Maybe other places are not so scary? You should think over the meaning of your activity - maybe it's not yours. Maybe it's yours elsewhere. Where it's not scary. Where flying...
Activity is always going to different places and in different directions, don't worry. Nor is the meaning of your life limited to sitting on a forum and moderating someone else's posts, I suppose.
A set of crutches that are not too burdensome is the ceiling
Alexey Navoykov:
1. Ну как видим, набор этот у вас постоянно растёт и множится. Поэтому тут вопрос чисто рационализаторский. Либо ты постоянно тратишь время на создание очередных костылей и возню с ними, либо решаешь проблему на корню и больше не паришься.
2. I'm honestly not sure what backwards compatibility was being talked about. Compatibility with what?
1. It seemed to you, the whole point of this"project" is 150 lines of shell script, which I forgot when I was making it. The rest is a single plugin setup, which every user should be able to do himself, decided to help potential newbies.
2. Remember what they did with the old MKL dialect? They could have made a checkbox to select, for example. Anyway, that's about where they were spinning this compatibility. I think it's so much fun to watch your 100500 line project turn into a pumpkin.
2. Remember what they did with the old MCL dialect? They could have made a selection box, for example. Anyway, that's about where they were spinning this compatibility. I think it's so much fun to watch your 100500 line project turn into a pumpkin.
Maybe you are not quite clear what I mean. It's just the opposite. Now while you are coding in MQL, you risk getting into the situation you've described and you will have to rewrite all your projects. I'm talking about writing a converter/translator to code directly in C++. And if you have compatibility problems, you will only need to fix this converter and not the projects themselves.