[O] electric-pair, autopair, smartparens, etc in org-mode

[Matt Price]

Hi eveyrone,

I'm just wondering what tools other people use to manage paired parentheses
and other markers in org.  I'm revisiting my long-ago decision to turn all
pairing tools off in org, but every tool I try is pretty frustrating out of
the box:

- smartparens steals a large number of really important structure-editing
commands from org-mode.  I find the default behaviour unusable.
- electric-pair and autopair complete [[ immediately, and don't seem to
allow me to skip past the closing brackets, so if I try to type [[
https://link.to.somewhere][link text]] I end up with
[[link.to.somewhere]][link-text] .

I'm willing to learn how to use these modes properly but I'm not quite sure
how best to proceed, so if someone else has a solution that works I would
be very grateful to hear it. thank you!

Re: [O] Bug: ox-odt.el should support text:start-value [9.1.14 (9.1.14-7-g01c419-elpaplus @ …/org-plus-contrib-20181015/)]

[Nicolas Goaziou]

Hello,

"Mark A. Hershberger"  writes:

> Nicolas Goaziou  writes:
>
>> Could you provide a patch using git format-patch, with a proper commit
>> message?
>
> Attached.  Also see
> .

Applied. Thank you.

>> Also, if you haven't signed FSF papers, please add TINYCHANGE at the
>> end of the commit message.
>
> I have signed papers on file.

Great. I added you to the list of contributors with signed FSF papers.

Regards,

-- 
Nicolas Goaziou

Re: [O] Why is ":CLOCK => hh:mm" allowed as a clock entry?

[Nicolas Goaziou]

Hello,

Marcin Borkowski  writes:

> I am studying the `org-clock-sum' function (I need to parse an Org file
> and extract clocking data), and I noticed that ":CLOCK => hh:mm" is
> allowed as a clock entry.  The Org syntax at
> https://orgmode.org/worg/dev/org-syntax.html#Clock,_Diary_Sexp_and_Planning
> confirms this.

  CLOCK:

and

  CLOCK: => hh:mm

are simply empty clocks.

> What is the rationale behind this?

Treating them as regular text would complicate parsing unnecessarily,
e.g., to determine when to stop a paragraph. 

There are other cases that can lead to odd clocks:

  CLOCK: INACTIVE-TIMESTAMP => HH:MM

where INACTIVE-TIMESTAMP is not a timestamp range.

> I want not only to sum the clocks (org-clock-sum does that, of
> course), but I want more detailed information (like how many clocks
> were that in the given period etc.). The format with only the duration
> makes this troublesome, and I'd like to ignore such entries (I have
> never seen them in my files, of course). I'm wondering what scenario
> could lead to their existence?

Hand-writing a clock information?

In any case, you can simply ignore them whenever you find them – which
shouldn't happen, right?

We can also add a checker in Org Lint for those problematic cases.

> BTW, the syntax draft says that there can be any TIMESTAMP object before
> the DURATION, but `org-clock-sum' assumes that its timestamps are
> inactive.  Isn't that a bug?

This is an oversight. Clock timestamps must be inactive. I will fix it.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: ox-beamer add label when option 'allowframebreaks' setted in org-beamer-frame-default-options [9.1.14 (9.1.14-7-g01c419-elpaplus @ .emacs.d/elpa/org-plus-contrib-20181015/)]

[Nicolas Goaziou]

Hello,

Héctor Enríquez Ramón  writes:

> Latex beamer not allow 'label=' when 'allowframebreaks' setted in frame.
>
> In file ox-beamer.el function org-beamer--format-frame search
> 'allowframebreaks' option inside beamer-opt but not inside variable
> org-beamer-frame-default-options. Then insert 'label=..' with
> 'allowframebreaks' and latex hide continuation's frames.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] Org source block header argument :var does not support space separated string

[stardiviner]

Org source block header argument :var does not support quoted string with space 
separator like bellowing example:

For example

 encrypt text -- ~<<< [TEXT]~

#+NAME: base64 encrypt text
#+begin_src sh
base64 <<< "stardiviner "
#+end_src

#+RESULTS: base64 encrypt text
: c3RhcmRpdmluZXIgPG51bWJjaGlsZEBnbWFpbC5jb20+Cg==

 decrypt text -- ~-d~

#+begin_src sh :var encrypted="base64 encrypt text"
# base64 -d <<< c3RhcmRpdmluZXIgPG51bWJjaGlsZEBnbWFpbC5jb20+Cg==
base64 -d <<< $encrypted
#+end_src

If I use #+NAME: base64-encrypt-text and :var encrypted=base64-encrypt-text, 
then it works fine.

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

Re: [O] How to make agenda generation faster

[Nicolas Goaziou]

Hello,

Adam Porter  writes:

> Yes, because this is the fastest way to search for matching entries in a
> buffer, when it's possible to use a regexp search.

You would still do regexp searches, but not at the time of queries.

> That would be ideal. The problem I foresee is that, when a buffer's cache
> is not up-to-date, and the user runs an agenda query, the user will have to
> wait for the buffer to be parsed and cached, which is much slower than a
> regexp search through the buffer.

No, because filling cache is still a regexp search.

> That was what I first tried with org-agenda-ng: I parsed the whole buffer
> with org-element and ran predicates against the element tree.

Org Element is not needed, and even shouldn't be used, to retrieve most
agenda related data.

There are exceptions of course, mainly plain timestamps and clocks. This
is where the current agenda is hard to beat, because 1. it cheats and
includes timestamps without checking context, 2. it only searches for
timestamps related to the day being displayed in the agenda view. The
last point makes it particularly fast for single day views.

> Another idea I've had, similar to yours, would be to pre-process buffers,
> adding metadata as text-properties on heading lines. However, I haven't
> tested it, and I don't know what the performance would be like. And it
> would still suffer from the caching problem I mentioned.

It is still a way to cache stuff. The difficulty here is to keep data
up-to-date with changes. Storing per-node cache could be nice,
nevertheless.

> I think the fundamental problems are 1) keeping the cache in sync with the
> raw buffer,

Yes, whole buffer caching is simpler here: drop all cached data if
buffer contents differ from the cached one. That's what I did in may
last attempt to speed up agenda, comparing md5sums. It works reasonably
well.

I also cached per agenda data type (schedules, deadlines, clocks…) but
that means you know something about the query. I think querying and
searching should be separated should it shouldn't be done.

> and 2) the slow speed of parsing an entire buffer's metadata at
> once (depending on the size of the files, of course, but mine are big
> enough to be slow, and I'm sure many users have larger ones).

I think this could be solved by fetching data preemptively during idle
time. I would also work well with per-node caching, since you can
interrupt fetching easily.


Regards,

-- 
Nicolas Goaziou

[O] (no subject)

[stardiviner]

Org source block header argument :var does not support quoted string with space 
separator like bellowing example:

For example

 encrypt text -- ~<<< [TEXT]~

#+NAME: base64 encrypt text
#+begin_src sh
base64 <<< "stardiviner "
#+end_src

#+RESULTS: base64 encrypt text
: c3RhcmRpdmluZXIgPG51bWJjaGlsZEBnbWFpbC5jb20+Cg==

 decrypt text -- ~-d~

#+begin_src sh :var encrypted="base64 encrypt text"
# base64 -d <<< c3RhcmRpdmluZXIgPG51bWJjaGlsZEBnbWFpbC5jb20+Cg==
base64 -d <<< $encrypted
#+end_src

If I use #+NAME: base64-encrypt-text and :var encrypted=base64-encrypt-text, 
then it works fine.

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

Re: [O] Org source block header argument :var does not support space separated string

[Nicolas Goaziou]

Hello,

stardiviner  writes:

> Org source block header argument :var does not support quoted string with 
> space separator like bellowing example:
>
> For example
>
>  encrypt text -- ~<<< [TEXT]~
>
> #+NAME: base64 encrypt text
> #+begin_src sh
>
> base64 <<< "stardiviner " #+end_src
>
> #+RESULTS: base64 encrypt text
> : c3RhcmRpdmluZXIgPG51bWJjaGlsZEBnbWFpbC5jb20+Cg==
>
>
>  decrypt text -- ~-d~
>
> #+begin_src sh :var encrypted="base64 encrypt text"
> # base64 -d <<< c3RhcmRpdmluZXIgPG51bWJjaGlsZEBnbWFpbC5jb20+Cg==
> base64 -d <<< $encrypted
> #+end_src
>
> If I use #+NAME: base64-encrypt-text and :var
> encrypted=base64-encrypt-text, then it works fine.

I cannot reproduce your issues, literally. It complains about
a redirection error or something.

Anyway, I tried the following block:

#+begin_src emacs-lisp :var encrypted="base64 encrypt text"
encrypted
#+end_src

and the output is

#+results:
: base64 encrypt text

which means there doesn't seem to be a problem with strings within
quotes.

Regards,

-- 
Nicolas Goaziou

[O] Styling header stats for collapsed trees

[Daniele Nicolodi]

Hello,

there is a feature of Orgzly that I like: when a headline containing
sub-haedlines is folded, the leading star (bullet in Orgzly interface)
changes to signal that subheadings are hidden below.

I've tried to see if org allows to easily achieve something similar, but
the face of the headline and of the stars do not change when the
headline is collapsed.

Does anyone have a hint about something to hook upon to implement
something like that?

Thank you.

Cheers,
Dan