Re: [O] avoiding "First item of list cannot move without its subtree"

[Max Rydahl Andersen]

On 22 Feb 2017, at 12:04, Nicolas Goaziou wrote:

> Hello,
>
> "Max Rydahl Andersen"  writes:
>
>> What am I doing wrong ?
>
> Nothing. There is a typo in my code.

Fixed the typo - but still nothing happens :/

/max

>
>> (add-hook 'org-shiftmetaleft-hook
>>(lambda ()
>>  (interactive)
>>  (let* ((element (org-element-at-point))
>> (list-parent (org-element-lineage element '(item plain-list) 
>> t)))
>>(when (and list-parent
>>   (= (line-beginning-position)
>>  (org-element-property :post-affiliated element)))
>
> -> (org-element-property :post-affiliated list-parent)
>
>>  (call-interactively
>>   (if (org-element-lineage list-parent '(item)) ;not at top level
>>   #'org-outdent-item-tree
>> #'org-ctrl-c-star))
>>  t
>
> Regards,
>
> -- 
> Nicolas Goaziou0x80A93738


/max
http://about.me/maxandersen

[O] Bug: Agenda clockcheck: org-duration-to-minutes: Wrong type argument: stringp [9.0.5 (release_9.0.5-318-gb1353c @ /tmp/emacs/org-mode/lisp\ /)]

[Dale]

Hi!  I think org-mode from master currently has a bug in agenda's
clockcheck mode.  Steps to reproduce:

1. Start emacs -Q and load org-mode master (b1353cb6f83)

2. Open a empty org-mode buffer, e.g.: C-x C-f test.org RET

3. M-x org-agenda RET

4. Hit "a" for "Agenda for current day or week"

5. Hit "v" then "c" to switch to clockcheck view

Expected results: clockcheck view is engaged (albeit empty given the
empty org-mode file)

Observed results: I receive the following error:

org-duration-to-minutes: Wrong type argument: stringp, 0

Due to this error, clockcheck mode does not seem to activate.

Emacs  : GNU Emacs 25.1.1 (x86_64-apple-darwin15.6.0)
 of 2017-01-30
Package: Org mode version 9.0.5 (release_9.0.5-318-gb1353c @
/tmp/emacs/org-mode/lisp/)

Other information:

I suspect this is happening as of the recent switch to using the
org-duration library (7e8cf5f4c20), which replaced some/all uses of
org-hh:mm-string-to-minutes with org-duration-to-minutes.
org-hh:mm-string-to-minutes accepted an integer as its argument
(despite its name):

(cond
 ((integerp s) s)
 ...

In contrast, org-duration-to-minutes only expects a string as its
argument.  The "Wrong type argument" seems to be coming from its first
string-match-p call.

org-agenda-show-clocking-issues will potentially call
org-duration-to-minutes with the integer 0 as its argument:

(mintime (org-duration-to-minutes
  (or (plist-get pl :min-duration) 0)))

The default value for org-agenda-clock-consistency-checks also
specifies :min-duration 0; that is, an integer rather than a string.

I cannot say whether org-duration-string should accept a number, as
org-hh:mm-string-to-minutes did, or instead whether org-agenda.el
should be changed to always pass it a string.

Kind regards,
Dale

Re: [O] latex preview table environment

[Jeremie Juste]

Hello,

Eric S Fraga  writes:

> When I switched my colour theme to one with a dark background, I found I
> had to set org-format-latex-options to
>
> '(:background default :foreground default)
>

 '(:background default :foreground default) work
for be as well.


> actually specifying colours did not seem to work for me.
I had as far as I can tell the following setting works for me. but I
need to remove the table environment for the foreground to turn blue (in
this case).


may be modifying the table after changing the color might help.  I always fall 
in this trap. 


(setq org-format-latex-options '(:foreground "blue" :background "gray" :scale 
1.4))

\begin{table}
\begin{center}
  \begin{tabular}{ | l | c | r }
\hline
1 & 2 & 3 \\ \hline
4 & 5 & 6 \\ \hline
7 & 8 & 9 \\
\hline
  \end{tabular}
\end{center}
\end{table}

Best wishes,
Jeremie

Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Colin Baxter]

On Wed, Feb 22 2017, Derek Feichtinger wrote:

Dear Derek,

> Hi Colin
>
> On 22.02.2017 16:27, Colin Baxter wrote:
>> Hi.
>>
>> On Tue, Feb 21 2017, Charles C. Berry wrote:
>>
>>> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>>>
- snip -
> Based on the documentation one can set the header arguments system wide 
> using these variables:
>
> org-babel-default-header-args (for all)
> org-babel-default-header-args:   (language specific)
>
> File wide using PROPERTY:
>
> #+PROPERTY: header-args :eval never-export
>
> Org heading wide using a local property setting:
>   * sample header
> :PROPERTIES:
> :header-args::eval never-export
> :END:
>
> The last two ways I tested. So, in the end, with some changes to most of 
> my files I can get the same behavior again, which is good.
>
> It's a matter of taste or use case whether to define the default 
> behavior to eval on export. I would have made the case the eval on 
> export is the more rare use case. I almost never have this, except for 
> certain kinds of reports, e.g. if you want to gather the state of a 
> server with a number of prepared queries in the org file. For me, most 
> org files are like a number of measurements taken at a certain point in 
> time, and I want to conserve the output of the evaluation exactly like 
> it was. E.g. when working at speeding up code, I very much like to do 
> the whole thing inside of an org file where I document the speed 
> measurements, my changes to code and what the effect was. So, more like 
> some kind of interactive lab journal.
>
> But as I said, it is a matter of taste, and I am happy that I can get 
> the original functionality without too much effort.
>
> Best regards,
> Derek

--- snip -

Thank you, I really appreciate this information. You have saved me a
couple of hours work. I'll probably end up setting
org-babel-default-header-args as a local variable.

Thanks again.

Best wishes.

[O] Dynamic block

[Sebastien Vauban]

Dear all,

I've used the following for years -- until (finally!) my switch to Org
mode 9, a couple of weeks ago.

--8<---cut here---start->8---
#+NAME: prestasTotal
#+BEGIN: clocktable :lang "fr" :block 2017-02 :maxlevel 3 :scope 
("~/4-Admin/client.org") :fileskip0 t :tags "-notbillable" :narrow 80! :indent t
#+CAPTION: Horodatage sommaire à [2017-02-22 Wed 16:01], for February 2017.
| Fichier | En-tête   | Durée |   |   |
|-+---+---+---+---|
| | TOUT Durée totale |  0:00 |   |   |
#+END:
--8<---cut here---end--->8---

Now, as you see, the total stays 0 -- while there are time clocking
lines for Feb 2017 in that `client.org' file.

In the *Messages* buffer, I just see:

--8<---cut here---start->8---
Updating dynamic block ‘clocktable’ at line 20...done
--8<---cut here---end--->8---

No error reported...

Have I missed something?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [ANN] New Org duration library

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> I had a few questions/comments though:
>
> - Given that the smallest unit of duration is the minute,

The base unit is the minute, but nobody prevents you from adding
a smaller unit:

  (let ((org-duration-units (cons `("s" . ,(/ 1 60.0)) org-duration-units)))
(org-duration-from-minutes 1.5 '(("min") ("s"

  => "1min 30s"

>   why are seconds a choice in h:mm:ss?  Wonʼt they always be zero?

Internally, durations are floats because of seconds.

  (org-duration-from-minutes 1.5 'h:mm:ss) => "0:01:30"

>   Maybe it is
>   better not to offer this choice; I think it is potentially confusing
>   (giving the impression that durations might be accurate to the
>   second).

Durations _can_ be accurate to the second. This library can be used
outside clocksum computations, which are, indeed, accurate only to the
minute.

> - I would remove the h:mm symbol shorthand.  It can still be offered as
>   a convenient option in customize using (const :tag "Use H:MM" (special
>   . h:mm)), but making it a special value with its own semantics makes
>   the system harder to understand for those who write their config in
>   lisp (rather than using customize).

Using a list means you want to use special units to display the
duration. However when the value is '((special . h:mm)), there is no
unit to display the duration with, so '((special . h:mm)) is the
degenerate case, not `h:mm'.

Mind you, I'm not opposed to removing `h:mm'. I'm just pointing out the
rational behind the initial choice.

Moreover, if we remove `h:mm', we need to replace calls like

  (org-duration-from-minutes 120 'h:mm)

with

  (org-duration-from-minutes 120 '((special . h:mm)))

which is slightly uglier.

> - The fact that the special options are grouped under the key “special”
>   is a bit confusing.  If it isnʼt too much work, I would recommend
>   restructuring the options slightly to be (use-h:mm . t) and (precision
>   . INT).  This more closely matches my intuition about how alists like
>   this are used.

I chose `special' for a reason: these options are mutually exclusive.
Using the same key, the structure (i.e., the alist) makes them mutually
exclusive, too. With your suggestion, however, nothing prevents an user
to have

  '((use-h:mm . t) (precision . 2))

and complain if strange things happen.

So, I'd rather keep the same car. I'm not married to `special' though.

> - Must the list be in decreasing order of unit size, or does everything
>   work if itʼs in arbitrary order?  The documentation doesnʼt make it
>   clear one way or the other.

There is no restriction about the order.

> The value should be a list of entries each following this pattern:
>
>   (UNIT . REQUIRED)

I'd favor REQUIRED? over REQUIRED because it is a boolean.

> UNIT is one of the unit strings defined in `org-duration-units'.  A
> duration is formatted using only the time components that are specified
> here.  If a time unit in missing, formatting falls back to the next
> smallest unit.

The algorithm works the other way: it consider biggest units first
(greedy algorithm).

> At the end of the list, there can be an entry indicating special formatting

"The end of the list" is not accurate. The entry can be anywhere.

Also, I reworded that part already in master. You may want to have
a look at it.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Colin Baxter]

Hi.

On Tue, Feb 21 2017, Charles C. Berry wrote:

> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>
>> Hi Chuck
>>
>> On 21.02.2017 00:54, Charles C. Berry wrote:
>>> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>>>
 When org-export-babel-evaluate is set to nil, I see a different
 behavior now as compared to earlier versions of org.
>>>
>>> Indeed.
>>>
>>> It is now *obsolete* and its behavior has intentionally been
>>> changed as noted here:
>>>
>
>
>> So, I still feel that this is a very much needed functionality that
>> has been lost on the way.
>
> Nothing is lost here.
>
> Reread the part of my post that you deleted in your reply:
>
> : | ...  Users
> : | who wish to avoid evaluating code on export should use the header
> : | argument ‘:eval never-export’.
> : |
>
> which is how to do what you want.
>
> And maybe review how to set header args buffer wide or system-wide.
>

I agree very much with the sentiments expressed by Derek
Feichtinger. The old org-export-babel-evaluate allowed a setting to be made
for one or several files. Perhaps I've not understood correctly, but the
new arrangement would seem to suggest that the user has to insert what
they want at each src_code block.

Best wishes,

C.

Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Derek Feichtinger]

Hi Colin

On 22.02.2017 16:27, Colin Baxter wrote:

Hi.

On Tue, Feb 21 2017, Charles C. Berry wrote:


On Mon, 20 Feb 2017, Derek Feichtinger wrote:


Hi Chuck

On 21.02.2017 00:54, Charles C. Berry wrote:

On Mon, 20 Feb 2017, Derek Feichtinger wrote:


When org-export-babel-evaluate is set to nil, I see a different
behavior now as compared to earlier versions of org.

Indeed.

It is now *obsolete* and its behavior has intentionally been
changed as noted here:




So, I still feel that this is a very much needed functionality that
has been lost on the way.

Nothing is lost here.

Reread the part of my post that you deleted in your reply:

: | ...  Users
: | who wish to avoid evaluating code on export should use the header
: | argument ‘:eval never-export’.
: |

which is how to do what you want.

And maybe review how to set header args buffer wide or system-wide.


I agree very much with the sentiments expressed by Derek
Feichtinger. The old org-export-babel-evaluate allowed a setting to be made
for one or several files. Perhaps I've not understood correctly, but the
new arrangement would seem to suggest that the user has to insert what
they want at each src_code block.

Based on the documentation one can set the header arguments system wide 
using these variables:


org-babel-default-header-args (for all)
org-babel-default-header-args:   (language specific)

File wide using PROPERTY:
#+PROPERTY: header-args :eval never-export

Org heading wide using a local property setting:
 * sample header
   :PROPERTIES:
   :header-args::eval never-export
   :END:

The last two ways I tested. So, in the end, with some changes to most of 
my files I can get the same behavior again, which is good.


It's a matter of taste or use case whether to define the default 
behavior to eval on export. I would have made the case the eval on 
export is the more rare use case. I almost never have this, except for 
certain kinds of reports, e.g. if you want to gather the state of a 
server with a number of prepared queries in the org file. For me, most 
org files are like a number of measurements taken at a certain point in 
time, and I want to conserve the output of the evaluation exactly like 
it was. E.g. when working at speeding up code, I very much like to do 
the whole thing inside of an org file where I document the speed 
measurements, my changes to code and what the effect was. So, more like 
some kind of interactive lab journal.


But as I said, it is a matter of taste, and I am happy that I can get 
the original functionality without too much effort.


Best regards,
Derek


--
Paul Scherrer Institut
Dr. Derek Feichtinger   Phone:   +41 56 310 47 33
Section Head Science-IT Email: derek.feichtin...@psi.ch
Building/Room No. WHGA/U126
CH-5232 Villigen PSI

Re: [O] [ANN] New Org duration library

[Aaron Ecay]

Hi Nicolas, hi Achim,

2017ko otsailak 21an, Nicolas Goaziou-ek idatzi zuen:

[...]

>> Also, I find the documentation to be completely impenetrable.
> 
> Great. Suggestions welcome.

I took a look at the docstring.  I think I managed to understand it, but
I can see how it might be confusing.  I made an attempt to restructure
it to explain first the general cases and then the exceptions, which is
a clearer order (at least to me).  I also changed some minor things that
hopefully make it clearer overall.  Iʼve pasted that effort at the bottom
of this email.

I had a few questions/comments though:

- Given that the smallest unit of duration is the minute, why are
  seconds a choice in h:mm:ss?  Wonʼt they always be zero?  Maybe it is
  better not to offer this choice; I think it is potentially confusing
  (giving the impression that durations might be accurate to the
  second).
- I would remove the h:mm symbol shorthand.  It can still be offered as
  a convenient option in customize using (const :tag "Use H:MM" (special
  . h:mm)), but making it a special value with its own semantics makes
  the system harder to understand for those who write their config in
  lisp (rather than using customize).
- The fact that the special options are grouped under the key “special”
  is a bit confusing.  If it isnʼt too much work, I would recommend
  restructuring the options slightly to be (use-h:mm . t) and (precision
  . INT).  This more closely matches my intuition about how alists like
  this are used.
- Must the list be in decreasing order of unit size, or does everything
  work if itʼs in arbitrary order?  The documentation doesnʼt make it
  clear one way or the other.

=

Format definition for a duration.

The value should be a list of entries each following this pattern:

  (UNIT . REQUIRED)

UNIT is one of the unit strings defined in `org-duration-units'.  A
duration is formatted using only the time components that are specified
here.  If a time unit in missing, formatting falls back to the next
smallest unit.

A non-nil REQUIRED value for these keys indicates that the
corresponding time component should always be included, even if
its value is 0.

For example,

   ((\"d\" . nil) (\"h\" . t) (\"min\" . t))

means a duration longer than a day is expressed in days, hours
and minutes, whereas a duration shorter than a day is always
expressed in hours and minutes, even when shorter than an hour.

On the other hand, the value

  ((\"d\" . nil) (\"min\" . nil))

means a duration longer than a day is expressed in days and
minutes, whereas a duration shorter than a day is expressed
entirely in minutes, even when longer than an hour.

At the end of the list, there can be an entry indicating special formatting
needs.  It must follow one of the three following patterns:

  (special . h:mm)
  (special . h:mm:ss)
  (special . PRECISION)

When one of the first two is present, a duration is expressed in mixed
mode, where larger units are used down to hours, then the remaining
hours and minutes of the duration are expressed as a \"H:MM:SS\" or
\"H:MM\" string.

With the last pattern, a duration is always expressed with a single
unit.  PRECISION, an integer, indicates the number of decimal places to
show.  The unit chosen is the first one required or with a non-zero
integer part.  If there is no such unit, the smallest one is used.

Thus, the following format

  ((\"d\" . nil) (special . h:mm))

means that any duration longer than a day is expressed as a whole number
of days plus a \"H:MM\" part, whereas a duration shorter than a day is
expressed only as a \"H:MM\" string.

The following format

  ((\"d\" . nil) (\"h\" . nil) (special . 2))

expresses a duration longer than a day as a multiple of a day, accurate
to two decimal places.  A duration shorter than a day uses units of an
hour instead.

Finally, the value can be set to the symbols `h:mm:ss' or `h:mm', which
means a duration, whatever its length, is expressed as a \"H:MM:SS\" or
\"H:MM\" string respectively.  These options are convenient shorthand
which is equivalent to ((special . h:mm:ss)) or ((special . h:mm)).
  
-- 
Aaron Ecay

Re: [O] orgtbl-insert-matrix, embedded

[Rasmus]

Hi Uwe,

Uwe Brauer  writes:

> I can use orgtbl-insert-matrix to nicely insert one matrix
> resulting in
> % BEGIN RECEIVE ORGTBL neu
> \[
> \begin{pmatrix}
> 8 & 8 \\
>  &  \\
> \end{pmatrix}
> \]
> % END RECEIVE ORGTBL neu
> \begin{comment}
>
> #+ORGTBL: SEND neu orgtbl-to-latex-matrix :splice nil :skip 0
> | 8 | 8 |
>
> |   |   |
> \end{comment}
> is there a way to insert another array into the same latex environment?

Something like this?

#+ATTR_LATEX: :mode math :environment pmatrix :math-suffix \times 
:math-prefix \mathbf{y}=
| a | b |
| c | d |
#+ATTR_LATEX: :mode math :environment pmatrix
| 1 | 2 |
| 3 | 4 |

See (info "(org) Tables in LaTeX export"):

http://orgmode.org/org.html#Tables-in-LaTeX-export

Rasmus

-- 
Even a three-legged dog has three good legs to lose

[O] [PATCH 1/1] org.el: Make faces org-quote and org-verse be appended

[Anders Johansson]

This means fontification of emphasis, links etc. is kept in quote 
and

verse blocks even with org-fontify-quote-and-verse-blocks non-nil.

TINYCHANGE
---
lisp/org.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3290a2b..282c078 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5934,9 +5934,9 @@ by a #."
			 '(org-block))) ; end of source 
block

 ((not org-fontify-quote-and-verse-blocks))
 ((string= block-type "quote")
-	  (add-text-properties beg1 (min (point-max) (1+ end1)) 
  '(face org-quote)))
+	  (add-face-text-property beg1 (min (point-max) (1+ end1)) 
'org-quote t))

 ((string= block-type "verse")
-	  (add-text-properties beg1 (min (point-max) (1+ end1)) 
  '(face org-verse
+	  (add-face-text-property beg1 (min (point-max) (1+ end1)) 
'org-verse t)))
	(add-text-properties beg beg1 '(face 
org-block-begin-line))
	(add-text-properties (min (point-max) (1+ end)) (min 
(point-max) (1+ end1))

 '(face org-block-end-line))
--
2.11.1

Re: [O] [ANN] New Org duration library

[Malcolm Purvis]

> "Nicolas" == Nicolas Goaziou  writes:

Nicolas> The documentation lists what is allowed. Strings are not. Where
Nicolas> did you read that they might be? For the record, here are the
Nicolas> first paragraphs of the docstring:

Nicolas>   The value can be set to, respectively, ‘h:mm:ss’ or ‘h:mm’,
Nicolas> which means a duration is expressed as, respectively, a
Nicolas> "H:MM:SS" or "H:MM" string.

I too was confused by this and took the quotes around ‘h:mm:ss’ and
‘h:mm’ to mean that they are strings.  Changing the working to be:

   The value can be set to, respectively, the symbols ‘h:mm:ss’ or ‘h:mm’,

would clarify the situation.

Malcolm

-- 
   Malcolm Purvis 

Re: [O] avoiding "First item of list cannot move without its subtree"

[Nicolas Goaziou]

Hello,

"Max Rydahl Andersen"  writes:

> What am I doing wrong ?

Nothing. There is a typo in my code.

> (add-hook 'org-shiftmetaleft-hook
> (lambda ()
>   (interactive)
>   (let* ((element (org-element-at-point))
>  (list-parent (org-element-lineage element '(item plain-list) 
> t)))
> (when (and list-parent
>(= (line-beginning-position)
>   (org-element-property :post-affiliated element)))

-> (org-element-property :post-affiliated list-parent)

>   (call-interactively
>(if (org-element-lineage list-parent '(item)) ;not at top level
>#'org-outdent-item-tree
>  #'org-ctrl-c-star))
>   t

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] [ANN] New Org duration library

[Nicolas Goaziou]

Hello,

Achim Gratz  writes:

> Nicolas Goaziou writes:

>> Strings are not allowed. It is either a symbol (h:mm:ss or h:mm) or
>> a list of conses.
>
> That sentence in the documentation would have helped.

The documentation lists what is allowed. Strings are not. Where did you
read that they might be? For the record, here are the first paragraphs
of the docstring:

  The value can be set to, respectively, ‘h:mm:ss’ or ‘h:mm’, which
  means a duration is expressed as, respectively, a "H:MM:SS" or
  "H:MM" string.

  Alternatively, the value can be a list of entries following the
  pattern:

(UNIT . REQUIRED?)

This is basically the same as "It is either a symbol (h:mm:ss or h:mm)
or a list of conses".

In any case, it is unreasonable, IMO, to also document all that is _not_
allowed.

> If units are defined as strings, then why can the format not be a string
> also?  I still find this confusing, especially as there are multiple
> other places in Org that use format strings quite happily.

I'm not sure to understand your suggestion. Are you suggesting to use
a format control string, e.g., as expected by `format-seconds'? The
problems with format strings are that:

- you cannot guarantee to be able to read the duration back into
  minutes, e.g., for some convoluted format strings;

- it is much less powerful than the current variable. In particular, it
  is not possible to have mixed mode with a format string. It is not
  possible to have conditional durations (e.g., one format for more than
  a day, another one for less than one) either;

> Lost me right there again.  Please tell the user what problem he can
> solve with this and then tell him how to do it, not the other way
> around.

There is no problem to solve. It is about aesthetics.
`org-duration-to-minutes' understands every possible format defined with
`org-duration-format' anyway.

Since I cannot foretell what a user is going to want, I simply describe
what is possible to do, and how.

Again, feel free to suggest more precise suggestions.

> So, the purpose of this variable is to specify how you want durations
> displayed in Org, using the predefined "special" formats or
> user-defined org-duration units (there's a default on those as well).

Correct. As a reminder, the first sentence of the docstring is:

  Format definition for a duration.

> A duration format doesn't necessarily use all defined units,

Correct.

> and of those it is using it (always?) starts with the largest unit and
> ends with the smallest.

Not necessarily. Considering (("d" . nil) ("h" . nil) ("min" . nil)),
180 minutes become "3h". Neither the largest nor the smallest units are
used.

> This is the only one that can usefully have PRECISION, I suppose, but
> the docstring shows there might be a possibility to chose differently
> (I believe that means it ignores the smaller units in this case).

The docstring is right. PRECISION implies a single unit is used, but you
can control which one. For example, with 

  ((d . nil) (h . nil) (special . 1))

390 minutes are spelled "6.5h", but 1440 minutes become "1.0d".

Note that, using ((d . nil) (special . 1)) instead, 390 minutes is
"0.3d".

>> There is even an example in the docstring:
>>
>>   The following format
>>
>> ((\"d\" . nil) (special . h:mm))
>
> Except the default really is shown as (("d") (special . h:mm)) if the
> user cares to look things up.

As you well know, ("d" . nil) is exactly ("d"). I spelled out the nil
part so it matches the expected pattern clearly. What is the problem
here?

> I've picked something that I expected to be nonsensical on purpose,
> although I think it wouldn't be entirely unreasonable for a user to
> expect that the duration would simply get formatted both ways.

Hmm, what? How do you format a duration "both ways"? You cannot write,
e.g., "30min 0:30": it could be interpreted as a convoluted way to say
"1h".

> The documentation should tell me not to do that or if it's ignoring
> part of the specification.

I re-worded that last part of the documentation:

  Eventually, the list can contain one of the following special
  entries:

(special . h:mm)
(special . h:mm:ss)

  Units shorter than an hour are ignored.  The hours and
  minutes part of the duration is expressed unconditionally
  with H:MM, or H:MM:SS, pattern.

(special . PRECISION)

  A duration is expressed with a single unit, PRECISION being
  the number of decimal places to show.  The unit chosen is the
  first one required or with a non-zero integer part.  If there
  is no such unit, the smallest one is used.

Hopefully, it is clearer now.

> I take from your answer that the order of specification might not be
> important, but it's not spelled out in the docstring yet.

The order of specification _is_ important, as in any alist. I don't
think every variable using alists reminds the user about this.

In the case above, though, the order is not important because 

  

Re: [O] Why does quote and verse block fontification have to override local fontification?

[Nicolas Goaziou]

Hello,

Anders Johansson  writes:

> I want to fontify quote blocks (i use them a lot for note taking and
> writing paper) so that they stand out (and so I enable
> org-fontify-quote-and-verse-blocks) but it would be useful to preserve
> the local fontification of emphasis, links etc. inside quote blocks.
> This can easily be achieved with a patch like this org.el:
>
> 6096,6099c6096,6099
> <  ((string= block-type "quote")
> <   (add-face-text-property beg1 (min (point-max) (1+ end1))
> 'org-quote t))
> <  ((string= block-type "verse")
> <   (add-face-text-property beg1 (min (point-max) (1+ end1))
> 'org-verse t)))
> ---
>>   ((string= block-type "quote")
>>(add-text-properties beg1 (min (point-max) (1+ end1))
>> '(face org-quote)))
>>   ((string= block-type "verse")
>>(add-text-properties beg1 (min (point-max) (1+ end1))
>> '(face org-verse
>
>
> In this invocation add-face-text-property appends org-quote to the
> face property, and hence all other fontification is kept.
>
> Does this interfere with something else or what people would expect?
> In my view it looks much better, but I guess that can depend on the
> appearance of org-quote and org-verse (I have them as
> font-lock-comment-face, just a slightly different colour, on top of
> which italics etc. look good).

Sounds good. Could you provide a patch using git format-patch command?

Please add TINYCHANGE at the end of the commit message if you haven't
signed FSF copyright papers.

Thank you.

Regards,

-- 
Nicolas Goaziou

[O] Why does quote and verse block fontification have to override local fontification?

[Anders Johansson]

Hi,
I want to fontify quote blocks (i use them a lot for note taking 
and writing paper) so that they stand out (and so I enable 
org-fontify-quote-and-verse-blocks) but it would be useful to 
preserve the local fontification of emphasis, links etc. inside 
quote blocks. This can easily be achieved with a patch like this 
org.el:


6096,6099c6096,6099
<  ((string= block-type "quote")
<   (add-face-text-property beg1 (min (point-max) (1+ 
end1)) 'org-quote t))

<  ((string= block-type "verse")
<   (add-face-text-property beg1 (min (point-max) (1+ 
end1)) 'org-verse t)))

---

 ((string= block-type "quote")
	  (add-text-properties beg1 (min (point-max) (1+ end1)) 
'(face org-quote)))

 ((string= block-type "verse")
	  (add-text-properties beg1 (min (point-max) (1+ end1)) 
'(face org-verse



In this invocation add-face-text-property appends org-quote to the 
face property, and hence all other fontification is kept.


Does this interfere with something else or what people would 
expect? In my view it looks much better, but I guess that can 
depend on the appearance of org-quote and org-verse (I have them 
as font-lock-comment-face, just a slightly different colour, on 
top of which italics etc. look good).



--
Anders Johansson