insert_final_newline == false --- strip EOL, or leave untouched?
#475
Comments
|
I remember that the Vim plugin implementation should be correct. However, editors have limitations and enforcing either should lead to some editors not being able to do so. |
|
I agree not all editors can implement all properties. However, I still think we should at least make sure the specification lists the intended behaviour of the property, so that plugin authors know the goal. |
For simplicity of implementation, each Kakoune buffer has at least one
line, and each line has at least one character, the trailing newline
("\n").
When writing a buffer to disk, we include the trailing newlines,
independent of whether they are present in the underpinning file.
There are some [use-cases] where this is undesirable, like when editing
a MOTD file or `<pre>`-formatted text on a web page. Additionally,
there are plenty of existing [source code files] that are missing
a trailing newline (probably because Emacs creates such files).
I've been using this workaround to avoid unintentional changes:
hook -always global BufOpenFile .* %{ evaluate-commands %sh{
if [ $(tail -c1 "$kak_hook_param" | wc -l) = 0 ]; then {
echo 'hook -always buffer BufWritePost .* %{
nop %sh{ truncate --size=-1 "$kak_hook_param" }
}'
} fi
} }
The -always switches are necessary when using [find-apply-changes]
which edits and writes files in a draft context with "-no-hooks"
(probably to suppress auto-format hooks).
Obviate the need for this workaround by making Kakoune preserve
missing newlines in the input.
Special care is taken of empty files: they are written back as empty
(without a newline) but if they are no longer empty we do include
the newline.
This patch can be thought of as "damage control". I believe it does
not make any real case worse because proper termination of files
should already be done at creation time. We shouldn't try to fix
the user's mistake here. Other costs are
1. Implementation complexity - but it's pretty contained.
2. We are giving the user the pretense that the file has a newline
even if that won't be written to disk.
The patch makes us match GNU sed but deviate from Vim (which adds
missing newlines).
PR mawww#3724 suggested making this behavior configurable. We could do
that with either approach. However, independent of the approach,
this would add some complexity: when reloading a buffer from disk we'd
want to distinguish between explicitly-set and inferred EOL-at-EOF
option to avoid stomping user configuration.
I also think that the configurability is of limited use.
There is even an EditorConfig option but it does not include the
sensible behavior of preserving input, see the [editorconfig-issue].
Closes mawww#2147
Closes mawww#3724
[use-cases]: mawww#2147 (comment)
[source code files]: mawww#2147 (comment)
[find-apply-changes]: https://github.com/occivink/kakoune-find/
[editorconfig-issue]: editorconfig/editorconfig#475
For simplicity of implementation, each Kakoune buffer has at least one
line, and each line has at least one character, the trailing newline
("\n").
When writing a buffer to disk, we include the trailing newlines,
independent of whether they are present in the underpinning file.
There are some [use-cases] where this is undesirable, like when editing
a MOTD file or `<pre>`-formatted text on a web page. Additionally,
there are plenty of existing [source code files] that are missing
a trailing newline (probably because Emacs creates such files).
I've been using this workaround to avoid unintentional changes:
hook -always global BufOpenFile .* %{ evaluate-commands %sh{
if [ $(tail -c1 "$kak_hook_param" | wc -l) = 0 ]; then {
echo 'hook -always buffer BufWritePost .* %{
nop %sh{ truncate --size=-1 "$kak_hook_param" }
}'
} fi
} }
The -always switches are necessary when using [find-apply-changes]
which edits and writes files in a draft context with "-no-hooks"
(probably to suppress auto-format hooks).
Obviate the need for this workaround by making Kakoune preserve
missing newlines in the input.
Special care is taken of empty files: they are written back as empty
(without a newline) but if they are no longer empty we do include
the newline.
This patch can be thought of as "damage control". I believe it does
not make any real case worse because proper termination of files
should already be done at creation time. We shouldn't try to fix
the user's mistake here. Other costs are
1. Implementation complexity - but it's pretty contained.
2. We are giving the user the pretense that the file has a newline
even if that won't be written to disk.
The patch makes us match GNU sed but deviate from Vim (which adds
missing newlines).
PR mawww#3724 suggested making this behavior configurable. We could do
that with either approach. However, independent of the approach,
this would add some complexity: when reloading a buffer from disk we'd
want to distinguish between explicitly-set and inferred EOL-at-EOF
option to avoid stomping user configuration.
I also think that the configurability is of limited use.
There is even an EditorConfig option but it does not include the
sensible behavior of preserving input, see the [editorconfig-issue].
Overall, I don't think we should make this configurable unless
there is a strong reason. It should be easy to add workarounds
to manually fix up line endings.
Closes mawww#2147
Closes mawww#3724
[use-cases]: mawww#2147 (comment)
[source code files]: mawww#2147 (comment)
[find-apply-changes]: https://github.com/occivink/kakoune-find/
[editorconfig-issue]: editorconfig/editorconfig#475
For simplicity of implementation, each Kakoune buffer has at least one
line, and each line has at least one character, the trailing newline
("\n").
When writing a buffer to disk, we include the trailing newlines,
independent of whether they are present in the underpinning file.
There are some [use-cases] where this is undesirable, like when editing
a MOTD file or `<pre>`-formatted text on a web page. Additionally,
there are plenty of existing [source code files] that are missing
a trailing newline (probably because Emacs creates such files).
I've been using this workaround to avoid unintentional changes:
hook -always global BufOpenFile .* %{ evaluate-commands %sh{
if [ $(tail -c1 "$kak_hook_param" | wc -l) = 0 ]; then {
echo 'hook -always buffer BufWritePost .* %{
nop %sh{ truncate --size=-1 "$kak_hook_param" }
}'
} fi
} }
The -always switches are necessary when using [find-apply-changes]
which edits and writes files in a draft context with "-no-hooks"
(probably to suppress auto-format hooks).
Obviate the need for this workaround by making Kakoune preserve
missing newlines in the input.
Special care is taken of empty files: they are written back as empty
(without a newline) but if they are no longer empty we do include
the newline.
This patch can be thought of as "damage control". I believe it does
not make any real case worse because proper termination of files
should already be done at creation time. We shouldn't try to fix
the user's mistake here. Other costs are
1. Implementation complexity - but it's pretty contained.
2. We are giving the user the pretense that the file has a newline
even if that won't be written to disk.
The patch makes us match GNU sed but deviate from Vim (which adds
missing newlines).
PR mawww#3724 suggested making this behavior configurable. We could do
that with either approach. However, independent of the approach,
this would add some complexity: when reloading a buffer from disk we'd
want to distinguish between explicitly-set and inferred EOL-at-EOF
option to avoid stomping user configuration.
I also think that the configurability is of limited use.
There is even an EditorConfig option but it does not include the
sensible behavior of preserving input, see the [editorconfig-issue].
Overall, I don't think we should make this configurable unless
there is a strong reason. It should be easy to add workarounds
to manually fix up line endings.
Closes mawww#2147
Closes mawww#3724
[use-cases]: mawww#2147 (comment)
[source code files]: mawww#2147 (comment)
[find-apply-changes]: https://github.com/occivink/kakoune-find/
[editorconfig-issue]: editorconfig/editorconfig#475
|
So, to validate: The intended behavior of
The third use case is: Multiple newlines at the end of the file (e.g., However, when I requested a feature in #483 to either trim multiple newlines at the end of a file (leaving one and only one newline) or specify the number of blank lines/newlines to leave at the end of the file, I was told that this issue indicates that the specification says that Can someone please provide clarification? Thx. |
|
I don't think they are the same. However, I don't think we'll implement exactly However, this issue should still be relevant to what you are looking for (exactly 1 EOL or only must end with EOL?) |
Thx. I didn't figure my feature request would be accepted, but at this point I'm simply looking for clarification regarding the intent of the specification. If the intent is to end with one-and-only-one EOL, then I'll go back to the author of the plugin, otherwise I'd request that this be added to the specification for this feature, as I think it's implied. |
Problem: Nvim editorconfig support actively removes a newline if `insert_final_newline=false`. This (apparently) contradicts the spec. editorconfig/editorconfig#475 Solution: Don't set options if `insert_final_newline=false`. fix neovim#21648
|
I think I would be surprised if a property called "insert_final_newline" caused newlines to be removed :) . I believe we should update the specification to say that insert_final_newline: Set to true
+to
ensure file ends with a newline when
-saving
+saving.
-and false to ensure it doesn’t.
+If it is set to false, the newline(s) at the end of the file will neither be checked nor modified.What say you all? |
|
Actually I don't think this is true. If the existing file has only 1 final newline, some editors will delete this final newline. What if the file has multiple newlines and the plugin tells the editor to not add final new lines? I guess editors will do this in wildly different ways (not verified). |
Editors do all kinds of things, but why is that relevant to editorconfig ? The name The central problem is
|
For simplicity of implementation, each Kakoune buffer has at least one
line, and each line has at least one character, the trailing newline
("\n").
When writing a buffer to disk, we include the trailing newlines,
independent of whether they are present in the underpinning file.
There are some [use-cases] where this is undesirable, like when editing
a MOTD file or `<pre>`-formatted text on a web page. Additionally,
there are plenty of existing [source code files] that are missing
a trailing newline (probably because Emacs creates such files).
I've been using this workaround to avoid unintentional changes:
hook -always global BufOpenFile .* %{ evaluate-commands %sh{
if [ $(tail -c1 "$kak_hook_param" | wc -l) = 0 ]; then {
echo 'hook -always buffer BufWritePost .* %{
nop %sh{ truncate --size=-1 "$kak_hook_param" }
}'
} fi
} }
The -always switches are necessary when using [find-apply-changes]
which edits and writes files in a draft context with "-no-hooks"
(probably to suppress auto-format hooks).
Obviate the need for this workaround by making Kakoune preserve
missing newlines in the input.
Special care is taken of empty files: they are written back as empty
(without a newline) but if they are no longer empty we do include
the newline.
This patch can be thought of as "damage control". I believe it does
not make any real case worse because proper termination of files
should already be done at creation time. We shouldn't try to fix
the user's mistake here. Other costs are
1. Implementation complexity - but it's pretty contained.
2. We are giving the user the pretense that the file has a newline
even if that won't be written to disk.
The patch makes us match GNU sed but deviate from Vim (which adds
missing newlines).
PR mawww#3724 suggested making this behavior configurable. We could do
that with either approach. However, independent of the approach,
this would add some complexity: when reloading a buffer from disk we'd
want to distinguish between explicitly-set and inferred EOL-at-EOF
option to avoid stomping user configuration.
I also think that the configurability is of limited use.
There is even an EditorConfig option but it does not include the
sensible behavior of preserving input, see the [editorconfig-issue].
Overall, I don't think we should make this configurable unless
there is a strong reason. It should be easy to add workarounds
to manually fix up line endings.
Closes mawww#2147
Closes mawww#3724
[use-cases]: mawww#2147 (comment)
[source code files]: mawww#2147 (comment)
[find-apply-changes]: https://github.com/occivink/kakoune-find/
[editorconfig-issue]: editorconfig/editorconfig#475
For simplicity of implementation, each Kakoune buffer has at least one
line, and each line has at least one character, the trailing newline
("\n").
When writing a buffer to disk, we include the trailing newlines,
independent of whether they are present in the underpinning file.
There are some [use-cases] where this is undesirable, like when editing
a MOTD file or `<pre>`-formatted text on a web page. Additionally,
there are plenty of existing [source code files] that are missing
a trailing newline (probably because Emacs creates such files).
I've been using this workaround to avoid unintentional changes:
hook -always global BufOpenFile .* %{ evaluate-commands %sh{
if [ $(tail -c1 "$kak_hook_param" | wc -l) = 0 ]; then {
echo 'hook -always buffer BufWritePost .* %{
nop %sh{ truncate --size=-1 "$kak_hook_param" }
}'
} fi
} }
The -always switches are necessary when using [find-apply-changes]
which edits and writes files in a draft context with "-no-hooks"
(probably to suppress auto-format hooks).
Obviate the need for this workaround by making Kakoune preserve
missing newlines in the input.
Special care is taken of empty files: they are written back as empty
(without a newline) but if they are no longer empty we do include
the newline.
This patch can be thought of as "damage control". I believe it does
not make any real case worse because proper termination of files
should already be done at creation time. We shouldn't try to fix
the user's mistake here. Other costs are
1. Implementation complexity - but it's pretty contained.
2. We are giving the user the pretense that the file has a newline
even if that won't be written to disk.
The patch makes us match GNU sed but deviate from Vim (which adds
missing newlines).
PR mawww#3724 suggested making this behavior configurable. We could do
that with either approach. However, independent of the approach,
this would add some complexity: when reloading a buffer from disk we'd
want to distinguish between explicitly-set and inferred EOL-at-EOF
option to avoid stomping user configuration.
I also think that the configurability is of limited use.
There is even an EditorConfig option but it does not include the
sensible behavior of preserving input, see the [editorconfig-issue].
Overall, I don't think we should make this configurable unless
there is a strong reason. It should be easy to add workarounds
to manually fix up line endings.
Closes mawww#2147
Closes mawww#3724
[use-cases]: mawww#2147 (comment)
[source code files]: mawww#2147 (comment)
[find-apply-changes]: https://github.com/occivink/kakoune-find/
[editorconfig-issue]: editorconfig/editorconfig#475
For simplicity of implementation, each Kakoune buffer has at least one
line, and each line has at least one character, the trailing newline
("\n").
When writing a buffer to disk, we include the trailing newlines,
independent of whether they are present in the underpinning file.
There are some [use-cases] where this is undesirable, like when editing
a MOTD file or `<pre>`-formatted text on a web page. Additionally,
there are plenty of existing [source code files] that are missing
a trailing newline (probably because Emacs creates such files).
I've been using this workaround to avoid unintentional changes:
hook -always global BufOpenFile .* %{ evaluate-commands %sh{
if [ $(tail -c1 "$kak_hook_param" | wc -l) = 0 ]; then {
echo 'hook -always buffer BufWritePost .* %{
nop %sh{ truncate --size=-1 "$kak_hook_param" }
}'
} fi
} }
The -always switches are necessary when using [find-apply-changes]
which edits and writes files in a draft context with "-no-hooks"
(probably to suppress auto-format hooks).
Obviate the need for this workaround by making Kakoune preserve
missing newlines in the input.
Special care is taken of empty files: they are written back as empty
(without a newline) but if they are no longer empty we do include
the newline.
This patch can be thought of as "damage control". I believe it does
not make any real case worse because proper termination of files
should already be done at creation time. We shouldn't try to fix
the user's mistake here. Other costs are
1. Implementation complexity - but it's pretty contained.
2. We are giving the user the pretense that the file has a newline
even if that won't be written to disk.
The patch makes us match GNU sed but deviate from Vim (which adds
missing newlines).
PR mawww#3724 suggested making this behavior configurable. We could do
that with either approach. However, independent of the approach,
this would add some complexity: when reloading a buffer from disk we'd
want to distinguish between explicitly-set and inferred EOL-at-EOF
option to avoid stomping user configuration.
I also think that the configurability is of limited use.
There is even an EditorConfig option but it does not include the
sensible behavior of preserving input, see the [editorconfig-issue].
Overall, I don't think we should make this configurable unless
there is a strong reason. It should be easy to add workarounds
to manually fix up line endings.
Closes mawww#2147
Closes mawww#3724
[use-cases]: mawww#2147 (comment)
[source code files]: mawww#2147 (comment)
[find-apply-changes]: https://github.com/occivink/kakoune-find/
[editorconfig-issue]: editorconfig/editorconfig#475
|
Yes, this is a bit confusing. Vim plugin doesn't do it partly because there's no way (or no clean way) to enforce no EOF of a file. If memory serves, we made the compromise in Vim but thought So what has really caused the confusion here may be that the spec should explicitly state that a plugin doesn't have to implement each single requirement -- they need to do their best in the context of the working editor. This is kind of obvious for developers in this circle but may not be obvious for anyone new to this system. What do you think? |
I would also add the requirement that where there is a difference between the specification and the behavior of the plugin, that difference MUST be documented. That would help reduce noise. |
|
To second what @justinmk said, I would like to propose that the EditorConfig specification be amended in one of two ways:
Taking the position that "editors should just implement the spec for whatever makes sense to them" diminishes the value of having a specification at all, and we will very soon (if we haven't already) run into "well it works in my editor" kind of issues. The whole point of having EditorConfig is to have common behavior enforced across editors. This ambiguity in the specification is detrimental to that objective. |
Given this situation, I think it's pretty clear that |
|
I agree with
|
For simplicity of implementation, each Kakoune buffer has at least one
line, and each line has at least one character, the trailing newline
("\n").
When writing a buffer to disk, we include the trailing newlines,
independent of whether they are present in the underpinning file.
There are some [use-cases] where this is undesirable, like when editing
a MOTD file or `<pre>`-formatted text on a web page. Additionally,
there are plenty of existing [source code files] that are missing
a trailing newline (probably because Emacs creates such files).
I've been using this workaround to avoid unintentional changes:
hook -always global BufOpenFile .* %{ evaluate-commands %sh{
if [ $(tail -c1 "$kak_hook_param" | wc -l) = 0 ]; then {
echo 'hook -always buffer BufWritePost .* %{
nop %sh{ truncate --size=-1 "$kak_hook_param" }
}'
} fi
} }
The -always switches are necessary when using [find-apply-changes]
which edits and writes files in a draft context with "-no-hooks"
(probably to suppress auto-format hooks).
Obviate the need for this workaround by making Kakoune preserve
missing newlines in the input.
Special care is taken of empty files: they are written back as empty
(without a newline) but if they are no longer empty we do include
the newline.
This patch can be thought of as "damage control". I believe it does
not make any real case worse because proper termination of files
should already be done at creation time. We shouldn't try to fix
the user's mistake here. Other costs are
1. Implementation complexity - but it's pretty contained.
2. We are giving the user the pretense that the file has a newline
even if that won't be written to disk.
The patch makes us match GNU sed but deviate from Vim (which adds
missing newlines).
PR mawww#3724 suggested making this behavior configurable. We could do
that with either approach. However, independent of the approach,
this would add some complexity: when reloading a buffer from disk we'd
want to distinguish between explicitly-set and inferred EOL-at-EOF
option to avoid stomping user configuration.
I also think that the configurability is of limited use.
There is even an EditorConfig option but it does not include the
sensible behavior of preserving input, see the [editorconfig-issue].
Overall, I don't think we should make this configurable unless
there is a strong reason. It should be easy to add workarounds
to manually fix up line endings.
Closes mawww#2147
Closes mawww#3724
[use-cases]: mawww#2147 (comment)
[source code files]: mawww#2147 (comment)
[find-apply-changes]: https://github.com/occivink/kakoune-find/
[editorconfig-issue]: editorconfig/editorconfig#475
The specification says (emphasis added):
However:
falseas "leave untouched", not "remove trailing newline".insert_final_newline = falsethe text editor is simply instructed to not auto-insert final newlines".Which is it? Does
insert_final_newline == falsemean:?
I think it's option 1, and that the specification should be updated, but I'm not sure. Thanks!
Motivating example: editorconfig/editorconfig-vim#136
Relates to #59 and #151
The text was updated successfully, but these errors were encountered: