Retain whether a file ended with a trailing newline optionally displaying it#687
Retain whether a file ended with a trailing newline optionally displaying it#687ntninja wants to merge 6 commits intomate-desktop:masterfrom
Conversation
…e should be hidden if present
…ing to determine whether the trailing newline should be hidden
…den when loading the document
…o documents that previously had one or were empty
|
@mbkma |
|
I simply don't know anything about how to actually use this in production, but will give it a test build and run |
lukefromdc
left a comment
lukefromdc
left a comment
There was a problem hiding this comment.
This works as intended, including adding the trailing newline to a document that did not contain one if hide-trailing-newline is not checked (defaults to checked/FALSE). Nice work including this in Pluma Preferences so it can be changed w/o having to have dconf-editor installed or using gsettings from the command line
|
A few comments from my side:
Sorry if some of my statements are wrong, I just quickly scanned the changes :) |
I have never seen this MR in gedit, I wrote this code entirely based on how pluma works today. Quickly scanning that code however, I think I get the confusion here. Most importantly consider what happens when you change the setting while a document is open: In the gedit MR you linked (unless I’m mistaken) opening a document with a trailing newline, then enabling the option, then saving it will cause the file to be saved without the trailing newline (ie: the newline will be lost). In my PR the document remembers whether it has previously hidden (removed) the trailing newline and will therefor correctly add it again when the document is saved even if the setting was changed in the mean time. This state (newline removed from the editing buffer or not) is what is stored in the “trimmed-trailing-newline” property – without retaining this information Pluma would also lose the newline if the setting is changed while a document with trailing newline is open and this is a lot more problematic for Pluma with this PR since the setting is visible and reachable in the UI.
As should be apparent from the previous answer, something is indeed “there but not show”: It’s just the extra information on whether the document has a trailing newline is not stored in the editing buffer (where the user would see it) but in a separate property (“trimmed-trailing-newline”).
That is indeed a valid concern: It would be nice if the hidden newline got shown/hidden as the checkbox in the settings is unchecked/checked. So basically you’re saying I should fix this todo: https://github.com/mate-desktop/pluma/pull/687/files#diff-5c01dc24a248053550fb8911bec3b952aefb442ca20c6d0647a12c6e41346532R402-R406 😉
I looked into that and it appears the way to fix that is to let GtkSourceView know whether the file is intended to contain a trailing newline or not using That option got added in GtkSourceView 3.14, is that old enough for Pluma to hard-depend on it?
I’ll look into this one, once it is clear whether we agree on the fundamentals. |
|
@mbkma |
|
Any updates on this? |
|
I never got any reply to my questions, so no. |
vkareh
left a comment
vkareh
left a comment
There was a problem hiding this comment.
The changes here feel inconsistent, like the gsettings does more than it intends, and pluma decides whether to honour the gsettings or not based on the size of the file.
My suggestion is to drop this and instead backport https://gitlab.gnome.org/World/gedit/gedit/-/commit/fe62ab8175747298a5315aaeed53ef0c56e60817
| <summary>Hide Tailing Newline</summary> | ||
| <description>Whether pluma should hide the final newline in opened files if one was present when loading the file. Enabling this will also cause newly created files to be saved with a trailing newline by default.</description> |
There was a problem hiding this comment.
This seems wrong. The fact that "hiding" the newline causes the newline to be added is unexpected behaviour.
| <property name="step-increment">1</property> | ||
| <property name="page-increment">10</property> |
There was a problem hiding this comment.
Can all these rewrites be left out of this patch?
|
|
||
| g_object_class_install_property (gobject_class, | ||
| PROP_ADD_TRAILING_NEWLINE, | ||
| g_param_spec_boolean ("add-trailing-newline", |
There was a problem hiding this comment.
This seems strange to me. You have a property below to trim the newline, and also a property to add the newline. On top of that there's a gsettings to hide it (but also to keep adding it?). It feels inconsistent.
| if (!trimmed_trailing_newline && doc_char_count > 0) | ||
| { | ||
| /* Document did not contain any trailing newline, so we want to | ||
| change hide-trailing-newline to FALSE so that saving the | ||
| document doesn’t automatically add a trailing newline if it | ||
| wasn’t previously present. */ | ||
| /* Note that we special-case empty documents here as these never | ||
| contain a trailing newline, so we cannot make any assumptions | ||
| on whether the omission of the trailing newline was intentional | ||
| or not. */ | ||
| g_object_set (doc, | ||
| "hide-trailing-newline", FALSE, | ||
| NULL); |
There was a problem hiding this comment.
This feels wrong. It means that pluma does whatever it wants even when the gsetting is set.
| </key> | ||
| <key name="hide-trailing-newline" type="b"> | ||
| <default>true</default> | ||
| <summary>Hide Tailing Newline</summary> |
5 participants
For some reason I felt the need to rewrite #388 after all these years and the result is this.
A lot of the discussion of the old PR still applies, but instead of always having the trailing newline visible (like in that PR), having the trailing newline is now optional.
Details: