bugGNU Octave - Bugs: bug #57861, GUI editor should save text files...

 
 

bug #57861: GUI editor should save text files with an implied final newline character

Submitter:  Mike Miller <mtmiller>
Submitted:  Wed 19 Feb 2020 08:54:35 PM UTC
   
 
Category:  GUI Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  ttl
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 28 Feb 2020 09:00:34 PM UTC, comment #20: 

No problem, closing the report.

Torsten Lilge <ttl>
Group Member
Fri 28 Feb 2020 08:21:30 AM UTC, comment #19: 

I tested both of the latest changes and it all looks perfect to me now. Thanks for working on this despite your preference for editors that show an extra blank line after a newline.

Mike Miller <mtmiller>
Group Member
Thu 27 Feb 2020 10:31:13 PM UTC, comment #18: 

When "saving as" there was an uninitalized variable formerly used with the old, non native file dialogs where it was possible to select the eol mode while saving. Depending of the random value of this variable, an empty eol string was assumed and all spaces were replaced. This should be fixed with cset http://hg.savannah.gnu.org/hgweb/octave/rev/33d89d314d43

Not adding a newline to an empty file will follow.

Torsten Lilge <ttl>
Group Member
Thu 27 Feb 2020 08:06:02 AM UTC, comment #17: 

I just built the latest default (e82d00e8be37), started the GUI, and verified these settings:


>> __event_manager_gui_preference__ ("editor/force_newline")
ans = true
>> __event_manager_gui_preference__ ("editor/rm_trailing_spaces")
ans = false


I opened the editor, got a new blank tab, and typed "x = 1    " (four trailing spaces), and clicked Save. I called the file ~/ascript.m. When I look at the file with cat -A or od, I can see that it ends with a space, not a newline.

Actually, if I only type "x", the same thing occurs, I get a 1 byte file containing "x", no newline.

Weird, now I'm not even getting a newline added to new files with both settings enabled again.

I'm also now seeing spaces in the middle of lines being removed, not just trailing spaces. For example


line 1
line 2
line 3
line 4


becomes


line1
line2
line3
line4


after saving.

Mike Miller <mtmiller>
Group Member
Thu 27 Feb 2020 06:38:44 AM UTC, comment #16: 

Mike, I am not able to reproduce issue 2 or I do not understand the exact way to do this. Removing trailing spaces is disabled, forcing newline is enabled. Now, when saving a file a newline is added, regardless the content of the last line (spaces, non-spaces or just a newline).

Torsten Lilge <ttl>
Group Member
Wed 26 Feb 2020 09:51:12 PM UTC, comment #15: 

Mike, thanks for testing. Regarding issue 1, I have just forgotten this exception. I thought issue 2 is fixed but I will a look at this.

Torsten Lilge <ttl>
Group Member
Wed 26 Feb 2020 08:35:44 PM UTC, comment #14: 

Thanks, I didn't see an email notification for this update. I've tested now, looks much better to how I would expect this to work.

There are still a couple oddities left that I'm seeing.

1. If I enable both new settings, open an existing file, delete the entire buffer, and Save, the file is saved with a trailing newline. The one exception I mentioned before is when the buffer is completely empty, a newline should not be appended, the file should be zero bytes.

2. If I disable the "Remove trailing spaces" option, the newline behavior seems to go back to the original. I don't see why these two options should interact with each other at all, but they do from what I can tell. If the last line in the file is only space characters, a newline is appended, that part works. But if the last line doesn't end in spaces, no newline is appended now with this option enabled.

Mike Miller <mtmiller>
Group Member
Sun 23 Feb 2020 02:49:25 PM UTC, comment #13: 

I have changed the behavior regarding the newlines with changeset http://hg.savannah.gnu.org/hgweb/octave/rev/480490faf659

Torsten Lilge <ttl>
Group Member
Sat 22 Feb 2020 11:28:54 PM UTC, comment #12: 

I think it's just two different valid perspectives on how a plain text file should be represented. I think an editor that shows the last newline in a file is doing it wrong.

I am hoping for a switch between the two behaviors, so people who like standard Unix file and editor semantics can have that, and people who want to see the newline as an extra line at the end can have that.

The final newline in a file isn't "hidden" in my perspective, it's just that a line always ends with a newline, if there's nothing after it then don't show a blank line.

Mike Miller <mtmiller>
Group Member
Sat 22 Feb 2020 10:47:04 PM UTC, comment #11: 

I see the point that extra whitespace should not be deleted at the end of a file.

I am still reluctant to "hide" an existing newline at the end of a file instead of displaying the file to the user as it is and like geany or nano are doing. If it is consent to chop an existing newline while loading and "silently" adding one by "saving" I will implement this behavior.

Torsten Lilge <ttl>
Group Member
Sat 22 Feb 2020 10:12:34 PM UTC, comment #10: 

To me this is just how a text editor should work. Here's a practical walkthrough with the GNOME gedit editor, and I get the same behavior with emacs or vim.

If I open a new empty buffer and click Save and give it a name, I get a zero byte empty file.

If I type a single character, let's say 'a', and click Save, I get a two byte file, an 'a' followed by a newline.

If I hit Enter after the 'a' and click Save, I get a three byte file, an 'a' followed by two newlines.

If I select all text with Ctrl+A, delete everything, then press Enter once and click Save, I get a two byte file, two newlines.

The best way I can describe this is if the buffer is empty, an empty file should be written. Otherwise, the contents of the text area should have a newline appended and written to the file.

When a file is loaded into the editor, if the file ends in a newline, the newline should be chopped off before populating the text into the editor text area.

Mike Miller <mtmiller>
Group Member
Sat 22 Feb 2020 09:45:01 PM UTC, comment #9: 

comment #8:

> This isn't quite right for me yet.
>
> 1. When this setting is enabled, but not the setting to remove trailing whitespace, this setting deletes all trailing whitespace on the last line of the file.

Actually this  was intended. Is it desired to have whitespaces at the end of a file except for this one empty newline?

> 2. This should not delete multiple newlines and spaces at the end of the file when saving, and it should always append a newline. If I press Enter to add a blank line in the editor, the file should end with two newlines, not just one.

See above. What is the purpose of multiple newlines at the end of a file?
 

> 3. After saving, the file is reloaded in the editor, and it now shows a blank line at the end of the file that wasn't there before. When this setting is enabled and a file is read that ends in a newline, one final newline should be deleted and removed before adding the text to the editor text view.
>
> So when saving a file, always append a single line ending, unless the buffer is completely empty. When loading a file, always remove the last line ending, if there is one.

When the file ends with a newline, I do not understand why this newline should be hidden to the user by deleting it while loading? In this case, the user might add one manually and at the end there are two. Why adding an empty line when there is already one?

Torsten Lilge <ttl>
Group Member
Sat 22 Feb 2020 09:06:07 PM UTC, comment #8: 

This isn't quite right for me yet.

1. When this setting is enabled, but not the setting to remove trailing whitespace, this setting deletes all trailing whitespace on the last line of the file.

2. This should not delete multiple newlines and spaces at the end of the file when saving, and it should always append a newline. If I press Enter to add a blank line in the editor, the file should end with two newlines, not just one.

3. After saving, the file is reloaded in the editor, and it now shows a blank line at the end of the file that wasn't there before. When this setting is enabled and a file is read that ends in a newline, one final newline should be deleted and removed before adding the text to the editor text view.

So when saving a file, always append a single line ending, unless the buffer is completely empty. When loading a file, always remove the last line ending, if there is one.

Mike Miller <mtmiller>
Group Member
Sat 22 Feb 2020 04:23:36 PM UTC, comment #7: 
Torsten Lilge <ttl>
Group Member
Fri 21 Feb 2020 07:37:29 PM UTC, comment #6: 

Yeah, making these editor behavior changes on the default branch is good with me, no need to get this in at the last minute.

I don't really use the GUI editor at all, but I wanted to propose some opinionated defaults so that people using this editor to contribute changes and new functions to Octave have these easy style things fixed for them.

Mike Miller <mtmiller>
Group Member
Fri 21 Feb 2020 07:11:16 PM UTC, comment #5: 

Famous last words in software development:  "I doubt that it would cause problems on the stable branch"  :-)

John W. Eaton <jwe>
Group administrator
Fri 21 Feb 2020 06:52:20 PM UTC, comment #4: 

This is marked as a feature request so I think it should go on the development branch.  I doubt that it would cause problems on the stable branch, but we might as well be consistent.

Rik <rik5>
Group administrator
Fri 21 Feb 2020 06:38:39 PM UTC, comment #3: 

I am working on a patch for this request and the one for removing trailing white spaces. Should they be pushed to the stable (6.0.1) or default branch?

Torsten Lilge <ttl>
Group Member
Thu 20 Feb 2020 04:40:44 AM UTC, comment #2: 

I added missing newlines to several ordinary text files in the Octave code base for UNIX compliance.  See changeset https://hg.savannah.gnu.org/hgweb/octave/rev/273db03ab762.

Rik <rik5>
Group administrator
Wed 19 Feb 2020 11:19:32 PM UTC, comment #1: 

I raised the severity.  It is still only "Minor", but I think this should get fixed.  I noticed recently that some of the files in Mercurial did not end in newlines which is it's own issue, but possibly related if the files were edited by someone in the GUI.

Rik <rik5>
Group administrator
Wed 19 Feb 2020 08:54:35 PM UTC, original submission:  

Unix files are line oriented, and it's expected that every line ends in a newline character. The last byte of every file should be a newline character.

The GUI editor does not follow this standard, and instead only writes newline characters when a line is followed by another line.

The standard Unix file behavior can only be achieved currently by pressing an extra Enter at the end of the file to insert a fake extra line at the end.

The editor should always write a newline at the end of files when saving, or at the very least offer a setting to choose the behavior, with the default being the standard to end files with newlines.

This would help new contributors edit and write m-file functions for submission to Octave, since this is part of our coding style guide.

Mike Miller <mtmiller>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-28 ttl StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-02-23 rik5 Carbon-CopyRemoved 72865 -
    2020-02-23 ttl StatusIn Progress Ready For Test
    2020-02-22 mtmiller StatusFixed In Progress
        Open/ClosedClosed Open
    2020-02-22 ttl StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2020-02-21 ttl Assigned toNone ttl
    2020-02-19 rik5 Severity1 - Wish 2 - Minor
        StatusNone Confirmed
    2020-02-19 mtmiller Carbon-CopyRemoved 80942 -

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code