Re: [O] Questions after Attempt at using org-publish per https://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html

2018-11-04 Thread Jud Taylor
I researched again and found

- https://orgmode.org/worg/exporters/ox-overview.html
- http://article.gmane.org/gmane.emacs.orgmode/65574
- https://orgmode.org/manual/HTML-export.html#HTML-export
- https://orgmode.org/manual/CSS-support.html#CSS-support

I will try to remove the CDATA in exported HTML files by using

"To just turn off the default style, customize 
org-html-head-include-default-style variable, or use this option line in the 
Org file.

#+OPTIONS: html-style:nil"

I added the options to both index.org and remember.org, reloaded the alist, 
then republished.

It Verked!

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Saturday, October 13, 2018 9:55 PM, Jud Taylor  
wrote:

> I have some questions about how to use ox-publish to create static sites.
>
> I have followed steps documented at 
> https://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html.
>
> I have documented my steps and copied source and output at 
> https://github.com/gptix/org-site-test
>
> I have tried to search for answers on the emacs-orgmode mailing list, and on 
> the web.
>
> My three current issues:
>
> - I do not understand how css info is being injected into output html files. 
> I did not create any css file to be referenced, but styling is being included 
> as CDATA.
>
> - I do not understand what the
> :auto-preamble t
> in a component is for.
>
> - I do not understand the relation between
> (require 'ox-publish)
> at the beginning of the tutorial, and
> (require 'org-publish)
> in the portion of the tutorial describing how to actually publish.
>
> I'd love any help or a pointer to where I can read about these.
>
> Thanks.
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

[O] org-habit: allow overriding org-scheduled-past-days and always including time of day

2018-11-04 Thread John Lee
Hi

Here's a couple of patches that add new org-habit variables.  I hope the 
variable documentation describes them sufficiently: if not I need to change the 
docs so if you review these patches please read the patch before the rest of 
this email so that you're not "cheating"!


Does the idea behind each of these seem appropriate to people?  They work for 
me of course, and behaviour is unchanged unless you set non-default values for 
the new variables -- but I know people have different workflows.

My own workflow around this is similar to GTD, so I'm using SCHEDULED as 
basically a way to get TODO items to show up after the scheduled date, not to 
show up in the calendar except as a reminder that I have new TODOs.  For that 
reason I set org-scheduled-past-days to a low value (3 right now).  I also set 
org-agenda-todo-ignore-scheduled to 'future and 
org-agenda-tags-todo-honor-ignore-options to t (not directly relevant here 
except as context).  For habits that causes habits not to show up sometimes 
because of the short org-scheduled-past-days, which isn't appropriate for my 
habits: if I say .+5d, I still want to see the habit there if it's due, even if 
it's been 4 days since the last done date (which is more than the 3 days of 
org-scheduled-past-days).  This motivates `org-habit-scheduled-past-days'.

Similarly, since I want to do some of my habits at a particular time of day, 
org-agenda's omitting of the time of day from the scheduled timestamp if this 
is a "repeat" (i.e. I missed doing the habit) is unhelpful for habits, because 
now I have to scan though a long-ish list of habits (5 or 10 right now!) and 
think "is now the right time, should I have done that already?" for every habit 
in the list, rather than just eyeballing it to see which ones are around now in 
time.  This motivates `org-habit-always-show-time'.

I have not yet submitted the FSF copyright assignment form but am prepared to 
do so.


>From 7bcf7b70b201af7a3d3cbbcf6a95511944370627 Mon Sep 17 00:00:00 2001
From: John Lee 
Date: Sun, 4 Nov 2018 23:11:17 +
Subject: [PATCH 1/2] org-habit: Add org-habit-scheduled-past-days

* lisp/org-habit.el: Add new variable `org-habit-scheduled-past-days'
  to allow overriding `org-scheduled-past-days' for habits

* lisp/org-agenda.el (org-agenda-get-scheduled): override
  `org-scheduled-past-days' for habits if
  `org-habit-scheduled-past-days` is not nil
---
 lisp/org-agenda.el |  5 -
 lisp/org-habit.el  | 11 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 180a0612c..e2bd5cc2d 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6196,7 +6196,10 @@ scheduled items with an hour specification like [h]h:mm."
   habitp
   (bound-and-true-p org-habit-show-all-today))
(when (or (and (> ddays 0) (< diff ddays))
- (> diff org-scheduled-past-days)
+ (> diff (if habitp
+ (or org-habit-scheduled-past-days
+ org-scheduled-past-days)
+   org-scheduled-past-days))
  (> schedule current)
  (and (/= current schedule)
   (/= current today)
diff --git a/lisp/org-habit.el b/lisp/org-habit.el
index 375714e35..b8415bdde 100644
--- a/lisp/org-habit.el
+++ b/lisp/org-habit.el
@@ -89,6 +89,17 @@ It will be green even if it was done after the deadline."
   :group 'org-habit
   :type 'boolean)
 
+(defcustom org-habit-scheduled-past-days nil
+  "Non-nil means the value of this variable will be used instead
+of org-scheduled-past-days, for habits only.
+Setting this to say 1 is a way to make habits always show up
+as a reminder, even if you set org-scheduled-past-days to a small
+value because you regard SCHEDULED items as a way of 'turning on'
+TODO items on a particular date, rather than as a means of
+creating calendar-based reminders."
+  :group 'org-habit
+  :type 'integer)
+
 (defface org-habit-clear-face
   'background light)) (:background "#8270f9"))
 (((background dark)) (:background "blue")))
-- 
2.17.1

>From a1d6e3af978237b3f555682a111c2439f17b45b9 Mon Sep 17 00:00:00 2001
From: John Lee 
Date: Sun, 4 Nov 2018 23:17:15 +
Subject: [PATCH 2/2] org-habit: Add org-habit-always-show-time

* lisp/org-habit.el: Add new variable `org-habit-always-show-time'
  to force always showing the time of day

* lisp/org-agenda.el (org-agenda-get-scheduled): honour
  `org-habit-always-show-time`
---
 lisp/org-agenda.el | 12 +---
 lisp/org-habit.el  | 10 ++
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index e2bd5cc2d..08e286730 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6253,9 +6253,15 @@ scheduled items with an hour specification like [h]h:mm."
   (head 

Re: [O] FW: [RFC] Link-type for attachments, more attach options

2018-11-04 Thread Nicolas Goaziou
Hello,

Gustav Wikström  writes:

> I’ve attached a patch with some suggested additions to org-attach.
> Patch comments below. Please review.

Thank you. Some comments follow.

> * Add new linktype "attached" for attachments

This seem a bit long. Why not "att" links?

> * Add further options for ATTACH_DIR
>
> When working with ATTACH_DIR there are now a couple of new options available:
> - org-attach-dir-inherit-by-default

What is the difference between this and `org-attach-allow-inheritance'?

> - org-attach-dir-create-if-not-exist

What is the use-case for this one? It doesn't seem terribly useful at
first glance.

> - org-attach-dir-relative

I'm not sure to understand this one.
>
> +This list shows the full set of built-in external link types:
> +| http   | web |
> +| https  | secure web  |
> +| doi| DOI for electronic resources|
> +| file   | file-links  |
> +| file+sys   | file-links forced to open via OS|
> +| file+emacs | file-links forced to open via emacs |
> +| attached   | links to attachments for nodes  |
> +| docview| doc-view mode   |
> +| id | Link to heading by id   |
> +| news   | Usenet link |
> +| mailto | mail link   |
> +| mhe| MH-E folder link|
> +| rmail  | Rmail link  |
> +| gnus   | Gnus link   |
> +| bbdb   | BBDB link   |
> +| irc| IRC link|
> +| info   | Info link   |
> +| shell  | shell command   |
> +| elisp  | interactive elisp command link  |
> +
> +The following list shows examples for each link type.
> +
> +| =http://www.astro.uva.nl/=dominik=| on the web 
>  |
> +| =doi:10.1000/182= | DOI for an electronic resource 
>  |
> +| =file:/home/dominik/images/jupiter.jpg=   | file, absolute path
>  |
> +| =/home/dominik/images/jupiter.jpg=| same as above  
>  |
> +| =file:papers/last.pdf=| file, relative path
>  |
> +| =./papers/last.pdf=   | same as above  
>  |
> +| =file:/ssh:me@some.where:papers/last.pdf= | file, path on remote machine   
>  |
> +| =/ssh:me@some.where:papers/last.pdf=  | same as above  
>  |
> +| =file:sometextfile::NNN=  | file, jump to line number  
>  |
> +| =file:projects.org=   | another Org file   
>  |
> +| =file:projects.org::some words=   | text search in Org file[fn:28] 
>  |
> +| =file:projects.org::*task title=  | heading search in Org file 
>  |
> +| =file+sys:/path/to/file=  | open via OS, like double-click 
>  |
> +| =file+emacs:/path/to/file=| force opening by Emacs 
>  |
> +| =attached:projects.org=   | file in folder attached to 
> headline |
> +| =attached:projects.org::some words=   | text search in attached file   
>  |
> +| =docview:papers/last.pdf::NNN=| open in doc-view mode at page  
>  |
> +| =id:B7423F4D-2E8A-471B-8810-C40F074717E9= | link to heading by ID  
>  |
> +| =news:comp.emacs= | Usenet link
>  |
> +| =mailto:ad...@galaxy.net= | mail link  
>  |
> +| =mhe:folder=  | MH-E folder link   
>  |
> +| =mhe:folder#id=   | MH-E message link  
>  |
> +| =rmail:folder=| Rmail folder link  
>  |
> +| =rmail:folder#id= | Rmail message link 
>  |
> +| =gnus:group=  | Gnus group link
>  |
> +| =gnus:group#id=   | Gnus article link  
>  |
> +| =bbdb:R.*Stallman=| BBDB link (with regexp)
>  |
> +| =irc:/irc.com/#emacs/bob= | IRC link   
>  |
> +| =info:org#External links= | Info node link 
>  |
> +| =shell:ls *.org=  | shell command  
>  |
> +| =elisp:org-agenda=| interactive Elisp command  
>  |
> +| =elisp:(find-file "Elisp.org")=   | Elisp form to evaluate 
>  |

I'm not sure to like the change above. It introduces a lot of
redundancy.

>  Here is the syntax of the different ways to attach a search to a file
>  link, together with explanations for each:
>  
>  #+begin_example
> 

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

2018-11-04 Thread Nicolas Goaziou
Hello,

Christian Moe  writes:

> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
> option as a list, as in this example from the manual
> ([[info:org#Applying custom styles]]):
>
>   #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>
> This is needed if you want a complex style with e.g. an image in the
> header.
>
> Exporting this causes an "Invalid specification of styles.xml file"
> error on my recent ELPA version. The problem seems to be that the option
> is treated as a string and never tested to see if it contains a list.
>
> To reproduce the problem, place the attached documents
> odt-styles-test.org and odt-test-styles.odt in the same directory, then
> export odt-styles-test.org to ODT. The result should have a unicorn in
> the letterhead.
>
> The below quick-and-dirty patch seems to fix it, but I'm sure there's a
> better approach.

Thank you. I applied your patch with an additional check: the value should
be enclosed within round brackets.

Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Capture template insertion fails with #+FOO [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/phil/.emacs.d/elpa/org-9.1.14/)]

2018-11-04 Thread Philip Hudson
On Sun, 4 Nov 2018 at 14:03, Nicolas Goaziou  wrote:
>
> Philip Hudson  writes:
>
> > On Sat, 3 Nov 2018 at 08:34, Nicolas Goaziou  wrote:
>
> >> I cannot see your template, since you did not send it yet. I assume it
> >> uses an `entry' type.
> >
> > No assumption involved. I stated so plainly.
>
> Indeed.
>
> >> Barring `plain', all capture types enforce
> >> a certain structure for contents. The `entry' type expects a node, which
> >> is roughly a headline plus contents, as noted in the manual:
> >>
> >>  ‘entry’
> >>   An Org mode node, with a headline.  Will be filed as the child
> >>   of the target entry or as a top-level entry.  The target file
> >>   should be an Org file.
> >
> > Agreed, understood, and 100% the case in both my case (I'm afraid
> > you'll just have to take my word for it) and in the trivial but
> > effectively illustrative minimal failing case I gave you.
>
> No, it is not the case. AFAIU, in the minimal failing case, you capture
>
> #+FOO: bar
> * Baz
>
> This is _not_ a node. A node starts with a headline and everything is
> contained within that headline. So it doesn't qualify as a valid `entry'
> capture type.

That's disappointing, and, obviously, news to me. So I have not
encountered a regression but rather a tightening of the existing
documented contract. Is that a fair interpretation of what you're
saying? If so, and not that I doubt you, do you have a reference for
that?

> > The doco seems fine to me. I relied on it for the definition of my
> > template, which has worked as expected for years.
>
> It might be that you misinterpreted the definition of a node. Hence my
> suggestion to improve the documentation.

If this is the only place that the definition should appear (not
saying that I know or believe it is), then are we not free to say that
it could be otherwise? Effectively, in terms of actual behavior, the
definition of "node" (at least in this context) has been otherwise,
for several years at least. In other words, absent a formal definition
of interface/contract, the implementation /is/ the interface; this is
an implementation change, and thus (arguably) a regression
nevertheless.

In still other words, I'm arguing this:

The idea of 'entry type for templates, and of a node as we are
discussing it, is that a well-formed and valid Org file is composed
exclusively of these entities and nothing else. Correct?

If that is true, then, under your definition, no well-formed and valid
Org file constructed only from Org-capture using templates of the
'entry type can ever start with any number of #+FOO in-buffer
settings. This is clearly at odds with the established definition of a
well-formed and valid Org file.

> In any case, you can simply move the keywords below the headline, and be
> done with it.

Sorry if this is getting tiresome. At this point I'm content for you
to close this issue and move on if you'd rather. I'll change my
template type to 'plain, or find some other workaround. But if you'd
like to keep going for the sake of clarifying what the right and
proper meaning of 'entry and "node" are then I'm glad to participate.

-- 
Phil Hudson  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85



Re: [O] coderef does not provide file path for org-insert-link when not in original buffre

2018-11-04 Thread Nicolas Goaziou
Hello,

stardiviner  writes:

> Because the variable `org-src-source-file' is a bridge to pass info
> between two buffers "source buffer" and source block opened "dedicated
> buffer". So this variable must be global. Otherwise the "dedicated
> buffer" can't read it.

The variable is set in the "dedicated buffer", and is local to it. OTOH,
the source buffer doesn't need to read it, ever.

I committed a change in "master" branch. Could you tell me if it fixes
your issue?

Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Capture template insertion fails with #+FOO [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/phil/.emacs.d/elpa/org-9.1.14/)]

2018-11-04 Thread Nicolas Goaziou
Hello,

Philip Hudson  writes:

> On Sat, 3 Nov 2018 at 08:34, Nicolas Goaziou  wrote:

>> I cannot see your template, since you did not send it yet. I assume it
>> uses an `entry' type.
>
> No assumption involved. I stated so plainly.

Indeed.

>> Barring `plain', all capture types enforce
>> a certain structure for contents. The `entry' type expects a node, which
>> is roughly a headline plus contents, as noted in the manual:
>>
>>  ‘entry’
>>   An Org mode node, with a headline.  Will be filed as the child
>>   of the target entry or as a top-level entry.  The target file
>>   should be an Org file.
>
> Agreed, understood, and 100% the case in both my case (I'm afraid
> you'll just have to take my word for it) and in the trivial but
> effectively illustrative minimal failing case I gave you.

No, it is not the case. AFAIU, in the minimal failing case, you capture

#+FOO: bar
* Baz

This is _not_ a node. A node starts with a headline and everything is
contained within that headline. So it doesn't qualify as a valid `entry'
capture type.

> The doco seems fine to me. I relied on it for the definition of my
> template, which has worked as expected for years.

It might be that you misinterpreted the definition of a node. Hence my
suggestion to improve the documentation.

In any case, you can simply move the keywords below the headline, and be
done with it.

Regards,

-- 
Nicolas Goaziou



[O] [Suggest] Add a command org-attach-sync-all

2018-11-04 Thread tumashu
I alway forgot to run org-attach-sync when I manual update task's attach dir,
suggest add a sync all command like below:



``` 

(defun org-attach-sync-all ()
(interactive)
(org-map-entries #'org-attach-sync)
(org-align-all-tags))




```


[O] [SOLVED] Re: dynamic block :block thismonth seems not correct

2018-11-04 Thread stardiviner


This is because my today limited scope in :block thismonth.

-- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3