After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 103753 - RFE: Gedit: CR+LF/CR/LF conversions
RFE: Gedit: CR+LF/CR/LF conversions
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Gedit maintainers
Gedit maintainers
: 128752 312008 347231 554945 (view as bug list)
Depends on:
Blocks: 312002
 
 
Reported: 2003-01-17 15:35 UTC by Roman Polach
Modified: 2010-01-23 19:56 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
the new save dialog with cr+lf / cr / lf mode selection (16.30 KB, image/jpeg)
2005-03-25 06:13 UTC, Ricardo Lenz
  Details
Convert MAC-DOS-UNIX plugin (8.41 KB, application/x-compressed-tar)
2005-06-13 02:57 UTC, Muthiah Annamalai
  Details
plugin (1.82 KB, text/plain)
2008-07-29 04:08 UTC, Jon Dufresne
  Details
convert on save (11.99 KB, application/x-compressed-tar)
2009-01-27 18:55 UTC, Wieland Hagen
  Details
My plugin for EOL convertion (10.18 KB, application/x-bzip)
2009-02-04 18:10 UTC, Mateus César Gröess
  Details
Patch to enable compilation of EOL plugin, against Gedit 2.24.2 (4.56 KB, patch)
2009-02-04 18:41 UTC, Mateus César Gröess
none Details | Review
New version, fix problems (10.04 KB, application/x-bzip)
2009-02-05 21:23 UTC, Mateus César Gröess
  Details
Fixed new plugin. (10.15 KB, application/x-bzip)
2009-02-05 23:44 UTC, Mateus César Gröess
  Details
New version, minor changes (10.20 KB, application/x-bzip)
2009-02-20 02:02 UTC, Mateus César Gröess
  Details

Description Roman Polach 2003-01-17 15:35:32 UTC
This is RFE for useful feature for Gedit:


1) ability to save an file with "CR" or "LF" or "CR-LF" as EOLs,


2) ability to convert all theese EOLs to std. "LF"-s at openning.
Comment 1 Jian He 2003-07-04 14:15:12 UTC
It seems we need a "End of Line" plugin, add a "End of Line" menu to
Tools menu, and add 3 submenu: UNIX, Windows/DOS, Macinosh.
Comment 2 Paolo Borelli 2003-12-23 19:44:42 UTC
*** Bug 128752 has been marked as a duplicate of this bug. ***
Comment 3 Joao Victor 2003-12-28 13:51:34 UTC
I suggest not using the words "End of line". IMO, the user shouldn't need to know that 
Windows/UNIX/Mac have different ways of ending a line. He must only know that 
Windows/UNIX/Mac have different ways of representing the *text*.

Suggestion: 
put something like "Export file to Windows/DOS enviroment", "Export file to 
Macintosh enviroment", etc.
Comment 4 Ricardo Lenz 2005-03-25 06:00:31 UTC
it should be very simple: just one option in the save dialog, in the sameway
there is one for the "character coding".

could be named "text mode" or "text type", and the options could be "windows",
"macintosh" or "unix". pretty simple and sufficient.
Comment 5 Ricardo Lenz 2005-03-25 06:13:52 UTC
Created attachment 39232 [details]
the new save dialog with cr+lf / cr / lf mode selection
Comment 6 Paolo Borelli 2005-03-25 08:21:11 UTC
No, I don't think it belongs to the save dialog.

This feature would be used only few times and by few users, while the save
dialog it is used all the time by all the user: we shouldn't force all the
additional UI complexity on all the users who don't care about end line conversion.


This feature should be implemented as a plugin and IMHO the UI should be a submenu.
Comment 7 Marc O'Morain 2005-06-06 00:40:40 UTC
Should the UNIX format be called UNIX or GNOME?
Comment 8 Muthiah Annamalai 2005-06-12 09:40:50 UTC
Im taking this up, and within a 2 days must be done.
Comment 9 Muthiah Annamalai 2005-06-13 02:51:13 UTC
This patch contains the convert/ plugin code.
It guesses the file type {DOS,MAC,UNIX} and uses
gedit_document_replace_string();

It runs a dialog in the middle, for user to abort conversions,
or convert from     Dos-Unix-Mac-Dos-Unix, 
All the 6 conversion combo's are possible, but based on
your file type.

Thanks 
Muthu.
Comment 10 Muthiah Annamalai 2005-06-13 02:57:36 UTC
Created attachment 47684 [details]
Convert MAC-DOS-UNIX plugin

This patch contains the convert/ plugin code.
It guesses the file type {DOS,MAC,UNIX} and uses
gedit_document_replace_string();

It runs a dialog in the middle, for user to abort conversions,
or convert from     Dos-Unix-Mac-Dos-Unix, 
All the 6 conversion combo's are possible, but based on
your file type.

Thanks 
Muthu.
Comment 11 Rod Butcher 2005-08-14 14:24:55 UTC
This patch still doesn't seem to have been implemented, is that correct ? I've
been using gedit cvs head and find that if I copy and paste text lines from a
file that has lines ending with CRLF (hex 0D0A) into a new file and save it, the
CRLF line endings have been copied too. This seems wrong to me, as copy and
paste is a visual operation and should only copy what is visible, not internal
characters.
I.e. the user sees
$abc=123;
$def=456;
and saves this as xyz.pl, he will assume that he has created a unix format file,
with lines ending in 0A - there is nothing to warn him that what he has in fact
copied and saved ends with 0D0A, and the perl script will crash. He has no way
of seeing that the file he copied it from was a DOS file. Solution - gedit
should tidy up line endings before saving - default to system type e.g. 0A on
Unix, and provide an optional selection for mac or Dos format.
Comment 12 Mateus César Gröess 2006-01-20 23:35:34 UTC
Is there any chance of this feature be included in time for GNOME 2.14? I can't use Gedit because I need access to ASCII documents used by all other Windows workstations in my network, so text format conversion is necessary. Using dos2unix and unix2dos all the time is a usability nightmare, so until the feature is implemented in Gedit, I will still use Anjuta for basic text editing. :-)
Comment 13 Peter Crocker 2006-02-03 16:20:33 UTC
Until this gedit bug is fixed, I have resorted to using KWrite/Kate with Windows "End of Line" default setting.
Comment 14 Paolo Borelli 2006-02-03 16:29:34 UTC
guys, I understand your frustration but saying 'if this is not fixed I use kate/anjuta/vim/whatever' doesn't help...

I personally don't need this feature and I have more pressing issues to fix. Developing a python plugin to do the conversion should be pretty easy if someone wants to give it a try. Or as a temporary solution you can also use the "External Tools" plugin to add a simple menu item that does the conversion on the current document using dos2unix etc.
Comment 15 Paolo Maggi 2006-03-04 18:28:17 UTC
We are moving all the request for plugins that we don't plan to add to gedit
itself on live.gnome.org/Gedit.

Closing as WONTFIX.
Comment 16 Paolo Maggi 2006-03-04 18:46:36 UTC
*** Bug 312008 has been marked as a duplicate of this bug. ***
Comment 17 Jon Dufresne 2008-07-29 04:08:15 UTC
Created attachment 115471 [details]
plugin

As a gedit user who is frustarted with receiving DOS text files in my UNIX environment I have created a plugin that when saving a document, the plugin will replace all DOS EOLs with UNIX EOLs. Feel free to use, comment, include, link to or do whatever you want (under the GPL) with the plugin.

The plugin is based on the delete trailing white space plugin.

http://comradesoffunk.org/jon/unix-eol/
Comment 18 Wieland Hagen 2009-01-27 18:55:07 UTC
Created attachment 127347 [details]
convert on save

Hi, 

I wrote a plugin that changes all End-of-Line marks to the specified format when the document is saved. 
It adds a submenu in the Edit-menu so that the user can choose between Unix/Mac/Windows formatting, or to make no changes at all..
Comment 19 Mateus César Gröess 2009-02-04 18:10:32 UTC
Created attachment 127934 [details]
My plugin for EOL convertion

I will understand if Wieland Hagen claim my plugin is a plagiarism. :-)

In fact, I started a plugin to to EOL convertion in the end of last week, without see the notification of his plugin. I had problems because of my little knowledge of Gtk text manipulation, so changed to an approach similar to what Mousepad (Xfce) does. It wasn't working right because to do the convertion I as replacing all the text of buffer (gtk_text_buffer_set_text).

So, I found Wieland Hagen's plugin and, looking at its source code, saw what I was doing wrong initially. I switched again my text convertion routines and now the plugin is working as right as possible. Well, because of some Gedit internals, Mac files will have a trailing '\n' at end (Gedit developers, please take a look at FIXMEs inside gedit-endofline-plugin.c file). Probably some minor changes are required to port to other OSs like MS Windows.

This version has some improvements, like separated EOL setting for each file with UI updated when switching tabs, auto-detection when a file is loaded (necessary in situations like bug 445895) and no more "None" convertion option (but tries to be "smart" to detect if a convertion is need).
Comment 20 Ignacio Casal Quinteiro (nacho) 2009-02-04 18:21:14 UTC
Pbor, now that we have the windows version and possibly in a near future the macosx version, what about having this in the core instead of a plugin?
Comment 21 Mateus César Gröess 2009-02-04 18:41:39 UTC
Created attachment 127936 [details] [review]
Patch to enable compilation of EOL plugin, against Gedit 2.24.2

The instructions to compile the plugin should be the same contained in INSTALL file of Wieland Hagen's tarball, I think. What I have done before was change all Gedit files where I could find references to other plugins names. :-)

For reference: I'm using Gedit 2.24.2 and the patch attached to this comment. I extract the files from my tarball into Gedit plugin directory, go to toplevel Gedit directory and apply the patch using "patch -p1 < gedit-2.24.2-endofline_plugin.diff". After, the "./configure" script must be run, then you can type "make" to compile  Gedit and its plugins or, if Gedit is already instaled with the same configure options, just compile the plugin typing "make" at endofline plugin directory, then install it with "make install".
Comment 22 Mateus César Gröess 2009-02-04 19:16:42 UTC
nacho, to add one point of view and help pbor think about:

Gedit rationale has been to not polute the code and/or the UI with functions "used only few times and by few users" (see comment 6). Ok, in theory I understand the rationale, but in practice, this is a world infected by a majority of Windows users. I need many times read files created by them, and write ones for them, directly in the same repository they work. This is why Gedit is useless for me without this function. Look at the description of bug 445895 and see the mess a Gedit user could do. :-)

If shouldn't Gedit contain functions used by few users, so I think all the code that handle character enconding should be moved to a separated plugin, because it is a function I rarely use, and many persons have no idea of its impact in the text they are writing.

Like said at comment 14, use the "External Tools" plugin to add a simple menu item that does the character enconding conversion on the current document using some external command. :-)
Comment 23 Ignacio Casal Quinteiro (nacho) 2009-02-04 19:25:38 UTC
In my point of view all you say is correct before we had gedit ported to other platforms, now I think would be better having the endofline detection in the core, as we are going to use it in a more close way.
Anyway I am just wondering if it would be better now, as maybe a plugin is the better solution. 
Comment 24 Mateus César Gröess 2009-02-04 20:08:13 UTC
Ok, thanks. The problem I see having EOL handling as a plugin is the possibility of users disable it, so a non-Unix file loaded will be edited and saved in a wrong way, what currently happens. Again, look at the description of bug 445895. I am talking about novice users. With the plugin enabled, the EOL format of the file will be detected automatically and used at saving. It's not even a problem of allowing the user to change or view the current EOL format (bug 347231). Maybe the ideal solution is having EOL handling functions in the core (autodetection and saving for the 3 formats), and having a plugin only for UI 	
functionality, to allow change of the format used. The plugin will change some property of the document, and the core will handle the convertion at saving.
Comment 25 Mateus César Gröess 2009-02-05 21:23:35 UTC
Created attachment 128044 [details]
New version, fix problems

Plugin updated:

- GEDIT_EOL_* renamed to EOL_*;
- new conversion method, solved two problems with conversion to Mac format, but the '\n' at end still is included because of Gedit internals (file gedit-document-saver.c: gedit_document_saver_write_document_contents and gedit_document_saver_get_end_newline).
Comment 26 Mateus César Gröess 2009-02-05 23:44:10 UTC
Created attachment 128062 [details]
Fixed new plugin.

I made a mistake in new conversion routine and it was not considering empty files. I changed the routine again and hope it is fine now.
Comment 27 Paolo Borelli 2009-02-07 00:01:32 UTC
I am reopening this bug so that the useful code stays on our radar. I have not reviewed it and for 2.26 it's a bit too late... I'll hope to have a look soon.
Comment 28 Mateus César Gröess 2009-02-07 00:51:33 UTC
Comment 3 has a valid point not followed by my plugin.

For the "Old Mac" string, it must be changed to "Old Macintosh" or just "Macintosh", because I don't know if the format is really "old" now, I just copied what is used by Wieland Hagen's plugin. :-)

For the "Change End Of Line", could be changed to "Text Mode" or "Text Type", like comment 4 suggested, or something else like "Target Platform", preceded or not by "Change". We just need to agree about one good description, for novice and advanced users, that makes sense.
Comment 29 Mateus César Gröess 2009-02-07 15:04:30 UTC
I made a research. Mac computers aren't common to find here even these days.

"Old Mac" -> "Old Mac OS". The reference must be the operational system. There were clones of the old Macintosh hardware with different names. "System Software" is an old OS for Mac anyway and seems not marketed at its time. I think "Mac OS Classic" could cause confusion because "classic" is a subjective word.

"Unix" -> "Unix-based/Mac OS X". Mac OS X is well known and a non-technical user will don't know it is Unix-based, so a reference is need here. "Unix-like" is a common english term, but I think could cause a strange translation. In my language, it would be something like "Seems like Unix" or "Works like Unix", instead of "Based on Unix".
Comment 30 Mateus César Gröess 2009-02-20 02:02:06 UTC
Created attachment 129114 [details]
New version, minor changes

- for detection, return EOL_DEFAULT instead of EOL_UNIX when no EOL character is found;
- minor changes to some strings and comments.
Comment 31 Mateus César Gröess 2009-02-21 00:43:52 UTC
I found one more issue caused by Gedit handling of the last '\n'. Because Gedit removes it when the file is loaded to the buffer, a DOS file containing only one line will incorrectly be detected as a Mac OS file.
Comment 32 Mateus César Gröess 2009-03-21 19:27:20 UTC
For correct functionality of the EndOfLine Plugin, one solution would be add new functions to the Gedit API, to make possible to disable the internal handling of the last EOL, so the plugin would handle it by itself. A draft of the implementation:


gedit-document-saver.c:
-------------------------------------------------------------------
gedit_document_saver_write_document_contents ()
{
        -if (res)
        +if (res && gedit_core_get_last_eol_handling_enabled ())
        {
                ...
                gedit_document_saver_get_end_newline ();
                ...
        }
}
-------------------------------------------------------------------

gedit-document-loader.c:
-------------------------------------------------------------------
insert_text_in_document()
{
        +if (gedit_core_get_last_eol_handling_enabled ())
        ->      if ((len > 0) && (text[len-1] == '\n'))
        ->              len--;
}
-------------------------------------------------------------------

gedit-endofline-plugin.c:
-------------------------------------------------------------------
gedit_endofline_plugin_activate ()
{
        gedit_core_set_last_eol_handling_enabled (FALSE);
}

gedit_endofline_plugin_deactivate ()
{
        gedit_core_set_last_eol_handling_enabled (TRUE);
}

eol_format_convert()
{
        ...
        -if (eol_format != EOL_UNIX)
        -       gtk_text_buffer_insert (buffer, &iter, "\r", 1);
        +switch (eol_format)
        +{
        +case EOL_UNIX:
        +       gtk_text_buffer_insert (buffer, &iter, "\n", 1);
        +       break;
        +case EOL_OLD_MAC:
        +       gtk_text_buffer_insert (buffer, &iter, "\r", 1);
        +       break;
        +case EOL_DOS:
        +       gtk_text_buffer_insert (buffer, &iter, "\r\n", 2);
        +       break;
        +}
}

eol_last_cr_workaround ()
{
        ...
        -if (gtk_text_iter_get_char (&iter) == '\r')
        -{
        -       gtk_text_buffer_delete (buffer, &iter, &iter2);
        -       gtk_text_buffer_set_modified (buffer, FALSE);
        -}
        +if (gtk_text_iter_get_char (&iter) == '\n')
        +{
        +       gtk_text_buffer_delete (buffer, &iter, &iter2);
        +       gtk_text_iter_backward_char (&iter);
        +}
        +if (gtk_text_iter_get_char (&iter) == '\r')
        +{
        +       gtk_text_buffer_delete (buffer, &iter, &iter2);
        +}
        +if (gtk_text_buffer_get_modified (buffer))
        +       gtk_text_buffer_set_modified (buffer, FALSE);
}
-------------------------------------------------------------------


But I still think that the ideal solution is pointed out at comment 24.

Comment 33 Alexander Kojevnikov 2009-04-28 08:57:51 UTC
*** Bug 347231 has been marked as a duplicate of this bug. ***
Comment 34 Alexander Kojevnikov 2009-04-28 08:58:37 UTC
*** Bug 554945 has been marked as a duplicate of this bug. ***
Comment 35 Mateus César Gröess 2009-06-14 03:24:56 UTC
Re: Comment 27

> I am reopening this bug so that the useful code stays
> on our radar. I have not reviewed it and for 2.26
> it's a bit too late... I'll hope to have a look soon.

Any change of this feature be included for 2.28?
Comment 36 Mateus César Gröess 2009-06-16 03:13:22 UTC
I meant "chance", any chance of this feature be included for 2.28?
Comment 37 Ignacio Casal Quinteiro (nacho) 2009-06-16 07:58:23 UTC
I don't think addding this feature as a plugin is the right way to go, I think this should go in the core. But we are still discussing how to do it.
Comment 38 Mateus César Gröess 2009-11-25 00:04:21 UTC
Hi again! Are you still discussing how to integrate the code? Permit me to suggest again a read in comment 24. Frequently I see Gnome developers complaining about functions that bloat the UI, so to satisfy them, place the UI stuff in a plugin and the rest will live in the core. The core code also will not become bloated, because the EOL code is short.
Comment 39 Ignacio Casal Quinteiro (nacho) 2009-11-25 00:09:32 UTC
The thing is that we really want this in the core, but we are waiting or searching for something in gio to make this in a really good way.
Comment 40 Mateus César Gröess 2009-12-04 00:10:02 UTC
That GConverter stuff included in GLib 2.23.0 could be what you were waiting for? Before I understood about the core being Gedit core, not lower level libraries.
Comment 41 Ignacio Casal Quinteiro (nacho) 2009-12-04 04:56:36 UTC
Indeed that's what we were waiting for, in fact I already made a converter for that, now it needs reviewing and see if it goes in gio or gedit directly.
Comment 42 Mateus César Gröess 2010-01-13 23:03:18 UTC
In case the plan is to include the new functions in gio, just a reminder that API/ABI Freeze enters next Monday.
Comment 43 jessevdk@gmail.com 2010-01-23 19:56:38 UTC
We decided to implement this in gedit as part of a special input stream that reads a GeditDocument and automatically converts the line endings according to a setting. The line ending is also 'automatically' detected at file load, and can be chosen from the save dialog. I'm closing this bug.