4coder » Forums » Parsing MSVC
xelNitram
xel
18 posts

presses plastic buttons for fun

#7044 Parsing MSVC
2 years, 10 months ago

Hello,

I'm writing a function to parse MSVC errors.

If I paste the MSVC output into a text file and open it in 4ed, the following function will jump to the first error. However, the function does not work when the MSVC output is in the actual *compilation* buffer. Thoughts?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
CUSTOM_COMMAND_SIG(next_error){
    View_Summary view = app->get_active_view(app);
    Buffer_Summary buffer = app->get_buffer(app, view.buffer_id);
    
    Range range;
    range.min = 0;
    range.max = buffer.size;

    String string;
    string.str = (char *)app->memory;
    string.size = range.max - range.min;
    app->buffer_read_range(app, &buffer, range.min, range.max, string.str);

    char delim_raw[16] = ") : "; //All the errors have this substring
    String delim = make_string(delim_raw, 4);
    int pos = find_substr(string, 0, delim);
    
    Buffer_Seek seek = {};
    seek.pos = pos;
    app->view_set_cursor(app, &view, seek, 0);
}

None
mrmixer
Simon Anciaux
565 posts
#7048 Parsing MSVC
2 years, 10 months ago

When running your code, view.buffer_id == 0 and buffer.size == 0. My guess is that the compilation buffer is treated differently but only Allen can answer this (I would be interested to know).

You can access the compilation buffer by name, there is an example in 4coder_default_bindings.cpp in the switch_to_compilation function.

1
2
3
char name[] = "*compilation*";
int name_size = sizeof(name)-1;
Buffer_Summary buffer = app->get_buffer_by_name(app, name, name_size);


In case you didn't know, you can attach the visual studio debugger to 4coder and open you source file to debug it. (Debug > attach to process...).

One last thing, you need to put the "bind( context, key_f9, MDFR_NONE, next_error );" in the "begin_map(context, mapid_global); ... end_map( context );" block, not in the "begin_map(context, my_code_map);" because if the buffer is not treated as code (.h, .cpp, .hpp, .c by default) the key will not be bound (this got me several times).
Mr4thDimention
Allen Webster
463 posts / 2 projects

Heyo

#7049 Parsing MSVC
2 years, 10 months ago Edited by Allen Webster on May 24, 2016, 4:14 p.m.

Just another tip, you're not quite using the seek struct correctly... that particular configuration might happen to be correct because maybe 0 is the normal seek. Anyway what I usually do is use the helper seek_pos(pos) which returns a seek struct set up for you. There are also seek_line_char and other helpers for whatever particular file coordinate system you want to use for seek.

Again I am not convinced that this will fix your problem.
xelNitram
xel
18 posts

presses plastic buttons for fun

#7050 Parsing MSVC
2 years, 10 months ago

Thanks mrmixer, accessing the *compilation* buffer that way fixed it.

None
xelNitram
xel
18 posts

presses plastic buttons for fun

#7051 Parsing MSVC
2 years, 10 months ago Edited by xel on May 24, 2016, 6:37 p.m.

Thanks for the tip Allen.

None
Mr4thDimention
Allen Webster
463 posts / 2 projects

Heyo

#7052 Parsing MSVC
2 years, 10 months ago

mrmixer
When running your code, view.buffer_id == 0 and buffer.size == 0. My guess is that the compilation buffer is treated differently but only Allen can answer this (I would be interested to know).


Ahh yes, I haven't gone into much detail explaining this. But there are three fields that can be filled with the buffer's id. The idea is that if you write all your code assuming that view.buffer_id is the id of a normal editable buffer, the system makes that correct by filling the field with 0 for read only buffers. For a similar reason, if you have a GUI up, the buffer is considered "hidden" and so the base field get's filled with 0 in that case as well.

The reason that is all done is that the buffer isn't actually read only, so if you wrote your own command for making edits without planning for these cases you could end up editing files you didn't want to edit. In other words you have to explicitly remember the funky versions of buffer_id and use them when you want to "break the rules" and edit otherwise locked buffers.
mrmixer
Simon Anciaux
565 posts
#7062 Parsing MSVC
2 years, 10 months ago

Is there a particular reason you want the *compilation* (or *messages*) buffer to be read only ? I don't know why I would modify it, I'm just wondering.
Mr4thDimention
Allen Webster
463 posts / 2 projects

Heyo

#7063 Parsing MSVC
2 years, 10 months ago

mrmixer
Is there a particular reason you want the *compilation* (or *messages*) buffer to be read only ? I don't know why I would modify it, I'm just wondering.


Well when I say read only, I mean as in if you use default cmdid_write_character or similar default editing commands in the buffer, they do nothing. It is this way because, especially for compilation, if you accidentally mess up the buffer, you might mess up jump to error type systems.

That said the customizer can still read and edit the buffer if they explicitly ask for it with the fancy buffer id fields.