Re: Table formula format string doesn't recognize %

[Daniel Clemente]

Thanks.

On Tue, 21 May 2024 at 09:10, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> > Hi, this stopped working, possibly after a related change
> > to org-table-eval-formula 2 days ago.
> >
> > |  a |  b | percent of a in b |
> > |++---|
> > | 10 | 20 | #ERROR|
> > | 20 | 30 | #ERROR|
> > #+TBLFM: $3=($1/$2)*100;%.2f%%
>
> Oops. Alas, that fix for
> https://orgmode.org/list/87ply5v1gj.fsf@localhost did not work.
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bae1b1fe7
> I reverted the commit.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Table formula format string doesn't recognize %

[Daniel Clemente]

Hi, this stopped working, possibly after a related change
to org-table-eval-formula 2 days ago.

|  a |  b | percent of a in b |
|++---|
| 10 | 20 | #ERROR|
| 20 | 30 | #ERROR|
#+TBLFM: $3=($1/$2)*100;%.2f%%

A simpler format string like ;%.2f also fails.
It seems the regexp doesn't allow the leading %.

This leading % appears in the manual, so this syntax is correct.
 | =$1+$2;%.2f=   | Same, format result to two decimals  |

Link to #ID-id:

[Daniel Clemente]

Hi,
  after updating org-mode and emacs to latest commits, I have seen that
some links to IDs in different files are exported like this:
some link: link

  Shouldn't it be?:   otherfile.html#c5m2je81pue0

  I didn't have time to debug this yet or see if it's from my setup. I may
do it in the next days.

Re: [proof of concept] inline language blocks

[Daniel Clemente]

> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}

Sorry for joining the discussion a bit late. A long time ago I created a
syntax to be able to mix languages in that way, and a program to separate
each version into a different file.

Info: https://www.danielclemente.com/dislines/
Sample: https://www.danielclemente.com/dislines/perl.txt
Syntax: https://www.danielclemente.com/dislines/syntax.en.html
Syntax in practice: https://www.danielclemente.com/dislines/quick.en.txt

It's format-agnostic, and unrelated to org. I have used it in plain HTML
and other file types.
Many times I tried to use it for org-mode, and while it works, the
challenges are more. For instance I'd like to integrate it into the export
process (so that a single command produces many files), I want to use it to
translate headers (but where do you keep the translations of the header
name? in the header itself? in a property?), I want the TOC to use the
translated headers, and I want to keep links working (and making sure each
language only links to files in the same language). More difficult yet:
what if a particular language requires another header structure (more
headers, fewer headers, or headers arranged in another way).
I tried several approaches (inline tasks, SRC blocks, my own syntax, tags
in headers, one sub-header per language, selective export of tags,
properties in headers, post-processing, exporting all and making language
selection in JS, one manual TOC per language, …). But I didn't have time to
think or discover a good system. Multi-language hypertext systems are hard.

Maybe you can get some ideas from this, if you're still working on mixing
human languages in org paragraphs/headers/lines/files. I see the discussion
may have shifted from multilingual texts (i.e. human languages) to
multi-backend texts (e.g. export HTML/LaTeX/… differently); multi-backend
variations might be an easier goal than dealing with multilingual texts and
translations.

Thanks for implementing code for your ideas.

On Tue, 20 Feb 2024 at 20:36, Juan Manuel Macías 
wrote:

> Hi,
>
> I'm dedicating a local branch to developing this proof of concept and
> testing it in my workflow, so far with good results. The basic idea is
> to provide Org with multilingual features and various methods for
> selecting languages.
>
> The inline-language-block is intended for small segments of text in a
> language other than the main language. They can span several lines but
> not more than a paragraph. They can be used for in-line textual quotes,
> glosses, etc. They are constructions equivalent to, for example, LaTeX
> \foreignlanguage{french}{text} or HTML text.
>
> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
>
> You can also use a literal term instead of a language code:
>
> :klingon!{some text in Klingon}
>
> The blocks can be nested:
>
> :klingon!{Some text in Klingon with :it{some text in Italian}}
>
> And they may include other elements:
>
> :el{Some text in Greek with a {{{macro}}} and a [[link]]}
>
> To this end, I have defined the following element:
>
> #+begin_src emacs-lisp
> (defun org-element-inline-language-block-parser ()
>   "Parse inline language block at point.
>
> When at an inline language block, return a new syntax node of
> `inline-language-block' type containing `:begin', `:end',
> `:type', `:contents-begin', `:contents-end' and `:post-blank' as
> properties.  Otherwise, return nil.
>
> Assume point is at the beginning of the block."
>   (save-excursion
> (when (looking-at ":\\([A-Za-z!]+\\){")
>   (goto-char (match-end 0))
>   (let* ((begin (match-beginning 0))
>  (contents-begin (match-end 0))
>  (type (org-element--get-cached-string
> (match-string-no-properties 1)))
>  (contents-end
>   (progn
> (goto-char (- contents-begin 1))
> (org-element--parse-paired-brackets ?\{)
> (- (point) 1)))
>  (post-blank (skip-chars-forward " \t"))
>  (end (point)))
> (when contents-end
>   (org-element-create
>'inline-language-block
>(list :type type
>  :contents-begin contents-begin
>  :contents-end contents-end
>  :begin begin
>  :end end
>  :post-blank post-blank)))
>
> (defun org-element-inline-language-block-interpreter
> (inline-language-block contents)
>   "Interpret INLINE LANGUAGE BLOCK object as Org syntax."
>   (format ":%s{%s}"
>   (org-element-property :type inline-language-block)
>   contents))
> #+end_src
>
> And, for 

Re: [BUG] repeated warnings about org-element-at-point "cannot be used in non-Org buffer" [9.7 (9.7-??-57b94f3 @ /Users/cstevens/.emacs.d/.local/straight/build-29.2/org/)]

[Daniel Clemente]

Thanks, I replaced org-cycle/org-global-cycle with
outline-cycle/outline-cycle-buffer, and then the outlining works.

On Tue, 6 Feb 2024 at 18:56, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> > I also see the warnings. In my case it's because I'm using outline-minor
> > mode in an elisp file. I'm not sure it's supported, but it worked years
> > ago: ...
>
> It is not supported by Org mode.
> The modern outline mode has `outline-cycle'.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: [BUG] repeated warnings about org-element-at-point "cannot be used in non-Org buffer" [9.7 (9.7-??-57b94f3 @ /Users/cstevens/.emacs.d/.local/straight/build-29.2/org/)]

[Daniel Clemente]

I also see the warnings. In my case it's because I'm using outline-minor
mode in an elisp file. I'm not sure it's supported, but it worked years
ago: I could fold and unfold sections with usual org-mode keys like C-tab.
I miss that feature. I never managed to learn the real outline-mode
keys/concepts (outline-show-branches, outline-hide-subtree etc.).

To reproduce it, I used test.el with:


;; -*- mode: emacs-lisp; mode:outline-minor; hs-minor-mode: nil;
outline-regexp:"* [^ \n]" -*-

;; a
;;; a1
;; b


Then I went to ;; a and pressed C-tab, expecting to open/close that
section (showing/hiding the a1). And I saw the warning, and an error:
rx--translate-bounded-repetition: rx ‘**’ range error [3 times]

Please excuse if my expectations or my test file are broken. I didn't use
this feature in years.





On Tue, 30 Jan 2024 at 16:17, Ihor Radchenko  wrote:

> Christopher Stevenson  writes:
>
> > I get these warnings about org-element when I am in non-org files; the
> > main ones that come to mind are JavaScript files and in magit when I am
> > doing a commit. They don't seem to break anything but it does get
> > annoying to have to constantly dismiss them.
>
> These warnings indicate that some of your packages or customization
> causes `org-element-at-point' to be executed in non-Org buffer.
> `org-element-at-point' does not have a defined behaviour in non-Org
> buffers and may cause random errors.
>
> If you can narrow down the caller of `org-element-at-point', I suggest
> you to report the observed behaviour as a bug (if that is a third-party
> package).
>
> Otherwise, you may suppress the Org warning.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

Re: [POLL] Any users setting `org-agenda-use-tag-inheritance' to nil or other non-default value?

[Daniel Clemente]

> 1. If you customized it to speed up agendas, are agendas still slow on
the latest main?

I disabled org-agenda-use-tag-inheritance but I can't provide a lot of
feedback because I don't use many tag filters:

1. I disabled it in a batch script that exports my agenda, though it
doesn't actually speed up the agenda (even with org-element-use-cache
disabled); I guess it's because the agenda view I'm exporting doesn't do
any filter (in particular, filter by tag).

2. I disabled it in my .emacs, but I guess it has no effect because I also
disabled org-use-tag-inheritance, because I've never needed tag inheritance.

I temporarily enabled org-use-tag-inheritance
and org-agenda-use-tag-inheritance and opened an agenda that filters by tag
(it combines 4 one-tag filters), it seems to run almost as fast; 25 to 26
seconds with tag inheritance enabled, whereas with tag inheritance disabled
it takes around 24 seconds. These are manual measurements which may be 1 or
2 seconds off, so you may want to measure it more precisely; they may take
the same time. Anyway I don't see slowness due to tag inheritance in agenda.


On Thu, 4 Jan 2024 at 17:28, Ihor Radchenko  wrote:

> Hello,
>
> We have a customization `org-agenda-use-tag-inheritance' that controls
> whether agenda searches should use tag inheritance or not.
>
> One of the main motivations to introduce it was that agenda searches
> could become really slow when resolving inherited tags. However,
> inherited tags can now be retrieved very fast, after org-element-cache
> has been enabled by default. At least, it is the theory.
>
> I'd like to hear from the users who customized
> `org-agenda-use-tag-inheritance':
>
> 1. If you customized it to speed up agendas, are agendas still slow on
>the latest main?
>
> 2. If you customized it for other reasons, may you please explain your
>use case?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

Re: [BUG] wrong-type-argument syntax-table-p "Syntax table including \"@\" and \"_\" as word constituents.

[Daniel Clemente]

It works now. Thanks!

On Mon, 29 May 2023 at 08:34, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> >   there was a recent change to how the tags table is initialized. I think
> > that as a side effect, some tag functions like org-tags-expand don't work
> > unless you open an org-mode buffer first. I have a small bash script that
> > exports my agenda; right in the beginning (before opening any org-mode
> > file) it collects some data by calling org-map-entries. org-map-entries
> > needs org-tags-expand, which now fails because the syntax table hasn't
> been
> > initialized yet.
> >
> > Minimal case to reproduce this:
>
> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=24ed8b204
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

[BUG] wrong-type-argument syntax-table-p "Syntax table including \"@\" and \"_\" as word constituents.

[Daniel Clemente]

Hi,

  there was a recent change to how the tags table is initialized. I think
that as a side effect, some tag functions like org-tags-expand don't work
unless you open an org-mode buffer first. I have a small bash script that
exports my agenda; right in the beginning (before opening any org-mode
file) it collects some data by calling org-map-entries. org-map-entries
needs org-tags-expand, which now fails because the syntax table hasn't been
initialized yet.

Minimal case to reproduce this:

1. run: emacs -Q

2. load latest org:
(add-to-list 'load-path "/…/org-mode/lisp")
(require 'org)

3. eval:
   (org-tags-expand "+sometag")

You'll see:

Debugger entered--Lisp error: (wrong-type-argument syntax-table-p "Syntax
table including \"@\" and \"_\" as word constit...")
  org-tags-expand("+sometag")
  (progn (org-tags-expand "+sometag"))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)


If I open any .org file before step 3, then it will work.

I think the related commit is:
commit 6e6354c074a323780f103aabf45be74104ce3ecf
Author: Ihor Radchenko 
Date:   Mon May 8 13:23:15 2023 +0200

org-tags-expand: Do no modify buffer's syntax table by side effect

* lisp/org.el (org-mode-tags-syntax-table): New variable holding
syntax table for tags.
(org-mode): Initialize tag syntax table.
(org-make-tags-matcher): Match tags using appropriate syntax table.
(org-tags-expand): Do no modify syntax table by side effect.

Reported-by: Mattias Engdegård 
Link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63225#68


Of course I could make sure to open an org file (any file) before calling
org-map-entries but that seems like a workaround to a bug. I would expect
(org-map-entries … 'agenda) to also work before opening any .org file.

Re: Radio links work only in small numbers

[Daniel Clemente]

Hi,
I also found this limitation, and my solution was to disable radio links
and to replace them by a manual approach:

1. I disabled the call to (org-update-radio-target-regexp) in org.el. Well,
I added a boolean org-inhibit-startup-radio-refresh, that works in a
similar way to org-inhibit-startup-visibility-stuff. After this change, I
still type <<>> to define a title, but org doesn't handle it anymore

2. I created a helm  menu, that offers
me all the radio links. I compute the list of radio links myself, through
grep, by looking for <<<. It's easier than it seems, and very fast. The
code (no explanations) is my configuration
, in these functions:
anythingyhelm-fuente-etiquetas-radio-org,
precarga-etiquetas-radio-de-wiki-para-helm

3. Often, when I want to refer to a title, I write in in cursive, /like
this/. That's my way of telling myself „that's a link, you can manually
search for it through helm“. The target will be tagged <<>>. I
could automate this link-following but I don't mind typing for 1 or 2
seconds to go a header. I still use normal links (C-c C-l, :ID: etc.) if I
want something that is easier to follow.

My system doesn't provide the same features as org's radio links, but I get
an interactive menu with pattern matching and very fast access to all
headers. I would still prefer the real radio links, with no limitations.
However, I understand that org-mode's approach is computationally harder.
Whereas I'm looking for ONE target link through all my 100 files, org-mode
is doing a regexp that looks for ALL target links in the current file. And
I have around 20k radio links!. Grepping for 20k things everywhere is
harder than grepping for 1 thing everywhere. Even GNU grep is slow (>25
seconds) if I use a long regular expression
 with
20k things inside.

In other words: since radio links don't scale well, I have replaced the
real radio links (search for everything everywhere) with a directed
approach (search for 1 thing everywhere).


On Tue, 13 Dec 2022 at 23:11, Rudolf Adamkovič  wrote:

> Greetings smart people!
>
> All [[link]]s in my notes perfectly match LEVEL-1 headings, so I figured
> that I may as well ask Org to make links for me.  So, I replaced all the
> ~4000 headings in my notes with radio <<>>.  However, Org now
> errors out with "Regular expression too big".
>
> Does anyone know how to overcome this limitation?  Or, perhaps someone
> has a patch in works that fixes it?  If so, please let me know!
>
> Thank you.
>
> Rudy
> --
> "The introduction of suitable abstractions is our only mental aid to
> organize and master complexity."
> -- Edsger Wybe Dijkstra, 1930-2002
>
> Rudolf Adamkovič  [he/him]
> Studenohorská 25
> 84103 Bratislava
> Slovakia
>
>

Re: [BUG] Shift-up/down move the cursor to end of timestamp

[Daniel Clemente]

It works now, thanks!

On Wed, 7 Dec 2022 at 10:53, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> > Using a file with just one header:
> >
> > * something
> >   :CLOCK:
> >   CLOCK: [2022-12-01 Thu 17:15]--[2022-12-01 Thu 17:30] =>  0:15
> >   :END:
> >
> > If I put the cursor on the end timestamp (on the 3 of 17:30) and press
> > shift+up or shift-down, the timestamp is correctly adjusted by 5 minutes,
> > but the cursor jumps some characters to the right and stays at the right
> of
> > ]
> > It should stay on the same character (the 3), so that I can keep
> adjusting
> > the minutes with shift-up/down
>
> Thanks for reporting!
> Fixed on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4dddbc143
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

[BUG] Shift-up/down move the cursor to end of timestamp

[Daniel Clemente]

Hi.

Using a file with just one header:

* something
  :CLOCK:
  CLOCK: [2022-12-01 Thu 17:15]--[2022-12-01 Thu 17:30] =>  0:15
  :END:

If I put the cursor on the end timestamp (on the 3 of 17:30) and press
shift+up or shift-down, the timestamp is correctly adjusted by 5 minutes,
but the cursor jumps some characters to the right and stays at the right of
]
It should stay on the same character (the 3), so that I can keep adjusting
the minutes with shift-up/down

Tested on: GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit,
cairo version 1.16.0, Xaw scroll bars) of 2022-11-18
No other settings needed in your .emacs

I bisected the tree until I found in which commit this started. Copying
from git bisect:

5bc6741a5abd42e8305bb0fcfe78801813309640 is the first bad commit
commit 5bc6741a5abd42e8305bb0fcfe78801813309640
Author: Ihor Radchenko 
Date:   Tue Nov 1 15:52:25 2022 +0800

org-clock-update-time-maybe: Update the containing timestamps as well

* lisp/org-clock.el (org-clock-update-time-maybe): Update the
containing timestamps inside the clock, not only the clock sum.

Reported-by: Bruce E. Robertson 
Link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53393

 lisp/org-clock.el | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

Re: sort “on-the-fly” in org-agenda-view

[Daniel Clemente]

Sorry for the late reply.
You can press M-up / M-down to manually sort agenda items once the agenda
view is open.
It's just a convenient way to do minor adjustments. No files are actually
changed.

On Mon, Apr 19, 2021 at 12:55 PM Ben Sima  wrote:

> Heh, I just found myself wanting to do this. I often use C-c ^ to sort
> subtrees by creation date, and I wanted to do that with my global TODO
> list just now, but couldn't figure out how.
>
> So, imo there is at least a small need for this feature.
>

Re: Cannot export org mode to collapsible HTML

[Daniel Clemente]

> Is this happening because org-info.js is no longer being maintained?
Another solution I saw was Daniel Clemente's tool, though I am at a total
loss for what to specify in the org file to incorporate his esquemadorg.js
script. I appreciate any help that could let me export large org files to
HTML while having the headers be collapsible.

Sorry for the very late answer. I just added some instructions
 about what to add to
the .org file.
But it looks like the best way is to adapt any existing tool to your needs.
Collapsing/expanding headers isn't very hard — the harder parts are things
like how to make links keep working (e.g. links to sections which are now
collapsed should auto-open it).


On Wed, Nov 6, 2019 at 12:04 AM Kris Brown  wrote:

> Hi, I am trying to have basic folding functionality for my org file that
> has been exported to HTML. I am using Emacs 26.2 (9.0) and Org 9.1.9 on a
> Mac.
>
> This seems to be a built-in feature: JavaScript supported display of web
> pages
> .
> I downloaded my own copy of org-info.js
> . However, I cannot see any
> difference when I use the #+INFOJS_OPT commands or not (org with
> , org without
> , html with
> , html without
> ). I would expect
> to see collapsible headers and no TOC displayed when I use those commands.
>
> There *is* a difference in the generated HTML files (an extra CDATA
> region with a bunch of statements like: *org_html_manager.set("VIEW",
> "info");*) but nothing different visually.
>
> Is this happening because org-info.js is no longer being maintained
> ?
> Another solution I saw was Daniel Clemente's tool
> ,
> though I am at a total loss for what to specify in the org file to
> incorporate his esquemadorg.js script. I appreciate any help that could let
> me export large org files to HTML while having the headers be collapsible.
>

Re: [O] [ANN] org-conflict add-on: timing conflicts detector and resolver for Org agenda

[Daniel Clemente]

Hi,
  I'm surprised that noone answered yet.
  This package is great! You're addressing one of the large shortcomings of
org-mode's planning features: org has information about several planning
details (estimation, duration, holidays, start date, deadline, …) and still
doesn't use any of that to offer help to the user in very simple cases.
  Like for instance, I would expect org-mode to say „you shouldn't have >20
tasks scheduled for the same day, because at a default duration of 1 h,
you'll find that there aren't enough working hours to do them“. Or if you
have a 10-hour task and a 12-hour task in the same day, it should trigger
some warning. Or scheduling a work task during a holiday. Or conflicts. Or
work which is scheduled after a deadline. Or 10 tasks scheduled one after
the other without taking into account that humans need to take breaks from
time to time. Or schedules based on out-of-date information like overrun
deadlines or overrun budgets. I want the freedom to be able to do all those
mistakes but I'd also appreciate some help from org-mode or any other tool…
  Scheduling algorithms are very hard. Repetitions, time zones, summer time
changes, …

  As for org-conflict itself:

I like how it has not only the part about detecting conflicts, but also an
interface to see conflicting items, propose a solution and try to find the
right time; that's many steps ahead. I would be fine with just being able
to *detect* conflicts, but I see how detecting+resolving can be useful to
many people.
I like how you included the part about having breathing time or „coffee
breaks“ between tasks. This is all very user-friendly.

I'm not sure about the entry point; that is, how to invoke the conflict
resolution step. From the documentation and from using it, it seems that
you must actively say „right now I'd like to write a date to see whether it
would conflict with anything“; this is a use case I never have thought of
or needed previously. My needs have rather been:
1) „right now I'd like to schedule a task“ (hopefully at a date which
doesn't create conflicts). That means, I'd prefer if the conflict
resolution happened as part of the normal C-c C-s scheduling process,
instead of an optional step that you must remember to invoke with C-c C-c.
Reschedulings (including rescheduling after a repetition) should be subject
to the same checks. Even if this means having to wait more. I think you
could provide some code or instructions about how to make automatic checks
after C-c C-s (maybe only if the specified date includes a duration)
2) from time to time I wish I could check not only 1 timestamp, but
*all* my existing appointments (mainly the future ones) for conflicts. This
means comparing each one against each other! (including repetitions) or
producing a timeline and checking for overlaps. This is very hard, I know!
And the interactive part (seeing proposed resolutions) is heavy because
there are infinite possible resolutions. This turns very fast into an
optimization problem

An issue that makes org-conflict less helpful than it could is that it only
works for agenda appointments that have a duration. You implemented a
default duration for the *new* event (the one just inputted) and then
compare this event against all existing agenda events *that have a duration*.
But I think that *all* agenda events should have a default duration too
(because in real life, no task takes 0 minutes). So the new event should be
compared against all future timestamps, not only those with a duration.
This is slower, I know.
Actually, a better way to implement this would be: let's forget about
durations and just take the day, not the hour. If you want to schedule an
event at day X, and there's already another event at day X (no duration
specified), let's call this a conflict and prevent scheduling a second one.
If you don't want to consider it a conflict (because you really plan to do
both things the same day) then you should be required to choose a time for
the existing event, and then another time (non-conflicting) for the new
event. This experiment may help in teaching the user to do better planning,
i.e. if you want to do many things the same day, choose at which times.


I tried to implement some programs to do similar things, and to get some
useful information from my org agenda (which is a mess because of too many
tasks). Like for instance, I take a list of tasks, „enhance them“ with
scheduling information like a default duration and a deadline, and then I
add the human requirements that org doesn't know about: for instance
complaining if there are more than 24 h of work in a day (actually I delay
them to the next day), or adding pauses for lunch or for sleep (this will
also shift everything forwards). This is all more complex than expected and
in the end I'm doing the processing outside org; actually I prefer to use a
very simple list (1. x, 2. yy, 3. , …) in an org file to do my
planning, and ignore org-mode 

Re: [O] Ridiculously long (2 minutes) startup time for org agenda

[Daniel Clemente]

It can be many things. My emacs was taking 6 minutes to open for some
years, due to many reasons: a slow computer, many org files and very large
(>100 files, >25 Mb in total), lack of optimizations from my side and from
org-mode's side. I got used to it but it's a very bad experience, specially
when it crashes (and I made it crash a lot).
Now org-mode has improved and I disabled the slow parts, and it opens very
fast (<20 seconds). I still open large files.

The problem may not only be in org but in emacs (e.g. vc-mode can be slow),
though from the instrumentation you send, it doesn't seem to be the case
because it doesn't spend time opening the files.

org-agenda-prepare-buffers is the slow function, so it's the one you should
check. Try to use edebug in it (C-u M-C-x) and run it slowly to see in
which section it's the slowest. Then optimize that part. You'll see many
optimization there (ignore properties, etc.). I had to disable many slow
things, like <<>> (when you use a lot, e.g. 1000 per file, it's too
slow and even crashes), I think that these radio targets were the main
reason of the slowness.

Try creating a very large file and then check opening it, to see if it's
also slow.
Try things in a clean emacs (e.g. starting with: emacs -Q), because you may
have some other mode enabled that wants to do lots of things when you open
the files.

You can test many more things. But keep testing, because it's possible to
make it work faster.


On Mon, Feb 19, 2018 at 3:00 AM, JI Xiang  wrote:

> Hello, first time posting on the mailing list. I encountered a problem
> where my agenda view (C-c a a) is taking ridiculously long (nearly 2
> minutes) to be shown the first time. From the second time onwards, the time
> is about 11 seconds, which is still very long by any means.
>
> I wondered whether it has something to do with me having many files in the
> agenda list, so I tried to restrict the list to just one file. But still
> the first call to org-agenda-list took 12 seconds. This shouldn’t be
> normal, right?
>
> The following are shown in the Messages buffer during the call.
>
> Press key for agenda command:
> Restoring clock data
> Loading /home/jx/.emacs.d/.cache/org-clock-save.el (source)...done
> [yas] Prepared just-in-time loading of snippets successfully.
> Importmagic and/or epc not found. importmagic.el will not be working.
> Setting up indent for shell type zsh
> Indentation variables are now local.
> Indentation setup for shell type zsh
> Using vacuous schema
> Shell native completion is disabled, using fallback
>
> I’m not sure why they would be there, especially the “using vacuous
> schema” and “shell native completion” part. Are the messages related to
> some #BEGIN_SRC blocks in the org files? I don’t think I would ever need
> source code blocks when I’m viewing an agenda buffer?
>
> I posted the question on Emacs.SE
> 
> and somebody suggested me use elp-instrument to perform a profiling. The
> results are as follows:
>
>
> Function Name, Call Count, Elapsed Time, Average Time
>
> org-agenda 1   116.6048159   116.6048159
> org-agenda-list 1   116.29427357  116.29427357
> org-agenda-prepare 1   109.15345470  109.15345470
> org-agenda-prepare-buffers 1   108.98258905  108.98258905
> org-agenda-get-day-entries 12887.0089191339  0.0054417074
> org-agenda-get-scheduled 12883.726361062   0.0028931374
> org-agenda-get-deadlines 12882.1579713230  0.0016754435
> org-agenda--timestamp-to-absolute 14544   1.1317418120   7.781...e-05
> org-agenda-get-timestamps 12880.3673404320  0.0002852021
> org-agenda-get-sexps 12880.3438970410  0.0002670008
> org-agenda-get-restriction-and-command 1   0.310503975
> 0.310503975
> org-agenda-get-blocks 12880.3083237900  0.0002393818
> org-agenda-prepare-window 1   0.157091024   0.157091024
> org-agenda-skip 86240.0781296389  9.059...e-06
> org-agenda-files 49  0.026090686   0.0005324629
> org-agenda-finalize 1   0.013325178   0.013325178
> org-agenda-mode 1   0.009848546   0.009848546
> org-agenda-finalize-entries 23  0.006178961   0.0002686504
> org-agenda-today-p 26040.0061717839  2.370...e-06
> org-agenda-skip-eval 16968   0.0052723920  3.107...e-07
> org-agenda-highlight-todo 112 0.0039840550  3.557...e-05
> org-agenda-format-item 112 0.0038309749  3.420...e-05
> org-agenda-new-marker 208 0.0031529359  1.515...e-05
> org-agenda-format-date-aligned 28  0.0007373120  2.633...e-05
> org-agenda-add-time-grid-maybe 28  0.0003810809  1.361...e-05
> org-agenda-fix-displayed-tags 112 0.000342384   3.057e-06
> org-agenda-fontify-priorities 

Re: [O] Scatter-gather idea

[Daniel Clemente]

On Mon, Apr 3, 2017 at 6:34 AM, Bob Newell  wrote:

>
> Or even simpler: you want to group together a bunch of scattered
> headlines that you now see as being related. Yes, you can do this by
> moving each one around individually, but I'd like a faster method---
> just mark them and relocate them all at once to the top or bottom of the
> buffer.
>

 If you need it fast and simple, and you're in an agenda view, you can use
M-up, M-down to reorder the headlines you see, and this doesn't modify
anything else, just the visual order in this agenda. Then when all the
tasks you want are at the top, you can copy/paste them, or mark them and
move them, etc.

Re: [O] How are people handling their calendars?

[Daniel Clemente]

I only tried the visualization part a few days ago, by exporting to
iCalendar (.ics). But the process was too slow: after fixing some export
errors it was still taking more than 1 hour for a large .org file.

After that I wanted to use Iceowl/Lightning (extension to
Icedove/Thunderbird) to open the .ics. But there might be better .ics
browsers (that run in local).

On Mon, Oct 24, 2016 at 1:36 AM, Tristan Strange 
wrote:

> The world of calendars is a murky one isn't it? After a couple of weeks of
> fiddling around I finally decided I'd keep my TODO's, deadlines, etc in a
> TODO.org and have org-gcal fetch (note not synchronise) my calendar from
> Google.
>
> That way I do all my daily TODO mangling in orgmode, edit calendar when on
> Desktop or Mobile and pull results in to org agenda for easier viewing.
>
> So how do you lot handle your calendars?
>
> Do any of you have a working two way set up with CalDAV or anything?
>
> Cheers,
> Tristan
>

[O] bug if link description contains percent sign (%)

[Daniel Clemente]

With yesterday's org-mode: if I export (C-c C-o O O) this line of text, it 
fails because of the % character:

See [[file:/][the m%n syntax]].



Debugger entered--Lisp error: (error "Not enough arguments for format string")
  format(#("[[%s][the m%n syntax]]" 6 20 (:parent (link (:type "file" :path "/" 
:format bracket :raw-link "file:/" :application nil :search-option nil :begin 5 
:end 31 :contents-begin 15 :contents-end 29 :post-blank 0 :parent (paragraph 
(:begin 1 :end 33 :contents-begin 1 :contents-end 33 :post-blank 0 
:post-affiliated 1 :parent (section (:begin 1 :end 33 :contents-begin 1 
:contents-end 33 :post-blank 0 :post-affiliated 1 :parent ...) #4)) #("See " 0 
4 (:parent #4)) #2 #(".\n" 0 2 (:parent #4 #("the m%n syntax" 0 14 (:parent 
#2) "file:/")
  org-element-link-interpreter((link (:type "file" :path "/" :format bracket 
:raw-link "file:/" :application nil :search-option nil :begin 5 :end 31 
:contents-begin 15 :contents-end 29 :post-blank 0 :parent (paragraph (:begin 1 
:end 33 :contents-begin 1 :contents-end 33 :post-blank 0 :post-affiliated 1 
:parent (section (:begin 1 :end 33 :contents-begin 1 :contents-end 33 
:post-blank 0 :post-affiliated 1 :parent (org-data nil #4)) #2)) #("See " 0 4 
(:parent #2)) #0 #(".\n" 0 2 (:parent #2 #("the m%n syntax" 0 14 (:parent 
#0))) #("the m%n syntax" 0 14 (:parent (link (:type "file" :path "/" :format 
bracket :raw-link "file:/" :application nil :search-option nil :begin 5 :end 31 
:contents-begin 15 :contents-end 29 :post-blank 0 :parent (paragraph (:begin 1 
:end 33 :contents-begin 1 :contents-end 33 :post-blank 0 :post-affiliated 1 
:parent (section (:begin 1 :end 33 :contents-begin 1 :contents-end 33 
:post-blank 0 :post-affiliated 1 :parent ...) #4)) #("See " 0 4 (:parent #4)) 
#2 #(".\
 n" 0 2 (:parent #4 #("the m%n syntax" 0 14 (:parent #2))
  org-org-link(…)
  org-export-data(…)



Greetings,

Daniel

[O] bug in org-element--object-lex seen when exporting (Invalid search bound, wrong side of point)

[Daniel Clemente]

Hi. I describe a rare bug seen in today's org-mode (8.3.6) running in emacs 
26.0.50.1.

1. emacs -Q, and load org-mode
2. Use this file (two lines):

* <<>>
a-bug

3. export to HTML  (C-c C-e h h)

I got:

Debugger entered--Lisp error: (error "Invalid search bound (wrong side of 
point)")
  re-search-forward("\\(?:[_^][-{(*+.,[:alnum:]]\\)\\|[*~=+_/][^
\n]\\|\\<\\(?:b\\(?:bdb\\|ibtex\\)\\|doi\\|elisp\\|f\\(?:ile\\(?:\\+\\(?:\\(?:emac\\|sy\\)s\\)\\)?\\|tp\\)\\|h\\(?:elp\\|ttps?\\)\\|i\\(?:d\\|nfo\\|rc\\)\\|m\\(?:ailto\\|essage\\)\\|news\\|shell\\|tel\\|w\\(?:3m\\|l\\)\\):\\|\\[\\(?:fn:\\|\\[\\|[0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\}\\|[0-9]*\\(?:%\\|/[0-9]*\\)\\]\\)\\|@@\\|{{{\\|<\\(?:%%\\|<\\|[0-9]\\|\\(?:b\\(?:bdb\\|ibtex\\)\\|doi\\|elisp\\|f\\(?:ile\\(?:\\+\\(?:\\(?:emac\\|sy\\)s\\)\\)?\\|tp\\)\\|h\\(?:elp\\|ttps?\\)\\|i\\(?:d\\|nfo\\|rc\\)\\|m\\(?:ailto\\|essage\\)\\|news\\|shell\\|tel\\|w\\(?:3m\\|l\\)\\)\\)\\|\\$\\|\\(?:[a-zA-Z[(]\\|[
   ]*$\\|_ +\\)\\|\\(?:call\\|src\\)_" 13 t)
  org-element--object-lex((bold code entity export-snippet footnote-reference 
inline-babel-call inline-src-block italic line-break latex-fragment link macro 
radio-target statistics-cookie strike-through subscript superscript target 
timestamp underline verbatim))
  org-element--parse-objects(13 19 (paragraph (:begin 13 :end 19 
:contents-begin 13 :contents-end 19 :post-blank 0 :post-affiliated 13)) (bold 
code entity export-snippet footnote-reference inline-babel-call 
inline-src-block italic line-break latex-fragment link macro radio-target 
statistics-cookie strike-through subscript superscript target timestamp 
underline verbatim))
  org-element--parse-elements(13 19 planning nil nil nil (section (:begin 13 
:end 19 :contents-begin 13 :contents-end 19 :post-blank 0 :post-affiliated 13)))
  org-element--parse-elements(13 19 section nil nil nil (headline (:raw-value 
"<<>>" :begin 2 :end 19 :pre-blank 1 :contents-begin 13 :contents-end 19 
:level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 2 
:title ((radio-target (:begin 4 :end 11 :contents-begin 7 :contents-end 8 
:post-blank 0 :value "a" :parent #0) #("a" 0 1 (:parent #3)))
  org-element--parse-elements(2 19 first-section nil nil nil (org-data nil))
  org-element-parse-buffer(nil nil)
  …



It happens with one-letter radios. I found it because I had <<>> and r-cran 
in the same file.

Greetings,

Daniel

Re: [O] Bug: HTML export ignoring CUSTOM_ID properties

[Daniel Clemente]

El Tue, 21 Apr 2015 09:25:13 +0200 Nicolas Goaziou va escriure:
 
 Hello,
 
 Daniel Clemente n142...@gmail.com writes:
 
  I also saw this change (diff format):
 
  -div id=outline-container-sec-1-4-3-1-2 class=outline-6
  -h6 id=sec-1-4-3-1-2span class=section-number-61.4.3.1.2/span 
  tercer error con stash/h6
  +div id=outline-container-orgheadline129 class=outline-6
  +h6 id=orgheadline129span class=section-number-61.4.3.1.2/span 
  tercer error con stash/h6
 
  The #sec-1-4-3-1-2 format was better. If I delete section 1.4.3.1.2,
  section 1.5 is still called 1.5, that's good.
 
 And if you delete section 1.4, section 1.5 is no longer called 1.5. So
 you need to update IDs most times you change headline numbering. I don't
 think it is really better than the current state.
 

It's good to minimize the number of changes after each export. I prefer to 
review 10 changes rather than 200. I cannot just forget and let the automatic 
export work its way; I need to review it because in every export I find many 
different export bugs or unexpected features.

While the two systems work, I don't see either why the #orgheadline129 system 
is better than the #sec-1-4-3-1-2. Not important enough to justify a breaking 
change either.


  And what's the use of IDs if they're not permanent?
 
 The point is that Org knows the ID associated to a given headline, and
 provides tools to access them (`org-export-get-reference' for back-end
 developers, [[*tercer error con stash]] for users).
 

IDs are not only internal. CSS knows about it, JS too, and URLs can be built 
and shared through the web that include org IDs (myweb.com/somedoc.html#someid).

Re: [O] Bug: HTML export ignoring CUSTOM_ID properties

[Daniel Clemente]

El Sat, 18 Apr 2015 15:57:15 +0200 Rasmus va escriure:
 
  Note that this also breaks any CSS styling for the section with the
  CUSTOM_ID (which I also use).  If I used a CUSTOM_ID because wanted a
  swanky background for the heading saying Bill Clinton, the current
  export not only doesn't use that ID, it doesn't encompass the heading
  with his name in.
 

I was also bit by that CUSTOM_ID change. I'm not using CSS to style an element, 
like #clinton in your example, but in some places I want to define an ID 
#clinton so that I can build a URL like myweb.com/presidents/#clinton (instead 
of, say, /presidents/#orgheadline515).


I also saw this change (diff format):

-div id=outline-container-sec-1-4-3-1-2 class=outline-6
-h6 id=sec-1-4-3-1-2span class=section-number-61.4.3.1.2/span tercer 
error con stash/h6
+div id=outline-container-orgheadline129 class=outline-6
+h6 id=orgheadline129span class=section-number-61.4.3.1.2/span tercer 
error con stash/h6

The #sec-1-4-3-1-2 format was better. If I delete section 1.4.3.1.2, section 
1.5 is still called 1.5, that's good. With a flat numbering like 
#orgheadline129, deleting any headline would change the IDs of all headers 
after it. And what's the use of IDs if they're not permanent?

Re: [O] Fwd: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

 
   Another option would be to have another option to indent only planning
   info, properties drawer, and every drawer located right after it, à la
   `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
   structure.
 
Is this possible?
 
 Why wouldn't it?
 

  I thought this could also kill kittens.

  Would you be so kind to allow this as an option for org-adapt-indentation? 
This is the most similar to the default behaviour that org-mode had until 2014, 
it looks nice, it's flexible and it doesn't break structure.
  Or could you provide some steps to implement this? (E.g. functions that need 
to be taken care of).


  About the 2nd proposal:
 
I'd rather have org-adapt-indentation = 'initial-only which works
like like org-adapt-indentation = nil with the extra that „Property
drawers and planning information is inserted indented“.
 
That is, new things appear with the same indentation as the element above.
And demoting doesn't indent anything.
 
Example:
 
 
  ** something
 
 
You press C-c C-s and you get:
 
 
  ** something
 SCHEDULED: 2051-01-09 Mon
 
 
You press S-M-right and you get:
 
 
  *** something
 SCHEDULED: 2051-01-09 Mon
 
 
The user can then manually decide whether he wants to correct
indentations for each line.
 
 I fail to see how this would be useful. In particular, it fails if the
 section has contents prior to the scheduling step. Also, it doesn't
 solve Sébastien's problem.
 

  Both Sébastien and I agree that this…:
  
  Some text
  [2014-12-14 Sun 18:55]

…looks nicer than this:

  Some text
 [2014-12-14 Sun 18:55]

  With the algorithm above, you'll get the nice version with the downside that 
org-mode won't handle indentation for you from now on. If 
org-adapt-indentation=nil is useful, this is useful and a bit nicer.
  If the section has contents prior to the scheduling line, you can still 
follow the rule that new things inherit the indentation of the previous element.


  The first option seems better anyway, but the second one seems easier to 
implement. 


Greetings

Re: [O] Fwd: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

Two proposed solutions:

1.

  Another option would be to have another option to indent only planning
  info, properties drawer, and every drawer located right after it, à la
  `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
  structure.

  Is this possible?

  This indents drawers located at the top, which I think is good enough because 
it's where org puts the common ones by default.
  Your examples are more complex, with drawers in the middle of the text or in 
the middle of lists. In those cases you might need full indentation, but people 
who only use :CLOCK: and SCHEDULED at the top (and that's the default) could 
use this option.

  This is not about „indenting by type“, but about „indenting until point X“, 
and the trick is to find the right X.


2.


  I'd rather have org-adapt-indentation = 'initial-only which works like like 
org-adapt-indentation = nil with the extra that „Property drawers and planning 
information is inserted indented“.

  That is, new things appear with the same indentation as the element above.
  And demoting doesn't indent anything.

  Example:


** something


  You press C-c C-s and you get:


** something
   SCHEDULED: 2051-01-09 Mon


  You press S-M-right and you get:


*** something
   SCHEDULED: 2051-01-09 Mon


  The user can then manually decide whether he wants to correct indentations 
for each line.



  Or maybe both options are interesting?


--
Daniel

El Mon, 22 Dec 2014 12:34:28 +0100 Nicolas Goaziou va escriure:
 
 Daniel Clemente n142...@gmail.com writes:
 
  El Sat, 13 Dec 2014 15:10:32 +0100 Nicolas Goaziou va escriure:
 
  You are free to make any distinction you want. Unfortunately, Org does
  a different one. In particular, as you noticed, there are some areas
  where things are not as clear. For example, Org cannot be sure that
  a given drawer wasn't inserted manually, so altering its indentation may
  or may not be a good choice.
 
Does it matter in practice? If the user manually inserts things that are
  normally handled by org, they can be also handled by org. Lckily you don't
  need to remember whether it was manually inputted or not.
 
 It matters here. You want to control indentation of what is handled by
 Org.
 
  So, what's wrong with `org-adapt-indentation' set to nil?
 
This. By default (tested on emacs -Q), when you have this tree:
 
   Some text
  Hi
 
...and you clock in, you get:
 
   Some text
  CLOCK: [2014-12-14 Sun 18:55]--[2014-12-14 Sun 18:57] =  0:02
  Hi
 
  Same with properties:
   e
  :PROPERTIES:
  :ou:   22
  :END:
  Text
 
That is 1) uglier than the default.
 
 This is subjective.
 
  2) violating the rule you said: new lines should be indented at the
  same level as the element above.
 
 It doesn't. Headline has level 0 indentation (per
 `org-adapt-indentation'), so are properties drawer and paragraph.
 
I want no change at all? No, my proposal is to move planning info in the
  top and not move the things below it.
 
 As explained already in this thread, the problem is not about planning
 info, but about regular drawers.
 
I'll try again. An underscore means a space:
 
Before demoting:
 
  ** some
  ___:CLOCK:
  ___CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
  ___:END:
  Text
 
 What I expect after demoting:
 
  *** some
  :CLOCK:
  CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
  :END:
  Text
 
 See: this is not about planning info.
 
 Again, it is not desirable to decide to move an element by its type
 because it could alter structure of the document. In the following
 example, demoting headline would move the clock drawer within the list,
 which was not intended initially.
 
   * Headline
 - something
 :CLOCK:
 ...
 :END:
 
 Elements can only be moved by their location. Hence, planning info and
 properties drawer can be freely indented, not because of their type, but
 because their location prevent them from altering the structure of the
 section.
 
Some lines moved and others not makes sense for a partial indentation.
  You can call it 'only-top so that it's clear which lines are updated.
 
 I don't mind the name, but I need to find a proper definition for it.
 
I think the default behaviour should be not to change indentation,
  because org-mode can be used in combination with other modes. E.g. I'm
  using org-mode in beancount files (a ledger program), and lines need to
  start in column 0.
 
 I think the default is fine. Your use-case doesn't look like a default
 one.
 
  Another option would be to have another option to indent only planning
  info, properties drawer, and every drawer located right after it, à la
  `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
  structure.
 
Interesting. Yes, you could indent until (org-log-beginning).
That would exclude notes, which are more akin to text than to drawers.
  Users who want to force indent

[O] Fwd: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

(I'm resending this old e-mail because it seems it didn't get to the list,
according to Gmane).

El Sat, 13 Dec 2014 15:10:32 +0100 Nicolas Goaziou va escriure:

  Users who type can do a simpler distinction:
1. things you type yourself
2. things that appear/change/disappear after invoking org functions
(C-something, S-something, M-something). E.g.: the words SCHEDULED,
TODO, CLOCK, PROPERTIES, EFFORT, checkboxes [ ], timestamps, ...
 
I speak for myself, but I expect class 1 not to be changed by org,
  and class 2 to be handled only by org (I can always edit manually, but
  I shouldn't need to do it). I know that you can actually type
  everything in class 2, but you shouldn't NEED to.
Any other opinions are welcome.

 You are free to make any distinction you want. Unfortunately, Org does
 a different one. In particular, as you noticed, there are some areas
 where things are not as clear. For example, Org cannot be sure that
 a given drawer wasn't inserted manually, so altering its indentation may
 or may not be a good choice.

  Does it matter in practice? If the user manually inserts things that are
normally handled by org, they can be also handled by org. Lckily you don't
need to remember whether it was manually inputted or not.


Indentation is for me as important as the other letters I type. I
don't want it changed.
It's a personal preference. Emacs respects it to great extents.

 I understand. Simply set `org-adapt-indentation' to nil.

Maybe I should clarify that I see the text inside my org files as
  a tree of knowledge. The position inside the tree of a particular item
  does not affect how I write the text (e.g. how many indentation
  spaces). I can move nodes freely from one place to another and I have
  no indentations to fix. Tree structure and item content are
  disconnected.
If you really need other sources, you can see how tree operations in
  other contexts don't modify the contents of each node:
 
http://pythonhosted.org/ete2/tutorial/tutorial_trees.html#concatenating-trees
I wouldn't want titles, clocks, IDs, indentations, properties,
priorities etc. changed when the tree structure changes.
Maybe other people think the same; you can survey the list.

 So, what's wrong with `org-adapt-indentation' set to nil?

  This. By default (tested on emacs -Q), when you have this tree:

 Some text
Hi

  ...and you clock in, you get:

 Some text
CLOCK: [2014-12-14 Sun 18:55]--[2014-12-14 Sun 18:57] =  0:02
Hi

Same with properties:
 e
:PROPERTIES:
:ou:   22
:END:
Text

  That is 1) uglier than the default. 2) violating the rule you said: new
lines should be indented at the same level as the element above.



That's similar to a not-so-bad old behaviour. But it's still a bit
better (it avoids the problem described in
http://permalink.gmane.org/gmane.emacs.orgmode/92450)

 The problem described there is different: the OP wants some changes when
 tree structure is modified (e.g., planning info moved). You claim to
 want no change at all, which is easier, and already implemented.


  I want no change at all? No, my proposal is to move planning info in the
top and not move the things below it. Therefore I called it partial
indentation, as opposed to t (always indent) or nil (never indent).
  Sorry for the examples I sent in my first e-mail (
http://lists.gnu.org/archive/html/emacs-orgmode/2014-12/msg00091.html), it
seems that some e-mail program has reformatted the spaces (or maybe I sent
TABs instead of spaces) and the indentation doesn't make sense. I should
have switched spaces to something else.

  I'll try again. An underscore means a space:

  Before demoting:

** some
___:CLOCK:
___CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
___:END:
Text

   What I expect after demoting:

*** some
:CLOCK:
CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
:END:
Text



  Ok, make it:
 
  2. With org-adapt-indentation = 'partial, new lines added by org
  (:CLOCK: drawer, CLOCK lines etc) are indented at the same level as
  the element above.

 This is better, but there is still the hack about text at column 0.

 Also, this only makes sense if these lines are also moved when headline
 is promoted or demoted. But, then, contents will change along with tree,
 which you don't like, and it could break section structure (some lines
 being moved and not others), which cannot happen currently.

  Some lines moved and others not makes sense for a partial indentation.
You can call it 'only-top so that it's clear which lines are updated.

  I think the default behaviour should be not to change indentation,
because org-mode can be used in combination with other modes. E.g. I'm
using org-mode in beancount files (a ledger program), and lines need to
start in column 0.

 Another option would be to have another option to indent only planning
 info, properties drawer, and every drawer located right after it, à la
 

Re: [O] demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

El Fri, 12 Dec 2014 19:25:25 +0100 Nicolas Goaziou va escriure:
 
Of course everything's text, but if there's no distinction between
  drawers/headers and text, that's the problem. Those headers are metadata
  written and managed by org and must follow some rules,
 
 This is incorrect.
 
 :CLOCK: or :LOGBOOK: or whatever the value of `org-clock-into-drawer'
 is, are regular drawers conveniently provided to collect clocks and
 allow to hide them away. They have no special meaning in Org, and may
 not even exist (i.e., when `org-clock-into-drawer' is nil). There is no
 reason to treat them specially.
 
 OTOH, clocks themselves are pure metadata. They could be indented
 specifically, but since they are allowed anywhere in a section, it might
 be dangerous to do so (e.g. it could break a list). Actually, this is
 true for anything that need to appear at the very beginning of the
 section, i.e., anything but planning info and properties drawers.

  […]
 This is also wrong. PROPERTIES drawer, which is metadata, has to be
 moved before anything else in the section (with the exception of
 planning info). This has nothing to do with CLOCK drawers, which are not
 even considered in the process.
 
So, I think org should detect its own syntax (:CLOCK: ... :END: etc.), and
  do automatic changes only to its own syntax, not to text typed by the user
  unless the user asks for it.
 
 Again, :CLOCK:...:END: is user's decision, not Org's. So are all
 drawers, but, of course, PROPERTIES. The latter is the exception, not
 the rule.

  But these are technical details, not relevant to a non-programmer. What a new 
user sees with the default settings as of today is:
- he writes a new tree and some text inside
- he clocks in
- he demotes the tree (shift+right) because he wants to change the tree 
structure. Result: his text also is modified
  This breaks user's expectations. At least it breaks my expectations, because 
in a logical tree of nodes, demoting does not mean „shift contents“. And I 
thought org was supposed not to break my content.
  I also lose controllability because I have no way to rearrange nodes without 
side effects.
  
  I suggest:

1. New default for org-adapt-indentation = 'partial, which shifts every line 
until the first line which starts at column 0. This may not shift all drawers 
in complex cases where you have them in the bottom of the tree; therefore it's 
called partial. This is handling the most common cases. And in case you had 
indentation in all lines, all lines will be shifted.

2. With org-adapt-indentation = 'partial, new lines added by org (:CLOCK: 
drawer, CLOCK lines etc) appear at the same column as the heading, not at 
column 0

3. The other options stay the same: org-adapt-indentation=t means everything 
will be shifted, org-adapt-indentation=nil means nothing will be shifted (new 
text starts at column 0)



-- Daniel

Re: [O] demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

El Sat, 13 Dec 2014 12:33:16 +0100 Nicolas Goaziou va escriure:
But these are technical details, not relevant to a non-programmer.
 
 Which basically means nothing, because everything ultimately boils down
 to technical details.
 

  That's always true. But UIs still need to be simple.
  No need to teach the user the differences of a :CLOCK: vs a :PROPERTIES: or 
drawer vs. metadata. Users who type can do a simpler distinction:
  1. things you type yourself
  2. things that appear/change/disappear after invoking org functions 
(C-something, S-something, M-something). E.g.: the words SCHEDULED, TODO, 
CLOCK, PROPERTIES, EFFORT, checkboxes [ ], timestamps, …

  I speak for myself, but I expect class 1 not to be changed by org, and class 
2 to be handled only by org (I can always edit manually, but I shouldn't need 
to do it). I know that you can actually type everything in class 2, but you 
shouldn't NEED to.  
  Any other opinions are welcome.


  - he writes a new tree and some text inside
  - he clocks in
  - he demotes the tree (shift+right) because he wants to change the tree 
  structure. Result: his text also is modified
 
 FUD. Neither the text nor its structure are modified. Only indentation
 is. How it is done is explained in `org-adapt-indentation' docstring.
 

  Indentation is for me as important as the other letters I type. I don't want 
it changed.
  It's a personal preference. Emacs respects it to great extents.


  because in a logical tree of nodes, demoting does not mean „shift
  contents“.
 
 Huh? Citation needed.

  Maybe I should clarify that I see the text inside my org files as a tree of 
knowledge. The position inside the tree of a particular item does not affect 
how I write the text (e.g. how many indentation spaces). I can move nodes 
freely from one place to another and I have no indentations to fix. „Tree 
structure“ and „item content“ are disconnected.
  If you really need other sources, you can see how tree operations in other 
contexts don't modify the contents of each node: 
http://pythonhosted.org/ete2/tutorial/tutorial_trees.html#concatenating-trees
  I wouldn't want titles, clocks, IDs, indentations, properties, priorities 
etc. changed when the tree structure changes.
  Maybe other people think the same; you can survey the list.
  

I also lose controllability because I have no way to rearrange nodes
without side effects.
 
 We might fix them. What are exactly these side-effects?
 
  The only one: indentation is added:


After demoting, it changes from this:

 some
:CLOCK:
CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
:END:
Text



  to this:
  
* some
 :CLOCK:
 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
 :END:
 Text


This will happen in all subtrees.


I suggest:
 
  1. New default for org-adapt-indentation = 'partial, which shifts
  every line until the first line which starts at column 0. This may not
  shift all drawers in complex cases where you have them in the bottom
  of the tree; therefore it's called partial.
 
 I'm not really against it, but this is really hackish and probably
 surprising.

  That's similar to a not-so-bad old behaviour. But it's still a bit better (it 
avoids the problem described in 
http://permalink.gmane.org/gmane.emacs.orgmode/92450)


 AFAICT, you erroneously think regular drawers are an Org internal
 artifact whereas they are really meant for users. They should be
 indented like their contents, no like planning info.

  I do the typed-by-me/not-typed-by-me distinction.
 
 
  2. With org-adapt-indentation = 'partial, new lines added by org
  (:CLOCK: drawer, CLOCK lines etc) appear at the same column as the
  heading, not at column 0
 
 This would be plain wrong. Indentation is relative to the element above.
 Heading indentation is but the fallback value.
 

Ok, make it:

2. With org-adapt-indentation = 'partial, new lines added by org
(:CLOCK: drawer, CLOCK lines etc) are indented at the same level as the element 
above.



--
Daniel

Re: [O] demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

 Proposal: if text starts in column 0, don't move the text; move
 only the headers.

 Then, in this case, :CLOCK: drawer will not move either. Unless
 headers is defined as stuff not too far from the headline. But it is
 too vague to be usable.

 There no such thing as a your headers in Org. :CLOCK: and Text are
 treated equally, as contents of the headline.

  Of course everything's text, but if there's no distinction between
drawers/headers and text, that's the problem. Those headers are metadata
written and managed by org and must follow some rules, whereas the rest of
text is data typed by the user and relatively free. Those headers must even
follow strict processes (like being repaired to make CLOCK appear after
PROPERTIES), so I wouldn't say they are normal text.
  Maybe you are referring to the non-drawers metadata, i.e. to those notes
that you can add with C-c C-z. That's in the limbo between org data and
text, that's the tricky part. I don't know whether that should be indented
together with the drawers, probably yes.
  So, I think org should detect its own syntax (:CLOCK: ... :END: etc.), and
do automatic changes only to its own syntax, not to text typed by the user
unless the user asks for it.

--
Daniel

On Sat, Dec 6, 2014 at 6:40 AM, Nicolas Goaziou m...@nicolasgoaziou.fr
wrote:

 Hello,

 Daniel Clemente n142...@gmail.com writes:

There was a change (cba2f0a2a3024ae5bf71e1a12ba99778a92902a2, Sat
Nov 8 14:35:24 2014 +0100) which made :CLOCK: etc entries shift to
the right when the tree is being shifted to the right (demoted,
e.g. using M-S-Right).
 
 
  But now it changes from this:
 
   some
:CLOCK:
CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
:END:
  Text
 
 
 
to this:
 
  * some
 :CLOCK:
 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
 :END:
   Text
 
 
 
 while what I expected was this:
 
  * some
 :CLOCK:
 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
 :END:
  Text
 
 
 
 
 Proposal: if text starts in column 0, don't move the text; move
 only the headers.

 Then, in this case, :CLOCK: drawer will not move either. Unless
 headers is defined as stuff not too far from the headline. But it is
 too vague to be usable.

 An old behaviour (reported in
 http://permalink.gmane.org/gmane.emacs.orgmode/92450) was not to move
 anything in this case, that's bad and was fixed. I think the proposal is
 better.
 org-adapt-indentation=nil would write all headers in column 0 by
 default, which is ugly and doesn't give the desired result.

 There no such thing as a your headers in Org. :CLOCK: and Text are
 treated equally, as contents of the headline.


 Regards,

 --
 Nicolas Goaziou

[O] demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

  There was a change (cba2f0a2a3024ae5bf71e1a12ba99778a92902a2, Sat Nov 8 
14:35:24 2014 +0100) which made :CLOCK: etc entries shift to the right when the 
tree is being shifted to the right („demoted“, e.g. using M-S-Right).


But now it changes from this:

 some
:CLOCK:
CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
:END:
Text



  to this:
  
* some
 :CLOCK:
 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
 :END:
 Text



   while what I expected was this:
   
* some
 :CLOCK:
 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =  0:55
 :END:
Text




   Proposal: if text starts in column 0, don't move the text; move only the 
headers.
   An old behaviour (reported in 
http://permalink.gmane.org/gmane.emacs.orgmode/92450) was not to move anything 
in this case, that's bad and was fixed. I think the proposal is better.
   org-adapt-indentation=nil would write all headers in column 0 by default, 
which is ugly and doesn't give the desired result.

   If some people prefer „move header+text even if text is in column 0“ 
(current behaviour) over „move header but not text if text is in column 0“ 
(proposal), org-adapt-indentation could select choose between the two.
   

   Thanks,
Daniel

Re: [O] Org and ledger

[Daniel Clemente]

El Mon, 10 Nov 2014 08:08:51 +0100 Bernhard Pröll va escriure:
 
 I have been curious too and found this file:
 
 https://bitbucket.org/blais/beancount/src/tip/examples/tutorial/example.beancount

Exactly. The first line defines org mode:
;; -*- mode: org; mode: beancount; -*-

Re: [O] Org and ledger

[Daniel Clemente]

 Well, ledger and hledger are different tools that use the same (very
 similar) data files.  The invocation of each is different.  org supports
 ledger out of the box but not hledger.
 
  I prefer beancount (very similar to ledger but stricter): beancount supports 
org out of the box! My beancount file is an org file (with structure, tasks, 
priorities, agenda, etc. except :CLOCK:) and it parses correctly as a ledger.
  So I don't use beancount support in org, but the reverse.
  It also includes Emacs mode, fontification, autocomplete, …
  http://furius.ca/beancount/
  

Re: [O] Announcement: org-one-to-many

[Daniel Clemente]

Hi,
breaking a big .org file in many small pieces is one of my major concerns
with .org and one which gives me lots of problems. Thank you very much for
having the clear objective of one-to-many.

If your goal is HTML export, you can do a function that iterates over all
headers and exports them (see below). But then links are broken, you need
to decide filenames, etc. Which is what your project solves.

org-one-to-many has a shortcoming which is present in so many org to blog
systems: it expects a particular structure (in this case, all headers at
the same level). I suggest you iterate over search results of a normal
search:

For instance, you can get all headers tagged with tobesplit like this:
(org-map-entries (lambda () (line-number-at-pos))  +tobesplit 'agenda)

One of the possible searches is headers at level 2, so this new system
would include the one you have.

Greetings

On Tue, Oct 21, 2014 at 10:02 PM, Marcin Borkowski mb...@wmi.amu.edu.pl
wrote:

 Hi all,

 a long time ago I asked here about a way to split an Org file into a
 bunch of smaller ones.  One of the answers I got was that the tricky
 part is maintaining internal links in a reasonable way.

 It is probably overoptimistic on my side, but it seems that this problem
 is solved now.  The code is not very elegant, and I will be actively
 working on it (I want to write an org-to-e-learning exporter, based on
 the HTML one, and this is a small part of that effort), but here it is
 for testing/review/bug reports/feature requests/any other kind of
 feedback.

 And here it is: https://github.com/mbork/org-one-to-many

 Best,

 --
 Marcin Borkowski
 http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
 Adam Mickiewicz University

Re: [O] Announcement: org-one-to-many

[Daniel Clemente]

El Thu, 23 Oct 2014 19:58:48 +0200 Marcin Borkowski va escriure:
  For instance, you can get all headers tagged with tobesplit like this:
  (org-map-entries (lambda () (line-number-at-pos))  +tobesplit 'agenda)
 
  One of the possible searches is headers at level 2, so this new system
  would include the one you have.
 
 I thought about it.  I'd like to first make my code a bit cleaner and
 fix one bug I know of.  I think this will be fairly easy; I could split
 headers with some property (a tag might not be a good idea, since tags
 are inherited).
 

Tag inheritance is customizable (org-use-tag-inheritance). I don't use it.

Anyway, if I have:
* :publish:
** b
** ccc:publish:
** 
* 

Well, it makes sense to export 2 .org: aaa.org (including ,,ddd) and 
ccc.org (including only ccc)

[O] C-c C-y in currently clocked header

[Daniel Clemente]

Feature request.

 currently clocking
 :CLOCK:
 CLOCK: [2014-10-15 Wed 16:06]
 CLOCK: [2014-10-13 Mon 11:23]--[2014-10-13 Mon 11:54] =  0:31
 :END:

Now it's 16:26. If I put the cursor in 16:06 and press C-c C-y 
(org-evaluate-time-range), it would be useful to see in the minibuffer that the 
difference until now is 20 minutes.

Re: [O] C-c C-y in currently clocked header

[Daniel Clemente]

 
   currently clocking
   :CLOCK:
   CLOCK: [2014-10-15 Wed 16:06]
   CLOCK: [2014-10-13 Mon 11:23]--[2014-10-13 Mon 11:54] =  0:31
   :END:
 
  Now it's 16:26. If I put the cursor in 16:06 and press C-c C-y 
  (org-evaluate-time-range), it would be useful to see in the minibuffer that 
  the difference until now is 20 minutes.
 
 Saluton!
 
 Are you aware that you can set org-clock-mode-line-total to 'current?
 (Personally, I only discovered it before a few hours, and set it to
 'today.)

Yes, but you may want to see the current clocking duration independently of the 
settings of the current header. E.g. even if org-clock-mode-line-total==all, I 
want to see that my unclosed clocking amounts for 20 minutes.

Re: [O] org-mode for knowledge management

[Daniel Clemente]

Thanks, that's a very simple way to search backlinks! I didn't know about 
org-search-view.


El Sun, 12 Oct 2014 22:17:27 -0700 Samuel Wales va escriure:
 
 (defun alpha-org-what-links-here ()
   Show all links that point to the current node.  Also show the
 node itself.
 
 This makes id links quasi-bidirectional.
   (interactive)
   (let ((org-agenda-files (alpha-org-all-org-files
:archive t
:text-search-extra t))
 ;; turn off redundancy
 ;;   fixme probably going to be redone
 org-agenda-text-search-extra-files)
 (org-search-view nil (org-entry-get nil ID t
 
 
 On 10/12/14, Daniel Clemente n142...@gmail.com wrote:
  El Mon, 13 Oct 2014 10:42:28 +0800 Eric Abrahamsen va escriure:
  
   This is the bit I'm not sure about...
  
   * project_a
   ** experiment about blah :proj_name:theme:
   [2014-10-11]
  
   Did x, y, and z today. Will analyze results tomorrow.
  
   [2014-10-12]
  
   Wow. Interesting finding. This will help a lot and may be relevant to
   future projects!
  
  …
 
  Perhaps both links and tags are what you're after then: you could leave
  a link to the general finding inside experiment about blah (to remind
  yourself you took that note), but also use the tags to open Agendas on
  both project and theme, so you can see all the relevant information in
  one place.
 
 
 
   * project_a
   ** experiment about blah :proj_name:theme:
 
I think it's crazy to use topics as tags. How many topics/themes are
  there? Wikipedia counts many million. Names of topic are very subjective.
  Topics are often mixed, split apart, refined, renamed, grouped in
  supertopics, …
In org it's easy to remodel hierarchical headers but it's not easy to
  remodel tags (much less, hierarchical tags).
 
So rather than:
 
  ** some construction  :plastics_engineering:
 
 
I would have:
 
  Engineering.org:
  * Plastics
  * Houses
  * …
 
 
I understand you use tags and „tag search“ to be able to look for bits of
  a particular topic in a file which is not related to the topic.
It would be better to have a tag that in addition links to a particular
  tree. With that you'd have the freedom of tagging anything and the
  flexibility of headers.
 
Some brainstorming about how to link tags with headers: Two options:
 
  1) There is a main tag in a header, and the other tags link to it (with C-c
  C-o you navigate to the main tag).
 
  proj1.org:
  ** some construction  :plastics_engineering:
 
  Engineering.org:  :plastics_engineering:
  * Plastics
  * Houses
  * …
 
 
  2) You use links and you ask for backlinks
 
  proj1.org:
  ** some construction [link to P]
 
  Engineering.org:
  * Plastics
:ID: 1231212311122
  * Houses
  * …
 
  And then… a key to *search for links to a header* („backlinks“). Can org do
  this now?.
  E.g. you go to „Plastics“ and you search „all the backlinks found in
  proj1.org“. Then you have the generic knowledge and in addition all the bits
  of specific knowledge about that topic.
 
 
  Maybe this is already possible… Whether it's useful, I don't know.
 
 
 
 
 -- 
 The Kafka Pandemic: http://thekafkapandemic.blogspot.com
 
 The disease DOES progress.  MANY people have died from it.  And
 ANYBODY can get it.
 
 Denmark: free Karina Hansen NOW.

Re: [O] org-mode for knowledge management

[Daniel Clemente]

 […]
 uniformity, extruder/die temperature, cooling time, holding pressure,
 etc. I think this is awesome general knowledge. But I'm documenting
 our learning in an experimental report for export and upload to my
 company's internal technical report repo.

  I find it very different to write notes for yourself and to write for an 
audience. In a report you need to follow a structure, you need to choose a 
particular natural language, you need to explain things that might be obvious 
for you, you cannot change topic, … Whereas in notes, you're free. Therefore I 
think it makes sense to have two different places for both.


 What I'm often torn about is re-writing the
 learning/understanding/summary in a more general way since how it
 usually arises is laden with specific details for *this*
 product/project, whereas the information I want to retain is about how
 I see the new understanding more generally.

  … However, I don't consider that rewriting (specific→general) you mention as 
a necessary task or a burden (I don't do it), because in your notes (generic 
knowledge) you can simply refer to the specific one (e.g.: „see what I did in 
this case ([[link_to_the_report]])“.). A header with 1 or 2 or N links to 
specific reports is a good start before continue focusing on other 
generic-knowledge topics.
  So you decide where you will work the most (either in the specific reports or 
in the generic knowledge) and then the other can refer to it.
  I do it like that. E.g. I'm not writing in my generic notes a „code style 
guide“ because I did it already in project X, so I add knowledge in 
projectX.org and just link to it. If some particular knowledge grows too big 
for that projectX_code_style, I develop it in my generic notes (another file, 
project-unrelated).


Of course copy+paste is a nightmare to maintain (see: DRY). I am still 
  forced to do it with some org tables which do complex calculations. I think 
  org offers dynamic tables to apply the same process to different data 
  sources, but it gets complex. I think there's no such thing as „templates“ 
  where you change the base one and all uses of it (in all files) are 
  automatically updated.
 
About links: in org-mode they all look the same, but semantically there 
  are many types, like:
  - *is-a*: „this is a concrete implementation of [[that generic knowledge]]“
  - *related*: „related to this is: [[that]]“
  - *same-as*: „this and [[that]] are exactly the same topic, so write only 
  under that header, not here“ ← this is poor man's transclusion, or more 
  like „symbolic links“ in ext4. With it, a header seems to be present in 
  many places at the same time; in reality the content is only in one place 
  and the rest are links. The good thing is, it doesn't really matter /where/ 
  exactly is that tree, because you'll find it anyway by following maximum 1 
  link. X can link to Y, or Y can link the X; what's important is that 
  reading both X or Y you'll find exactly the same thing (not copy+pasted 
  contents).
 
So, it's all about finding a manual algorithm to organize things
 
 This is generally what I've tried to do, though I find this is
 cumbersome as I often use subtrees for more report-style/narrative
 analyses of data and experiments. Thus I don't find it as simple as
 your example to Brady with the PDF/HTML info, which is more basic. As
 I write this, I'm thinking I could probably still do this...
 
 For an example, let's say I'm making plastic widgets and we've been
 running a series of injection mold trials with a manufacturer. Some
 really novel understanding comes about with respect to part
 uniformity, extruder/die temperature, cooling time, holding pressure,
 etc. I think this is awesome general knowledge. But I'm documenting
 our learning in an experimental report for export and upload to my
 company's internal technical report repo.
 
 My initial thought was that links this way would get in the way... but
 I suppose now I could be writing along and create a link to the
 nearest headline in the report, then go to some other tree and insert
 a link to that headline with some note about the gist of the
 understanding or keywords for the future me trying to re-find that
 tidbit.
 

  Note that:
- I don't suggest you abuse links and link every header. You can link to 
interesting topics. Like in Wikipedia: you /could/ link every word, but it 
makes sense to link only interesting information (only: in WP they link too 
much because they don't know what exactly will be interesting to the reader; 
but in your notes, you know already which links will you need in the future).
- In my example, the link meant „this is the same as that“, and I think this is 
always a basic concept, even in complex scenarios. In your case, your link may 
mean something different (like: „this heading is a specific wording of that 
knowledge“)
- That header with empty contents that says „for this, don't look here but look 
there: [[there]]“ 

Re: [O] org-mode for knowledge management

[Daniel Clemente]

El Mon, 13 Oct 2014 10:42:28 +0800 Eric Abrahamsen va escriure:
 
  This is the bit I'm not sure about...
 
  * project_a
  ** experiment about blah :proj_name:theme:
  [2014-10-11]
 
  Did x, y, and z today. Will analyze results tomorrow.
 
  [2014-10-12]
 
  Wow. Interesting finding. This will help a lot and may be relevant to
  future projects!
 
 …
 
 Perhaps both links and tags are what you're after then: you could leave
 a link to the general finding inside experiment about blah (to remind
 yourself you took that note), but also use the tags to open Agendas on
 both project and theme, so you can see all the relevant information in
 one place.
 


  * project_a
  ** experiment about blah :proj_name:theme:

  I think it's crazy to use topics as tags. How many topics/themes are there? 
Wikipedia counts many million. Names of topic are very subjective. Topics are 
often mixed, split apart, refined, renamed, grouped in supertopics, …
  In org it's easy to remodel hierarchical headers but it's not easy to remodel 
tags (much less, hierarchical tags).

  So rather than:

** some construction  :plastics_engineering:


  I would have:

Engineering.org:
* Plastics
* Houses
* …


  I understand you use tags and „tag search“ to be able to look for bits of a 
particular topic in a file which is not related to the topic.
  It would be better to have a tag that in addition links to a particular tree. 
With that you'd have the freedom of tagging anything and the flexibility of 
headers.

  Some brainstorming about how to link tags with headers: Two options:

1) There is a main tag in a header, and the other tags link to it (with C-c C-o 
you navigate to the main tag).

proj1.org:
** some construction  :plastics_engineering:

Engineering.org:  :plastics_engineering:
* Plastics
* Houses
* …


2) You use links and you ask for backlinks

proj1.org:
** some construction [link to P]

Engineering.org:
* Plastics
  :ID: 1231212311122
* Houses
* …

And then… a key to *search for links to a header* („backlinks“). Can org do 
this now?.
E.g. you go to „Plastics“ and you search „all the backlinks found in 
proj1.org“. Then you have the generic knowledge and in addition all the bits of 
specific knowledge about that topic.


Maybe this is already possible… Whether it's useful, I don't know.

Re: [O] org-mode for knowledge management

[Daniel Clemente]

El Fri, 10 Oct 2014 16:48:39 -0500 John Hendy va escriure:
 
 On Fri, Oct 10, 2014 at 10:46 AM, Daniel Clemente n142...@gmail.com wrote:
  
   I've been using org-mode for a variety of purposes for a few years. I 
   find
   that it suffers from the same problem that other such tools do. The
   problem is me. I can't remember week to week how I may have classified
   some scrap of information. Did I drop it into notes/someproduct.org or 
   was
   it procedures/someprocess.org?
 
  1. Every information should have a single location, not two. Mix sections 
  fast
  if you detect repetitions. Use links extensively (C-c l) to connect one 
  header
  with another, specially after you get lost once. Don't bother too much about
  finding the right place at the first time, you'll eventually reorder or move
  headers to the correct place.
 
 I'm curious about this. Is this a well-known recommendation/best
 practice? 

  I find it it similar to the „Don't repeat yourself“ principle. But I was just 
explaining my experience.

 I actually struggle with this a great deal. Often a bit of
 research or testing for a specific project at work is very possibly
 relevant to any number of future projects. So, working in product
 development, I find it hard to decide what the best single location
 is, and would love for it to act as though it were in multiple
 locations.
 
 When the current project is done, I'd like to archive everything
 specifically related to it while keeping around the general knowledge
 I've accumulated for use with future efforts.

  I use no tags or categories, just a clear and manual separation of concepts. 
E.g. it's not the same activity „I'm learning about database X“ and „I'm 
considering database X for project Y“, because notes from the first one go to 
Databases.org and notes from the second one to ProjectY.org. Clocking is 
different (even if I'm learning about X, I clock in Y if I'm doing it as part 
of a project).
  Therefore I try to keep project notes at a minimum, because they are dated 
and ephimeral, whereas the general knowledge accumulates in other files (one 
file per topic, encyclopedia-style).

 
 Or is this what you mean by using links? Are you just saying that
 individuals should not be copying the same text around in multiple
 places?
 

  Of course copy+paste is a nightmare to maintain (see: DRY). I am still forced 
to do it with some org tables which do complex calculations. I think org offers 
dynamic tables to apply the same process to different data sources, but it gets 
complex. I think there's no such thing as „templates“ where you change the base 
one and all uses of it (in all files) are automatically updated.

  About links: in org-mode they all look the same, but semantically there are 
many types, like:
- *is-a*: „this is a concrete implementation of [[that generic knowledge]]“
- *related*: „related to this is: [[that]]“
- *same-as*: „this and [[that]] are exactly the same topic, so write only under 
that header, not here“ ← this is poor man's transclusion, or more like 
„symbolic links“ in ext4. With it, a header seems to be present in many places 
at the same time; in reality the content is only in one place and the rest are 
links. The good thing is, it doesn't really matter /where/ exactly is that 
tree, because you'll find it anyway by following maximum 1 link. X can link to 
Y, or Y can link the X; what's important is that reading both X or Y you'll 
find exactly the same thing (not copy+pasted contents).

  So, it's all about finding a manual algorithm to organize things.


Daniel

Re: [O] org-mode for knowledge management

[Daniel Clemente]

El Sat, 11 Oct 2014 12:45:45 -0700 Brady Trainor va escriure:
 
About links: in org-mode they all look the same, but semantically there 
  are many types, like:
  […]
  - *same-as*: „this and [[that]] are exactly the same topic, so write
  only under that header, not here“ 
  […]
 I don't think I am aware of the *sameas* type of link in org-mode, can
 you give an example please? 
 

There's only 1 type of link between headers in org-mode; what's different is 
the way in which you use it.

* About web pages
** CSS
** HTML
*** Convert to other formats
 convert to JSON
Use html2json
 convert to PDF → see [[html_to_pdf]]
* About PDFs
** create them
*** from .odt
Click that icon.
*** from .html. id:html_to_pdf
There's this method…
*** from .tex


In this case, that „HTML→PDF“ section could live under the „web pages“ tree or 
under the „PDFs“ tree, and there's no difference because it's exactly the same 
information.
If you consider „link following“ as a trivial operation, you could say that 
that knowledge is accessible under both trees at the same time. It's not 
transclusion, but it works the same.

Note that in the example above, the „→ see …“ header must be empty of content. 
If you write inside, it's not a light link anymore, it's a header on its own.

Org-mode could offer this type of header built-in (a light header is a header 
which must link to another one and have no content), but you can do it with the 
current tools and a bit of care.

Re: [O] org-mode for knowledge management

[Daniel Clemente]

 
  I've been using org-mode for a variety of purposes for a few years. I find 
  that it suffers from the same problem that other such tools do. The 
  problem is me. I can't remember week to week how I may have classified 
  some scrap of information. Did I drop it into notes/someproduct.org or was 
  it procedures/someprocess.org?

1. Every information should have a single location, not two. Mix sections fast 
if you detect repetitions. Use links extensively (C-c l) to connect one header 
with another, specially after you get lost once. Don't bother too much about 
finding the right place at the first time, you'll eventually reorder or move 
headers to the correct place.

2. Use global search (C-a /), you can use regular expressions there. No need to 
use grep.

3. Use the package „helm“ to get fast access to all headers or to a subsection 
of headers (e.g. the ones you tag). E.g. I use radio to give important 
sections a title. After 1 key you start typing some letters, select with 
cursors, press ENTER and go to the header.

 
 Also, if English is not your native language, consider making notes in
 English.  Whether you like it or not, it has one huge advantage: it's
 /simple/.  Almost no inflections, so grepping English texts is /much/
 easier than, say, Polish (we have /a lot/ of inflections).  (In this
 regard, Esperanto is even better, though personally I'm not fluent
 enough in it to make my notes in Esperanto comfortably.)
 

  And I thought I was the only one taking notes in Esperanto! 700 Kb of my 
notes are in Esperanto. Sometimes I invent new words which later I don't find 
by searching, but after I do, I add the new variants of the title. It's great 
for defining strange concepts.
  Inflections are a minor problem in most languages, just use partial search or 
regexp (e.g. in Polish use „słow“ instead of „słowo“, „następn.*“ etc.) and 
you'll find everything. If you want inflection-free languages you'll need 
Indonesian, Chinese, … 
  But I wouldn't force taking notes in a language you don't like, just use the 
ones you like. („the ones“, in plural).


  Ĝis!
  
Daniel

Re: [O] words from radio links are not visible when exporting subtrees

[Daniel Clemente]

El Thu, 28 Aug 2014 01:06:43 +0200 Nicolas Goaziou va escriure:
 
  * word
  * aaa
  ** export only this subtree (you'll lose a word)
  ABC
 
 
 
  Go to the „**“ and use C-c C-e C-s h H (export subtree to HTML). The result 
  has the word „word“ missing from title and header:
 
  titleexport only this subtree (you'll lose a )/title
  h1 class=titleexport only this subtree (you'll lose a )/h1
 
 I think this bug came with the initial merge of the new export
 framework. Anyway, it should be fixed. Thank you for reporting it.
 

  It works now, thanks.
  

Re: [O] HTML lists are including paragraphs (lip…/p/li)

[Daniel Clemente]

It works very well now, thank you.


El Tue, 26 Aug 2014 09:59:24 +0200 Nicolas Goaziou va escriure:
 
 Daniel Clemente n142...@gmail.com writes:
 
Ok, let's keep the complex cases possible, but the simple ones simple. So:
  - litext/li and litextul//li if there's only 1 text or sublist or 
  text+sublist
  - li[normal flow including p,ol,ul,blockquote,…]/li in the rest.
  This includes lip/p//li, lip/ol/p//li,
  liolp//li, lip/p/ol//li
 
 Fair enough. This is now implemented in master. Please report if it
 isn't working as expected.
 
 Thank you.
 
 
 Regards,
 
 -- 
 Nicolas Goaziou

[O] words from radio links are not visible when exporting subtrees

[Daniel Clemente]

Hi, with latest org-mode and this 4-line org:


* word
* aaa
** export only this subtree (you'll lose a word)
ABC



Go to the „**“ and use C-c C-e C-s h H (export subtree to HTML). The result has 
the word „word“ missing from title and header:

titleexport only this subtree (you'll lose a )/title
h1 class=titleexport only this subtree (you'll lose a )/h1


I tried to bisect it but export stopped working for other reasons.

Re: [O] HTML lists are including paragraphs (lip…/p/li)

[Daniel Clemente]

El Mon, 25 Aug 2014 10:30:27 +0200 Nicolas Goaziou va escriure:

But why not, as a general rule, avoid p for the first elements of 
  lists? That is, don't output paragraph+list+paragraph, but 
  text+list+paragraph.
This works for the simple case (litext/li) and allows the
complex ones (litextpaa/pol/olwhatever/whatever/li).
 
 This was the original behaviour, which was, apparently, unsatisfactory.
 See
 
   http://article.gmane.org/gmane.emacs.orgmode/87898
 
 

  Ok, let's keep the complex cases possible, but the simple ones simple. So:
- litext/li and litextul//li if there's only 1 text or sublist or 
text+sublist
- li[normal flow including p,ol,ul,blockquote,…]/li in the rest. This 
includes lip/p//li, lip/ol/p//li, liolp//li, 
lip/p/ol//li

Re: [O] HTML lists are including paragraphs (lip…/p/li)

[Daniel Clemente]

El Wed, 06 Aug 2014 14:12:21 +0200 Nicolas Goaziou va escriure:
 
 I understand that paragraph is alone in its item is not a good test to
 skip paragraph wrappers. I'm still confused about what a good test would
 be. In particular, what should be done in the following cases
 
   - item
   - item
 - sublist
 resuming item


  You mean „item“ contains text+ol+p? Rather strange… I first thought that 
„resuming item“ would be a continuation line of „sublist“ (that is, as if 
„sublist resuming item“ were the only item of the sublist).
  But why not, as a general rule, avoid p for the first elements of lists? 
That is, don't output paragraph+list+paragraph, but text+list+paragraph.
  This works for the simple case (litext/li) and allows the complex ones 
(litextpaa/pol/olwhatever/whatever/li).

  
 i.e., (paragraph plain-list paragraph), and
 
   - outer
 
 another paragraph
 
 - inner
 - simple list
 
 i.e., are nested plain-lists independent relatively to paragraph
 wrappers skipping. I think so, but I'd rather make sure.
 

I'd also say text+p+ol.

Rather unusual syntax anyway… but it shouldn't break the simple liPlain 
item/li (now broken).

[O] HTML lists are including paragraphs (lip…/p/li)

[Daniel Clemente]

Hi. With latest org I'm getting lip…/p/li, which makes no sense; it 
should be li…/li
Aren't there tests to find this type of breakages in export?


Example:

- hola
- uno
  - dos
- tres


Is exported to:


ul class=org-ul
lip
hola
/p
/li
lip
uno
/p
ul class=org-ul
lidos
/li
/ul
/li
lip
tres
/p
/li
/ul

Re: [O] Export org-mode buffer to dynamic html document (collapse/expand details)

[Daniel Clemente]

I did a custom solution, very simple, with jQuery. You may use it:

Demo:
  http://www.danielclemente.com/hacer/emacs.html
Code:
  http://www.danielclemente.com/pagina/esquemadorg.js
  http://www.danielclemente.com/pagina/esquemadorg.css


- The JS and CSS applies to the normal org export.
- The index of contents is itself collapsable.
- The hyperlinking was tricky because if the link destination is collapsed you 
have to open it automatically (including its parents).
- There's a button to disable the outline (text: „ver todo seguido“)


El Thu, 31 Jul 2014 17:50:03 +0200 Martin Beck va escriure:
 
 Hi,
 I'm sorry, if this might be obvious, but I don't have much experience with 
 org-mode export up to now and I urgently need to export
 much information from my notes and task lists in org-mode in a way that my 
 colleagues (no experience with Emacs / org-mode at all)
 can use it during my absence.
  
 Therefore I need some advice from you:
  
 I have a lot of projects (hierarchically structured in headings with todo 
 keywords, sub-headings, hyperlinks, notes, etc.)
 I want to export all this information into a text format to make it usable 
 for my colleagues.
 However, there is A WHOLE LOT of text and to make it the least confusing 
 possible,
 it would be great if the text below headings could be collapsed somehow or if 
 there was an overview page listing all projects and
 some important sub-headings or remarks and a hyperlink pointing to the 
 detailed notes concerning this project.
  
 Any hints appreciated
  
 Kind regards
  
 Martin
 
 

Re: [O] results from Python block not visible

[Daniel Clemente]

I reported this to emacs (bug 18095):
http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-07/msg00736.html

It's still happening with latest emacs and org-mode


On Wed, Jul 2, 2014 at 11:51 PM, Daniel Clemente n142...@gmail.com wrote:

 Since this org-babel + tramp-cache incompatibility is very puzzling, I
 continued researching it. The line that makes my Python block stop working
 (i.e. outputting None instead of the x I asked with print x') is this
 one, found in tramp-cache.el:

 (add-hook 'kill-buffer-hook 'tramp-flush-file-function)

 Its code is:

 (defun tramp-flush-file-function ()
  Flush all Tramp cache properties from `buffer-file-name'.
 This is suppressed for temporary buffers.
  (unless (string-match ^ \\*temp\\* (or (buffer-name) ))
(let ((bfn (if (stringp (buffer-file-name))
   (buffer-file-name)
 default-directory)))
  (when (tramp-tramp-file-p bfn)
 (with-parsed-tramp-file-name bfn nil
  (tramp-flush-file-property v localname))


 That temporary buffer detector is working correctly because org-babel
 buffers have names like  *temp*-993012, which are correctly detected.
 I'm afraid that the (string-match ...) will forget the last search, so later
 (match-string) done by babel will be from the wrong search. Can this happen?

 --
 Daniel


 On Fri, Jun 27, 2014 at 4:50 PM, Daniel Clemente n142...@gmail.com
 wrote:

 I confirm that with Debian's Emacs, org-babel works well after the
 (require 'tramp-cache):
 GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.2) of 2014-06-06
 on barber, modified by Debian

 But it fails with my compiled one from 2014-06-20.

 So is it because of tramp-cache or org-babel?


 On Fri, Jun 27, 2014 at 12:19 AM, Daniel Clemente n142...@gmail.com
 wrote:


 El Thu, 26 Jun 2014 12:36:47 -0400 Eric Schulte va escriure:
   #+BEGIN_SRC python :results output
   print x
   #+END_SRC
  
   It prints:
  
   #+RESULTS:
   : None
  
   I expected to see x. This worked some days ago.
  
 
  This works for me using the latest version of Org-mode with an Emacs
  launched by running make vanilla from the base of the Org-mode repo.
 
   I didn't know make vanilla. It worked fine from there, I don't know
 why from emacs -Q it didn't.

  Maybe the problem is in your configuration?

   Exactly, it is from my configuration, because after loading my full
 configuration, I see the problem again and code highlighting suddenly
 disappears.

   I identified the exact lines that cause org-babel to stop failing.
 Bewonder:

   (autoload 'tramp tramp Remotely access files. t)
   (require 'tramp-cache)

   Yes! After C-x C-e on the first line, org-babel still works. After C-x
 C-e on the second line, it doesn't work anymore.
   There were some Tramp changes in latest Emacs, maybe they are bad. I'm
 using:  GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw
 scroll bars) of 2014-06-20 on la4


   What a strange bug...

Re: [O] cache problem, with ECM

[Daniel Clemente]

 
 As a quick follow-up, I can get rid of the cache corruption by not using
 the log book (I set '(setq org-log-into-drawer nil)'). If others are
 seeing such cache corruption, this might be a temporary workaround.
 
  I also am seeing many cache problems, e.g.
  - after changing TODO→DONE a repeating task with .+1m , it stays DONE (not 
TODO), the date doesn't change to next month, and C-e stops working (Wrong type 
argument: number-or-marker-p, nil). The backtrace included some function like 
…-update-cache-…
  - lines that should appear inside log drawer (like :LAST_REPEAT:) appear 
anywhere, e.g. in between the CLOCK: […]--[…] entries

Re: [O] babel evaluation of python and utf-8

[Daniel Clemente]

El Fri, 04 Jul 2014 16:08:10 +0200 Alan Schmitt va escriure:
 
 On 2014-06-26 18:07, Daniel Clemente n142...@gmail.com writes:
 
  
  #+BEGIN_SRC python :prefix # -*- coding: utf-8 -*- :results output
  print(u'é')
  #+END_SRC
  
 
  I also see the same problem here. Even if you include   # -*- coding: utf-8 
  -*-as the first line.
 
  Shouldn't org-babel already be using utf-8 instead of ASCII for 
  input/output?
 
  By the way, with Python3 it doesn't happen since it doesn't need the 
  coding:utf-8 declaration anymore.
 
 Should this be considered a bug, or do we require python 3 for such
 things?
 

I think if the user writes the # -*- coding: utf-8 -*- line, org-mode should 
pass it. With that, all Pythons (Python2, Python3) work well, so I wouldn't say 
there's a bug in Python. It would be in org-mode.

Re: [O] results from Python block not visible

[Daniel Clemente]

Since this org-babel + tramp-cache incompatibility is very puzzling, I
continued researching it. The line that makes my Python block stop working
(i.e. outputting None instead of the x I asked with print x') is this
one, found in tramp-cache.el:

(add-hook 'kill-buffer-hook 'tramp-flush-file-function)

Its code is:

(defun tramp-flush-file-function ()
 Flush all Tramp cache properties from `buffer-file-name'.
This is suppressed for temporary buffers.
 (unless (string-match ^ \\*temp\\* (or (buffer-name) ))
   (let ((bfn (if (stringp (buffer-file-name))
  (buffer-file-name)
default-directory)))
 (when (tramp-tramp-file-p bfn)
(with-parsed-tramp-file-name bfn nil
 (tramp-flush-file-property v localname))


That temporary buffer detector is working correctly because org-babel
buffers have names like  *temp*-993012, which are correctly detected.
I'm afraid that the (string-match ...) will forget the last search, so later
(match-string) done by babel will be from the wrong search. Can this happen?

--
Daniel


On Fri, Jun 27, 2014 at 4:50 PM, Daniel Clemente n142...@gmail.com wrote:

 I confirm that with Debian's Emacs, org-babel works well after the
 (require 'tramp-cache):
 GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.2) of 2014-06-06
 on barber, modified by Debian

 But it fails with my compiled one from 2014-06-20.

 So is it because of tramp-cache or org-babel?


 On Fri, Jun 27, 2014 at 12:19 AM, Daniel Clemente n142...@gmail.com
 wrote:


 El Thu, 26 Jun 2014 12:36:47 -0400 Eric Schulte va escriure:
   #+BEGIN_SRC python :results output
   print x
   #+END_SRC
  
   It prints:
  
   #+RESULTS:
   : None
  
   I expected to see x. This worked some days ago.
  
 
  This works for me using the latest version of Org-mode with an Emacs
  launched by running make vanilla from the base of the Org-mode repo.
 
   I didn't know make vanilla. It worked fine from there, I don't know
 why from emacs -Q it didn't.

  Maybe the problem is in your configuration?

   Exactly, it is from my configuration, because after loading my full
 configuration, I see the problem again and code highlighting suddenly
 disappears.

   I identified the exact lines that cause org-babel to stop failing.
 Bewonder:

   (autoload 'tramp tramp Remotely access files. t)
   (require 'tramp-cache)

   Yes! After C-x C-e on the first line, org-babel still works. After C-x
 C-e on the second line, it doesn't work anymore.
   There were some Tramp changes in latest Emacs, maybe they are bad. I'm
 using:  GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw
 scroll bars) of 2014-06-20 on la4


   What a strange bug...

Re: [O] results from Python block not visible

[Daniel Clemente]

I confirm that with Debian's Emacs, org-babel works well after the (require
'tramp-cache):
GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.2) of 2014-06-06
on barber, modified by Debian

But it fails with my compiled one from 2014-06-20.

So is it because of tramp-cache or org-babel?


On Fri, Jun 27, 2014 at 12:19 AM, Daniel Clemente n142...@gmail.com wrote:


 El Thu, 26 Jun 2014 12:36:47 -0400 Eric Schulte va escriure:
   #+BEGIN_SRC python :results output
   print x
   #+END_SRC
  
   It prints:
  
   #+RESULTS:
   : None
  
   I expected to see x. This worked some days ago.
  
 
  This works for me using the latest version of Org-mode with an Emacs
  launched by running make vanilla from the base of the Org-mode repo.
 
   I didn't know make vanilla. It worked fine from there, I don't know
 why from emacs -Q it didn't.

  Maybe the problem is in your configuration?

   Exactly, it is from my configuration, because after loading my full
 configuration, I see the problem again and code highlighting suddenly
 disappears.

   I identified the exact lines that cause org-babel to stop failing.
 Bewonder:

   (autoload 'tramp tramp Remotely access files. t)
   (require 'tramp-cache)

   Yes! After C-x C-e on the first line, org-babel still works. After C-x
 C-e on the second line, it doesn't work anymore.
   There were some Tramp changes in latest Emacs, maybe they are bad. I'm
 using:  GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw
 scroll bars) of 2014-06-20 on la4


   What a strange bug...

Re: [O] babel evaluation of python and utf-8

[Daniel Clemente]

 
 #+BEGIN_SRC python :prefix # -*- coding: utf-8 -*- :results output
 print(u'é')
 #+END_SRC
 

I also see the same problem here. Even if you include   # -*- coding: utf-8 -*- 
   as the first line.

Shouldn't org-babel already be using utf-8 instead of ASCII for input/output?


By the way, with Python3 it doesn't happen since it doesn't need the 
coding:utf-8 declaration anymore.

[O] results from Python block not visible

[Daniel Clemente]

Hi, this babel code recently stopped working on my system:

#+BEGIN_SRC python :results output
print x
#+END_SRC

It prints:

#+RESULTS:
: None

I expected to see x. This worked some days ago.

If I use a command like os.system(xeyes), I see it running.

In addition I don't see the Python block highlighted


GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 
2014-06-20 on la4
org-mode from today
Debian. Python 2.7 (same with Python 3).
It also happens under emacs -Q

Of course I loaded Python support:

(org-babel-do-load-languages
 'org-babel-load-languages
 '((R . t)
   (C . t)
; …
   (python . t)
   (ruby . t)
   (sql . t)
   (sqlite . t)))


Greetings, Daniel

Re: [O] results from Python block not visible

[Daniel Clemente]

El Thu, 26 Jun 2014 12:36:47 -0400 Eric Schulte va escriure:
  #+BEGIN_SRC python :results output
  print x
  #+END_SRC
 
  It prints:
 
  #+RESULTS:
  : None
 
  I expected to see x. This worked some days ago.
 
 
 This works for me using the latest version of Org-mode with an Emacs
 launched by running make vanilla from the base of the Org-mode repo.

  I didn't know make vanilla. It worked fine from there, I don't know why 
from „emacs -Q“ it didn't.
  
 Maybe the problem is in your configuration?

  Exactly, it is from my configuration, because after loading my full 
configuration, I see the problem again and code highlighting suddenly 
disappears.
  
  I identified the exact lines that cause org-babel to stop failing. Bewonder:

  (autoload 'tramp tramp Remotely access files. t)
  (require 'tramp-cache)

  Yes! After C-x C-e on the first line, org-babel still works. After C-x C-e on 
the second line, it doesn't work anymore.
  There were some Tramp changes in latest Emacs, maybe they are bad. I'm using: 
 GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 
2014-06-20 on la4
  

  What a strange bug…

Re: [O] radio links in middle of words.

[Daniel Clemente]

El Thu, 10 Apr 2014 23:43:41 +0200 Nicolas Goaziou va escriure:
 
 It could work. But I think [:alnum:] is needed instead of [:alpha:].
 Here's a patch implementing it.
 

Now it's much better. Thanks.

[O] radio links match blank spaces

[Daniel Clemente]

Hi, after the recent change to radio links, THIS link will make the 2 
spaces around THIS word become blue, as if they were part of the link.

  I wanted to write a test. I have been inspecting org-element's result but I 
can't understand the :begin and :end properties; they seem to be too high, e.g. 
they are :begin 3 :end 5 for a 1-letter link that is in position 0 to 1. I used 
this 2-line file to test:

r LINK
r

  Greetings
  

Re: [O] radio links in middle of words.

[Daniel Clemente]

 
  Can't we break at non-letters? Not at non-„word-constituents“, but at
  non-letters. If emacs doesn't provide that concept, better build it.
 
 I don't know. Could you define precisely that concept?
 

  I propose: radio links should be delimited by characters that don't match 
[:alpha:] in emacs' regular expression syntax.
  Letters (like: aá書ĉ) match, and delimiters (like: -'/) don't.

  Test it with:
: (string-match-p [[:alpha:]] á)
: (string-match-p [[:alpha:]] 書)
: (string-match-p [[:alpha:]] ĉ)

: (string-match-p [[:alpha:]] ')
: (string-match-p [[:alpha:]] -)

  And the opposite: check for non-letterness:
: (string-match-p [^[:alpha:]] -)
: (string-match-p [^[:alpha:]] á)


  So a radio link with LINK_TEXT should not only be a match of the regexp 
LINK_TEXT but of [^[:alpha:]]LINK_TEXT[^[:alpha:]] (well, make it something 
like (^|non-letter)LINK_TEXT($|non-text).

  I think that's better than the current solution and stills allows for radio 
links which contain non-letters, like o'clock.
  What do you think?


Daniel

Re: [O] radio links in middle of words.

[Daniel Clemente]

El Wed, 02 Apr 2014 18:57:13 +0200 Nicolas Goaziou va escriure:
 
  ** Languages
  *** C language
  *** JavaScript
  *** etc.
  Etc. ← should the C in etc be highlighted as a link to „C“? Now it is and 
  it's a bit annoying. This is new behaviour.
 
 Indeed, this is expected. The patch you pointed out allows mid-word
 radio-targets. See related thread for more information.
 
  „Related thread“: http://comments.gmane.org/gmane.emacs.orgmode/82923

  I don't see in there any argument to have midword links, it's presented as a 
consequence of other patch.

  I'm a heavy user of these links to mark concepts' definitions, they are 
much more useful than these or [[these]]. I have notes about programs I 
tried, like R, at or ps, C, CR vs LF vs 
CRLF, 3-letter stock tickers, … so now I'm seeing blue links everywhere 
in the middle of words. I can get used to it, but it's ugly and not useful.

  I only need links surrounded by non-letters, like:
#+BEGIN_EXAMPLE
  org
  organization ← certainly I'm not using the letter 'a' as a separator. I don't 
want link.
  org:mode ← ':' is a non-letter, so it's a separator. I want link
  orgもmode ← what's も? Let's simply say it's a letter, so no separator. No 
link, ok.
  org'mode ← is ' a letter? Ask people, I think most say no. So: with link.

  o'clock (oh, a non-letter inside. Ok)
  o'clocking ← no, I'm not using 'i' as a separator. No link.
  o'clock ← is  a letter? No. So: with link
#+END_EXAMPLE

  The only use case I see is using radio links to mark the root of a word so 
that the inflected words are also highlighted, e.g. script would 
highlight „scripting“. But hey, when I want both „script“ and „scripting“ 
highlighted, I use radio links on both, not a problem.

  Can't we break at non-letters? Not at non-„word-constituents“, but at 
non-letters. If emacs doesn't provide that concept, better build it.


  Thanks
  

[O] radio links in middle of words. (was: Re: radio links should not match empty text)

[Daniel Clemente]

El Wed, 02 Apr 2014 14:59:42 +0200 Nicolas Goaziou va escriure:
  Hi, recently this syntax:   started highlighting all spaces (spaces 
  between words) as if they were links. I see them with a blue underline.
I found this because I used some Unicode-art like   
  where I certainly didn't mean to define a radio link.
 
 This should be fixed. Thank you for reporting it.

  Now it works, thanks.
  I also found a strange behaviour where links appear in the middle of words. 
Explanatory example:


** Languages
*** C language
*** JavaScript
*** etc.
Etc. ← should the C in etc be highlighted as a link to „C“? Now it is and it's 
a bit annoying. This is new behaviour.

[O] radio links should not match empty text

[Daniel Clemente]

Hi, recently this syntax:   started highlighting all spaces (spaces 
between words) as if they were links. I see them with a blue underline.
  I found this because I used some Unicode-art like   where I 
certainly didn't mean to define a radio link.

  This happens since this change:

#+BEGIN_QUOTE
commit 1c1936fbb1f0c42e5c7e1d3c903626aa5993a357
Author: Nicolas Goaziou n.goaz...@gmail.com
Date:   Tue Mar 25 10:15:25 2014 +0100

Allow radio links after an apostrophe and mid-word

* lisp/org.el (org-make-target-link-regexp): Allow radio links after
  an apostrophe and mid-word.  Small refactoring.

* testing/lisp/test-ox.el (test-org-export/resolve-radio-link): Add
  test.

See http://permalink.gmane.org/gmane.emacs.orgmode/84108.
#+END_QUOTE

  Greetings,
Daniel

Re: [O] [ANN] Lazy cache synchronization

[Daniel Clemente]

 Nicolas Goaziou n.goaz...@gmail.com writes:
  Now, synchronization happens lazily, which means the cache is only
  updated when and where needed, or during idle time. Therefore the cache
  mechanism scales a lot better.
 

  I had been regularly tracking the performance of org-mode for big files, e.g. 
a 18 Mb one with 380k lines (created only to test this).

  1. With last month's org-mode in emacs 24 I needed more than 5 minutes to 
open it, and then moving around the file was too slow to be comfortable (local 
editing was however acceptable).
  2. With the current one, it's only 10 seconds loading time, local editing is 
still fast, and jumping around sections takes at most 2 seconds per move.
  
  So this change has made me stop worrying about files growing too fast, at 
least for many years. Thanks!

Re: [O] IDs w/ human friendly component

[Daniel Clemente]

  Have you tried changing the strange ID to the ID that you want? (e.g. 
7f3b531b-f1c9-41aa-854b-37235500495f → introduction). They should be unique.
  I use my manually written IDs for some important headers which I want to 
detect from outside org.
  In addition there's CUSTOM_ID, but I think that's the id=… you want in HTML 
exports.


El Sat, 1 Feb 2014 14:39:15 -0500 (EST) Ken Mankoff va escriure:
 
 
 I've never cared that the ID field was not human friendly.
 
 But I've just learned about the Estimate Table where you can see your 
 estimates
 and actual clock time to complete tasks. If you want to see the estimates for
 the current tree, you need to know the ID, which is not human friendly.
 
 It seems like with IDO mode, the first few characters or words of the title,
 stripped of whitespace, could be pre- or ap- pended onto the ID, and then it
 would be easy to select IDs. If this were how IDs were created, would this 
 break
 some other features? Do others see this as a good or bad thing? Or is there 
 some
 other way to tell the Estimate Table to work on the local tree.
 
 Cheers,
 
   -k.
 

Re: [O] There can only be one item with priority 1?

[Daniel Clemente]

El Thu, 30 Jan 2014 14:49:59 +0100 Fredrik va escriure:
 I know there is the ABC but that doesn't support what I shown here where I add
 an item in the middle of the list changes the priority of everything below it?
 

  If you consider section order as priority, then you already have it: when you 
insert a section in the middle, all the ones below are of lower priority, 
without you having to change anything else.
  Use M-up and M-down to reorder sections.

  You can use the sorting order only when you have many [#A] or [#B] or [#C] of 
the same type together.

  You could also use [#A] [#B] [#C] [#D] [#E], but I think 3 groups is enough.
  

[O] void-variable: tree in agenda in emacs 23.4.1

[Daniel Clemente]

Hi,
  since some days ago I get an export error after C-a a, batch export, C-e on 
.org files, … Backtrace at the end.

  Even (avl-tree--root org-element--cache) or (avl-tree--root nil) produce the 
same error.

  This is not a bug in org, but in Emacs 23.4.1. avl-tree.el says:

(defmacro avl-tree--root (tree)
  ;; Return the root node for an avl-tree.  INTERNAL USE ONLY.
  `(avl-tree--node-left (avl-tree--dummyroot tree)))

  And it should have a comma before the word „tree“ in the body. Like this 
(org-mode works with this):

(defmacro avl-tree--root (tree)
  ;; Return the root node for an avl-tree.  INTERNAL USE ONLY.
  `(avl-tree--node-left (avl-tree--dummyroot ,tree)))

  This was fixed in emacs from Bazaar (in rev. 104392, Fri 2011-05-27 20:03:26 
-0300).

  But at the moment org-mode does not work in Emacs 23.4.1, so I think it 
should have a work-around.
  The fix can be: „if Emacs version is lower than […] then define the macro 
again with the correct code“. Like:

(if (version emacs-version 24)
  (defmacro avl-tree--root (tree)
  ;; Backport fix for older versions due to missing comma in ,tree
  `(avl-tree--node-left (avl-tree--dummyroot ,tree)))
)


  Thanks,

Daniel




  Backtrace:

Debugger entered--Lisp error: (void-variable tree)
  (avl-tree--dummyroot tree)
  (avl-tree--node-left (avl-tree--dummyroot tree))
  (avl-tree--root org-element--cache)
  (let ((node ...) last) (catch (quote found) (while node ...) last))
  (if (not (wholenump key)) (gethash key org-element--cache-objects) (let (... 
last) (catch ... ... last)))
  (progn (when (and ... ...) (org-element--cache-sync ...)) (if (not ...) 
(gethash key org-element--cache-objects) (let ... ...)))
  (if (and org-element-use-cache org-element--cache) (progn (when ... ...) (if 
... ... ...)))
  (when (and org-element-use-cache org-element--cache) (when (and ... ...) 
(org-element--cache-sync ...)) (if (not ...) (gethash key 
org-element--cache-objects) (let ... ...)))
  org-element-cache-get(65264)
  (let* ((cached ...) (begin ...)) (cond (... ... ... ...) (... ...) (... ... 
... ...) (t ...)))
  (let ((origin ...) element next) (end-of-line) (skip-chars-backward  
\n) (cond (... ...) (... ... ...)) (goto-char origin) (let* (... ...) 
(cond ... ... ... ...)) (let (... parent special-flag) (while t ... ... ...)))
  (save-restriction (widen) (let (... element next) (end-of-line) 
(skip-chars-backward  
\n) (cond ... ...) (goto-char origin) (let* ... ...) (let ... ...)))
  (save-excursion (save-restriction (widen) (let ... ... ... ... ... ... ...)))
  (org-with-wide-buffer (let (... element next) (end-of-line) 
(skip-chars-backward  
\n) (cond ... ...) (goto-char origin) (let* ... ...) (let ... ...)))
  …

Re: [O] Parsing Org-mode in Python

[Daniel Clemente]

El Wed, 08 Jan 2014 10:42:17 -0500 Brett Viren va escriure:
 
   http://lists.gnu.org/archive/html/emacs-orgmode/2013-12/msg00415.html
 
 In any case, here is the salient chunk:
 
 #+BEGIN_SRC elisp
   (require 'json)
   (let* ((tree (org-element-parse-buffer 'object nil)))
 (org-element-map tree (append org-element-all-elements
 org-element-all-objects '(plain-text))
   (lambda (x) 
 (if (org-element-property :parent x)
 (org-element-put-property x :parent none))
 (if (org-element-property :structure x)
 (org-element-put-property x :structure none))
 ))
 (write-region
  (json-encode tree) 
   nil foo.dat))
 #+END_SRC
 

  I like this very much. This output is much easier to parse than the source 
.org file, and it's still using the original Elisp parser (so you don't need a 
Python parser).
  I hope ox-json.el gets into org-mode some day.

  Are there already Python parsers for it?
  Should ox-json's output be as raw as possible (e.g. what your code produces 
now) or transformed to simpler JSON?
  (I think both formats should coexist).
  

Re: [O] Implementing Org-mode tools in languages other than ELISP

[Daniel Clemente]

 
 I dream of having a general Python parser for Org mode files, knowing
 every bit about the current syntax for Org files, surrounded by enough
 Python machinery to make it useful.
 

Try PyOrgMode (https://github.com/bjonnh/PyOrgMode), it works for some files 
(but still needs corrections: it crashes with date formats, with bold markers, 
etc.).

You don't need a Lisp interpreter written in Python, only Python code that 
understands org syntax without getting confused.

Re: [O] re-export using same options

[Daniel Clemente]

  Can I re-export using the last settings? 
   
   C-u C-c C-e
  
Thanks, that makes it faster, but you need to be in the same subtree. 
 
 Not so.
 

  With org-mode from some days ago it was failing: only moving to a new subtree 
would make C-u C-c C-e export the new subtree (using the old format).
  But I tried again today with latest org-mode and it doesn't happen; now the 
old tree is remembered correctly.
  Thanks for pointing it out.


 and it appears to update during edits so that same the subtree is found
 in subsequent exports. This
 
  If the current buffer hasn't changed and subtree export 
  was activated, the command will affect that same subtree.
 
 seems to say that buffer edits will break C-u C-c C-e, but 
 that did not happen in the examples I tried.

  This happened to me (the marker pointed to a different subtree) but only if 
my edits were before the marker, not after. But since most people want to edit 
things below the heading they export, this shouldn't be a common problem.

[O] re-export using same options

[Daniel Clemente]

  Hi, after exporting a subtree to HTML, I do some change and want to export 
again. I find that I have to do a long process to get there:
C-spaceC-c C-u   C-c C-e C-s h HC-u space

  This works, but for every little change I do I have to select again which 
subtree and which format I want.

  Can I re-export using the last settings? If there's a function for that that 
can be invoked with M-x, then only  M-x up RET   will be needed for successive 
reexports.


  Thanks

Re: [O] re-export using same options

[Daniel Clemente]

  
Can I re-export using the last settings? 
 
 C-u C-c C-e

  Thanks, that makes it faster, but you need to be in the same subtree. Is 
there something that also remembers which subtree was exported?

[O] words starting with call_ confuse C-c C-c and export

[Daniel Clemente]

  Hi, with org-mode from today on Emacs 23.4.1 and with this 2-line file:

- [ ] call_me
- [ ] try funcall_lambda (maybe)


1. Go to the „me“ and press C-c C-c. You get „C-c C-c can do nothing useful at 
this location“. I expected to switch the checkbox.

2. Go to the „maybe“ and press C-c C-c. I got:

Debugger entered--Lisp error: (void-function maybe)
  (maybe)
  eval((maybe))
  org-babel-read((maybe))
  org-babel-ref-parse(results=(maybe))
  #[(el) …
  mapcar(#[(el) …
  org-babel-process-params(((:comments . ) (:shebang . ) (:cache . no) 
(:padline . ) (:noweb . no) (:tangle . no) (:exports . code) (:results 
. replace) (:var . results=(maybe)) (:hlines . no) (:session . none)))
  org-babel-lob-execute((lambda (maybe) nil 13 nil))
  org-babel-lob-execute-maybe()
  org-babel-execute-maybe()
  org-babel-execute-safely-maybe()
  run-hook-with-args-until-success(org-babel-execute-safely-maybe)
  org-ctrl-c-ctrl-c(nil)


3. Similar confusions happen on export; the word Fcall_interactively which 
appeared in a gdb backtrace was crashing the HTML exportation.


  I think something similar happened to me years ago, and I had to avoid all 
call_ words!

Re: [O] org-publish parameters mismatch → cannot publish to HTML

[Daniel Clemente]

 
org-publish-org-to-html seems to have its parameters in the same
order (filename, extension, plist). Correct me if I'm wrong.
 
 
 If you are using org8.X, then org-publish-org-to-html no longer
 exists. If it does, you are picking up old org bits from somewhere.
 

True. And I was following an outdated page which used org-publish-org-to-html: 
http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html
With the new function, it works, thanks.

Can we use define-obsolete-function-alias for the old functions?

[O] org-publish parameters mismatch → cannot publish to HTML

[Daniel Clemente]

  Hi, in ox-publish.el I see in line 555:

(defun org-publish-org-to (backend filename extension plist optional pub-dir)
…

  org-publish-org-to-html seems to have its parameters in the same order 
(filename, extension, plist). Correct me if I'm wrong.

  But then in same file, line 654:
(when (org-publish-needed-p
   filename pub-dir f tmp-pub-dir base-dir)
  (funcall f project-plist filename tmp-pub-dir)
…

  With the default setting f == org-publish-org-to-html, the funcall passes 
parameters in the wrong order: plist filename. It should be: filename extension 
plist

  Later I see org trying to open the „filename“ variable which is not a file 
name but a plist:
(wrong-type-argument stringp (:base-directory ~/repoweb/ofinial… …) …)
file-truename((:base-directory ~/repoweb/ofinial/hacer/ :publishing-directory 
…) …)


  Maybe my setup is wrong (I'm confused with the org-publish / ox-publish mix) 
but the org-publish-project-alist seems safe; the stranges thing is:   
:publishing-function org-publish-org-to-html


  Does org-publish work for someone else? Why do I see new problems each time I 
try to publish…?

  Thanks

[O] [patch] correct link following

[Daniel Clemente]

Hi, I sent this patch 1 month ago but it wasn't included in org. I still need 
it for link following to work, otherwise I get:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match(^id: nil)
  org-open-at-point(nil)
  call-interactively(org-open-at-point nil nil)
  command-execute(org-open-at-point)


  I remember seeing another bug report on this list providing the same solution.

Thanks.


diff --git a/lisp/org.el b/lisp/org.el
index c42b9eb..01b39be 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10517,7 +10517,8 @@ application the system uses for this file type.
   ((and (string= type thisfile)
 (or (run-hook-with-args-until-success
  'org-open-link-functions path)
-(and (string-match ^id: link)
+(and link
+ (string-match ^id: link)
  (or (featurep 'org-id) (require 'org-id))
  (progn
(funcall (nth 1 (assoc id org-link-protocols))

[O] I cannot follow radio links

[Daniel Clemente]

  Hi, since a few days, when I press C-c C-o on a highlighted word that points 
to a radio link, I get this error:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match(^id: nil)
  org-open-at-point(nil)
  call-interactively(org-open-at-point nil nil)
  command-execute(org-open-at-point)


I think this in enough to correct it:


diff --git a/lisp/org.el b/lisp/org.el
index 6d34bce..0571bc1 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10542,7 +10542,8 @@ application the system uses for this file type.
   ((and (string= type thisfile)
 (or (run-hook-with-args-until-success
  'org-open-link-functions path)
-(and (string-match ^id: link)
+(and link
+ (string-match ^id: link)
  (or (featurep 'org-id) (require 'org-id))
  (progn
(funcall (nth 1 (assoc id org-link-protocols))



Latest org-mode, emacs from 26.m8.2013.  Thanks

Re: [O] faster agenda with properties support disabled (no org-refresh-properties)

[Daniel Clemente]

Thank you.
  With this on, I reduced 1'7 seconds my normal agenda time (C-a a), from 13'5 
to 11'8. Numbers are from elp but I checked them with an external stopwatch 
because sometimes I have the impression that elp makes things slower.
  The strange thing is, I don't see the difference I saw days before in 
(org-batch-agenda). I could reproduceably run a slow export (with no patch) and 
a fast export (with the patch). Now both are fast. I suppose that the contents 
of my agenda might have changed in a way that is fast to handle. Anyway, this 
is only good.

El Sat, 31 Aug 2013 07:58:00 +0200 Carsten Dominik va escriure:
 
 Hi Daniel,
 
 I have implemented a different version of the patch.  Please take a look at 
 the new variable
 org-agenda-ignore-drawer-properties.
 
 Regards, and thanks!
 
 - Carsten
 
 On 23.8.2013, at 11:24, Daniel Clemente n142...@gmail.com wrote:
 
  So I would like to ask: is there a clean way to disable calls to
  org-refresh-properties?
  
  No, that would require a patch and a config variable.
  
  - Carsten
  
  
   I send a patch to do this. Setting this new variable to t reduced 10
  seconds my agenda export time (down from 1 minute 6 seconds) as well
  as the update.
   You may add a comment about what to expect if your agenda depends on
  property data.
  
  
  diff --git a/lisp/org.el b/lisp/org.el
  index 572b797..167e7a8 100644
  --- a/lisp/org.el
  +++ b/lisp/org.el
  @@ -17656,6 +17656,14 @@ is not set, the tables are not re-aligned, etc.
:version 24.3
:group 'org-agenda)
  
  +(defcustom org-agenda-ignore-properties nil
  +  Avoid updating text properties when building the agenda.
  +Properties are used for effort estimation, appointments, categories.
  +If you don't use these in the agenda, set it to t and it will be faster.
  +  :type 'boolean
  +  :version 24.3
  +  :group 'org-agenda)
  +
  (defun org-duration-string-to-minutes (s optional output-to-string)
Convert a duration string S to minutes.
  
  @@ -18017,9 +18025,11 @@ When a buffer is unmodified, it is just
  killed.  When modified, it is saved
  ;; this is only run for setting agenda tags from setup
  ;; file
  (org-set-regexps-and-options)))
  -   (org-refresh-category-properties)
  -   (org-refresh-properties org-effort-property 'org-effort)
  -   (org-refresh-properties APPT_WARNTIME 'org-appt-warntime)
  +   (unless org-agenda-ignore-properties
  + (org-refresh-category-properties)
  + (org-refresh-properties org-effort-property 'org-effort)
  + (org-refresh-properties APPT_WARNTIME 'org-appt-warntime)
  +   )
  (setq org-todo-keywords-for-agenda
(append org-todo-keywords-for-agenda org-todo-keywords-1))
  (setq org-done-keywords-for-agenda
  
 

Re: [O] faster agenda with properties support disabled (no org-refresh-properties)

[Daniel Clemente]

  So I would like to ask: is there a clean way to disable calls to
 org-refresh-properties?

 No, that would require a patch and a config variable.

 - Carsten


  I send a patch to do this. Setting this new variable to t reduced 10
seconds my agenda export time (down from 1 minute 6 seconds) as well
as the update.
  You may add a comment about what to expect if your agenda depends on
property data.


diff --git a/lisp/org.el b/lisp/org.el
index 572b797..167e7a8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17656,6 +17656,14 @@ is not set, the tables are not re-aligned, etc.
   :version 24.3
   :group 'org-agenda)

+(defcustom org-agenda-ignore-properties nil
+  Avoid updating text properties when building the agenda.
+Properties are used for effort estimation, appointments, categories.
+If you don't use these in the agenda, set it to t and it will be faster.
+  :type 'boolean
+  :version 24.3
+  :group 'org-agenda)
+
 (defun org-duration-string-to-minutes (s optional output-to-string)
   Convert a duration string S to minutes.

@@ -18017,9 +18025,11 @@ When a buffer is unmodified, it is just
killed.  When modified, it is saved
;; this is only run for setting agenda tags from setup
;; file
(org-set-regexps-and-options)))
-   (org-refresh-category-properties)
-   (org-refresh-properties org-effort-property 'org-effort)
-   (org-refresh-properties APPT_WARNTIME 'org-appt-warntime)
+   (unless org-agenda-ignore-properties
+ (org-refresh-category-properties)
+ (org-refresh-properties org-effort-property 'org-effort)
+ (org-refresh-properties APPT_WARNTIME 'org-appt-warntime)
+   )
(setq org-todo-keywords-for-agenda
  (append org-todo-keywords-for-agenda org-todo-keywords-1))
(setq org-done-keywords-for-agenda

Re: [O] [PATCH] Center currently clocked headline to top of screen

[Daniel Clemente]

Seeing a bit of context is nice; maybe putting it at line 2 or 3 is better than 
at the top and I think it is better than centered. It could also be 
configurable.


El Thu, 22 Aug 2013 10:36:00 +0200 Sebastien Vauban va escriure:
 
 Hello,
 
 When jumping to the currently clocked headline (via `C-c C-x C-j'), it seems
 (to me) more logical to recenter that headline at the top of the screen (vs at
 the center of the screen, that is the current behavior).
 

Re: [O] Agenda in the mode-line?

[Daniel Clemente]

El Fri, 02 Aug 2013 09:59:55 -0500 Kyle Sexton va escriure:
 What I am after is more of a overview of How many total TODO tasks do I
 have, ideally with some function to limit or match based on tag.
 

  I manually run a script each day to update many things, one of them is 
exporting the agenda to a file. I can then use „wc -l“ to count the number of 
tasks and „grep“ to filter.
  The downside is that the file is usually outdated. But computing it at every 
change would be too slow.

Re: [O] org-odt-export-to-odt: hide text

[Daniel Clemente]

 
 You put your translation table in an org table, and there's a command to
 slurp that into a hashtable. The translation commands just whizz through
 the text and swap strings, basically. You can do subtree/region/file,
 tag subtrees to translate or not to translate, and there are interactive
 (a la query-replace) and noninteractive (for use as an export hook)
 versions.

  This is the usual gettext approach, which centralizes translations in a file 
(or table). When you change the original, your strings won't be found and you 
must update the translation table.
  I prefer the approach of having a phrase's translations together, so that you 
when you make a change you can update the translations from the same place.
  An overlay system in Emacs could show only „the current language“ and hide 
the others, then with some keys you could cycle through languages.
  I think this is something that can be done at an Emacs level (since it's for 
any text file), and org can simply use it.

Re: [O] org-odt-export-to-odt: hide text

[Daniel Clemente]

El Sat, 6 Jul 2013 13:03:01 +0200 Suvayu Ali va escriure:
 
 If you or any other user wants this kind of feature, you have to come up
 with a syntax that is not intrusive and doesn't break basic Org
 features.
 

  I created such a syntax for normal text files [1] but have been struggling to 
port it to Org, mainly because of the „header“ concept.
  I want translatable content in headers and text inside headers but without 
ever having to distort the outline structure (e.g. duplicate headers, missing 
titles, …).
  I see two solutions:

  1)
  If only we had „part-of-line drawers“ we could annotate titles directly:

* @ENGLISH{Section 1} @SPANISH{Sección 1}
:ENGLISH:
Section 1 is in English
:ENGLISH:

:SPANISH:
La sección 1 está en español
:SPANISH:

** 123
etc. (more translatable content)
** 456

  2)
  We could do the same with a property which means „if drawer X is visible, use 
this property's value as the title of this section“. E.g.:

* the first section (this title isn't used)
  :PROPERTIES:
  :TITLE_ENGLISH: Section 1
  :TITLE_SPANISH: Sección 1
  :END:

:ENGLISH:
Section 1 is in English
:ENGLISH:

:SPANISH:
La sección 1 está en español
:SPANISH:

** 123
etc. (more translatable content)
** 456



  Just some ideas for anyone who has the time to come up with a multilingual 
export engine.


[1]: http://www.danielclemente.com/dislines/syntax.en.html

Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

[Daniel Clemente]

I had lost colors in some modes for some weeks (helm, wl) and yesterday with an 
updated org they came back. So for me it's fixed.

El Tue, 25 Jun 2013 22:01:43 -0400 Mike McLean va escriure:
 
 I pulled and tested around 8:00 AM EDT today (because I let myself get so far 
 behind on commits that I couldn't tell if a fix had been pushed or not) and 
 the problem still existed at that time.
 
 
 On Jun 25, 2013, at 11:52 AM, Bastien b...@altern.org wrote:
 
  Nicolas Richard theonewiththeevill...@yahoo.fr writes:
  
  Meanwhile, John Hendy reported that the issue is resolved for him, so
  maybe I notice the thread too late to be useful, otoh I don't see which
  commit solved the problem, so maybe luck is involved in his resolution.
  
  Well, I'm really curious to see if affected users can confirm it is
  solved... I didn't have time to fix it, and I'd be glad Luck did it
  for me!
  
  -- 
  Bastien
  
 
 

Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

[Daniel Clemente]

El Tue, 25 Jun 2013 21:42:39 -0500 John Hendy va escriure:
 
 On Jun 25, 2013 9:36 PM, Daniel Clemente n142...@gmail.com wrote:
 
 
  I had lost colors in some modes for some weeks (helm, wl) and yesterday 
  with an updated org they
 came back. So for me it's fixed.
 
 Do you have a #+setupfile  entry in your file?
 

I had a #+setupfile in 6 of the .org files that make up my agenda. In addition, 
I always did this:
  emacsclient -n --eval '(org-agenda-list)'
after opening emacs --daemon so that all files be opened and the agenda be 
prepared.

Re: [O] agenda: personal priority for today

[Daniel Clemente]

 
 You can now use M-up and M-down to move agenda lines around.
 This is for quick use only.  It is not persistent and the agenda
 will be reordered on next refresh.
 
  That's nice, thanks.

Re: [O] agenda: personal priority for today

[Daniel Clemente]

 
 ** TODO This task second
:PROPERTIES:
:Sorting:  5029662198291
:END:
 

  As others said, this should be view-based, because the order in one agenda 
can be different to the order in other agenda.
  Each agenda view has some identifier (e.g. the letter you use to open it: 
a, a, t, …). You could use this to store different orders (one for each 
possible agenda view):

 ** TODO This task second
:PROPERTIES:
:Sorting:  a10_t80_c1_mm10
:END:

  Or a simpler solution:
  To me it would still be useful to be able to move things around in the agenda 
view, with M-up, M-down, even if the order is lost when I kill the agenda! That 
can help me decide a good task order which I can memorise or write down 
somewhere.

Re: [O] OT, but not really: todays XKCD

[Daniel Clemente]

El Tue, 12 Feb 2013 19:28:24 +0530 Jambunathan K va escriure:
 
 I will give you one more attempt.  Try again.  See whether you can
 convince me.
 

  Wow, you like discussing! You would enjoy a debate association. I did it and 
I enjoyed very much, it's discussing only for its own sake.

  I suggest you a challenging exercise: correct facts /without/ causing a 
negative response from the list. It may be difficult but it's useful.

  In this way we will be able to focus discussions on more useful and relevant 
topics.

[O] format of the ID property in the new HTML exporter

[Daniel Clemente]

Hi,
  in ox-html.el there's a line with an assert (the only one):

   (assert (org-uuidgen-p path))


1.  I have some IDs like o5y98600aze0 which don't conform to that uuidgen 
format; they were created by early versions of org. Should only UUIDs be 
accepted as ID?
2.  I think the ID should be editable by hand to what you like, as long as they 
are unique. If you don't need to export it you don't need a CUSTOM_ID, and 
having both ID and CUSTOM_ID is not the simplest way.

  So I think that assert is too strict. My short IDs seem as good as the long 
UUIDs.

Re: [O] How to improve Org startup time?

[Daniel Clemente]

  Per chance, you did not forget to M-x compile ? ;)
 
 Good to remind me/us with that, but, once again, no, as I do not use compiled
 Org files. That way, I'm sure not to forget such recompile step -- which I
 would definitely do once in a while!
 

  If you are worried about speed, you should always byte-compile, because it's 
easy and byte-compiled code is faster.
  Just do a make after each git pull.

[O] different color for calculated cells in tables

[Daniel Clemente]

Hi, 

  I would like to easily view which table cells are calculated, that is, which 
values would be overwritten if I updated the table (C-u C-u C-u C-c C-c)
  We can use a different cell background color (maybe with overlays?) for the 
automatic cells, and the normal one for „manual entry“ cells.
  This coloring would happen on load and after each table update; no need to do 
it in real time.


  A table example:

| a |b |   percent |m | multiple |
|---+--+---+--+--|
|15 |  112 | 16.80 |2 | 33.6 |
| 2 |   15 |  0.30 |  2.1 | 0.63 |
|   1.2 |7 |  0.08 | 12.5 |   1. |
|---+--+---+--+--|
| max%→ | 16.8 | 5.727 |1 |0 |
#+TBLFM: 
$3=($1/100.0)*$2;%.2f::$5=$3*$4::@5$2=vmax(@-I$3..@I$3)::@5$3=vmean(@-I..@I)::@5$4=$35.2::@5$5=0

  The „automatic“ cells (and thus highlighted) would be: 16.80, 33.6, 0.30, 
0.63, 0.08, 1, 16.8, 5.727, 1, 0. But I had to look at the TBLFM to find 
it, and that's not easy.

  This is an idea, but the code's missing. A similar code exists for cell 
highlighting from the formula editor window (C-c '); this would help.


  Any comments on the difficulty of this?


Daniel

Re: [O] BBDB(3) or org-contacts

[Daniel Clemente]

Hi,

El Mon, 7 Jan 2013 21:03:24 +0100 Gour va escriure:
 of bbdb-to-org-contacts converter wrote: Once I point org-contacts at
 my newly generated file containing 831 records it make org-contacts
 really really slow down. I wouldn't care about the normal record
 searching process for just looking something up, but it makes loading a
 message in gnus unusable (5 second delay per message).
 

  I use org-contacts with Wanderlust and I see it makes contact completion very 
slow (5 seconds for each keypress, and that's with only 200 contacts).
  Therefore I use its infrastructre (because I like it) but I don't run its 
code. I'll explain myself:

  I keep this structure in an .org file:

** John von Neumann 
:mathematic:
   :PROPERTIES:
   :EMAIL:  j...@neumann.com
   :END:
- some info


  I use tags, I store e-mails, and I can write any infos, subsections, 
appointments, tasks, etc. which I want; even clock in.
  If I want to search for a contact, I simply open that buffer and use C-s or 
do a tags search.
  You can use org-capture to fill that file.


  I strongly prefer this system over BBDB.


Greetings,
Daniel

Re: [O] A mail client that is org-mode compatible

[Daniel Clemente]

  I use Wanderlust and can make links from org just fine.

  I used gnus from 2008 to 2010 but could not make it work as I wanted. It 
seemed to value some things that I didn't (e.g. scoring, splitting, NNTP-style 
everywhere) whereas it didn't shine in other areas I needed (e.g. multiple SMTP 
servers, usability). Wanderlust was working perfectly since the first moment, 
and didn't require hacking, just configuration.

  Wanderlust is primarily an e-mail reader (IMAP, POP, Maildir, MH, …) but it 
can read NNTP natively, and some people also read RSS with it: 
http://www.emacswiki.org/emacs/HOWTOReadFeedsInEmacsViaEmail

  So that's my bet.

Daniel
El Mon, 31 Dec 2012 08:29:12 +0100 Gour va escriure:
 […]
 
 Afaict, there is no support in orgmode for Claws mailer which I use for
 regular email, mailing lists (mostly via gmane) as well as rss reader.
 
 is Gnus the only Emacs-based client which has good support for all of
 these as well as good support for orgmode?
 
 I'd also like to use Notmuch for quick searching and would fetch
 mail via getmail and use locally running dovecot for serving IMAP...
 
 Yesterday I read a bit about mu(4e), but it seems it handles only email
 and not nntp?
 
 
 Any hint?
 
 
 Sincerely,
 Gour
 
 
 -- 
 The embodied soul may be restricted from sense enjoyment, 
 though the taste for sense objects remains. But, ceasing 
 such engagements by experiencing a higher taste, 
 he is fixed in consciousness.
 
 http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
 
 
 

Re: [O] patch for org-contacts to ignore radio_marks when completing

[Daniel Clemente]

El Tue, 01 Jan 2013 23:57:27 +0100 Bastien va escriure:
 
 The function you introduced is used within `org-contacts-format-email',
 where using a bare name makes more sense IMHO.
 
  Exactly. It says:
(concat name   email )
  But name is John and you will get: John j...@email.com
  With the patch you get a bare name:  John j...@email.com
  So that new function should „clean“ the name: remove radio marks, emphasis, 
bold, etc. I did only radio marks..


  I also don't know org-contacts very much, but it seems that 
org-contacts-format-email returns not only the e-mail, but also the name; it 
could be called org-contacts-format-name-and-email.

  Greetings

Re: [O] A mail client that is org-mode compatible

[Daniel Clemente]

El Tue, 01 Jan 2013 23:14:19 + Richard Riley va escriure:
  (gnus)
 
 Multiple smtp servers are well supported for quite a while now.
 
  Yes, I used it, but it was not an elegant solution. Just look at how much 
information you need to make it work; it's frightening: 
http://emacswiki.org/emacs/MultipleSMTPAccounts
  If there's a new way to do it, the wiki can be updated.

Re: [O] Using Org-mode file format for storing configuration data

[Daniel Clemente]

El Sun, 30 Dec 2012 19:04:25 +0100 Karl Voit va escriure:
 
 I plan to implement a new weblog system that parses Org-mode files
 and generates (static) HTML output. Yes, I am aware that there are
 other solutions out there but I do not like them for various
 reasons.[1]

  Nice! I also don't like existing solutions and I was thinking on writing some 
Python to do the export. But the complexities of exporting are so well resolved 
in elisp that it's much easier to invoke elisp code than to write your own in 
Python.


 
 So for my new system, I am thinking of using Org-mode files for
 writing (and parsing) the user-defined preferences.

  I happened to be thinking the same two days ago. I wanted a place for scripts 
to store data as key→value pairs: e.g. configurations, or observations (like: 
file count on ~). Normally I would use lots of small hidden files for that. Now 
I wanted a central registry.
  I thought of using some cache server, or a small NoSQL database, or a system 
monitor for observations (e.g. collectd), and of course, org-mode. In the end, 
I think I will stay with the many small files; it's much easier!
  

   - In Python I have to parse a basic sub-set of Org-mode format
 anyhow. An additional parser would be more work to do.

  Don't do it from scratch; there are already some parsers which work. I tried: 
https://github.com/bjonnh/PyOrgMode


 - Possible methods to store configuration/settings of a weblog system
   that scans Org-mode files to generate HTML:
   - in drawers: see below
   - in tables: see below
   - in tags: see below
   - other possibilities?
 
   From the ones you say, I prefer property drawers. It's the most DB-like and 
it's analogous to storing data (well, strings).
   You don't need all the table benefits (reordering, exporting, formatting, 
formulae, …).
   Nor the tags benefits (search, multiple tags, …)


 What do you think of this?
 Can you imagine a better way of storing key-value-pairs in Org-mode?
 
 My focus is user friendly maintenance and overview including in-line
 documentation of the preferences.

  Of course, storing configuration in .org is very utopic (being all .org), but 
I would prefer *not* to do it. I would use a simple ~/.file.conf with some 
variables in the usual style:

# a comment
path=~/web/
# where to export images
images=~/web/images


  I think this wins for usability and „friendly maintenance“, since people know 
it and it works. And it allows you to define many projects (e.g. check the 
configuration file for the program unison).

  There are even libraries to parse these simple files: 
http://docs.python.org/2/library/configparser.html

  And if you want to design an equivalent grammar for configuration files 
(beware! that's another adventure!), check http://augeas.net/ . It can 
manipulate configuration files in a format-agnostic way.


  But I think it's more important to center efforts in developing a good 
exporter web publisher. As you said, the current ones are not powerful enough.

  Good luck.

[O] patch for org-contacts to ignore radio_marks when completing

[Daniel Clemente]

Hi, I send a patch which allows org-complete to complete if you do „J o h n 
TAB“ even if your contact was written as John (now you would have to type 
   J TAB).
  It can be extended to remove emphasis, strongs, etc. if someone needs it.

Thanks


diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el
index 7e3cbb7..0173f1d 100644
--- a/contrib/lisp/org-contacts.el
+++ b/contrib/lisp/org-contacts.el
@@ -388,12 +388,17 @@ This function should be called from 
`gnus-article-prepare-hook'.
   (org-completing-read
prompt (org-contacts-filter) predicate t initial-input hist def 
inherit-input-method))
 
+(defun org-contacts-format-name (name)
+  Format a person name to remove radio marks.
+  (replace-regexp-in-string org-radio-target-regexp \\1 name)
+  )
+
 (defun org-contacts-format-email (name email)
   Format a mail address.
   (unless email
 (error `email' cannot be nul))
   (if name
-  (concat name   email )
+  (concat (org-contacts-format-name name)   email )
 email))
 
 (defun org-contacts-check-mail-address (mail)

[O] radio target: stopped working

[Daniel Clemente]

Hi,
  in the latest org-mode and emacs (both compiled today), global radio targets 
like this one are colored as such and work, but this one is not 
detected, because there's a comma after the 

  I used bisect to find where it stopped working and got to:

ce8819f18d9d2be000fb70fc4d74b5d96fe07a83 is the first bad commit

  This was about org-element and included something for radio; maybe it 
needs tests for radio too.


Regards

[O] [PATCH] initialize level in org-agenda-format-item

[Daniel Clemente]

When I used %l in org-agenda-prefix-format, my agenda failed with:

Debugger entered--Lisp error: (args-out-of-range 0 0)
  get-text-property(0 extra-space nil)
  (concat level  (get-text-property 0 (quote extra-space) level))
  (if (equal level )  (concat level  (get-text-property 0 (quote 
extra-space) level)))
  (format %s (if (equal level )  (concat level  (get-text-property 0 
(quote extra-space) level
  …

It was due to „level“ being nil. The (if (equal level )) did not run because 
level was nil and not .
So I set it to  and it worked:


diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 9e2380b..a8b009c 100755
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6038,7 +6038,8 @@ Any match of REMOVE-RE will be removed from TXT.
 (t ))
  extra (or (and (not habitp) extra) )
  category (if (symbolp category) (symbol-name category) category)
- thecategory (copy-sequence category))
+ thecategory (copy-sequence category)
+ level )
(if (string-match org-bracket-link-regexp category)
(progn
  (setq l (if (match-end 3)

Re: [O] multilingual presentation with org

[Daniel Clemente]

El Wed, 15 Feb 2012 13:33:49 +0530 Rustom Mody va escriure:
 
 Now I am exploring how I could 'zip' the two together. My requirements are 
 like this:
 
 Any thoughts/suggestions?
 

  I made a small markup language which lets you write it in this way:


---
A song in English and Sanskrit:

@en bhaja govindam bhaja govindam
@sa भज गोविंदं भज गोविंदं

@en govindam bhaja mUDhamate
@sa गोविंदं भज मूढमते

@en saMprApte sannihite kAle
@sa संप्राप्ते सन्निहिते काले

@en nahi nahi rakShati DukrinkaraNe
@sa नहि नहि रक्षति डुकृंकरणे

---


  You run it through a script and you obtain two files, one with all the @en 
and the other with all the @sa. The common text goes to both.
  The script is at http://www.danielclemente.com/dislines/index.en.html


  How to integrate this approach with org's outline… is a challenge. One header 
per language? One property per language? Inline headers?…



Daniel

Re: [O] sqlite3 in org-babel

[Daniel Clemente]

 Have you tried using a sqlite code block?  See ob-sqlite.el

  I didn't notice there were both ob-sql and ob-sqlite. It would be useful to 
mention sqlite inside ob-sql.
  Perhaps they should be united?


  I still prefer ob-sql for sqlite because it lets me pass the parameter :init 
/dev/null. That makes it NOT load my ~/.sqliterc (where I have a very verbose 
.tables). ob-sqlite does not have :init and therefore always stuffs that 
output into the results.



 
 Daniel Clemente n142...@gmail.com writes:
 
  Hi,
 org-babel works well with sqlite3 if you add this (which I propose for 
  inclusion):