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?
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);
}
|
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.
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).
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).
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.
Again I am not convinced that this will fix your problem.
Edited by Allen Webster
on
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.
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.
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.