Re: [O] [SOLVED] How to use xml src block as data input?

[John Kitchin]

all things in emacs are elisp...

You can use this function:

#+BEGIN_SRC emacs-lisp
(defun get-xml (name)
  (save-excursion
(org-babel-goto-named-src-block name)
(org-element-property :value (org-element-context
#+END_SRC

#+RESULTS:
: get-xml

like this in a python (or other general lang) block to get the xml as a
string that you parse in the language:

#+BEGIN_SRC python :var data=(get-xml "xml-example")
import xml.etree.ElementTree as ET
root = ET.fromstring(data)
for child in root:
print(child.tag, child.attrib)
#+END_SRC

#+RESULTS:
: to {}
: from {}
: heading {}
: body {}

I don't know about noweb.

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Mon, Apr 30, 2018 at 8:36 PM, stardiviner  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Thanks, John and Simonyi. This is a solution on Elisp. Not general way.
> But as a intermedia step, really workable. I chose this method.
>
> BTW, is it possible to archived with noweb reference <> ?
> Like
>
> #+begin_src python :var data=<>
> ...
> #+end_src
>
> - --
> [ stardiviner ] don't need to convince with trends.
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrn4LYACgkQG13xyVro
> msP8ywf/VaaQkpFcV16/2NDRODkC+iNN6TCp1MRJjYL9qkppa/A8vRGPZSxIG5Sd
> d2TEGx+mqRS0EANM/mhJwAIlM5U9SpycBfzasvU7R+Cn9CiehZCnJKA0dBaZiu+q
> vPBifqEqOzY873XsaRS2Xty6W4NSrh8aL6hEWxiDJSafjaCxI2FvApg2JnPi6HoC
> /sy9eSuIYvG8vCRow9y8E/GFcWE5EXoB/d/mdcEmGz80sB39Tjp4PGvLMyglROMa
> sR+8QkUTQAtDP4uEAF7biHAGE2PcELpZVLjzWm0GfZkCdJF9tH8KrEXaorB+hyHn
> MWxzlZ/gSNcsROF7DHVaZgCMMiiXuw==
> =fImh
> -END PGP SIGNATURE-
>

Re: [O] [SOLVED] How to use xml src block as data input?

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thanks, John and Simonyi. This is a solution on Elisp. Not general way.
But as a intermedia step, really workable. I chose this method.

BTW, is it possible to archived with noweb reference <> ?
Like

#+begin_src python :var data=<>
...
#+end_src

- -- 
[ stardiviner ] don't need to convince with trends.
   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrn4LYACgkQG13xyVro
msP8ywf/VaaQkpFcV16/2NDRODkC+iNN6TCp1MRJjYL9qkppa/A8vRGPZSxIG5Sd
d2TEGx+mqRS0EANM/mhJwAIlM5U9SpycBfzasvU7R+Cn9CiehZCnJKA0dBaZiu+q
vPBifqEqOzY873XsaRS2Xty6W4NSrh8aL6hEWxiDJSafjaCxI2FvApg2JnPi6HoC
/sy9eSuIYvG8vCRow9y8E/GFcWE5EXoB/d/mdcEmGz80sB39Tjp4PGvLMyglROMa
sR+8QkUTQAtDP4uEAF7biHAGE2PcELpZVLjzWm0GfZkCdJF9tH8KrEXaorB+hyHn
MWxzlZ/gSNcsROF7DHVaZgCMMiiXuw==
=fImh
-END PGP SIGNATURE-

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-04-30 00:09 +02, Bastien  wrote:
> Hi Göktuğ,
>
> thanks for your patch.

You're welcome!

> Kayaalp  writes:
> Do you have other examples on local variables that would be useful to
> pass on when editing code in Org Src buffers?

Currently I only pass on lexical-binding and truncate-lines, and I do
not have another concrete example in my configuration (I do not use
source blocks for anything other than shell and elisp currently).  But I
have listed some hypothetical use cases further down.

> In general, instead of inheriting values from the Org's buffer, I'd
> allow users to set the values independantly -- for example, the cdr
> of elements in `org-babel-load-languages', instead of being `t' all
> the time (because nil makes no sense to me), could contain an alist
> of variables and their local values when editing and... executing.

This might be a better way indeed.  But this setting is then global,
i.e. one can't have the file A.org have lexical-binding on, but B.org
off (which might be necessary for say an older org file that depends on
lexical binding).

> This is: *if* we find cases that seem generic enough.
>
> What do you think?

One case I can think of is to set variables like fill-column when
editing inline LaTeX, HTML,  blocks, and also, those like
c-file-style, where say when writing a paper the author wants to use k
style, but when writing a literate source prefers gnu style.

Maybe a good way to achieve this would be to have the way you suggest to
set defaults for Babel, but allow to define such bindings also in
individual org mode files, either via the local variables or with a
specific #+keyword like:

#+edit_special_bindings: lexical-binding:t
# or
#+edit_special_bindings: c-file-style:gnu fill-column:80

which is better IMO because there is no need to declare separately which
variables to copy, and is more granular.  Also, in this case, a shortcut
syntax for inheriting the buffer local value of a variable can be
useful:

 x.org ===
# -*- fill-column: 65 -*-
#+edit_special_bindings: c-file-style:gnu fill-column*

This can be useful when one needs/wants to keep a consistent style in a
given file.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Steve Downey]

>>   For many existing users, restoring the old behaviour is just adding a
require to their setup, so it isn't a lot to ask.

Asking users to accept any breakage in the tool they use to get work done
is a lot. Changes in UI in emacs are opt-in.

Even if the change is the right thing to do.


On Mon, Apr 30, 2018 at 10:01 PM Tim Cross  wrote:

>
> On 1 May 2018 at 08:39, Jon Snader  wrote:
>
>>
>> Tim Cross  writes:
>>
>> [Snip]
>>>
>>> Personally, I feel the new version should be the default and we should
>>> provide an easy way to re-enable the old version for those who wish to
>>> continue with what they are use to.
>>>
>>
>> We already have this. The problem, as you say, is
>>
>> how we communicate this to existing users.
>>>
>>
>> But here's what I don't understand: what, exactly, is so bad about
>> leaving the old behavior enabled by default. The new behavior is still
>> available and naive users don't get surprised. What's not to like?
>>
>
> The problem is that if the old behaviour remains as the default, then that
> is what new users will be introduced to and the improved new functionality
> won't be seen. If the new behaviour is the default, there will be a small
> period of adjustment for existing users, but new users will be benefiting
> from the changes immediately.  For many existing users, restoring the old
> behaviour is just adding a require to their setup, so it isn't a lot to
> ask. (I believe there will be some power users with lots of custom blocks
> who may be more impacted, but as I understand it, whether the new or old
> functionality is enabled by default doesn't really change the situation for
> them anyway as they will have to take additional steps to migrate their
> custom block settings). The real issue isn't about changing the default as
> much as doing whatever is possible to inform existing users of the change
> and how to restore previous behaviour if desired.
>
> In the past, after an org upgrade, I have seen messages in the *Messages*
> buffer regarding inconsistent, incompatible changes and what action needs
> to be taken (I think this occurred when changes were made to TODO
> templates). Maybe something along these lines could also be done - maybe
> have a message displayed when someone tries to do a ' not have org-tempo loaded? Maybe this could be developed as something which
> could be used in the future when we make other changes.
>
> Along these same lines, maybe we need to consider adopting something
> similar to the Emacs obsolete/deprecated  approach. In this next release,
> add a message to org-tempo advising that this functionality will change in
> the next release where org-tempo will not be loaded by default. This could
> include a pointer to a web page explaining the change and associated
> benefits and how to make the switch now if desired. While this might delay
> the transition, it might address concerns regarding impact to existing
> users and new users will be aware of the alternative etc. It would be
> important to have a way to silence this message of course.
>
>
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Tim Cross]

On 1 May 2018 at 08:39, Jon Snader  wrote:

>
> Tim Cross  writes:
>
> [Snip]
>>
>> Personally, I feel the new version should be the default and we should
>> provide an easy way to re-enable the old version for those who wish to
>> continue with what they are use to.
>>
>
> We already have this. The problem, as you say, is
>
> how we communicate this to existing users.
>>
>
> But here's what I don't understand: what, exactly, is so bad about
> leaving the old behavior enabled by default. The new behavior is still
> available and naive users don't get surprised. What's not to like?
>

The problem is that if the old behaviour remains as the default, then that
is what new users will be introduced to and the improved new functionality
won't be seen. If the new behaviour is the default, there will be a small
period of adjustment for existing users, but new users will be benefiting
from the changes immediately.  For many existing users, restoring the old
behaviour is just adding a require to their setup, so it isn't a lot to
ask. (I believe there will be some power users with lots of custom blocks
who may be more impacted, but as I understand it, whether the new or old
functionality is enabled by default doesn't really change the situation for
them anyway as they will have to take additional steps to migrate their
custom block settings). The real issue isn't about changing the default as
much as doing whatever is possible to inform existing users of the change
and how to restore previous behaviour if desired.

In the past, after an org upgrade, I have seen messages in the *Messages*
buffer regarding inconsistent, incompatible changes and what action needs
to be taken (I think this occurred when changes were made to TODO
templates). Maybe something along these lines could also be done - maybe
have a message displayed when someone tries to do a '

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Alan Tyree]

I'm a non-technical user, and I've never used ysnippets, but I'm willing to
give it a go with some proper instruction.

I do see the argument of both sides.

Here is a question: I see specialised snippet packages in the ELPA
respositories. Is it possible to provide snippets that reproduce the
existing "Easy Templates", maybe even keep the same key bindings so that
the change is transparent to the users that are likely to have the troubles
referred to by Bastien?

It is a genuine question since I have no idea of the problems involved.

I'll keep using org no matter what you decide!

Cheers,
Alan


On 1 May 2018 at 08:49, Kaushal Modi  wrote:

> Hi all,
>
> I normally am all for adapting to changes, staying on bleeding edges of
> emacs, Org, etc.
>
> But FWIW, for this particular change to the " the camp of "It was working awesome, it was beautiful! Why change it?". For
> record, I understand the "why", but it just doesn't seem worth it in this
> case.
>
> But the good thing is that this is open source, and you can backport the
> stuff you like from the original Easy Template code into your personal
> Emacs config (and then later adapt to the new way of doing the similar when
> you have time and motivation).
>
> Kaushal
> --
>
> Kaushal Modi
>



-- 
Alan L Tyreehttp://www2.austlii.edu.au/~alan

Re: [O] Smart archiving of subtrees with parent headlines

[Mark Edgington]

Hi Bastien,

On Thu, Apr 26, 2018 at 7:34 PM, Bastien  wrote:

> I'd be interested in integrating such a functionality in
> org-archive.el.
>
> Do you think that is feasible?


I don't know why not -- I'm OK with the code being used in org-archive.el.
As far as I'm concerned, you can use it however you wish (it is based on
Ken's code though, so he would also need to sign off on its use, I suppose).

Regards,

Mark

Re: [O] Does :block field of clocktable respect org-extend-today-until?

[Robert Irelan]

I have a patch to fix this in https://github.com/telotortium/org-mode
(branch org-clock-table-extend-today-until-block). I've submitted a
copyright assignment with the FSF.

On Tue, Apr 17, 2018 at 5:54 AM Nicolas Goaziou 
wrote:

> Hello,

> Robert Irelan  writes:

> > Testing it just now, it appears that it doesn't - the clock table
excludes
> > times after midnight but before org-extend-today-until. I'll probably
work
> > on fixing this unless someone believes that the current version of
org-mode
> > is expected to respect org-extend-today-until. org-version gives:
> > Org mode version 9.1.9 (9.1.9-8-gf05c2e-elpaplus)

> As its docstring states:

>   IMPORTANT:  This is a feature whose implementation is and likely will
>   remain incomplete.

> IOW, nothing in Org is really expected to respect
> `org-extend-today-until'. Patches welcome, of course.

> Regards,

> --
> Nicolas Goaziou



--
Robert Irelan
rire...@gmail.com

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Kaushal Modi]

Hi all,

I normally am all for adapting to changes, staying on bleeding edges of
emacs, Org, etc.

But FWIW, for this particular change to the "

Re: [O] Moving from Jekyll to Orgmode

[Kaushal Modi]

Hi Diego,

On Mon, Apr 30, 2018 at 4:29 PM Diego Zamboni  wrote:

>
> ox-hugo takes a different approach: it uses org-mode’s ox-markdown
> exporter to produce Markdown from the org source, so that Hugo processes a
> Markdown file. This makes a big difference, as each tool is processing its
> own native format: org-mode processes org, and Hugo processes Markdown.
>

That's very well said :)


> Thanks to this, you can even include Hugo shortcodes (
> https://gohugo.io/content-management/shortcodes/) in your org-mode
> source, and they will be passed untouched to Hugo (this is not entirely
> advisable as it makes your source Hugo-specific, but it’s doable if you
> want it).
>

Correct. The aim of ox-hugo is to allow any Org document to be easily
exportable to Hugo, while also allowing the same document to be reusable
for other export formats too.

So I don't recommend embedding Hugo shortcodes directly in Org files (even
if they work.. not guaranteeing that such embedded Hugo shortcodes will
always work). But shortcodes are still supported, though in a different
style, leveraging the Org special blocks. That feature is yet undocumented.
But it is fully implemented, tested (and used by me). See
https://github.com/kaushalmodi/ox-hugo/issues/126 for more info.


> Another very nice ox-hugo feature is its “One post per Org subtree” mode (
> https://ox-hugo.scripter.co/#screenshot-one-post-per-subtree), in which
> you keep your entire post tree (in fact, you could keep your entire
> website) in a single Org file. I was skeptical about this at first (who
> wants to keep *everything* in a single file), but in practice it works very
> well, and allows you to have tags/categories or other attributes per
> subtree, so you don’t have to repeat them on every post.
>

That's the primary reason why I started working on ox-hugo. I couldn't bear
the manual labor of copy/pasting/syncing of front-matter across separate
Markdown files. I always suggest people to try the "per-subtree blogging
flow" because Org subtree structure, property and tag inheritance so much
reduce that manual effort. See here on how various properties and tags
translate to Hugo front-matter ->
https://ox-hugo.scripter.co/doc/org-meta-data-to-hugo-front-matter/#for-subtree-based-exports
.

I also have this little annotated diagram:
https://discourse-cdn-sjc2.com/standard12/uploads/gohugo/original/2X/8/8dd4af3e103c3a691a71356aa3f91bfe1019ebae.png


> If you really want to keep each post in a separate file, that is doable as
> well. The ox-hugo website has a lot of very useful information.
>
> Finally, you can do the transition gradually - for my website, I had years
> of accumulated Markdown files from my adventures with Jekyll, Octopress and
> later Hugo. Those are still in place, and I have started only putting my
> new posts in an org file which ox-hugo processes. Since those are converted
> to Markdown files, they end up alongside the old hand-crafted files, and
> Hugo just processes them all together.
>

That too! Looks like you hit all the awesome points :) My scripter.co site
source also contains of few dozen old Markdown posts. New stuff is written
in Org and exported to Markdown using ox-hugo which live right along the
old Markdown content... and everything just works.


> I really recommend ox-hugo, Kaushal has done a fantastic job and he is
> also really helpful and responsive with questions.
>

Thanks for this heavy recommendation. Working on this project and
supporting/making it more robust based on user feedback has been great
pleasure.

Tip: I learned a lot by reading the source files for
> https://ox-hugo.scripter.co/ and for https://scripter.co/, both of which
> are kept in ox-hugo structure. You can find pointers to those and some
> other examples (including my own websites, zzamboni.org and cf-learn.info)
> at https://ox-hugo.scripter.co/doc/examples/
>

Yes! The list of contributors on that Real World Examples page is growing
day by day.

And finally, some clarification about things mentioned in other parts of
this thread:

- Using Hugo does *not* require you to know the Go language. You just learn
the Go templating syntax. And that too, if you want to start by tweaking
and designing Hugo themes. You can always pick one of the 200+ Hugo themes,
and get your blog started, and then revisit writing your own theme at a
later time.
- It doesn't even require you to install the Go toolchain (though it's not
difficult, you just unzip an archive).
- "Installing" hugo is a matter of a single wget of the archive for the OS
of your choice from here: https://github.com/gohugoio/hugo/releases, and
then unarchiving that to somewhere in your PATH.

Apart of the binary-static-ness of the hugo static site generator, another
reason it appealed to me is that the Go templating syntax feels a bit
/lispy/. For example, I use this:

{{ $.Scratch.Set "__repo_updated_time" (index (index (index (index
$repo_json "commit") "commit") 

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Jon Snader]

Tim Cross  writes:


[Snip]

Personally, I feel the new version should be the default and we 
should
provide an easy way to re-enable the old version for those who 
wish to

continue with what they are use to.


We already have this. The problem, as you say, is


how we communicate this to existing users.


But here's what I don't understand: what, exactly, is so bad about
leaving the old behavior enabled by default. The new behavior is 
still

available and naive users don't get surprised. What's not to like?

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Cook, Malcolm]

If the poll is still open, I vote don’t change the default.

Unless I missed a prior good argument for changing it…

Or, unless, upon first invocation, org-mode guided you through or prompted you 
to changing your defaults, or at the very least, offered/insisted upon your 
reading ORG-NEWS.

Otherwise, I think Jon is spot on in his assessment of  “what’s going to 
happen” to many.


From: Emacs-orgmode  On Behalf 
Of Tim Cross
Sent: Monday, April 30, 2018 5:25 PM
To: Jon Snader 
Cc: Bastien ; Org-mode 
Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand 
templates thru e.g. "> 
wrote:

Richard Lawrence 
> writes:
Jon Snader > writes:
I use the 

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Tim Cross]

I don't think anyone disagrees that this change comes at a cost. Change is
very difficult and many people don't like change. The real question is how
do we manage this change to minimise the pain while moving org forward to
make it an even better solution.

Many seem to believe that what is being discussed here is a loss of
functionality. This isn't really the case. What we are talking about here
is a change, even an enhancement, of functionality. Unfortunately, that
change cannot be implemented without some impact to users.

The question is how do we implement this change so that users will get to
benefit from the improvements while minimising impact to those who don't
want to change or cannot make the change right now and at the same time,
ensure users are exposed to the new functionality so that they can gain the
benefit from this change.  On one side, we have those who feel the impact
is too muich and will cause too much pain for users and on the other side,
we ahve a concern that without some impact to users, we run the risk of
inertia and unawareness of the improvements/enhancements for existing users
and new users being introduced to the older, less feature rich solution
rather than the enhanced  version.

Personally, I feel the new version should be the default and we should
provide an easy way to re-enable the old version for those who wish to
continue with what they are use to. The key will be how we communicate this
to existing users.

Tim

On 1 May 2018 at 07:46, Jon Snader  wrote:

>
> Richard Lawrence  writes:
>
> Jon Snader  writes:
>>
>> I use the >> enabled. I don't want to have to deal with a menu and its more
>>> complicated calling sequence
>>>
>>
>> I feel the same!  Please don't disable > complicated to use.
>>
>
> You can make the case that it doesn't really matter because all that's
> needed is a minor adjustment to your init.el to restore the old
> behavior. But here's what's going to happen: A user who upgrades through
> ELPA is going to discover that suddenly the familiar template code is no
> longer working. He'll likely think it's an bug and wait for an upgrade
> or two for it to be fixed. When it doesn't get fixed, he'll ask the
> Internet what's wrong.
> Here's what's not going to happen: he's not going to read the ORG-NEWS
> file. In the first place, as Bastien says, most users don't but many
> users won't even know where to look. Org mode is famously Emacs' killer
> app and many non-technical users have been drawn to Emacs to get access
> to it. Many of them probably have no idea where the ELPA files are
> stored and even if they do they probably won't look in the etc
> subdirectory.
>
> Why torture our users when it's so simple to keep the old behavior
> enabled? If I hadn't seen Bastien's tweet pointing to this thread, I
> would most certainly be one of the people described above.
>
>


-- 
regards,

Tim

--
Tim Cross

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Jon Snader]

Richard Lawrence  writes:


Jon Snader  writes:

I use the 

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Michael Gauland]

Same here!


On 01/05/18 08:46, Peter Dewey Ore wrote:
> I second (third?) Richard and Jon. I use  appreciate the simplicity.
>
> On Mon, Apr 30, 2018 at 1:37 PM, Richard Lawrence
> >
> wrote:
>
> Jon Snader > writes:
>
> I use the  it enabled. I don't want to have to deal with a menu and its
> more complicated calling sequence
>
>
> I feel the same!  Please don't disable  complicated to use.
>
> -- 
> Best,
> Richard
>
>

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Peter Dewey Ore]

I second (third?) Richard and Jon. I use  wrote:

> Jon Snader  writes:
>
> I use the > I don't want to have to deal with a menu and its more complicated calling
>> sequence
>>
>
> I feel the same!  Please don't disable  to use.
>
> --
> Best,
> Richard
>
>

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Richard Lawrence]

Jon Snader  writes:

I use the 

Re: [O] Moving from Jekyll to Orgmode

[Diego Zamboni]

Hi Luis,

easy-hugo is simply a control layer over plain Hugo. As such, when you write a 
post in org format, it’s not org-mode but Hugo who is doing the interpretation, 
using the goorgeous library (https://github.com/chaseadamsio/goorgeous/ 
). This is why there are 
inconsistencies and other problems in parsing - goorgeous does not support the 
whole range of org-mode constructs. I originally started with easy-hugo as 
well, and got increasingly frustrated by some of these issues.

ox-hugo takes a different approach: it uses org-mode’s ox-markdown exporter to 
produce Markdown from the org source, so that Hugo processes a Markdown file. 
This makes a big difference, as each tool is processing its own native format: 
org-mode processes org, and Hugo processes Markdown. Thanks to this, you can 
even include Hugo shortcodes (https://gohugo.io/content-management/shortcodes/ 
) in your org-mode source, 
and they will be passed untouched to Hugo (this is not entirely advisable as it 
makes your source Hugo-specific, but it’s doable if you want it).

Another very nice ox-hugo feature is its “One post per Org subtree” mode 
(https://ox-hugo.scripter.co/#screenshot-one-post-per-subtree 
), in which you 
keep your entire post tree (in fact, you could keep your entire website) in a 
single Org file. I was skeptical about this at first (who wants to keep 
*everything* in a single file), but in practice it works very well, and allows 
you to have tags/categories or other attributes per subtree, so you don’t have 
to repeat them on every post. If you really want to keep each post in a 
separate file, that is doable as well. The ox-hugo website has a lot of very 
useful information.

Finally, you can do the transition gradually - for my website, I had years of 
accumulated Markdown files from my adventures with Jekyll, Octopress and later 
Hugo. Those are still in place, and I have started only putting my new posts in 
an org file which ox-hugo processes. Since those are converted to Markdown 
files, they end up alongside the old hand-crafted files, and Hugo just 
processes them all together.

I really recommend ox-hugo, Kaushal has done a fantastic job and he is also 
really helpful and responsive with questions.

Tip: I learned a lot by reading the source files for 
https://ox-hugo.scripter.co/  and for 
https://scripter.co/ , both of which are kept in ox-hugo 
structure. You can find pointers to those and some other examples (including my 
own websites, zzamboni.org and cf-learn.info ) at 
https://ox-hugo.scripter.co/doc/examples/ 


Hope this helps,
—Diego

> On 29 Apr 2018, at 14:55, Luis Roca  wrote:
> 
> On Sun, 2018-04-29 at 09:45 +0200, Saša Janiška wrote:
>> ST  writes:
>> 
>>> I would like to rewrite my website using Orgmode (till now I used
>>> Jekyll). It would be nice if you could help me with following
>>> questions:
>> 
>> I recommend you to take look at ox-hugo (https://ox-hugo.scripter.co/
>> )
>> 
>> 
>> Sincerely,
>> Gour
>> 
> 
> I tested easy-hugo recently but the exporting of org files was
> inconsistent with headlines and content separated. Does ox-hugo export
> well consistently? 
> 
> If so I may try Hugo again.
> 
> Thanks in advance,
> Luis
> 

Re: [O] Bug: org-fill-paragraph deletes an extra line [9.1.11 (9.1.11-2-ge3b1c6-elpa @ /home/yminsky/.emacs.d/elpa/org-9.1.11/)]

[Nicolas Goaziou]

Hello,

Yaron Minsky  writes:

> Oddly, it also gets indentation wrong. So if I start with this:
>
> - asdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
>   asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
>   asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
>   asdfasdf asdfasdf asdf
>
> And I try to fill the paragraph, I'll get this:
>
> - asdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
> asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
> asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
> asdfasdf asdfasdf asdf

I cannot reproduce it. M-q anywhere in your example doesn't change
anything. Could you try again without any configuration on your side
(besides the one that loads a recent Org)?

Regards,

-- 
Nicolas Goaziou

[O] bug#31273: 27.0.50; org: #+begin_right block is not exported correctly

[Dmitry Alexandrov]

Nicolas Goaziou  wrote:
> Dmitry Alexandrov <321...@gmail.com> writes:
>> with the latest Emacs from git master, exporting #+begin_right block
>> neither to HTML, nor to ODT (didn’t test other options) does not work
>> as expected, while this should be pretty possible with both.
>>
>> With HTML, as far as I can see, the problem is in that, so a CSS class
>> is named ‘org-right’:
>>
>>   .org-right  { margin-left: auto; margin-right: 0px;  text-align: right; }
>>
>>
>> while in the HTML it is referenced as just ‘right’:
>>
>> 
>
> ".org-right" is an internal CSS class for table alignment.
>
> OTOH, "#+begin_right" starts a special block that, as expected, create
> a "right" div.
>
> So, there is no issue here. You can either define "right" CSS, or
> (untested), try "#+begin_org-right".

Thank you for a response, #+begin_org-right block indeed works like a charm.

Now, I am not sure, whether am I supposed to use #+begin_org-center blocks 
instead of #+begin_center too.

In fact, given that #+begin_center creates a .org-center div block, that is 
centred by default CSS (and stylesheets of other formats), I found your answer 
absolutely surprising.

I would be probably not alone on this feeling; see, for instance, Fabrice 
Niessen’s Org mode syntax reference card [0], where (as far as I got it) 
#+begin_right is presented as alignment tag for paragraphs rather than tables:

--8<---cut here---start->8---
Centered text

#+begin_left
This text is \\
aligned to the left!
#+end_left

#+begin_center
This text is \\
centered!
#+end_center

#+begin_right
This text is \\
aligned to the right!
#+end_right
--8<---cut here---end--->8---

In a part for centring it is in accordance to (info "(org) Paragraphs"), which 
says:

--8<---cut here---start->8---
   If you would like to center some text, do it like this:
 #+BEGIN_CENTER
 Everything should be made as simple as possible, \\
 but not any simpler
 #+END_CENTER
--8<---cut here---end--->8---

[0] https://github.com/fniessen/refcard-org-mode


signature.asc
Description: PGP signature

[O] Bug: org-fill-paragraph deletes an extra line [9.1.11 (9.1.11-2-ge3b1c6-elpa @ /home/yminsky/.emacs.d/elpa/org-9.1.11/)]

[Yaron Minsky]

This problem crops up when I install 9.1.11. I was previously using an
8.* version of org, and didn't see an issue. The basic problem is that
every time I do M-q to fill a paragraph, it deletes an extra line from
right after the paragraph, eventually sucking in following headers and
paragraphs into the present paragraph.

Oddly, it also gets indentation wrong. So if I start with this:

- asdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
  asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
  asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
  asdfasdf asdfasdf asdf

And I try to fill the paragraph, I'll get this:

- asdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf asdfasdf
asdfasdf asdfasdf asdf

I wasn't able to find a description of this error by googling around, sadly.

Emacs  : GNU Emacs 25.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.22.19)
 of 2017-09-14
Package: Org mode version 9.1.11 (9.1.11-2-ge3b1c6-elpa @
/home/yminsky/.emacs.d/elpa/org-9.1.11/)

current state:
==
(setq
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-image-actual-width 100
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-startup-folded nil
 org-latex-pdf-process '("pdflatex -interaction nonstopmode
-shell-escape -output-directory %o %f"
"pdflatex -interaction nonstopmode -shell-escape -output-directory %o %f"
"pdflatex -interaction nonstopmode -shell-escape -output-directory %o %f")
 org-export-with-section-numbers nil
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-tree-slide-skip-outline-level 4
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-from-is-user-regexp "\\"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '((closure
  (org-inlinetask-min-level buffer-face-mode-face org-struct-menu org-last-state
   org-id-track-globally texmathp-why remember-data-file
org-agenda-tags-todo-honor-ignore-options
   calc-embedded-open-mode calc-embedded-open-formula
calc-embedded-close-formula
   align-mode-rules-list ffap-url-regexp t)
  nil
  (add-hook (quote change-major-mode-hook) (quote org-show-block-all)
(quote append) (quote local)))
(closure (*this* org-babel-confirm-evaluate-answer-no t) nil
  (add-hook (quote change-major-mode-hook) (quote
org-babel-show-result-all) (quote append)
   (quote local))
  )
#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook
org-show-block-all append local]
   5]
#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
(lambda nil (abbrev-mode) (define-key org-mode-map (kbd "M-q") (quote
fill-paragraph
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME
CONTENTS WIDTH)"]
 org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
 org-tree-slide-modeline-display nil
 org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-tree-slide-header nil
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-html-format-headline-function 'org-html-format-headline-default-function
 org-link-parameters '(("id" :follow org-id-open) ("rmail" :follow
org-rmail-open :store org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link)
   ("info" :follow org-info-open :export org-info-export :store
org-info-store-link)
   ("gnus" :follow org-gnus-open :store org-gnus-store-link)
   ("docview" :follow org-docview-open :export org-docview-export
:store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export org-bbdb-export 

[O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Jon Snader]

I use the 

Re: [O] Moving from Jekyll to Orgmode

[Luis Roca]

On Sun, 2018-04-29 at 09:45 +0200, Saša Janiška wrote:
> ST  writes:
> 
> > I would like to rewrite my website using Orgmode (till now I used
> > Jekyll). It would be nice if you could help me with following
> > questions:
> 
> I recommend you to take look at ox-hugo (https://ox-hugo.scripter.co/
> )
> 
> 
> Sincerely,
> Gour
> 

I tested easy-hugo recently but the exporting of org files was
inconsistent with headlines and content separated. Does ox-hugo export
well consistently? 

If so I may try Hugo again.

Thanks in advance,
Luis

[O] bug#31273: 27.0.50; org: #+begin_right block is not exported correctly

[Dmitry Alexandrov]

Nicolas Goaziou  wrote:
> Dmitry Alexandrov <321...@gmail.com> writes:
>
>> Now, I am not sure, whether am I supposed to use #+begin_org-center
>> blocks instead of #+begin_center too.
>
> The latter. As I explained, ".org-center" is an internal style.
>
>> In fact, given that #+begin_center creates a .org-center div block,
>> that is centred by default CSS (and stylesheets of other formats),
>> I found your answer absolutely surprising.
>
> "Center" blocks are defined in the manual, along with their syntax.

Thank you, I will.

> There is nothing surprising.
>
> Moreover, there is no such thing as a "Right" block. Or, more precisely,
> this falls into the special block category, which is handled differently
> in each export back-end.
>
>> I would be probably not alone on this feeling; see, for instance,
>> Fabrice Niessen’s Org mode syntax reference card [0], where (as far as
>> I got it) #+begin_right is presented as alignment tag for paragraphs
>> rather than tables:
>
> This reference card is not an official reference card.

Yes, I fully realize that.

Just another unofficial reference card [0], by Caio Rordrigues at that time, 
that again states that:

--8<---cut here---start->8---
#+begin_right
This text is
aligned to the right!
#+end_right
--8<---cut here---end--->8---

These persons are probably consider themselves highly familiar with Org, yet 
they have been mistaken.  What to say about novices!  So the absence of this 
feature is indeed highly unobvious.  That’s the only point I am trying to make.

[0] 
https://github.com/caiorss/Emacs-Elisp-Programming/blob/master/Org-Mode.org#text-position

> In any case, let me insist again on the following point: you can use
> "#+begin_right" in HTML to your heart's content if you define the
> appropriate CSS property.

If there is no plan to make into default as with centring, a warning might be 
very apt.

Thank you again for your work on the Org.


signature.asc
Description: PGP signature

Re: [O] problems with tables using https://orgmode.org/worg/org-tutorials/org-lookups.html

[Nicolas Goaziou]

Hello,

Uwe Brauer  writes:

> #+name: raw-data2
> |---+-+-+-+-+-+-+-+-|
> |   | /   | |  <> |  <> |  <> |  <> |  <> |  <> |

I also moved "/" to the left column. But it works without it.

> |   | Nombre Completo | DNI | Ej1 | Ej2 | Ej3 | Ej4 | Ej5 | Res |
> |---+-+-+-+-+-+-+-+-|
> |   | Candidate1  |   1 |   0 |   5 |   5 |   0 |  10 |   2 |
> |   | Candidate2  |   2 |   5 |   0 |   5 |   0 |   0 |   1 |
> |   | Candidate3  |   3 |   0 |   0 |   0 |  20 |  25 | 4.5 |
> |   | Candidate4  |   4 |   0 |   0 |   0 |  25 |  15 |   4 |
> |   | Candidate5  |   5 |  15 |  15 |  20 |  25 |  25 |  10 |
> |   | Candidate6  |   6 |  15 |  10 |  20 |  20 |  20 | 8.5 |
> |   | Candidate7  |   7 |  15 |  10 |  10 |  20 |  15 |   7 |
> #+TBLFM: $9=($4+$5+$6+$7+$8)/10
>
> | lower bound | upper bound | frequency |
> |-+-+---|
> |   1 |   5 | #ERROR|
> |   5 |  10 | #ERROR|
> #+TBLFM: $3='(length (org-lookup-all '($1 $2) '(remote(raw-data2,@2$9..@>$9)) 
> nil 'in-interval));N
>
> #+end_src
>
>
>
> That did not work neither as you can see.

It definitely works here.

Regards,

-- 
Nicolas Goaziou

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Steve Downey]

Changing the UI to no longer work is a very non-emacsy thing to do. There's
a lot of existing doc and tutorials explaining the org template system, as
well as current users who have trained fingers. Breaking 

Re: [O] problems with tables using https://orgmode.org/worg/org-tutorials/org-lookups.html

[Uwe Brauer]

Thanks!

Do you mean

#+begin_src org

#+name: raw-data2
|---+-+-+-+-+-+-+-+-|
|   | /   | |  <> |  <> |  <> |  <> |  <> |  <> |
|   | Nombre Completo | DNI | Ej1 | Ej2 | Ej3 | Ej4 | Ej5 | Res |
|---+-+-+-+-+-+-+-+-|
|   | Candidate1  |   1 |   0 |   5 |   5 |   0 |  10 |   2 |
|   | Candidate2  |   2 |   5 |   0 |   5 |   0 |   0 |   1 |
|   | Candidate3  |   3 |   0 |   0 |   0 |  20 |  25 | 4.5 |
|   | Candidate4  |   4 |   0 |   0 |   0 |  25 |  15 |   4 |
|   | Candidate5  |   5 |  15 |  15 |  20 |  25 |  25 |  10 |
|   | Candidate6  |   6 |  15 |  10 |  20 |  20 |  20 | 8.5 |
|   | Candidate7  |   7 |  15 |  10 |  10 |  20 |  15 |   7 |
#+TBLFM: $9=($4+$5+$6+$7+$8)/10

| lower bound | upper bound | frequency |
|-+-+---|
|   1 |   5 | #ERROR|
|   5 |  10 | #ERROR|
#+TBLFM: $3='(length (org-lookup-all '($1 $2) '(remote(raw-data2,@2$9..@>$9)) 
nil 'in-interval));N

#+end_src



That did not work neither as you can see.

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Kevin Foley]

I should add that one issue with org-tempo is it doesn't seem to be
backwards compatible with old templates.  For example packages such as
ob-sql-mode and org-reveal have easy templates based on the old format such
as :

(add-to-list 'org-structure-template-alist
  `(,org-babel-sql-mode-template-selector
"#+BEGIN_SRC sql-mode ?\n\n#+END_SRC"
"#+BEGIN_SRC sql-mode ?\n\n#+END_SRC"))

https://github.com/nikclayton/ob-sql-mode/blob/8d36d312bec4a742bec8890373948a888cac18de/ob-sql-mode.el#L187

This causes the cryptic error "File mode specification error: (error Format
specifier doesn’t match argument type)" when trying to load org-mode which
took me ages to figure out and could potentially turn someone new to
org-mode/emacs off forever.

I think this would be a good reason to not enable org-tempo at least for
the time being until either it can handle templates in the old format, or
produces a less cryptic error for users.

Regards,
Kevin

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Kevin Foley]

Bastien  writes:

> Here is what the experience can look like:
>
> - Upgrading Emacs or Org (hurray!!)
> - Trying to hit  - Thinking your stupid

[...]

I have to admit that Bastien's list describes my experience almost
perfectly.  It look me a long time to figure out something that in the end
seemed very simple.  At the time I wasn't familiar with the NEWS file and
it didn't come up in any of my online searches.  It also didn't help that
site still documented the old behavior (and apparently still does
https://orgmode.org/manual/Easy-templates.html).

After reading Nicolas' points, I see the argument for moving people away
from org-tempo, actually I'm very excited to start using yasnippet. I've
been putting off incorporating it into my workflow for a while but this
thread has finally convinced me to start.

However, I do think the transition could be made a lot smoother for new
users.  The biggest step would be updating the easy-templates page to let
users know they now need to use org-tempo and should consider alternatives
such as yasnippet for more functionality.

Regards,
Kevin

On Mon, Apr 30, 2018 at 6:29 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Bastien  writes:
>
> > Here is what the experience can look like:
> >
> > - Upgrading Emacs or Org (hurray!!)
> > - Trying to hit  > - Thinking your stupid
>
> [...]
>
> I have an issue with this argument: it can be opposed to virtually any
> backward-incompatible change we make. There are actually 10 such changes
> in Org 9.2. Would it makes sense to remove them because some users,
> unfortunately, will encounter a workflow break upon updating Org?
>
> I totally agree this is an issue, yet, we have to move forward. We can
> make UX consistent across releases, but we cannot guarantee 100%
> compatibility at each step. As a data point, I don't know any software
> that preserves the exact same UX after each release -- Firefox, Gnome,
> I'm looking at you! There are unavoidable gotchas. This just means Org
> is still vivid.
>
> > In fact, I'm inclined to ask the real question: if org-tempo is on by
> > default, who will have good reasons to turn it off and why?
>
> This is one problem: only a few will have a reason (good or bad, who
> cares?) to turn it off, e.g., because expansion gets in the way with
> other templating systems. Possibly even fewer will actually turn it off.
> As a consequence, the vast majority of users will keep using " put maintenance burden on us -- instead of trying, and improving
> something else. Inertia...
>
> I already stated the following, sorry for re-iterating. Marking a region
> and wrapping it in some environment is a basic operation Org is expected
> to provide. We already did with `org-emphasize'. Implementing
> programmable templates, even though we are re-using what Emacs ships
> with, is another story.
>
> Org Tempo is a nice tool. I'm not questioning this. It is also almost
> 100% compatible with previous feature. Yet, it competes with external
> Emacs libraries, as capable as itself. Since it is not a feature
> mandatory in Org, why forcing it onto the users? I'm inclined to think
> we shouldn't.
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>
>

Re: [O] exporting drawers: odt versus LaTeX

[Eric S Fraga]

On Monday, 30 Apr 2018 at 13:46, Nicolas Goaziou wrote:
> Eric S Fraga  writes:
>
>> Yes, I understand.  I am definitely not disagreeing about how org parses
>> the elements, simply how it exports them.
>
> Then we agree on this point. 

Yes!

> Export is different because, well, target languages are also
> different...

Which makes consistency challenging.  We're seeing this with the
citations thread.

[...]

> Since I couldn't answer those questions, I'm mostly a LaTeX guy, this is
> not implemented so far.

Which is fine with me as I also am a LaTeX guy... :-)

I only need odt when I am sharing with some colleagues that have not yet
seen the light. ;-)

thanks for the detailed explanation in any case.

eric

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.11-620-ga548e4


signature.asc
Description: PGP signature

Re: [O] How to use xml src block as data input?

[John Kitchin]

Here is a minor variation on this idea:

#+name: xml-example
#+BEGIN_SRC xml

Tove
Jani
Reminder
Don't forget me this weekend!

#+END_SRC

#+BEGIN_SRC emacs-lisp :var name="xml-example"
(save-excursion
  (org-babel-goto-named-src-block name)
  (let ((data (org-element-property :value (org-element-context
(with-temp-buffer (insert data) (libxml-parse-xml-region (point-min) 
(point-max)
#+END_SRC

#+RESULTS:
| note | nil | (to nil Tove) | (from nil Jani) | (heading nil Reminder)
| (body nil Don't forget me this weekend!) |


Simonyi András writes:

> Hello,
>
> if having the data in a source block is a must, then, as a last resort,
>   you might try to pull the block's content from the buffer's parse tree:
>
> #+begin_src emacs-lisp :var src-block-name="xml-sample"
>(let ((xml-str
>   (org-element-map (org-element-parse-buffer) 'src-block
> (lambda (x)
>   (and (string= src-block-name (org-element-property :name x))
>(org-element-property :value x)))
> nil t)))
>  (with-temp-buffer (insert xml-str) (libxml-parse-xml-region (point-min)
> (point-max
> #+end_src
> On Mon, 30 Apr 2018 at 05:43, stardiviner  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>
>
>> Thanks, I forgot to mention I know example block can be used as input.
>> But this will lose the syntax highlighting. If there is no better
> solution.
>> I guess it is the best for now.
>
>> - --
>> [ stardiviner ] don't need to convince with trends.
>> Blog: https://stardiviner.github.io/
>> IRC(freenode): stardiviner
>> GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>> -BEGIN PGP SIGNATURE-
>
>> iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrmkL0ACgkQG13xyVro
>> msOU6gf/UNiTzSt8Cizpk1FLBjJJiqOMfWdvp+jJVoNOCJzaxkHFAiwjbEyIf9B5
>> k27Zw3Gh60rT0iz/RYscptv2keTieUwU0rf23oyouFESgIBaICfRRYzZZ0ZUWTHO
>> 9VGILsaQfOZfO4lenZGMnWGt583DCV1CxEqcODQj2Z7DFb8EfxvRiGup9qPjMSVq
>> 65gu7/Vk2Y2d+cvUZU7t592b7D/5na5Dxy0jkuAEttXjoJrk4OHoxcmYMjbnoimq
>> DSUyu467YqtKKyyOgC8hEnatarkItDp6O5v/P8Ki/iVV5zSTiqkhriQYI9k/sPTV
>> xmI9WZEFOB5A8auvw9csQTUUny2Mjw==
>> =qQac
>> -END PGP SIGNATURE-


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] problems with tables using https://orgmode.org/worg/org-tutorials/org-lookups.html

[Nicolas Goaziou]

Hello,

Uwe Brauer  writes:


> #+TBLNAME: raw-data2

Not related, but : #+name: raw-data2

> |---+-+-+-+-+-+-+-+-|
>
> |   | /   | |  <> |  <> |  <> |  <> |  <> |  <> |
> |   | Nombre Completo | DNI | Ej1 | Ej2 | Ej3 | Ej4 | Ej5 | Res |
> |---+-+-+-+-+-+-+-+-|
> |   | Candidate1  |   1 |   0 |   5 |   5 |   0 |  10 |   2 |
> |   | Candidate2  |   2 |   5 |   0 |   5 |   0 |   0 |   1 |
> |   | Candidate3  |   3 |   0 |   0 |   0 |  20 |  25 | 4.5 |
> |   | Candidate4  |   4 |   0 |   0 |   0 |  25 |  15 |   4 |
> |   | Candidate5  |   5 |  15 |  15 |  20 |  25 |  25 |  10 |
> |   | Candidate6  |   6 |  15 |  10 |  20 |  20 |  20 | 8.5 |
> |   | Candidate7  |   7 |  15 |  10 |  10 |  20 |  15 |   7 |
>
> #+TBLFM: $9=($4+$5+$6+$7+$8)/10
>
> | lower bound | upper bound | frequency |
> |-+-+---|
> |   1 |   5 | 0 |
> |   5 |  10 | 1 |
>
> #+TBLFM: $3='(length (org-lookup-all '($1 $2) '(remote(raw-data2,@9$9..@>$9)) 
> nil 'in-interval));N
   
   @2$9
>
> #+TBLNAME: raw-data3

See above.

> |---+-+-+-+-+-+-|
>
> |   | /   |  <> |  <> |  <> |  <> |  <> |
> |   | Nombre Completo | Ej1 | Ej2 | Ej3 | Ej4 | Res |
> |---+-+-+-+-+-+-|
> |   | Candidate1  |   0 |   5 |   5 |   0 |   1 |
> |   | Candidate2  |   5 |   0 |   5 |   0 |   1 |
> |   | Candidate3  |   0 |   0 |   0 |  20 |   2 |
> |   | Candidate4  |   0 |   0 | |  25 | 2.5 |
> |   | Candidate5  |  15 |  15 |  20 |  25 | 7.5 |
> |   | Candidate6  |  15 |  10 |  20 |  20 | 6.5 |
> |   | Candidate7  |  15 |   0 |  10 |  20 | 4.5 |
>
> #+TBLFM: $7=($3+$4+$5+$6)/10
>
> | lower bound | upper bound | frequency |
> |-+-+---|
> |   0 |   5 | 1 |
> |   5 |  10 | 2 |
>
> #+TBLFM: $3='(length (org-lookup-all '($1 $2) '(remote(raw-data3,@7$7..@>$7)) 
> nil 'in-interval));N
   
  ditto
Regards,

-- 
Nicolas Goaziou

Re: [O] exporting drawers: odt versus LaTeX

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> Yes, I understand.  I am definitely not disagreeing about how org parses
> the elements, simply how it exports them.

Then we agree on this point. 

Export is different because, well, target languages are also
different...

Since empty lines are preserved upon exporting documents, Org is /de
facto/ nice with formats that separate paragraphs with blank lines,
e.g., LaTeX or Texinfo. I.e, it adapts easily to their definition of
a paragraph.

As you noted, this is not the same for other back-ends, as HTML or ODT.
At some point, I wanted to have Org adapt to their own definition of
a paragraph. I.e., a parse-tree filter (provided by the back-end) would
generate pseudo-elements matching the target's definition of
a paragraph. Then, the parse-tree would convert the pseudo-element as
a paragraph whereas it would do nothing for a regular paragraph.

E,g., the following document

  Paragraph
  #+begin_quote
  Quote
  #+end_quote
  Paragraph 2

  Paragraph 3

is parsed as 

  (paragraph "Paragraph") 
  (quote-block (paragraph "Quote"))
  (paragraph "Paragraph 2")
  (paragraph "Paragraph 3")

the HTML parse tree filter would turn it into

  (html-paragraph 
   (paragraph "Paragraph")
   (quote-block (html-paragraph (paragraph "Quote")))
   (paragraph "Paragraph 2"))

  (html-paragraph
   (paragraph "Paragraph 3"))

and since regular paragraph converter would be a no-op, this would
really become:

  (html-paragraph 
   "Paragraph"
   (quote-block (html-paragraph "Quote"))
   "Paragraph 2")

  (html-paragraph "Paragraph 3")

Some parts of the export framework already implement a similar
mechanism, e.g., `org-latex--wrap-latex-matrices'.

But there are a some shortcomings. E.g., is an `html-paragraph' nested
in an `html-paragraph' still valid? What about the quote block being
a table, a plain list? IOW, what is the exact definition of HTML
paragraph?

Since I couldn't answer those questions, I'm mostly a LaTeX guy, this is
not implemented so far.

Regards,

-- 
Nicolas Goaziou

Re: [O] Moving from Jekyll to Orgmode

[ST]

On Sun, 2018-04-29 at 11:45 -0500, Grant Rettke wrote:
> On Sat, Apr 28, 2018 at 4:05 PM, ST  wrote:
> > 3. is there a free modern "corporate" style theme for org-mode?
> 
> Twitter Bootstrap https://github.com/marsmining/ox-twbs and

This looks nice...

1. Does it mean that any Bootstrap theme can be used with this?
see here: https://themes.getbootstrap.com/

2. Does it support the latest Bootstrap 4.1?

Thank you!

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Here is what the experience can look like:
>
> - Upgrading Emacs or Org (hurray!!)
> - Trying to hit  - Thinking your stupid

[...]

I have an issue with this argument: it can be opposed to virtually any
backward-incompatible change we make. There are actually 10 such changes
in Org 9.2. Would it makes sense to remove them because some users,
unfortunately, will encounter a workflow break upon updating Org?

I totally agree this is an issue, yet, we have to move forward. We can
make UX consistent across releases, but we cannot guarantee 100%
compatibility at each step. As a data point, I don't know any software
that preserves the exact same UX after each release -- Firefox, Gnome,
I'm looking at you! There are unavoidable gotchas. This just means Org
is still vivid.

> In fact, I'm inclined to ask the real question: if org-tempo is on by
> default, who will have good reasons to turn it off and why?

This is one problem: only a few will have a reason (good or bad, who
cares?) to turn it off, e.g., because expansion gets in the way with
other templating systems. Possibly even fewer will actually turn it off.
As a consequence, the vast majority of users will keep using "

Re: [O] How to use xml src block as data input?

[Simonyi András]

Hello,

if having the data in a source block is a must, then, as a last resort,
  you might try to pull the block's content from the buffer's parse tree:

#+begin_src emacs-lisp :var src-block-name="xml-sample"
   (let ((xml-str
  (org-element-map (org-element-parse-buffer) 'src-block
(lambda (x)
  (and (string= src-block-name (org-element-property :name x))
   (org-element-property :value x)))
nil t)))
 (with-temp-buffer (insert xml-str) (libxml-parse-xml-region (point-min)
(point-max
#+end_src
On Mon, 30 Apr 2018 at 05:43, stardiviner  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256


> Thanks, I forgot to mention I know example block can be used as input.
> But this will lose the syntax highlighting. If there is no better
solution.
> I guess it is the best for now.

> - --
> [ stardiviner ] don't need to convince with trends.
> Blog: https://stardiviner.github.io/
> IRC(freenode): stardiviner
> GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
> -BEGIN PGP SIGNATURE-

> iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrmkL0ACgkQG13xyVro
> msOU6gf/UNiTzSt8Cizpk1FLBjJJiqOMfWdvp+jJVoNOCJzaxkHFAiwjbEyIf9B5
> k27Zw3Gh60rT0iz/RYscptv2keTieUwU0rf23oyouFESgIBaICfRRYzZZ0ZUWTHO
> 9VGILsaQfOZfO4lenZGMnWGt583DCV1CxEqcODQj2Z7DFb8EfxvRiGup9qPjMSVq
> 65gu7/Vk2Y2d+cvUZU7t592b7D/5na5Dxy0jkuAEttXjoJrk4OHoxcmYMjbnoimq
> DSUyu467YqtKKyyOgC8hEnatarkItDp6O5v/P8Ki/iVV5zSTiqkhriQYI9k/sPTV
> xmI9WZEFOB5A8auvw9csQTUUny2Mjw==
> =qQac
> -END PGP SIGNATURE-

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Eric S Fraga]

On Sunday, 29 Apr 2018 at 15:22, Bastien wrote:

[...]

> But again, I might be wrong, I just don't want this to be a discussion
> between us two :)

The new system seems more powerful and works better for me as it doesn't
conflict with predictive texting that also uses the TAB key.

I'm am tending to side with the view put forward by Nicolas on this one:
one well supported solution is better than 2.  However, Emacs is
infamous for having >n (with n large) solutions to any problem...  So I
don't have any fundamental problems with both being available per se so
long as they do not conflict.

My 2¢.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.7-475-g3ffc7d


signature.asc
Description: PGP signature