On 27/03/2023 21:16, Ihor Radchenko wrote:
+++ b/etc/ORG-NEWS
@@ -145,6 +145,27 @@ execution completes. The new ~:async~ header allows users
to continue
editing with Emacs while a ~:session~ block executes.
** Miscellaneous
+*** Blank lines after removed objects are not retained during
Ihor Radchenko writes:
> I am attaching tentative patch that simply keeps spaces, but if and only
> if the previous object does not end with whitespace (including newline).
Applied, onto main.
Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=960722661
--
Ihor Radchenko
Ihor Radchenko writes:
> Max Nikulin writes:
>
>>>[previous object ]
>>
>> Yes, you do.
>>
>> I expected some complications due to newline characters (not line break
>> markup objects), but they are not included in :post-blank and
>> represented as "\n" string objects.
>
> Newlines are
Max Nikulin writes:
> On 11/03/2023 17:38, Ihor Radchenko wrote:
>>
>> Newlines are tricky. They may or may not be significant.
>> For example, in CJK paragraphs, newlines are to be stripped.
>>
>> I think that a reasonable thing to do could be not adding newlines if
>> the previous object is
On 11/03/2023 17:38, Ihor Radchenko wrote:
Newlines are tricky. They may or may not be significant.
For example, in CJK paragraphs, newlines are to be stripped.
I think that a reasonable thing to do could be not adding newlines if
the previous object is a plain string ending with a newline.
Max Nikulin writes:
>>[previous object ]
>
> Yes, you do.
>
> I expected some complications due to newline characters (not line break
> markup objects), but they are not included in :post-blank and
> represented as "\n" string objects.
Newlines are tricky. They may or may not be
On 10/03/2023 19:08, Ihor Radchenko wrote:
Do I understand correctly that you propose the following:
If we have
[previous object ][object to be removed ]
change it to
[previous object ]
Yes, you do.
I expected some complications due to newline characters (not line break
markup
Max Nikulin writes:
>> Plain strings always have :post-blank nil.
>> So do line breaks.
>
> If preceding object is string than trailing spaces should be taken into
> account instead of :post-blank. If footnote reference or similar object
> has more :post-blank spaces than replace it by string
On 09/03/2023 19:43, Ihor Radchenko wrote:
Max Nikulin writes:
Both "Heading" and "[0/1]" have the same :post-blank " ", so when
stripping the statistics cookie use " " :post-blank for "Heading"
(retain current value).
Sorry, but we are mis-communicating here.
No, it just means that I am
Max Nikulin writes:
> On 07/03/2023 20:59, Ihor Radchenko wrote:
>> I agree about the last example, but what about "Heading [0/1] text"?
>
> Both "Heading" and "[0/1]" have the same :post-blank " ", so when
> stripping the statistics cookie use " " :post-blank for "Heading"
> (retain current
On 07/03/2023 20:59, Ihor Radchenko wrote:
I agree about the last example, but what about "Heading [0/1] text"?
Both "Heading" and "[0/1]" have the same :post-blank " ", so when
stripping the statistics cookie use " " :post-blank for "Heading"
(retain current value).
Max Nikulin writes:
Max Nikulin writes:
> On 05/03/2023 20:01, Ihor Radchenko wrote:
>> Consider
>>
>> * Heading [0/1] text
> ...
>> Text with newline\\
>> [footnote] more text.
> ...
>> Text (parens[footnote] ).
>
> I am not convinced that space should be dropped here.
I agree about the last example, but what
On 05/03/2023 20:01, Ihor Radchenko wrote:
Consider
* Heading [0/1] text
...
Text with newline\\
[footnote] more text.
...
Text (parens[footnote] ).
I am not convinced that space should be dropped here.
It might be enough to use spaces if and only if there are no preceding
spaces. Or
Andrea Lazzarini writes:
> If some languages require it and some not, as you correctly say, couldn't the
> behaviour be customizable?
Maybe. But we are not only talking about footnotes.
Consider
* Heading [0/1] text
Or
Text with newline\\
[footnote] more text.
or
Text (parens[footnote]
If some languages require it and some not, as you correctly say, couldn't the
behaviour be customizable?
> Il giorno 5 mar 2023, alle ore 13:42, Ihor Radchenko ha
> scritto:
>
>
> Andrea Lazzarini writes:
>> Consider the fact that I had to put an extra space before the footnote
>> exactly
Andrea Lazzarini writes:
> Consider the fact that I had to put an extra space before the footnote
> exactly to have a space (not an extra one) in the result.
>
> As you say, couldn't it be replaced with:
>
>> maybe with number of spaces equal to :post-blank ?
Sure, but footnotes are expected
Consider the fact that I had to put an extra space before the footnote exactly
to have a space (not an extra one) in the result.
As you say, couldn't it be replaced with:
> maybe with number of spaces equal to :post-blank ?
> Il giorno 5 mar 2023, alle ore 13:06, Ihor Radchenko ha
>
Max Nikulin writes:
> In my opinion, the filter removing footnotes should transfer afterspaces
> to preceding objects.
I am not sure.
Consider text like "Pellentesque dapibus suscipit ligula. [fn:1] Donec posuere
augue in quam."
with space before the footnote. If we replace the footnote with
I totally agree with Max Nikulin: wouldn't that be an improvement? That would
make things a lot easier for those instances in which you want to put the
footnotes back in.
> Il giorno 3 mar 2023, alle ore 17:47, Max Nikulin ha
> scritto:
>
> On 03/03/2023 22:47, Ihor Radchenko wrote:
>> Max
On 03/03/2023 22:47, Ihor Radchenko wrote:
Max Nikulin writes:
Self-containing example:
8<
#+options: f:nil
Pellentesque dapibus suscipit ligula.[fn::1 ftnt] Donec posuere augue
in quam.
>8
This is because spaces after Org syntax objects are considered a part of
those
Max Nikulin writes:
> Self-containing example:
>
> 8<
> #+options: f:nil
>
> Pellentesque dapibus suscipit ligula.[fn::1 ftnt] Donec posuere augue
> in quam.
> >8
This is because spaces after Org syntax objects are considered a part of
those syntax objects. So, excluding
On 03/03/2023 17:07, Andrea Lazzarini wrote:
After setting 'org-export-with-footnotes' to 'nil',
the space following the footnote is removed when exporting (I’ve tested
this with pandoc [docx and html]).
I am unsure if pandoc is relevant. However the issue exists for ox, e.g.
ox-latex and
After setting 'org-export-with-footnotes' to 'nil',
the space following the footnote is removed when exporting (I’ve tested
this with pandoc [docx and html]).
So, given this example:
«Pellentesque dapibus suscipit ligula.[fn:1] Donec posuere augue in quam.»
The resulting text is:
23 matches
Mail list logo
