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 <mb...@mbork.pl> 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 <kaushal.m...@gmail.com> 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 <m...@nicolasgoaziou.fr> 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 <samolog...@gmail.com> 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 <kaushal.m...@gmail.com> 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 <mb...@mbork.pl> 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]

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 package, use !(ox-kbd "M-x") =package-install=.

It doesn't look too awkward, and "C-x C-e" would still work simply
inside the Org document. Here's a simple implementation of `ox-kbd':

(defun ox-kbd (str)
  (cl-case org-export-current-backend
(html (format "%s" str))
(texinfo+ (format "@kbd{%s}" str))
(t str)))

Here's another example of the proposed inline Elisp syntax:

This document's last revision is !(substring (shell-command-to-string "git 
rev-parse HEAD") 0 -1).

It should be fairly easy to add this to the syntax, since the "!("
string is very unique, and `forward-sexp' can be used to find the ending
of the inline block.

I'd appreciate everyone's thoughts on the proposed addition.  Best case
scenario, Nicolas agrees and it's actually easy to add the new "!()"
inline Elisp syntax. Mid case, everyone's indifferent and I can add the
code myself. Worst case, people are opposed to this change and I'm sad.

regards,
Oleh

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 <m...@nicolasgoaziou.fr> 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 <aarone...@gmail.com> 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 <k...@kyleam.com> 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 <jsch...@gmail.com> 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 <mb...@mbork.pl> 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

Re: [O] org-download.el

[Oleh]

 2. As I'm testing now, I can get a Wrong type argument:
number-or-marker-p, nil error if the org-mode file in question is
empty or the cursor is before the first heading. Is this the case for
 you?
I'll fix this case soon anyway.
 -- Not really, I made a test.org then insert some heading, then tried
 (org-download-yank) with the web address on top of kill-ring, which did not
 trig the download events as well.

It is important that the point should be not before the first
heading. Is this the case?  Also, are you using the Github version? I
haven't yet propagated the changes to the org-contrib version.

 3. If this doesn't work, try the following simplified function:

 (defun org-download-yank-1 ()
   (interactive)
   (let ((filename ./foo.png))
 (org-download--image
  https://www.google.nl/images/srpr/logo11w.png;
  filename)
 (insert (format [[%s]] filename))
 (org-display-inline-images)))

 -- This one works! The google logo gets into my test.org buffer, which is a
 good signal~

OK, this means that at least `org-download-yank` can be fixed very soon.
And, as I recall, the dnd works for some OSX users.
Let's not bother the nice org-people and continue the discussion here:
https://github.com/abo-abo/org-download/issues/11

regards,
Oleh

Re: [O] org-download.el

[Oleh]

 Thanks for the detailed instruction. I just checked following your advice,
 by copying the address of the image (and by looking at the browser-ring, I
 can make sure the address has been there), then M-x org-download-yank,
 returns error: if: Wrong type argument: number-or-marker-p, nil.

 Also I tried (org-download-yank the-address-to-the-image), which does not
 work either.

 Do you have any insight? Thanks.

Alright, we're getting somewhere now.

1. Have you made any customizations to `org-download`? It's easier for
me to proceed with the defaults.
2. As I'm testing now, I can get a Wrong type argument:
   number-or-marker-p, nil error if the org-mode file in question is
   empty or the cursor is before the first heading. Is this the case for you?
   I'll fix this case soon anyway.
3. If this doesn't work, try the following simplified function:

(defun org-download-yank-1 ()
  (interactive)
  (let ((filename ./foo.png))
(org-download--image
 https://www.google.nl/images/srpr/logo11w.png;
 filename)
(insert (format [[%s]] filename))
(org-display-inline-images)))

If this one doesn't work as well, I can proceed from there.

regards,
Oleh

Re: [O] org-download.el

[Oleh]

Hi all,

I've made a blog post regarding today's improvements to org-download
at http://oremacs.com/2015/01/18/sprucing-up-org-download/.
The post also links to a video demo: https://www.youtube.com/watch?v=dAojpHR-6Uo

regards,
Oleh

Re: [O] org-download.el

[Oleh]

Hello,

 Does anyone get org-download.el to work under Mac OSX? I'm struggling to get
 it work, but it seems to help a lot, empowering org to handle images a lot
 easier.

 I believe I've installed org-download.el correctly, but when I'm dragging
 and drop the image into an org buffer, all I get is the link address
 inserted into the buffer, no downloading events trigger.

I'm the org-download author. I've mentioned these things on the tracker,
but there's no harm to posting here additionally.

I don't have OSX, so I can't test it. However, it should work in
theory, since all tools used are portable.

Try using `org-download-yank' first: this one does everything except
drag-and-drop. Just right click and copy the image url in the browser,
and call `org-download-yank' in Emacs. If it doesn't work, the issue is
with dnd, otherwise it's with the downloading itself.

The default `org-download-backend 'uses `url-retrieve', which is a part of
Emacs, so if it doesn't work then it's an Emacs bug.

regards,
Oleh

[O] Bug: bad fontification

[Oleh]

Hello,

Here's a minimal file for which fontification fails:

* DONE =foo=
CLOSED: [2015-01-03 Sat 21:21]
CLOCK: [2015-01-03 Sat 21:20]--[2015-01-03 Sat 21:21] =  0:01
* TODO =bar=

TODO is highlighted with a verbatim face. The problem goes away
if I add a newline after =bar=.

regards,
Oleh

Re: [O] How to show/hide the snippet block in org-babel when the cursor is inside the snippet text

[Oleh]

Hi Dmitry,

 I would like to implement the following. Suppose, we have this org file:

 #+BABEL: :cache yes :tangle yes :noweb yes

 #+NAME: top_block
 #+begin_src perl :tangle test.pl :noweb tangle :shebang #!/usr/bin/perl
   use strict;
   use warnings;

   open(my $fh, , test.txt)
   or die cannot open  file name: $!;
   output-all
   close($fh);
 #+end_src

 #+NAME: output-all
 #+begin_src perl
   while (my $line = $fh) {
   print $line;
   }
 #+end_src

 I can expand/collapse src blocks only when the cursor is on the top lines:


 #+NAME: top_block
 #+begin_src perl ...

 But when it is inside any text in the scr block, expand/collapse doesn't
 work. How can I add this functionality as moving the cursor every time is
 not nice.

There's a feature like this in https://github.com/abo-abo/worf
(installable also from MELPA).

If you're in a source block, [ will bring you to its start, and i
will hide/unhide it.

You can use j/k/i to quickly navigate and fold many source
blocks within one heading.

regards,
Oleh

Re: [O] [PATCH] org-src: allow `org-babel-edit-prep:.*' to mark region

[Oleh]

Hi Nicolas,

 Well, I'm not trying to push my markup or anything, I just want my
 custom `org-babel-edit-prep:elisp' to be able to mark the region.
 Currently I'm not given that option.

 Understood.

 Would you mind providing a patch with format-patch, and reference the
 current thread in the commit message?

I can just push it through if you don't mind. I have push access.

Is this OK as reference: http://article.gmane.org/gmane.emacs.orgmode/93053 ?

regards,
Oleh

[O] [PATCH] org-src: allow `org-babel-edit-prep:.*' to mark region

[Oleh]

Hello,

Is it ok to apply the attached patch? I don't want to break anything.

I want to be able to denote my source blocks like so:

- *~* is the mark,
- *|* is the point

#+begin_src elisp
(~a b c| d e f g h i j k l m n o p q r s t u v w x y z)
#+end_src

- `org-edit-special' will automatically transform this markup into an
actual active region
- `org-edit-src-exit' will automatically transform an active region into markup

If anyone is interested, the implementation looks like this:

#+begin_src elisp
(defun org-src-denote-region (optional context)
  (when (and (memq major-mode '(emacs-lisp-mode))
 (region-active-p))
(let ((pt (point))
  (mk (mark)))
  (deactivate-mark)
  (insert |)
  (goto-char (if ( pt mk) mk (1+ mk)))
  (insert ~

(advice-add 'org-edit-src-exit :before #'org-src-denote-region)

(defun org-babel-edit-prep:elisp (info)
  (when (string-match [~|][^~|]+[|~] (cadr info))
(let (mk pt deactivate-mark)
  (goto-char (point-min))
  (re-search-forward [|~])
  (if (looking-back ~)
  (progn
(backward-delete-char 1)
(setq mk (point))
(re-search-forward |)
(backward-delete-char 1)
(set-mark mk))
(backward-delete-char 1)
(setq pt (point))
(re-search-forward ~)
(backward-delete-char 1)
(set-mark (point))
(goto-char pt)
#+end_src

The only thing left to do is to patch `org-edit-src-code'.

regards,
Oleh
From 66f117d3bab3be682f136a74376ac8e5ca92876a Mon Sep 17 00:00:00 2001
From: Oleh Krehel ohwoeo...@gmail.com
Date: Sat, 29 Nov 2014 13:20:41 +0100
Subject: [PATCH] org-src: allow `org-babel-edit-prep:.*' to mark region

* lisp/org-src.el (org-edit-src-code): Let `deactivate-mark' nil.
---
 lisp/org-src.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 6bc2171..af5336d 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -710,7 +710,8 @@ name of the sub-editing buffer.
 	  example))
 	   (lang-f (and (eq type 'src-block) (org-src--get-lang-mode lang)))
 	   (babel-info (and (eq type 'src-block)
-			(org-babel-get-src-block-info 'light
+			(org-babel-get-src-block-info 'light)))
+	   deactivate-mark)
   (when (and (eq type 'src-block) (not (functionp lang-f)))
 	(error No such language mode: %s lang-f))
   (org-src--edit-element
-- 
1.8.4

Re: [O] [PATCH] org-src: allow `org-babel-edit-prep:.*' to mark region

[Oleh]

Hi Nicolas,

 I don't understand what your use-case is. Note that `org-edit-special'
 already preserves region.

That's good, but not what I need. I want to go from an unmarked region
in an org file with markup
to a marked region without markup in the *Org Src* buffer.

I've defined a custom `org-babel-edit-prep:elisp' that does this, but
it's not allowed to mark region in this function.  A patch to
`org-edit-src-code' is required for this.

Just to sum it up: I want a custom `org-babel-edit-prep:elisp' to be
able to mark region, even if it wasn't marked before.

regards,
Oleh

Re: [O] [PATCH] org-src: allow `org-babel-edit-prep:.*' to mark region

[Oleh]

 I don't understand what your use-case is. Note that `org-edit-special'
 already preserves region.

 That's good, but not what I need. I want to go from an unmarked region
 in an org file with markup
 to a marked region without markup in the *Org Src* buffer.

 That still doesn't explain why you need it.

To automate things.
I'm writing a function reference for a package here:
  https://raw.githubusercontent.com/abo-abo/lispy/gh-pages/index.org.
Here's the link in case you don't want to compile the org-file:
  http://abo-abo.github.io/lispy/.

Some of the source blocks in this document feature a marked region
that I export marked to HTML.  Most source blocks are step-by-step
examples that assume a certain point and region state in order to
work.  And it's nice to automatically set the region state in order to
text out an example.


 I've defined a custom `org-babel-edit-prep:elisp' that does this, but
 it's not allowed to mark region in this function.

 Why?

Well, I can call `set-mark' in this function, but it won't work unless
the function
that calls it binds `deactivate-mark' to nil.


 Just to sum it up: I want a custom `org-babel-edit-prep:elisp' to be
 able to mark region, even if it wasn't marked before.

 Your markup is very personal. I still don't see the need to turn it into
 a general mechanism.

Well, I'm not trying to push my markup or anything, I just want my
custom `org-babel-edit-prep:elisp' to be able to mark the region.
Currently I'm not given that option.

 Isn't an advice enough?

I don't know how this would work. `org-babel-edit-prep:elisp' is
already the exit point
of `org-edit-src-code' and it's not allowed to mark the region.

regards,
Oleh

Re: [O] Org Babel Clojure No Prettyprint

[Oleh]

Hi,

I've just pushed a fix for this.
See if works now.

regards,
Oleh


On Wed, Oct 22, 2014 at 3:42 AM, Prathyush pra...@gmail.com wrote:
 Hi,

 I was trying to use org-babel-clojure to pretty print a collection and found
 out that it always evaluated to:

 Code block produced no output.

 Here's some sample code:

 #+begin_src clojure :results pp
 (println Hello)
 #+end_src

 Similar issue was reported few weeks back and I guess it could be related
 to the API change that broke it as mentioned here:
 http://lists.gnu.org/archive/html/emacs-orgmode/2014-10/msg00100.htmle

[O] issue with `org-insert-heading'

[Oleh]

Hi all,

I just wanted to point out what I think is a bug in `org-insert-heading'.
The abridged code:

#+begin_src elisp
(let ((adjust-empty-lines t))
  ;; code that does not change `adjust-empty-lines'
  (when adjust-empty-lines
(if (or (not blank)
(and blank (not (org-previous-line-empty-p
(org-N-empty-lines-before-current (if blank 1 0)
#+end_src

So at the very least there's test that always returns t.

The effect of this code is that when I do M-RET 3 times in a blank
file, the first two stars don't get a space after them and get
highlighted differently than the third.
Calling `outline-previous-heading' from the third star moves point to
the first star and not the second, which means that they're not
recognized as proper headings.

What I think 3 M-RET should do is to insert a space after each star.
That way they are proper headings with empty headlines.

best regards,
Oleh

Re: [O] Moving my init.el to Org

[Oleh]

 I'm using a one .el file per mode approach, with around 4000 lines
 split into 40 files.

 This approach simplifies things a lot: for instance I haven't touched
 Javascript in ages, but all my customizations for it are sitting in
 javascript.el without getting in the way of the stuff that I'm using
 now. They aren't even loaded unless I open a js file.

 Interesting - is your configuration online, so that one could take a
 look at it? I did not find them on your github page?

It's not online since it's a hassle to put it up.

 Or how do you do it, that the e.g. javascript.el is only loaded when a
 js file is opened? Because this is exactly what I would like to have.

It's a three-part setup that goes like this.
In hooks.el that's loaded unconditionally:

...
(add-hook 'java-mode-hook 'oleh-java-hook)
(add-hook 'tuareg-mode-hook 'oleh-tuareg-hook)
(add-hook 'js-mode-hook 'oleh-javascript-hook)
(add-hook 'markdown-mode-hook 'oleh-markdown-hook)
...

In modes/javascript.el that's not loaded:

;;;###autoload
(defun oleh-javascript-hook ()
  (smart-insert-operator-hook)
  (moz-minor-mode 1)
  (define-key js-mode-map (kbd f5) 'js-f5)
  (define-key js-mode-map (kbd C-f5) 'js-C-f5)
  ...
  )

And this function generates the autoloads when a new file is added:

;;;###autoload
(defun update-all-autoloads ()
  (interactive)
  (let ((generated-autoload-file (concat emacs.d loaddefs.el)))
(when (not (file-exists-p generated-autoload-file))
  (with-current-buffer (find-file-noselect generated-autoload-file)
(insert ;;) ;; create the file with non-zero size to
appease autoload
(save-buffer)))
(mapcar #'update-directory-autoloads
'( oleh oleh/modes matlab-emacs

The file loaddefs.el is loaded unconditionally as well.  So when a js
file is opened, `js-mode-hook` is called and the autoloaded
`oleh-javascript-hook` is called, making sure that
oleh/modes/javascript.el is loaded.

regards,
Oleh

Re: [O] Moving my init.el to Org

[Oleh]

 I know that I could use org-babel-load-file, or outshine.  What are
 other possibilities?  What are the caveats (and advantages) of both
 (other?) ways?

I'm using a one .el file per mode approach, with around 4000 lines
split into 40 files.

This approach simplifies things a lot: for instance I haven't touched
Javascript in ages, but all my customizations for it are sitting in
javascript.el without getting in the way of the stuff that I'm using
now. They aren't even loaded unless I open a js file.

The rest of my codes are published and I just use them via
MELPA.  I use my own package to navigate and maintain code
(https://github.com/abo-abo/lispy).  Here's a short screencast if you
haven't seen it before: https://vimeo.com/86894158.

regards,
Oleh

Re: [O] Organizing org-mode files: Tree view

[Oleh]

Hi Dotan,

 If there is a better way to organize the files, then I would love to
 know how the more experienced users do it.

I'm using an extremely simplistic approach: just dump all the org
files into one directory.  The name of each org file should be concise
but descriptive, e.g. Makefile.org describes Makefiles, and git.org
describes git.

This simplicity completely alleviates organization effort: there's
nothing to organize, since there's only one directory to put the files in.
At the same time, it's very accessible by means of two `helm` wrappers:

- globally, C-0 runs the command helm-org-wiki (the code is below)
- in org-mode, g runs the command wspecial-worf-goto (the code is at
https://github.com/abo-abo/worf)

It's like a two-stage personal Google: the first stage is to find an org-file,
the second stage is to search within an org-file.

For example, here's the sequence of key bindings when I want to look
up how git bisect works, assuming that I'm in some random buffer, like
`ansi-term`:

C-0 gi RET g bis RET

Done. Note that gi was enough to match git.org, since all my other
pages don't contain gi.  Same thing for bis being able to match
uniquely the heading git bisect.  I think that it's quite optimal
that I'm able to find the topic git bisect by using only 10 key
presses, which is the same as the amount of characters in git
bisect.  Compare this to `helm-google-suggest` (bound to C-p g):

C-p g git bi RET TAB RET

That's 12 key presses (10 in Emacs, 2 in Firefox).

New wiki pages can be created with C-0 as well, just type in the
name of the new file and hit RET.

That's it, the code is below. It's very similar to `org-switchb`,
except that the files need not be opened to appear in the completion
list, and new files are created if there's no match.

(defgroup helm-org-wiki nil
  Simple jump-to-org-file package.
  :group 'org
  :prefix helm-org-wiki-)
(defcustom helm-org-wiki-directory ~/org/wiki/
  Directory where files for `helm-org-wiki' are stored.
  :group 'helm-org-wiki
  :type 'directory)
(defun helm-org-wiki-files ()
  Return .org files in `helm-org-wiki-directory'.
  (let ((default-directory helm-org-wiki-directory))
(mapcar #'file-name-sans-extension
(file-expand-wildcards *.org
(defvar helm-source-org-wiki
  `((name . Projects)
(candidates . helm-org-wiki-files)
(action . ,(lambda (x)
  (find-file (expand-file-name
  (format %s.org x)
  helm-org-wiki-directory))
(defvar helm-source-org-wiki-not-found
  `((name . Create org-wiki)
(dummy)
(action . (lambda (x)
(helm-switch-to-buffer
 (find-file
  (format %s/%s.org
  helm-org-wiki-directory x)))
;;;###autoload
(defun helm-org-wiki ()
  Select an org-file to jump to.
  (interactive)
  (helm :sources
'(helm-source-org-wiki
  helm-source-org-wiki-not-found)))
(provide 'helm-org-wiki)

regards,
Oleh

Re: [O] Fast Access to TODO States without C-t

[Oleh]

Hi Esben,

 If I hit 't' over a TODO item, it just changes the state to the next
 state. How can I jump to DONE(d!), f.ex?

There's https://github.com/abo-abo/worf (also in MELPA) - an
alternative to org speed keys.

It's inspired by vi, so your task is handled by cwd (change word
DONE).  Other stuff works as well, such as cw[tnc] for (change word
[TODO NEXT CANCELLED]).

Similarly:
cp is change property,
dp is delete property,
p is move to property,
ct is change tag,
hjkl - navigate left/down/up/right
d2j - delete two headings down
d3k - delete three headings up
yj - copy one heading down to kill ring
3i - change view to summary level 3.
wn - make jk move only by NEXT keywords.
c - make hjkl behave like Meta+arrows
cf - make hjkl behave like Shift+Meta+arrows
cs - make hjkl behave line Shift+arrows
q - return from the four modes above

Try it out, perhaps you'll like it.

regards,
Oleh

Re: [O] update to ob-clojure.el

[Oleh]

 I've made an update to ob-clojure.el, which wasn't working for me with
 the new cider (the required function was removed).

 I haven't looked into 'nrepl or 'slime options for evaluation, is
 anyone using them?

 Eric, should 'nrepl option be removed as obsolete? And maybe 'slime as well?


 I'm not sure about removing nrepl and slime, as there may be some still
 using them, especially nrepl.  As long as it is not getting in the way,
 perhaps at this time it would be better to leave them in?  I'm not sure
 the open-source and/or emacs-org philosophy on this kind of thing.

 Prior to updating the documentation for Clojure code blocks earlier this
 year, which was several years old, I did a lot of searching around and
 came to the conclusion that the slime and swank-clojure functionality
 was no longer being developed, and the community had moved on to nrepl.
 CIDER evolved from nrepl, and is the current direction.

 https://github.com/clojure-emacs/cider

 The revised documentation is very CIDER-centric:

 http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html

My point was that if even CIDER, which is a favorite method, has
bit-rotted to the point of not working, makes it a bit questionable to
try to support the other two methods.

For instance, I could not get SLIME to work with org when I tried a
year ago, so I don't know if it's working now.

And CIDER replaces nREPL, so nREPL should be dropped at some point.
On the other hand, since nREPL isn't being edited now it's unlikely to
produce the same problem as CIDER did (the function used by ob-clojure
was removed from CIDER).

regards,
Oleh

Re: [O] ob-clojure: ':results pp' parses the output as a string value

[Oleh]

Hi Phil,

Could you test my last commit? Your case should be working now.

regards,
Oleh

Re: [O] [PATCH] ob-scheme.el: Fix scheme code blocks execution error in batch mode

[Oleh]

Hi,

I tried to have a look at your patch, but ob-scheme has stopped working
for me. Can you send me the minimal init.el to make your scheme-test.org
work in interactive mode?

regards,
Oleh

On Tue, Apr 8, 2014 at 3:56 PM, KDr2 killy.d...@gmail.com wrote:
 Hi, folks

 Has anyone reviewed this patch? Or is there a better way to fix the bug?

 Thanks.


 On Wed, Apr 2, 2014 at 11:48 AM, KDr2 killy.d...@gmail.com wrote:

 The bug:
 write file ~/scheme-test.org with the content below:
 ---8--
 #+BEGIN_SRC scheme :exports results :results output raw
   (display Hello Scheme in OrgMode)
 #+END_SRC
 ---8--

 and run:

 emacs --batch --eval='(load ~/.emacs.d/init.el)' ~/scheme-test.org -f
 org-html-export-to-html

 you will find the bug:

 `org-babel-scheme-execute-with-geiser' uses `current-message' to get the
 results of scheme code blocks, but `current-message' always returns nil in
 batch mode, and this patch fixes this.

 --
 --

 KDr2, http://kdr2.com




 --
 --

 KDr2, http://kdr2.com

[O] update to ob-clojure.el

[Oleh]

Hi all,

I've made an update to ob-clojure.el, which wasn't working for me with
the new cider (the required function was removed).

I haven't looked into 'nrepl or 'slime options for evaluation, is
anyone using them?

Eric, should 'nrepl option be removed as obsolete? And maybe 'slime as well?

regards,
Oleh

Re: [O] [PATCH] ob-scheme.el: Fix scheme code blocks execution error in batch mode

[Oleh]

 0. I use Debian(sid) and Emacs 24
 1. install guile (using apt): http://www.gnu.org/software/guile/
 2. install geiser(http://www.nongnu.org/geiser/) with elpa
 and setting for geiser:

 (setq geiser-active-implementations '(guile))
 (setq geiser-default-implementation 'guile)


I've got emacs trunk, GNU Guile 2.0.9, geiser from MELPA and I'm
getting the results in a *Geiser dbg* window instead of org-mode when
I eval.  So the issue is either with ob-scheme or with my geiser,
which is the development version, but I don't see why it shouldn't
work.

regards,
Oleh

Re: [O] [ANN] Firefox extension for org-protocol and org-capture

[Oleh]

 Following all the nice comments you made after my first announce, I just
 uploaded an updated version of the org-capture extension.

 You can find it on the main webpage
 http://chadok.info/firefox-org-capture/ or on the Mozilla addons
 repository https://addons.mozilla.org/fr/firefox/addon/org-mode-capture/
 (review pending from Mozilla people).

Hi Olivier,

Thanks for the great extension.
No more meddling with bookmarks and keyconfig for me:).

Oleh

Re: [O] update to ob-clojure.el

[Oleh]

Hi Nicolas,


 I've made an update to ob-clojure.el, which wasn't working for me with
 the new cider (the required function was removed).

 As long as we have to support Emacs 23, I think you shouldn't replace
 case with cl-case.

I've reverted it. I'll keep this in mind for future commits, thanks.

regards,
Oleh

Re: [O] [PATCH] ob-scheme.el: Fix scheme code blocks execution error in batch mode

[Oleh]

Of course it works, that's the first thing I tried.
The issue probably is that the implementation of geiser functions that
ob-scheme uses has been changed.

Oleh

On Thu, Apr 10, 2014 at 11:02 AM, KDr2 killy.d...@gmail.com wrote:
 Does your M-x run-geiser work? It will lead you to a scheme REPL like
 this:

 GNU Guile 2.0.9-deb+1-1
 Copyright (C) 1995-2013 Free Software Foundation, Inc.

 Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
 This program is free software, and you are welcome to redistribute it
 under certain conditions; type `,show c' for details.

 Enter `,help' for help.
 scheme@(guile-user) 1
 $2 = 1
 scheme@(guile-user)




 On Thu, Apr 10, 2014 at 4:55 PM, Oleh ohwoeo...@gmail.com wrote:

  0. I use Debian(sid) and Emacs 24
  1. install guile (using apt): http://www.gnu.org/software/guile/
  2. install geiser(http://www.nongnu.org/geiser/) with elpa
  and setting for geiser:
 
  (setq geiser-active-implementations '(guile))
  (setq geiser-default-implementation 'guile)
 

 I've got emacs trunk, GNU Guile 2.0.9, geiser from MELPA and I'm
 getting the results in a *Geiser dbg* window instead of org-mode when
 I eval.  So the issue is either with ob-scheme or with my geiser,
 which is the development version, but I don't see why it shouldn't
 work.

 regards,
 Oleh




 --
 --

 KDr2, http://kdr2.com

Re: [O] [PATCH] ob-scheme.el: Fix scheme code blocks execution error in batch mode

[Oleh]

 Version of  geiser I installed: geiser-20140326.951, If it has been changed,
 it must be changed in the past 2 weeks ...


That's exactly the version that I have.
Which org-mode are you using?

Re: [O] Screencast of lispy.el with org-mode code base

[Oleh]

 The package provides a key binding method that can work effectively
 only for a Lisp-like language: Elisp, Scheme, Common Lisp and Clojure
 all fit here.

 I better understand the name then.

 Looks like quite a big project already.

Yes, it's my biggest yet.

 Each time I tried paredit, I could not stand it for more than
 a few minutes, I've not been patient so far, especially since
 `electric-pair-mode' is now on by default and does 90% of what
 I need.

That's how I've started to write lispy: with 3 functions for inserting
pairs and a re-bind of `forward-list`/`backward-list` to ]/[.

 But I may look at other solutions than paredit (being conscious
 your librarie goes far beyond that.)

Sure. Not everyone likes paredit (at first:). That's why each locally
bound function in lispy is constructed from a regular interactive
function: so you can use them without turning on the minor mode.

But somehow paredit together with other powerful tools becomes more
than the sum of its parts: paredit + multiple-cursors allows easy
refactors of repeated information, lispy store region + ediff makes
for easier and faster diffs, and lispy narrowing + ace-jump-mode
symbol selection + iedit allows to rename variables faster.

And of course it's nice to keep some specialty tools handy:
`lispy-multiline` (M) may not seem like much, but it's great after a
`macroexpand-all`.

And look at `lispy-flatten` (xf):

|(org-defkey org-mode-map [(meta up)]'org-metaup)

-

|(define-key org-mode-map (org-key [(meta up)]) 'org-metaup)

Nifty, right?

regards,
Oleh

Re: [O] mark parent element?

[Oleh]

Hi Matt,

 I'm trying to write a function that will mark the parent of the
 current element.  I think I understand how to do it but for some
 reason I can get the mark to persist after the funciton is called.  I
 think it's really an elisp problem, not an org problem, but am hoping
 someone can ehelp me.  Here's what I have:

 (defun er/mark-org-parent-element ()
   Marks an org parent element
   (interactive)
   (let ((parent (plist-get (car (cdr (org-element-at-point))) :parent)))
 (let ((parent-props (car (cdr parent
   ;; (print parent-props)
   ;; (print (plist-get parent-props :begin))
   ;; (print (plist-get parent-props :end))
   (if (plist-get parent-props :begin)
   (progn
 (goto-char (plist-get parent-props :begin))
 (set-mark (point))
 (goto-char (plist-get parent-props :end))
 (exchange-point-and-mark)
 )))
 )
 )

The probelm here is that `(org-element-at-point)` doesn't always have
a parent. I'm using plain outline functions for this purpose.
See `worf-mark-left' at https://github.com/abo-abo/worf/blob/master/worf.el.

regards,
Oleh

Re: [O] [PATCH] org.el (org-delete-property): Remove bogus properties

[Oleh]

Hi Bastien,

I've pushed a bugfix related to the patch.
`org-entry-delete' was being called with 3 args, although it takes 2.
I hope I understood it correctly. Could you please check?

regards,
Oleh

On Wed, Mar 12, 2014 at 7:22 PM, Bastien b...@gnu.org wrote:
 Hi Oleh,

 Oleh ohwoeo...@gmail.com writes:

 Can someone have a look at this patch and check it in?

 I applied a different patch, things are a bit more complicate:
 (org-get-category) always returns a non-empty string (at least
 after `org-refresh-category-properties' as been called once),
 while (org-entry-get (point) CATEGORY) is the real check we
 need to perform.

 Thanks for raising this!

 --
  Bastien

[O] [PATCH] org.el (org-delete-property): Remove bogus properties

[Oleh]

Hi all,

Can someone have a look at this patch and check it in?

It fixes `org-delete-property` offering to delete CATEGORY property although
it's not present. Also skip completion when there's only one candidate.

regards,
Oleh
From ad4415a4cbf67955c636b8a3384f3163cac61462 Mon Sep 17 00:00:00 2001
From: Oleh Krehel ohwoeo...@gmail.com
Date: Wed, 12 Mar 2014 17:11:12 +0100
Subject: [PATCH] org.el (org-delete-property): Remove bogus properties

* lisp/org.el (org-delete-property): Don't offer to delete CATEGORY
  property, since it's not really there. If there's only one property
  to delete, don't call `org-icompleting-read'.
---
 lisp/org.el | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 2f3820f..3a64d1d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15895,13 +15895,16 @@ in the current file.
   In the current entry, delete PROPERTY.
   (interactive
(let* ((completion-ignore-case t)
-	  (prop (org-icompleting-read Property: 
-  (org-entry-properties nil 'standard
- (list prop)))
+	 (props (org-remove-if
+		 (lambda (x) (string= (car x) CATEGORY))
+		 (org-entry-properties nil 'standard
+ (if (= 1 (length props))
+	 (list (caar props))
+   (list (org-icompleting-read Property:  props)
   (message Property %s %s property
-	   (if (org-entry-delete nil property)
-	   deleted
-	 was not present in the entry)))
+	 (if (org-entry-delete nil property)
+	 deleted
+	 was not present in the entry)))
 
 (defun org-delete-property-globally (property)
   Remove PROPERTY globally, from all entries.
-- 
1.8.4

Re: [O] advice on ways to quicken refiling..perhaps a hotkey to refile to specific org file/header?

[Oleh]

 On Tue, Mar 4, 2014 at 6:19 PM, Xebar Saram zelt...@gmail.com wrote:
 Thx Oleh
  you said you dont refile much latley, is there a better solution ;-)


There is, actually.
It's quite simple: capture all the tasks into the proper place right away,
instead of dumping them into one place and sorting out later.

Firstly, there's capturing into project.
A project is just a heading at gtd.org/Projects/project-name.
Once a task is in a project, there's rarely any need to refile it.
I tag each task with the project tag anyway, just in case.
The project setup is a list entry like this:

'(TINY y tiny.el)

That's the tag, key binding and heading name. I push this data into
`org-capture-templates`.
Now I can capture into project gtd.org/Projects/tiny.el with C-- y.

Secondly, there's a special capture for pdf files, I've posted it on
the list before.

Thirdly, there are captures from `org-protocol`. I have this setup:

(setq org-protocol-default-template-key l)
(push '(l Link entry (function org-handle-link)
* TODO %(org-wash-link)\nAdded: %U\n%(org-link-hooks)\n%?)
  org-capture-templates)

`org-handle-link` will distinguish:

1. Links for StackOverflow questions, putting them in wiki/stack.org/Questions.
2. Links to YouTube, downloading the video with `youtube-dl` and including both
   the link to the original and the downloaded videos in the captured item.
   I highly recommend `youtube-dl`: watching videos in vlc compared to firefox
   is like editing in Emacs compared to gedit:)
3. All the rest will be dumped into ent.org/Articles.

`org-wash-link` currently just strips the unnecessary  - Stack
Overflow from the link description, since the task is already in
wiki/stack.org/Questions. It's possible to add other rules per website
of course.

Hopefully some of the described tricks are useful.
I can post the code on github if anyone's interested in the details.

regards,
Oleh

Re: [O] advice on ways to quicken refiling..perhaps a hotkey to refile to specific org file/header?

[Oleh]

 I can post the code on github if anyone's interested in the details.

 yes please :)


Posted here: https://github.com/abo-abo/org-fu

Oleh

[O] `org-attach-file-list' doesn't allow dotfiles

[Oleh]

Hi all,

I recently investigated why `org-open-at-point` uses smplayer to
open *.mp4 links, although the system's default is vlc.
The solution was to create ~/.mailcap with

video/mp4; vlc %s

I wanted to store this file as an attachment in an org document, so I
don't forget about it, but this attachment can't be opened due
to `org-attach-file-list` ignoring all files that start with a dot.

I would modify it like this to ignore just . and ..:

--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -425,7 +425,7 @@ This can be used after files have been added
externally.
   Return a list of files in the attachment directory.
 This ignores files starting with a \.\, and files ending in \~\.
   (delq nil
-   (mapcar (lambda (x) (if (string-match ^\\. x) nil x))
+   (mapcar (lambda (x) (if (string-match ^\\.\\.?$ x) nil x))
(directory-files dir nil [^~]\\'

Is there a reason behind this dot file restriction? Would anything break
if the proposed change was made?

regards,
Oleh

Re: [O] Get to next NEXT headline with one key

[Oleh]

 And commands work from start of #+... as well.


 Like this one.

Note that you have to use f to get to the first #+ that belongs to a heading.

 Here's how I've implemented the functionality that you want:

 j/k are bound move down/up just like in vim, but they move by
 headings or #+ markers.
 But K can change their behavior temporarily: it will prompt you for
 a char that corresponds to a keyword:
 t - TODO
 d - DONE
 n - NEXT
 c - CANCELLED

 After a keyword is set, j/k will move by this keyword instead,
 until any command other than j/k is issued (for instance m,
 which reveals heading). After that j/k will return to their
 regular behavior.


 Question: is there a particular reason for restricting keyword j/k movement
 only to
 - headlines at lower/equal levels (I get stuck in the subtree with the first
 NEXT)?
 - visible headlines (I miss folded NEXT entries)?

Restriction lifted.

 Still eventually I would like to pack those Knjm keys into just one key to
 replicate what is done by Matt my-org-next-next() function.

Doable by defining these functions on your own:

(defun set-keyword-next ()
  (interactive)
  (worf-keyword NEXT))

(defun set-keyword-done ()
  (interactive)
  (worf-keyword DONE))

After a call to `set-keyword-next`, j/k will move by NEXT
keyword until any other command is called.

 Do you think that the selection procedure of *helm* could be compatible with
 sth like ace-jump-line-mode? The problem then will be to find a good keyword
 also for activating the ace commands.

I think I see what you mean, but `helm` is already good enough in my
opinion.

I have mixed opinion of `ace-jump-mode`: on one hand it's fast, on the
other - it always requires you to focus and read: it can never become
muscle memory.

`helm`, on the other hand, is very nice in this respect: if you want
to go to a heading related to ice cream, you just

1. Press g for go.
2. Type ice.

This will usually give you just one candidate to you can C-m
right away.

If you're an ice enthusiast and there are many
matches (from 2 to 10), use C-n/C-p to select.

If you're obsessed with ice and there are more than 10 matches,
press space to narrow the candidates and type in something else:
ice age will match not only the movie, but Aged rice as well.
This should bring you to less than 10 matches.

This also works nicely with org mode: todo coffee :office will match
a TODO related to coffee with tag :OFFICE:.

 I think this is a good step towards the ultimate keystroke-minimizing
 editing environment... it's just a thousand key-bindings-to-memorize away,
 but I can see it!

Hopefully it's not a thousand.  Actually the whole Knj thing was my
attempt at minimizing the amount that you have to remember. I don't
know much about vim, but I've glimpsed its notion of verb-modifier-object,
at least the modifier-verb part: Kn is the modifier
(keyword-next) and j is the verb (down).  Or 4 is the modifier (4
times) and j is the verb etc.

You don't have to remember each combination together, you just have to
remember the components and combine them as you like. So my suggestion
for you is consider not defining `set-keyword-next` and binding it to
some random free key binding, but using Kn for a while, maybe it'll
grow on you.
I can think of one more use for Kn: Kn+ could add a heading with
keyword NEXT (+ is the verb to add an empty heading).

regards,
Oleh

Re: [O] Get to next NEXT headline with one key

[Oleh]

Hi Giacomo,

 Sorry for having been ambiguous, I meant the next headline with a NEXT
 todo keyword.

If you're feeling adventurous, you can try my new minor mode:
https://github.com/abo-abo/worf.

It's basically the same thing as speed commands, except it's got
different keys and different commands.
And commands work from start of #+... as well.

Here's how I've implemented the functionality that you want:

j/k are bound move down/up just like in vim, but they move by
headings or #+ markers.
But K can change their behavior temporarily: it will prompt you for
a char that corresponds to a keyword:
t - TODO
d - DONE
n - NEXT
c - CANCELLED

After a keyword is set, j/k will move by this keyword instead,
until any command other than j/k is issued (for instance m,
which reveals heading). After that j/k will return to their
regular behavior.

As an example:

So to move to the next NEXT, you can issue Knj.
One NEXT down after this: j.
Five NEXTs down: 5j.
Back to the first NEXT: 6k.

Same thing, but with DONE:

So to move to the next DONE, you can issue Kdj.
One DONE down after this: j.
Five NEXTs down: 5j.
Back to the first DONE: 6k.

And if you're trying out the mode, make sure to try g and h - those
are my two favorites. `helm` and `ace-jump-mode` respectively are required
in order for these commands to work. I'm planning to add the package to MELPA,
so the dependencies would be downloaded automatically, but I don't want to add
it until I've assigned all the alphanumeric keys:)

regards,
Oleh

[O] Links in tables: could the plain text also look good?

[Oleh]

Hi all,

I don't know if this issue has been raised before (it's a bit
difficult to google it).

I was just committing a single line change to an org-mode table into
git, and the diff isn't good at all: the whole table appears to have
changed. Well, not really - just a few spaces were added on each table
line because the single new line caused a need to re-align the whole
table.

So I'm thinking: if org-mode uses overlays for links to make some of
the real text invisible, why not keep the plain text aligned and use
the overlays to align the fontified text?

Having a good-looking plain text is an achievement in itself, but
using an smart allocation strategy (like std::vector growth) to add
more spaces than needed each time a column grows, would alleviate the
diff problem, i.e. the diff would show only a single line change most
of the time a line is added or removed.

I'd like some feedback on whether:

- it's done already and I just haven't enabled this behavior
- it can't be done because of some complex issue
- it can be done, but just isn't a priority

In the third case maybe some pointers on where to start implementing
would help.

regards,
Oleh

Re: [O] Screencast of lispy.el with org-mode code base

[Oleh]

Hi Bastien,

 One early neatpick: the name lispy does not help understanding
 what the package is really about.  But maybe the package does a
 lot and it's difficult to capture all what it does in a name.

The package provides a key binding method that can work effectively
only for a Lisp-like language: Elisp, Scheme, Common Lisp and Clojure
all fit here.
The gist is that e.g. j will not self-insert when positioned at open
paren or after closing paren, but will instead move downwards list.

On top of that I've tacked on:

- my own type of Paredit: most functions are called from either
  side of the list and the result depends on the side.

- region manipulation based on sexps,
  e.g. j will extend/shrink region by a sexp forwards and k backwards.

- outline-minor-mode bindings
  `lispy-shifttab` (I) actually uses `org-overview` and `org-cycle`.

- IDE-like features (eval, eval-and-insert, inline doc, arglist,
  jump-to-tag and follow-to-definition)

- some refactoring support (defun-to-lambda, lambda-to-defun, inline-function,
  cond-to-ifs, ifs-to-cond, sexp-to-oneline, sexp-to-multiline,
string-to-oneline)

  I'm especially proud of the cond-to-ifs / ifs-to-cond stuff, because they
  (in theory and once properly debugged) preserve whitespace and comments
  and are invertible.

- misc stuff (bindings for edebug, multiple cursors, ediff-sexps)

  I'm quite fond of `lispy-ediff-regions` as well. Try it if you like
  `ediff-regions-linewise`.

So it's a bunch of stuff, all of it Lisp-related, hence lispy.

Btw, here's the new documentation: http://abo-abo.github.io/lispy/.
It's generated with org-mode export of this file:
https://raw.github.com/abo-abo/lispy/gh-pages/index.org.

Actually, I have a few questions on the org to HTML export of this document:

How do I make HTML links that refer to heading, e.g.
not http://abo-abo.github.io/lispy/#sec-3-1,
but http://abo-abo.github.io/lispy/#lispy-forward?

And is there a good method to put babel source blocks into a HTML table?
I'm just using #+HTML: at the moment and it's pretty ugly.

regards,
Oleh

Re: [O] Screencast of lispy.el with org-mode code base

[Oleh]

 How do I make HTML links that refer to heading, e.g.
 not http://abo-abo.github.io/lispy/#sec-3-1,
 but http://abo-abo.github.io/lispy/#lispy-forward?

 Isn't this a use case for CUSTOM_ID (instead of ID)?  In this case,
 you'd name it `lispy-forward'...


Thanks again, Sebastien,

I'm off to make an epic macro to replace all those ID with CUSTOM_ID.

regards,
Oleh

Re: [O] How to ensure that (org-get-heading) is pretty?

[Oleh]

 I'm working on a helm interface to org headings.

 Doesn't it already exist?  What about:

   ╭
   │ helm-org-headlines is an interactive autoloaded compiled Lisp function in
   │ `helm-org.el'.
   │
   │ It is bound to menu-bar tools Helm Org Org headlines.
   │
   │ (helm-org-headlines)
   │
   │ Preconfigured helm to show org headlines.
   ╰

 Do you want to write something else?


Thanks, Sebastien,

I wasn't aware of `helm-org-headlines`.
I've just tried it and I like my implementation better,
exactly because my implementation is using font-locked strings, while
`helm-org-headlines` uses plain strings.
And I don't like the whole menu-like interface.
A list is better in my opinion.

So the question still stands.

regards,
Oleh

Re: [O] advice on ways to quicken refiling..perhaps a hotkey to refile to specific org file/header?

[Oleh]

I have this in my config, although I don't refile that much lately:

(setq org-refile-targets
  '((nil :maxlevel . 3)
(org-agenda-files :maxlevel . 3)))

This should give you an ido choice of all headings up to level 3 in
all your agenda files
as refile targets. Then just give a few headings a unique enough name
and you're done.

regards,
Oleh

On Tue, Mar 4, 2014 at 4:43 PM, Xebar Saram zelt...@gmail.com wrote:
 Hi all

 i find the normal C-c w then manually choosing a file to allocate each
 'capture' pretty slow. i am looking for any advice on workflows you guys
 have to make this quicker.

 one thing i was thinking of was maybe assigning a hotkey to do a refile to a
 specific note/heading. so ill have 5-6 hotkeys to my most common files to
 speed things up, can this be done? if so can anyone show my an example of
 such a thing?

 kind regards

 Z.

[O] How to ensure that (org-get-heading) is pretty?

[Oleh]

Hi all,

I'm working on a helm interface to org headings.
To get the candidates, I'm using `org-map-entries` and `org-get-heading`
(see `worf-goto` function at: https://github.com/abo-abo/worf)

If the document is fully expanded it works fine, but when it's
initially folded and hasn't been
expanded yet, `org-get-heading` returns a plain string.

What's a proper way to make `org-get-heading` always return a fontified string?

regards,
Oleh