Re: should a BIBLIOGRAPHY keyword supercede org-cite-global-bibliography?

2021-07-19 Thread Thomas S. Dye
I used to have a global bibliography that my employees all used. 
Every project also had a local bibliography for citations that 
didn't appear in the global bibliography.  At the end of a 
project, after the editor had cleaned up the local bibliography, 
I'd merge it with the global bibliography using a utility called 
bibtool.


hth,
Tom

Vikas Rawal  writes:

It seems like that should not be the case, i.e. if you define 
BIBLIOGRAPHY

keywords it means you do not want to use the ones
in org-cite-global-bibliography. Is there a scenario where the 
union of those

makes sense?


I second this. The local bibliographies should supercede the 
global.


Vikas



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: [wip-cite-new] Merging tomorrow?

2021-07-07 Thread Thomas S. Dye

Aloha Nicolas,

Good news! I'm looking forward to using this facility.

Thanks to all the contributors.

All the best,
Tom

Nicolas Goaziou  writes:


Hello,

I think the "wip-cite-new" branch is in good shape now. As
a consequence, I'd like to merge it tomorrow.

It is documented, but the documentation is scattered across the 
various
"oc" libraries, and some threads in the mailing list. I'll do a 
summary

here, from a user point of view.

--8<---cut 
here---start->8---
Basically, in order to use it, you need to first set-up a 
bibliography,
using one or more "bibliography" keywords.  on such a 
keyword
visits the related file. Out of the box, Org supports JSON-CSL 
and

BibTeX (or biblatex) bibliographies.

Then, citations can be inserted with the following syntax:

  [cite/style:common prefix ;prefix @key suffix; ... ; common 
  suffix]


Spaces are meaningful except those after the initial colon and 
before

the closing bracket.

Every part of the syntax is optional, except the brackets, 
"cite" and
the colon. Also the citation must contain at least a key. So its 
minimal

form is:

  [cite:@key]

The "style" part is detailed below, in the part related to 
export.


Org can insert or edit citations with  (and delete 
them with
), follow them with , fontify them, and 
export
them. These four actions (insert, follow, activate, and export) 
are
called capabilities.  Libraries responsible for these 
capabilities are

called citation processors.

You can select one citation processor for each capability, 
independently

on the others, through the following variables:

- org-cite-activate-processor
- org-cite-export-processors
- org-cite-follow-processor
- org-cite-insert-processor

Out of the box, Org provides the "basic" (in "oc-basic.el") 
processor
for all of these tasks. It also boasts processors dedicated for 
export:

"csl", "natbib" and "biblatex".

During export, output for citations is controlled by their 
style, which
is an Org label that the export processor may recognize and 
associate to
a specific display, or fall-back to a default style (called 
"nil"). For

example, most processors support "noauthor" and "text" styles.

Some styles can accept a variant, with the syntax 
"style/variant".
Again, it's up to the processor to associate it to a specific 
display.
Common variants include "bare", "caps" or "full".  They also 
accept

short-hands, like "b", "c" and "f".  Please refer to the export
processors' libraries ("oc-basic.el", "oc-csl.el", …) for more 
information.


It is possible to define a default style for a whole document 
(with
"cite_export"), or for all documents (with 
`org-cite-export-processors').


References are displayed with the "print_bibliography" keyword. 
It is
possible to add parameters to its value, as some export 
processors could

make use of them.
--8<---cut 
here---end--->8---


Please let me know if there are any objections to the merge.

Regards,



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: Org mode manual export

2021-05-22 Thread Thomas S. Dye

Done.  Thanks!

All the best,
Tom

Kyle Meyer  writes:


Thomas S. Dye writes:


Aloha all,

The Org mode FAQ on Worg correctly reports that the Org mode
manual is written in Org mode, but it implies that it is 
exported

to texinfo using pandoc--"You can export .org files to texinfo
using Pandoc".

I thought the manual was exported to texinfo with ox-texinfo, 
but

I don't know for certain.

Can someone confirm how the Org mode manual is exported to
texinfo, please?


Yes, you're right that ox-texinfo is used.

In doc/Makefile there's

  org.texi orgguide.texi:   org-manual.org org-guide.org
$(BATCH)  \
  --eval '(add-to-list `load-path "../lisp")' \
  --eval '(load "../mk/org-fixup.el")'  \
  --eval '(org-make-manuals)'

where org-make-manuals is defined in mk/org-fixup.el as

  (defun org-make-manuals ()
"Generate the Texinfo files out of Org manuals."
(require 'ox-texinfo)
(dolist (manual '("../doc/org-manual.org" 
"../doc/org-guide.org"))

  (find-file manual)
  (org-texinfo-export-to-texinfo)))



--
Thomas S. Dye
https://tsdye.online/tsdye



Org mode manual export

2021-05-22 Thread Thomas S. Dye

Aloha all,

The Org mode FAQ on Worg correctly reports that the Org mode 
manual is written in Org mode, but it implies that it is exported 
to texinfo using pandoc--"You can export .org files to texinfo 
using Pandoc".


I thought the manual was exported to texinfo with ox-texinfo, but 
I don't know for certain.


Can someone confirm how the Org mode manual is exported to 
texinfo, please?


I'll update the FAQ if necessary.

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye



Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

2021-05-20 Thread Thomas S. Dye

Bummer!

This non-minimal example (modified from a document that originally 
called biblatex-chicago directly) works for me:
  \usepackage[style=chicago-authordate, giveninits=true, 
  uniquename=mininit, noibid, sortcites=true, backend=biber, 
  bibencoding=utf8]{biblatex}


All the best,
Tom

Bruce D'Arcus  writes:

On Thu, May 20, 2021 at 6:37 PM Thomas S. Dye  
wrote:


Interested lurker here.  From the biblatex-chicago manual:

"You can load the package via the usual \usepackage{biblatex},
adding either style=chicago-notes or style=chicago-authordate"


Alas, I get errors when I use that invocation.

Only when I add this does it work correctly.

\usepackage[notes,backend=biber]{biblatex-chicago}

Bruce



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

2021-05-20 Thread Thomas S. Dye

Interested lurker here.  From the biblatex-chicago manual:

"You can load the package via the usual \usepackage{biblatex}, 
adding either style=chicago-notes or style=chicago-authordate"


All the best,
Tom

Denis Maier  writes:


Hi,

Am 20.05.2021 um 19:06 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:

On Thu, May 20, 2021 at 9:57 AM Denis Maier 
 wrote:


I'm not really sure we need bare substyles at all. At least 
in biblatex

it's the basis for the other commands.


Though see my followup message on autocite config.

Does that change this discussion?


Why?


I put it in the form of a question, because I'm not sure, but 
...


1. I wasn't sure Nicolas was aware of this config option, nor 
how one
would configure it currently (but it seems necessary in 
general)


There is `org-cite-biblatex-options' defcustom. Currently, it 
defaults
to nil, but you can set it to, e.g., "key=value,key2=value" if 
needed.

We can also change the default.


Is there a way to use styles that aren't loaded via biblatex 
package options,

but as distinct package. E.g., biblatex-chicago is loaded as
\usepackage{biblatex-chicago}. Internally, the package will then 
load biblatex

on its own.

Denis



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: [PATCH] LaTeX export: arbitrary float environments

2021-05-01 Thread Thomas S. Dye

Aloha Timothy,

Thanks for your kind response.

Sorry for the clumsy patch, which I guess would also benefit from 
an addition to the manual, as well?


Larger question: do we really want to tinker with ob-latex in this 
way?  Or, should changes like this patch follow a path indicated 
by Tim Cross and into their own package, say ob-latex-ex, which 
might someday replace ob-latex if it proved useful and stable?


All the best,
Tom

Timothy  writes:


Hi Thomas,

On the surface, this looks reasonable to me :)

Just commenting on some technicalities with the patch itself:
- In ORG-NEWS it would be good to wrap the content over multiple 
lines

  instead of having a single 270 char line :)
- You seem to have an anomalous change to the ob-python :return 
entry
- I don't think your patch subject follows the convention for 
Org, it

  should be:
  "main file/feature: overall change summary"
  so, something like
  "ox-latex: allow for arbitrary float environments"
  rather than
  "LaTeX export: arbitrary float environments"

Thanks for the patch :)

Timothy



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: List of ob-* maintainers

2021-04-21 Thread Thomas S. Dye

Aloha Kyle,

Done.  Thanks.

There are quite a few unmaintained languages in core.

All the best,
Tom

Kyle Meyer  writes:


Thomas S. Dye writes:


Aloha Kyle,

Thanks for this.  I think the Worg list might be useful to
indicate which languages don't have maintainers. Or, is the
information in the source files sufficient?


I don't know, but adding the information to the Worg table 
sounds fine

to me.

Thanks.



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: List of ob-* maintainers

2021-04-19 Thread Thomas S. Dye

Aloha Kyle,

Thanks for this.  I think the Worg list might be useful to 
indicate which languages don't have maintainers. Or, is the 
information in the source files sufficient?  I'm happy not to work 
on the Worg table in that case.


All the best,
Tom

Kyle Meyer  writes:


Thomas S. Dye writes:


Aloha all,

Is there a list of current ob-* maintainers?


Bastien updated the "Maintainer" field of the source files:

  $ git grep -i maintainer lisp/ob-* | cut -d'<' -f1
  lisp/ob-C.el:;; Maintainer: Thierry Banel
  lisp/ob-J.el:;; Maintainer: Joseph Novakovich
  lisp/ob-R.el:;; Maintainer: Jeremie Juste
  lisp/ob-abc.el:;; Maintainer: William Waites
  lisp/ob-clojure.el:;; Maintainer: Bastien Guerry
  lisp/ob-dot.el:;; Maintainer: Justin Abrahms
  lisp/ob-eshell.el:;; Maintainer: stardiviner
  lisp/ob-groovy.el:;; Maintainer: Palak Mathur
  lisp/ob-haskell.el:;; Maintainer: Lawrence Bottorff
  lisp/ob-java.el:;; Maintainer: Ian Martins
  lisp/ob-mscgen.el:;; Maintainer: Justin Abrahms
  lisp/ob-perl.el:;; Maintainer: Corwin Brust
  lisp/ob-python.el:;; Maintainer: Jack Kamm
  lisp/ob-screen.el:;; Maintainer: Ken Mankoff

  $ git describe
  release_9.4.5-317-g3d5284326

The oldest addition is from September 2020, so that should be a 
fairly

current list.

Perhaps it would be useful to add and populate a Maintainer 
column to
the language table on Worg 
(org-contrib/babel/languages/index.html)?


Hmm, I suppose it's nice to have just one spot to avoid 
information
becoming out of sync, but that's a minor issue, so no objections 
from me
if you or others think it'd be helpful to have the information 
on Worg.



--
Thomas S. Dye
https://tsdye.online/tsdye



List of ob-* maintainers

2021-04-18 Thread Thomas S. Dye

Aloha all,

Is there a list of current ob-* maintainers?  Perhaps it would be 
useful to add and populate a Maintainer column to the language 
table on Worg (org-contrib/babel/languages/index.html)?


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye



Re: Concerns about community contributor support

2021-04-18 Thread Thomas S. Dye



Timothy  writes:


Thomas S. Dye  writes:


Hmmm, what constitutes noise?

Good question.  I suppose like most words the meaning changes 
over time.  Early
on, posts along the lines of "Wouldn't it be cool if Org mode 
would do this?"
were given more space than they seem to be today.  Tim Cross 
points out a
project trajectory that appears to be common and would explain 
why.  At a more

concrete level, I can offer several of my posts to the list :)


Follow up: What should be the response to "noise", because I 
don't think

it should be a cold shoulder.

Agreed.  I'm trying to put myself in the maintainers' shoes.  They 
volunteer lots of highly skilled time, which I admire greatly.  I 
can imagine a situation where a patch falls outside a maintainer's 
interest and they have difficulty finding the time to understand 
it and offer a meaningful critique.


Historical note: when Carsten took his leave and announced Bastien 
would maintain Org mode, I jumped in noisily to suggest that a 
committee approach might be better.  I couldn't imagine a world 
with two Carstens!  It appears there is a committee of sorts now, 
though I'm in the dark how it is organized.  Assuming there is a 
committee, perhaps addition of an Initial Patch Reviewer might be 
a good idea?


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye



Re: Concerns about community contributor support

2021-04-18 Thread Thomas S. Dye



Timothy  writes:


, but Org mode development is
in a new phase that *requires* technique and is quicker to 
identify and filter

out noise.


Hmmm, what constitutes noise?

Good question.  I suppose like most words the meaning changes over 
time.  Early on, posts along the lines of "Wouldn't it be cool if 
Org mode would do this?" were given more space than they seem to 
be today.  Tim Cross points out a project trajectory that appears 
to be common and would explain why.  At a more concrete level, I 
can offer several of my posts to the list :)


These changes mean that contributions need to be checked for 
contributions to
Nicolas' project and also fit into the history of discussion 
and development.
The Org mode project now resembles a scholarly discipline that 
moves slowly and
deliberately toward a more or less well defined goal.  The days 
when Carsten
would bang out a new feature during his train ride home from 
work are gone.


I think here there may have been a minor misunderstanding
/miscommunication. Reading this paragraph I get the sense you 
read my
email as complaining about a delay in merging patches, however 
this is a

separate ---if related--- point to what I intended to raise: the
lack of /response/ to patches.

1. Were I talking about merging: a more considered development 
model, as
   you describe above, can certainly see a protracted merge 
   delay.
   However, 6 months for a minor feature addition [1], and 2 
   months for
   a minor bug fix [2] is not justified by a more considered 
   development

   model IMO.
2. (My main point) Even if development is slower, leaving a 
first-time
   contributor with /absolutely no response/, i.e. *zero* 
   replies to
   their email *months* after they sent it (see [1] and [2] for 
   example,
   and updates.orgmode.org for more) is not good enough IMO. We 
   should

   be better.

So, something in between merging (or not) and appearing on the 
public list that Bastien keeps?



Once again, with reference to my earlier paragraph, IMO slowed
development is one thing, not responding at all to attempted
contributors for months on end another. It is the latter which I 
seek to
improve. I can, have, and will try to help with this myself; but 
I think
we would benefit from a "community effort" and a discussion on 
what the

best way to improve this is.



What do you think of Tim Cross' suggestion that a way forward is 
for "new features and enhancements to be initially implemented as 
add on contribution packages rather than as extensions/enhancement 
to the core 'org-mode' package"? This sounds good to me, but I'm 
not much of a programmer and lack the ability to suss out its 
ramifications fully.  I can see how it would ease Org mode 
maintenance, though.


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye



Re: Concerns about community contributor support

2021-04-17 Thread Thomas S. Dye
nkfully, I received prompt and 
friendly
feedback and was guided through the adjustments needed so it 
could be
merged in a timely manner. Should my patch have been similarly 
ignored,
I would have been quite disheartened; it is not an overstatement 
to say
I would likely have written off this mailing list and not tried 
again.


Simply put, this is not good enough. This does a disservice to 
those
that have dedicated time and effort to try and better this 
project only

to be ignored. Not rejected, not even acknowledged, nothing.

It is imperative that this community improves our response to
contributions for the long-term health of this project. Do not 
take me
to be a doomsayer; I have faith that Org is going to keep on 
improving
regardless. However, failing to welcome and encourage 
contributors has a

deleterious effect on the health of the project.

I do not blame the maintainers in the slightest. As Bastien 
brought up
in a recent worg discussion, as time goes on we find ourselves 
taking on
more and more life responsibilities. Therefore it's in our best 
interest
to delegate some of the maintainer responsibilities to 
consistently
active, and supportive community members to "pass down the 
torch" so the
community and platform can continue to expand with grace and 
care.


What can the community do?

I don't know of any silver bullet, but I believe there are some 
steps

which could help, namely:
+ The development and publication of "reasonable expectations" 
which

  contributors should have when submitting a patch, and that the
  maintainers should strive to uphold (e.g. "expect a response 
  within

  ").
+ A community effort/sprint to respond to those patches that 
have been

  seemingly abandoned
+ Onboarding of new maintainers, when reasonable and suitable 
candidates
  exist (I'd very willingly throw my hat in the ring for 
  consideration).

  If it's too much work, spread it out as much as possible.

If any other ideas come to mind, please share them so we can 
discuss

them further.

Finally, it's not all bad.

While this discussion has called for some criticism, I don't 
want to
give the false impression that I think nothing is working and 
nobody is
supporting contributors. This is not the case at all, there are 
some
standout individuals one the mailing list who have been 
fantastic. Kudos

to you all.

My best to everyone,

Timothy

[1] 
https://orgmode.org/list/caoywxzg1cbl07thlzxhbbczm6te2vmtqnmm0w63331gybrj...@mail.gmail.com/

[2] https://orgmode.org/list/87h7qi2l2m@gmail.com/



--
Thomas S. Dye
https://tsdye.online/tsdye



[PATCH] LaTeX export: arbitrary float environments

2021-04-04 Thread Thomas S. Dye

Aloha all,

LaTeX users are able to define arbitrary float types, e.g. with 
the float package.  The attached patch makes them accessible from 
Org mode.


This is a follow on to my efforts several years ago to support the 
Tufte-LaTeX package in Org mode, and a suggestion at the time (by 
Rasmus iirc) to implement an :environment attribute for LaTeX 
export.  This patch achieves a similar goal, but is a bit lighter 
imo.


Let me know if you have questions.

All the best,
Tom
>From 5154901b781f93d08851f96431c976f010fc420c Mon Sep 17 00:00:00 2001
From: "Thomas S. Dye" 
Date: Sun, 4 Apr 2021 08:11:40 -1000
Subject: [PATCH] LaTeX export: arbitrary float environments

* lisp/ox-latex.el (`org-latex--inline-image', `org-latex--decorate
table'): recognize arbitrary :float value.

LaTeX users are able to define arbitrary float types.  This patch
makes them accessible from Org mode.

* etc/ORG-NEWS: Announce new :float capability.
---
 etc/ORG-NEWS |  6 +-
 lisp/ox-latex.el | 16 +++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9fc126b2f..cdfb1c727 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -12,6 +12,10 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.5 (not yet released)
 ** New options and settings
+*** LaTeX attribute ~:float~ now passes through arbitrary values
+
+LaTeX users are able to define arbitrary float types, e.g. with the float package.  The Org mode LaTeX exporter is now able to process and export arbitrary float types.  The user is responsible for ensuring that Org mode configures LaTeX to process any new float type.
+
 *** Option ~org-hidden-keywords~ now also applies to #+SUBTITLE:
 
 The option ~org-hidden-keywords~ previously applied
@@ -106,7 +110,7 @@ behavior.
 By default ox-html now inlines webp images.
 
 ** New features
-*** =ob-python= improvements to =:return= header argument 
+*** =ob-python= improvements to =:return= header argument
 
 The =:return= header argument in =ob-python= now works for session
 blocks as well as non-session blocks.  Also, it now works with the
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 376d27a07..514801d7c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2377,6 +2377,7 @@ used as a communication channel."
 			((string= float "sideways") 'sideways)
 			((string= float "multicolumn") 'multicolumn)
 			((and (plist-member attr :float) (not float)) 'nonfloat)
+(float float)
 			((or float
 			 (org-element-property :caption parent)
 			 (org-string-nw-p (plist-get attr :caption)))
@@ -2470,6 +2471,18 @@ used as a communication channel."
 		   nil t
 ;; Return proper string, depending on FLOAT.
 (pcase float
+  ((and (pred stringp) env-string)
+   (format "\\begin{%s}%s
+%s%s
+%s%s
+%s\\end{%s}"
+   env-string
+   placement
+   (if caption-above-p caption "")
+   (if center "\\centering" "")
+   comment-include image-code
+   (if caption-above-p "" caption)
+   env-string))
   (`wrap (format "\\begin{wrapfigure}%s
 %s%s
 %s%s
@@ -3200,7 +3213,7 @@ centered."
 (defun org-latex--decorate-table (table attributes caption above? info)
   "Decorate TABLE string with caption and float environment.
 
-ATTRIBUTES is the plist containing is LaTeX attributes.  CAPTION
+ATTRIBUTES is the plist containing LaTeX attributes.  CAPTION
 is its caption, as a string or nil.  It is located above the
 table if ABOVE? is non-nil.  INFO is the plist containing current
 export parameters.
@@ -3211,6 +3224,7 @@ Return new environment, as a string."
 	(cond ((and (not float) (plist-member attributes :float)) nil)
 		  ((member float '("sidewaystable" "sideways")) "sidewaystable")
 		  ((equal float "multicolumn") "table*")
+  (float float)
 		  ((or float (org-string-nw-p caption)) "table")
 		  (t nil
 	 (placement
-- 
2.25.1



--
Thomas S. Dye
https://tsdye.online/tsdye


Re: About exporting

2021-03-29 Thread Thomas S. Dye

Aloha Ypo,

"Exporting for life" is a vague target, so it is difficult to give 
precise recommendations.


It is usually the case that export to LaTeX doesn't require 
subsequent modification of the tex file.  In most cases for my 
work, I am exporting to a LaTeX document style/class provided by 
someone else.  This is fairly typical of the LaTeX world, where 
academic journals and university degree programs design their own 
in-house styles and then ask authors to use them.  The idea behind 
LaTeX is that LaTeX defines the meaningful units of a document 
(headers, paragraphs, quotes, etc.) so that a single LaTeX 
document can be exported to multiple targets, each of which styles 
the document units in its own way.  Because Org mode targets 
LaTeX, and not a particular style, this means that Org mode 
inherits LaTeX's style agnosticism.


Of course, there are exceptions to this general rule, where a 
LaTeX class/style defines document units that extend the LaTeX 
spec.  It can be tricky to get Org mode to export to one of these 
non-standard styles.


If you intend to create documents with bibliographies, then IMHO 
LaTeX export is the best choice.  BibTeX defines a plain text 
bibliographic database that is very widely used and capable of 
meeting the most exact bibliographic requirements.  John Kitchin 
has written org-ref to manage BibTeX databases from Org mode, and 
Joost Kremers has ebib, which integrates nicely with Org mode and 
accomplishes many of the same tasks covered by org-ref.  A native 
Org mode bibliographic solution has been discussed for many years 
and there is an org-cite branch that is a nearly complete work in 
progress.  This will be designed to use Citation Style Language, 
rather than BibTeX, which means (at least currently IIUC) that 
there will be somewhat less fine control over bibliographic 
format, although there are thousands of CSL style definitions, 
which presumably cover all the most likely targets.  In my 
experience, CSL approximates most bibliographic styles, rather 
than producing them exactly, so YMMV.


Even without the need for bibliographies, LaTeX might be your best 
choice.  In my field, most of the journals *require* an MS Word 
document, a practice that gives me no end of heartburn.  I've 
found that export to LaTeX followed by conversion with the Haskell 
program pandoc gives the best results.  Pandoc is pretty nifty, 
with conversion among quite a few different formats.  LaTeX 
provides a rich input, which pandoc handles really well.


hth,
Tom


Ypo writes:


Hi

After some years of using orgmode, and exporting using its 
defaults, I would
like to take a quality leap and find a way of exporting for 
life. My options:

LaTeX, ODT, HTML.

LaTeX: I can see some masters here that make professional books, 
and I have some
friends that publish scientific papers using LaTeX. But, it 
looks like a like a
rabbit hole to me, since even the masters seem to have to modify 
the tex file
directly (is this correct?), not being sufficient orgmode to 
culminate the work
by itself. And to learn LaTeX seems a lifelong activity (almost 
like "learning"
orgmode). BTW, when I export to LaTeX although it gets the job 
done, it sends a

lot of error messages.

ODT: I take this one as a lower level solution than LaTeX, but 
it looks easier
to tame, and it even allows to use templates,  for example to 
make reports in
the workplace. Do you think it is worth focusing on ODT 
exporting? Could it be a
definitive solution to publish papers and books directly from 
orgmode? ODT
exporting sends some error message to me, but at least I 
understand it.


HTML: I have seen some themes
<https://olmon.gitlab.io/org-themes/latexcss/latexcss.html> 
designed to export
in LaTeX format using HTML. Here we would have the "definitive 
tool": The power
of LaTeX in the versatility that could give the use of different 
themes for
different purposes. But, do you think it could get, some day, 
the quality of a
direct LaTeX export? No errors by my side when exporting to 
HTML.


How do you think I should spend some hundreds (or thousands) of 
hours to achieve

maestry exporting my documents?

Best regards.



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: source blocks DAG evaluation

2021-03-21 Thread Thomas S. Dye

Aloha c4to,

I would be tempted to use noweb expansion here.

#+name: libB
#+begin_src scheme :results none :noweb yes
<>
(define greetings (string-append hi ", " "to all the people!"))
#+end_src

#+begin_src scheme :session example :results output :noweb yes
<>
(display greetings)
#+end_src

Does this do what you want?

All the best,
Tom

c4t0 writes:


Hi,

Is it possible to have a dependency hierarchy of source blocks?

i.e.: in C, if you use libA from a compilation unit and that 
library needs libB, you don't need to include it in main.c


-> main.c
#include "libB.h"
-> libB.c
#include "libA.h"

you don't need to:
-> main.c
#include "libB.h"
#include "libA.h"

because library headers are closed under inclusion.

I haven't succeeded in doing the same in org-mode. Even after 
populating org-babel-library-of-babel.


Using #+call just doesn't work. Using :var is better, evaluates 
all, but there appears to lack session support, it doesn't check 
for cycles and it feels a little hacky


With #+call I need to do it like this:

#+name: libA
#+begin_src scheme :results none
(define hi "hello")
#+end_src

#+name: libB
#+begin_src scheme :results none
(define greetings (string-append hi ", " "to all the people!"))
#+end_src

here is my "main" I need to C-c C-c in each #+call line and 
write the :session that the code block uses in each one, and do 
it in the correct order. If I C-c C-c in libB first it won't 
eval because 'hi' is not defined.


#+call: libB[:session example]
#+call: libA[:session example]
#+begin_src scheme :session example :results output
(display greetings)
#+end_src

source blocks can be #+call(ed) but aren't closed under #+call 
(a source block can be called but then the callee won't)


instead I would like to :

#+name: libA
#+begin_src scheme :results none
(define hi "hello")
#+end_src

#+call: libA
#+name: libB
#+begin_src scheme :results none
(define greetings (string-append hi ", " "to all the people!"))
#+end_src

#+call: libB
#+begin_src scheme :session example :results output
(display greetings)
#+end_src

- there shouldn't be needed to C-c C-c in the #+call line, 
evaluating the source block alone should suffice.

- there shouldn't be a need to write the :session
  - it should use the session of the user evaled block, unless 
  specified otherwise


In the other hand, using :var with a dummy variable:

#+name: libA
#+begin_src scheme :results none
(define hi "hello")
#+end_src

#+name: libB
#+begin_src scheme :results none :var _=libA
(define greetings (string-append hi ", " "to all the people!"))
#+end_src

#+HEADER: :var _=libB
#+begin_src scheme :session example :results output
(display greetings)
#+end_src

It evals libA then libB and finally the (display greetings) 
code.
But it fails, because the :session example is ignored. Even if I 
add a :session example to every source block (which would be 
really bad, sessión must be decided by the consumer) it doesn't 
work. I think that is because :var expects a value, so it just 
opens a new session to evaluate code every time.


Besides if there are any dependency cycles, it just fails with: 
Lisp nesting exceeds ‘max-lisp-eval-depth’


So if I'm right and there is not an implemented way to do this, 
how can we do it? Adding session support for :var? constructing 
a DAG of #+calls and then evaluating in order? maybe using a new 
header?


COD.



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: Outdated instructions for Org-babel-abc

2021-03-05 Thread Thomas S. Dye

Done.  Thanks.

All the best,
Tom

Wade McReynolds writes:

The babel-languages setup instructions for ABC list the outdated 
"sh t" where they should have "shell t".



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: Problem with custom links

2021-02-12 Thread Thomas S. Dye

Aloha Kyle,

Thanks for taking a look at this, and also for the instructions 
how to test.  I get the results you report.


Separately, off list, John Kitchin kindly noted that my symptoms 
might be caused by org-ref.  A bit of snooping led me to 
understand that org-ref was installed on my system as a dependency 
of emacs-reveal, so the mystery is solved.


I'm happy using the two new keywords; they seem to protect my 
setup from being changed by org-ref.


All the best,
Tom


Kyle Meyer writes:


Thomas S. Dye writes:


Aloha all,

Recently, custom links that I've used for years changed their
behavior.  They used to behave like other org mode links, but 
now
they are displayed in a different color face and are always 
fully

displayed, unless I add two new keywords to
org-link-set-parameters.

  (org-link-set-parameters
   "parencite"

[...]

   :display 'org-link
   :face 'org-link)


I tried this snippet, dropping the :display and :face arguments

  (org-link-set-parameters
   "parencite"
   :follow 'org-ebib-open
   :export (lambda (path desc format)
 (cond
  ((eq format 'html)
   (format "(%s)" path))
  ((eq format 'latex)
   (if (or (not desc) (equal 0 (search "parencite:"
   desc)))
   (format "\\parencite{%s}" path)
 (format "\\parencite[%s][%s]{%s}"
 (cadr (split-string desc ";"))
 (car (split-string desc ";")) 
 path))


with the following buffer:

  [[parencite:foo][bar]]

With an otherwise default configuration and the current master
(49364f904), the link gets fontified with the org-link face and
displayed as just "bar".  So, that seems to be behaving as 
expected and
I don't spot any relevant code change to the handling of the 
defaults in

org-activate-links.

Have you tried to trigger it without any additional 
configuration?



--
Thomas S. Dye
https://tsdye.online/tsdye



Problem with custom links

2021-02-08 Thread Thomas S. Dye

Aloha all,

Recently, custom links that I've used for years changed their 
behavior.  They used to behave like other org mode links, but now 
they are displayed in a different color face and are always fully 
displayed, unless I add two new keywords to 
org-link-set-parameters.


 (org-link-set-parameters
  "parencite"
  :follow 'org-ebib-open
  :export (lambda (path desc format)
(cond
 ((eq format 'html)
  (format "(%s)" path))
 ((eq format 'latex)
  (if (or (not desc) (equal 0 (search "parencite:" 
  desc)))

  (format "\\parencite{%s}" path)
(format "\\parencite[%s][%s]{%s}"
(cadr (split-string desc ";"))
(car (split-string desc ";")) path)
  :display 'org-link
  :face 'org-link)

I added the :display and :face keywords after I stumbled upon a 
list of defined links (which I wish I'd noted because I haven't 
found it since) that indicated that :display was set to 'full 
(which confused me because I'd read that the default was supposed 
to be 'org-link).  Adding these two keywords restores the original 
behavior for me.


I'm wondering why I have to set these keywords to get the default 
behavior?


I did search ORG-NEWS for a relevant entry, but didn't see 
anything that rang a bell.


I hope you and yours are well in the face of the pandemic.

Let me know if you have questions.

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye



Re: a few dead links on the babel languages page

2021-01-03 Thread Thomas S. Dye

Aloha,

These should be fixed now.

Thanks,
Tom

Greg Minshall writes:


hi.  here are a few dead links from
https://orgmode.org/worg/org-contrib/babel/languages/index.html

- http://ditaa.org/ditaa/
  - ? s/b http://ditaa.sourceforge.net/

- http://www.mathomatic.org/

- http://www.mozart-oz.org/

cheers, Greg



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: [TIP] Export to LaTeX and HTML with a watermark

2020-12-22 Thread Thomas S. Dye

Nice!

This is the kind of thing I like to find here: 
https://orgmode.org/worg/org-hacks.html


Please consider adding it to Worg!

All the best,
Tom

Juan Manuel Macías writes:


Hi,

Recently, I needed to export a document to both LaTeX and HTML 
with a
watermark background. I came to write this little function (for 
LaTeX,
the 'draftwatermark' package is used; for html, a bit of CSS. 
The
optional arg `text' is the text of the watermark; by default 
what is

printed is "DRAFT"):

#+begin_src org
  ,#+begin_src emacs-lisp :exports results :results none
(defun my-watermark ( text)
  (cond ((org-export-derived-backend-p 
  org-export-current-backend 'latex)

 (concat "#+LaTeX_Header:\\usepackage"
 (if text
			 (format "[text=%s]" (replace-regexp-in-string " " "~" 
text))

   "")
 "{draftwatermark}"))
	((org-export-derived-backend-p org-export-current-backend 
'html)

 (concat "@@html:"
 (if text
 (format "%s" text)
   "DRAFT")
 "@@"

  ,#+end_src
#+end_src

The CSS could be (source:
https://stackoverflow.com/questions/68569/text-watermark-on-website-how-to-do-it):

#+begin_src org
  ,#+html_HEAD: #watermark {color: #d0d0d0; font-size: 
</tt><tt>  200pt; -webkit-transform: rotate(-45deg); -moz-transform: 
</tt><tt>  rotate(-45deg); position: absolute; width: 100%; height: 100%; 
</tt><tt>  margin: 0; z-index: -1; left:-100px; top:-200px;}

#+end_src

And then, this replacement macro:

#+begin_src org
  ,#+MACRO: wmark (eval (if (org-string-nw-p $1)(my-watermark 
  $1)(my-watermark)))

#+end_src

And finally, an example:

#+begin_src org
  {{{wmark(Top secret!)}}}

  Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
  accumsan nisl.

  (...)
#+end_src

Regards,

Juan Manuel



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: basic org questions

2020-09-16 Thread Thomas S. Dye
Yes, of course.  But first you need to write a style or class 
file.


All the best,
Tom

Emanuel Berg via General discussions about Org-mode. writes:


Thomas S Dye wrote:


There are many pieces of software that will allow
the user to the violate best typesetting practices
easily. LaTeX is not one of them.


In my experience, you can typeset whatever you want
with LaTeX, and in any way that you want.

non-fiction book:

  https://dataswamp.org/~incal/borta/borta.pdf

math teacher ad:

  https://dataswamp.org/~incal/about/matte.pdf

university paper:

  https://dataswamp.org/~incal/hs-linux/docs/report/report.pdf

(don't even remember what this was supposed to be)

  https://dataswamp.org/~incal/fps/cis/task_flow_demo.pdf



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: basic org questions

2020-09-16 Thread Thomas S. Dye

This is the unix design: let each tool do what it does well.

LaTeX decides how to format and align tables, and it does this 
very well.  Nevertheless, it does this at the level of the 
document class, which decides how tables are formatted and aligned 
for the whole document.  The idea of having a user decide table 
formatting and alignment on a case by case basis is completely 
foreign to the design of LaTeX.  It is also completely foreign to 
the best practices of book design.


There are many pieces of software that will allow the user to the 
violate best typesetting practices easily.  LaTeX is not one of 
them.


hth,
Tom

Emanuel Berg writes:


Matt Huszagh wrote:


Yes, after export to PDF, they are centered.
they = the whole table items.


I think this link
(https://orgmode.org/manual/Tables-in-LaTeX-export.html)
is the relevant part of the documentation.


Yeah, but in LaTeX being left aligned is not some
property of the table, everything is left-aligned,
and if you want it otherwise, you put between
\begin{center} and \end{center} ...



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: Can you automatically noweb include?

2020-08-07 Thread Thomas S. Dye
It works here if you remove the blank line between the headline 
and the PROPERTIES block.


William McCoy writes:


Chuck,

Thanks very much for your response.  I didn't know about those 
options.  When I

use C-c C-v C-i, I get the following:

Lang: python
Properties:
:header-argsnil
:header-args:python nil
Header Arguments:
:cache  no
:exportscode
:hlines no
:noweb  no
:resultsoutput replace
:sessionnone
:tangle no

And C-c C-v C-v, shows that the import statements in the header 
do not get

expanded into the code block.

So I am obviously doing something wrong.  There appear to be no 
typos or
misspellings and the org file containing the coded is exactly 
this:


* Test of prologue header

:PROPERTIES:
:header-args:python+: :prologue "import numpy as np; import os"
:END:

#+BEGIN_SRC python :results output
print(np.__version__)
#+END_SRC

#+RESULTS:


My init file has no org babel header arguments defined.

I am using C-c C-v C-b or C-c C-v C-s to evaluate and I get

"Code block produced no output." in the mini-buffer.


If I use C-c C-c directly on the code block itself I get:

Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'np' is not defined

Is there something else I need to do to get babel to recognize 
the header-args?


Thanks


On 8/7/20 12:51 PM, Berry, Charles wrote:


On Aug 7, 2020, at 8:39 AM, William McCoy  
wrote:


This use of :prologue appeared to me to be very useful.  But 
for some reason when I try it out it does not work for me.  I 
just get a message that the code block produced no output and 
that 'np' is not defined.  Just to check, when I put the 
import statements directly within my code block it works fine.


I am running:  Org mode version 9.3.7 (9.3.7-16-g521d7f-elpa

Any idea what I'm doing wrong?


It is sometimes useful to use C-c C-v C-i to see what header 
args org has detected for a source block. Misspelled words 
sometimes wreak havoc and invisible characters can cause real 
pain.



Also, it helps to use C-c C-v C-v to to see the expanded code 
block. When I do this with Kens' ECM, I get


import numpy as np; import os
print(np.__version__)

in the preview buffer.

HTH,

Chuck



On 8/6/20 2:12 PM, Ken Mankoff wrote:

Actual example:


* Prologue test
:PROPERTIES:
:header-args:python+: :prologue "import numpy as np; import 
os"

:END:

#+BEGIN_SRC python :results output
print(np.__version__)
#+END_SRC

#+RESULTS:
: 1.18.4




On Wed, Aug 5, 2020 at 3:03 PM Ken Mankoff 
 wrote:
What about using :pre or :prologue and setting it at the 
header or document level?


Please excuse brevity. Sent from tiny pocket computer with 
non-haptic-feedback keyboard.


On Wed, Aug 5, 2020, 14:22 George Mauer  
wrote:

Use case:

I'm using ob-racket but this would apply just as well to a 
few other workflows I have with python or js.


I would like to write a helper function in a src block and 
then automatically have access to it in other src blocks 
further down the document. I don't really want a stateful 
session (nor does ob-racket support sessions) so I 
essentially want the equivalent of automatically including it 
everywhere so I don't have to type it out all the time (and 
have it screw up syntax coloring/indentation).


Is this currently possible? Does anyone have any ideas for 
how to extend things so it is?





--
Thomas S. Dye
https://tsdye.online/tsdye



Re: [PATCH] Add margin option to float for figure in ox-latex.el

2020-05-17 Thread Thomas S. Dye

Aloha Kyle,

Barring a guru's user-end customization, Rasmus's figure 
:environment attribute idea is a good one.


The LaTeX float package has a facility to create and name 
environments that are handled like figures.  A figure :environment 
attribute in Org mode would provide a straightforward and flexible 
path to transcode them.


Thanks for looking into this.

Let me know if you have questions.

All the best,
Tom

Kyle Meyer writes:


Thomas S. Dye writes:

This patch produces a LaTeX environment, marginfigure, that 
isn't

part of the standard.  AFAIK, marginfigure is defined in the
sidenotes package and separately in the tufte-latex class, 
neither
of which Org mode loads by default.  If the patch is applied, 
then
one of these packages should be added to the list of default 
LaTeX
packages so ox-latex doesn't export code it is unable to 
compile.


My takeaway from the discussion surrounding ox-tufte-latex 
several
years ago is that support for non-standard LaTeX constructs 
should
not be part of Org mode core because they complicate 
maintenance

unduly.


Thanks for your input and the helpful summary.  The stance in 
the second

paragraph sounds like a sensible one.

Given the desire to use the marginfigure environment has popped 
up a few
times, I wonder if an ox-latex guru can suggest a user-end 
customization
that would enable the use of that environment.  I suppose an 
alternative
is Rasmus's proposal of an :environment attribute for figures 
[*] that I

mentioned in a sibling thread.

[*]: https://yhetil.org/orgmode/878u31ycc5@gmx.us/



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: [PATCH] Add margin option to float for figure in ox-latex.el

2020-05-16 Thread Thomas S. Dye

Aloha Kyle,

This patch produces a LaTeX environment, marginfigure, that isn't 
part of the standard.  AFAIK, marginfigure is defined in the 
sidenotes package and separately in the tufte-latex class, neither 
of which Org mode loads by default.  If the patch is applied, then 
one of these packages should be added to the list of default LaTeX 
packages so ox-latex doesn't export code it is unable to compile.


My takeaway from the discussion surrounding ox-tufte-latex several 
years ago is that support for non-standard LaTeX constructs should 
not be part of Org mode core because they complicate maintenance 
unduly.


I haven't used ox-tufte-latex since I last used paper handouts at 
a presentation several years ago, so I don't know if it still 
works.  However, it really was cobbled together, a process that 
involved copying big chunks of Org mode code.  I knew then this 
approach is sub-optimal, but never found the time to puzzle out 
how to turn it into advice that could sit on top of a possibly 
changing code base.


Also, FYI, I found the tufte-latex class a bit difficult to use. 
Objects in the margin can easily overwrite one another and the 
author has to fix these manually, which can be tricky.  The upside 
is that when everything is right, the output can be terrific to 
look at.


All the best,
Tom

Kyle Meyer writes:


Pablo Palazon writes:

I've created a path to add a new option to float properties for 
figures on
latex. This is my first change for org-mode, and I don't really 
sure if

this is the correct way to do it.


Thank you!

* lisp/ox-latex.el (org-latex--inline-image): Include margin 
option
to create marginfigure environment for figures. It's useful for 
tufte
latex class, where with this environment shows the figure in 
the margin.


I wondered if something like this had been proposed or discussed 
before.
Searching the list, I see a patch [0] very similar to yours from 
a
couple of months back that didn't get a response (author added 
to cc).


Further back, there is a thread about an exporter Thomas Dye 
(+cc) wrote
to handle marginfigure and some other Tufte-y things [1].  It 
looks like
the code is available at 
<https://github.com/tsdye/tufte-org-mode>,

though I'm not sure if it still works with the current Org.

As for the proposed patch, while I think the specific code 
change itself
looks fine, skimming through the above thread makes me think 
that adding
marginfigure to ox-latex.el without considering similar cases 
may not be

the right approach.  What do others think?


[0]: 
https://yhetil.org/orgmode/35aac187-b751-5723-0f15-be6605fb8...@free.fr/

[1]: https://yhetil.org/orgmode/m2h9hsgdo2@tsdye.com/



--
Thomas S. Dye
https://tsdye.online/tsdye



Solved inline image problem from 2015

2020-04-14 Thread Thomas S. Dye

Aloha all,

Five (!) years ago, I came to the list with a problem toggling 
inline image display.  No matter what I did, images were displayed 
in the buffer.  Despite some good help from Rasmus, I wasn't able 
to solve the problem at that time.


A few years ago, I noticed the problem is restricted to png files, 
which I was exporting from R.  For a long while I solved the 
problem by not exporting png files :)


Recently, I needed png files again and ran into my old problem. 
Toggling inline images had no effect on the png files, which were 
always displayed in the buffer.


It appears the problem has to do with interlacing in the png file. 
I used ImageMagick to get rid of the interlacing --- mogrify 
-interlace none *.png.  Fixed!


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye



Re: rmarkdown-like production of multiple plots in org

2020-03-31 Thread Thomas S. Dye

Aloha Matt,

A guess based on my experience with ggplot2 is that the 
auto-naming and saving take place in the functions plot2() and 
plot4().  If so, then calling them from Org mode babel blocks will 
also get you auto-naming and saving.


I think you're right that you'll need to put each of the plots in 
its own babel source code block and then set up the html export to 
your satisfaction.  IIUC, these are the prices one pays for 
working in a system like Org mode which is both language agnostic 
and export target agnostic.  The rmarkdown/rstudio solution is 
nifty, but it is tied to one language and one export target.


hth,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye



Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-30 Thread Thomas S. Dye

Aloha Joost,

This link reflects my understanding of how properties accumulate, 
rather than overwrite: 
https://org-babel.readthedocs.io/en/latest/header-args/


hth,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye



Re: LaTeX export failure

2020-01-30 Thread Thomas S. Dye

Thanks Eric,

Good to know.  I'll try to track down the issue when I find time.

All the best,
Tom

Fraga, Eric writes:


On Wednesday, 29 Jan 2020 at 15:22, Thomas S. Dye wrote:

Here is the offending bit, which worked fine last November but
fails today:

 #+caption: Compare figure\nbsp{}[[fig:mqs3_op]].


This works fine for me.  Sorry; that probably doesn't help you
much... :-(



--
Thomas S. Dye
https://tsdye.online/tsdye



Re: LaTeX export failure

2020-01-29 Thread Thomas S. Dye

Thanks John,

IIRC, this isn't the first time you've recommended that I divide 
and conquer :)


Here is the offending bit, which worked fine last November but 
fails today:


#+caption: Compare figure\nbsp{}[[fig:mqs3_op]].

All the best,
Tom

John Hendy writes:

On Wed, Jan 29, 2020 at 2:32 PM Thomas S. Dye  
wrote:


Happy New Year!

Returning to a writing project after a few months absence, I'm 
no
longer able to export the writing project subtree.  Here is 
what I

find in *Messages*:

  Wrote /home/dk/Projects/historical-inference/r14c.org
  executing Shell code block...
  Wrote /tmp/babel-j0SOWm/ob-input-aS23DO
  Code block evaluation complete.
  match-string-no-properties: Args out of range: #  buffer>,

  3, 11



Are you able to share a portion of this? Or have you tried, say,
creating a copy of the file and removing all but the first 
heading and

a sentence to see if it fails?

Someone else might recognize that particular failure from past
experience, but I'd have to try something locally. In the past 
to
debug I've moved all headings after the first under a new one, 
marked
that as :noexport:, and exported iteratively, moving each one 
out of
the :noexport: heading until I find the offending one. Then I 
can hone

in on where I should be looking.

John


The writing project exported without issue on November 7, 2019.

I'm typically using up-to-date org-plus-contrib from Elpa, so
suspect my issue is due to a recent change in Org mode.

I don't know how to track down the problem.  Any ideas?

All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye




--
Thomas S. Dye
https://tsdye.online/tsdye



LaTeX export failure

2020-01-29 Thread Thomas S. Dye

Happy New Year!

Returning to a writing project after a few months absence, I'm no 
longer able to export the writing project subtree.  Here is what I 
find in *Messages*:


 Wrote /home/dk/Projects/historical-inference/r14c.org
 executing Shell code block...
 Wrote /tmp/babel-j0SOWm/ob-input-aS23DO
 Code block evaluation complete.
 match-string-no-properties: Args out of range: #, 
 3, 11


The writing project exported without issue on November 7, 2019.

I'm typically using up-to-date org-plus-contrib from Elpa, so 
suspect my issue is due to a recent change in Org mode.


I don't know how to track down the problem.  Any ideas?

All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye



Fwd: Re: Finally figuring out some ob-sqlite stuff -- for worg?

2019-11-09 Thread Thomas S. Dye

Cancel that, I was looking at a cached version of the page.

Thanks again for the documentation.

All the best,
Tom

Thomas S. Dye writes:

Okay, it's up. If anyone wants to explain to me the point of 
the

"where
exists" clause in the SQL, I would be interested to hear. It
works as
expected this way, but is that clause necessary?


The 'if exists' clause protects against an SQLite error raised 
if
you ask to delete a table that doesn't exist.  The code will 
work
without it if the table exists, but will exit without creating 
the

table if not.

Thanks for a useful addition to the Org babel SQLite
documentation.  I agree with you that Org mode tables are a
convenient way to enter SQL data, keeping in mind that table
columns can't be rearranged without changes to the SQL code.

All the best,
Tom



--
Thomas S. Dye
http://tsdye.online/tsdye



Re: Finally figuring out some ob-sqlite stuff -- for worg?

2019-11-09 Thread Thomas S. Dye



Okay, it's up. If anyone wants to explain to me the point of the 
"where
exists" clause in the SQL, I would be interested to hear. It 
works as

expected this way, but is that clause necessary?


The 'if exists' clause protects against an SQLite error raised if 
you ask to delete a table that doesn't exist.  The code will work 
without it if the table exists, but will exit without creating the 
table if not.


Thanks for a useful addition to the Org babel SQLite 
documentation.  I agree with you that Org mode tables are a 
convenient way to enter SQL data, keeping in mind that table 
columns can't be rearranged without changes to the SQL code.


All the best,
Tom

--
Thomas S. Dye
http://tsdye.online/tsdye



Re: Finally figuring out some ob-sqlite stuff -- for worg?

2019-11-07 Thread Thomas S. Dye

Aloha Eric,

Good news.  Yes, please feel free to update the Worg SQLite page.

IIRC, you can get permission from Bastien to push changes and then 
you can edit Worg at will.


All the best,
Tom

--
Thomas S. Dye
http://tsdye.online/tsdye



Re: [O] change font-size in python plots depending on context

2019-08-19 Thread Thomas S. Dye

Aloha Johanna May,

This works:

#+name: fs
#+BEGIN_SRC emacs-lisp
10
#+END_SRC

#+RESULTS: fs
: 10

#+header: :var fontsize=fs() :results output
#+begin_src python
print(fontsize)
#+end_src

#+RESULTS:
: 10

Note "fs()" instead of "fs".

All the best,
Tom

--
Thomas S. Dye
http://tsdye.online/tsdye



[O] noweb strip-export

2019-06-26 Thread Thomas S. Dye

Aloha all,

The noweb strip-export setting leaves empty lines in the export.

I have this ecm:

 #+name: foo
 #+begin_src elisp
 (+ 1 1)
 #+end_src

 #+name: bar
 #+header: :noweb strip-export
 #+begin_src elisp
 <>
 (+ 2 2)
 #+end_src

LaTeX export renders this:

 \begin{minted}[fontsize=\footnotesize]{elisp}
 (+ 1 1)
 \end{minted}

 \begin{minted}[fontsize=\footnotesize]{elisp}

 (+ 2 2)
 \end{minted}

Note the blank line before (+ 2 2).

I'd like this LaTeX output:

 \begin{minted}[fontsize=\footnotesize]{elisp}
 (+ 1 1)
 \end{minted}

 \begin{minted}[fontsize=\footnotesize]{elisp}
 (+ 2 2)
 \end{minted}

Is it possible?

All the best,
Tom

--
Thomas S. Dye
http://tsdye.online/tsdye



[O] Bug in LaTeX export?

2019-06-13 Thread Thomas S. Dye

Aloha all,

I have this in my Org mode file:

#+name: tab:hanamiai-oxcal-files
#+attr_latex: :font \footnotesize :environment longtable :booktabs
#+caption: =OxCal= input files for the Hanamiai models

And this in the exported LaTeX file:

{\footnotesize
\begin{longtable}{lll}
\caption{\label{tab:orgf695a5d}
\texttt{OxCal} input files for the Hanamiai models}
\\

The linebreak at the end of the \caption line introduces a space 
before the caption in the list of tables.  I can get rid of the 
space like this:


{\footnotesize
\begin{longtable}{lll}
\caption{\label{tab:orgf695a5d}%
\texttt{OxCal} input files for the Hanamiai models}
\\

Note the % at the end of the \caption line.

A bug, or something in my setup?

All the best,
Tom
--
Thomas S. Dye
http://tsdye.online/tsdye



Re: [O] Key bindings for Org export back-ends?

2019-02-08 Thread Thomas S. Dye

One place for the list of key bindings might be here:
https://orgmode.org/worg/exporters/index.html

All the best,
Tom


Re: [O] Bug: Babel :var order affects :colnames [9.2 (9.2-41-g010a35-elpaplus @/home/dk/.emacs.d/elpa/org-plus-contrib-20190122/)]

2019-01-28 Thread Thomas S. Dye

Aloha all,

Answering myself.  This bug is known and was discussed several years 
ago:


From: Myles English
Subject: Re: [O] babel R: should/does order of parameters matter?
Date: Tue, 29 Mar 2011 16:57:37 +0100

Apparently, ob-R wants tables to be passed to parameters that are early 
in the parameter list.


Also, ob-R expects all the cells in a table to be non-empty.  An empty 
table cell raises Cain.


Argh.

All the best,
Tom


Re: [O] Easy templates broken with 9.2

2019-01-27 Thread Thomas S. Dye

Aloha Chuck,

That is helpful.  Thanks.

All the best,
Tom


[O] Easy templates broken with 9.2

2019-01-27 Thread Thomas S. Dye

Aloha LB,

I'm working my way through this change, too, hunting down all the 
places I've modified org-structure-template-alist.  You'll need to get 
rid of the templates you've added to this list.  The new function won't 
run if it finds an old-style template on the list.


Once the list is clean, the new function offers the possibility of 
selecting some text, then hitting C-c C-, and choosing a structure that 
encloses the selected text.  This is quite handy.


I had a number of one-line templates that I haven't figured out how to 
replace yet.  Any suggestions are welcome.


hth,
Tom


[O] Bug: Babel :var order affects :colnames [9.2 (9.2-41-g010a35-elpaplus @ /home/dk/.emacs.d/elpa/org-plus-contrib-20190122/)]

2019-01-24 Thread Thomas S. Dye




Remember to cover the basics, that is, what you expected to happen 
and
what in fact did happen.  You don't know how to make a good 
report?  See


https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


I expect =colnames-bug-bad= to parse =test-table= like 
=colnames-bug-good=.  The only difference is the order of :var 
assignments.


 ECM
#+name: colnames-bug-bad
#+header: :var str="Foo" :var tab=test-table
#+header: :colnames yes
#+BEGIN_SRC R
data.frame(tab)
#+END_SRC

#+RESULTS: colnames-bug-bad
| cell.1 | cell.2 |
|+|

#+name: colnames-bug-good
#+header: :var tab=test-table :var str="Foo"
#+header: :colnames yes
#+BEGIN_SRC R
data.frame(tab)
#+END_SRC

#+RESULTS: colnames-bug-good
| head.1 | head.2 |
|+|
| cell.1 | cell.2 |

#+name: test-table
| head.1 | head.2 |
|+|
| cell.1 | cell.2 |

Let me know if you have questions.

All the best,
Tom


Emacs  : GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ 
Version 3.22.30)

of 2018-05-28
Package: Org mode version 9.2 (9.2-41-g010a35-elpaplus @ 
/home/dk/.emacs.d/elpa/org-plus-contrib-20190122/)

--
Thomas S. Dye
http://tsdye.online/tsdye



Re: [O] typo, sp at C++ Source Code Blocks in Org Mode

2018-11-10 Thread Thomas S. Dye

Aloha Van L,


On Sat, Nov 10, 2018 at 12:17 AM, Van L  wrote:


 AFAIK there is no mechanism to have changes in  one propagate 
changes in the other.


It should be possible to link the two because both are org files.

Worg would need to render to info:worg.


That's an interesting idea.  AFAICT it should be possible.  
Nevertheless, my guess is that it would be a lot of work to mark up the 
Worg sources to get well-formatted info output.


All the best,
Tom


Re: [O] typo, sp at C++ Source Code Blocks in Org Mode

2018-11-09 Thread Thomas S. Dye

Aloha Van L,

Thanks for your contribution.

The Org mode manual and Worg are separate documents.  AFAIK there is no 
mechanism to have changes in  one propagate changes in the other.


If you'd like to propose a change to the manual, please submit a patch 
following the instructions here: 
https://orgmode.org/worg/org-contribute.html.


All the best,
Tom


Re: [O] typo, sp at C++ Source Code Blocks in Org Mode

2018-11-05 Thread Thomas S. Dye

Aloha  Van L,

Worg is maintained by the community.  You can find information on how 
to make these changes yourself:


https://orgmode.org/worg/worg-git.html

Thanks for your interest in Org mode and Worg.

All the best,
Tom




[O] ox-hugo-like "DWIM" cope for other exporters?

2018-09-29 Thread Thomas S. Dye

Aloha Matt,

I've often wished LaTeX export had this capability.  I'd certainly be 
happy if this were a feature of all the exporters.


All the best,
Tom


Re: [O] ox-hugo, 2 questions

2018-06-09 Thread Thomas S. Dye

Aloha Kaushal,

Kaushal Modi writes:


It's difficult to tell. Can you share a git repo with a minimal 
site (just
the config.toml and the Org content files would do). I will try 
reproducing
the issue locally using ox-hugo plus the ox-hugo test site 
theme:

https://github.com/kaushalmodi/hugo-bare-min-theme.

I have a "sandbox" site where you can see an example of _index. 
See for

"_index" here:
https://gitlab.com/kaushalmodi/hugo-sandbox/raw/master/content-org/sandbox.org.
That example also happens to have an image on the home page, 
though I am
inserting that image in the layout file itself using the 
.Resources Hugo

method.

Here is the outcome: https://hugo-sandbox.netlify.com/.


Many thanks for this kind offer.  Will do, if I can't figure it 
out.


Just putting this custom figure.html in your site's 
layouts/shortcodes/
directory (which will override the inbuilt figure shortcode) 
will fix this

second issue.


Yes, it works like magic!

Hope this helps. For future, you can ask ox-hugo questions 
directly at

https://github.com/kaushalmodi/ox-hugo/issues.

I don't mind Hugo-related questions there too. But just so that 
you know
the Hugo Discourse forum is pretty active too: 
https://discourse.gohugo.io/.


OK, will do.

All the best,
Tom

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



[O] ox-hugo, 2 questions

2018-06-09 Thread Thomas S. Dye

Aloha all,

1) Is this the correct way to get an image in the homepage branch 
bundle?


I have this in the org file:

* Homepage
 :PROPERTIES:
 :EXPORT_HUGO_SECTION:
 :EXPORT_FILE_NAME: index
 :END:

[[/bldg-1-5-sequence-distance-1332+-small.png]]

This is the markdown export:

+++
title = "Homepage"
author = ["Thomas S. Dye"]
lastmod = 2018-06-09T09:32:43-10:00
draft = false
+++

{{< figure src="/bldg-1-5-sequence-distance-1332+-small.png" >}}

I don't see an image on the home page.  Perhaps this is an issue 
with the theme I'm using (material-docs)?


2) Can I have links in figure captions?

I have this in the org file:

#+name: fig-12-sequence
#+caption: Stratigraphic DAG for the information on Figure 
[[fig-12-section]].

[[file:/fig-12-sequence.png][file:/fig-12-sequence-small.png]]

This is the markdown export:

{{< figure src="/fig-12-sequence-small.png" caption="Figure 2: 
Stratigraphic DAG for the information on Figure [1](#org1658d1e)." 
link="/fig-12-sequence.png" >}}


All the best,
Tom

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



Re: [O] Moving from Jekyll to Orgmode

2018-05-09 Thread Thomas S. Dye

Aloha ST,

ST writes:


Is the difficulty to setup ox-publish the sole disadvantage vis.
ox-hugo/ox-jekyll/etc.? Is the functionality the same 
more_or_less?


What ox-hugo devs/users have to say on this?


I enjoy the hugo server.  Make a change to the org mode file, 
export with ox-hugo, and then look at the web browser to see the 
effect of the change.  It makes the work much easier, IMHO.


All the best,
Tom

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



Re: [O] "DONE" markers have different colors?

2018-05-08 Thread Thomas S. Dye

Aloha Kaushal,

Kaushal Modi writes:


Hello,

On Tue, May 8, 2018 at 5:56 PM Thomas S. Dye <t...@tsdye.com> 
wrote:




These are from two differently colored TODO cookies, not DONE
cookies.

There are text properties here:
  face (:inherit hl-todo :foreground "#cc9393")
  fontifiedt
  org-category "research"
  org-stats0

There are text properties here:
  face org-todo
  fontifiedt
  org-category "research"
  org-stats0



I don't use the hl-todo package. But looks like you do, and it 
somehow

highlights only some "TODO" keywords based on some regexp.

How about disabling hl-todo completely in Org files, and then 
see if you

still get that difference in faces?


That's it.  It is a known issue with spacemacs, which I'm using. 
See: https://github.com/syl20bnr/spacemacs/issues/9950, which 
provides a solution.


All the best,
Tom

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



Re: [O] "DONE" markers have different colors?

2018-05-08 Thread Thomas S. Dye

Aloha Kaushal,

Kaushal Modi writes:


Hello Thomas, Zongheng,

On Tue, May 8, 2018 at 5:34 PM Thomas S. Dye <t...@tsdye.com> 
wrote:



Hi,

Zongheng Yang writes:

> Hi,
>
> Lately I've noticed that in my org-mode files, the "DONE"
> markers started
> showing different colors.  I don't believe this happened 
> before.

> Any ideas?
> Is this a recent org-mode change?

I see this, too.



What do you guys see when you do C-u C-x = (equal sign is part 
of that
binding) with point placed on each of those differently colored 
"DONE"

states?


These are from two differently colored TODO cookies, not DONE 
cookies.


There are text properties here:
 face (:inherit hl-todo :foreground "#cc9393")
 fontifiedt
 org-category "research"
 org-stats0

There are text properties here:
 face org-todo
 fontifiedt
 org-category "research"
 org-stats0

hth,
Tom

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



Re: [O] "DONE" markers have different colors?

2018-05-08 Thread Thomas S. Dye

Hi,

Zongheng Yang writes:


Hi,

Lately I've noticed that in my org-mode files, the "DONE" 
markers started
showing different colors.  I don't believe this happened before. 
Any ideas?

Is this a recent org-mode change?


I see this, too.

All the best,
Tom

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



Re: [O] Thank you org-lint!

2018-05-04 Thread Thomas S. Dye

+1 It's a godsend.

Russell Adams writes:

I just had to express my thanks for the addition of org-lint in 
9.0. This is an
incredible tool for validating complex documents for export. 
It's been of great

help while I upgrade my templates.

--
Russell Adams 
rlad...@adamsinfoserv.com


PGP Key ID: 0x1160DCB3 
http://www.adamsinfoserv.com/


Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 
DCB3



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



Re: [O] Moving from Jekyll to Orgmode

2018-05-04 Thread Thomas S. Dye

Aloha Kaushal,

Kaushal Modi writes:


Hello Thomas,

On Fri, May 4, 2018 at 2:50 AM Thomas S. Dye <t...@tsdye.com> 
wrote:



This looks like an interesting project.

I've browsed the various Hugo themes and the example web sites. 
I

think I've seen websites similar to and themes suitable for a
variety of sites I'd like to consolidate: archaeology course
syllabus and class calendar; documentation for a software 
project;
a publication list with download links; and a book/article 
review

blog.



That's correct, you can use Hugo to generate any of those kinds 
of sites. I
use it for my blog, the ox-hugo doc site itself, the bare-bones 
ox-hugo
test site, product doc site at work. I have also used it in the 
past for a

"for-rent" site in the past (and it worked ;-)).



  I use org-mode for writing these kinds of thing now, and
I'm hoping to work out a way to make my org mode source work 
with

Hugo.



At minimum you just need the #+hugo_base_dir keyword and 
EXPORT_FILE_NAME
property (if using per-subtree flow). So it should not be too 
difficult. To
get an idea, I made these[1] changes to make the pre-existing 
use-package

Org manual ready for ox-hugo export.


I'm especially keen on previewing the web pages as I work on 
them,

which was super easy to set up (thanks!),



Great! So I gather that you were able to get a preliminary setup 
of

ox-hugo + Hugo working?


Yes, your ox-hugo test site was up and running in a few minutes. 
Every few seconds new blog entries would pop up on my browser as 
Hugo processed the test file.


The hardest part for me was getting ox-hugo to work in spacemacs. 
This isn't an ox-hugo thing.  I've had problems with other org 
mode components in spacemacs, mostly having to do with the order 
things are loaded.





and generating  "responsive" content to satisfy my smartphone 
connected

students.



That part is not too difficult if you want to get the basic
responsiveness.. just adding the viewport meta tag in HTML head 
does most

of the job:


maximum-scale=5">

You need to get into CSS hacking if you want to go further in 
@media based

CSS formatting, or implementing CSS grids, etc.



Apparently, there is a 'responsive' module for Hugo that several 
themes use.  I'm hoping to find responsiveness out of the box 
through careful choice of themes.



I see that ox-hugo and many Hugo templates have a blog as their
focus.  Is it reasonable to go down the ox-hugo path for my
planned sites?



I think so, as I mentioned earlier, I have used it for a variety 
of sites.
The Hugo theme tagging system is not great as it relies 
completely on what
the theme authors manually tag those as. But this[2] gives a 
small
selection of themes for documentation sites. I might find more 
sites that
fit your needs as you explore each of the themes on that site 
(don't reply

100% on tags).



  Or, is the blog focus likely to restrict what I'd like to do?



Hugo Go templating is very powerful[3]. It inherently has no 
restrictions.

The templating language does not have a "blog focus".

If you decide to use a theme, just as is[*], then that's a 
restriction. I
would suggest to pick a theme that best fits your need, and then 
gradually
mold (mould?) it as you learn more of Go templating, to make it 
perfect for

you.


Perfect.  Thanks.  I'm looking forward to getting started with 
ox-hugo.


Many thanks for the useful links.

All the best,
Tom


Thanks.

Kaushal


[1]:
https://github.com/jwiegley/use-package/commit/dede56276ce157fb55f84562b10a70978c34230e#diff-980e09e4bfed99830873c784dfb12a7a

[2]: https://themes.gohugo.io/tags/documentation/

[3]: Here are some of the professional non-blog sites created 
using Hugo:

https://gohugo.io/showcase/.

[*]: Being Emacs users, I doubt if the "use the theme as is" 
would work for

any of us ;-)



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



Re: [O] Moving from Jekyll to Orgmode

2018-05-04 Thread Thomas S. Dye

Aloha Kaushal

Kaushal Modi writes:


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.


This looks like an interesting project.

I've browsed the various Hugo themes and the example web sites. I 
think I've seen websites similar to and themes suitable for a 
variety of sites I'd like to consolidate: archaeology course 
syllabus and class calendar; documentation for a software project; 
a publication list with download links; and a book/article review 
blog.  I use org-mode for writing these kinds of thing now, and 
I'm hoping to work out a way to make my org mode source work with 
Hugo.


I'm especially keen on previewing the web pages as I work on them, 
which was super easy to set up (thanks!), and generating 
"responsive" content to satisfy my smartphone connected students.


I see that ox-hugo and many Hugo templates have a blog as their 
focus.  Is it reasonable to go down the ox-hugo path for my 
planned sites?  Or, is the blog focus likely to restrict what I'd 
like to do?


All the best,
Tom

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



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

2018-04-29 Thread Thomas S. Dye


Bastien writes:

I wish I'd be as optimistic as you are and assume every user 
reads
ORG-NEWS!  I seriously doubt a majority of users do.  Those 
installing
Org from ELPA cannot possibly know where to find ORG-NEWS, Org 
gives
no indication where it lives: IOW, it's not even because users 
are

lazy or what.


Would it be difficult to add an ORG-NEWS option to the 
Documentation section of the Org drop-down menu?  It's an 
interesting document.


Re: org tempo.  I really appreciate all the work done to preserve 
backward compatibility with the expansion mechanism.  I use Org 
for almost all my work nowadays and I hate to put my other work on 
hold to re-implement some Org mode functionality that I rely on.


That said, I didn't find the addition of (require org-tempo) to my 
configuration onerous.  I admire the kind of thinking that 
simplifies in order to make complexity possible.  Keep it up!


All the best,
Tom

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



Re: [O] Library of Babel confusion

2018-04-11 Thread Thomas S. Dye

Aloha Lawrence,

Lawrence Bottorff writes:

I'll try that, Thomas, but this was set up by simply doing the 
on-board
customize, i.e., it needs to have this corrected. So how do I 
request this

correction?


There are instructions here:

https://orgmode.org/org.html#Feedback

You'll need to indicate which customization option you've set and 
what you expected to happen vs. what actually happened.


I don't use customize and am not familiar with it, but when I 
looked through the Babel section this morning I didn't find an 
option to ingest a library of babel.  Perhaps I missed it, or it 
is found somewhere else?


All the best,
Tom



On Tue, Apr 10, 2018 at 3:26 PM, Thomas S. Dye <t...@tsdye.com> 
wrote:



Aloha Lawrence,

You probably want (org-babel-lob-ingest  FILE)

All the best,
Tom


Lawrence Bottorff writes:

Thanks for the help. However, one mystery still remains: Why is 
this


 '(org-babel-lob-files (quote 
 ("~/org/worg/library-of-babel.org")))


in my init.el's custom-set-variables not getting handled? I 
always have to
do an org-babel-lob-ingest to actually get 
library-of-babel.org loaded.


On Fri, Apr 6, 2018 at 10:38 PM, Berry, Charles 
<ccbe...@ucsd.edu> wrote:





> On Apr 6, 2018, at 4:59 PM, Thomas S. Dye <t...@tsdye.com> > 
> wrote:

>

[Tom's response covering the main issues deleted]

> hth,
> Tom
>
> Lawrence Bottorff writes:
>
>> I guess I need more information. For example, what is C-c 
>> >> C-v v

doing
>> exactly? Then C-x C-e? And  M-x (symbol-function >> 
>> 'myelsquare)

doesn't
work.


`C-h k' is really your friend here. If you do not know it, 
try typing it

twice `C-h k C-h k'.

As for the specific keystrokes mentioned above:

,[ C-h k C-c C-v v ]
| C-c C-v v runs the command org-babel-expand-src-block 
(found in
| org-mode-map), which is an interactive autoloaded compiled 
Lisp

| function in ‘ob-core.el’.
|
| It is bound to C-c C-v v, C-c C-v C-v.
|
| (org-babel-expand-src-block  ARG INFO PARAMS)
|
| Expand the current source code block.
| Expand according to the source code block’s header
| arguments and pop open the results in a preview buffer.
|
| [back]
`

In your case, it shows that the `mtelsquare' src block 
expands to:



,
| (let ((x (quote 0)))
| (defun myelsquare (x)
|   (* x x))
| )
`


,[ C-h k C-x C-e ]
| C-x C-e runs the command eval-last-sexp (found in 
global-map), which
| is an interactive compiled Lisp function in 
‘elisp-mode.el’.

|
| It is bound to C-x C-e.
|
| (eval-last-sexp EVAL-LAST-SEXP-ARG-INTERNAL)
|
| Evaluate sexp before point; print value in the echo area.
| Interactively, with prefix argument, print output into 
current buffer.

|
| Normally, this function truncates long output according to 
the value

| of the variables ‘eval-expression-print-length’ and
| ‘eval-expression-print-level’.  With a prefix argument of 
zero,
| however, there is no such truncation.  Such a prefix 
argument
| also causes integers to be printed in several additional 
formats

| (octal, hexadecimal, and character).
|
| If ‘eval-expression-debug-on-error’ is non-nil, which is 
the default,

| this command arranges for all errors to enter the debugger.
|
| [back]
`

So with point at the end of the preview buffer for myelsquare 
(which has

one `let' expression it it) it has the same effect as running
`eval-buffer'. viz, the elisp function `myelsquare' is 
created.


If you have gotten this far, there is an lisp function called
`myelsquare'
and the `symbol-function' expression will return its value 
when properly

`eval'ed. I misspoke before. I should have said

M-: (symbol-function 'myelsquare) RET

And that value is `(lambda (x) (* x x))'. Which simply shows 
you have

defun'ed a function and what it is.

Once you have an elisp function, the natural way to call it 
is

src_emacs-lisp{(myelsquare 1.5)}.

One thing you can do with LOB blocks is use them in header 
args of src

blocks just as you would use calls to ordinary src blocks.

HTH,

Chuck






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




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



Re: [O] Library of Babel confusion

2018-04-11 Thread Thomas S. Dye

Aloha Lawrence,

You probably want (org-babel-lob-ingest  FILE)

All the best,
Tom

Lawrence Bottorff writes:

Thanks for the help. However, one mystery still remains: Why is 
this


 '(org-babel-lob-files (quote 
 ("~/org/worg/library-of-babel.org")))


in my init.el's custom-set-variables not getting handled? I 
always have to
do an org-babel-lob-ingest to actually get library-of-babel.org 
loaded.


On Fri, Apr 6, 2018 at 10:38 PM, Berry, Charles 
<ccbe...@ucsd.edu> wrote:





> On Apr 6, 2018, at 4:59 PM, Thomas S. Dye <t...@tsdye.com> 
> wrote:

>

[Tom's response covering the main issues deleted]

> hth,
> Tom
>
> Lawrence Bottorff writes:
>
>> I guess I need more information. For example, what is C-c 
>> C-v v doing
>> exactly? Then C-x C-e? And  M-x (symbol-function 
>> 'myelsquare) doesn't

work.


`C-h k' is really your friend here. If you do not know it, try 
typing it

twice `C-h k C-h k'.

As for the specific keystrokes mentioned above:

,[ C-h k C-c C-v v ]
| C-c C-v v runs the command org-babel-expand-src-block (found 
in
| org-mode-map), which is an interactive autoloaded compiled 
Lisp

| function in ‘ob-core.el’.
|
| It is bound to C-c C-v v, C-c C-v C-v.
|
| (org-babel-expand-src-block  ARG INFO PARAMS)
|
| Expand the current source code block.
| Expand according to the source code block’s header
| arguments and pop open the results in a preview buffer.
|
| [back]
`

In your case, it shows that the `mtelsquare' src block expands 
to:



,
| (let ((x (quote 0)))
| (defun myelsquare (x)
|   (* x x))
| )
`


,[ C-h k C-x C-e ]
| C-x C-e runs the command eval-last-sexp (found in 
global-map), which

| is an interactive compiled Lisp function in ‘elisp-mode.el’.
|
| It is bound to C-x C-e.
|
| (eval-last-sexp EVAL-LAST-SEXP-ARG-INTERNAL)
|
| Evaluate sexp before point; print value in the echo area.
| Interactively, with prefix argument, print output into 
current buffer.

|
| Normally, this function truncates long output according to 
the value

| of the variables ‘eval-expression-print-length’ and
| ‘eval-expression-print-level’.  With a prefix argument of 
zero,

| however, there is no such truncation.  Such a prefix argument
| also causes integers to be printed in several additional 
formats

| (octal, hexadecimal, and character).
|
| If ‘eval-expression-debug-on-error’ is non-nil, which is the 
default,

| this command arranges for all errors to enter the debugger.
|
| [back]
`

So with point at the end of the preview buffer for myelsquare 
(which has

one `let' expression it it) it has the same effect as running
`eval-buffer'. viz, the elisp function `myelsquare' is created.

If you have gotten this far, there is an lisp function called 
`myelsquare'
and the `symbol-function' expression will return its value when 
properly

`eval'ed. I misspoke before. I should have said

M-: (symbol-function 'myelsquare) RET

And that value is `(lambda (x) (* x x))'. Which simply shows 
you have

defun'ed a function and what it is.

Once you have an elisp function, the natural way to call it is
src_emacs-lisp{(myelsquare 1.5)}.

One thing you can do with LOB blocks is use them in header args 
of src

blocks just as you would use calls to ordinary src blocks.

HTH,

Chuck






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



Re: [O] Library of Babel confusion

2018-04-06 Thread Thomas S. Dye

Aloha Lawrence,

#+name: myelsquare
#+header: :var x=0
#+begin_src emacs-lisp :var x=0
 (defun myelsquare (x)
   (* x x))
#+end_src

#+RESULTS: myelsquare
: myelsquare

Assuming myelsquare has been evaluated:

#+name: eval-myelsquare
#+header: :var y=2
#+BEGIN_SRC emacs-lisp
(myelsquare y)
#+END_SRC

#+RESULTS: eval-myelsquare
: 4

#+call: eval-myelsquare(3)

#+RESULTS:
: 9

hth,
Tom

Lawrence Bottorff writes:

I guess I need more information. For example, what is C-c C-v v 
doing
exactly? Then C-x C-e? And  M-x (symbol-function 'myelsquare) 
doesn't work.

Again,

#+name: myelsquare
#+header: :var x=0
#+begin_src emacs-lisp :var x=0
  (defun myelsquare (x)
(* x x))
#+end_src

is Lisp code where the last thing should be returned. From
library-of-babel.org:

#+name: json
#+begin_src emacs-lisp :var file='() :var url='()
  (require 'json)
  (cond
   (file
(org-babel-with-temp-filebuffer file
  (goto-char (point-min))
  (json-read)))
   (url
(require 'w3m)
(with-temp-buffer
  (w3m-retrieve url)
  (goto-char (point-min))
  (json-read
#+end_src

And this calling a sample json-containing file gives

#+call: json(file="jsontest1")

| glossary | (title . example glossary) | (GlossDiv (title . S) 
(GlossList
(GlossEntry (ID . SGML) (SortAs . SGML) (GlossTerm . Standard 
Generalized
Markup Language) (Acronym . SGML) (Abbrev . ISO 8879:1986) 
(GlossDef (para
. A meta-markup language, used to create markup languages such 
as DocBook.)

(GlossSeeAlso . [GML XML])) (GlossSee . markup |

which is correct, although not in list form. So again I'm 
looking at elisp
code that is not in the form of a function. So I'm guessing 
"functions"
cannot be #+call'ed, just "headless" elisp code. So what 
advantage does LOB

offer?

On Tue, Apr 3, 2018 at 5:39 PM, Berry, Charles 
<ccbe...@ucsd.edu> wrote:





> On Apr 3, 2018, at 1:31 PM, Lawrence Bottorff 
> <borg...@gmail.com> wrote:

>
> I've been trying to grok LOB again. So I've cloned the worg 
> git and
library-of-babel.el is one of the files. org-babel-lob-injest 
didn't work,



Try

M-x org-babel-lob-ingest RET org/worg/library-of-babel.org RET

Don't be a jester, be an ingester. ;-)


> so I customized org-babel-lob-files and inserted
.../worg/library-of-babel.el . . . and it did in fact get added 
to my

init.el under the custom-set-variables:
>
>  '(org-babel-lob-files (quote 
>  ("~/org/worg/library-of-babel.org")))

>
> I checked org-babel-library-of-babel variable, and the new 
> things seemed
to be there, although it's rather mind-bending to know I will 
be calling
LOB code that is internally stored inside of an association 
list.

>
> Now, in my org file I put this:
>
> #+lob: write(file="jsontest")


See (info"(org) Evaluating code blocks")

The proper idiom is

#+call: write(file="jsontest")

Of course, there needs to be a proper 'write' src block in the 
file you

ingested, etc.

>
> and try C-c C-c on it. Nothing. My minibuffer says "local 
> setup has been
refreshed". How does one use, call a LOB function? Also, while 
I'm

demonstrating my rank noobian-ness, I try this:
>
> #+name: myelsquare
> #+header: :var x=0
> #+begin_src emacs-lisp
>   (* x x)
> #+end_src
>
> #+call: myelsquare(x=6)
>
> #+RESULTS:
> : 36
>
> but this results in
>
> #+name: myelsquare
> #+header: :var x=0
> #+begin_src emacs-lisp
>   (defun myelsquare (x)
>   (* x x))
> #+end_src
>
> #+call: myelsquare(x=6)
>
> #+RESULTS:
> : myelsquare2


Is this *verbatim* ? Did you cut and paste everything 
(including the

trailing `2') all at once? If so, I do not get it.

I would have expected

#+RESULTS:
: myelsquare

 which is the correct behavior.

To see why put point in the myelsquare src block and type C-c 
C-v v


then move point to the end of the 'preview' buffer and type C-x 
C-e.


Look at the value echo-ed in the minibuffer.

If it still isn't clear maybe `M-x (symbol-function 
'myelsquare)' will

help.

HTH,

Chuck




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



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

2018-03-06 Thread Thomas S. Dye

Aloha Bastien,

Bastien writes:


Hi Thomas,

"Thomas S. Dye" <t...@tsdye.com> writes:

Instead, let's move the project forward with the understanding 
that
if it proves to be a bad idea, then the Org mode community will 
have
Nicolas' very nice .texi file (with backports by Kyle Meyer) to 
fall

back on.


Maybe we are miscommunicating, because that's exactly what I 
suggest!


Good news.  Thanks!

All the best,
Tom

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



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

2018-03-06 Thread Thomas S. Dye

Aloha Bastien,

I disagree that the manual project should move into a one year 
probation where success is measured by the number of contributors. 
So, my response to LETS GO! is NOT THERE!


Instead, let's move the project forward with the understanding 
that if it proves to be a bad idea, then the Org mode community 
will have Nicolas' very nice .texi file (with backports by Kyle 
Meyer) to fall back on.


On the issue of your work on Org mode, I'm hoping your 
circumstances will allow you to be more involved, not less.


All the best,
Tom

Bastien writes:


Hello Thomas,

as a preamble, let me say that I appreciate the directness of 
your
message and the civil tone of this conversation.  I understand 
there
are frustrations lingering around, I have my own too, so let's 
keep
this thread as constructive as possible, because we all deserve 
it

as a community.

Let me separate two questions: one is my attitude in dealing 
with this

migration; another one is my general ability as a maintainer.

The first question naturally leads to the other one, but the 
last one

exists per se and I'll take this opportunity to say a few words.

So, about this manual migration.

Here is a quick timeline:

  In 2013, I said it was a nice experiment.

  In 2014, I said I would be "more than happy" if you and others 
  could
  progress on this: 
  http://thread.gmane.org/gmane.emacs.orgmode/85574


  In 2016, Charles quoted me saying: "Where Bastien says: "the 
  day we
  can export org.org to org.texi with very little headache and 
  ad hoc

  configuration, yes, we will make the move.""

  In January 2018, I said: "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."


  In March 2018, I said there was no blocker, "please move 
  ahead".


So I don't think I have been scolding you or anyone working on 
this,
quite on the contrary.  In my message from 2014, I said I won't 
have
time to dedicate to the project.  And while I was kind of 
skeptical
about the idea, I have been consistent in sending encouragements 
and

in not blocking it.

Maybe I should have explained why I was skeptical: but in 
2013-2015,
it was just a gut feeling, and expressing it would probably have 
been
unproductive; then when I had this project to develop Org from 
within
Emacs, I was not so sure about it either, so I was first 
cautious not

to raise premature objections.

When Nicolas sollicited the list again in january, I tried to 
make a
few inputs: not as constructive as I'd wish they were, but 
still.


Now, my main input is this: LET'S GO!

So...  I completely recognize my general lack of responsiveness 
is a
problem and it may have been a problem in this case, but I hope 
you
see that I carefully tried not to block anyone's work on this. 
Again:
asking inputs from emacs-devel@ is not a way of delaying or 
blocking,

it is just something normal to do considering the move.

So now let's close this issue, I'll write to emacs-devel@ and we 
will

make the switch.


Now, about my general experience and attitude as a maintainer.

I started to take care of Org-mode in 2011, on January 1st.

Seven years ago... time flies :)

I've been involved in code and communication on the list on a 
daily
basis until septembre 2012, the day my daughter was born.  Stats 
may
prove my memory is wrong here, but I think I stayed closely 
committed
until septembre 2014.  Enters life: I had a burn out, a break up 
and
I was broke.  Like in: completely broke, no job, no place to 
stay.


I asked Nicolas whether he would considered to be the maintainer 
on
several occasions -- the first one dating back to november 2011. 
We
always had a frank conversation about this.  Nicolas declined, 
but we
managed to find a balanced way of collaborating and I 
confidently

moved from being proactive to being more of a release manager.

Despite not being the "official" maintainer, Nicolas is the de 
facto
one since 2015.  And again, I cannot express how much I owe to 
Nicolas

and his consistency for the last three years.

But believe me: I wish I could continue to spend one or two 
hours per
day coding and communicating on the mailing list: because, it's 
kind

of a home for me.  But I could not.  And I cannot.


So here is my plan:

- We make the switch to using manual.org.

- We release Org 9.2.

- I extract the contrib/ directory from org-mode.git into a 
separate
  org-contrib.git to live on code.orgmode.org (something I've 
  wanted

  for long).

- I go down my org-mode TODO list to see if there are importants 
bugs

  and features I wish to work on.

- In the meantime, I find a new maintainer.

- We release Org 10 and the new maintainer takes on.

I think the whole process can take from 2 to 3 months, and I'm 
ready

to dedicate more time to Org during these months.

WDYT?



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



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

2018-03-06 Thread Thomas S. Dye

Aloha Bastien,

Bastien Guerry writes:
Maybe this is where some misunderstanding arose: to me, there 
was no
_project_ to migrate to manual.org -- it was an idea in the air 
after
you made your experiment and we now have the decision at hand 
because

the project is, well, DONE.

We could have done it another way: we could have discussed it as 
a
project, then anticipated that it will prevent Org's code to 
migrate
to Emacs repository, then discussed the pros and cons before 
investing

more time.


Thanks for pointing out this alternative.

Several of us working on the manual did recently discuss various 
issues on the list. Nicolas had several messages, I responded to 
most of them, and others chimed in on particular parts: Achim 
Gratz, Kyle Meyer, and Kaushal Modi come to mind immediately, but 
there may have been others.


In the past, we could have been assured Carsten would join the 
discussion in one way or another as maintainer, working to keep us 
on track and guide us to the most productive use of our time.


However, you have chosen to fulfill the duties of maintainer in a 
different way, one that does not involve day-to-day interaction 
with the volunteers who are themselves choosing to spend time 
trying to augment and improve Org mode.  I don't argue with this 
decision of yours, but to my mind, this is why we are where we are 
today.


Certainly, if I had understood in 2013 that my efforts would 
eventually work against Org mode by preventing migration of its 
code to Emacs repository (an issue that I don't understand fully 
but accept as valid), then I would have saved that time for other 
pursuits.  But, you did not say this at the time, as far as I 
remember.  My memory is that you were mostly silent.


Similarly, it was clear to me from lurking on the list last year 
that Nicolas was going to revive the project.  I believe it was 
also clear to the others who participated in the conversation on 
list, but I don't want to speak for them.  You either did not read 
that discussion or you did read it and chose not to participate. 
Work on the manual project wasn't a secret.


From my point of view, your involvement has come at the 11th hour, 
well after much effort has been expended on what several of our 
colleagues believe is a contribution to Org mode.  I'm pleased 
that you are willing to give the project a try, but I want to 
insist that you take some responsibility for where we are in this 
discussion.  I cannot accept that the maintainer scolds me and 
others who worked on the project that "we could have done it 
another way."  This is exactly the responsibility I want to insist 
the maintainer accept.


We look to the maintainer for guidance.  Please give it to us in a 
timely manner.


All the best,
Tom

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



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

2018-03-05 Thread Thomas S. Dye


Nicolas Goaziou writes:


I don't have strong opinions on this issue.


I read it otherwise.


So do I.

Some history.  When I worked on this project several years ago, I 
concluded that Bastien was hostile to it, but there was nothing in 
his communication that was particularly negative.  When I 
suggested on the list recently that Bastien did not like the 
project, I was scolded a bit by others who found mildly supportive 
statements from him in the archives.  Yesterday, in Bastien's 
response to Glenn Morris, was the first time I read that he 
thought the project was a "bad idea".  I wish I'd known that at 
the time!


I'm fine with Bastien holding an opinion different from mine.  My 
point is that he did not speak his mind when I worked on the 
project, so it is valid today to disagree with his statement about 
the strength of his opinions.



Do you agree with the one I suggested?


I disagree. My motivation is not to attract more contributors. I 
don't
think this was Thomas and Jonathan's motivation when they 
started the

project either, but I may be wrong.


I can only speak for myself here.  At the time, I thought the Org 
manual was a stylistic mess and I thought I could use my 
experience as a writer and editor to improve the situation.  I had 
lots of experience writing in LaTeX, but found texinfo clunky and 
obtrusive.  When I discovered Jonathan's texinfo exporter and 
found that it worked nicely, I thought I had an opportunity to 
contribute two ways to Org: 1) I could create a document that 
would challenge the texinfo exporter and lead to its development 
and improvement, and 2) I could edit the manual using the same 
lightweight markup language that I was now using in my academic 
work, having switched from LaTeX to Org mode for its reproducible 
research capabilities.


Of course, I figured the Org mode developers who write the manual 
would also appreciate the switch, and was pleased that Carsten 
pitched in with the memorable comment about Org eating its own dog 
food.


Many thanks to Nicolas for his efforts on this project.

All the best,
Tom

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



Re: [O] Patch for documentation standards

2018-03-04 Thread Thomas S. Dye

Aloha Bastien,

Bastien Guerry writes:


Hi Thomas,

Feel free to cmmit when appropriate.  IMO, the comment period 
for
Nicolas' manual project has been sufficiently long and I do not 
want

to work with you to prolong it.


Mhh... "working with me" would shorten it for sure!

Anyway, I committed this:

https://code.orgmode.org/bzg/org-mode/commit/dd99ed74430a8b6a48f6b63fac71a0bede3e772f

Let me know what you think.


I hope you find it useful.

All the best,
Tom

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



Re: [O] Patch for documentation standards

2018-03-04 Thread Thomas S. Dye

Aloha Bastien,

> Can you make separate patches, one fixing errors and another one
> for the move to editing the manual with .org?

> I don't want to commit anything premature.

Feel free to cmmit when appropriate.  IMO, the comment period for 
Nicolas' manual project has been sufficiently long and I do not want to 
work with you to prolong it.


All the best,
Tom


[O] Patch for documentation standards

2018-03-03 Thread Thomas S. Dye

Aloha all,

A lightly edited and augmented version of the Org documentation 
standards is attached.


All the best,
Tom

>From 010294deec9d35217bdc991bec55a80ab0f40853 Mon Sep 17 00:00:00 2001
From: "Thomas S. Dye" <t...@tsdye.com>
Date: Sat, 3 Mar 2018 16:06:27 -1000
Subject: [PATCH] Update documentation standards

---
 doc/Documentation_Standards.org | 57 ++---
 1 file changed, 37 insertions(+), 20 deletions(-)

diff --git a/doc/Documentation_Standards.org b/doc/Documentation_Standards.org
index 357520b9f..f1495d2e8 100644
--- a/doc/Documentation_Standards.org
+++ b/doc/Documentation_Standards.org
@@ -34,7 +34,7 @@ used in the patches I am submitting and, which I hope, may be adopted by
 others when making their own contributions.
 
 * Org - Referencing systems, packages, modes and much else
- 
+
 Originally Org was a single mode and there was no ambiguity about what
 Org mode could refer to.  Things have changed rapidly though and it
 seems that Carsten now thinks of Org as the system encompassing the
@@ -49,7 +49,7 @@ perfect, merely a start):
applicable to Org as a whole.
 
  - Be more specific and write, for example, "the Orgtbl minor mode" when
-   referring to something unique to that feature.  It maybe, for example,
+   referring to something unique to that feature.  It may be, for example,
a command is only available when you are actually editing a file using
just that mode, add-on package or plug-in.
 
@@ -67,7 +67,7 @@ perfect, merely a start):
 
 * Other Org specific conventions
 
-Unless there is a good reason to do otherwise then try and adopt the
+Unless there is a good reason to do otherwise, then try and adopt the
 following conventions.  (I think all can be justified by reference to
 Carsten or precedent in other significant Emacs documentation...unless I
 have made them up of course).
@@ -89,36 +89,53 @@ have made them up of course).
lowercase.
 
  - Built-in properties (eg PRIORITY) are written in uppercase.  User defined
-   properties (eg Release) are written in lowercase.
+   properties (e.g. Release) are written in lowercase.
 
- - [[info:org:Top][The Org Manual]] uses the @chapter, @section and @subsection Texinfo
-   commands for sectioning.  I have tried to capitalize significant words
-   in @chapter headings.  In @section and @subsection headings, just the
+ - [[info:org:Top][The Org Manual]] capitalizes significant words
+   in first level headings.  In second and third level headings, just the
first word is capitalized and all other words are lowercase (with
exceptions of course...).  Thus, use:
 
-   @chapter Properties and Columns
+   * Properties and Columns
 
-   @section Visibility cycling
+   ** Visibility cycling
 
*but*
 
-   @section Fast access to TODO states
+   ** Fast access to TODO states
 
 * Miscellaneous
 
- - Only two of the standard Texinfo indexes are used; those for concepts
-   and keys.  This has some implications:
+ - Five of the standard Texinfo indexes are used in the Org manual:
+
+   + #+cindex: :: concept index, for general concepts
+
+   + #+findex:  :: function index, for function and function-like names
+
+   + #+kindex: :: keystroke index, for keyboard commands
+
+   + #+pindex: :: program index, for names of programs
+
+   + #+vindex: :: variable index, for variable names
+
+ - Entries in the concept index are normally all lower case unless
+   some other rule dictates otherwise
+
+ - 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 colons
+
+ - when to use =...= or ~...~ markup:
+
+   - files or extensions use =...=,
 
-   + The preference is to document commands by key rather than by name
+   - anything that is meant to be written in the Org buffer uses =...=,
 
-   + Texinfo commands such as @var and @defoption are not used.  The
- preference for this type of thing is that the user browses the
- customize groups.  If you want or need to refer to, say, a variable
- then document it as "the variable @code{org-startup-folded}"
- 
-   + Entries in the concept index are normally all lower case unless
- some other rule dictates otherwise.
+   - any meaningful token in a programming language uses ~...~.
 
  - Org documentation is written in American English, which is somewhat
foreign as far as I am concerned, but live with it anyway.
-- 
2.14.1



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


[O] Broken Worg link

2018-02-27 Thread Thomas S. Dye

Aloha all,

https://orgmode.org/worg/org-contrib/babel/languages.html 404s 
here.


All the best,
Tom

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



Re: [O] Images in HTML export

2018-02-18 Thread Thomas S. Dye

Aloha Eric,

Eric S Fraga writes:


On Saturday, 17 Feb 2018 at 12:01, Thomas S. Dye wrote:

Aloha all,

Using an up-to-date Org mode from Elpa, I'm not getting inline
images when the description part of the Org link is itself a 
link.
Instead, the browser shows the alt text, which points to the 
link.


[...]

I have org-html-inline-images set to t, and am viewing the 
output

in an up-to-date Mozilla Firefox browser.


Maybe check org-html-inline-image-rules to ensure that it covers 
.jpeg

files?


Thanks for the suggestion.

As is often the case, Org mode is doing just what I tell it to do 
and the problem is that I've been telling it to do the wrong 
thing. Sorry for the noise.


All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com



[O] Images in HTML export

2018-02-17 Thread Thomas S. Dye

Aloha all,

Using an up-to-date Org mode from Elpa, I'm not getting inline 
images when the description part of the Org link is itself a link. 
Instead, the browser shows the alt text, which points to the link.


Here is an example from the Org mode buffer:

#+name: fig:bldg-1-5-seq
#+caption: Stratigraphic DAG of the North Area sequence based on a 
Harris matrix created by Craig Cessford.

[[file:~/quicklisp/local-projects/hm/examples/bldg-1-5/bldg-1-5-sequence.png][file:~/quicklisp/local-projects/hm/examples/bldg-1-5-sequence-small.jpeg]]

This is what I get in the html file:


href="file:///home/dk/quicklisp/local-projects/hm/examples/bldg-1-5/bldg-1-5-sequence.png">src="file:///home/dk/quicklisp/local-projects/hm/examples/bldg-1-5-sequence-small.jpeg" 
alt="bldg-1-5-sequence-small.jpeg" />


Figure 6: Stratigraphic DAG 
of the North Area sequence based on a Harris matrix created by 
Craig Cessford.



I have org-html-inline-images set to t, and am viewing the output 
in an up-to-date Mozilla Firefox browser.


I'm expecting to see bldg-1-5-sequence-small.jpeg displayed 
inline.  Any idea what I'm doing wrong?


All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com



Re: [O] Dedicated targets

2018-01-27 Thread Thomas S. Dye

Thanks.

Nicolas Goaziou writes:


Hello,

"Thomas S. Dye" <t...@tsdye.com> writes:


Is it possible to have a dedicated target in a comment?


No, it isn't. A comment is not active data.

You could, however, have a target in a drawer, that you would 
not export.


Regards,



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



[O] Dedicated targets

2018-01-27 Thread Thomas S. Dye

Aloha all,

Is it possible to have a dedicated target in a comment?

I found a Common Lisp package that generates documentation in Org 
mode.  It outputs dedicated targets like so:


# link target 2: <>
# link target: <>

Org-lint complains about unknown fuzzy link locations and the file 
won't export to html.


All the best,
Tom

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



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

2018-01-23 Thread Thomas S. Dye

Aloha all,

Nicolas Goaziou writes:



Note that I made a few design choices I didn't write about, 
e.g.,:


  - use fixed-width area for one-line examples,
  - use example blocks for Org syntax instead of "begin_src 
  org",

  - internal links to headlines always start with a star,
  - tags, 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'd like to follow up on an earlier suggestion to put together a 
style guide for manual.org based on Phil Rooke's 
Documentation_Standards.org.  The idea was to "translate" Phil's 
document to follow the change from .texi source to .org source.


I think it will prove useful to have design choices described 
together in one place.


I've copied Phil in case he objects to having his "Notes to myself 
..." document used in this way.


Any comments welcome.

All the best,
Tom

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



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

2018-01-22 Thread 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

2018-01-20 Thread Thomas S. Dye


Nicolas Goaziou writes:


Hello,

"manual.org" was updated a month ago, and, so far, nobody 
complained
about it. So, I think it's a good time to discuss about what 
could be

done next.

The first obvious step is to move the file into "doc/" 
directory. Then
I assume we could delete "org.texi" 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.

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?


+1

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



Re: [O] BeOrg

2018-01-02 Thread Thomas S. Dye

Aloha all
Peter Davis writes:


On Tue, Jan 2, 2018, at 3:43 PM, Nicolas Goaziou wrote:


I think you are missing the point. Free software is primarily 
about

source code (the four definitions).


If we refuse to provide useful information just because it 
violates some
purist idea of what is or is not acceptably unencumbered, then 
we’re
just denying users potential helpful capabilities that may make 
the
difference between using org-mode or abandoning it completely in 
favor

of some commercial, cross-platform solution.


IIUC, the question is about where to provide this information, not 
whether or not to provide it.  OP asked about putting it in the 
Org manual and Nicolas has pointed out that the manual is for 
documenting Org software.


Perhaps Worg is a better place to provide information about BeOrg?

hth,
Tom

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



Re: [O] Preventing noweb substitution during export

2017-12-28 Thread Thomas S. Dye


Patches welcome! Org manual is now an Org file, it should be 
much more

pleasant to edit. :)


Good news. When will the switch from doc/org.texi to 
contrib/manual.org take place?


All the best,
Tom

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



Re: [O] [RFC] Dog food, anyone?

2017-12-19 Thread Thomas S. Dye
Aloha Jonathan,

Jonathan Leech-Pepin writes:

>>
>>Just to prevent miscommunication, I wasn't criticizing your work when
>>I wrote I had improved the back-end.
>>
>
> I didn’t take it as criticism, when I’d started working on it the new export 
> engine was still in it’s infancy and a lot of the work you’ve done to improve 
> performance and parsing hadn’t occurred yet.  I’m glad it was complete enough 
> to let Thomas start his work and give you a basis for improving to allow for 
> a full manual.

I remember that working with you, and with your software, was a real
pleasure.  Like you, I'm pleased our work provided some basis for
Nicolas' accomplishment.

All the best,
Tom

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



Re: [O] [RFC] Dog food, anyone?

2017-12-19 Thread Thomas S. Dye
Aloha Nicolas,

Nicolas Goaziou writes:

> Hello,
>
> "Thomas S. Dye" <t...@tsdye.com> writes:
>
>> I find the en-dash with spaces more aesthetically pleasing, too.
>
> Unfortunately, Emacs manual thoroughly uses em-dash. We have to bite the
> bullet, IMO.
>
> I will change " -- " into "---" if there is no objection.

No objection here.

>> Agreed. This is one of the first things we might do if manual.org
>> becomes the official source of the Org manual.
>>
>> FYI, Phil Rooke's Documentation_Standards.org suggests title case for
>> chapter heads and sentence case for section and subsection headings.
>
> OTOH, Emacs manual seems to use title case at every level, barring some
> exceptions (e.g., "Terminal emulator").
>
> Maybe we should stick to title case to every heading that belong to
> a menu, i.e., we can use sentence case for "notoc" headings.
>
> Since Texinfo node names are derived from headlines, it means external
> references to Org manual, if such thing exists, are going to break.
>
> WDYT?

I think we should identify and follow the appropriate style guide, but
I'm confused about what *is* the appropriate style guide.

The style guide for GNU documentation seems more about teaching coders
how to communicate with other humans and less about the nitty-gritty
style issues that send an editor to a guide like the Chicago Manual of
Style. See:

https://www.fsf.org/gnu-press/GNU-Press-styleguide.pdf

Note that the GNU style guide uses sentence case for section heads, and
em-dashes with spaces (" --- ")!

Of course, the TexInfo style guide I cited in an earlier post appears to
have conflicting advice about dashes :(

In the end, the important thing is consistency.  A good document
"trains" its readers how to read it by hewing to a consistent standard.

My recommendation at this point is to follow Phil Rooke's style guide
and augment it where possible. If manual.org becomes the official source
for Org documentation, then it would be useful to "translate" Rooke's
guide to show how to achieve its style prescriptions using Org markup.

hth,
Tom

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



Re: [O] [RFC] Dog food, anyone?

2017-12-18 Thread Thomas S. Dye
Aloha Nicolas,

Nicolas Goaziou writes:

>> One change that might be made globally is the use of em-dash (---) to
>> set off text, versus en-dash (--) between numerals, e.g. "the range of
>> run times is 1--5 seconds".  I've spotted several places where the
>> en-dash is used to set off text.  See this web site for the convention
>> on dashes:
>>
>> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Conventions.html
>
> I think it is a matter of "American English" vs "British English"
> convention. See, e.g., <https://www.gsbe.co.uk/grammar-the-dash.html>.
>
> I consistently used the latter because I find it more aesthetically
> pleasing. As a GNU manual, we can switch to the American English
> convention everywhere. In this case, however, em-dash are not
> spaced-out.

I find the en-dash with spaces more aesthetically pleasing, too.

>
> In the same vein, we also need to use title case. This needs some
> special care as fuzzy links need to be updated accordingly.
>
> WDYT?

Agreed. This is one of the first things we might do if manual.org
becomes the official source of the Org manual.

FYI, Phil Rooke's Documentation_Standards.org suggests title case for
chapter heads and sentence case for section and subsection headings.


> I changed it to
>
>   ... by tweaking the header arguments (see [[* Using header
>   arguments]]) for compiling...
>
> For more information, see (info "(texinfo) @ref"), last paragraphs.
> N.B.: I suggest to read it in regular info viewer, i.e., "info texinfo"
> from the command line, instead of Emacs to make sense out of this.

Yes, much better.

All the best,
Tom

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



Re: [O] [RFC] Dog food, anyone?

2017-12-18 Thread Thomas S. Dye
file.  Besides text
-output, results may include links to other data types that Emacs can
-handle: audio, video, and graphics.
-
-An important feature of Org's execution of the code blocks is passing
-variables, functions, and results between them.  Such interoperability
-uses a common syntax even if these blocks are in different source code
-languages.  The integration extends to linking the debugger's error
-messages to the line in the source code block in the Org file.  That
-should partly explain why this functionality by the original
-contributors, Eric Schulte and Dan Davison, was called /Org Babel/.
-
-In literate programming, the main appeal is code and documentation
-co-existing in one file.  Org mode takes this several steps further.
-First by enabling execution, and then by inserting results of that
-execution back into the Org file.  Along the way, Org provides
-extensive formatting features, including handling tables.  Org handles
-multiple source code languages in one file, and provides a common
-syntax for passing variables, functions, and results between source
-code blocks.
+Org can manage the source code in the block delimited by =#+BEGIN_SRC=
+... =#+END_SRC= in several ways that can simplify housekeeping tasks
+essential to modern source code maintenance.  Org can edit, format,
+extract, export, and publish source code blocks.  Org can also compile and
+execute a source code block, then capture the results.  The Org mode
+literature sometimes refers to source code blocks as /live code/
+blocks because they can alter the content of the Org document or the
+material that it exports.  Users can control how live they want each
+source code block by tweaking the [[*Using header arguments][header arguments]] for compiling,
+execution, extraction, and exporting.
+
+Source code blocks are one of many Org block types, which also include
+=quote=, =export=, =verse=, =latex=, =example=, and =verbatim=.  This
+section pertains to blocks between =#+BEGIN_SRC= and =#+END_SRC=.
+
+For editing and formatting a source code block, Org uses an
+appropriate Emacs major-mode that includes features specifically
+designed for source code in that language.
+
+Org can extract one or more source code blocks and write them to one
+or more source files --- a process known as /tangling/ in literate
+programming terminology.
+
+For exporting and publishing, Org's back-ends can format a source code
+block appropriately, often with native syntax highlighting.
+
+For executing and compiling a source code block, the user can
+configure Org to select the appropriate compiler.  Org provides
+facilities to collect the result of the execution or compiler output,
+insert it into the Org document, and/or export it.  In addition to
+text results, Org can insert links to other data types, including
+audio, video, and graphics. Org can also link a compiler error message
+to the appropriate line in the source code block.
+
+An important feature of Org's management of source code blocks is the
+ability to pass variables, functions, and results to one another using
+a common syntax for source code blocks in any language.  Although most
+literate programming facilities are restricted to one language or
+another, Org's language-agnostic approach lets the literate programmer
+match each programming task with the appropriate computer language and
+to mix them all together in a single Org document.  This
+interoperability among languages explains why Org's source code
+management facility was named /Org Babel/ by its originators, Eric
+Schulte and Dan Davison.
 
 Org mode fulfills the promise of easy verification and maintenance of
-publishing reproducible research by keeping all these in the same
-file: text, data, code, configuration settings of the execution
-environment, the results of the execution, and associated narratives,
-claims, references, and internal and external links.
+publishing reproducible research by keeping text, data, code,
+configuration settings of the execution environment, the results of
+the execution, and associated narratives, claims, references, and
+internal and external links in a single Org document.
 
-Details of Org's facilities for working with source code are shown
-next.
+Details of Org's facilities for working with source code are described
+in the following sections.
 
 ** Structure of code blocks
 :PROPERTIES:
@@ -16046,7 +16047,7 @@ An inline code block conforms to this structure:
 
 : src_{}
 
-#+teinfo: @noindent
+#+texinfo: @noindent
 or
 
 : src_[]{}
-- 
2.14.2


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


Re: [O] Git repository error

2017-12-18 Thread Thomas S. Dye

Nick Dokos writes:

> git clone  git://orgmode.org/org-mode.git
>
> all fail, but
>
>git clone http://orgmode.org/org-mode.git
>
> succeeded and `git remote update' when the remote is the
> http version, succeeds as well.

This describes my experience yesterday, as well.

All the best,
Tom

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



Re: [O] [RFC] Dog food, anyone?

2017-12-17 Thread Thomas S. Dye
Aloha Nicolas,

Nicolas Goaziou writes:

> "Thomas S. Dye" <t...@tsdye.com> writes:
>
>> My concern is with the time between a working manual.org and when it
>> becomes the official source.  IIRC, I wasn't able to get a commitment to
>> make manual.org the official source, so was looking at an open-ended
>> future of what I considered arduous maintenance, without any real hope
>> the project might succeed.  Perhaps you have that wrinkle ironed out?
>
> Not really. But the shift is a step forward. It cannot see how that
> could fail (famous last words).

:)

> The file is in master branch. You need to use that to export it.

Thanks.

All the best,
Tom

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



Re: [O] [RFC] Dog food, anyone?

2017-12-17 Thread Thomas S. Dye
Aloha Adrian,

Adrian Bradd writes:
>
> I support the move to manual.org. If there are concerns about the
> quality of the manual.org file and its exported .texi manual that
> prevent it from becoming the master source one could ask contributors to
> add information to both the .texi and .org file until the final
> conversion is made. At the very least this would prevent an individual
> from taking all the load.
>
> Was there resistance to the move to manual.org previously? Or was the
> issue one of apathy?

I don't know exactly.  I think there were legitimate concerns at the
time that manual.org required more work to produce a standard org.texi,
and some doubt whether it would indeed be possible.

I don't think apathy was a factor. IIRC, there was a lot of support for
the idea, including Carsten's hope that Org mode could "eat it's own dog
food."

All the best,
Tom

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



Re: [O] [RFC] Dog food, anyone?

2017-12-17 Thread Thomas S. Dye
Aloha Nicolas,

Nicolas Goaziou writes:

> Once manual.org is the official source for org.texi, there is no need to
> modify "org.texi" directly. Only the occasional back-port from upstream
> requires to do so, which is very manageable.
>
> Do you foresee any difficulty?

No, once manual.org is the official source for org.texi, there shouldn't
be any difficulty AFAICT.

My concern is with the time between a working manual.org and when it
becomes the official source.  IIRC, I wasn't able to get a commitment to
make manual.org the official source, so was looking at an open-ended
future of what I considered arduous maintenance, without any real hope
the project might succeed.  Perhaps you have that wrinkle ironed out?

BTW, I wasn't able to export manual.org using Org mode version 9.1.4
(9.1.4-elpaplus @ /Users/dk/.emacs.d/elpa/org-plus-contrib-20171205/).
It fails with this message:

format: Symbol’s value as variable is void: M-x

Does it depend on a more recent Org mode?

All the best,
Tom

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



Re: [O] [RFC] Dog food, anyone?

2017-12-17 Thread Thomas S. Dye
Aloha Nicolas,

It's a real pleasure to know that Org can now eat its own dog food (and
to see Carsten's memorable phrase on the Org mode list again). Many
thanks for picking up this orphaned project. I look forward to the day
it serves as the source for org.texi.

When I was working on the project several years ago, I didn't notice any
constraints introduced by Jonathan Leech-Pepin's ox-texinfo. For me, the
hard part was trying to synchronize with the on-going changes to
org.texi, which quickly defeated my best efforts. Have you figured out
how to automate that?

All the best,
Tom

Nicolas Goaziou writes:

> Hello,
>
> The task started by Thomas S. Dye a couple years ago is now complete.
> The "manual.org" file in "contrib/" directory is an up-to-date,
> sometimes enhanced, version of the Org manual. Org can now eat its own
> dog food.
>
> During the process, I had to re-organize some parts of the manual (e.g.,
> "Working with source code" section, the concept index...) and improve
> the "texinfo" export back-end, which was not up to the task when Thomas
> started it.
>
> Ultimately, this file is going to serve as the source for a new
> "org.texi". IOW, it could go into "doc/" and "make info" should export
> "manual.org" to "org.texi". First, however, it would be nice to review
> it, either as an Org file, or within the Info viewer, with
>
>(require 'ox-texinfo)
>
> and
>
>`C-c C-e i o' from "manual.org".
>
> Note that Info output is expected to be sometimes different from the
> current manual. This is not a 1:1 conversion.
>
> Feedback welcome!
>
>
> Regards,


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



Re: [O] can't get org-mode noweb tangle to work

2017-11-24 Thread Thomas S. Dye
Aloha Charlie,

Charles R (Charlie) Martin writes:

> I'm trying to get literate programming with `:noweb` syntax working in
> org-mode. I think I'm down to about the minimum case:
>
> #+TITLE: Console Tic Tac Toe
> #+SUBTITLE: A Literate Program in EMACS Org-Mode
> #+AUTHOR: Charlie Martin
> #+STARTUP: showall
>
> #+BEGIN_SRC python :tangle yes :noweb
>   import sys
>   import os
>
>   def main(args):
>   <>
>
>   if __name__ == "__main__":
>   main(sys.argv)
> #+END_SRC
>
> #+NAME: initialize-the-game-board
> #+BEGIN_SRC python :tangle yes :noweb
>   board = [[-1 for x in range(3)] for y in range(3)]
> #+END_SRC
>
> but when I tangle it I get:
>
> import sys
> import os
>
> def main(args):
> <>
>
> if __name__ == "__main__":
> main(sys.argv)
>
> board = [[-1 for x in range(3)] for y in range(3)]
>
> I've tried permuting the argument, flags, and so on to no avail.
>
> EMACS version is 25.3.1 MacOS, org-mode 9.1.3

I think it should be :noweb yes

hth,
Tom

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



Re: [O] "Reference Dump" rant

2017-11-21 Thread Thomas S. Dye

Lawrence Bottorff writes:

>> > I guess I'm saying it would be nice to have a big omnibus O'Reilly-style
>> > tutorial on how to use org-mode. I've hung with org-mode because I think
>> > it's great and, IMHO, should become a standard tool in all
>> > STEM/STEM-education settings. Think of all those high schools (and even
>> > colleges) forcing students to use "graphic calculators." What a waste!

Worg has some fits and starts in the direction of tutorials and such.
It might be a good place to start.

All the best,
Tom

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



Re: [O] org-mode in French

2017-11-12 Thread Thomas S. Dye
Aloha Frederic,

gmx writes:

> Hello,
> I've been using Org-mode for several months now, with pleasure.
> However, I would like the .tex files use some packages (babel,
> french...), a particular koma-script class (scrartcl), etc., which allow
> me to release a. pdf file with French typographical standards.
>
> How to do this?
>
> Thank you for your help,
> Frederic

Below are two examples that should help you on your way.  See the
documentation for org-latex-classes for an explanation of
[NO-DEFAULT-PACKAGES], etc., which you might or might not want to use.

You can put the (add-to-list ...) functions in your .emacs so they are
always available, or you can call one of the source code blocks from a
buffer you want to export.  I find it convenient to do this:

#Local Variables
# eval: (org-sbe "koma-article-palatino")

You'll also need to specify the LaTeX class in the buffer you want to export:
#+LATEX_CLASS: koma-article-palatino

hth,
Tom

#+name: koma-article-times
#+header: :results silent
#+begin_src emacs-lisp
  (require 'ox-latex)
  (add-to-list 'org-latex-classes
   '("koma-article-times"
 "\\documentclass{scrartcl}
   [NO-DEFAULT-PACKAGES]
   [PACKAGES]
   [EXTRA]
  \\usepackage{microtype}
  \\usepackage{tgtermes}
  \\usepackage[scale=.9]{tgheros}
  \\usepackage{tgcursor}
  \\usepackage{paralist}
  \\usepackage[T1]{fontenc}
  \\usepackage{graphicx}
  \\usepackage{textcomp}
  \\usepackage{hyperref}
  \\newcommand{\\rc}{$^{14}$C}"
 ("\\section{%s}" . "\\section*{%s}")
 ("\\subsection{%s}" . "\\subsection*{%s}")
 ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
 ("\\paragraph{%s}" . "\\paragraph*{%s}")
 ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
#+end_src

#+name: koma-article-palatino
#+header: :results silent
#+begin_src emacs-lisp
   (require 'ox-latex)
   (add-to-list 'org-latex-classes
'("koma-article-palatino"
  "\\documentclass{scrartcl}
   [NO-DEFAULT-PACKAGES]
   [PACKAGES]
   [EXTRA]
   \\usepackage{microtype}
   \\usepackage{tgpagella}
   \\linespread{1.05}
   \\usepackage[semibold]{sourcesanspro}
   \\usepackage{tgcursor}
   \\usepackage{paralist}
   \\usepackage[T1]{fontenc}
   \\usepackage{graphicx}
   \\usepackage{textcomp}
   \\usepackage{hyperref}
   \\newcommand{\\rc}{$^{14}$C}"
  ("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
  ("\\paragraph{%s}" . "\\paragraph*{%s}")
  ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
#+end_src


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



Re: [O] function for inserting a block

2017-11-11 Thread Thomas S. Dye

Eric Abrahamsen writes:

> Rasmus <ras...@gmx.us> writes:
>
>> Hi Eric,
>>
>> Eric Abrahamsen <e...@ericabrahamsen.net> writes:
>>
>>>> Also, Eric, it seems that org-structure-template-alist only supports a
>>>> single letter for short-hands (the car of an entry in
>>>> org-structure-template-alist is a char).  I used to have blocks like "<ab"
>>>> expanding to an "abstract" special-block, which I guess isn’t possible
>>>> anymore?
>>>
>>> I hadn't thought of that. Really, all I ever wanted was to wrap things
>>> in blocks...
>>>
>>> I don't see any reason why org-structure-template-alist couldn't go back
>>> to using string keys. Then we could use read-string, and wouldn't have
>>> to have special  behavior -- a string that didn't exist in the
>>> alist could just be used literally to make a block.
>>
>> I’d prefer that.  For some special blocks, a few characters might makes it
>> more intuitive, e.g. "def" → "definition", "hyp" → "hypothesis" etc.
>
> Here's the simplest solution.
>
> There still remains the fact that `org-structure-template-alist' has
> changed format, and `org-try-structure-completion' no longer exists.
> That may still annoy some people who were using the internals of the
> process, but...

Would something like this work?

(defun org-try-structure-completion ()
  (tempo-complete-tag))

All the best,
Tom

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



Re: [O] function for inserting a block

2017-11-08 Thread Thomas S. Dye
Aloha Nicolas,

Nicolas Goaziou writes:

> Hello,
>
> Takaaki Ishikawa <tak...@ieee.org> writes:
>
>> I also support the idea of keeping "<s" as it was.
>> Please give importance to the backward compatibility in this case.
>
> I explained why I thought it could be removed. I also suggested
> solutions to get an equivalent feature without implementing it in Org.
>
> What is wrong with Abbrev mode, skeletons, tempo.el, expand.el, all
> bundled with Emacs, or YASnippet, in the Emacs ecosystem? It sounds like
> NIH. Or, to put it differently: why in the world would Org implement its
> own template system?

The "why in the world" question is likely one that can be answered by
the author of the Org template system.

> The only argument so far is "<" cannot be expanded since it not word
> constituent. Seriously. "<" has no meaning anyway. You can use "@",
> which is word constituent and just as meaningless. So, you can define,
> e.g., a skeleton, that will expand "@s" to "#+begin_src\n#+end_src".
>
> We can even document how to do it in the manual.

For me, the issue isn't about how the template system is implemented, it
is about backwards compatibility of (org-try-structure-completion).

All the best,
Tom

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



Re: [O] function for inserting a block

2017-11-08 Thread Thomas S. Dye

Berry, Charles writes:

>> On Nov 8, 2017, at 6:07 AM, Rasmus <ras...@gmx.us> wrote:
>>
>> I think the template expansion a la "<s" is brilliant.  I used to have
>> YASnippet installed for many years, and I never figured out how to use it
>> properly.  To me, it is a bit too complex a replacement.
>
>
> Me too.  "<s" just works. And it is brutally easy to extend.
>
> I suspect that there will be cries of pain and anger from others who have not 
> tuned in to this thread if it is removed.
>
> Chuck

Agreed.  It would be great if backward compatibility could be
maintained.  I use (org-try-structure-completion) all the time.

All the best,
Tom

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



Re: [O] Export attributes for babel blocks

2017-10-02 Thread Thomas S. Dye
Aloha Juan Amiguet,

Juan Amiguet writes:

> Dear all,
>
> I have been having this issue for quite a while perhaps I am using the
> feature wrong and someone can enlighten me or perhaps someone can point me
> at the bit of code I can patch it myself.
> Here is the issue:
>
> I have a babel block such as
>
> #+begin_src dot :file test.png
> digraph test {
> A -> B
> }
> #+end_src
>
> This will create after execution a
>
> #+RESULT:
> [[file:./test.png]]
>
> Now if I would like have something like :width .5/.linewith as a attribute
> to the image the only I have found is to do the following
>
> #+begin_src dot :file test.png :exports none
> digraph test {
> A -> B
> }
> #+end_src
>
> #+attr_latex: width=.5/linewidth
> [[file:./test.png]]
>
> Is there a way of passing the export attributes to babel blocks in a way in
> which from direct rendering of the document things work and I can adjust?
> If now which part of the org mode codebase controls all of this?
>
> Thanking you all in advance.

Dot doesn't know anything about the linewidth you might be using in
LaTeX.  LaTeX will take any image and reproduce it at .5/linewidth,
regardless of dot settings.

The :cmdline header argument for dot is documented here:
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-dot.html

You can find links to the dot command line arguments.  Babel gives you
full access to the dot command line.

hth,
Tom

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



Re: [O] (gnus-icalendar-org-setup) not evaluated in .emacs?

2017-09-20 Thread Thomas S. Dye
Aloha,

Lars-Johan Liman writes:

>> 3. I now use org to manage my init file. In fact, I have a few init
>> files. I have a bare bones minimal init file which I use when I need to
>> debug a specific feature/package or generate bug reports, I have an
>> experimental one where I play with new things and I have my stable
>> one. Using org, I can just 'tangle' a new init based on one of those
>> files whenever I need it. I started by just putting all my existing
>> setup into a block in an org file and exporting that as elisp. As time
>> permitted, I broke bits off into their own blocks with explanatory
>> comments/text so that I can remember why/what of the block.
>
> Can you expand on how using Org for this is done? Examples?
> Documentation?
>
>   Cheers,
> /Liman
> #-
> # Lars-Johan Liman, M.Sc.  ! E-mail: li...@cafax.se
> # Cafax AB ! HTTP  : //www.cafax.se/
> # Computer Consultants, Sweden ! Voice : +46 8 - 564 702 30
> #-

An example from a few years ago is here:
https://github.com/eschulte/emacs24-starter-kit

hth,
Tom

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



Re: [O] Org latex pdf syncing

2017-09-17 Thread Thomas S. Dye

Nick Dokos writes:

> Amos Bird <amosb...@gmail.com> writes:
>
>> Hi,
>>
>> Is there a way to support pdf syncing when exporting and opening pdf in org 
>> mode?
>>
>
> Meaning that if you make a change to the org file, you see the change 
> immediately
> in the displayed PDF? I don't think there is a built-in way to do that.

Or, if syncing means what SyncTeX does for TeX source code, so that it
is possible to jump back and forth to the same place in the TeX and pdf
documents, the answer is the same as Nick's, that there is no built in
way to do that in Org mode.

All the best,
Tom

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



Re: [O] LaTeX > PDF blocked by extender chars in filename

2017-08-26 Thread Thomas S. Dye
Aloha Eduardo,

In my experience, having both org and org-plus-contrib installed is a
problem.  You might want to settle on the one or the other, then see if
your problem persists.

hth,
Tom

Eduardo Mercovich writes:

> Hola Nicolas.
>
>>> The file > img/ProcesoDeDiseñoDeInteraccion.pdf
>>> was translated/inserted on the org buffer as >
>>> img/ProcesoDeDise%C3%B1oDeInteraccion.pdf
>
>> What command did you use to "translate/insert" the filename?
>
> C-c C-l with keyboard and tab completion.
>
>>> + Org-mode: Org-mode version 8.3.4 (8.3.4-88-g792bb9-elpaplus)
>
>> This release is old. Could you update to a more recent one?
>
> Sure. Upgraded from the package manager and now I have
> org-20170821 and org-plus-contrib-20170821. Both from elpa. Would
> it be better from the org repository?
>
> org-version gives: Org mode version 9.0.9
> (9.0.9-88-g251f88-elpaplus [...])
>
>
> Repeating the same experiment now results in:
>
> 1. Org inserts the same string
> (file:img/ProcesoDeDise%C3%B1oDeInteraccion.pdf)
>
> 2. But export is not blocked! :)
>
> 3. The linked file is not present on the exported pdf (may not be
> an org issue, but about other latex to pdf component)...
>
> I hope this is useful.
> How do I proceed from here? Any other test or info to report?
>
> Thanks a lot for your hard work on Org. :)


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



Re: [O] ox-taskjuggler on MELPA useful despite org-plus-contrib

2017-08-09 Thread Thomas S. Dye
In case it is useful, here is Achim's post:

From: Achim Gratz
To: emacs-orgmode@gnu.org
Subject: Re: [O] Stable releases
Flags: replied, seen, list
Date: Sat Aug 22 07:44:14 2015
Maildir: /TSDYE/INBOX
List: emacs-orgmode.gnu.org

Thomas S. Dye writes:
> I do have a technical question that you or someone else on the list
> might be able to answer for me.  When I downloaded the Babel languages
> from melpa just now, the elpa version of Org mode was also downloaded
> and installed, even though I didn't ask for it.  Why is this?

Although you don't say which package you tried, I would guess that the
"org" package is specified as a dependency, likely with some minimum
version.

> Can it be disabled? Must the elpa Org mode be installed and activated
> in order for the Org mode packages to work?

>From the point of package manager anything installed from the outside
doesn't exist.  You can fake that in various way, for instance by
creating a package directory "org-21991231" and putting an org-pkg.el
with

(define-package "org" "21991231" "Fake Org package for dependency resolution" 
'nil)

in it.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs


Achim Gratz writes:

> Adam Porter writes:
>> I've had the same problem, I have to manually delete the extra org
>> package now and then.  I wonder if a dummy package would prevent
>> package.el from reinstalling it...
>
> Yes it does and I've provided instructions on how to do that quite some
> time ago on this list.
>
>
> Regards,
> Achim.


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



Re: [O] ox-taskjuggler on MELPA useful despite org-plus-contrib

2017-08-08 Thread Thomas S. Dye
Aloha Simon,

Spacemacs has this problem, too.  The solution there is to
byte-recompile org-plus-contrib after an update.

hth,
Tom

Simon Guest writes:

> Hi Nicolas,
>
> My problem with org-plus-contrib exhibited itself when using a .emacs.d
> based on Steve Purcell's, https://github.com/purcell/emacs.d. Specfically,
> when loading ob-R, I got this error:
>
> Invalid function: org-babel-header-args-safe-fn
>
> In response to your email, just now I stripped that config right back to
> basics, and found that my problem went away, and I was able to load ob-R
> after all.  Sorry, I should have done that before.
>
> Having realised that, I think I should report this against Steve Purcell's
> .emacs.d, and leave you guys alone.
>
> Thanks for your help.
>
> cheers,
> Simon
>
> On 8 August 2017 at 19:50, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
>
>> Hello,
>>
>> Simon Guest <s...@cantab.net> writes:
>>
>> > Well, almost as soon as I started on that, I see some issues around
>> mixing
>> > old/new org-mode functionality, so this seems like a not-so-good idea
>> after
>> > all.
>> >
>> > In particular, ox-taskjuggler is using the very new org-duration
>> > library.
>>
>> You could use "ox-taskjuggler" from maint.
>>
>> > I'll think of another approach, not using MELPA.
>>
>> I suggest to use GNU ELPA instead.
>>
>> > At least until the underlying problem with org-plus-contrib is
>> > resolved.
>>
>> What exactly is the underlying problem?
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>>


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



Re: [O] org-plus-contrib, where is library-of-babel.org?

2017-07-27 Thread Thomas S. Dye
Aloha Rasmus,

I agree, and believe the best course forward is to resolve the licensing
of library-of-babel.org (which appears not to be problematic) and
include the file in the emacs distribution.

When I asked on the list for advice how to install library-of-babel.org
from Worg, there was no response, which suggests to me that few users
actually work out a way to install it from Worg.

All the best,
Tom

Rasmus writes:

> Kyle Meyer <k...@kyleam.com> writes:
>
>> Hi Bastien and Rasmus,
>>
>> Any further thoughts on this?  If we're still not sure what to do with
>> the file, I'd vote that we remove it from Emacs for now so that we don't
>> let an unlicensed file sit in the Emacs repo.
>
> If it's to be referred in the manual it should be there IMO.  Otherwise,
> it could be removed from both places.
>
> I personally don’t understand how it would be more convenient to host it
> on Worg.
>
> Nonetheless, I do not feel strongly against removing it.
>
> Rasmus


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



Re: [O] org-plus-contrib, where is library-of-babel.org?

2017-07-12 Thread Thomas S. Dye
Aloha all,

Rasmus writes:

> Bastien Guerry <b...@bzg.fr> writes:
>
>> Kyle Meyer <k...@kyleam.com> writes:
>>
>>>>> Apparently, library-of-babel.org is not distributed with the Org mode
>>>>> that ships with emacs.  Not sure why that is.  I'm guessing it's a
>>>>> license issue?
>>>>
>>>> It will be in the next release (in /emacs/etc/org/).  If there's a license
>>>> issue it needs to be removed.
>>
>> The reason why this library-of-babel.org was not in Emacs is not
>> because of its lack of license.  I guess it's because Carsten and
>> Eric didn't think of it as something that should land in Emacs.
>
> Fine by me, but then let’s remove the references to it in the manual.
>
>> Hence my will to clarify this by moving it to Worg, where it will
>> be more easily accessed.
>
> I personally do not see how that is more easily accessible.  If part of
> Org, it’s already there when I start Emacs.  If it lives in Worg, the user
> must first wget it and tell Emacs how to find it.

I asked Eric Schulte about his thoughts on library-of-babel.org and the
current question of whether it should live on Worg or be distributed
with emacs.

   I don't recall why I would have thought that the library-of-babel.org
   shouldn't be distributed with Emacs so, assuming this is a position I
   held, I can't speak to the merit of my argument.

   Sorry I can't be of more help... For what it's worth I can't currently
   think of a good reason why this should not be distributed with Emacs.
   However, the same care should be taken with entries in the library as
   with any other executable code in Emacs that will run on user's
   machines.

   My thinking today is that this decision should be made based on the
   utility (to how many users) vs. the weight this could add to an Emacs
   install.  I thought Emacs was headed to distribution as a smaller core
   with more moved into external packages, but I haven't seen any evidence
   of that yet.

hth,
Tom

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



  1   2   3   4   5   6   7   8   9   10   >