When I edit a file with Vim and only put one word in it Vim will add a newline. This is the desired behavoir. Mousepad does not do this, leading to the following: $ cat <file edited with vim> Hello $ $ cat <file edited with mousepad> Hello$ Even gedit (which also uses GTK) follows the behavoir of VIM.
Created attachment 2201 Patch for terminating files with a newline while saving
It's annoying when you're editing a C source code and gcc throws a newline warning message. Can the patch be reviewed and committed, please? Thanks everybody.
Very annoying. Please implement this simple feature.
From my user perspective it's indeed weird that no newline is added like in Gedit, VIM or even nano (no offence given). Please implement this upstream (BTW thanks for patch).
Matthew, Xfce devs: could you please either apply this patch, or state a reason for rejection? The patch is 5 years old now. Thanks.
POSIX states that a file should finish by a newline character. So yes, this patch should definitely be applied.
@Steve, it wasn't rejected was it? The bugmail shows the state changed from NEW (ie. TODO) to ASSIGNED (ie. somebody's working on it), and the priority changed from Medium (ie. normal) to Very High (ie. critical bug that makes the program unusable/insecure). Personally I never looked back at all the bugs from Mousepad 0.2, before the re-write, when I started contributing, because there were too many and the vast majority didn't apply to the re-write. FWIW, the main reason open bugs are not fixed is just a lack of time/manpower; it's just me and I don't have access to give commit rights to contributors who have shown to be competent, so it bottlenecks. There's something like 50-80 bugs I want to get addressed before next release (which there's nobody to do), I'll gladly add this to my "when I get a week/weekend free I'll tackle as many as possible" pile :) On the technical side, this patch, being made so long ago is effectively for a different program than Mousepad 0.3 since it shares little to no source code with 0.2, and so is not applicable as is. Also it seems to only apply to one of the Line Ending modes (LF/Unix), so if someone is editing a file made on Windows with CRLF at the end, it will insert an "invalid" (in the MS-sense) character at the tail of the file.
Hi Matthew, Sorry for the confusion. I mark bug reports ASSIGNED to indicate that someone reviewed the reports and that the patches are a priori correct (because we don't have a TRIAGED mode). I marked it Very High because I wanted to spot it again later. This patch is 5 years old and is one of the oldest valid-looking patches we have in the bugzilla. As it still generated comments in 2014, that makes for a 5 year span of demand for this apparently simple feature. I understand a rewrite is needed, so the patch can't be applied as is. I can leave it assigned to you if you want to take the time to do it later (leaving ASSIGNED), or I can give this to potentially new contributors looking for simple tasks (switching to NEW). Thanks.
Created attachment 6964 bug 4824 new patch Hello, I've been experiencing this bug for a long time and decided to make an updated patch. The core of the issue is that the text view doesn't expect a line ending at end of the last line, but POSIX text files do. According to https://developer.apple.com/library/content/documentation/OpenSource/Conceptual/ShellScripting/PortingScriptstoMacOSX/PortingScriptstoMacOSX.html#//apple_ref/doc/uid/TP40004268-TP40003517-SW37 Mac style text files are the same, although I couldn't test that. However I did test Microsoft Notepad and it doesn't expect a line ending after the last line. So the patch removes/adds the final line ending on open/save for Unix and Mac files. Note that the condition to check for existing \n in the original patch is not needed as this would cause multiple empty lines at the end of a file to behave incorrectly. Since the text view's buffer will continue to be used after save I didn't modify it. I also avoided a duplicate realloc on save with the write bom code. Not sure what process should be used for requesting a review, but anyways I'm running it and it's working well.
Created attachment 6966 bug 4824 new patch v3 Fixed some edge cases with files 0 or 1 bytes in length. Patch is against devel tip, but this patch also works with Mousepad 0.3.0 if anyone needs to backport.
I have tested the patch and can confirm that it works as intended.
Aaron B referenced this bugreport in commit 7e7a4214ce2d54cd9ee4be1c211c4250b4d4cade Append a newline char at EOF when saving (Bug #4824) https://git.xfce.org/apps/mousepad/commit?id=7e7a4214ce2d54cd9ee4be1c211c4250b4d4cade
Thanks aaron for the patch, i've tested it in the following cases (on top of git master of course): saving a file containing only 'test' as UNIX line endings, hexdump shows: 0000000 6574 7473 000a 0000005 switch to MAC line endings, save again: 0000000 6574 7473 000d 0000005 and switch to DOS-style, then save: 0000000 6574 7473 0000004 so it does what's expected. Sorry it took so long, and thanks theo for testing it ! closing the bug now, hoping for a release soonish.
I added my comment to the commit: https://gitlab.xfce.org/apps/mousepad/-/commit/7e7a4214ce2d54cd9ee4be1c211c4250b4d4cade But in summary, I disagree with this from the start, it was not a bug to start with, and the fix has made things worse (sorry).