Re: [O] inline images (png/jpg) are not displayed

[Nick Dokos]

Uwe Brauer  writes:

 "Uwe" == Uwe Brauer  writes:
>
>> Hi
>> I am using emacs 26 (kubuntu 14.04) and I can open png and images files
>> and they are displayed correctly so I presume png/jpg support is
>> compiled in.
>
>> I added the following to my org file
>> [[myimage.png]]
>> and set
>> org-startup-with-inline-images to t
>
> Sorry the syntax should be
> [[file:myimage.png]]
> then the image is displayed for a couple of seconds then disappeared.
>

Maybe you have a timer that toggles it off after a while? I don't think org is 
doing the
toggling (and it does not happen in my experiments). Try evaluating 
(timer-list) in that
buffer.

>
> -  how can I resize the image, it is far too large.
>

C-h v org-image-actual-width RET

-- 
Nick

Re: [O] Org unique id behavior changed?

[John Hendy]

On Fri, Feb 3, 2017 at 4:23 PM, Nicolas Goaziou  wrote:
> Hello,
>
> John Hendy  writes:
>
>> I just tried to recreate a unique id link from the mailing list and
>> was surprised to find that =C-c l= did not create a unique id
>> automatically.
>>
>> From the manual:[1]
>>
>> C-c l (org-store-link)
>> ...
>> If the headline has a CUSTOM_ID property, a link to this custom ID
>> will be stored. In addition or alternatively (depending on the value
>> of org-id-link-to-org-use-id), a globally unique ID property will be
>> created and/or used to construct a link (jwh adding: if org-id is
>> loaded).
>>
>>
>>
>> Here's my min config:
>>
>> #+begin_example
>>
>> (add-to-list 'load-path "~/.elisp/org/lisp/")
>> (add-to-list 'load-path "~/.elisp/org/contrib/lisp")
>>
>> (require 'org-id)
>> (global-set-key "\C-cl" 'org-store-link)
>> (setq org-link-to-org-use-id 'create-if-interactive)
>>
>> #+end_example
>>
>>
>>
>> Starting emacs with =emacs -Q= and then =M-x load-file ~/path/to/min-config=
>>
>>
>> File:
>>
>> #+begin_example
>>
>> * Alcohol^
>>
>> Something
>>
>> \newpage
>>
>> * Another heading
>>
>> Blah blah blah, see
>>
>> #+end_example
>>
>>
>>
>> With cursor at ^, I do =C-c l= and get this in the mini-buffer:
>> =Stored: Alcohol=
>>
>> When trying to insert with =C-c C-l= I get this auto-completion suggestion:
>>
>> Alcohol  
>> 
>>
>> Normally that would have a unique-id, not file path/headline.
>>
>> Org mode version 9.0.2 (release_9.0.2-140-g1c8908 @
>> /home/jwhendy/.elisp/org/lisp/)
>>
>> Is this on my end (settings) or did something change? Doing this
>> definitely used to generate a unique id property drawer under the
>> linked headline and suggest it when going to insert the link
>> elsewhere.
>
> FWIW, I cannot reproduce this issue.

Wow. I just wrote a response re-replicating my behavior and then went
to check the value of the variable to be sure!

org-id-link-to-org-use-id is a variable defined in ‘org-id.el’.
Its value is nil

That's interesting. So what did I set in my config??

(setq org-link-to-org-use-id 'create-if-interactive)

I changed to the correct variable name and all is well. Sorry for the
noise; it appears this is a super old variant of the variable based on
references I find on the web:
- http://git.net/ml/emacs-orgmode-gnu/2012-04/msg01203.html
- 
http://orgmode.org/w/?p=org-mode.git;a=commitdiff_plain;h=4b4328e29b2c286505c7f0be0e54a37a8d1fbc75

I must not have caught a change at some point but I *swear* it was
working within the last year.


John

>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Org unique id behavior changed?

[Nicolas Goaziou]

Hello,

John Hendy  writes:

> I just tried to recreate a unique id link from the mailing list and
> was surprised to find that =C-c l= did not create a unique id
> automatically.
>
> From the manual:[1]
>
> C-c l (org-store-link)
> ...
> If the headline has a CUSTOM_ID property, a link to this custom ID
> will be stored. In addition or alternatively (depending on the value
> of org-id-link-to-org-use-id), a globally unique ID property will be
> created and/or used to construct a link (jwh adding: if org-id is
> loaded).
>
>
>
> Here's my min config:
>
> #+begin_example
>
> (add-to-list 'load-path "~/.elisp/org/lisp/")
> (add-to-list 'load-path "~/.elisp/org/contrib/lisp")
>
> (require 'org-id)
> (global-set-key "\C-cl" 'org-store-link)
> (setq org-link-to-org-use-id 'create-if-interactive)
>
> #+end_example
>
>
>
> Starting emacs with =emacs -Q= and then =M-x load-file ~/path/to/min-config=
>
>
> File:
>
> #+begin_example
>
> * Alcohol^
>
> Something
>
> \newpage
>
> * Another heading
>
> Blah blah blah, see
>
> #+end_example
>
>
>
> With cursor at ^, I do =C-c l= and get this in the mini-buffer:
> =Stored: Alcohol=
>
> When trying to insert with =C-c C-l= I get this auto-completion suggestion:
>
> Alcohol  
> 
>
> Normally that would have a unique-id, not file path/headline.
>
> Org mode version 9.0.2 (release_9.0.2-140-g1c8908 @
> /home/jwhendy/.elisp/org/lisp/)
>
> Is this on my end (settings) or did something change? Doing this
> definitely used to generate a unique id property drawer under the
> linked headline and suggest it when going to insert the link
> elsewhere.

FWIW, I cannot reproduce this issue.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: org-agenda-only-exact-dates [9.0.4 (9.0.4-elpa @ c:/Users/atamulis/.emacs.d/elpa/org-20170124/)]

[Nicolas Goaziou]

Hello,

"Tamulis, Andrius"  writes:

> I note that in the latest version of orgmode, that the
> org-agenda-only-exact-dates variable is no longer "honored". It is set
> twice in org-agenda.el, but never checked, and so affects nothing.
>
> When this functionality was deleted,

This variable is not documented in the manual. It has no docstring
either. I see no functionality here, only an obscure dynamically scoped
parameter.

If I had to make a guess about its use, I would say it is an internal
variable for the Timeline functionality, which is removed from master.

> was any thought given to how one
> may recreate the action of this variable? That is, in orgmode
> 9.0.4, how can I create an agenda that only shows entries whose exact
> timestamp, scheduled or deadline, is the given day? And that ignores
> "Sched. nx" and "In m d." entries?

I assume binding both `org-deadline-warning-days' and
`org-scheduled-past-days' to 0 would be a start. Also, you could bind
`org-agenda-span' to `day'. 

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Log mode shows the wrong clock note [9.0.4 (9.0.4-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20170124/)]

[Nicolas Goaziou]

Hello,

Jorge Morais Neto  writes:

> In log mode, after each clock line the agenda should show the corresponding
> clock note.  Instead, it shows the clock note for the previous clock line.
> For example, with the entry
>
>   *** Espe2016 exp
>   :PROPERTIES:
>   :CREATED:  [2017-01-27 Sex 16:50]
>   :CATEGORY: ponto exp
>   :END:
>   :LOGBOOK:
>   CLOCK: [2017-02-03 Sex 08:16]--[2017-02-03 Sex 08:28] =>  0:12
>   - Saindo agora para o almoço.
>   CLOCK: [2017-01-27 Sex 10:28]--[2017-01-27 Sex 11:13] =>  0:45
>   CLOCK: [2017-01-26 Qui 13:45]--[2017-01-26 Qui 14:44] =>  0:59
>   :END:
>
> The agenda for [2017-02-03 Sex] shows:
>
>   ponto exp:   8:16- 8:28 Clocked:   (0:12) Espe2016 exp - Saindo
> agora para o almoço.

The fix for the other issue you reported about CLOCK and notes probably
has also fixed this one. Could you confirm it?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Org separates clock out note from the clock line [9.0.4 (9.0.4-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20170124/)]

[Nicolas Goaziou]

Hello,

Jorge Morais Neto  writes:

> Hi.  I have started this instance of GNU Emacs 25.1.91.1 with an empty init
> file and then I customized org-log-note-clock-out to t.  Then I created a
> new Org buffer with a single level 1 headline, and set property
> CLOCK_INTO_DRAWER to nil.  I then clocked in and then out, adding a note.
> The note was stored outside any drawer (as requested) and above the clock
> line.  Then I clocked in and out again, adding a second note.  The result
> was:
>
>   * Teste
> :PROPERTIES:
> :CLOCK_INTO_DRAWER: nil
> :END:
> - Teste 2.
> - Teste 1.
> CLOCK: [2017-01-31 Tue 14:12]--[2017-01-31 Tue 14:13] =>  0:01
> CLOCK: [2017-01-31 Tue 14:12]--[2017-01-31 Tue 14:12] =>  0:00
>
> "teste" is Portuguese for "test".
>
> I expected the "Teste 1" line to stay in its place above the corresponding
> clock line, like this:
>
>   * Teste
> :PROPERTIES:
> :CLOCK_INTO_DRAWER: nil
> :END:
> - Teste 2.
> CLOCK: [2017-01-31 Tue 14:12]--[2017-01-31 Tue 14:13] =>  0:01
> - Teste 1.
> CLOCK: [2017-01-31 Tue 14:12]--[2017-01-31 Tue 14:12] =>  0:00

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: clock comments [9.0.2 (9.0.2-elpaplus @ c:/USR/FJM/APP/.emacs.d/elpa/org-plus-contrib-20161214/)]

[Nicolas Goaziou]

Correcting myself,

Nicolas Goaziou  writes:

> I considered re-introducing the behaviour you suggest, but there is one
> issue.
>
> When `org-clock-into-drawer' is set to an integer, an the number of
> clocks in the entry get past it, all pre-existing clocks are moved to
> log drawer (by default "LOGBOOK"). Unfortunately, it is not possible to
> preserve association between the note and the clock (i.e., the list item
> after the clock may or may not be a note relative to the clock). So we
> cannot guarantee that both the note and the clock are always kept
> together.
>
> Basically, the two features are incompatible.
>
> I'm open to suggestions.

Due to another bug report related to CLOCK lines, notes are again
attached to CLOCK lines, which should fix your initial report.

As another consequence, the issue above now belongs to the code base.

I'm still open to suggestions.

Regards,

Re: [O] more global keys in ox-bibtex

[Nicolas Goaziou]

Hello,

Sébastien Le Maguer  writes:

> I did a mini-patch to capture completely the key in bibtex export. For 
> example for the following key, in the bibtex2html produced file:
>
> Balestri et al., 1999
>
> only Balestri will be captured instead of Balestri et al., 1999
>
> As it is 3 characters, I just submit the patch here and hope it might
> help :)

Thank you.

Would you mind sending it using git format-patch and adding a commit
message?

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] ox.el: Slovenian translations for exporting

[Nicolas Goaziou]

Hello,

Martin Vuk  writes:

> I would like to propose Slovenian translations for exporting orgmode
> documents. Patch is attached.

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] [Ann] Tool to hack time

[Christian Moe]

Here I was, hoping it was a tool to *actually* hack time.

You know, M-x tardis-mode.

:-)

Yours,
Christian



Marco Wahl writes:

> Dear Orgers,
>
> https://gitlab.com/marcowahl/hack-time is a little tool to forge the
> `current-time' in Emacs.  This allows to mark todo-items done
> conveniently at another date.
>
> Maybe you want to play with that time forgery.
>
> Comments welcome, as always.
>
>
> Best regards
>
>Marco

Re: [O] Is it possible to "properly" indent inside latex fragments?

[Nicolas Goaziou]

Hello,

alain.coch...@unistra.fr writes:

> Great, thanks a lot.  Looking forward to using it (I guess it will be
> available in the version following 9.0.4?).

Indeed.

> I have one (minor) question/concern, though: will the indentation
> survive an 'M-x indent-region' or 'M-x org-indent-region'?

It should, now. Thank you for the heads up.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] inline images (png/jpg) are not displayed

[Uwe Brauer]

>>> "Uwe" == Uwe Brauer  writes:

   > Hi
   > I am using emacs 26 (kubuntu 14.04) and I can open png and images files
   > and they are displayed correctly so I presume png/jpg support is
   > compiled in.

   > I added the following to my org file
   > [[myimage.png]]
   > and set
   > org-startup-with-inline-images to t

Sorry the syntax should be
[[file:myimage.png]]
then the image is displayed for a couple of seconds then disappeared.

-  how can I configure the display time?

-  how can I resize the image, it is far too large.

Thanks

Uwe Brauer 

[O] inline images (png/jpg) are not displayed

[Uwe Brauer]

Hi

I am using emacs 26 (kubuntu 14.04) and I can open png and images files
and they are displayed correctly so I presume png/jpg support is
compiled in.

I added the following to my org file
[[myimage.png]]
and set
org-startup-with-inline-images to t

Then I reopened the file, but the image was not displayed.

What do I miss?

Thanks

Uwe Brauer 

Re: [O] fill text (indent) in lists

[Samuel Wales]

i use filladapt for things org's and emacs's filling mechanisms do not
do.  it usually does exactly what i want, but i recall i had to change
an alist.

-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it.

Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free

Re: [O] Feature request: lists with letters

[William Denton]

On 3 February 2017, Rainer M Krug wrote:


I must admit, I haven't read the thread mentioned, and I am sure
Carsten's point was correct, but orgmode is more and more used for
non-structure tasks. As an example I see the whole field of reproductive
research and scientific paper writing, which, in my opinion, has many
more elements than structure. Another example are html emails (like them
or not - I also dislike them) which people compose in org, or org as a
LaTeX frontend.

Exporting, i.e. typesetting and sharing, becomes much more important
these days and possibly as important as the structure.

In a nutshell: I agree with Titus' point and also would love to have
alphabetical bullets.


I'm all in favour too, and hope that someone might implement this.

Bill
--
William Denton :: Toronto, Canada :: https://www.miskatonic.org/
Caveat lector.

Re: [O] Sync up the org in emacs master to org maint branch?

[David Engster]

John Wiegley  writes:
>> "DE" == David Engster  writes:
>
> DE> So if you don't get convinced, we'll just move again, right? No big deal.
>
> I suppose I'm asking that of you, yes.

Sorry, but I rather wait.

> DE> You are insinuating that my motivation is to delegate CEDET development to
> DE> the core Emacs developers. This is simply not true, and I don't see how my
> DE> original mail could be interpreted like that.
>
> I didn't mean to insinuate anything; it seems we may have gotten off on the
> wrong foot, my intention is to make your life easier, not harder. If all this
> would do is make more work for people, it's not worth it.

This will most definitely make things harder for me. 

> DE> So let me try again: What I find completely misguided is to move packages
> DE> out of core *but still putting them into the release*. In other words, in
> DE> my opinion there are really just two options that make sense: you either
[+]
> DE> keep a package in core, or you kick it out and don't ship it with the
> DE> release.
>
> Why is this so? Right now I see the Emacs release as more than just releasing
> Emacs core; it's more of a "batteries included" release, combining the editor
> with lots of other default packages. It makes sense to me to move these
> batteries outside the core repository, than to put them all together in the
> same Git repository.

For package developers, keeping up with Emacs has become much harder in
recent years, as its development has accelerated (which is a good
thing). It's not like packages communicate with Emacs over a well
defined RESTful interface. In other words: CEDET and Gnus are not
loosely coupled, quite the opposite: they are extremely dependend on
many obscure Emacs internals (not sure about Org). As a consequence, we
and also the Gnus guys decided to not do separate releases anymore.  We
used to provide CEDET for different Emacs versions, and it was a *huge*
amount of work. I had a buildbot running with 7 or 8 Emacs versions to
run the test suite, and things broke pretty regularly.

Now you might say: fine, only release a package for current master. But
let's say we put CEDET into ELPA. Emacs 26 gets released, and work on
Emacs 27 starts. Now there are changes happening in Emacs 27 that
require changes in CEDET, which make it incompatible with Emacs 26. So
you have to create two packages: one for 26, one for 27? Not only is
this confusing, but it most definitely increases my workload.

> We can arrange things so that a Git clone of Emacs includes pulling the
> submodules (or trees, or ELPA.git, or what not) that are considered part of
> "main Emacs development", including some of those batteries. I see this all as
> a process issue, and that "living in one Git repository" has just been an
> implementation strategy to satisfy that process.

Obviously, I'm very skeptical towards such an approach. Our tooling
around Emacs development is already very intricate and only works
because a few people work quietly behind the scenes to keep this all
running. Introducing even more complexity through
submodules/subtrees/whatever will do the opposite of what you want to
achieve: it creates more work for those few people who manage the Emacs
infrastructure. But I'd love to hear what for instance Glenn and Paul
think about this.

> Why do the split at all? Core becomes smaller,

First off, the Emacs repo isn't that big w.r.t. the number of
files. Secondly, while there surely is an inverse correlation between
repo size and maintainability, I would argue that as long as the Big
Three are well maintained, they are not the problem. When did CEDET,
Gnus or Org ever significantly delay an Emacs release?  When was an
Emacs core developer ever forced to fix a critical thing in those
packages he did not break?  These are the questions we should be
asking. From watching this list over the past years, I don't get the
feeling that the inclusion of these packages has been a significant
burden, but I may be wrong.

> its future history less cluttered,

That's actually a bit funny, since we gave up an uncluttered history
when we switched to git's spaghetti DAG.

> updating packages within it is no longer a major issue, and (I hope)
> it will be clearer when something is a core issue vs. a package issue.

I find this whole core vs package argument strange. If you ship Emacs
with Org, Gnus and CEDET, they are part of Emacs, so it's in the
interest of all Emacs developers that they work well, whether they use
them or not. The users won't care if they originate from a separate repo
and are considered a "package". So if Paul is determined to fix all
occurences of "compatilibity" in the doc-strings, why would he only do
that for core?  People won't care if it's a CEDET doc-string, they'd
just say "Teh Emacs people cant spell!1!!". It's no big deal for him
anyway if everything is in one repo. Likewise when Stefan does some
refactoring, like renaming 'defmethod' to 'cl-defmethod'. Doing this for
all files 

[O] [Ann] Tool to hack time

[Marco Wahl]

Dear Orgers,

https://gitlab.com/marcowahl/hack-time is a little tool to forge the
`current-time' in Emacs.  This allows to mark todo-items done
conveniently at another date.

Maybe you want to play with that time forgery.

Comments welcome, as always.


Best regards

   Marco

Re: [O] Allowing multiple date trees in a single file

[Carsten Dominik]

Hi Nicolas,

ok, here is where I have gotten with this:

Attached is a patch that does the following:

It consolidates all four different org-capture target types that have to do
with
date/week trees into a single one, called `file+olp+datetree'.  This target
allows for an optional outline path specification to tell capture to build
the
datetree under a specific headline.  To switch to a week tree, or to force
a date prompt is now the matter of setting one of the properties in the
org-capture-template variable.

Everything works transparently, so users can update the way they
write their datetree captures, but they don't have to - the old syntax
remains
supported and will automatically switched when one uses customize to change
the variable.

After a bit more testing, I'd like to apply this patch.  Please let me know
if you agree. And additional testers would be useful.  Anyone?  Make sure
to backup your capture templates if something goes wrong.

Cheers

Carsten





On Wed, Jan 18, 2017 at 12:23 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Carsten Dominik  writes:
>
> > I meant
> >
> > :DATE_TREE: my_diary
> > :DATE_TREE: food_and_health
> > :DATE_TREE: movies watched
>
> It sounds less useful because we already have ways to identify uniquely
> a heading.
>
> > Another thing I was thinking is a way to force prompting for a date, for
> > example through a prefix argument, so that a single capture template
> could
> > be used for using the current date and optionally a set one.
>
> It is nice, too. It would reduce the number of new capture target types
> required.
>
> Regards,
>
> --
> Nicolas Goaziou
>


datetree-patch
Description: Binary data

[O] [PATCH] ox.el: Slovenian translations for exporting

[Martin Vuk]

I would like to propose Slovenian translations for exporting orgmode 
documents. Patch is attached.


Best Regards,

Martin Vuk

>From 0b22387d519201174a562fe07832354619dea6e1 Mon Sep 17 00:00:00 2001
From: Martin Vuk 
Date: Fri, 3 Feb 2017 12:05:50 +0100
Subject: [PATCH] ox.el: Slovenian translations for exporting
To: emacs-orgmode@gnu.org

* lisp/ox.el (org-export-dictionary): Slovenian translations.

* lisp/ox.el (org-export-smart-quotes-alist): Slovenian quotes and
apostrophes for exporting documents.

TINYCHANGE
---
 lisp/ox.el | 45 +++--
 1 file changed, 39 insertions(+), 6 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 93f4437..3aeb56b 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5399,6 +5399,17 @@ Return a list of src-block elements with a caption."
  (secondary-closing
   :utf-8 "“" :html "“" :latex "\\grqq{}" :texinfo "@quotedblleft{}")
  (apostrophe :utf-8 "’" :html: "'"))
+("sl"
+ ;; based on https://sl.wikipedia.org/wiki/Narekovaj
+ (primary-opening :utf-8 "«" :html "«" :latex "{}<<"
+		  :texinfo "@guillemetleft{}")
+ (primary-closing :utf-8 "»" :html "»" :latex ">>{}"
+		  :texinfo "@guillemetright{}")
+ (secondary-opening
+  :utf-8 "„" :html "„" :latex "\\glqq{}" :texinfo "@quotedblbase{}")
+ (secondary-closing
+  :utf-8 "“" :html "“" :latex "\\grqq{}" :texinfo "@quotedblleft{}")
+ (apostrophe :utf-8 "’" :html "’"))
 ("sv"
  ;; based on https://sv.wikipedia.org/wiki/Citattecken
  (primary-opening :utf-8 "”" :html "”" :latex "’’" :texinfo "’’")
@@ -5637,6 +5648,7 @@ them."
  ("pl" :default "Autor")
  ("pt_BR" :default "Autor")
  ("ru" :html "Автор" :utf-8 "Автор")
+ ("sl" :default "Avtor")
  ("sv" :html "Författare")
  ("uk" :html "Автор" :utf-8 "Автор")
  ("zh-CN" :html "作者" :utf-8 "作者")
@@ -5651,7 +5663,8 @@ them."
  ("nl" :default "Vervolg van vorige pagina")
  ("pt" :default "Continuação da página anterior")
  ("ru" :html "(Продолжение)"
-  :utf-8 "(Продолжение)"))
+  :utf-8 "(Продолжение)")
+ ("sl" :default "Nadaljevanje s prejšnje strani"))
 ("Continued on next page"
  ("ar" :default "التتمة في الصفحة التالية")
  ("de" :default "Fortsetzung nächste Seite")
@@ -5662,7 +5675,10 @@ them."
  ("nl" :default "Vervolg op volgende pagina")
  ("pt" :default "Continua na página seguinte")
  ("ru" :html "(Продолжение следует)"
-  :utf-8 "(Продолжение следует)"))
+  :utf-8 "(Продолжение следует)")
+ ("sl" :default "Nadaljevanje na naslednji strani"))
+("Created"
+ ("sl" :default "Ustvarjeno"))
 ("Date"
  ("ar" :default "بتاريخ")
  ("ca" :default "Data")
@@ -5684,6 +5700,7 @@ them."
  ("pl" :default "Data")
  ("pt_BR" :default "Data")
  ("ru" :html "Дата" :utf-8 "Дата")
+ ("sl" :default "Datum")
  ("sv" :default "Datum")
  ("uk" :html "Дата" :utf-8 "Дата")
  ("zh-CN" :html "日期" :utf-8 "日期")
@@ -5703,6 +5720,7 @@ them."
  ("pt_BR" :html "Equação" :default "Equação" :ascii "Equacao")
  ("ru" :html "Уравнение"
   :utf-8 "Уравнение")
+ ("sl" :default "Enačba")
  ("sv" :default "Ekvation")
  ("zh-CN" :html "方程" :utf-8 "方程"))
 ("Figure"
@@ -5734,6 +5752,7 @@ them."
  ("nn" :default "Illustrasjon %d")
  ("pt_BR" :default "Figura %d:")
  ("ru" :html "Рис. %d.:" :utf-8 "Рис. %d.:")
+ ("sl" :default "Slika %d")
  ("sv" :default "Illustration %d")
  ("zh-CN" :html "图%d " :utf-8 "图%d "))
 ("Footnotes"
@@ -5758,6 +5777,7 @@ them."
  ("pl" :default "Przypis")
  ("pt_BR" :html "Notas de Rodapé" :default "Notas de Rodapé" :ascii "Notas de Rodape")
  ("ru" :html "Сноски" :utf-8 "Сноски")
+ ("sl" :default "Opombe")
  ("sv" :default "Fotnoter")
  ("uk" :html "Примітки"
   :utf-8 "Примітки")
@@ -5775,6 +5795,7 @@ them."
  ("nb" :default "Dataprogrammer")
  ("ru" :html "Список распечаток"
   :utf-8 "Список распечаток")
+ ("sl" :default "Seznam programskih izpisov")
  ("zh-CN" :html "代码目录" :utf-8 "代码目录"))
 ("List of Tables"
  ("ar" :default "قائمة بالجداول")
@@ -5791,6 +5812,7 @@ them."
  ("pt_BR" :default "Índice de Tabelas" :ascii "Indice de Tabelas")
  ("ru" :html "Список таблиц"
   :utf-8 "Список таблиц")
+ ("sl" :default "Seznam tabel")
  ("sv" :default "Tabeller")
  ("zh-CN" :html "表格目录" :utf-8 "表格目录"))
 ("Listing"
@@ -5806,6 +5828,7 @@ them."
  ("pt_BR" :default "Listagem")
  ("ru" :html "Распечатка"
   :utf-8 "Распечатка")
+ ("sl" :default "Izpis programa")
  ("zh-CN" :html "代码" :utf-8 "代码"))
 ("Listing %d:"
  ("ar" :default "برنامج %d:")
@@ -5820,18

Re: [O] Feature request: lists with letters

[Titus von der Malsburg]

On 2017-02-03 Fri 12:40, Eric S Fraga wrote:
> On Friday,  3 Feb 2017 at 11:37, Titus von der Malsburg wrote:
>
> [...]
>
>> For me and many others, this is a very common use case.  I challenge you
>> to implement this with current Org such that it will export correctly to
>> HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
>
> #+begin_src org
>   Sensation, perception, and memory are of particular
>   interest to which group of contemporary psychologists?
>
>   1. psychoanalysts
>   2. behaviorists
>   3. humanistic psychologists
>   4. <> cognitive psychologists
>
>   The correct answer is [[answer]] because 
> #+end_src
>
> does the job for both LaTeX and HTML although with a number in this
> case.  I have not tried with alphabetical enumeration.

This is nice, but letters are conventionally used in many contexts and I
think making it work with letters is much harder.

  Titus



-- 
Dr. Titus von der Malsburg
Visiting Professor for Computational Psycholinguistics
Department of Linguistics
University of Potsdam, Germany
https://tmalsburg.github.io
PGP fingerprint: C34C 7364 EAAD 4752 FABA  35E6 AE34 59F3 C613 689D
GNU Ring ID: ring:a1494601ee7d214bdfd8105dca065aee6d653556


signature.asc
Description: PGP signature

Re: [O] [PATCH] Support time units in est+

[Malcolm Matalka]

Hello, has anyone had an opportunity to review this?  Thank you.

Den 18 jan. 2017 9:33 em skrev "Malcolm Matalka" :

> Hey, this is my first elisp programming so I'm quite certain this is a
> big hack.  I just stole elements from elsewhere in the file.  I'm hoping
> this is good enough to get accepted then perhaps someone with more taste
> would be able to refactor it to be a bit better.
>
> Let me know if I need to change anything.
>
> From 1167bd20e042ad2ae3f2712f596d76ad8b230336 Mon Sep 17 00:00:00 2001
> From: orbitz 
> Date: Wed, 18 Jan 2017 21:18:23 +0100
> Subject: [PATCH] org-colview.el: Add support for time units to est+
>
> * lisp/org-colview.el: Add support for time units in est+.  Ranges are
> interpreted just like non-range estimates.
>
> TINYCHANGE
> ---
> lisp/org-colview.el | 44 
> 1 file changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/lisp/org-colview.el b/lisp/org-colview.el
> index 45c71a028..2a5c067ac 100644
> --- a/lisp/org-colview.el
> +++ b/lisp/org-colview.el
> @@ -1288,23 +1288,43 @@ When PRINTF is non-nil, use it to format the
> result."
> (/ (apply #'+ (mapcar #'org-columns--age-to-seconds ages))
>(float (length ages)
>
> -(defun org-columns--summary-estimate (estimates printf)
> +(defun org-columns--summary-estimate (estimates _)
>"Combine a list of estimates, using mean and variance.
> The mean and variance of the result will be the sum of the means
>  and variances (respectively) of the individual estimates."
>(let ((mean 0)
> -(var 0))
> +(var 0)
> +(hms-flag nil)
> +(duration-flag nil))
>  (dolist (e estimates)
> -  (pcase (mapcar #'string-to-number (split-string e "-"))
> -(`(,low ,high)
> - (let ((m (/ (+ low high) 2.0)))
> -   (cl-incf mean m)
> -   (cl-incf var (- (/ (+ (* low low) (* high high)) 2.0) (* m m)
> -(`(,value) (cl-incf mean value
> -(let ((sd (sqrt var)))
> -  (format "%s-%s"
> -  (format (or printf "%.0f") (- mean sd))
> -  (format (or printf "%.0f") (+ mean sd))
> +  (pcase (split-string e "-")
> +(`(,low ,high)
> + (dolist (time (list high low))
> +   (cond
> +(duration-flag)
> +((string-match-p org-columns--duration-re time)
> + (setq duration-flag t))
> +(hms-flag)
> +((string-match-p "\\`[0-9]+:[0-9]+:[0-9]+\\'" time)
> + (setq hms-flag t
> + (let* ((low-sec (org-columns--time-to-seconds low))
> +(high-sec (org-columns--time-to-seconds high))
> +(m (/ (+ low-sec high-sec) 2.0)))
> +   (cl-incf mean m)
> +   (cl-incf var (- (/ (+ (* low-sec low-sec) (* high-sec
> high-sec)) 2.0) (* m m)
> +(`(,value) (cl-incf mean (org-columns--time-to-seconds value)
> +(let* ((sd (sqrt var))
> +   (low-second (truncate (- mean sd)))
> +   (high-second (truncate (+ mean sd)))
> +   (low
> +(cond (duration-flag (org-minutes-to-clocksum-string (/
> low-second 60.0)))
> +  (hms-flag (format-seconds "%h:%.2m:%.2s" low-second))
> +  (t (format-seconds "%h:%.2m" low-second
> +   (high
> +(cond (duration-flag (org-minutes-to-clocksum-string (/
> high-second 60.0)))
> +  (hms-flag (format-seconds "%h:%.2m:%.2s" high-second))
> +  (t (format-seconds "%h:%.2m" high-second)
> +  (format "%s-%s" low high
>
>
>
> --
> 2.11.0
>
>

Re: [O] Feature request: lists with letters

[Eric S Fraga]

On Friday,  3 Feb 2017 at 11:37, Titus von der Malsburg wrote:

[...]

> For me and many others, this is a very common use case.  I challenge you
> to implement this with current Org such that it will export correctly to
> HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no

#+begin_src org
  Sensation, perception, and memory are of particular
  interest to which group of contemporary psychologists?

  1. psychoanalysts
  2. behaviorists
  3. humanistic psychologists
  4. <> cognitive psychologists

  The correct answer is [[answer]] because 
#+end_src

does the job for both LaTeX and HTML although with a number in this
case.  I have not tried with alphabetical enumeration.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.3-262-g5210de


signature.asc
Description: PGP signature

Re: [O] Feature request: lists with letters

[Titus von der Malsburg]

Eric Abrahamsen wrote:
>> Titus von der Malsburg  writes:
>>
>>> Correct me if I’m wrong but there are a lot of things in Org that are
>>> just about typesetting: *bold*, /italic/, _underlined_, =verbatim= and
>>> ~code~, +strike-through+.  Would you remove these things as well?
>>
>> I could argue that emphasis is not just about typesetting. It conveys
>> a meaning. How emphasis is rendered _is_ typesetting, however. For
>> example, "latex" and "beamer" export back-ends render bold text
>> differently.
>
>It's similar to how HTML went from  and  to  and .
>The former were presentation directives. The latter are semantic
>directives. They're practically the same, for reasons of backwards
>compatibility, and conceptual continuity. Org's emphasis markers are
>similar -- they *look* like presentation directives, but at this point
>they're actually used as semantic directives.

Hi Eric,

I appreciate that it makes sense to make Org more consistent and to use
abstract principles to guide its design.  However, I’m not convinced by
the analogy to HTML since there are some crucial differences between Org
and HTML.

First, HTML is not supposed to be read by humans – it is code.  In
contrast to that, Org is supposed to be human readable and hence, it has
to deal with visual presentation to some degree.  And it actually does:
when I write *bold* in Emacs, a bold font is used.  Nicholas’ point that
Org’s bold has nothing to do with bold fonts is therefore not entirely
correct.  Bold clearly means bold in Org, even if the beamer exporter
interprets this otherwise (which I always found annoying).

Secondly, HTML can afford to be purely semantic because there is CSS to
deal with visual presentation.  In the case of Org, there is no such
thing as CSS, and the only solution is to litter the Org document with
LaTeX and HTML code.  Not appealing at all in my opinion.  Here is an
example to illustrate this:

#+BEGIN_SRC org
Sensation, perception, and memory are of particular
interest to which group of contemporary psychologists?

a. psychoanalysts
b. behaviorists
c. humanistic psychologists
d. cognitive psychologists

The correct answer is d. because …
#+END_SRC

For me and many others, this is a very common use case.  I challenge you
to implement this with current Org such that it will export correctly to
HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
clean and simple solution for this, this strongly suggests that Org
should do the pragmatic thing and support alphabetic bullet points
in its exporters.

More generally, I’m not convinced by the philosophy that Org should be
purely semantic markup and that its syntax should be changed to enforce
this even if this breaks existing documents (Nicholas’ preferred
solution).  Org clearly has a certain WYSIWYG quality and precisely that
is one of the reasons for its success.  We should embrace the fact that
Org is differnt from HTML and not force it to be something that it
isn’t.

  Titus


signature.asc
Description: PGP signature

[O] Bug: Log mode shows the wrong clock note [9.0.4 (9.0.4-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20170124/)]

[Jorge Morais Neto]

Hi.

In log mode, after each clock line the agenda should show the corresponding
clock note.  Instead, it shows the clock note for the previous clock line.
For example, with the entry

  *** Espe2016 exp
  :PROPERTIES:
  :CREATED:  [2017-01-27 Sex 16:50]
  :CATEGORY: ponto exp
  :END:
  :LOGBOOK:
  CLOCK: [2017-02-03 Sex 08:16]--[2017-02-03 Sex 08:28] =>  0:12
  - Saindo agora para o almoço.
  CLOCK: [2017-01-27 Sex 10:28]--[2017-01-27 Sex 11:13] =>  0:45
  CLOCK: [2017-01-26 Qui 13:45]--[2017-01-26 Qui 14:44] =>  0:59
  :END:

The agenda for [2017-02-03 Sex] shows:

  ponto exp:   8:16- 8:28 Clocked:   (0:12) Espe2016 exp - Saindo
agora para o almoço.

(I trimmed some irrelevant tags)  Note that the 08:16-08:28 clock line is
followed by the note corresponding to the /previous/ clock line.

Regards

Emacs  : GNU Emacs 25.1.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-12-31
Package: Org mode version 9.0.4 (9.0.4-elpaplus @
/home/jorge/.emacs.d/elpa/org-plus-contrib-20170124/)

current state:
==
(setq
 org-capture-prepare-finalize-hook '(J-insert-created-and-id-all)
 org-clocktable-defaults '(:maxlevel 2 :lang "en" :scope file :block nil
  :wstart 1 :mstart 1 :tstart nil :tend nil :step nil
  :stepskip0 nil :fileskip0 nil :tags nil :emphasize
  nil :link nil :narrow 40! :indent t :formula nil
  :timestamp nil :level nil :tcolumns nil :formatter nil)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-log-note-clock-out t
 org-footnote-section "Notas de rodapé"
 org-icalendar-combined-agenda-file "~/org/org.ics"
 org-insert-heading-hook '(org-expiry-insert-created)
 org-habit-preceding-days 0
 org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
 org-special-ctrl-k t
 org-agenda-entry-text-maxlines 3
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-priority-faces '((65 :slant italic :weight bold :foreground "red"
  :background "black")
 (66 :slant italic :weight bold :foreground "red"
  :background "cyan")
 (67 :slant italic :weight bold :foreground "red") (68
:slant italic :weight bold) (69 . italic)
 (70 . default) (71 :foreground "gold") (72 :foreground "yellow"))
 org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
 org-clock-mode-line-total 'current
 org-confirm-shell-link-function 'yes-or-no-p
 org-id-link-to-org-use-id 'create-if-interactive
 org-finalize-agenda-hook '(J-org-agenda-to-appt-refresh)
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-icalendar-use-deadline '(event-if-not-todo event-if-todo todo-due)
 org-export-default-language "pt_BR"
 org-agenda-sticky t
 org-list-allow-alphabetical t
 org-email-link-description-format "Email %c: %s"
 org-special-ctrl-a/e t
 org-ascii-text-width 77
 org-agenda-custom-commands '(("J" "Now, agenda and TODOs (week)"
  ((tags "now" nil)
(agenda "" ((org-agenda-span (quote week))
   (org-agenda-time-grid (quote (nil nil nil)
(tags-todo "-@GYNO"
((org-agenda-todo-ignore-deadlines (quote
all)) (org-agenda-todo-ignore-scheduled (quote all))
 (org-agenda-todo-ignore-timestamp
  org-deadline-warning-days))
)
)
  ((org-agenda-compact-blocks t)
(org-agenda-tags-todo-honor-ignore-options t)
(org-agenda-tag-filter-preset (quote
  ("-hide"
  )
 ("j" "Now, agenda and TODOs (two days)"
  ((tags "now" nil) (agenda "" ((org-agenda-span
 2) (org-agenda-time-grid (quote (nil nil nil)
(tags-todo "-@GYNO"
((org-agenda-todo-ignore-deadlines (quote
all)) (org-agenda-todo-ignore-scheduled (quote all))
 (org-agenda-todo-ignore-timestamp
  org-deadline-warning-days))
)
)
  ((org-agenda-compact-blocks t)
(org-agenda-tags-todo-honor-ignore-options t)
(org-agenda-tag-filter-preset (quote
  ("-hide"
  )
 ("n" "Entradas a memorizar" tags "mem-hide"
  ((org-agenda-hide-tags-regexp
"\\`\\(mem\\|not_ical\\|h\\|gagá\\)\\'")
(org-agenda-start-with-follow-mode t))
  )
 )
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-expiry-handler-function 'org-toggle-archive-tag
 org-expiry-inactive-timestamps t
 org-todo-keyword-faces '(("DGTD" . "#00FF10") ("FBCK_" . "#A0A0FF") ("FBCK"
 . "blue") ("FIX_COMM" . "#00FF10")
 ("CNTN_" . "#FFA0A0"))
 org-habit-following-days 0
 org-icalendar-use-scheduled '(event-if-todo todo-start)
 org-startup-indented t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-clock-x11idle-program-name "xprintidle"
 org-from-is-user-regexp
"|\\"
 org-use-tag-inheritance "[^_]$"
 org-icalendar-timezone "Brazil/East"
 org-src-mode-hook '(

[O] SOLVED - Re: linking to headings with a unique ID exported to latex/PDF

[Sharon Kimble]

Sharon Kimble  writes:

> I'm writing a document which is exported to latex and then built into a
> PDF where I might have 'Alcohol', just as an example, mentioned several
> times in different level headings. Currently I'm using org links like
> this [[*Alcohol][Alcohol]] but that only allows me to link to one
> heading only.
>
> I've tried using links like this
> [[id:542d0880-c0fd-46d5-b75d-4cc6f5fa99cc][Alcohol]] and under the
> heading that I'm linking to it says -
>
> *** Alcohol
> :PROPERTIES:
> :ID: 542d0880-c0fd-46d5-b75d-4cc6f5fa99cc  
> :END:
>
> But when exported it does not work.
>
> So, how can I link to specific headings, preferably with a unique ID
> please?

Nothing that I tried worked, yes, I was using 'org-id', but it was still
failing, so I set about building a MWE.

And then I found the problem - the latex package called 'titlesec' when
used with org-mode to latex is incompatible with org-mode and stops
org-id from working. Comment it out and org-id works perfectly again.
What 'titlesec' does is compress the space around each header, so its a
latex problem not an org-mode problem, so I shall look for a latex
solution to compressing the header spaces.

Thanks for all the suggestions and ideas to solve the problem.

Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.6, fluxbox 1.3.5-2, emacs 25.1.1.1


signature.asc
Description: PGP signature

Re: [O] fill text (indent) in lists

[Uwe Brauer]

   > Uwe Brauer  writes:

   > I think you need to read (info "(org) Plain lists"), in particular third
   > paragraph.

   > Anyway, let me try again. [X] are corners of the rectangle selection,
   > i.e., the point and mark,

Thanks very much, that worked as expected. Sorry for the hassle.

Re: [O] Feature request: lists with letters

[Rainer M Krug]

Nicolas Goaziou  writes:

> Hello,
>
> Titus von der Malsburg  writes:
>
>> One issue with org-list-allow-alphabetical is that we get numbers
>> instead of letters when we export to HTML and LaTeX.  I saw the earlier
>> thread [0] that gives the reasoning for this but I find it
>> unsatisfying.  If Org allows us to distinguish between -, +, 1., 1), a.,
>> A., a), A), this should also be honored by the exporter.
>
> This is also why I dislike the feature.
>
>> Otherwise it’s rather pointless to allow that distinction in the first
>> place.
>
> Exactly.
>
>> IMHO, a clean solution would be to either drop everything but - and
>> 1. or to keep all these and make the exporters honor them.  The former
>> would breaks existing documents and is therefore out of the
>> question.  This leaves us with the second solution.
>
> I wouldn't rule that out. Breaking changes happen. We can provide tools
> to fix existing documents.
>
> Actually, I like the idea of keeping only "-" and "1.". We could
> implement other bullet types as overlays.
>
>> Any chance you are willing to reconsider the decision to ignore
>> allow-alphabetical during export?
>
> I still agree with Carsten in the thread you pointed out. Org document
> is about structure. The bullet in about typesetting.

I must admit, I haven't read the thread mentioned, and I am sure
Carsten's point was correct, but orgmode is more and more used for
non-structure tasks. As an example I see the whole field of reproductive
research and scientific paper writing, which, in my opinion, has many
more elements than structure. Another example are html emails (like them
or not - I also dislike them) which people compose in org, or org as a
LaTeX frontend.

Exporting, i.e. typesetting and sharing, becomes much more important
these days and possibly as important as the structure.

In a nutshell: I agree with Titus' point and also would love to have
alphabetical bullets.

But it is for me not that important if they are alphabetical or numeric
in org - a simple command / which I could put in front of the list, and
*which could be interpreted by the exporter* to do the right thing for
this list would be fine, simmilar to bold, verbtin, ...
The implementation would then be in the exporter.

Cheers,

Rainer

>
>> I think it would be very useful to have that. I know there are other
>> ways to get alphabetical bullets in exported documents but they are
>> all specific to certain export targets and the beauty of Org mode is
>> precisely that we can export to many different targets.
>
> The beauty of Org is also to allow to control different export targets
> in the same document.
>
> I think this is a non-issue.
>
> Regards,

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature