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.

*** Bug 128752 has been marked as a duplicate of this bug. ***

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.

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.

Created attachment 39232 [details]
the new save dialog with cr+lf / cr / lf mode selection

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.

Should the UNIX format be called UNIX or GNOME?

Im taking this up, and within a 2 days must be done.

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.

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.

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.

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. :-)

Until this gedit bug is fixed, I have resorted to using KWrite/Kate with Windows "End of Line" default setting.

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.

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.

*** Bug 312008 has been marked as a duplicate of this bug. ***

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/

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..

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).

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?

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".

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. :-)

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. 

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.

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).

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.

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 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.

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".

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.

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.

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.

*** Bug 347231 has been marked as a duplicate of this bug. ***

*** Bug 554945 has been marked as a duplicate of this bug. ***

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?

I meant "chance", any chance of this feature be included for 2.28?

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.

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.

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.

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.

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.

In case the plan is to include the new functions in gio, just a reminder that API/ABI Freeze enters next Monday.

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.