Aloha Bastien,
Bastien writes:
Hi Thomas,
"Thomas S. Dye" writes:
Instead, let's move the project forward with the understanding
that
if it proves to be a bad idea, then the Org mode community will
have
Nicolas' very nice .texi file (with backports by Kyle Meyer) to
fall
back on.
Maybe
Bastien Guerry writes:
>> Exactly. Emacs will anyways ship with org.texi. So moving the manual
>> source to Org in the Org repo shouldn't concern the Emacs repo.
>
> Yes, but it is still a concern for Emacs contributors like Glenn and
> others who occasionnally make corrections in Emacs' org.texi.
Hi Thomas,
"Thomas S. Dye" writes:
> Instead, let's move the project forward with the understanding that
> if it proves to be a bad idea, then the Org mode community will have
> Nicolas' very nice .texi file (with backports by Kyle Meyer) to fall
> back on.
Maybe we are miscommunicating, becaus
Aloha Bastien,
I disagree that the manual project should move into a one year
probation where success is measured by the number of contributors.
So, my response to LETS GO! is NOT THERE!
Instead, let's move the project forward with the understanding
that if it proves to be a bad idea, then t
Hi Achim,
Achim Gratz writes:
> I've posted a working Makefile back when Thomas was working on the
> manual and it is still working with minimal modifications. If you
> decide you want to have this (and exactly which way) I'm sure that can
> be further refined in a matter of days (not weeks) to
Hi Nicolas,
Nicolas Goaziou writes:
> I disagree. My motivation is not to attract more contributors. I don't
> think this was Thomas and Jonathan's motivation when they started the
> project either, but I may be wrong.
For the record, I think having more contributors for the manual is a
very sa
phillip.l...@russet.org.uk (Phillip Lord) writes:
> Probably, by the time all of the manuals are in org-mode,
> machines will be significantly faster, there will be emacs-free org mode
> converter, or we will have hit the heat death of the universe. Perhaps
> it's not a problem.
:)
The output of
Hi Nicolas,
Nicolas Goaziou writes:
> You recently re-introduced a file named "orgmanual.org" in contrib/
> alongside "manual.org". The former is apparently outdated.
Yes, my mistake, fixed now.
--
Bastien
Hi Kaushal,
Kaushal Modi writes:
> Exactly. Emacs will anyways ship with org.texi. So moving the manual
> source to Org in the Org repo shouldn't concern the Emacs repo.
Yes, but it is still a concern for Emacs contributors like Glenn and
others who occasionnally make corrections in Emacs' org.
Hello Thomas,
as a preamble, let me say that I appreciate the directness of your
message and the civil tone of this conversation. I understand there
are frustrations lingering around, I have my own too, so let's keep
this thread as constructive as possible, because we all deserve it
as a communit
My 2¢ on this topic:
1. org is an excellent tool for writing. I cannot consider writing with
any other tool these days.
2. texi is an excellent tool for reading/browsing
documentation. Likewise, I cannot imagine doing so in another tool
(in the Emacs sphere).
We should find a way to al
Aloha Bastien,
Bastien Guerry writes:
Maybe this is where some misunderstanding arose: to me, there
was no
_project_ to migrate to manual.org -- it was an idea in the air
after
you made your experiment and we now have the decision at hand
because
the project is, well, DONE.
We could have don
Hi Thomas and all,
please, let's take a deep breath and let me try to explain myself as
clearly as possible. And remember english is not my first language,
so sometimes I may not express myself in the most adequate manner.
First, let me just restate this clearly: I am in favor of editing the
man
Nicolas Goaziou writes:
>> Testing the process of running "make pdf" while emacs will in charge
>> of producing a PDF file (.org => .texi => .pdf) will be interesting,
>> and potentially more error-prone than the current .texi=>.pdf process.
>
> I didn't invest time in the Makefile, so I don't know
Nicolas Goaziou writes:
I don't have strong opinions on this issue.
I read it otherwise.
So do I.
Some history. When I worked on this project several years ago, I
concluded that Bastien was hostile to it, but there was nothing in
his communication that was particularly negative. When I
Bastien writes:
>> For the record, and as a first feedback, I totally disagree with the
>> FUD (".org flexibility will bring us new problems", seriously)
>> spread about the Org manual.
>
> Testing the .texi exporter (and maybe .html and .pdf) against this big
> file will be interesting.
>
> Test
On Mon, Mar 5, 2018 at 9:21 AM Nicolas Goaziou
wrote:
>
> > Again, the question is: what problem are we trying to solve?
>
> Org boasts itself as a format to write, among other things,
> documentation. Do you think it is confidence-inspiring if we do not
> write our own documentation in our forma
Bastien Guerry writes:
> So when we make the move, we publish 9.2 by merging master in maint
> and edit orgmanual.org from both maint and master. Correct?
Correct, but I don't know what "orgmanual.org" you are talking about.
You recently re-introduced a file named "orgmanual.org" in contrib/
al
Hello,
Bastien writes:
> But I'm sure there will be some.
True, as I'm sure there are some "challenges" with the current Texinfo
manual. Therefore, I do not see the point of insisting on the fact that
a new paradigm brings new problems.
> I don't have strong opinions on this issue.
I read it
Hi Nicolas,
Nicolas Goaziou writes:
>> Is the current contrib/orgmanual.org in sync with doc/org.texi in both
>> master and maint?
>
> Not at all. It is in sync (and a bit above) in master only.
Okay.
>> How difficult is it to keep it in sync in both branches?
>
> "manual.org" relies on improv
Hi Nicolas,
Nicolas Goaziou writes:
> For the record, and as a first feedback, I totally disagree with the
> FUD (".org flexibility will bring us new problems", seriously)
> spread about the Org manual.
Maybe I used the wrong word: let's call them "challenges", not
"problems".
But I'm sure the
Hello,
Bastien Guerry writes:
> Is the current contrib/orgmanual.org in sync with doc/org.texi in both
> master and maint?
Not at all. It is in sync (and a bit above) in master only.
> How difficult is it to keep it in sync in both branches?
"manual.org" relies on improvements made to the Tex
Hi Nicolas,
Nicolas Goaziou writes:
> "manual.org" was updated a month ago, and, so far, nobody complained
> about it. So, I think it's a good time to discuss about what could be
> done next.
Is the current contrib/orgmanual.org in sync with doc/org.texi in both
master and maint?
How difficult
Hi Glenn,
Glenn Morris writes:
> Maybe I'm worried about nothing, but I do suggest asking on emacs-devel.
Thanks for your feedback.
You are definitely not worried about nothing. I share some of your
worries.
To speak the truth, I first thought migrating to org as the preferred
format for edi
I'm sure this is an impressive technical achievement, but can I urge you
to raise this on emacs-devel first, because I think it's potentially
problematic.
I'm not entirely sure what you are proposing here. If the .org version
will become the "preferred form" for modification, it would eg need to
Le sam. 03 mars 2018 à 04:57:33 , Bastien Guerry a envoyé
ce message:
> The rationale for using org.org (which, I agree, sounds a bit
> childish) is that this is the current convention for naming GNU
> manual is [package-name].[extension].
>
> See emacs.texi, gnus.texi, calc.texi, etc.
>
> If usi
Hi Nicolas,
Nicolas Goaziou writes:
> I don't understand this part. Currently, "manual.org" is exported as
> "org.texi" per
>
> #+export_file_name: org.texi
>
> So we are getting the best of both worlds. Am I missing something?
No, I was missing the "#+export_file_name: org.texi" part.
>> Or
Hello,
Bastien Guerry writes:
> Nothing, please move ahead.
Great.
> I suggest to rename the file org.org, which will produce org.texi.
I don't understand this part. Currently, "manual.org" is exported as
"org.texi" per
#+export_file_name: org.texi
So we are getting the best of both world
Hi Nicolas,
Nicolas Goaziou writes:
> I'm bumping the thread. What is still needed for that to move
> forward?
Nothing, please move ahead.
I suggest to rename the file org.org, which will produce org.texi.
Or org-manual.org, which seems more readable.
It would be great to have org-guide.org
Hello,
Bastien Guerry writes:
> To be continued,
I'm bumping the thread. What is still needed for that to move forward?
Again, the first step could be to move manual.org to core and have it
generate a new org.texi, overwriting the previous one.
I would also be nice to think about what can be d
Hi,
On Sun, Feb 4, 2018 at 6:40 PM, Nicolas Goaziou wrote:
> Yasushi SHOJI writes:
>
>> Hmm... I'm using 4b2006db3d04, which includes b4cc12fc32a771 but
>> it still inf-loops. `key-binding` returns `fill-paragraph`. I tried
>> it `toggle-fill-unfill`,
>> which I set to `M-q` in general, and `o
Hello,
Yasushi SHOJI writes:
> Hmm... I'm using 4b2006db3d04, which includes b4cc12fc32a771 but
> it still inf-loops. `key-binding` returns `fill-paragraph`. I tried
> it `toggle-fill-unfill`,
> which I set to `M-q` in general, and `org-fill-paragraph`, but nothing
> works here.
>
> I see that
Hello,
Yasushi SHOJI writes:
> I mean, I run `emacs -q`,
> eval only the following code in the `*scratch*` buffer,
> open `manual.org` and do `M-x org-reformat`.
>
> and I see:
>
> >8 >8
> @@ -134,9 +133,9 @@
> You can clone Org's repository and install Org like this:
>
> #+begi
Hi,
On Thu, Feb 1, 2018 at 11:55 PM, Nicolas Goaziou wrote:
> Yasushi SHOJI writes:
>
>> What if _I_, for my own project, want to customize the formatter and like to
>> call fill-paragraph, can I still do this?
>
> No need to tweak the formatter. You can post-process its output to your
> liking,
Hello,
Yasushi SHOJI writes:
> What if _I_, for my own project, want to customize the formatter and like to
> call fill-paragraph, can I still do this?
No need to tweak the formatter. You can post-process its output to your
liking, e.g., with `org-fill-paragraph' called on the whole buffer.
>
On Thu, Feb 1, 2018 at 8:43 PM, Yasushi SHOJI wrote:
> On Mon, Jan 29, 2018 at 11:41 PM, Nicolas Goaziou
> wrote:
>> Yasushi SHOJI 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 mean, I run `emacs
Hi,
On Mon, Jan 29, 2018 at 11:41 PM, Nicolas Goaziou
wrote:
> Yasushi SHOJI 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.
>>
Hello,
Yasushi SHOJI writes:
> Do you see this on your env? Or, is it just me?
I don't see anything like 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 i
Hi,
On Mon, Jan 29, 2018 at 12:17 AM, Nicolas Goaziou
wrote:
> Yasushi SHOJI writes:
>
>> A big one seems to be the indentation of description lists.
>> The formatter seems to prefer aligning the begging of a description
>> to the begging of a term. But manual.org has some indentation.
>
> Some
Hello,
Yasushi SHOJI writes:
> A big one seems to be the indentation of description lists.
> The formatter seems to prefer aligning the begging of a description
> to the begging of a term. But manual.org has some indentation.
Somewhat fixed. The indentation of description items is weird.
> Th
Hi Nicolas,
On Fri, Jan 26, 2018 at 7:32 PM, Nicolas Goaziou wrote:
> Yasushi SHOJI writes:
>
>> Also, the code converts all lower case "#+title", "+begin_src" and
>> other "#+"s to
>> the UPCASE. Is this intended? I thought we are moving away from CAP
>> to lower?
>
> This was changed a few
Hello,
Yasushi SHOJI writes:
> Also, the code converts all lower case "#+title", "+begin_src" and
> other "#+"s to
> the UPCASE. Is this intended? I thought we are moving away from CAP
> to lower?
This was changed a few days ago. See commit
13424336a6f30c50952d291e7a82906c1210daf0.
Regards,
Hi Nicolas,
On Wed, Jan 24, 2018 at 8:28 PM, Nicolas Goaziou wrote:
> Org Lint is not a formatter. It detects common mistakes or hypothetical
> mistakes in an Org document, e.g., invalid links. In particular, it
> doesn't detect stylistic issues like those discussed above.
Oh, OK.
> It doesn't
Hello,
Yasushi SHOJI writes:
> How about using org-lint or some other formatter on git commit hook?
> after go lang introduced gofmt, many projects adapted the method to
> keep the code constant.
Org Lint is not a formatter. It detects common mistakes or hypothetical
mistakes in an Org document
Hi,
On Mon, Jan 22, 2018 at 10:54 PM, Rasmus wrote:
> Bastien Guerry writes:
>
>> I'm all for editing manual.org instead of org.texi in the long run.
>>
>> Before moving manual.org into doc/, I'd suggest we agree on editing
>> variables like `fill-column' and the like:
>>
>> fill-column: 70
>> o
i will leave style decisions to the bike shed manufacturer [those who
do the work]. but i will opine anyway. i'm with the no indentation
people. [except -- not implemented -- plain lists indented by 2. :]]
but my reason for posting is that as a default for org, i think (setq
org-src-preserve-i
Aloha all,
Nicolas Goaziou writes:
Note that I made a few design choices I didn't write about,
e.g.,:
- use fixed-width area for one-line examples,
- use example blocks for Org syntax instead of "begin_src
org",
- internal links to headlines always start with a star,
- tags, nod
On Tue, Jan 23, 2018 at 11:33 AM Nicolas Goaziou
wrote:
>
> If `org-src-fontify-natively' is non-nil, contents of source blocks is
> not shown verbatim. In this particular case, contents are displayed as
> in an Org buffer, which means links are partly invisible.
>
Thanks. That makes sense. It's
Hello,
Kaushal Modi writes:
> On Mon, Jan 22, 2018 at 2:52 PM Nicolas Goaziou
> wrote:
>
>> There is another issue with "begin_src org" blocks. If your example
>> contains a link, you only see the description part, not the whole
>> syntax. Thus
>>
>> #+begin_src org
>> [[path][descrip
Am 23.01.2018 um 16:19 schrieb Kaushal Modi:
> There is another issue with "begin_src org" blocks. If your example
> contains a link, you only see the description part, not the whole
> syntax. Thus
>
> #+begin_src org
> [[path][description]]
> #+end_src
>
>
On Mon, Jan 22, 2018 at 2:52 PM Nicolas Goaziou
wrote:
> Kaushal Modi writes:
>
> There is another issue with "begin_src org" blocks. If your example
> contains a link, you only see the description part, not the whole
> syntax. Thus
>
> #+begin_src org
> [[path][description]]
> #
Bastien Guerry writes:
> Hi Nicolas,
>
>> "manual.org" was updated a month ago, and, so far, nobody complained
>> about it. So, I think it's a good time to discuss about what could be
>> done next.
>
> Having the manual in .org is a great achievement, congrats to anyone
> who worked on this titan
Kaushal Modi writes:
> Thank you. I'd like to see Org snippets in src blocks as they are not any
> "raw" monospace text blocks. But if no one else has a strong opinion for
> using src blocks for Org snippets, then I guess I'll have to concede.
There is another issue with "begin_src org" blocks.
Bastien Guerry writes:
>> Why do we need it? If it is mandatory (I fail to see why, since we
>> provide the source of the info file), can we include it read-only?
>
> It is mandatory, as long as the GNU standard for documentation is to
> provide it as a .texi file.
It can always be generated for t
On Mon, Jan 22, 2018 at 12:20 PM Nicolas Goaziou
wrote:
>
> Again, Org manual, as published in "orgmode.org", is generated through
> Texinfo, which treats "begin_src org" exactly as "begin_example". So,
> switching to "begin_src org" will not give us Org fontification in HTML
> output.
>
Ah, OK.
Kaushal Modi writes:
> I am hoping that using "begin_src org" preserves the meta data that a code
> block is an Org snippet when the Org manual HTML pages are published on
> orgmode.org.
Again, Org manual, as published in "orgmode.org", is generated through
Texinfo, which treats "begin_src org"
Aloha Bastien,
Bastien Guerry writes:
Hi Nicolas,
"manual.org" was updated a month ago, and, so far, nobody
complained
about it. So, I think it's a good time to discuss about what
could be
done next.
Having the manual in .org is a great achievement, congrats to
anyone
who worked on this
On Mon, Jan 22, 2018 at 11:02 AM Nicolas Goaziou
wrote:
> "manual.org" is not meant to be exported to HTML through "ox-html", but
> using Texinfo itself. AFAIK, Texinfo does not highlight specially Org
> syntax, so using "begin_src org" is not very important for export.
>
I am hoping that using
Bastien Guerry writes:
> I've added (org-list-description-max-indent . 5)
OK.
> Me too, for the same argument. But this points to a strong limitation
> to `org-adapt-indentation' for which I'd like to propose this change.
>
>(setq org-adapt-indentation t) => current behavior
> (se
On Mon, Jan 22, 2018 at 11:35 AM Bastien Guerry wrote:
> what do you think of the proposal to have
>
> (setq org-adapt-indentation 'content)
>
> set :PROPERTIES: aligned with the beginning of the headline,
> while leaving content unindented?
>
> I'd also like to have the better of both worlds w
Kaushal Modi writes:
> - use example blocks for Org syntax instead of "begin_src org",
>
>
> I'd prefer "begin_src org". When these manuals are converted to HTML,
> we can use syntax highlighting to format comments, etc in Org
> snippets. I think it's good to retain the meta data that that
Hi Kaushal,
Kaushal Modi writes:
> I have always started PROPERTIES at col 0. With org-indent-mode
> enabled, it doesn't matter.. looks pretty (PROPERTY drawer in below
> screenshot actually starts at col 0):
what do you think of the proposal to have
(setq org-adapt-indentation 'content)
se
Hi Nicolas,
thanks for your answer.
Nicolas Goaziou writes:
>> fill-column: 70
>
> This is already the case.
Okay, I've found .dir-locals.el.
>> org-list-description-max-indent: 5
>> org-edit-src-content-indentation: ?
>
> It is 2. I'd favor 0, but I don't care much.
I've added (org-list-des
Hello,
Kaushal Modi writes:
> I'd prefer "begin_src org". When these manuals are converted to HTML, we
> can use syntax highlighting to format comments, etc in Org snippets. I
> think it's good to retain the meta data that that is not an arbitrary block
> of text, but Org data. Can you please re
On Mon, Jan 22, 2018 at 8:51 AM Nicolas Goaziou
wrote:
> > org-edit-src-content-indentation: ?
>
> It is 2. I'd favor 0, but I don't care much.
>
I also favor 0, less white space noise, the better.
> > This is necessary so that contributors don't mess up accidentally with
> > the desired forma
On Mon, Jan 22, 2018 at 8:56 AM Rasmus wrote:
>
> Could we use .dir-locals.el to ensure that the correct settings are
> loaded?
>
+1
As for their values, I have no strong preferences, but I’d prefer settings
> are either automatically loaded or that they are like the default settings
> so that
Bastien Guerry writes:
> I'm all for editing manual.org instead of org.texi in the long run.
>
> Before moving manual.org into doc/, I'd suggest we agree on editing
> variables like `fill-column' and the like:
>
> fill-column: 70
> org-list-description-max-indent: 5
> org-edit-src-content-indenta
Hello,
Bastien Guerry writes:
> Before moving manual.org into doc/, I'd suggest we agree on editing
> variables like `fill-column' and the like:
>
> fill-column: 70
This is already the case.
> org-list-description-max-indent: 5
> org-edit-src-content-indentation: ?
It is 2. I'd favor 0, but I
Hi Nicolas,
> "manual.org" was updated a month ago, and, so far, nobody complained
> about it. So, I think it's a good time to discuss about what could be
> done next.
Having the manual in .org is a great achievement, congrats to anyone
who worked on this titanic task!
I'm all for editing manual
Achim Gratz writes:
> Nicolas Goaziou writes:
>> Actually, I have another idea. We could implement a function generating
>> the manual, right in Org core. It can be useful for both packaging, like
>> the above, and for developers, who can update the manual on the fly.
>
> That should go into mk/o
Nicolas Goaziou writes:
> Actually, I have another idea. We could implement a function generating
> the manual, right in Org core. It can be useful for both packaging, like
> the above, and for developers, who can update the manual on the fly.
That should go into mk/org-fixup.el then. I am not aw
Hello,
Achim Gratz writes:
Thank you for your answer. Some comments follow.
> The lack of complaints is unlikely to mean that everybody tried it and
> found nothing to complain about.
I didn't imply anything like that.
> The export to texi is still relatively slow,
I don't think it is much o
Nicolas Goaziou writes:
Hello,
"manual.org" was updated a month ago, and, so far, nobody
complained
about it. So, I think it's a good time to discuss about what
could be
done next.
The first obvious step is to move the file into "doc/"
directory. Then
I assume we could delete "org.texi" a
Nicolas Goaziou writes:
> "manual.org" was updated a month ago, and, so far, nobody complained
> about it. So, I think it's a good time to discuss about what could be
> done next.
The lack of complaints is unlikely to mean that everybody tried it and
found nothing to complain about. I haven't had
Hello,
"manual.org" was updated a month ago, and, so far, nobody complained
about it. So, I think it's a good time to discuss about what could be
done next.
The first obvious step is to move the file into "doc/" directory. Then
I assume we could delete "org.texi" and "org.info" there and generate
75 matches
Mail list logo
