Re: [O] org-drill extremely slow with Org 9.2.5

[Oleh Krehel]

Hi Milan,

> Are there any tricks to speed it up?

I noticed org-drill being slow three years ago when I tried to learn it.
So I wrote my own package: https://github.com/abo-abo/pamparam/.
It's quite fast: it takes 0.6s to sync my 3300 cards from the master Org file.
And day-to-day learning operations like building a schedule or
fetching a card are instantaneous.
The master file is relatively small, since it stores no metadata: less
than 1 lines.
The metadata is stored per-card, each card is in its own file. The
whole thing is backed by Git.
All your learning sessions are stored in commits as well.

Check it out. It might have less features, but it's really fast and
has served me well.

regards,
Oleh

Re: [O] do you need a separate LaTeX installation to export org mode files to pdf?

[Oleh Krehel]

Hi all,

>> Would they need to install LaTeX too, or is org mode self-contained and
>> able to export to pdf without LaTeX an friends installed?
>
>
> Yes, they'd need to have a LaTeX distribution installed on their system. In
> my experience, installing the full latest version of TexLive is the easiest
> way.

For years, my approach was to install texlive-full. But that meant
blocking me for around 2 hours.

Recently, I threw together a minimal Dockerfile to enable org-to-pdf
export. Here's the gist of it:

FROM ubuntu:xenial
RUN apt update && apt install -y software-properties-common
RUN apt install -y texlive-latex-extra cm-super

I also install Emacs and some project specific stuff on top of it. In
the end, the built Docker image is only 2.19GB.
If you don't care for Docker, you can just install the above minimal
packages with sudo.

regards,
Oleh

Re: [O] Ediff org files starts folded

[Oleh Krehel]

Here's what I use:

(defun ora-ediff-prepare-buffer ()
  (when (memq major-mode '(org-mode emacs-lisp-mode))
(outline-show-all)))

(add-hook 'ediff-prepare-buffer-hook 'ora-ediff-prepare-buffer)

regards,
Oleh

Re: [O] [RFC] New "kbd" macro?

[Oleh Krehel]

> Copying Oleh, as I believe he would also have some interest in this.

Thanks for the info. I still prefer to denote keys as ~C-x C-f~, and
code as =forward-char=:
1. It looks good in text.
2. It looks good on Github/Gitlab render.
3. It still exports as C-x C-f for HTML, and @kbd{C-x C-f}
for Texinfo.

See for example:
https://github.com/abo-abo/swiper/blob/master/doc/ivy.org#writing-this-manual

regards,
Oleh

Re: [O] Firefox extension "Org-capture" stopped working after update

[Oleh Krehel]

Same happened to me.

Downgraded Firefox on Ubuntu 16:

apt-cache show firefox | grep Version
sudo apt install firefox=45.0.2+build1-0ubuntu1
sudo apt-mark hold firefox

Next, about:config / xpinstall.signatures.required:=false.

Finally, install 0.3.0.xpi from the website.

There's an alternative addon that installs without a downgrade. But
that one doesn't seem to work.

regards,
Oleh

On Wed, Aug 16, 2017 at 2:58 PM, Marcin Borkowski  wrote:
> Hi all,
>
> the title text says it all.  Anybody can confirm that?  How to configure
> capture in FF now?
>
> TIA,
>
> --
> Marcin Borkowski
>

[O] Commit "org-agenda: Support for dimming..." breaks agenda display

[Oleh Krehel]

Hi all,

I updated Org recently and noticed that the agenda display looks very
broken, especially in `org-agenda-log-mode'.

I did a bisect; reverting commit
912a385518bcf2e320cc161d573ad329111de6c7 fixes it.
Anyone else have this problem?

regards,
Oleh

Re: [O] New package: ox-minutes [Please critique]

[Oleh Krehel]

Kaushal Modi  writes:

> Hi all,
>
> I have never published a package. I generally write elisp snippets embedded 
> in my config.
>
> Here are my first attempts at a 'package' and defining a custom org
> export backend.

Congrats on your first package! It will surely come in handy when
interacting with my less Emacs-enlightened colleagues. I recall one of
them writing very similar-looking notes in Microsoft Outlook. One or two
times I had to send them some notes, I actually did by hand the
transformation that `ox-minutes' now does.

> I would love to get criticism on this... What did I miss? Bad coding
> practices?

The coding looks fine. Just a suggestion: I think "\n" looks better than
a literal string newline.

It would be cool to have a regression test with:

./ox-minutes/ox-minutes-test.el
./ox-minutes/test_input.org
./ox-minutes/test_output.txt

Both test_input.org and test_output.txt could be moved from README.md.

regards,
Oleh

Re: [O] Is it possible to keep /all/ the heading properties in one place?

[Oleh Krehel]

Nicolas Goaziou  writes:

> Some users complained, and told me that "Org is not a programming
> language". Fair enough. Org has, indeed, to strike a balance between
> structure, required for efficiency and maintainability, and sloppiness,
> needed when you want to quickly jot down notes in a document, or simply
> let your ideas flow as you type, without hindrance.

Simply the headline structure is enough for all of this. The rest, like
properties, tags and logging can be made more rigorous.  For instance,
the current tags implementation implies the illusion that they can be
manipulated by hand. However, in practice it's frustrating to align
them.

>> Suggestion, and I've said it before, Org needs a standard simple inline
>> kbd markup. Just like Markdown's  and Texinfo's @kbd{}.
>> Since Org is tied into Emacs having an easy (and unambiguous) way to
>> denote keyboard shortcuts would be very convenient.
>
> This is export back-end specific. Org has no use for a "kbd" markup.

I really disagree here. The very first thing I did used Org for was
jotting down the Emacs key bindings that I wanted to remember.  Not
being able to distinguish the key bindings from symbols removes from the
markup's expressiveness.

For example, some people write like this:

~M-x forward-char~ or ~C-f~

while I write like this:

~M-x~ =forward-char= or ~C-f~

As long as only I read my own documents, my notation isn't a
problem. But if I share it with someone else, they will have to get used
to my non-standard notation.


>> Adding that would also progress the direction of having Org be the
>> language for Emacs manuals. Right now, Org's own manual is in Texinfo,
>> which is a shame since no one likes Texinfo and few people understand
>> enough of it to get by.

> Org can export to Texinfo. It can be helpful for those not understanding
> well enough the latter.

Org can export to Texinfo. But not well enough to be able to write Org
manual in Org.

That was my point. To be able to write a manual as rich as any existing
one, with only Org's built-in markup, i.e. without a tonne of export
specific #+TEXINFO or #+HTML includes.

I made some progress towards this goal with some custom code for
ivy.org -> ivy.html + ivy.texi export:
https://github.com/abo-abo/swiper/blob/master/doc/ivy-ox.el.

I made use of my own kbd markup that I wrote once in Org, but exported
the same both to Texinfo and HTML (see e.g. 
http://oremacs.com/swiper/#key-bindings).

regards,
Oleh

Re: [O] Is it possible to keep /all/ the heading properties in one place?

[Oleh Krehel]

Nicolas Goaziou  writes:

> So is Lisp.

I like Lisp.

> It boils down to ask users to write Lisp by hand at some point. Not
> everyone wants to use interactive tools.

I claim that a user can get by without having to write a single line of
Lisp manually. M-x `customize' has been doing it successfully for years.

> Unfortunately, writing Lisp is not fun in a basic text editing
> environment.

Right, not in a basic one. But it's great in Emacs. And for others, they
could use `read' followed by a graphical tool like a TreeView widget,
followed by `prin1'. This Lisp is supposed to be so simple that a
`read'->`delete-sexp'->`prin1' is an `identity' operation.

> Here is the full Org property syntax:
>
> 3.7 Property Drawers
> 
>
>   Property drawers are a special type of drawer containing properties
>   attached to a headline.  They are located right after a [headline] and
>   its [planning] information.
>
>   ┌
>   │ HEADLINE
>   │ PROPERTYDRAWER
>   │ 
>   │ HEADLINE
>   │ PLANNING
>   │ PROPERTYDRAWER
>   └
>
>   PROPERTYDRAWER follows the pattern
>
>   ┌
>   │ :PROPERTIES:
>   │ CONTENTS
>   │ :END:
>   └

Missed out the logging drawer and the tags. That's two things more out
of a single place than I'd like.

> I don't think this is very impressive nor particularly difficult to
> implement.

I get a headache just trying to imagine how I could hide the properties
/and/ the logging /and/ the tags into a single fold-able thing.

> You may want to have a look at "outline.el", which is Org without all
> the extra "stuff".

Already have been using it for years. I actually prefer outline.el to
org-babel for most things now. But not for GTD - for that I need Org.

> Alas, the Devil is in the detail:
>
>   (example
>...
>(properties ...))

Not really. You see, the `beginning-of-defun' trick is: a defun is a
thing that starts in the first column (that's why we escape all parens
in the first column in Elisp). This trick has been working successfully
for decades. It's both fast and simple.

Since all Lisp properties are written to programmatically by Org, they
are always perfectly indented. And if a person wants to edit it
manually, he'll have to simply remember to `indent-sexp'.

> Anyway, at this point I don't know what to add.

Suggestion, and I've said it before, Org needs a standard simple inline
kbd markup. Just like Markdown's  and Texinfo's @kbd{}.
Since Org is tied into Emacs having an easy (and unambiguous) way to
denote keyboard shortcuts would be very convenient.

Adding that would also progress the direction of having Org be the
language for Emacs manuals. Right now, Org's own manual is in Texinfo,
which is a shame since no one likes Texinfo and few people understand
enough of it to get by.

> You want to improve Org and this is fine. However simplistic examples
> do not help understanding the full picture, at least for me. So,
> implement your idea, test the syntax, ask for feedback here. In the
> end, if it happens to be superior, users will naturally switch to it,
> for the benefit of everyone.

Thanks, I'll be trying that out. In the last week I've been archiving
most of my gtd.org. So the switch should be easier now.

Do we have a way in Org to archive a heading form anywhere into a memoir
format like this:

* 2014
** 2014-01 January
*** 2014-01-03 Thursday
 CANCELLED Foobar
CLOSED: [2014-01-03 Fri 09:42] SCHEDULED: <2013-12-25 Wed>
Added: [2013-08-08 Thu 17:38]
 DONE Baz
CLOSED: [2014-01-03 Fri 17:12]

Each heading is archived into level 4, on the day it was closed.  I had
it working a few years ago, relying on org-archive.el. But when I tried
this week, it stopped working, so I had to rewrite it.

> You may also want to have a look at Skribilo
> (http://www.nongnu.org/skribilo/), if you don't know it already.

Thanks, I didn't know about it. It looks very similar to Racket's
Scribble, and my own ElTeX.

Re: [O] Is it possible to keep /all/ the heading properties in one place?

[Oleh Krehel]

Nicolas Goaziou  writes:

> I do not feel like asking users to write directly the AST for their
> plain text documents, really.

It's not an AST though. It's simply nested lists. Like JSON or XML but
better. And the idea is to both have it automatic and manual. For
example, `org-set-property' would work exactly as it does right now -
interactively. But on the programming level it would use `read',
`delete-sexp', `plist-put' and `prin1'. Isn't it much better to defer
all the heavy lifting to the Elisp reader?

Additionally, LISP readers are readily available outside of Emacs.  It
would ease other projects' Org-mode integration. Like mobile apps,
taskwarrior, github, whatever - the people would be able to parse and
modify Org with simply:

import lisp_reader

instead of grokking the full Org property syntax and all if its oddities
and idiosyncrasies. Because the basic Org heading structure is genius
simple. It's all the extra "stuff" than drags it down in terms of
simplicity.

> Parsing an Org document is a solved problem. I do not pretend the
> solution cannot be improved, but at least, it is complete.

Just like reading LISP is a solved problem. And not just in Emacs.

> I'm not sure about your motivations. If they are about reducing visual
> clutter, you can work it out at the display level. I'm pretty sure this
> improvement would be appreciated.

The motivation is to have Org look simpler by virtue of /being/ simpler.
Compare (require 'org-element) and hours of grokking it and looking up
docs to simply:

(defun all-props ()
  (save-excursion
(goto-char (point-min))
(let (props)
  (while (re-search-forward "^(properties" nil t)
(goto-char (match-beginning 0))
(push (read (current-buffer)) props))
  (nreverse props
(mapcar (lambda (p)
  (assoc 'deadline (cdr p)))
(all-props))
;; =>
;; ((deadline "<2016-02-26 Fri 17:00 +1w>") nil)

Re: [O] Is it possible to keep /all/ the heading properties in one place?

[Oleh Krehel]

Nicolas Goaziou  writes:

> Because not everything is a node property.

This shouldn't prevent us from keeping things that /are/ node properties
all in one place.

> TODO keywords, tags and properties are all different, and blurring the
> distinction between them would not make Org easier. Note that Org
> doesn't force you to use any of them.

I would most definitely make Org easier in some respects. Suppose a
person wants to parse an Org file's content, just for displaying it on a
website (like Github does right now). If all properties were in a single
place, they could be trivially skipped with a regex, resulting in an
almost ASCII-like export of the Org file.

> CLOCK cannot be located within PROPERTIES drawer because it not
> a key-value association. You can have multiple clocks with different
> values.

:LOGBOOK: could be the key, and all of its contents would be the value.
Same thing with putting :TAGS: into :PROPERTIES:.

> SCHEDULED and DEADLINE could have been moved within PROPERTIES drawer.
> It was even discussed a couple of times on this ML. However, Carsten
> decided to keep them separated, mainly because such an important
> information should not be hidden in the document, in particular for
> newcomers. I still agree with him.

Could we have an option to customize this? Just declare a standard
getter and setter interface for :SCHEDULED: and :DEADLINE:. I'll
customize them in my config to put them in the :PROPERTIES: drawer.

Here's another idea for the :PROPERTIES: drawer that might make things a
lot less hairy - make it fully in Lisp:

(properties
 (scheduled [2016-02-25 Thu])
 (id ca23d969-d189-4d38-aee3-aa21feb5b305)
 (logbook
  (clock [2016-02-25 Thu 15:03])
  (clock [2016-02-25 Thu 14:33] [2016-02-25 Thu 14:58])
  (clock [2016-02-25 Thu 13:24] [2016-02-25 Thu 13:49]))
 (added [2016-02-25 Thu 11:24]))

I think it would greatly enhance the parsing of Org files, and simplify
many functions in org.el. With this, a simple `read' will suffice to
parse all the stuff.

Re: [O] Is it possible to keep /all/ the heading properties in one place?

[Oleh Krehel]

Nicolas Goaziou  writes:

>> Here's a list of the diverse things that I'd like to hide into
>> :PROPERTIES:
>>
>> - Tags - there are always a pain to re-align, they show up as diffs in
>>   git commits
>> - The clock entries - they are stored in a :LOGBOOK:, separately from
>>   :PROPERTIES:
>> - The :SCHEDULED: and :DEADLINE: time stamps
>
> It is not possible to move these things into the properties drawer.

Why not? What's the barrier to doing this? I think it would not only
make the text files cleaner, but also the org.el code.

[O] Is it possible to keep /all/ the heading properties in one place?

[Oleh Krehel]

Hi all,

I've recently gotten back to reorganizing my Org setup. There are a few
things I find lacking, one of which is having all the auxiliary
information for a heading stored in a single place, that I can further
make less noticeable with `prettify-symbols-mode'.

(add-to-list 'prettify-symbols-alist
   '(":PROPERTIES:" . ":"))
(prettify-symbols-mode)

Here's a list of the diverse things that I'd like to hide into
:PROPERTIES:

- Tags - there are always a pain to re-align, they show up as diffs in
  git commits
- The clock entries - they are stored in a :LOGBOOK:, separately from
  :PROPERTIES:
- The :SCHEDULED: and :DEADLINE: time stamps
- I also have the "Added: ..." line from a recommended capture setup, I
  think it would be better placed in :PROPERTIES:

Is it possible to set up what I described above? Any pointers? Ideas to
do it better?

thanks,
Oleh

Re: [O] (message "Greedy org-protocol handler. Killing client.")

[Oleh Krehel]

Samuel Wales  writes:

> org-protocol works less than half the time now.
>
> i try it with the org-capture firefox extension on iceweasel.  i also
> try it with a manual bookmark created by some instruction somewhere.
>
> today every click puts this in my messages buffer:
>
> "Greedy org-protocol handler.  Killing client."
>
> could somebody please explain what this means?  i do not understand the code.

org-protocol works by advising `server-visit-files' in an obsolete way.
I encountered this problem this week when I tried to advice
`server-done' to do something clever with Itsalltext.  It seems the
`defadvice' on `server-visit-files' is incompatible with any other
advice in that vicinity. I would get "Greedy org-protocol handler.
Killing client." when I advised `server-done'. This error would
disappear immediately after I disabled the advice.

So I suggest examining your custom advises. And see if disabling some of
them fixes the problem.  And maybe someone could look into using
something better than `defadvice' in org-protocol.el.

Oleh

[O] Bug: Regression in ox-texinfo export

[Oleh Krehel]

At the current git master, the org source:

#+BEGIN_TEXINFO
@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with the Front-Cover Texts being ``A GNU Manual,''
and with the Back-Cover Texts as in (a) below.  A copy of the license
is included in the section entitled ``GNU Free Documentation License.''

(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and
modify this GNU manual.''
@end quotation
#+END_TEXINFO

results in the following .texi output:

@TEXINFO
@@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with the Front-Cover Texts being ``A GNU Manual,''
and with the Back-Cover Texts as in (a) below.  A copy of the license
is included in the section entitled ``GNU Free Documentation License.''

(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and
modify this GNU manual.''
@@end quotation
@end TEXINFO

This was done with `emacs -Q', no extra code except (require 'ox-texinfo).

Note that the above org source works fine with the built-in Org-mode:

@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with the Front-Cover Texts being ``A GNU Manual,''
and with the Back-Cover Texts as in (a) below.  A copy of the license
is included in the section entitled ``GNU Free Documentation License.''

(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and
modify this GNU manual.''
@end quotation

@c Emacs 25.0.50.4 (Org mode 8.2.10)

regards,
Oleh

Re: [O] Bug: Regression in ox-texinfo export

[Oleh Krehel]

Kaushal Modi  writes:

> The syntax change was announced in Dec last year:
> https://lists.gnu.org/archive/html/emacs-orgmode/2015-12/msg00525.html
>
> It is now
>
> #+BEGIN_EXPORT backend
> #+END_EXPORT

Thanks, Kaushal. I wasn't aware of the change.

I assume that #+TEXINFO: and #+HTML: one-line blocks remain unchanged?

Oleh

Re: [O] Why does evaluating a piece of Elisp code seemingly not expand a macro?

[Oleh Krehel]

Marcin Borkowski  writes:

> Why?

Macro-expand the defun to get:

(defalias 'print-answer
#'(lambda nil
(message
 "The answer is %s."
 (forty-two

`lambda' is a macro that /quotes/ its body. Therefore, the body of
`defun' is not evaluated or expanded when it's defined.

You probably wanted something like this instead:

(macroexpand-all
 '(lambda nil
   (message
"The answer is %s."
(forty-two
;; =>
;; (function
;;  (lambda nil
;;   (message
;;"The answer is %s."
;;42)))

Which could be wrapped in a new macro:

(defmacro defun-1 (name arglist  docstring  body)
  (unless (stringp docstring)
(setq body
  (if body
  (cons docstring body)
docstring))
(setq docstring nil))
  (list 'defun name arglist docstring (macroexpand-all body)))

The above seems to work, at least superficially:

(symbol-function
 (defun-1 print-answer ()
   (message "The answer is %s." (forty-two
;; =>
;; (lambda nil
;;   (message
;;"The answer is %s."
;;42))

By the way, it might be more appropriate to ask similar questions on
help-gnu-em...@gnu.org.

Oleh

[O] Need some help in customizing ox-texinfo

[Oleh Krehel]

Hello,

I'm exporting an Org-mode document to Texinfo currently, but I'm having
an inconvenience with production of @subsubheading items.

What I'm doing right now:

#+BEGIN_TEXINFO
@subsubheading 
#+END_TEXINFO


What I would like to have instead:

* :@subsubheading


And have it export to the same thing. I didn't find an easy way to do
it, since this requires embedding the content of a headline into the
parent headline. What I've got so far is adding this code to
`org-texinfo--normalize-headlines':

(org-element-map tree 'headline
(lambda (hl)
  (when (member "@subsubheading" (org-element-property :tags hl))
(setcar (nthcdr (cl-position hl (org-element-property :parent hl))
(org-element-property :parent hl))
(cons `(paragraph
()
,(format
  "@subsubheading %s"
  (org-element-property
   :raw-value hl)))
  (org-element-contents hl)
info)

It almost works, the only issue is that "@" is escaped later on and I
get "@@subsubheading" in the end. How can I fix that? Is there an easier
way to do this in general?

regards,
Oleh

Re: [O] Conditional link export?

[Oleh Krehel]

Aaron Ecay  writes:

> Extra elisp inside the org file is an important way of extending the
> power of org markup.  Why don’t you want to use it?

Including boilerplate Elisp, all subtly different into each markup
document, just to extend the markup with the syntax that it should have
in the first place anyway. Doesn't that sound bad to you?

One-off Elisp inclusions relevant to a single document are great and
powerful, but adding boilerplate code, usually more of it that the whole
sum of the markup, doesn't sound great at all.  This could be rectified
somewhat by using `require', but then we don't have a self-contained
document any more. Which is important to facilitate sharing and re-use
of Org-mode documents.

> Not in general.  For small pieces of text, you can use macros.
> Something like:
>
> #+macro: ifinfo (eval (if (org-export-derived-backend 
> org-export-current-backend 'info) "$1" "$2"))
>
> {{{ifinfo([[info:emacs#Pachages]],[[https://]])}}}

The macro definition and call syntax looks very ugly.
Why can't we add inline Elisp calls with the following rules:

1. Any amount of Elisp code can be embedded.
2. The result of the last expression is interpreted either as "%s" or
"%S" appropriately.

I tried this:

For more package manager details, see 
#+begin_src emacs-lisp :exports results
(defun ox-link (link  description)
  (cond ((equal org-export-current-backend 'html)
 (format "%s"
 link
 (or description link)))
(t
 link)))
(cond
  ((equal org-export-current-backend 'texinfo+)
   (ox-link "info:emacs#Packages"))
  (t
   (ox-link 
"https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;)))
#+end_src
.

Here are the problems that I see here:

1. The results aren't embedded and are instead quoted. Extra newlines
are added around the result.
2. Something like `ox-link' isn't built-in.
3. The boundaries are rather verbose, maybe "#+begin_src inline" or
something even shorter would look better.

I think fixing the above three issues would really improve Org-mode's
markup, make it much more powerful. We already have `org-edit-src-code'
which allows us to edit Elisp natively, it only remains to un-constrain
the results from being quoted in a  block, and provide the
standard API (e.g. `ox-link', `ox-src', `ox-tbl') that would work
for all export back ends.

Here's how my example would look, once the above changes are
implemented:

!(cl-case org-export-current-backend
   (texinfo+
(ox-link
 "info:emacs#Packages"))
   (t
(ox-link
 
"https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;)))

Now note that the above is meant to be exported inline, instead of into
a  block. If I wanted such a block, I would Paredit-wrap that
sexp with (ox-pre) - a very quick and simple modification.  And to
remove (ox-pre), simply Paredit-raise. Now this would be a powerful
markup indeed. One very important advantage is that each block can be
efficiently debugged in its native Elisp mode, maybe even ERT-tested,
because all API functions would be bound all the time, not just during
the export.

> Note that the solution I gave you allows the links to be clickable in
> the buffer, whereas a macro does not (sort of).

I think we should completely get rid of macros and simply use inline
Elisp, which is both more powerful and more simple.

> See, even you can’t resist putting elisp in.  :P  You could give the
> your pseudocode a #+name and then call it as an inline babel call.

The #+name thing is powerful because if I understood correctly it allows
to call /any/ language not just Elisp. As I mentioned above, I think
Elisp should be privileged and we should be able to call any bound Elisp
function inline without having to declare it.

>> 2. Does Org-mode support the kbd markup for denoting keyboard shortcuts?
>> I'm guessing that the answer is no, which is a shame since both Texinfo
>> and Github/StackExchange-flavored Markdown support it.
>
> No.  There was recently a thread on small caps syntax:
> 
> where many of the same themes come up.
>
> There’s not enough consensus at present to add any new markup types to
> org syntax.  Macros can be made to serve many of the same functions,
> though.

I see. I understand why Nicolas is reluctant to modify the actual syntax
for every small thing. And macros could indeed be a solution. My issues
with the macros are the following:

1. They're awkward to define.
2. They're awkward to call.

Using inline Elisp instead of macros would solve both problems.  The
first problem is solved by having a standard library e.g. ox-inline.el
bundled with Org. That would include, e.g. `ox-kbd'. Additionally the
users can write their own libraries and simply `require' them.

Here's how it might look like:

To install a 

Re: [O] Conditional link export?

[Oleh Krehel]

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Oleh Krehel <ohwoeo...@gmail.com> writes:
>
>> Is that a new feature?
>
> It is probably almost as old as Babel itself.
>
>> First time I've heard about it, and I did google
>> for inline code block evaluation before.
>
> You should check the Org manual first: 
>
>   (info "(org) Structure of code blocks")

OK, I was looking at
http://orgmode.org/manual/Exporting-code-blocks.html instead.


>
>> In any case, the HTML export result of e.g. this:
>>
>> The current time is: src_emacs-lisp{(format "%s"
>> "http://google.com; (format-time-string "%H:%M"))}.
>>
>> is:
>>
>> The current time is: a href"> href="http://google.com/;>http://google.com/"15:50/a=.
>>
>> which is far from what I want.
>
> Try
>
> The current time is: src_emacs-lisp[:results html]{(format " href=%S>%s" "http://google.com; (format-time-string "%H:%M"))}.

This is quite restrictive, since it implies that I want to export to
HTML. What I really want is to insert a raw string, with no further
processing into the export, whatever format the export may have.

>> And I still think that Elisp could benefit from privileged call
>> syntax. Compare:
>>
>> !(foo)
>>
>> to
>>
>> src_emacs-lisp{(foo)}
>
> I'm not a big fan of redundant syntax. Also, I'm trying to move Org
> format out of Elisp's grasp. This doesn't help much either.

I think it's better to have people use !(foo) than to be turned away by
src_emacs-lisp[:results html]{(foo)} and use nothing at all.  Besides,
Elisp is a very strong library for Org. We could also have e.g.

#+INLINE_LANG Elisp

to set the language for !() in the current document.

>> Additionally `org-edit-src-code' doesn't work for these blocks.
>
> Do you want to provide a patch for it?

I could provide a patch for `org-edit-src-code' to work with !().  I'm
not interested in using the current inline syntax.  I'll implement the
!(progn (foo) (bar)) style for my config anyway, then it's up to you
whether you'll want to merge it or not.

Re: [O] Conditional link export?

[Oleh Krehel]

Hi Nicolas,

Nicolas Goaziou  writes:
> There is already inline syntax for any language, including elisp:
>
>   src_emacs-lisp{(foo)}
>
> and, if you use the library of Babel,
>
>   call_foo{}
>
> I don't see the need to add yet another way to call inline code from an
> Org document.

Is that a new feature? First time I've heard about it, and I did google
for inline code block evaluation before.

In any case, the HTML export result of e.g. this:

The current time is: src_emacs-lisp{(format "%s" 
"http://google.com; (format-time-string "%H:%M"))}.

is:

The current time is: a href"http://google.com/;>http://google.com/"15:50/a=.

which is far from what I want.

And I still think that Elisp could benefit from privileged call
syntax. Compare:

!(foo)

to

src_emacs-lisp{(foo)}

No one would quickly forget the first call syntax after using it once,
while the second one is highly forgettable and clumsy.

Additionally `org-edit-src-code' doesn't work for these blocks.

regards,
Oleh

Re: [O] Conditional link export?

[Oleh Krehel]

Aaron Ecay  writes:

Hi Aaron,

Thanks for the effort, I might use the code you suggested as a last
resort:)

I think the issue here is extending the power of Org markup.

The task at hand is "Write a manual in Org that exports to both Texinfo
and HTML", preferably with zero config outside of the Org file itself.
Also preferably without any extra Elisp inside the Org file. Is Org-mode
suitable for the task?

Currently I have a few questions that I had trouble internet-searching:

1. Does Org-mode support export-based #ifdef #endif escapes? Here's what
I have currently:

You can read about ELPA in the Emacs manual, see 
#+HTML: https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;>(emacs)Packages.
#+TEXINFO: @ref{Packages,,,emacs,}.

Note that I'm getting an unwanted newline after "see" in case of HTML
export that I'd like to get rid of. Even if that problem is solved, it
still looks a bit clunky.

Is there a way to make something like this work instead?

#+begin_src elisp :inline
(cond
  (ox-htmlp
   (ox-html-link
"(emacs)Packages"

"https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;))
  (ox-texinfop
   (ox-texinfo-link
"info:emacs#Packages")))
#+end_src

2. Does Org-mode support the kbd markup for denoting keyboard shortcuts?
I'm guessing that the answer is no, which is a shame since both Texinfo
and Github/StackExchange-flavored Markdown support it.

Currently I've customized my Org to export =foo= as code, and ~foo~ as
foo. Could we have this or a similar markup as the built-in
default? Since Org-mode has so much to do with Emacs, having kbd tags
would be very convenient.  In some odd cases, ~foo~ wasn't working for
me and I've had to use @@html:@@"@@html:@@, which looks quite
ugly.

3. I really like http://orgmode.org/manual/index.html. How would I go
about producing something like that (i.e. where can I find the sources)?
Each time I've seen HTML export, it's always a single page. How to
export each heading to its own page and have them all linked?

4. Is Org-mode powerful enough to have all of Emacs' manuals re-written
in it, without any change in the final Info output?

regards,
Oleh

[O] Conditional link export?

[Oleh Krehel]

Hi all,

I'm writing a manual in Org-mode, with the intent to export both to
Texinfo and HTML. And I'd like to use this link for Texinfo:

info:emacs#Packages

and this link for HTML:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html

They both link to the same information, but in different browsers
basically. How could this be done? I'm thinking of something like:

#ifdef TEXINFO
[[info:emacs#Packages]]
#else
[[https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html]]
#endif

Oleh

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Kyle Meyer  writes:

>> As far as I understood, maint is a subset of master, i.e. all commits
>> that are in maint are in master as well. Is that correct?
>
> Yes.  As long as there aren't any new commits on maint that have yet to
> be merged

What is the purpose of maint exactly? In Emacs git repository there's
master and emacs24. All commits apply to master first, while some are
cherry picked onto emacs24. The emacs24 branch will never be merged into
master: it's divergent and that's fine.

As I understood, for Org mode some commits are applied to maint, and
then merged into master. Why?

Oleh

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Stefan Nobis <stefan...@snobis.de> writes:

> Oleh Krehel <ohwoeo...@gmail.com> writes:
>
>> Would it be so hard for Git to perform a single merge of master into
>> maint on release, while keeping them separate and cherry-picking
>> in-between for the sake of a clean linear history?
>
> The question is not whether git is capable of doing this (there are
> ways to accomplish this goal). The true question is: Do you really
> want a linear history?

Of course I do: it's prettier. My problem is that I don't see the
advantages that the other approach brings, I only see that it takes away
the prettiness.

> A linear history may look pretty, but at the same time you loose
> information. In a big complex project that is also a dependency to
> another complex project, a bit more ugly bookeeping may make
> maintenance easier.

Org's git history doesn't look complex at all: the commits are pretty
much synchronous and applied to master and maint at the same time.
Basically, Org's history is already linear, it's just hard to see it
behind the ugly bookkeeping.

Oleh

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Josiah Schwab  writes:

Hi Josiah,

>> As I understood, for Org mode some commits are applied to maint, and
>> then merged into master. Why?
>
> It may be helpful for you to do a some background reading on workflows
> with git.  Have you ever read the gitworkflows man page?
>
>   https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>
> This page discusses many of the questions you have raised.

Thanks for the link. I've read it, and it does make sense.  But making
sense doesn't make it more convenient. I can understand some feature
branch being merged, but is the workflow of applying a single commit to
maint and merging maint into master really the best that Git can offer?

Would it be so hard for Git to perform a single merge of master into
maint on release, while keeping them separate and cherry-picking
in-between for the sake of a clean linear history?  The easy way would
be to rewrite maint on each release, but perhaps Git can do better?

Oleh

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Achim Gratz <strom...@nexgo.de> writes:

> Am 11.09.2015 um 13:59 schrieb Oleh Krehel:
>> What is the purpose of maint exactly?
>
> It's a bit short on the explanation side, but does that help?
>
> http://orgmode.org/worg/dev/index.html

It does help a bit.

> Also (not exactly the branch model ORg uses, but explains the issues
> in more detail):
>
> http://nvie.com/posts/a-successful-git-branching-model/
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> http://williamdurand.fr/2012/01/17/my-git-branching-model/
>
>> In Emacs git repository there's
>> master and emacs24. All commits apply to master first, while some are
>> cherry picked onto emacs24. The emacs24 branch will never be merged into
>> master: it's divergent and that's fine.
>
> You might want to check your facts (most recently, see for instance
> commit 59db4308b546).  Realitity simply doesn't conform to your
> world-view and the conclusions you draw from it are similarly
> distorted. Cherry-picking from master to emacs24 is actually fixing a
> mistake made when committing a bug-fix to master.

Well, there are only 5 commits since the last tag in the emacs-24
branch, the top one being a cherry-pick. I don't really see harm in
them, there are more cherry-picks in that branch.

What exactly is the advantage of having 2 commits in master for 1 commit
in maint? Besides the ease of merging maint into master and master into
maint or release? This ease of merging comes at the cost of ease of
examining the master, which is where most of the work should be anyway.

Now, please check my facts again. Is it true that Emacs doesn't have
maint and has instead a bunch of hanging branches for each release that
aren't meant to have master merged into them on release? If so, what
exactly is the advantage in applying a patch to a stable branch and then
merging it into master, instead of applying to patch to master and
cherry-picking it to the stable branch?

I'm not saying that I'm a Git expert or anything, far from it. But I
observe the Git history of Emacs and Org regularly, and both models seem
to be working fine for the users, release-wise. But the master branch of
Emacs looks a lot better than the master branch of Org, and I don't
understand the trade-off that Org's model offers to compensate for that
lack of prettiness.

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Kyle Meyer <k...@kyleam.com> writes:

> Hello,
>
> Oleh Krehel <ohwoeo...@gmail.com> writes:
>
>> Hi all,
>>
>> Was the issue of abundant "Merge branch 'maint'" commit messages
>> discussed before? I couldn't find a reference...
>>
>> It's not a big deal, really, but I personally prefer to have linear
>> history with commits that actually do stuff. And it should be easy to
>> switch to this style: just use the "rebase" instead of the "merge"
>> command.
>>
>> Anyway, it's a small thing, and if Nicolas or Bastien strongly like the
>> merge method I won't bring it up again. But if they don't care either
>> way, I think it's better to start rebasing.
>
> While I'm all for rebasing unpushed commits, short-lived feature
> branches, and throw-away integration branches, your suggestion would
> frequently rewrite the history of a long-lived public branch.

Why not just cherry-pick the commits from master onto maint, or the
other way around? That would result in no merge commits.

I think it should be possible to rebase two branches without having to
rewrite the public history. As far as I understood, maint is a subset of
master, i.e. all commits that are in maint are in master as well. Is
that correct?

Oleh

[O] Merge branch 'maint'

[Oleh Krehel]

Hi all,

Was the issue of abundant "Merge branch 'maint'" commit messages
discussed before? I couldn't find a reference...

It's not a big deal, really, but I personally prefer to have linear
history with commits that actually do stuff. And it should be easy to
switch to this style: just use the "rebase" instead of the "merge"
command.

Anyway, it's a small thing, and if Nicolas or Bastien strongly like the
merge method I won't bring it up again. But if they don't care either
way, I think it's better to start rebasing.

Oleh

Re: [O] Is there a way to search for link target, not description?

[Oleh Krehel]

Marcin Borkowski  writes:

> Hi all,
>
> as in the subject.  So, when I have e.g. [[foo][bar]], C-s finds bar,
> but not foo.
>
> Any way to find foo without e.g. temporarily resorting to text-mode?

The `swiper' command can do this. Available in GNU ELPA. I haven't used
`isearch' for half a year now, only occasionally for testing.

Oleh

Re: [O] John's amazing indexing posts

[Oleh Krehel]

Hi Xebar,

Xebar Saram zelt...@gmail.com writes:

 i start using counsel and the counsel-recoll and is quite good, thx for this!
 a small Q. when i launch the command am i supposed to see the search term 
 inline (like in grep) or just the file name it
 resides in. currently i just see the filename that contains the search term. 
 example screenshot:
 https://paste.xinu.at/B77QYh/

You can't see the search term inline, only the file name.  Recoll
doesn't support inline context. It has support for abstracts, but they
are disjointed, as in not a full sentence, but a summary of
keywords. Showing those is a possibility, but at times it's just too
much information.

For instance, here's one candidate for input 'git':

text/plain  [file:///home/oleh/Dropbox/org/wiki/git.org][git.org]   
9921bytes   
ABSTRACT
title my git notes language en ... css articles done http git scm com
book en git branching branching workflows git branching workflows closed
2013 ... 22 00 done http git scm com book en distributed git distributed
workflows git distributed workflows closed 2013 ...
/ABSTRACT

I think the file name here is more relevant than the abstract, taking
into account that there are 59 other candidates, besides this one.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Hi Aaron,

Aaron Ecay aarone...@gmail.com writes:
 Besides, CC-BY-NC-SA is compatible with GPL! Compatible. With GPL.

 This isn’t correct.  -NC licenses are non-Free (in the FSF sense of the
 word): https://www.gnu.org/licenses/license-list.en.html#CC-BY-NC
 -SA licenses are Free, but not GPL-compatible, as indicated
 by the dashed orange line in the left-hand margin at:
 https://www.gnu.org/licenses/license-list.en.html#ccbysa

Thanks for clarifying. Maybe I should switch to CC-BY-SA instead.
Theoretically, I wouldn't want someone to simply mirror my blog and put
ads on it. But I guess it would be fine if a link to my blog is
provided, since then the reader is then aware of the option for ad-free
posts.

On the other hand, I wouldn't want to restrict anyone from significantly
building upon my content and making money from that.

--Oleh

Re: [O] Commit ceae5d651b80295f35c01ecfc53661c7e8eceba7 Breaks syncing with Android

[Oleh Krehel]

Hi Charles,

Charles Philip Chan cpc...@bell.net writes:


 Just want to let you know, this commit:

 ,
 | commit ceae5d651b80295f35c01ecfc53661c7e8eceba7
 | Author: Oleh Krehel ohwoeo...@gmail.com
 | Date:   Tue Jul 28 15:06:25 2015 +0200
 | 
 | lisp/org.el (org-set-tags): Simplify the code
 | 
 | * lisp/org.el (org-set-tags): Prefer let* to multi-variable setq,
 | ...skipping...
 | org-mobile: Tiny fix in creating index.org file
 | 
 | * lisp/org-mobile.el (org-mobile-create-index-file):
 | Eliminate cloning of `#+READONLY' property in the `index.org' file.
 | A sublists of `org-todo-keywords' don't need to contain the `|'.
 | 
 | TINYCHANGE
 `

 broke syncing with mobileorg on Android. After I revert to commit
 5f3d8037a5099ca92db7edbf95ced22f0adefbef everything was fine.


I'm pretty sure my commit isn't to blame  and you meant this one:

c15db80e32d22dace184203f6f03a0b586bb4b50
Author: Sergey Gordienko gordien...@gmail.com
Date:   Fri Jun 26 17:44:20 2015 +0300

org-mobile: Tiny fix in creating index.org file

* lisp/org-mobile.el (org-mobile-create-index-file):
Eliminate cloning of `#+READONLY' property in the `index.org' file.
A sublists of `org-todo-keywords' don't need to contain the `|'.

TINYCHANGE

--Oleh

Re: [O] John's amazing indexing posts

[Oleh Krehel]

Erik Hetzner e...@e6h.org writes:

 I believe that you can rewrite using the recoll tool directly instead
 of recollq, using `recoll -t -b 'search string'`:

 (defun counsel-recoll-function (string optional _pred rest _unused)
   Grep in the current directory for STRING.
   (if ( (length string) 3)
   (counsel-more-chars 3)
 (counsel--async-command
  (format recoll -t -b '%s' string))
 nil))

 If you use `recoll -A -t 'search string'` and do some post processing
 you could get snippets, too. I can’t see how to do that easily with
 counsel--async-command, though.

Thanks, Erik. I've merged your pull request. So now it's very easy to
start using recoll with Emacs - outside of Emacs the only necessary
thing is:

sudo apt-get install recoll

And inside Emacs it's:

package-install counsel

I did look into the annotation switch. The thing is that it just shows
some database aggregates instead of the actual line context, like grep
does. With 30 candidates and no line context, a pure list of files looks
simpler than a list of files and a list of out-of-sequence words that
each file contains.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Marcin Borkowski mb...@mbork.pl writes:

 As Oleh Krehel pointed out in a reply to another mail of yours, if your
 code links to org-mode code (or other GPL code) you cannot release it
 under a different license. I'm not sure about how linking is intended in
 Elisp sense of ('require)ing a library, but I believe it is analog to
 executable linking in machine code programs.

 I understand, and I thank you for your clarification.  (Though I still
 consider it plain ridiculous.  And the fact that Oleh's own blog is
 CC-BY-NC-SA licensed, and contains many fragments of Elisp code, both
 small snippets and whole functions, thus rendering it illegal, is
 sweet;-).)

I think posting snippets on a blog falls into Fair Use. As long as I'm
not posting something which is a full program, this is fine.  Besides,
CC-BY-NC-SA is compatible with GPL! Compatible. With GPL.

Quoting the SA (ShareAlike) part from the website:

 ShareAlike — If you remix, transform, or build upon the material, you
 must distribute your contributions under the same license as the
 original.

So if anyone dislikes GPL, add CC-...-SA to your list as well.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Eric S Fraga e.fr...@ucl.ac.uk writes:

 On Monday, 27 Jul 2015 at 19:04, Marcin Borkowski wrote:

 [...]

 Nope.  As stated by someone here (Oleh, I guess), if I (require 'org),
 or possibly even just write Elisp, and want to distribute it, it has to
 be GPL.

 I do not think this is true.  I would like to see a proper reference
 where it is shown to be the case.  Oleh?

Look here:
https://en.wikipedia.org/w/index.php?title=GNU_General_Public_Licensesection=11#Libraries

Most useful quote:

 The Free Software Foundation (which holds the copyright of several
 notable GPL-licensed software products and of the license text itself)
 asserts that an executable which uses a dynamically linked library is
 indeed a derivative work. This does not however apply to separate
 programs communicating with one another.

So calling GNU find in your program via the shell call API (or whatever
else, pipes ...) of your language is totally fine.

But adding #include find.h to your code is not fine, according to FSF.
Same thing with Org: adding a shell call emacs --eval org-export ...
is fine. Adding (require 'org) to your program is not fine.

Org the text format is fully open and not copyright-able. Anyone can
choose to support it (Orgzzly, Trello etc.). Org-mode's Elisp
implementation is GPL, just like the whole of the Elisp interpreter.

You could argue about Elisp being close to Common Lisp, and indeed: if
you write in a subset of Elisp that is compatible with Common Lisp,
you're not using the Elisp standard library, and your code can run on
whatever CL implementation and you don't have to GPL your code.

One could try make a BSD licensed Emacs, just like the Wine 
(https://www.winehq.org/) project was
made to emulate Windows: just try to adhere to the API without reusing
any of the original code.

See also GNU LGPL: 
https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License.
That license explicitly allows closed code to link to a free software
library. Since this license exists, it's natural to assume that GPL does
not allow this.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Andreas Hilboll li...@hilboll.de writes:

 Look here:
 https://en.wikipedia.org/w/index.php?title=GNU_General_Public_Licensesection=11#Libraries

 Most useful quote:

 The Free Software Foundation (which holds the copyright of several
 notable GPL-licensed software products and of the license text itself)
 asserts that an executable which uses a dynamically linked library is
 indeed a derivative work. This does not however apply to separate
 programs communicating with one another.

 thanks for this link and excerpt.  I could argue that the key word in
 the excerpt is executable.  I cannot see how code written in elisp
 itself would need to be GPL.

 Exactly.  To quote again
 https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL:

When the interpreter just interprets a language, the answer is no.
The interpreted program, to the interpreter, is just data; a free
software license like the GPL, based on copyright law, cannot limit
what data you use the interpreter on. You can run it on any data
(interpreted program), any way you like, and there are no
requirements about licensing that data to anyone.

Just to link the paragraph exactly below the one you quoted

 However, when the interpreter is extended to provide “bindings” to
 other facilities (often, but not necessarily, libraries), the
 interpreted program is effectively linked to the facilities it uses
 through these bindings. So if these facilities are released under the
 GPL, the interpreted program that uses them must be released in a
 GPL-compatible way. The JNI or Java Native Interface is an example of
 such a binding mechanism; libraries that are accessed in this way are
 linked dynamically with the Java programs that call them. These
 libraries are also linked with the interpreter. If the interpreter is
 linked statically with these libraries, or if it is designed to link
 dynamically with these specific libraries, then it too needs to be
 released in a GPL-compatible way.

Indeed, the Emacs interpreter gives bindings to all Emacs facilities,
which are GPL, and the interpreted program that uses them must be
released in a GPL-compatible way.

Plus Emacs supports byte compilation: someone could publish only the
exporter.elc, without providing exporter.el. That would be illegal, but
if the third party is given exporter.el released under BSD by a second
party, theoretically they could do it. Therefore, the second party
should not be allowed to change to BSD if they're linking to GPL code.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Andreas Hilboll li...@hilboll.de writes:

 However, when the interpreter is extended to provide “bindings” to
 other facilities (often, but not necessarily, libraries), the
 interpreted program is effectively linked to the facilities it uses
 through these bindings. So if these facilities are released under the
 GPL, the interpreted program that uses them must be released in a
 GPL-compatible way. The JNI or Java Native Interface is an example of
 such a binding mechanism; libraries that are accessed in this way are
 linked dynamically with the Java programs that call them. These
 libraries are also linked with the interpreter. If the interpreter is
 linked statically with these libraries, or if it is designed to link
 dynamically with these specific libraries, then it too needs to be
 released in a GPL-compatible way.
 
 Indeed, the Emacs interpreter gives bindings to all Emacs facilities,
 which are GPL, and the interpreted program that uses them must be
 released in a GPL-compatible way.

 I would interpret this as

As long as I write pure elisp and don't require' and GPL'ed part of
Emacs, I can release my code under any license I want.  If I do
require' any part of Emacs, I have to go the GPL path.

 If I'm wrong with this interpretation, please explain why.

Your interpretation is entirely correct. However, to write almost any
useful code, you're going to need to require some parts of
Emacs. Anything that interacts with text in a buffer will need to call
`buffer-string' eventually - GPL-ed code.

Here are the famous 9 lines from the Oracle-Google Java lawsuit:

private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
 if (fromIndex  toIndex)
  throw new IllegalArgumentException(fromIndex( + fromIndex +
   )  toIndex( + toIndex+));
 if (fromIndex  0) 
  throw new ArrayIndexOutOfBoundsException(fromIndex);
 if (toIndex  arrayLen) 
  throw new ArrayIndexOutOfBoundsException(toIndex);
}

This lawsuit is currently on some sort of appeal now. The code above is
essentially the most simple, efficient and obvious way to implement the
rangeCheck function based on the API signature. And still they sued.

On the other hand, the implementation of `buffer-string' isn't at all
trivial:

DEFUN (buffer-string, Fbuffer_string, Sbuffer_string, 0, 0, 0,
   doc: /* Return the contents of the current buffer as a string.
If narrowing is in effect, this function returns only the visible part
of the buffer.  */)
  (void)
{
  return make_buffer_string_both (BEGV, BEGV_BYTE, ZV, ZV_BYTE, 1);
}

Lisp_Object
make_buffer_string_both (ptrdiff_t start, ptrdiff_t start_byte,
 ptrdiff_t end, ptrdiff_t end_byte, bool props)
{
  Lisp_Object result, tem, tem1;

  if (start  GPT  GPT  end)
move_gap_both (start, start_byte);

  if (! NILP (BVAR (current_buffer, enable_multibyte_characters)))
result = make_uninit_multibyte_string (end - start, end_byte - 
start_byte);
  else
result = make_uninit_string (end - start);
  memcpy (SDATA (result), BYTE_POS_ADDR (start_byte), end_byte - 
start_byte);

  /* If desired, update and copy the text properties.  */
  if (props)
{
  update_buffer_properties (start, end);

  tem = Fnext_property_change (make_number (start), Qnil, make_number 
(end));
  tem1 = Ftext_properties_at (make_number (start), Qnil);

  if (XINT (tem) != end || !NILP (tem1))
copy_intervals_to_string (result, current_buffer, start,
  end - start);
}

  return result;
}

It's possible to write some complex number-crunching functions without
relying on the Elisp library. That's the only use-case that I see of
using Emacs like an interpreter and not relying on the bindings to the
code that it provides.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Eric S Fraga e.fr...@ucl.ac.uk writes:

 Anyway, I think we've beaten this to death already.  Time to get real
 work done! :-)

That is my usual approach: label everything I write with GPL and not
think about it:)

It's just that most posts about GPL cast it in a bad light: I think it's
the best license, and I don't want people who casually read this list to
think that GPL has no supporters or that we are somehow stuck with it,
or it is imposed on us.

Even if I was not *required* to use this license, I would *choose* to
use it, because I like the idea.

--Oleh

[O] Is it possible to remove org-completing-read and org-completing-read-no-i?

[Oleh Krehel]

Hi all,

I'd like to remove them in favor of using `org-icompleting-read'
everywhere (or better yet, `completing-read').

`org-completing-read-no-i' doesn't do much, is called twice and can be
replaced with a let binding wrapper.

`org-completing-read' could be updated this way:

(defmacro with-org-minibuffer-keys (rest body)
  Minibuffer read with SPACE being a normal character.
  `(let ((enable-recursive-minibuffers t)
 (minibuffer-local-completion-map
  (copy-keymap minibuffer-local-completion-map)))
 (org-defkey minibuffer-local-completion-map   'self-insert-command)
 (org-defkey minibuffer-local-completion-map ? 'self-insert-command)
 (org-defkey minibuffer-local-completion-map (kbd C-c !) 
'org-time-stamp-inactive)
 ,@body))

(with-org-minibuffer-keys
(org-icompleting-read args))

This change will simplify the code nicely.  One example that bothers me
is `org-tags-completion-function': it's essentially a hacky closure that
relies on several dynamic variables being set:
`org-last-tags-completion-table' and
`org-add-colon-after-tag-completion' are implicit arguments to this
function.

With the proposed change, each use of `org-tags-completion-function'
will be in conjunction with `org-icompleting-read'. That means a new
function can be written:

(defun org-read-tags (tag-list optional colon)
  (let ((org-last-tags-completion-table tag-list)
(org-add-colon-after-tag-completion colon))
(org-icompleting-read
 Tag:  'org-tags-completion-function
 ;; ...
 )))

I think it's a better interface, since the coupling is now made
explicit, instead of having to remember to set
`org-last-tags-completion-table' and
`org-add-colon-after-tag-completion' each time
`org-tags-completion-function' is to be used.

An even better thing to do would be to use lexical-binding: t, remove
`org-tags-completion-function' and have it be a real closure inside
`org-read-tags'. Is there any wish or effort to move Org to
lexical-binding? Adding it would allow us to get rid of those dynamic
variables and `org-tags-completion-function' altogether and have the
lambda enclose on tag-list and colon instead.

regards,
Oleh

Re: [O] Org-mode exporters licensing

[Oleh Krehel]

Rasmus ras...@gmx.us writes:

 Oleh Krehel ohwoeo...@gmail.com writes:

 If anywhere in your code there's (require 'org), you have to release
 your code under GPL.

 Are you sure about that?  By this logic, *any* .el file should be GPL as
 they use (defun ·), implicitly loaded from byte-run.

I'm pretty sure: you're calling a library that is GPLv3.  There was this
whole TiVo issue about linking GPL libraries to non-GPL code, which
resulted in GPLv3. I just checked, and `progn' is GPLv3 and not GPLv2
(which would at least have a chance to be linked).

--Oleh

Re: [O] Org-mode exporters licensing

[Oleh Krehel]

Marcin Borkowski mb...@mbork.pl writes:

 I'm preparing a tutorial on writing Org-mode exporters.  To this end,
 I'm writing a (simplistic) Oddmuse/WikiCreole exporter.  Rather
 obviously, I'm modeling it on existing exporters (mainly ox-latex),
 which seem to share a lot of structure (function names and docstrings in
 particular).  I'd like to put my code in public domain.  However,
 I reuse parts of GPL'd code (as I mentioned, quite generic ones, but
 still).  Is it fine, or should I expect a visit from EFF lawyers or
 something?

If anywhere in your code there's (require 'org), you have to release
your code under GPL.

If you want a Public Domain license, you'll have to write an exporter
basically without using Elisp, since the GNU Emacs implementation of
Elisp is GPL. You could write it in Python, for example, and just add a
shell call in Elisp. In that case the Python code could be PD, while the
couple-line Elisp shell call would still be GPL.

regards,
Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Marcin Borkowski mb...@mbork.pl writes:

 Hi all,

 after a short discussion in a recent thread, I have a serious technical
 question.

 Assume that (for some reason) I want to write an Org-mode exporter which
 won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
 writing a tutorial on them, and I consider publishing a *tutorial* with
 GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
 other people can or even should reuse the code in the tutorial, right?
 And I see no reason to impose GPL on them.))

 How do I do that?  Is that even possible?  Also, is it possible to get
 an actual answer to this question without spending money on lawyers?

Like I said in an earlier message just a few minutes ago, you can do it,
but you can't use org.el or Elisp at all, unless you implement your own
Elisp engine that you call.

The GPL isn't as evil as you make it out to be: in fact, it's not evil
at all: it only ensures that you pass on the freedom that you receive to
others, i.e. **you are not free to remove freedom from others**.

As for documentation, here I cite a bit of Elisp manual:

(a) The FSF’s Back-Cover Text is: “You have the freedom to copy and
 modify this GNU manual.  Buying copies from the FSF supports it in
 developing GNU and promoting software freedom.”

Just think about it: on 99% of published books it says:

No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form or by means electronic,
mechanical, photocopying, or otherwise, without prior written
permission of the publisher.

Now who is the evil guy here?

regards,
Oleh

Re: [O] John's amazing indexing posts

[Oleh Krehel]

Hi Erik,

Erik Hetzner e...@e6h.org writes:
 I previously hooked up org with recoll with pretty good results.
 ...
 http://www.lesbonscomptes.com/recoll/

Thanks for the link. I tried it, and it actually works great on my
system (unlike swish-e). And I did no configuration of mimeinfo, I only
told it to index my whole org/ directory.

If anyone is interested, I've added an Emacs interface to recallq (a
shell tool that comes with recoll that you have to build yourself).  See
counsel-recoll command from
https://github.com/abo-abo/swiper/blob/master/counsel.el.

Initially, this command gives you a list of files that match the
query. After selecting the file, it's searched for the current query.
Unfortunately, the -A (abstract) switch isn't as useful as the context
that e.g. grep gives, so I went only with the file names.

regards,
Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Marcin Borkowski mb...@mbork.pl writes:

 And what if I explicitly want people to be able to use my code in
 a proprietary software?

Then you're out of luck. Just like thousands (millions) of programmers
are out of luck when they want to examine the code of a closed source
proprietary software.

If I asked someone for Microsoft Word source code, because I want to
understand why my macro doesn't work, they would laugh in my face.  And
then bring up that situation as a joke for years. A credit to FSF
people: no one is laughing at you. Myself included, I tried to explain
the benefits of GPL, but if you don't want to listen that's fine.

--Oleh

Re: [O] old ob-clojure in orgmode.org/elpa/?

[Oleh Krehel]

Hi Julien,

I asked this before, and the reason is that it was missed in the last
release.  And there's still some time until the next release that will
finally update it.

regards,
Oleh

[O] Unclear org-icompleting-read interface

[Oleh Krehel]

Hi all,

The current `org-icompleting-read' is defined as taking only `rest
args', which can be as many as 8, all of them without a name.

I propose to update the definition to:

(cl-defun org-icompleting-read (prompt collection
key predicate require-match
  initial-input hist def 
inherit-input-method)
  ;; ...
  )

Let me know if you like the idea. If so, there are 43 calls to
`org-icompleting-read' in the source that need to be updated. Some of
them should as they are, since usually only the first two arguments are
used.

This change would make the calls to `org-icompleting-read' much easier
to read.

regards,
Oleh

Re: [O] Unclear org-icompleting-read interface

[Oleh Krehel]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Moreover,
 `org-icompleting-read' is not harder to read as `completing-read'
 anyway.

I disagree on this. `completing-read' at least declares its own argument
list. So it's possible to distinguish which argument is which, albeit
with some effort for a large amount of arguments.

For example, in this case there are 5 args, the first two I know by
heart. Not the other three.

(setq prop (org-icompleting-read
Property:  (mapcar 'list (org-buffer-property-keys t nil t))
nil nil prop))

And the arglist: rest args, instead of prompt collection predicate
require-match initial-input hist def inherit-input-method.

Here's how it would look like for a `cl-defun' variant:

(org-icompleting-read
 Property:  (mapcar 'list (org-buffer-property-keys t nil t))
 :initial-input prop)

Down to 3 arguments from 5, and the last one is very easy to understand,
even without eldoc.

In any case this also solves the problem of the argument list:

(define-obsolete-function-alias
'org-icompleting-read 'completing-read)

Re: [O] CUSTOM_ID doesn't work for HTML export on Org trunk

[Oleh Krehel]

Hi Nicolas,

Thanks for helping.

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 The following buffer

 * Headline
   :PROPERTIES:
   :CUSTOM_ID: my-id
   :END:


 exports as

 div id=outline-container-orgheadline1 class=outline-2
   h2 id=my-ida id=orgheadline1/aspan 
 class=section-number-21/span Headline/h2
   div class=outline-text-2 id=text-my-id
   /div
 /div

I'm getting the same behavior.

 It looks correct.

It's not: I'm getting this in my Firefox address bar if I click the link:

testorg.html#orgheadline1

Here's the two months old export behavior:

div id=outline-container-my-id class=outline-2
h2 id=my-ida id=sec-1/aspan class=section-number-21/span 
Headline/h2
div class=outline-text-2 id=text-my-id
/div

And the corresponding Firefox bar:

testorg.html#my-id

regards,
Oleh

Re: [O] CUSTOM_ID doesn't work for HTML export on Org trunk

[Oleh Krehel]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Oleh Krehel ohwoeo...@gmail.com writes:

 It's not: I'm getting this in my Firefox address bar if I click the link:

 testorg.html#orgheadline1

 What link? There is no link in your example.

The link to the headline in the table of contents.

 The code generated for headlines is correct. However, links indeed
 target internal reference instead of custom ID. I changed to behaviour
 so they prefer custom ID (b856f66892b8fbf827e4b4a3e89e739a9caca051).

This solves the problem for me, thanks.

Oleh

[O] CUSTOM_ID doesn't work for HTML export on Org trunk

[Oleh Krehel]

Hi all,

I don't know if this has been raised before, but it seems not to be
fixed yet.  Currently, in HTML export, instead of #custom_id I'm getting
e.g. #orgheadline10.

The commit that broke this was 2 months ago:
160820bc9498e9364103e72b55a27cf92576dbb8 still works fine.

Let me know if this is bug that needs to be fixed, or maybe CUSTOM_ID
was replaced with something.

regards,
Oleh

Re: [O] navigate between source code blocks

[Oleh Krehel]

Leo Ufimtsev lufim...@redhat.com writes:

And it's got the best Helm implementation for navigating to
 headings.

 Well, when I hear someone use the word 'best', I see it as a challenge X-D.

 I used worf-goto for a while. It's certainly amazing and on the odd occasion 
 I still use it, but lately I've switched over to: helm-org-in-buffer-headings

 The difference is that worf-goto only looks at the specific headings (e.g the 
 line it self), where as helm-org-in-buffer-headings searches the whole 
 hierarchy. 

 E.g if I have a structure like this:

 * Gdb 
 ** Break 
 *** on line  (1)
 *** on function 
 * Eclipse
 ** Break
 *** on line
 *** on function 

 And I search for gdb break line, then I will not get a match with 
 worf-goto, but helm-org-in-buffer-headings does do a match on (1).

 For example in the attached screenshot I search for gdb cmd break. It's 
 also smart enough to trim long headings.

 This is particularly useful for finding the deeply nested sub-items.

 from what I gather, worf doesn't have an equivalent:
 https://github.com/abo-abo/worf/blob/master/worf.el
 Imho it would benefit from having something of that sort in the
 package.

Thanks for the feedback, Leo. It's doable, but then it would be pretty
much identical to helm-org-in-buffer-headings.  If you or anyone else is
interested, post at https://github.com/abo-abo/worf/issues.

 It just takes vi-style hjkl arrows, because
 Emacs-style bnpf arrows aren't convenient.

 Well, I use the Colemak layout, so hjkl is actually not very
 convenient for me :-/. Meh.

Well, it's always something, isn't it :)

By the way, I'm trying to go with general-purpose tools these days.
Here's a link to the search that you mentioned using swiper:
http://oremacs.com/download/org-mode-swiper.png.

Swiper is an isearch replacement, so I could just:

1. C-s break - see 38 matches.
2. C-a \* SPC - see 9 matches.
3. C-n repeatedly to navigate to the one that I want.

As you see, I kind of stole your notes and the org-bullets
customization, so thanks for that:)

Oleh

Re: [O] navigate between source code blocks

[Oleh Krehel]

Leo Ufimtsev lufim...@redhat.com writes:

 Worf I think is a bit on the vi side of things. Helm is more generic.

Worf is as much on the vi side of things, as `org-use-speed-commands'
are. Almost not at all. It just takes vi-style hjkl arrows, because
Emacs-style bnpf arrows aren't convenient.

And it's got the best Helm implementation for navigating to
headings. I've just added named blocks to this list as well.
Screenshot: http://oremacs.com/download/worf-goto.png.
The command to call is M-x `worf-goto' or g while in `worf-mode'.

Oleh

Re: [O] navigate between source code blocks

[Oleh Krehel]

Hi Zhihao,

 I’ve got a simple question: how to speed up jumping
 between code blocks?

You might be interested in https://github.com/abo-abo/worf.
It allows you to traverse anything that starts with * or #+ with
just hjkl keys.
See the docs here: http://oremacs.com/worf/README.html.

regards,
Oleh

Re: [O] Could org-mode use `completing-read-function' instead of `org-icompleting-read'?

[Oleh Krehel]

Hi Rasmus,

On Thu, Apr 16, 2015 at 4:10 PM, Rasmus ras...@gmx.us wrote:
 Hi Oleh,

 Oleh Krehel ohwoeo...@gmail.com writes:

 I was just trying to customize the completion back end for refiling (ido 
 isn't
 great for that, even with the ido-vertical upgrade).  And it's not at all 
 easy,
 since ido seems to be hard-wired into org-mode's completion.  Could we just
 change to use `completing-read-function' instead of `org-icompleting-read'?

 I think it's nicer to use existing features/variables, but comparability
 is also an issue.

Alright, I've made so that if `completing-read-function' is
`completing-read-default', nothing changes.  But when it's set, it
used. So now, e.g. `helm-mode' or `ivy-mode' will automatically work.

Oleh

[O] Could org-mode use `completing-read-function' instead of `org-icompleting-read'?

[Oleh Krehel]

Hi all,

I was just trying to customize the completion back end for refiling (ido isn't
great for that, even with the ido-vertical upgrade).  And it's not at all easy,
since ido seems to be hard-wired into org-mode's completion.  Could we just
change to use `completing-read-function' instead of `org-icompleting-read'?

regards,
Oleh

Re: [O] Could org-mode use `completing-read-function' instead of `org-icompleting-read'?

[Oleh Krehel]

On Thu, Apr 16, 2015 at 5:21 PM, Rasmus ras...@gmx.us wrote:
 Hi Oleh,

 Oleh Krehel ohwoeo...@gmail.com writes:

 I was just trying to customize the completion back end for refiling
 (ido isn't
 great for that, even with the ido-vertical upgrade).  And it's not
 at all easy,
 since ido seems to be hard-wired into org-mode's completion.  Could we just
 change to use `completing-read-function' instead of `org-icompleting-read'?

 I think it's nicer to use existing features/variables, but comparability
 is also an issue.

 Alright, I've made so that if `completing-read-function' is
 `completing-read-default', nothing changes.  But when it's set, it
 used. So now, e.g. `helm-mode' or `ivy-mode' will automatically work.

 The change is no good IMO.  For the fix to work one needs to set
 org-completion-use-ido.  If this is non-nil it would be weird if ido is
 not used.


 I don't know how to use helm of ivy.  But I think the attached patch is
 better.  Would that work with helm and ivy?

I could live with it, but basically `org-completion-use-ido` says I
don't care if you've temporarily disabled `ido-mode' or not, I'll use
ido anyway. This isn't a good approach, especially considering that
`ido-mode' is already a convenient minor mode.
Maybe `org-completion-use-ido' should be completely removed, and ido completion
should be used automatically when `ido-mode' is on.

Oleh

Re: [O] Could org-mode use `completing-read-function' instead of `org-icompleting-read'?

[Oleh Krehel]

 I don't know how to use helm of ivy.  But I think the attached patch is
 better.  Would that work with helm and ivy?

Yes, both work fine.

 I could live with it, but basically `org-completion-use-ido` says I
 don't care if you've temporarily disabled `ido-mode' or not, I'll use
 ido anyway. This isn't a good approach, especially considering that
 `ido-mode' is already a convenient minor mode.
 Maybe `org-completion-use-ido' should be completely removed, and ido 
 completion
 should be used automatically when `ido-mode' is on.

Oops, just noticed that `ido-mode' is actually in the condition.
All is fine then.

Except that iswitchb is obsolete. Should we remove it?

Oleh

Re: [O] Could org-mode use `completing-read-function' instead of `org-icompleting-read'?

[Oleh Krehel]

Hi Marcin,

On Thu, Apr 16, 2015 at 7:45 PM, Marcin Borkowski mb...@mbork.pl wrote:

 On 2015-04-16, at 17:35, Oleh Krehel ohwoeo...@gmail.com wrote:

 I don't know how to use helm of ivy.  But I think the attached patch is
 better.  Would that work with helm and ivy?

 Yes, both work fine.

 Just my 2 cents: what about us Icicles users?  (Apparently, all two of
 us, which saddens me...)

Icicles works fine. And any new future package that adheres to the
interface should work too.

Oleh

[O] Updating to the current org-mode in emacs trunk, and Org stable

[Oleh Krehel]

Hi all,

I normally use the git master version of org-mode, so I didn't notice
this for the longest time, but my several of my updates to org-mode
still aren't merged into stable versions.

For instance, ob-J.el was added over a year ago, and there have been
stable releases since then, but it wasn't in any of them. And it's not
in the emacs trunk either.

Same for ob-clojure.el: it still tries to rely on SLIME for
evaluation, although I added CIDER support over a year ago.

These are just the two files that I'm familiar with, there may be many
more.  What's the schedule of merging these changes to the stable
versions of Org and to Emacs trunk?

regards,
Oleh

[O] bug#14910: org-mode `org-open-at-point' doesn't follow id links

[Oleh Krehel]

Hi Bastien,

 please make sure to send your replies on the list, you'll get a
 quicker answer.
Thanks for reminding, I keep forgetting.

 As for requiring org-id for `org-open-at-point', I'm not sure this
 is the right thing to do since it will require it for all users, even
 those who don't use org-id at all.
I understand that you don't want to bloat the loaded code, but the current
behavior isn't optimal:
* I open a file with a link [[id:58cc1851-c36a-452a-82e1-0b9ecde1c472][foo]]
* I click the link and get the message
  No match. Create this as a new heading? And on y it proceeds to create it.
  In the same file that I asked it to find it.
  Just a few lines above the actual reference. That's not very smart.

If there's a link in the file, it points somewhere in 99% cases.
And currently the program assumes implicitly that stupid user clicked on a
dangling link and rushes to correct him before even looking in the
same file if the requested sequence of 36 chars (pretty unique) is
actually there.

The issue is that the current solution isn't portable.
I've sent last week an org file to a new org-mode user with id links.
And he says that they don't work.
He's not experienced in elisp, so it's hard for me to explain to him
that he has to include (require 'org-id) in his ~/.emacs to make links work.
In my opinion it would be best to require 'org-id implicitly so that
the links work the same for all users.

Imagine that I've sent him a pdf with links that don't work
and then I told him that he needs to install some specific software
from who knows where just to make the pdf links work.

regards,
Oleh