VIM, Windows, quickfix - struggle with compiler coding
There is an instrumental computer with Windows and an assembler for one remarkable, but specific processor. For convenience, the VIM-based working environment was set up - syntax highlighting, preprocessor call, assembler and linker via make with parsing error messages, ctags with code jumping. But there is a nuance - issuing messages: make goes in Russian. Of course, in console Russian, cp866. And the source code in assembler and VIM locale is cp1251. And how to be?
To bring all encoding - text files and VIM locale - to cp866 because of one compiler? Not even funny. Guess from the context of the meaning of the error? So far, and did. I'm tired. We must understand, spend a couple of evenings and forget about this annoying misunderstanding.
The quickfix system works: make output gets into the error file, numbers of incorrect lines of code and type of error are extracted from it, the cursor after compilation is immediately put in the right place. That's just to understand the essence of the error is not easy:
')
And the command: cope does not help in reading, although, due to erroneous lines of code, jumping allows you to:
Note: The example uses the option makeef = error.err (to shorten the displayed make command line), although I usually have it empty by default, and the make error file is created in TEMP.
It would seem - what nonsense! If we fix the encoding option ... But no - it is, contagion, global. Therefore, the encoding will be changed everywhere, in all open buffers, including the source window. Comments in Russian Khan. Reports of the VIM itself - as well.
You can try: set encoding = cp866 manually, you can plug it into $ VIM / vimfile / ftplugin / qf.vim, so that it works with the command: cope. You can even try: setlocal does not help.
Once it is impossible to change the encoding in one single buffer, try to recode the error file itself. To do this, look in the help, and find that when you call: make the following sequence is executed:
It turns out that when opening the qf buffer with the command: the cope error file no longer exists. You can try to return it in a non-elegant way - in $ VIM / vimfile / ftplugin / qf.vim write
That is, when opening the qf buffer with the command: cope, change the encoding, insert the encoding for the file, write the new error file and return the encoding back. By the way, you can omit the local place — it is still useless. Now you can manually install a new error file: cf ./error.err.
Ugly, uncomfortable and a bunch of unnecessary movements with his hands. So, after each compilation, you must first: cope, then: ccl, then: cf ./error.err and again: cope. If you try to insert it all into qf.vim, then a furious recursion will occur, which VIM will strangle on its own. And: cope behaves in a strange way: extra sticks are added at the beginning of the lines, even the reluctance to understand the reasons.
Okay, then we will try to catch the moment not near reading the error file, but closer to the compiler output. Let's look at the help again:
The exclamation mark ":! {Command}" requires to execute the specified {command} in the shell. So, catch the event that occurs with the file when you run: make, will not work. Hope to use the auto-command collapsed. But give up early. Let's take a closer look at
It turned out that my default VIM has shellpipe =>% s 2> $ 1. It seems that there is an opportunity to take an external command line utility and somehow shove it into the middle of this very shellpipe.
Take iconv , which is in the GnuWin32 project on the libiconv page. It can receive data from a file or from a console stream. I put it in C: \ bin \, where make, ctags, 7z, a couple of auxiliary command files and a couple of dll are already located. Do not forget about the dependencies (Dependencies, namely libintl3.dll, lies on the utility page).
Played with the command line separately from VIM in order to figure out how to provide input data and options. Then I tried the same, but already on the VIM command line. Somewhere from the second or third attempt something like this came out:
Vertical bars, spaces and backslashes in the full path to the utility are escaped with backslashes. As for the full path, you can, of course, not pervert so much, but to prescribe the path to iconv in the PATH, but for some time now I personally don’t like this method: the four IDE / CADs on the work computer have make not fully compatible with each other and all spelled out in the PATH. Full paths are safer.
In general, it worked. I wrote this line (without a colon at the beginning) in the $ VIM / vimfile / ftplugin / a6403.vim file. Now the "shell pipe" is changed to recoded only when opening this particular type of file. Here is the result:
Russian comments in the source are readable, error messages are also, jumped by mistake. The solution is not ideal:
To eliminate the second drawback, you can locally (setlocal) override the makeprg option, add a special “stub” after make as the “$ *” sequence, which will be replaced with command line arguments, and call iconv. Then the shellpipe can not touch. And the vertical line will have to be escaped with as many as three backslashes: one for the command: set, the second - to screen the third one, which is necessary when parsing the command.
I did not find a better method in various kinds of Internet. Actually, I did not find any way. Maybe it was me who was so unlucky? But if anyone can help at least the very idea of ​​introducing a team into the chain, I will be pleased.
To bring all encoding - text files and VIM locale - to cp866 because of one compiler? Not even funny. Guess from the context of the meaning of the error? So far, and did. I'm tired. We must understand, spend a couple of evenings and forget about this annoying misunderstanding.
The quickfix system works: make output gets into the error file, numbers of incorrect lines of code and type of error are extracted from it, the cursor after compilation is immediately put in the right place. That's just to understand the essence of the error is not easy:
')
And the command: cope does not help in reading, although, due to erroneous lines of code, jumping allows you to:
Note: The example uses the option makeef = error.err (to shorten the displayed make command line), although I usually have it empty by default, and the make error file is created in TEMP.
It would seem - what nonsense! If we fix the encoding option ... But no - it is, contagion, global. Therefore, the encoding will be changed everywhere, in all open buffers, including the source window. Comments in Russian Khan. Reports of the VIM itself - as well.
You can try: set encoding = cp866 manually, you can plug it into $ VIM / vimfile / ftplugin / qf.vim, so that it works with the command: cope. You can even try: setlocal does not help.
Once it is impossible to change the encoding in one single buffer, try to recode the error file itself. To do this, look in the help, and find that when you call: make the following sequence is executed:
- When the 'autowrite' option is enabled, all modified buffers are written.
- The name of the error file is calculated according to the value of the 'makeef' option. If the value of the 'makeef' option does not contain "##", then an existing file with the same name will be deleted.
- A program is started with the name specified in the 'makeprg' option (default: “make”) with an optional set of [arguments], the output of which is redirected to an error file (on Unix, the output is also displayed on the screen).
- Reads the error file using the value of the 'errorformat' option.
- If the [!] Modifier is not set, then it moves to the first error from the list.
- The error file is deleted.
- Now you can navigate through the list of errors with commands like: cnext and: cprevious.
It turns out that when opening the qf buffer with the command: the cope error file no longer exists. You can try to return it in a non-elegant way - in $ VIM / vimfile / ftplugin / qf.vim write
setlocal encoding=cp866 setlocal fileencoding=cp1251 w! ./error.err setlocal encoding=cp1251 That is, when opening the qf buffer with the command: cope, change the encoding, insert the encoding for the file, write the new error file and return the encoding back. By the way, you can omit the local place — it is still useless. Now you can manually install a new error file: cf ./error.err.
Ugly, uncomfortable and a bunch of unnecessary movements with his hands. So, after each compilation, you must first: cope, then: ccl, then: cf ./error.err and again: cope. If you try to insert it all into qf.vim, then a furious recursion will occur, which VIM will strangle on its own. And: cope behaves in a strange way: extra sticks are added at the beginning of the lines, even the reluctance to understand the reasons.
Okay, then we will try to catch the moment not near reading the error file, but closer to the compiler output. Let's look at the help again:
The ": make" command executes the program specified in the 'makeprg' option. This is done by invoking a command from the shell specified in the value of the 'shell' option. In other words, almost the same thing happens as when entering the command
":!{_makeprg} [] {_shellpipe} {_}".
Here {makeprg_value} is the string value of the 'makeprg' option. You can use any necessary program, not just “make”.
The exclamation mark ":! {Command}" requires to execute the specified {command} in the shell. So, catch the event that occurs with the file when you run: make, will not work. Hope to use the auto-command collapsed. But give up early. Let's take a closer look at
'shellpipe' 'sp' string (default: ">", "| tee", "| & tee" or "2> & 1 | tee") global option The option is used to specify the string that forces the shell. put the output of the ": make" command in the error file.
It turned out that my default VIM has shellpipe =>% s 2> $ 1. It seems that there is an opportunity to take an external command line utility and somehow shove it into the middle of this very shellpipe.
Take iconv , which is in the GnuWin32 project on the libiconv page. It can receive data from a file or from a console stream. I put it in C: \ bin \, where make, ctags, 7z, a couple of auxiliary command files and a couple of dll are already located. Do not forget about the dependencies (Dependencies, namely libintl3.dll, lies on the utility page).
Played with the command line separately from VIM in order to figure out how to provide input data and options. Then I tried the same, but already on the VIM command line. Somewhere from the second or third attempt something like this came out:
:set shellpipe=\|c:\\bin\\iconv\\iconv.exe\ -c\ -f\ CP866\ -t\ CP1251>%s\ 2>&1
Vertical bars, spaces and backslashes in the full path to the utility are escaped with backslashes. As for the full path, you can, of course, not pervert so much, but to prescribe the path to iconv in the PATH, but for some time now I personally don’t like this method: the four IDE / CADs on the work computer have make not fully compatible with each other and all spelled out in the PATH. Full paths are safer.
In general, it worked. I wrote this line (without a colon at the beginning) in the $ VIM / vimfile / ftplugin / a6403.vim file. Now the "shell pipe" is changed to recoded only when opening this particular type of file. Here is the result:
Russian comments in the source are readable, error messages are also, jumped by mistake. The solution is not ideal:
- I had to use a third-party utility with the built-in transcoding tools. Excuse: Not particularly scary in this case - it’s still to use a third-party compiler, and third-party ctags, and third-party make. Well, there were more files in my c: \ bin \ ...
- The global shellpipe option will be applied to all buffers. Excuse: if you do not open the files of this specific assembler - no one will feel. If you open and simultaneously work in other simultaneously opened buffers with another translator - English-speaking compilers will be purple (checked), Russian-speaking (on cp866) - only for benefit.
To eliminate the second drawback, you can locally (setlocal) override the makeprg option, add a special “stub” after make as the “$ *” sequence, which will be replaced with command line arguments, and call iconv. Then the shellpipe can not touch. And the vertical line will have to be escaped with as many as three backslashes: one for the command: set, the second - to screen the third one, which is necessary when parsing the command.
setlocal makeprg=c:\bin\make.exe\ $*\ \\\|c:\\bin\\iconv\\iconv.exe\ -c\ -f\ CP866\ -t\ CP1251
I did not find a better method in various kinds of Internet. Actually, I did not find any way. Maybe it was me who was so unlucky? But if anyone can help at least the very idea of ​​introducing a team into the chain, I will be pleased.
Source: https://habr.com/ru/post/196470/
All Articles