[O] Question about Agenda view

[Thomas Moyer]

I will sometimes add additional notes below a TODO entry, usually some link
to something, or some extra explanation. Is there a way to customize the
agenda view to indicate if these extra lines exist? I'm looking for
something potentially as simple as appending ... to the end of an agenda
entry if something other than a timestamp is on the lines below the TODO
item.

For example:

* TODO Item 1
SCHEDULED: <2016-02-18 Thu>
* TODO Item 2
[2016-02-15 Mon]
* TODO Item 3
SCHEDULED: <2016-02-18 Thu>
We should look into making the system perform better

Would result in agenda lines where Items 1 & 2 appear as they currently do,
and Item 3's agenda line ends with ... to indicate that there is a line
that is not a timestamp following the headline.

Tom

Re: [O] bug#6922: 23.1; Setting read-only property in an overlay has no effect

[Marcin Borkowski]

On 2016-02-07, at 23:24, John Wiegley  wrote:

>> Eli Zaretskii  writes:
>
>> What is the current consensus? should we adjust the documentation or fix the
>> code? John? Richard?
>
> I think read-only overlays could be very useful. For example:
>
>  1. Create a command called `mask-regexp'. It creates read-only overlays for
> matching text throughout the buffer.
>  2. There should also be a way to add manual masks, using `mask-region'.
>  3. Now use `replace-string' or any other command to bulk transform text.
> However, masked text is not changed.
>  4. Then execute unmask-all, and the mask disappears.
>
> This method of editing is key to video editing workflows. I think the only
> reason I never thought to use it in Emacs is because it's never been there
> (and so never occurred to me until now).

Hi,

I just realized that this idea could be /extremely/ useful.  Here's the
case: I start a clock in Org-mode (C-c C-x C-i), and an entry with the
starting time is added in the :LOGBOOK: drawer (and btw, it is
invisible).  While working on the file, I hit C-/ (undo) once too many,
and the entry disappears (and this fact is still invisible to me!).
Then, after some more work, I stop the clock only to see "org-clock-out:
Clock start time is gone", and my clock is still going on (!).

While the last thing (about the clock still going on) is probably an
Org-mode bug (I'll propbably report it later "officially", I'm now
Cc-ing this message to the Org-mode ML), the whole experience (and yes,
it happened to me) is /very/ confusing.

When read-only properties and masking are here, Org could just mark the
half-done entry as read-only.  I suspect that trying to undo it would
perhaps trigger some error, which could be confusing, but it would be
still better than silently removing a vital information.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] [PATCH] ox-koma-letter.el: Add support for 'location' koma variable

[Rasmus]

Myles English  writes:

> Rasmus writes:
>
>> I will try to merge your patch soon, this weekend.  Again, unless someone
>> beats me to it.
>
> Please would someone apply this patch?

I will *try* to write the remaining code to maintain feature parity
between keywords and special headings in the weekend.  I don’t think we
should add half-finished features.

Rasmus

-- 
Together we'll stand, divided we'll fall

Re: [O] Refile is not using IDO

[Samuel Wales]

not an answer but an fyi:

in maint, i use ido-hacks with ido, and the org settings seem to be
irrelevant. it works.

there is also one more thing:

i do find it necessary to remove the confusing parentheses from the
outline paths.
they seem to be unnecessary and actually arbitrary. they might even
depend on whether the path is in the current buffer or not, or
somehting equally irrelevant.

it's possible that they interact with an org setting for supplying
information in parens, but inconsistently. so i find that it is better
to remove them.

here is the patch. i am not signed up with fsf, so i don't know if a
tinychange would work or not.

=== alpha remove the parens from ido completion of olpaths

Modified   lisp/org.el
diff --git a/lisp/org.el b/lisp/org.el
index 39d4029..7c497f6 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12050,7 +12050,7 @@ this is used for the GOTO interface."
 (tbl (mapcar
   (lambda (x)
 (if (and (not (member org-refile-use-outline-path
-  '(file full-file-path)))
+  '(nil file full-file-path)))
  (not (equal filename (nth 1 x
 (cons (concat (car x) extra " ("
   (file-name-nondirectory (nth 1 x)) ")")




On 2/2/16, Vitalie Spinu  wrote:
>
> Hi,
>
> I cannot get IDO working with refile anymore. The following change seem to
> be
> relevant:
>
>


-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

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

Denmark: free Karina Hansen NOW.

Re: [O] Refile is not using IDO

[Vitalie Spinu]

>> On Tue, Feb 02 2016 22:36, Nicolas Goaziou wrote:

> Helm, indeed.

>> Something is resetting in refile. I will investigate.

I have finally checked this up.

It's ido-ubiquitous override. Once that's removed, org refile started working
again.

I opened an issue there:

  https://github.com/DarwinAwardWinner/ido-ubiquitous/issues/107


  Vitalie

Re: [O] tangling order

[Alan Schmitt]

On 2016-02-16 18:34, "Charles C. Berry"  writes:

>> I've found a workaround, as it is only for a few blocks I manually
>> change their headers, so it is fine at the moment.
>
> Another workaround would be to add after advice to 
> `org-babel-get-src-block-info' to map your faux languages to a common 
> variant.
>
>> I still think it
>> would be great to have better control on the order in which blocks are
>> tangled.
>
> If you want to do this inside org/emacs (and not stitch a bunch of tangled 
> files together with other tools), try this in your *.org file and execute 
> it. The result is what you might work with (i.e. customize or advice the 
> function below).
>
> #+BEGIN_SRC emacs-lisp :results pp :tangle foo.ml
> (org-babel-tangle-collect-blocks)
> #+END_SRC

Thank you for the suggestions. Looking at what this function returns
(blocks sorted by language), I now understand better why this does not
do what I want.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂ (2016-01, Mauna Loa Obs.): 402.52


signature.asc
Description: PGP signature

[O] exporting a math figure in both latex and html: missing caption and label

[Alan Schmitt]

Hello,

I'm trying to replicate the following latex code to orgmode so that it
exports correctly in latex and orgmode:

#+begin_src latex
\begin{figure}[h]

\[\scalebox{2}{\color{
blue}$\omega^{(\omega^\omega\,+\, \omega^2 \times 8 \,+\, 
   \omega)
 }+ \omega^\omega + \omega^4+ 6$}\]
\caption{An ordinal in Cantor normal form \label{fig:cnf-example}}

\end{figure}
#+end_src

I'm currently using this:

#+begin_src org
,#+caption: An ordinal in Cantor normal form
,#+name: fig:cnf-example
,#+begin_figure
\[
\omega^{(\omega^\omega\,+\, \omega^2 \times 8 \,+\, \omega)}+ \omega^\omega + 
\omega^4+ 6
\]
,#+end_figure
#+end_src

(I'm not too worried about the scaling and color, I can deal with them
using a custom environment in latex and a CSS in html).

The html code that is generated forgets both the caption and the label:

#+begin_src html


\[
\omega^{(\omega^\omega\,+\, \omega^2 \times 8 \,+\, \omega)}+ \omega^\omega + 
\omega^4+ 6
\]



#+end_src

I see that captions are correctly generated for images in html export.
Is there something special I need to do for other kinds of figures?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂ (2016-01, Mauna Loa Obs.): 402.52


signature.asc
Description: PGP signature

Re: [O] Embedding images in Org Mode for HTML export

[Eric S Fraga]

On Tuesday, 16 Feb 2016 at 19:22, Lawrence Bottorff wrote:
> I've got this code:

[...]

> running in an org file, and it gives me embedded images in an html
> file. (See this). But they're cramped and have a strange gray
> background. How can I not clip and get the png transparent working?

I added these options to the src block

 :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 800

and the first src block works for me: images are proper size and the
background is transparent.  I could not test the second as I don't have
qtree.

The process might depend on what your system uses to generate the images
from LaTeX.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.91.1, Org release_8.3.3-601-gff9890