From: Yasushi SHOJI <yasushi.shoji@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-org list <emacs-orgmode@gnu.org>
Subject: Re: [RFC] Moving "manual.org" into core
Date: Thu, 1 Feb 2018 20:43:06 +0900 [thread overview]
Message-ID: <CAELBRWK0X2jjiT-=w=Ze+Y66mKnjow1aCocwRDVLFQWAGebywQ@mail.gmail.com> (raw)
In-Reply-To: <87zi4wpw0x.fsf@nicolasgoaziou.fr>
Hi,
On Mon, Jan 29, 2018 at 11:41 PM, Nicolas Goaziou
<mail@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <yasushi.shoji@gmail.com> writes:
>
>> Do you see this on your env? Or, is it just me?
>
> I don't see anything like this.
Hmm... I don't know how to fix this.
>> I'd like to have the formatter and `fill-paragraph` work in a coherent way.
>> But, if you, who know org much better than me, don't know, I don't think
>> I can help. Though, just in case, can you elaborate a bit?
>
> The formatter doesn't call `fill-paragraph' at all. No wonder both do
> not work in a way you would expect.
ah, ok.
> The newline characters introduced in the output of the formatter were
> present already in the original text. However, some objects ignore white
> spaces on purpose. For example, [[foo bar]] and [[foo bar]] and [[foo\n
> bar]] are equivalent, so the parser does not retain the distinction
> between them. Hence links are always formatted on a single line.
I see.
> Now, I'm not sure the formatter should call `fill-paragraph', for some
> reasons:
>
> - the original document could be using `visual-line-mode' so there's
> could be nothing to fill without Org knowing about it;
>
> - Calling `fill-paragraph' requires full fontification, so `org-mode'
> would be initialised at every paragraph to fill;
>
> - `fill-paragraph' depends heavily on user's configuration (custom link
> types, `org-fontify-emphasized-text', `org-hide-emphasis-markers',
> `org-pretty-entities'...) whereas the formatter is expected to be more
> neutral.
Being neutral is good.
What if _I_, for my own project, want to customize the formatter and like to
call fill-paragraph, can I still do this?
I don't know how `fill-paragraph` works and the second point you listed
above worries me.
With my ignorance, I thought just call org-fill-paragraph. Or, do you
mean that "`org-mode' will be initialized" in `org-fill-paragraph`?
BTW, while reading `org-fill-paragraph`, I found a bug.
#+begin_src emacs-lisp
(add-to-list 'load-path "~/path/to/orgdir/lisp")
#+end_src
activate the region for the src block above, and do `M-x org-fill-paragraph`.
It will inf-loop because `M-q` moves the cursor back to the beginning of
the middle line.
> We could however, un-fill everything. But the output would be very
> different. So, TRTD is not obvious.
For the default behavior, I don't think that a good idea.
>> Since you fixed the big ones, I can see another issue. This is also indentation
>> issue, but with a macro replacement . Somehow, macro replacement
>> gets extra indentation. Like this:
>
>> a numeric prefix, check that many days. For example, {{{kbd(C-1
>> - C-c / d)}}} shows all deadlines due tomorrow.
>> + C-c / d)}}} shows all deadlines due tomorrow.
>
> This is related to the explanation above. Macros did the opposite of
> links. The parser didn't remove meaningless spaces upon parsing macros.
> So those would be inserted twice. I fixed this. Now macros show the same
> behaviour as links: even multi-lines macros are inserted as a single
> line.
Thank you for fixing this, too.
--
yashi
next prev parent reply other threads:[~2018-02-01 11:43 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-20 14:43 [RFC] Moving "manual.org" into core Nicolas Goaziou
2018-01-20 17:41 ` Achim Gratz
2018-01-20 18:15 ` Nicolas Goaziou
2018-01-20 18:36 ` Achim Gratz
2018-01-20 18:51 ` Nicolas Goaziou
2018-01-20 17:41 ` Thomas S. Dye
2018-01-22 10:51 ` Bastien Guerry
2018-01-22 13:48 ` Nicolas Goaziou
2018-01-22 15:30 ` Kaushal Modi
2018-01-22 16:02 ` Nicolas Goaziou
2018-01-22 17:00 ` Kaushal Modi
2018-01-22 17:20 ` Nicolas Goaziou
2018-01-22 17:31 ` Kaushal Modi
2018-01-22 19:52 ` Nicolas Goaziou
2018-01-23 15:19 ` Kaushal Modi
2018-01-23 16:30 ` Julius Dittmar
2018-01-23 16:33 ` Nicolas Goaziou
2018-01-23 16:37 ` Kaushal Modi
2018-01-22 16:35 ` Bastien Guerry
2018-01-22 16:53 ` Kaushal Modi
2018-01-22 16:35 ` Bastien Guerry
2018-01-22 16:31 ` Bastien Guerry
2018-01-22 17:03 ` Nicolas Goaziou
2018-01-23 8:07 ` org-adapt-indentation 'content (was Re: [RFC] Moving "manual.org" into core) Christian Moe
2018-03-06 19:01 ` Bastien Guerry
2018-01-22 19:04 ` [RFC] Moving "manual.org" into core Achim Gratz
2018-03-03 9:17 ` Nicolas Goaziou
2018-03-03 10:18 ` Bastien Guerry
2018-03-03 11:29 ` Nicolas Goaziou
2018-03-03 15:57 ` Bastien Guerry
2018-03-03 16:15 ` Joseph Vidal-Rosset
2018-03-03 19:48 ` Glenn Morris
2018-03-04 9:30 ` Bastien Guerry
2018-01-23 20:06 ` Thomas S. Dye
2018-01-22 13:54 ` Rasmus
2018-01-22 15:23 ` Kaushal Modi
2018-01-24 8:39 ` Yasushi SHOJI
2018-01-24 11:28 ` Nicolas Goaziou
2018-01-26 8:52 ` Yasushi SHOJI
2018-01-26 10:32 ` Nicolas Goaziou
2018-01-27 8:40 ` Yasushi SHOJI
2018-01-28 15:17 ` Nicolas Goaziou
2018-01-29 2:40 ` Yasushi SHOJI
2018-01-29 14:41 ` Nicolas Goaziou
2018-02-01 11:43 ` Yasushi SHOJI [this message]
2018-02-01 12:11 ` Yasushi SHOJI
2018-02-04 9:05 ` Nicolas Goaziou
2018-02-01 14:55 ` Nicolas Goaziou
2018-02-02 2:07 ` Yasushi SHOJI
2018-02-04 9:40 ` Nicolas Goaziou
2018-02-06 14:11 ` Yasushi SHOJI
2018-01-22 16:41 ` Thomas S. Dye
2018-01-23 8:08 ` Christian Moe
2018-01-23 21:00 ` Samuel Wales
2018-03-04 9:32 ` Bastien Guerry
2018-03-04 10:06 ` Nicolas Goaziou
2018-03-04 10:29 ` Bastien
2018-03-05 14:20 ` Nicolas Goaziou
2018-03-05 16:23 ` Kaushal Modi
2018-03-06 17:41 ` Bastien Guerry
2018-03-06 21:39 ` Achim Gratz
2018-03-05 18:08 ` Thomas S. Dye
2018-03-06 1:08 ` Bastien Guerry
2018-03-06 9:57 ` Thomas S. Dye
2018-03-06 11:55 ` Eric S Fraga
2018-03-06 17:39 ` Bastien
2018-03-06 18:45 ` Thomas S. Dye
2018-03-06 19:19 ` Bastien
2018-03-07 2:53 ` Thomas S. Dye
2018-03-05 19:01 ` Achim Gratz
2018-03-06 19:02 ` Bastien
2018-03-06 18:59 ` Bastien Guerry
[not found] ` <WM!6f8274ba0065f984ff76586f7cf117703ccda15adbb5042672b0d2695ee5ac6b367ee58f70aacbbc9c2b10eecb9672ea!@mailhub-mx3.ncl.ac.uk>
2018-03-05 16:22 ` Phillip Lord
2018-03-06 17:47 ` Bastien Guerry
2018-03-04 10:54 ` Bastien Guerry
2018-03-05 14:26 ` Nicolas Goaziou
2018-03-06 17:43 ` Bastien Guerry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAELBRWK0X2jjiT-=w=Ze+Y66mKnjow1aCocwRDVLFQWAGebywQ@mail.gmail.com' \
--to=yasushi.shoji@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.