[O] properties using other properties

[cpb]

Is there a way to set properties using other properties?  Doesn't matter
if its on export only, though it would be nice to have it in-situ.

here's an example (obviously doesn't work), where a project properties
for the project client only needs the CLIENT property filled, the rest
of it automatically populates on export.  Would save having to duplicate
the data where there are a lot of projects.


* client1
:PROPERTIES:
:CUSTOM_ID:client1
:NAME: a client
:ADDRESS:  an address
:EMAIL:an email
:URL:  a website
:END:

* project1
:PROPERTIES:
:CUSTOM_ID:project1
:NAME: a project
:CLIENT:   client1
:CLIENT_NAME:  {{{property(NAME,#{{{property(CLIENT)}}})}}}
:CLIENT_ADDRESS:   {{{property(ADDRESS,#{{{property(CLIENT)}}})}}}
:CLIENT_EMAIL: {{{property(EMAIL,#{{{property(CLIENT)}}})}}}
:EXPORT_FILE_NAME: ./a_project
:END:

project: {{{property(NAME)}}}
for: {{{property(CLIENT)}}}
 {{{property(CLIENT_ADDRESS)}}}
 {{{property(CLIENT_EMAIL)}}}

Re: [O] change in calling remote code blocks?

[numbch...@gmail.com]

I agree. use `file::name` is better.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Tue, Jan 23, 2018 at 3:24 AM, Nicolas Goaziou 
wrote:

> Nicolas Goaziou  writes:
>
> > Fixed. Thank you. I also updated documentation and added tests.
>
> As a side note, file:name syntax is a bit weak. It prevents using colons
> in a name, as reported by the linter. I don't know if the feature is
> used extensively but it may be worth considering changing references
> syntax to, e.g, "file::name".
>
>

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

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. If your example
contains a link, you only see the description part, not the whole
syntax. Thus

#+begin_src org
  [[path][description]]
#+end_src

is seen as

#+begin_src org
  description
#+end_src

which can be very confusing. There is no such issue with example blocks
and fixed-width areas.

Re: [O] change in calling remote code blocks?

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> Fixed. Thank you. I also updated documentation and added tests.

As a side note, file:name syntax is a bit weak. It prevents using colons
in a name, as reported by the linter. I don't know if the feature is
used extensively but it may be worth considering changing references
syntax to, e.g, "file::name".

Re: [O] [RFC] Moving "manual.org" into core

[Achim Gratz]

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 the Emacs export.  But it should cease to
exist in the Git repo since it becomes a derivative of manual.org.

> I don't think providing it read-only is a good idea: people should be
> able to edit it and provide patches against it, even though we prefer
> to encourage patches against manual.org.

No, I'd strongly discourage that and accept such edits only in
exceptional cases.  If the source file is manual.org, all patches or
other changes need to be against the source.  You wouldn't accept
patches to the PDF of the manual or any such thing, do you?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [O] change in calling remote code blocks?

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> I don't recall how I learned about that, I guess maybe in some library of
> babel documentation somewhere. I confirmed it does work in 8.2.10, e.g.
> just with emacs -Q.
>
> There are a few changes in org 9 to org-babel-lob-execute-maybe
> and org-babel-lob-get-info that seem to be the root cause of the change.
> Notably, org-babel-lob-get-info now returns nil where it used to return the
> "path" to the file and block.
>
> So, if I put this into an org file
>
> (progn
>  (re-search-forward "call")
>  (message "%s" (org-babel-lob-get-info)))   ;<- execute here
>
> #+call: remote-call.org:test-block()
>
> These get returned
>
> In 8.2.10: "(remote-call.org:test-block() nil 0 nil)"
> In 9.1.6: "nil"
>
> I am not sure what all the differences are, but it seems to be where the
> change in behavior came from.

Fixed. Thank you. I also updated documentation and added tests.

Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Moving "manual.org" into core

[Kaushal Modi]

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. Understood now. I didn't know that.. would have been nice if that
meta data was somehow retained.


> This is not about typing. When the markup is more visible than the
> contents, it is visual clutter.
>

OK.

It is a matter of taste. I tested both when updating the manual, and
> eventually settled for example blocks.
>
> In any case, I have no strong opinion about it. I just lean towards
> simplicity.
>

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.

> While pasting that example, I realized, that you don't even need to
> > specially made an Org snippet an src block just because you want to use
> it
> > as a noweb ref in the manual. Making Org snippets, src blocks, always,
> just
> > feels like the right thing.
>
> I didn't understand this part.
>

AFAIK noweb-ref can be used only for src blocks. So in the case you need to
use Org snippets as noweb refs, you would then need to make those Org
snippets src blocks instead of example blocks. I was just trying to make
that point.

Overall, I am glad to see consistency edits being made in the manual.. will
make it easier to contribute to it by just following by example.

Thanks.


-- 

Kaushal Modi

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

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" exactly as "begin_example". So,
switching to "begin_src org" will not give us Org fontification in HTML
output.

> Moreover, the advantage of using "begin_example" instead is:
>> 1. we can use fixed-width for one-liners,
>>
>
> I personally don't see that as a big advantage. Whether the snippet is a
> single line or more, one can just select those and use the Org structural
> template insertion to wrap that with "#+begin_src org" .. "#+end_src".

This is not about typing. When the markup is more visible than the
contents, it is visual clutter.

>> 2. Org fontification for source blocks can be sometimes misleading,
>>as you sometimes cannot what is an example and what is not.

> I didn't understand that limitation. I use Org src blocks quite liberally
> in this Org document[1], some even with nested non-Org src blocks.
>
> #+BEGIN_SRC org :noweb-ref src-block-n-default-continue
> ,#+BEGIN_SRC emacs-lisp +n
> ;; This will be listed as line 22
> (message "This is line 23")
> ,#+END_SRC
> #+END_SRC
>
> I haven't found any issue.

It is a matter of taste. I tested both when updating the manual, and
eventually settled for example blocks.

In any case, I have no strong opinion about it. I just lean towards
simplicity.

> While pasting that example, I realized, that you don't even need to
> specially made an Org snippet an src block just because you want to use it
> as a noweb ref in the manual. Making Org snippets, src blocks, always, just
> feels like the right thing.

I didn't understand this part.

Re: [O] [RFC] Moving "manual.org" into core

[Thomas S. Dye]

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 titanic task!

I'm all for editing manual.org instead of org.texi in the long 
run.


This is wonderful news.  Thank you!

All the best,
Tom

--
Thomas S. Dye
http://www.tsdye.com

Re: [O] [RFC] Moving "manual.org" into core

[Kaushal Modi]

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 "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.

Moreover, the advantage of using "begin_example" instead is:
> 1. we can use fixed-width for one-liners,
>

I personally don't see that as a big advantage. Whether the snippet is a
single line or more, one can just select those and use the Org structural
template insertion to wrap that with "#+begin_src org" .. "#+end_src".


> 2. Org fontification for source blocks can be sometimes misleading,
>as you sometimes cannot what is an example and what is not.
>

I didn't understand that limitation. I use Org src blocks quite liberally
in this Org document[1], some even with nested non-Org src blocks.

#+BEGIN_SRC org :noweb-ref src-block-n-default-continue
,#+BEGIN_SRC emacs-lisp +n
;; This will be listed as line 22
(message "This is line 23")
,#+END_SRC
#+END_SRC

I haven't found any issue.

While pasting that example, I realized, that you don't even need to
specially made an Org snippet an src block just because you want to use it
as a noweb ref in the manual. Making Org snippets, src blocks, always, just
feels like the right thing.

[1]:
https://raw.githubusercontent.com/kaushalmodi/ox-hugo/master/test/site/content-org/all-posts.org


-- 

Kaushal Modi

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

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
>  (setq org-adapt-indentation nil) => current behavior
> (setq org-adapt-indentation 'content) => only adapt content's
>  indentation, not that of the property drawer.

I proposed this very change some years ago, but it didn't get much
traction and wasn't implemented in the end.

>>> - Line 1013: Why an orphan dash?  Because of #+vindex entries?
>>
>> Yes.
>
> This is definitely a corner-case, but can we imagine another way of
> adding #+vindex entries here?

You can add the #+vindex entries at the end of the paragraph instead of
its beginning. However, cross references then point to the end of the
paragraph. I think the current state is better.

> I was noticing different styles, just wondering if there was a
> favorite one, as contributors may ask themselves.

Tag alone on its line is the favorite one because you cannot always
achieve the other option, i.e., contents on the same line as the tag.

> An "electric" display would also be good IMO.

Not sure what you mean here.

> It is mandatory, as long as the GNU standard for documentation is to
> provide it as a .texi file.

Too bad.

> I don't think providing it read-only is a good idea: people should be
> able to edit it and provide patches against it, even though we prefer
> to encourage patches against manual.org.

Is it really a bad idea to discourage people from editing an
auto-generated file? In any case, I have no strong opinion about this.

>>   - internal links to headlines always start with a star,
>
> No problem.  Is the leading star optional?

Of course. Without it, however, the internal link tries to match
a #+name keyword or a target first.

>>   - tags, node properties, are not shown with the surrounding columns,
>>   - when to use =...= or ~...~ markup: 
>> - files or extensions use =...=,
>> - anything that is meant to be written in the Org buffer uses =...=,
>> - any meaningful token in a programming language uses ~...~.
>>
>> I used {{{var(...)}}} for meta-syntactic names, but we may simply use
>> capitals instead, depending on the output of HTML export. It doesn't
>> change anything in Info format.
>
> I guess the above should be part of a guideline on how to contribute
> to manual.org

Probably, but this is not important as long as manual.org has not moved
to core, IMO.

> - which btw should better be named org.org.

Why is that? "manual.org" is a lot more explicit. What is better in
"org.org"? Note that "manual.org" already exports to "org.texi".

Re: [O] [RFC] Moving "manual.org" into core

[Kaushal Modi]

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 without the
> need to use `org-indent-mode'.
>

I cannot draw an opinion on that, as I have used org-indent-mode for many
years.. it "just works".

With the default value of org-indent-mode-turns-off-org-adapt-indentation
being non-nil, org-adapt-indention is auto-set to nil with org-indent-mode
enabled. So for all my use cases, org-adapt-indentation has always been nil
(which I learn today :) ).

In summary, I prefer to have no indentation anywhere (PROPERTIES, content,
src blocks (I set org-edit-src-content-indentation to 0 in my config.. I
never understood why the 2-space indentation was there by default))..
org-indent-mode simply takes care of everything.


-- 

Kaushal Modi

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

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 is not
> an arbitrary block of text, but Org data. Can you please revert to
> "begin_src org"?

I agree this makes sense.

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

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)

set :PROPERTIES: aligned with the beginning of the headline,
while leaving content unindented?

I'd also like to have the better of both worlds without the
need to use `org-indent-mode'.

Thanks for your feedback!

-- 
 Bastien

Re: [O] do you need a separate LaTeX installation to export org mode files to pdf?

[Rasmus]

Christopher W Ryan  writes:

> I'm a longtime LaTeX user and a more recent org mode user. So I've always
> had LaTeX installed on any computer on which I was using org mode. I'd like
> to introduce org mode to a co-worker unfamiliar with the whole concept of
> plain text files, markup, and literate programming, etc.  Would they need
> to install LaTeX too, or is org mode self-contained and able to export to
> pdf without LaTeX an friends installed?

You /could/ use latexonline.  I think it even supports bibtex.

https://github.com/aslushnikov/latex-online

Here’s a minimal example.

* TODO headline
 *bf* /emph/ etc.

 | a |


 #+begin_src emacs-lisp
   (let ((str (mapconcat 'identity
 '("tar -cj %f" "|"
   "curl -L --post301 --post302 --post303 -F file=@-"
   "\"https://latexonline.cc/data?command=%latex=%f\";
   "> %b.pdf")
 '" ")))
 (setq org-latex-pdf-process (list str)))
 #+end_src

How to include all document dependencies (e.g. images) in the tar file is
left as an exercise for the motivated reader.  One could probably make a
"dumb" but effective solution by finding all instances of certain file
types in the project folder.

Needless to say, if you use this with real-life documents, you will
probably want to set up your own instance of latexonline.

Rasmus

-- 
There are known knowns; there are things we know that we know

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

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-description-max-indent . 5)

>> org-src-preserve-indentation: ?
>
> nil.

OK.

>> This is necessary so that contributors don't mess up accidentally with
>> the desired format.
>
> Why does it matter? We just put them in ".dir-locals.el" and be done
> with it. They override user's preferences anyway.

I meant: it matters to have .dir-locals.el, so we're all set.

>> Can we grow a list here:
>> https://bimestriel.framapad.org/p/22KTn231su
>>
>> Also, why are :PROPERTIES: drawers at the beginning of the line?
>
> I set `org-adapt-indentation' to nil in the file above. It gives more
> columns in a line, which I find more comfortable (e.g., text always
> starts at the same column).

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
 (setq org-adapt-indentation nil) => current behavior
(setq org-adapt-indentation 'content) => only adapt content's
 indentation, not that of the property drawer.

Having the property drawer at the beginning of the line while all
other metadata (e.g. SCHEDULED etc.) are aligned with the beginning
of the headline's content feels wrong.

Would anyone else use (setq org-adapt-indentation 'content) ?

>> - Line 1013: Why an orphan dash?  Because of #+vindex entries?
>
> Yes.

This is definitely a corner-case, but can we imagine another way of
adding #+vindex entries here?

>> - Line 1077: Why indenting this list ?
>
> Fixed. Note that it didn't change output.

Thanks.  Noted.

>> - It would be nice to have #+[kvc]index with multiple entries per
>> line.
>
> I'm not sure I'd like it. The current state eases reviewing all index
> entries associated to a location.

Not that important anyway.

>> - Line 1303 : Why "- =[fn:NAME]= ::" lives on a single line here?
>
> It is on a single line like almost every item definition in the file. Am
> I missing something?

I was noticing different styles, just wondering if there was a
favorite one, as contributors may ask themselves.

>> - Line 21228 ("possible, including the version"): a macro spanning
>>   over multiple lines is not fontified.
>
> This is a fontification bug, unrelated to "manual.org". I suggest to
> discuss about it in another thread.

Sure.

>> - Footnotes: it would be nice to get an overview of a footnote when
>>   the pointer is hovering on some [fn:x] reference.
>
> You can use C-c ' on a footnote reference.

An "electric" display would also be good IMO.

>> We still need to create org.texi for inclusion into Emacs repository.
>
> 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.

I don't think providing it read-only is a good idea: people should be
able to edit it and provide patches against it, even though we prefer
to encourage patches against manual.org.

> Note that I made a few design choices I didn't write about, e.g.,:
>
>   - use fixed-width area for one-line examples,

Agreed.

>   - use example blocks for Org syntax instead of "begin_src org",

Agreed.

>   - internal links to headlines always start with a star,

No problem.  Is the leading star optional?

>   - tags, node properties, are not shown with the surrounding columns,
>   - when to use =...= or ~...~ markup: 
> - files or extensions use =...=,
> - anything that is meant to be written in the Org buffer uses =...=,
> - any meaningful token in a programming language uses ~...~.
>
> I used {{{var(...)}}} for meta-syntactic names, but we may simply use
> capitals instead, depending on the output of HTML export. It doesn't
> change anything in Info format.

I guess the above should be part of a guideline on how to contribute
to manual.org - which btw should better be named org.org.

To be continued,

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

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 revert to "begin_src org"?

"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.

Moreover, the advantage of using "begin_example" instead is:
1. we can use fixed-width for one-liners,
2. Org fontification for source blocks can be sometimes misleading,
   as you sometimes cannot what is an example and what is not.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] do you need a separate LaTeX installation to export org mode files to pdf?

[Oleh Krehel]

Hi all,

>> Would they need to install LaTeX too, or is org mode self-contained and
>> able to export to pdf without LaTeX an friends installed?
>
>
> Yes, they'd need to have a LaTeX distribution installed on their system. In
> my experience, installing the full latest version of TexLive is the easiest
> way.

For years, my approach was to install texlive-full. But that meant
blocking me for around 2 hours.

Recently, I threw together a minimal Dockerfile to enable org-to-pdf
export. Here's the gist of it:

FROM ubuntu:xenial
RUN apt update && apt install -y software-properties-common
RUN apt install -y texlive-latex-extra cm-super

I also install Emacs and some project specific stuff on top of it. In
the end, the built Docker image is only 2.19GB.
If you don't care for Docker, you can just install the above minimal
packages with sudo.

regards,
Oleh

Re: [O] do you need a separate LaTeX installation to export org mode files to pdf?

[Martin Alsinet]

Hello Christopher

I have a docker image with LaTeX installed in order not to "pollute" my
local filesystem with the 4GB of additional libraries a full LaTeX
installation requires.
If your co-worker is a software developer you could use that approach.

Here is mi Dockerfile for LaTeX:

FROM ubuntu:xenial
MAINTAINER Martin Alsinet 

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update -q
RUN apt-get install -y texlive-full gnuplot python-pygments
RUN apt-get clean
RUN rm -rf /var/lib/apt/lists/*

Save that in a file named *Dockerfile* in a blank folder and run *docker
build -t latex .*
This will create a docker image named latex with all the libraries and
executables neatly tucked away.
Then, in order to use it, you can save the following script in
~/bin/pdflatex

#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
docker run --rm \
   -v $(pwd):$(pwd) \
   -v ~/.ssh:/root/.ssh \
   -w $(pwd) \
   latex \
   pdflatex $@
rm *.log *.aux
rm -f *.ent
rm -Rf _minted-*

With that you can use the *pdflatex* command as usual, and docker creates a
temporary container (docker run --rm ...) from the image, runs the pdflatex
command and removes the container after execution.

bash-3.2$ pdflatex --version
pdfTeX 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian)
kpathsea version 6.2.1
Copyright 2015 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
Compiled with libpng 1.6.17; using libpng 1.6.17
Compiled with zlib 1.2.8; using zlib 1.2.8
Compiled with poppler version 0.41.0
rm: *.log: No such file or directory
rm: *.aux: No such file or directory



Martin


On Mon, Jan 22, 2018 at 10:23 AM Kaushal Modi 
wrote:

> On Mon, Jan 22, 2018 at 9:57 AM Christopher W Ryan 
> wrote:
>
>> Would they need to install LaTeX too, or is org mode self-contained and
>> able to export to pdf without LaTeX an friends installed?
>>
>
> Yes, they'd need to have a LaTeX distribution installed on their system.
> In my experience, installing the full latest version of TexLive is the
> easiest way.
>
>
> --
>
> Kaushal Modi
>

Re: [O] [RFC] Moving "manual.org" into core

[Kaushal Modi]

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 format.
>
> Why does it matter? We just put them in ".dir-locals.el" and be done
> with it. They override user's preferences anyway.
>

+1


> > Also, why are :PROPERTIES: drawers at the beginning of the line?
>
> I set `org-adapt-indentation' to nil in the file above. It gives more
> columns in a line, which I find more comfortable (e.g., text always
> starts at the same column).
>

Another place where we can prevent unnecessary white space.

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):

[image: image.png]


>   - 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 is not an arbitrary block
of text, but Org data. Can you please revert to "begin_src org"?


>   - internal links to headlines always start with a star,
>

Nice.

  - tags, node properties, are not shown with the surrounding columns,
>   - when to use =...= or ~...~ markup:
> - files or extensions use =...=,
> - anything that is meant to be written in the Org buffer uses =...=,
> - any meaningful token in a programming language uses ~...~.
>

Sounds good.


-- 

Kaushal Modi

Re: [O] [RFC] Moving "manual.org" into core

[Kaushal Modi]

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 one can just use "emacs -q".
>

+1


-- 

Kaushal Modi

Re: [O] do you need a separate LaTeX installation to export org mode files to pdf?

[Kaushal Modi]

On Mon, Jan 22, 2018 at 9:57 AM Christopher W Ryan 
wrote:

> Would they need to install LaTeX too, or is org mode self-contained and
> able to export to pdf without LaTeX an friends installed?
>

Yes, they'd need to have a LaTeX distribution installed on their system. In
my experience, installing the full latest version of TexLive is the easiest
way.


-- 

Kaushal Modi

[O] do you need a separate LaTeX installation to export org mode files to pdf?

[Christopher W Ryan]

I'm a longtime LaTeX user and a more recent org mode user. So I've always
had LaTeX installed on any computer on which I was using org mode. I'd like
to introduce org mode to a co-worker unfamiliar with the whole concept of
plain text files, markup, and literate programming, etc.  Would they need
to install LaTeX too, or is org mode self-contained and able to export to
pdf without LaTeX an friends installed?

Thanks.

--Chris Ryan

Re: [O] [RFC] Moving "manual.org" into core

[Rasmus]

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-indentation: ?
> org-src-preserve-indentation: ?
>
> This is necessary so that contributors don't mess up accidentally with
> the desired format.

Could we use .dir-locals.el to ensure that the correct settings are
loaded?

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 one can just use "emacs -q".

Rasmus

-- 
Not everything that goes around comes back around, you know

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

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 don't care much.

> org-src-preserve-indentation: ?

nil.

> This is necessary so that contributors don't mess up accidentally with
> the desired format.

Why does it matter? We just put them in ".dir-locals.el" and be done
with it. They override user's preferences anyway.

> Can we grow a list here:
> https://bimestriel.framapad.org/p/22KTn231su
>
> Also, why are :PROPERTIES: drawers at the beginning of the line?

I set `org-adapt-indentation' to nil in the file above. It gives more
columns in a line, which I find more comfortable (e.g., text always
starts at the same column).

> I have them aligned with the headline in my configuration, which
> I find much more readable. Can we fix this?

There is nothing to "fix": this is a configuration option, per above.

> IMO the above questions should be resolved before exposing manual.org
> to collaboration.
>
> Some other micro-reports/requests, not blocking anything:
>
> - Line 1013: Why an orphan dash?  Because of #+vindex entries?

Yes.

> - Line 1077: Why indenting this list ?

Fixed. Note that it didn't change output.

> - It would be nice to have #+[kvc]index with multiple entries per
> line.

I'm not sure I'd like it. The current state eases reviewing all index
entries associated to a location.

> - Line 1303 : Why "- =[fn:NAME]= ::" lives on a single line here?

It is on a single line like almost every item definition in the file. Am
I missing something?

> - Line 21228 ("possible, including the version"): a macro spanning
>   over multiple lines is not fontified.

This is a fontification bug, unrelated to "manual.org". I suggest to
discuss about it in another thread.

> - Footnotes: it would be nice to get an overview of a footnote when
>   the pointer is hovering on some [fn:x] reference.

You can use C-c ' on a footnote reference.

> We still need to create org.texi for inclusion into Emacs repository.

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?

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, node properties, are not shown with the surrounding columns,
  - when to use =...= or ~...~ markup: 
- files or extensions use =...=,
- anything that is meant to be written in the Org buffer uses =...=,
- any meaningful token in a programming language uses ~...~.

I used {{{var(...)}}} for meta-syntactic names, but we may simply use
capitals instead, depending on the output of HTML export. It doesn't
change anything in Info format.

Thank you for the review.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

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.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-indentation: ?
org-src-preserve-indentation: ?

This is necessary so that contributors don't mess up accidentally with
the desired format.

Can we grow a list here:
https://bimestriel.framapad.org/p/22KTn231su

Also, why are :PROPERTIES: drawers at the beginning of the line?  I
have them aligned with the headline in my configuration, which I find
much more readable. Can we fix this?

IMO the above questions should be resolved before exposing manual.org
to collaboration.

Some other micro-reports/requests, not blocking anything:

- Line 1013: Why an orphan dash?  Because of #+vindex entries?

- Line 1077: Why indenting this list ?

- It would be nice to have #+[kvc]index with multiple entries per line.

- Line 1303 : Why "- =[fn:NAME]= ::" lives on a single line here?

- Line 21228 ("possible, including the version"): a macro spanning
  over multiple lines is not fontified.

- Footnotes: it would be nice to get an overview of a footnote when
  the pointer is hovering on some [fn:x] reference.

> 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
> new ones from the Org file. For example, the following command, called
> from the "manual.org" file,
>
> (let ((org-texinfo-logfiles-extensions
>(cons "texi" org-texinfo-logfiles-extensions)))
>   (org-texinfo-export-to-info))
>
> produces an "org.info" file without an "org.texi". It thus prevents
> direct editing of "org.texi". I assume this could be called by "make
> info" target.

We still need to create org.texi for inclusion into Emacs repository.

> So basically, the idea would be to not provide anymore an "org.texi"
> file. Only "manual.org" and "org.info". Emacs developers already apply
> fixes to ORG-NEWS, which is a plain Org file, so I guess it would not
> make their life harder if "manual.org" replaces "org.texi".
>
> WDYT?

I think it's a great step forward but a big one, so let's move
carefully here.

Thanks!

-- 
 Bastien

[O] compatible issue between MELPA org and source code org

[numbch...@gmail.com]

Because some MELPA package requires `org`. So Emacs will **force** install
`org` package from MELPA. But it is delay with source code Org.
I use source code org with use-package like this:
```
(use-package org
  :load-path "~/Code/Emacs/org-mode/lisp/"
  :pin manual
  ;; :mode (("\\.org$" . org-mode))
  :config
  (use-package org-plus-contrib
:load-path "~/Code/Emacs/org-mode/contrib/lisp/"
:no-require t
:pin manual)
  )
```
But Emacs still will load MELPA org with `(package-initialize)`.
In currently latest MELPA org package. It defines
`org-structure-template-alist` Like this:
```
(defcustom org-structure-template-alist
  '(("s" "#+BEGIN_SRC ?\n\n#+END_SRC")
("e" "#+BEGIN_EXAMPLE\n?\n#+END_EXAMPLE")
("q" "#+BEGIN_QUOTE\n?\n#+END_QUOTE")
("v" "#+BEGIN_VERSE\n?\n#+END_VERSE")
("V" "#+BEGIN_VERBATIM\n?\n#+END_VERBATIM")
("c" "#+BEGIN_CENTER\n?\n#+END_CENTER")
("C" "#+BEGIN_COMMENT\n?\n#+END_COMMENT")
("l" "#+BEGIN_EXPORT latex\n?\n#+END_EXPORT")
("L" "#+LaTeX: ")
("h" "#+BEGIN_EXPORT html\n?\n#+END_EXPORT")
("H" "#+HTML: ")
("a" "#+BEGIN_EXPORT ascii\n?\n#+END_EXPORT")
("A" "#+ASCII: ")
("i" "#+INDEX: ?")
("I" "#+INCLUDE: %file ?"))
  "Structure completion elements.
This is a list of abbreviation keys and values.  The value gets inserted
if you type `<' followed by the key and then press the completion key,
usually `TAB'.  %file will be replaced by a file name after prompting
for the file using completion.  The cursor will be placed at the position
of the `?' in the template.
There are two templates for each key, the first uses the original Org
syntax,
the second uses Emacs Muse-like syntax tags.  These Muse-like tags become
the default when the /org-mtags.el/ module has been loaded.  See also the
variable `org-mtags-prefer-muse-templates'."
  :group 'org-edit-structure
  :type '(repeat
  (list
   (string :tag "Key")
   (string :tag "Template")))
  :version "26.1"
  :package-version '(Org . "8.3"))
```
But in source code `master` branch. It is updated to use new templates.
So after Emacs finished launching.
It becomes like this:
```
 (("Q" "#+BEGIN_SRC sql-mode ?

 ,#+END_SRC" "#+BEGIN_SRC sql-mode ?

 ,#+END_SRC")
  ("n" "#+BEGIN_NOTES
 ?
 ,#+END_NOTES")
  (116 . "translate")
  ("s" "#+BEGIN_SRC ?

 ,#+END_SRC")
  ("e" "#+BEGIN_EXAMPLE
 ?
 ,#+END_EXAMPLE")
  ("q" "#+BEGIN_QUOTE
 ?
 ,#+END_QUOTE")
  ("v" "#+BEGIN_VERSE
 ?
 ,#+END_VERSE")
  ("V" "#+BEGIN_VERBATIM
 ?
 ,#+END_VERBATIM")
  ("c" "#+BEGIN_CENTER
 ?
 ,#+END_CENTER")
  ("C" "#+BEGIN_COMMENT
 ?
 ,#+END_COMMENT")
  ("l" "#+BEGIN_EXPORT latex
 ?
 ,#+END_EXPORT")
  ("L" "#+LaTeX: ")
  ("h" "#+BEGIN_EXPORT html
 ?
 ,#+END_EXPORT")
  ("H" "#+HTML: ")
  ("a" "#+BEGIN_EXPORT ascii
 ?
 ,#+END_EXPORT")
  ("A" "#+ASCII: ")
  ("i" "#+INDEX: ?")
  ("I" "#+INCLUDE: %file ?"))
 Original value was
 ((97 . "export ascii")
  (99 . "center")
  (67 . "comment")
  (101 . "example")
  (69 . "export")
  (104 . "export html")
  (108 . "export latex")
  (113 . "quote")
  (115 . "src")
  (118 . "verse"))
```

Does anybody have a perfect solution to use latest source code Org in Emacs
way? Please tell me thanks.
And question two: I don't know how to fix this issue. I think might org
should update MELPA org package? (I know package `org` updated recently)

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/