gtk_text_buffer_insert() of a '\n' following an existing '\r' results in `\r\r\n'
@drankinatty
Submitted by David C. Rankin Link to original bug (#785715)
Description
All,
I think I've found a bug in Gtk+2 gtk_text_buffer_insert() of a "\n" following an existing '\r' in a GTK_TEXT_BUFFER (to convert end-of-line from CR
(Max pre-OSX) to CRLF
. (I have not yet confirmed on Gtk+3)
When I locate an existing '\r' end-of-line with gtk_text_iter_forward_to_line_end() and gtk_text_iter_forward_char() and check that the next char is NOT '\n', I simply want to insert a '\n' to manually complete the conversion. However, gtk_text_buffer_insert() inserts "\r\n" (0x0d 0x0a) instead of "\n" making the line-end "\r\r\n"?
By simply making the change of gtk_text_buffer_backspace() to remove the existing '\r' and then gtk_text_buffer_insert() of a "\r\n" the end-of-line is correctly converted from '\r' to "\r\n". Why should I have to backspace over '\r' and then insert "\r\n" instead of just inserting "\n". Thus the bug in how gtk_text_buffer_insert() handles inserting a single "\n" following an existing '\r'.
This is a summary of the question (details follow afterwards)
Why does the following fail?
if (gtk_text_iter_get_char (&iter) != '\n') {
gtk_text_buffer_insert (buffer, &iter, "\n", -1);
}
When the following works?
if (gtk_text_iter_get_char (&iter) != '\n') {
if (gtk_text_buffer_backspace (buffer, &iter, FALSE, TRUE)) {
gtk_text_buffer_get_iter_at_mark (buffer, &iter, app->last_pos);
gtk_text_buffer_insert (buffer, &iter, "\r\n", -1);
}
This is either a bug, or Gtk+2 considers CRLF a single char and will NOT allow manual creation of '\r\n' by inseting a '\n' following an existing '\r' in a buffer. (which Is probably where the bug (or issue) is, but I don't know where to begin to look in the Gtk+2 source... I can remove the exising '\r' and insert '\r\n' and everything is fine, but I cannot place a single '\n' after an existing '\r' in the buffer to manually create a CRLF and have it work.
A test file for the conversion from 'CR' to 'CRLF' loaded into buffer is, e.g.
$ hexdump -C eol_cr.txt 00000000 6d 79 0d 64 6f 67 0d 20 20 68 61 73 0d 20 20 66 |my.dog. has. f| 00000010 6c 65 61 73 0d 61 20 6c 6f 74 0d 20 20 20 20 6f |leas.a lot. o| 00000020 66 20 66 6c 65 61 73 0d |f fleas.| 00000028
In human readable form:
$ cat eol_cr.txt my dog has fleas a lot of fleas
Bug or feature? Does it exist in Gtk+3?
Version: 2.24.x