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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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?
>
>
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
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
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
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
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,
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
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
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
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
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
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
>
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
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.
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'
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
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
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
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
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
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
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
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
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
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
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
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,
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.
>
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
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
>
>
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
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
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
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
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,
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
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.
>
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
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
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
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
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.
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
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
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
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
>
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
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
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
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
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
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"
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
74 matches
Mail list logo