Re: [O] Patch adding from-logo to ox-koma-letter.el

[Grant Rettke]

On Fri, Apr 27, 2018 at 11:30 PM, Grant Rettke  wrote:
> Tested it manually with Elisp and also in buffer properties. There are
> four combinations (both in properties, both in Elisp, and then the two
> permutations).

Here is how it works, the same way as the other ones:

#+name: 
org_gcr_2018-04-27T22-46-38-05-00_mara_081C9DD8-1C37-4A55-833C-1BEC6AA754FF
#+begin_src sh
#+FROM_LOGO: \includegraphics{wnw-from-logo-1inx1in}
#+OPTIONS: from-logo:t
#+end_src

#+name: 
org_gcr_2018-04-27T22-46-38-05-00_mara_F28B56C1-0226-4AFB-B044-702315603A99
#+begin_src emacs-lisp
(setq org-koma-letter-from-logo "\\includegraphics{wnw-from-logo-1inx1in}")
(setq org-koma-letter-use-from-logo t)
#+end_src

If eventually this patch is accepted then I will update Worg with this variable.

[O] Patch adding from-logo to ox-koma-letter.el

[Grant Rettke]

Hi,

This patch adds from-logo support to ox-koma-letter.el.

Tested it manually with Elisp and also in buffer properties. There are
four combinations (both in properties, both in Elisp, and then the two
permutations).

It was a copy-and-paste job so I marked it as a tinychange even though
it was more than 15 lines.

Ran the system tests and they pass.

Sincerely,

Grant Rettke


0001-ox-koma-letter.el-Adds-from-logo-variable.patch
Description: Binary data

Re: [O] Please see attached debug-init

[Charles Millar]

Hello,


On 04/26/2018 11:13 PM, Nick Dokos wrote:

Charles Millar  writes:


Hi Nicholas,

On 04/26/2018 07:34 PM, Bastien wrote:

 Hi Charles,
 
 Charles Millar  writes:


 Attached --debug-init when starting -
 
 is this with emacs -Q?  If not, can you bisect your configuration?
 
 Thanks,
 
emacs -Q starts fine.


The problem may be with

require 'ox-XXX

When I worked my way down to (require 'ox-texinfo) there was no problem. When I 
uncomment that line the startup error appeared.

In the warnings buffer part of the message is

error: Invalid byte opcode: op=183, ptr=31

Byte compilation is not necessarily backwards compatible.

If the file was compiled with emacs 27, then earlier versions of emacs
will not necessarily be able to deal with it. If you recompile all
*.el files with emacs 24, they should work with emacs 24 and *also*
with emacs 27.


I update org using the https:// access to the git repo.

the Emacs 24 version is the debian package. Is this a factor?

Charlie
Charlie

Re: [O] add blocks to org-structure-template-alist

[Charles Millar]

Hi, again,

On 04/27/2018 07:09 PM, Bastien wrote:

Hi Charles,

Charles Millar  writes:


Is this correct of has the format changed?

The format slightly changed, please check this option's docstring.

Also see ORG-NEWS here, which I just updated:

https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L65

Let me know if you think this is informative enough for other
users.
Prior to posting I did read the docstring for 
org-structure-template-alist in version 9.1.12 and I found nothing 
concerning "roll your own" templates. I have also read your org-news 
entry as well as the other replies.


It is not clear to me - is it possible to write my own, fairly simple 
template with a few modifications that are a result of some recent 
changes or, for example, are elements such as those in 
tempo-define-template now required?


Thanks.

Charlie Millar

Re: [O] Bug: Usability for tags in master branch [9.1.12 (release_9.1.12-646-gb08245 @ c:/D-Drive/bin/org-mode/lisp/)]

[Nicolas Goaziou]

Hello,

Bernt Hansen  writes:

> With the below org file tags handling behaves in a surprising way.
>
>
> * TODO Test Parent  :PRODUCTION:MISC:
> ** TODO foo :BAR:
> ** keys to reproduce
>
>
> 1) At beginning of line 2 on TODO foo
> 2) M-ret to insert a new heading before foo
> 3) S-ret to get TODO keyword
>- auto fills :PRODUCTION:MISC: tags ?
> 4) SPC now does not work to insert a space after the TODO so I can type my 
> headline
>I have to use C-f
> 5) C-c C-q on this line now removes both tags
>I thought this was a bug but it seems to be removing tags that are defined 
>by the parent tasks and maybe that is intentional
> 6) When I enter a parent tag C-c C-q MISC RET it is displayed and then 
> removed if I do another C-c C-q
>This was surprising to me and I thought tag handling was completely broken
>Until I tried a tag not in a parent task
>try C-c C-q TAB MISC RET
>C-c C-q TAB PRODUCTION RET

I think this is now fixed. Could you confirm it?

Thank you!

Regards,

-- 
Nicolas Goaziou

Re: [O] add blocks to org-structure-template-alist

[Eric Abrahamsen]

Bastien  writes:

> Hi Nicolas,
>
> Nicolas Goaziou  writes:
>
>> In master branch, the format has changed.
>
> With the new template mechanism, can we have rich templates like the
> one Charles quotes?
>
>   (add-to-list 'org-structure-template-alist '("r" "#+begin_src rec :data? 
> :type \n#+end_src" ""))
>
> allowing cursor positioning, etc?
>
> If yes, what pointer can we add to ORG-NEWS?

I think more complicated templating has gone into org-tempo.el, which
can be loaded separately, and uses the tempo package. The docstring of
`tempo-define-template' shows what's possible.

Re: [O] Should wip-cite branch be merged to master?

[Nicolas Goaziou]

Hello,

András Simonyi  writes:

>   > [cite:author @Jones2018]
>
>   > Again, maybe it's worth having some shortcuts here for the common cases,
>   > but I think in general we want to try to avoid proliferation of basic
>   > citation commands. So for that reason I think we should just stick with
>   > the 'cite'/'(cite)' distinction as the two basic commands, perhaps with
>   > a more extensible/compositional syntax in each case for expressing the
>   > variations on these two basic types of citation.
>
> Again, I very much agree with the general direction of these proposals,
> but doesn't this mean that the citation element should have an attribute
> to represent which parts of an 'in text' citation are meant to be in the
> main text? (I think currently the only citation-specific attributes in
> the wip-cite branch are 'prefix', 'suffix' and 'parenthetical'.)

IIRC, in the proposal above was, i.e., [cite:foo: @Jones2018], "foo"
would be a well-defined style. IOW, it could cover much more than
a simple "author".

> I'd like to add that I don't consider the choice of the two citation
> commands a crucial one, 'cite' as 'in main text' and '(cite)' as
> 'parenthetical' could also be a perfectly usable syntax/semantics,
> especially if -- as Richard suggests -- we provide extension points to
> cover more complex use cases.

The syntax above might be such an extension point. It requires, however,
to find a way to associate a style definition to a given key.

Thank you to the answers of everyone involved so far. It's nice to see
this moving forward.

Regards,

-- 
Nicolas Goaziou

Re: [O] add blocks to org-structure-template-alist

[Nicolas Goaziou]

Hello,

Bastien  writes:

> With the new template mechanism, can we have rich templates like the
> one Charles quotes?
>
>   (add-to-list 'org-structure-template-alist '("r" "#+begin_src rec :data? 
> :type \n#+end_src" ""))
>
> allowing cursor positioning, etc?
>
> If yes, what pointer can we add to ORG-NEWS?

I don't know, but I would suggest to use Yasnippet or some other
specialized package for advanced templates like this one.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] add blocks to org-structure-template-alist

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> In master branch, the format has changed.

With the new template mechanism, can we have rich templates like the
one Charles quotes?

  (add-to-list 'org-structure-template-alist '("r" "#+begin_src rec :data? 
:type \n#+end_src" ""))

allowing cursor positioning, etc?

If yes, what pointer can we add to ORG-NEWS?

Thanks,

-- 
 Bastien

Re: [O] add blocks to org-structure-template-alist

[Bastien]

Hi Charles,

Charles Millar  writes:

> Is this correct of has the format changed?

The format slightly changed, please check this option's docstring.

Also see ORG-NEWS here, which I just updated:

https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L65

Let me know if you think this is informative enough for other
users.

Thanks,

-- 
 Bastien

Re: [O] add blocks to org-structure-template-alist

[Nicolas Goaziou]

Hello,

Charles Millar  writes:

> Hi,
>
> in my .emacs I have a couple of (add-to-list 
> 'org-structure-template-alist) blocks of my own, for example
>
> #+begin_src
>
> (add-to-list 'org-structure-template-alist '("r" "#+begin_src rec :data? 
> :type \n#+end_src" ""))
>
> #+end_src
>
> which I used until a few months ago.
>
> Is this correct of has the format changed?

In master branch, the format has changed. You may want to look at the
variable docstring.

Regards,

-- 
Nicolas Goaziou

[O] add blocks to org-structure-template-alist

[Charles Millar]

Hi,

in my .emacs I have a couple of (add-to-list 
'org-structure-template-alist) blocks of my own, for example


#+begin_src

(add-to-list 'org-structure-template-alist '("r" "#+begin_src rec :data? 
:type \n#+end_src" ""))


#+end_src

which I used until a few months ago.

Is this correct of has the format changed?

Charlie Millar

Re: [O] Should wip-cite branch be merged to master?

[András Simonyi]

Dear All,

thanks for your responses. I find John's list of the most important
capabilities of org-ref very useful and agree that in the long run we
should aim at providing all of these functionality for the new syntax as
well. One point where this might prove to be difficult is precisely the
set of provided citation commands since org-ref, being bib(la)tex
focused, can support all BibTeX/biblatex commands via its citation
links. This leads to Richard's comments on this topic:

  > one of the fundamental problems with citations, namely, they resist
  > attempts to separate 'content' from 'style'. It is hard to insert
  > citations into a document without making any assumptions about how they
  > will be rendered by the citation processor. And so it is hard to come up
  > with a syntax that is general enough to represent widely different
  > citation styles, in a way that makes those assumptions explicit in the
  > syntax of the unprocessed citation, so that the content of the citation
  > can be separated from how it will be rendered. Thus we see the huge
  > proliferation of different citation commands in e.g. BibLaTeX, natbib,
  > and similar packages. András' proposal would reintroduce some of the
  > complexity of BibLaTeX citation commands at the level of Org syntax.

These are very good points and I agree that the used citation style can
influence the way of writing to a large extent, which makes it virtually
impossible to devise a citation syntax using which one could switch any
document to a totally different style (say from author-date to footnote)
without any rewrites. I suppose in this respect (i.e., 'separating
content and style') our aim can only be to provide those few
style-independent abstractions that are possible to minimize the amount
of changes needed, plus perhaps some style-dependent constructs.

  > I want to point out that one of the goals of the original discussion
  > to come up with an Org syntax that is simpler and does a better job
  > of separating content and style.

  > I think we should try to avoid proliferation of citation commands.

  > If that is a reasonable goal, then I think there is really just
  > one distinction that deserves to be represented at the level of
  > citation commands: the distinction between 'in text' and
  > 'parenthetical' citations, that is, the distinction between
  > 'cite:' and '(cite):' in the current syntax in wip-cite.  That
  > brings me to this point:

I agree both that we should avoid having too many citation commands and
that the most important distinction is that of between 'parenthetical'
and '(partly) in main text'. As for the concrete choice of these two
commands, it seems that I misunderstood the intended semantics of the
commands in the current wip-cite syntax because I thought that 'cite'
isn't supposed to produce an 'in main text' citation but a
'bare'/bracketless one, i.e., in the case of author-date styles, 'Smith
2018' instead of '(Smith 2018)'. If, on the contrary, 'cite' was
intended to stand for 'in text' citations then it is indeed a question
which part of the citation should be part of the main text -- e.g., how
should [cite: @Smith2018] be rendered by an author-date style? Since the
typical choice is the author's name, this would probably be a good
default.

  > we should just stick to one command for the in-text case, and have some
  > extensible way to represent the data that should be rendered, e.g. maybe
  > like

  > [cite: @Jones2018 :year]

  > or (as I think was proposed at one point):

  > [cite:author @Jones2018]

  > Again, maybe it's worth having some shortcuts here for the common cases,
  > but I think in general we want to try to avoid proliferation of basic
  > citation commands. So for that reason I think we should just stick with
  > the 'cite'/'(cite)' distinction as the two basic commands, perhaps with
  > a more extensible/compositional syntax in each case for expressing the
  > variations on these two basic types of citation.

Again, I very much agree with the general direction of these proposals,
but doesn't this mean that the citation element should have an attribute
to represent which parts of an 'in text' citation are meant to be in the
main text? (I think currently the only citation-specific attributes in
the wip-cite branch are 'prefix', 'suffix' and 'parenthetical'.)

Finally, to (at least roughly) conform with Wadler's law of language
design :-), just for the record, a few words about the choice of the
concrete commands for 'parenthetical' and 'in main text' citations.
Although Richard is right that the ratio of 'parenthetical' vs '(partly)
in main text' citations

  > depends completely on one's field, writing style, etc. (In my
  > dissertation, for example, in-text citations outnumber parenthetical
  > citations roughly 3:2.)

I still think a case can be made for making the 'parenthetical' one the
default/basic (and, consequently, interpreting the simplest/shortest
citation command as 

Re: [O] Bug: Usability for tags in master branch [9.1.12 (release_9.1.12-646-gb08245 @ c:/D-Drive/bin/org-mode/lisp/)]

[Bernt Hansen]

Bastien  writes:

> Hi Bernt,
>
> glad to read you!
>

Hi Bastien!  I have been away from this list for far too long -- hoping
to correct that.

> Bernt Hansen  writes:
>
>> With the below org file tags handling behaves in a surprising way.
>
> Thanks for the report - just a quick check, do you have these
> issues on the maint branch as well or just on master?

master branch only.  maint works fine.
I have been on maint for a week or two and tried master due to the
pending release plans.

Thanks,
Bernt

Re: [O] Bug: Usability for tags in master branch [9.1.12 (release_9.1.12-646-gb08245 @ c:/D-Drive/bin/org-mode/lisp/)]

[Bastien]

Hi Bernt,

glad to read you!

Bernt Hansen  writes:

> With the below org file tags handling behaves in a surprising way.

Thanks for the report - just a quick check, do you have these
issues on the maint branch as well or just on master?

No problem if you cannot check, just thought you might have.

Thanks!

-- 
 Bastien

Re: [O] org-open-link-from-string truncates file path at spaces

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> The initial report is wrong anyway, because "file:test test.hmtl" is not
> a valid link syntax, i.e., plain links cannot contain spaces. It should
> be:
>
> (org-open-link-from-string "[[file:test test.hmtl]]")
>
> IMO, there is nothing to fix in the first place.

Indeed, sorry for the wrong fix here and thanks for the revert.

-- 
 Bastien

Re: [O] [ANN] OrgStruct is dead. Long live Orgalist.

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> I just sent an email to Emacs devels for inclusion in GNU ELPA.

Great.  Let's advertize it in etc/ORG-NEWS when it's available.

-- 
 Bastien

Re: [O] Time shifting functions

[Matt Price]

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

> Hi Andrei,
>
> Andrei Beliankou  writes:
>
> > I wonder if Org-mode has a convinient function to shift a timestamp with
> > a (weekly) repeating interval by that interval.
>
> Actually the same way `org-read-date' reads the time in the timestamp
> it could also read a repeater interval, so that C-c C-s would present
> you with this repeater interval by default.
>
> Would that make sense for you?
>
>
Huh, that sounds interesting. What I did was define this function:

;; this is the one I'm currently using
(defun get-ts+7 ()
"returns a string of the form <%Y-%m-d %a> where the date elements are 7
days later
than the previous timestamp in the buffer. No error checking or anything
yet."
(interactive)
(let ((base-date (save-excursion
 (re-search-backward
  (org-re-timestamp 'all))
 (match-string 0)))
  (result nil))

  (format-time-string "<%Y-%m-%d %a>"
  (time-add
   (date-to-time base-date) (days-to-time (1+ 7
))

And then I use this macro:

#+MACRO: ts (eval (get-ts+7))

And then my headings look like this:

* Week {{{n}}} (<2017-09-11 Mon>):Intro. On Discussion.
* Week {{{n}}} ({{{ts}}}): What is a River?
* Week {{{n}}} ({{{ts}}}): Rivers in the Broad Sweep of Time

It's not easy to look at in its org-native form, but it's pretty good on
export.

Re: [O] Visit the include file at point (C-c ') stopped working with user-error: No link found

[Nicolas Goaziou]

Hello,

Joon Ro <joon...@outlook.com> writes:

> Hi -
>
> With Org mode version 9.1.12 (9.1.12-elpaplus @
> ~/.emacs.d/elpa/org-plus-contrib-20180427/), whenever I do C-c ' on
> a #+INCLUDE: , I get user-error: No link found error. I thought at
> first the include was broken, but when I export the file it correctly
> works, so the visiting part is the problem it seems.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] org-open-link-from-string truncates file path at spaces

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Hi Joon,
>
> Joon Ro  writes:
>
>> With current org version (Org mode version 9.1.8 (9.1.8-elpaplus @ c:
>> /Users/joon/.emacs.d/elpa/org-plus-contrib-20171228/)), 
>> org-open-link-from-string does not work with a path string if it
>> includes a space. For example,
>>
>> (org-open-link-from-string "file:test test.hmtl")
>>
>> yields
>>
>> user-error: No such file: c:/Users/joon/test
>
> Fixed in maint, thanks.

I reverted this fix because it introduces an error when trying to edit
a file in an INCLUDE keyword.

The initial report is wrong anyway, because "file:test test.hmtl" is not
a valid link syntax, i.e., plain links cannot contain spaces. It should
be:

(org-open-link-from-string "[[file:test test.hmtl]]")

IMO, there is nothing to fix in the first place.

Regards,

-- 
Nicolas Goaziou

[O] Visit the include file at point (C-c ') stopped working with user-error: No link found

[Joon Ro]

Hi -

With Org mode version 9.1.12 (9.1.12-elpaplus @ 
~/.emacs.d/elpa/org-plus-contrib-20180427/), whenever I do C-c ' on a 
#+INCLUDE: , I get user-error: No link found error. I thought at first the 
include was broken, but when I export the file it correctly works, so the 
visiting part is the problem it seems.

Best Regards,
Joon

Re: [O] how to use org-crypt with different key per file or node?

[Nicolas Goaziou]

Bastien  writes:

> Gregor Zattler  writes:
>
 +#+begin_src emacs-lisp
 +  * totally secret :crypt:
>
> PS: I guess this should have been "#+begin_src org" instead.

Actually, we settled on "#+begin_example" instead, because of
fontification issues.

Fixed. Thank you.

Re: [O] [ANN] OrgStruct is dead. Long live Orgalist.

[Nicolas Goaziou]

Hello,

Bastien  writes:

> orgalist.el works great for me, thanks for writing it.

You're welcome.

> Just out of curiosity, did you consider make this a minor more from
> within org-list.el (e.g. `org-list-mode')?

I did. But I think features messing with other modes should go outside
Org core.

> As for orgalist.el: does it live somewhere outside of this list?

No, it only leaves in the mailing list archives.

> If not, I suggest adding it on GNU ELPA or creating a repository
> on code.orgmode.org.

I prefer the former, since it is, AFAIU, easier to install from Emacs.
I just sent an email to Emacs devels for inclusion in GNU ELPA.

Regards,

-- 
Nicolas Goaziou

Re: [O] error while creating agenda clocktable

[Rainer Stengele]

Am 27.04.2018 um 15:47 schrieb Bastien:

Hi Rainer,

Rainer Stengele  writes:


I will copy the new function and modify it to fit my needs.


Thanks for this - please share your experience so that we can better
guide people in updating their code.

The only backward-incompatible change is that :tags is now :match
and :tags can now be nil or t to allow to insert tags.

You might also want to test the new feature.

Thanks,


Hi Bastien,

thanks for the request, I am glad to do do.

What I really want is a very simple clocktable in my agenda view:

Only 2 columns, CATEGORY, the total clocked time and the sum of clocked time 
for each CATEGORY in the agenda view.
Using the standard org-clocktable-write-default I see this:

|---+---+---+--|
|   | GESAMT| *Gesamtdauer*   | 
*2:45* |
|---+---+---+--|
| Projectmanagement.org | *Dateizeit* | * |
* |
|   | project 1 | *project 1: Projektmanagement*  | 
0:15 |
|   | project 2 | *project 2: Projektmanagement*  | 
1:15 |
..

..
my goal is to end up with column 2 and 4:

|---+--|
| CATEGORY  | *2:45* |
|---+--|
| *Dateizeit* |* |
| project 1 | 0:15 |
| project 2 | 1:15 |

as I only use 1 project org file and only 1 headline under which I clock my 
project time.
I would of course be more than happy to have new clocktable options to inhibit the filename column and also the headline lock column, not 
sure how that is named in the code.


In the past I just copied the org-clocktable-write-default and modified it 
brutally in order to just output my 2 needed columns.
That of course makes it sensitive to code changes..

Thank you.
Regards, Rainer

[O] Bug: Usability for tags in master branch [9.1.12 (release_9.1.12-646-gb08245 @ c:/D-Drive/bin/org-mode/lisp/)]

[Bernt Hansen]

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.

Hi!

With the below org file tags handling behaves in a surprising way.


* TODO Test Parent  :PRODUCTION:MISC:
** TODO foo :BAR:
** keys to reproduce


1) At beginning of line 2 on TODO foo
2) M-ret to insert a new heading before foo
3) S-ret to get TODO keyword
   - auto fills :PRODUCTION:MISC: tags ?
4) SPC now does not work to insert a space after the TODO so I can type my 
headline
   I have to use C-f
5) C-c C-q on this line now removes both tags
   I thought this was a bug but it seems to be removing tags that are defined 
   by the parent tasks and maybe that is intentional
6) When I enter a parent tag C-c C-q MISC RET it is displayed and then removed 
if I do another C-c C-q
   This was surprising to me and I thought tag handling was completely broken
   Until I tried a tag not in a parent task
   try C-c C-q TAB MISC RET
   C-c C-q TAB PRODUCTION RET

Thanks for all your amazing work on org-mode!

Best regards,
Bernt

== minimal.emacs 
==
(add-to-list 'load-path "C:/D-Drive/bin/org-mode/lisp/")
(add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))
(require 'org)

(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-ca" 'org-agenda)
(global-set-key "\C-cb" 'org-iswitchb)
== test.el-emacs 
==
(setq org-agenda-tags-todo-honor-ignore-options t)
(setq org-fast-tag-selection-single-key (quote expert))
(setq org-tag-alist (quote ((:startgroup)
("S1" . ?1)
("S2" . ?2)
("S3" . ?3)
(:endgroup)
("WAITING" . ?w)
("HOLD" . ?h)
("PERSONAL" . ?P)
("FS" . ?f)
("DEFECT" . ?d)
("DEV" . ?D)
("QA" . ?Q)
("MISC" . ?M)
("crypt" . ?E)
("CANCELLED" . ?c)
("FLAGGED" . ??
(setq org-tags-match-list-sublevels t)
(setq org-todo-keyword-faces
  (quote (("TODO" :foreground "red" :weight bold)
  ("NEXT" :foreground "blue" :weight bold)
  ("MEETING" :foreground "forest green" :weight bold)
  ("DONE" :foreground "forest green" :weight bold)
  ("WAITING" :foreground "orange" :weight bold)
  ("DELEGATED" :foreground "orange" :weight bold)
  ("HOLD" :foreground "magenta" :weight bold)
  ("PASS" :foreground "forest green" :weight bold)
  ("FAIL" :foreground "red" :weight bold)
  ("CANCELLED" :foreground "forest green" :weight bold
(setq org-todo-keywords
  (quote ((sequence "TODO(t/!)" "NEXT(n/!)" "|" "DONE(d/!)")
  (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" 
"MEETING"

(setq org-todo-state-tags-triggers
  (quote (("CANCELLED" ("CANCELLED" . t))
  ("WAITING" ("WAITING" . t))
  ("HOLD" ("WAITING") ("HOLD" . t))
  (done ("WAITING") ("HOLD"))
  ("TODO" ("WAITING") ("CANCELLED") ("HOLD") ("DELEGATED"))
  ("NEXT" ("WAITING") ("CANCELLED") ("HOLD") ("DELEGATED"))
  ("DONE" ("WAITING") ("CANCELLED") ("HOLD") ("DELEGATED"))
  ("DELEGATED" ("DELEGATED" . t) ("WAITING") ("CANCELLED") ("HOLD"))
  ("PASS" ("WAITING") ("CANCELLED") ("HOLD")

Emacs  : GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17
Package: Org mode version 9.1.12 (release_9.1.12-646-gb08245 @ 
c:/D-Drive/bin/org-mode/lisp/)

current state:
==
(setq
 org-agenda-tags-todo-honor-ignore-options t
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-tab-before-tab-emulation-hook '(org-tempo-complete-tag)
 org-todo-keyword-faces '(("TODO" :foreground "red" :weight bold)
  ("NEXT" :foreground "blue" :weight bold)
  ("MEETING" :foreground "forest green" :weight bold)
  ("DONE" :foreground "forest green" :weight 

Re: [O] how to use org-crypt with different key per file or node?

[Bastien]

Gregor Zattler  writes:

>>> +#+begin_src emacs-lisp
>>> +  * totally secret :crypt:

PS: I guess this should have been "#+begin_src org" instead.

-- 
 Bastien

Re: [O] error while creating agenda clocktable

[Bastien]

Hi Rainer,

Rainer Stengele  writes:

> I will copy the new function and modify it to fit my needs.

Thanks for this - please share your experience so that we can better
guide people in updating their code.

The only backward-incompatible change is that :tags is now :match
and :tags can now be nil or t to allow to insert tags.

You might also want to test the new feature.

Thanks,

-- 
 Bastien

Re: [O] Release 9.1.12

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> Bastien  writes:
>
>> Speaking of which... IIRC one of the reasons for not having
>>
>>   (defconst org-version "9.1.12")
>>
>> in org.el was to having merge conflicts.
^^
sorry for the typo: s/having/avoid

> I don't remember this issue.

In the early days, org.el contained something like
(defconst org-version "6.53") to declare Org version.

Then Achim helped us produce org-version.el by using
Makefile, inferring Org version from Git tags.

This led to users being confused by not understanding
why their Org version was another one than the one they
downloaded or cloned - because they didn't use Make to
create org-version.el.

While trying to understand why it was so bad to have
(defconst org-version "6.53") in org.el, the answers
I receive (IIRC) were that it's bad practise to store
the version number in the file, it leads to merge
conflicts when merging from a version (eg "9.1.11"
in maint) to another say (eg "9.2rc1" in master).

I've never been convinced it was a real issue.

>> Does having "Version: 9.1.12" in org.el means we can switch back
>> to having (defconst org-version "9.1.12") there as well?
>>
>> Could it fix the very annoying "I-don't-know-what-Org-version-is
>> running-within-my-Emacs" issue?
>>
>> I'm aware that M-x org-version RET is more informative today,
>> but I also see just too many people struggling with the current
>> way of setting the version.
>
> I don't understand what you mean by "setting the version". I probably do
> not understand the problem you are describing to its full extent, but
> I think Version: keyword (necessary for ELPA) and `org-version' are
> enough. Yet another way to defined the Org version would be asking for
> trouble.

Sure keyword (necessary for ELPA) and `org-version' are enough.

I'm not asking for yet another way to define the Org version,
I'm wondering whether we can revert back to the primitive way
of doing things: set (defconst org-version "9.2") in org.el,
instead of creating a separate org-version.el thru Make.

Not an issue for now, of course.  Probably Achim can chime in
and, if he has the patience, re-explain me why the primitive way
is wrong, even if Version: 9.2 is written down in org.el.

-- 
 Bastien

Re: [O] how to use org-crypt with different key per file or node?

[Gregor Zattler]

Hi Nicolas, org-mode users,
* Nicolas Goaziou  [2018-04-27; 15:13]:
> Gregor Zattler  writes:
>> +It's possible to use different keys for different headings by
>> +specifying the respective key as property CRYPTKEY, e.g.:
>
> I used =CRYPTKEY= instead of CRYPTKEY, as it is meant to be written in
> an Org document.

sorry

>> +#+begin_src emacs-lisp
>> +  * totally secret :crypt:
>
> There was a missing comma in front of the headline.

Indentation is not enough!?  Is there a document describing how
to contribute to org-manual.org?


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: [O] how to use org-crypt with different key per file or node?

[Nicolas Goaziou]

Hello,

Gregor Zattler  writes:

> Hi org-mode users and developers,
>
> Marco Wahl helped me with this: As always the solution is
> already there in org-mode.  Attached you find a patch in
> order to document this feature.

Thank you.

> +It's possible to use different keys for different headings by
> +specifying the respective key as property CRYPTKEY, e.g.:

I used =CRYPTKEY= instead of CRYPTKEY, as it is meant to be written in
an Org document.

> +#+begin_src emacs-lisp
> +  * totally secret :crypt:

There was a missing comma in front of the headline.

I applied your patch with the changes above.

Regards,

-- 
Nicolas Goaziou

Re: [O] Release 9.1.12

[Nicolas Goaziou]

Bastien  writes:

> Speaking of which... IIRC one of the reasons for not having
>
>   (defconst org-version "9.1.12")
>
> in org.el was to having merge conflicts.

I don't remember this issue.

> Does having "Version: 9.1.12" in org.el means we can switch back
> to having (defconst org-version "9.1.12") there as well?
>
> Could it fix the very annoying "I-don't-know-what-Org-version-is
> running-within-my-Emacs" issue?
>
> I'm aware that M-x org-version RET is more informative today,
> but I also see just too many people struggling with the current
> way of setting the version.

I don't understand what you mean by "setting the version". I probably do
not understand the problem you are describing to its full extent, but
I think Version: keyword (necessary for ELPA) and `org-version' are
enough. Yet another way to defined the Org version would be asking for
trouble.

Re: [O] error while creating agenda clocktable

[Rainer Stengele]

Hi Bastien,

I see that org-clocktable-write-default has been modified quite a bit.
I will copy the new function and modify it to fit my needs.

So please consider this case closed.

Thank you.
Regards, Rainer

Am 27.04.2018 um 14:05 schrieb Rainer Stengele:

Hi Bastien,

I am addressing you because I read that something changed with the agenda 
clocktables.
Maybe related to that E-Mail:

Subject: Re: agenda clockreport -- include tags?
Date: Fri, 27 Apr 2018 01:34:50 +0200

After updating today I cannot get the agenda clocktable anymore.
I use my own formatter function rst/org-clocktable-write-default, which worked 
fine before.

Can you please look into this?

Error message see here:


Debugger entered--Lisp error: (wrong-type-argument listp 15)
   assoc("CATEGORY" 15)
   (cdr (assoc p (nth 4 entry)))
   (or (cdr (assoc p (nth 4 entry))) "")
   (closure ((tcol) (narrow-cut-p) (content) (recalc) (headline . #("*Helbako-RO-BMW: Projektmanagement*" 0 1 (:org-clock-minutes 15 
wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "Helbako-RO-BMW" invisible org-link org-emphasis t font-lock-multiline 
t face (bold org-level-1) fontified t) 1 34 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category 
"Helbako-RO-BMW" org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t) 34 35 (:org-clock-minutes 15 wrap-prefix #("* " 0 
2 (face org-indent)) line-prefix "" org-category "Helbako-RO-BMW" keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . 
org-mouse-move-tree) (C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) 
(mouse-3) (mouse-2 . org-open-at-mouse)) mouse-face highlight invisible org-link org-emphasis t font-lock-multiline t face (bold 
org-level-1) fontified t))) (entry 1 #("*Helbako-RO-BMW: Projektmanagement*" 0 1 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face 
org-indent)) line-prefix "" org-category "Helbako-RO-BMW" invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) 
fontified t) 1 34 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "Helbako-RO-BMW" org-emphasis 
t font-lock-multiline t face (bold org-level-1) fontified t) 34 35 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "Helbako-RO-BMW" keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) 
(C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . 
org-open-at-mouse)) mouse-face highlight invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t)) nil 
nil 15 (("CATEGORY" . "Helbako-RO-BMW"))) (entries (1 #("*Waltron: Projektmanagement*" 0 1 (:org-clock-minutes 75 wrap-prefix #("* " 0 2 
(face org-indent)) line-prefix "" org-category "Waltron" invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) 
fontified t) 1 27 (:org-clock-minutes 75 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "Waltron" org-emphasis t 
font-lock-multiline t face (bold org-level-1) fontified t) 27 28 (:org-clock-minutes 75 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "Waltron" keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) 
(C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . 
org-open-at-mouse)) mouse-face highlight invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t)) nil 
nil 75 (("CATEGORY" . "Waltron"))) (1 #("*00 - Project Managament - general*" 0 1 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face 
org-indent)) line-prefix "" org-category "PM - daily" invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) 
fontified t) 1 34 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "PM - daily" org-emphasis t 
font-lock-multiline t face (bold org-level-1) fontified t) 34 35 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "PM - daily" keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) 
(C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . 
org-open-at-mouse)) mouse-face highlight invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t)) nil 
nil 15 (("CATEGORY" . "PM - daily"))) (1 #("*00 - PM Special*" 0 1 (:org-clock-minutes 60 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "PM - special" invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t) 1 16 
(:org-clock-minutes 60 wrap-prefix #("* " 

Re: [O] how to use org-crypt with different key per file or node?

[Gregor Zattler]

Hi org-mode users and developers,

Marco Wahl helped me with this: As always the solution is
already there in org-mode.  Attached you find a patch in
order to document this feature.

>From be08948c331118e2c66b858dc3133d3e44bfff69 Mon Sep 17 00:00:00 2001
From: Gregor Zattler 
Date: Fri, 27 Apr 2018 14:17:05 +0200
Subject: [PATCH] doc/org-manual.org: Document CRYPTKEY property

TINYCHANGE
---
 doc/org-manual.org | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index e670c387f..76f061709 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -19180,6 +19180,16 @@ Here is a suggestion for Org Crypt settings in Emacs init file:
 ;; # -*- buffer-auto-save-file-name: nil; -*-
 #+end_src
 
+It's possible to use different keys for different headings by
+specifying the respective key as property CRYPTKEY, e.g.:
+
+#+begin_src emacs-lisp
+  * totally secret :crypt:
+:PROPERTIES:
+:CRYPTKEY: 0x0123456789012345678901234567890123456789
+:END:
+#+end_src
+
 Excluding the =crypt= tag from inheritance prevents already encrypted
 text from being encrypted again.
 
-- 
2.11.0



* Gregor Zattler  [2018-04-26; 16:09]:
> I use org-crypt for different org files.  Till now I follow the
> documentation and specify the one and only key to use via
> (setq org-crypt-key "0xdeadbeef") for all org files and their
> headings.
>
> Is it possible to specify different keys for different files or
> even better for different headings?

Ciao; Gregor

-- 
 -... --- .-. . -.. ..--.. ...-.-

[O] error while creating agenda clocktable

[Rainer Stengele]

Hi Bastien,

I am addressing you because I read that something changed with the agenda 
clocktables.
Maybe related to that E-Mail:

Subject: Re: agenda clockreport -- include tags?
Date: Fri, 27 Apr 2018 01:34:50 +0200

After updating today I cannot get the agenda clocktable anymore.
I use my own formatter function rst/org-clocktable-write-default, which worked 
fine before.

Can you please look into this?

Error message see here:


Debugger entered--Lisp error: (wrong-type-argument listp 15)
  assoc("CATEGORY" 15)
  (cdr (assoc p (nth 4 entry)))
  (or (cdr (assoc p (nth 4 entry))) "")
  (closure ((tcol) (narrow-cut-p) (content) (recalc) (headline . #("*Helbako-RO-BMW: Projektmanagement*" 0 1 (:org-clock-minutes 15 
wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "Helbako-RO-BMW" invisible org-link org-emphasis t font-lock-multiline 
t face (bold org-level-1) fontified t) 1 34 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category 
"Helbako-RO-BMW" org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t) 34 35 (:org-clock-minutes 15 wrap-prefix #("* " 0 
2 (face org-indent)) line-prefix "" org-category "Helbako-RO-BMW" keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . 
org-mouse-move-tree) (C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) 
(mouse-3) (mouse-2 . org-open-at-mouse)) mouse-face highlight invisible org-link org-emphasis t font-lock-multiline t face (bold 
org-level-1) fontified t))) (entry 1 #("*Helbako-RO-BMW: Projektmanagement*" 0 1 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face 
org-indent)) line-prefix "" org-category "Helbako-RO-BMW" invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) 
fontified t) 1 34 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "Helbako-RO-BMW" org-emphasis 
t font-lock-multiline t face (bold org-level-1) fontified t) 34 35 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "Helbako-RO-BMW" keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) 
(C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . 
org-open-at-mouse)) mouse-face highlight invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t)) nil 
nil 15 (("CATEGORY" . "Helbako-RO-BMW"))) (entries (1 #("*Waltron: Projektmanagement*" 0 1 (:org-clock-minutes 75 wrap-prefix #("* " 0 2 
(face org-indent)) line-prefix "" org-category "Waltron" invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) 
fontified t) 1 27 (:org-clock-minutes 75 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "Waltron" org-emphasis t 
font-lock-multiline t face (bold org-level-1) fontified t) 27 28 (:org-clock-minutes 75 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "Waltron" keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) 
(C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . 
org-open-at-mouse)) mouse-face highlight invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t)) nil 
nil 75 (("CATEGORY" . "Waltron"))) (1 #("*00 - Project Managament - general*" 0 1 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face 
org-indent)) line-prefix "" org-category "PM - daily" invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) 
fontified t) 1 34 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "PM - daily" org-emphasis t 
font-lock-multiline t face (bold org-level-1) fontified t) 34 35 (:org-clock-minutes 15 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "PM - daily" keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) 
(C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . 
org-open-at-mouse)) mouse-face highlight invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t)) nil 
nil 15 (("CATEGORY" . "PM - daily"))) (1 #("*00 - PM Special*" 0 1 (:org-clock-minutes 60 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "PM - special" invisible org-link org-emphasis t font-lock-multiline t face (bold org-level-1) fontified t) 1 16 
(:org-clock-minutes 60 wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category "PM - special" org-emphasis t 
font-lock-multiline t face (bold org-level-1) fontified t) 16 17 (:org-clock-minutes 60 wrap-prefix #("* " 0 2 (face org-indent)) 
line-prefix "" org-category "PM - special" keymap 

Re: [O] Release 9.1.12

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

>> Org 9.1.12, a bugfix release, is out.
>
> However, you forgot to update "Version:" keyword in org.el prior to
> release, AFAICT.

D'oh! Thanks for spotting and reporting this, fixed now.

Speaking of which... IIRC one of the reasons for not having

  (defconst org-version "9.1.12")

in org.el was to having merge conflicts.

Does having "Version: 9.1.12" in org.el means we can switch back
to having (defconst org-version "9.1.12") there as well?

Could it fix the very annoying "I-don't-know-what-Org-version-is
running-within-my-Emacs" issue?

I'm aware that M-x org-version RET is more informative today,
but I also see just too many people struggling with the current
way of setting the version.

Let me know what you think,

-- 
 Bastien

Re: [O] Release 9.1.12

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Org 9.1.12, a bugfix release, is out.

Thank you.  

However, you forgot to update "Version:" keyword in org.el prior to
release, AFAICT.

Regards,

-- 
Nicolas Goaziou

[O] Release 9.1.12

[Bastien]

Hi,

Org 9.1.12, a bugfix release, is out.

Enjoy!

-- 
 Bastien

Re: [O] Release Org 9.2 soon ?

[Bastien]

Hi Rasmus,

Rasmus  writes:

> I am waiting for 9.1.12.

It's been out since a few hours, I will mention it on the list
explicitely.

-- 
 Bastien

Re: [O] Release Org 9.2 soon ?

[Rasmus]

Bastien  writes:

> Hi Nicolas and all,
>
> Bastien  writes:
>
>> I'm back from a few days off, I'll be able to make the 9.2 release
>> at the end of next week.  I've released 9.1.10 in the meantime.
>
> I'm now reading past emails and checking things for 9.2.
>
> Maybe we will need to release 9.1.12 before 9.2, as there are some
> new bugfixes in maint.

I am waiting for 9.1.12.

Please consider making the release soon, as an upstream merge would have
to be approved first.

Thanks,
Rasmus

-- 
I hear there's rumors on the, uh, Internets. . .

Re: [O] Alternatives to inlinetasks? [was: Problems created by inlinetasks in agenda views]

[Eric S Fraga]

On Friday, 27 Apr 2018 at 09:46, Bastien wrote:

[...]

> Does that make sense to you?

It does.  Thanks.

In any case, getting rid of the * END bit will be nice.  And I've
already moved to using drawers for a large number of my inline task use
cases, the ones that weren't really tasks!

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-474-g92785f


signature.asc
Description: PGP signature

Re: [O] Alternatives to inlinetasks? [was: Problems created by inlinetasks in agenda views]

[Bastien]

Hi Eric,

Eric S Fraga  writes:

> Using *s seems confusing as they are intended for headlines.  From a
> font lock point of view, I would have thought that ! at the start of the
> line would be easier as well.

I should have said that I don't like having a new syntax like this.

My whole point could have been "let's say headlines with more than X
stars are inline tasks, with no contents and thus, no cycling."

If we have inline tasks like "! TODO Rewrite Org's table :Code:" then
of course, they will be easy to fontify, but hard to collect for the
agenda and so on.

As we all know here, the beauty of Org is that it mixes an outliner
with a TODO list manager: inline tasks are at the frontier... they try
to escape the outliner.  I suggest that they don't so that we don't
break Org's intimate design: they can just escape recycling by having
X stars and by not having contents.

Does that make sense to you?

-- 
 Bastien

Re: [O] Changing Modes and Headline Closing

[Eric S Fraga]

On Tuesday, 27 Mar 2018 at 00:00, 42 147 wrote:
> Hello,
>
> I'm editing a large document, mostly text, that is intended for a
> website -- thus html is interspersed throughout, though not enough to
> justify editing the document as a dedicated .html file.

[...]

> Is there a way to switch back to org-mode via M-x org-mode while
> preserving the state of the open / closed headlines?

Can you not put the HTML within #+begin_export HTML ... #+end_export
blocks and then use org-edit-special (C-c ') to edit the HTML?  That
will put the block in HTML mode and leaving the edit buffer (C-c ') will
return you to your org file as it was when you invoked org-edit-special.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-474-g92785f


signature.asc
Description: PGP signature

Re: [O] Alternatives to inlinetasks? [was: Problems created by inlinetasks in agenda views]

[Eric S Fraga]

On Friday, 27 Apr 2018 at 01:34, Bastien wrote:

[...]

> I'd favor a solution where inline tasks are really simple:
>
> 0. Prevent cycling for tasks with a high number of stars
>("high" being defined by the user as an option).
>
> 1. Allow TODO keywords, priority, tags, SCHEDULED and DEADLINE
>but nothing else.
>
> 2. Archiving and refiling DTRT.
>
> 3. ... and we move org-inlinetask.el outside of Org's core.
>
>  is really too much clutter and we can simplify
> things by saying "more than X stars are going to be inline tasks by
> default".

I agree with all of the above, as somebody who uses inline tasks all the
time.  I would prefer the syntax to be very simple and would find, for
instance, a line starting with optional whitespace and "! " as a task
marker, akin to comments.  Nicolas proposed !! but I see no need for
more than one...

Using *s seems confusing as they are intended for headlines.  From a
font lock point of view, I would have thought that ! at the start of the
line would be easier as well.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-474-g92785f


signature.asc
Description: PGP signature