Re: [O] Bug? -- installing and updating on Windows
David Masterson writes: > I installed a pre-built version of GNU Emacs 24.3.1 on Windows 8.1. It > came with v7.9.3f of Org. I used the package management option to > update to the latest version which (I think) it installed into my > ~/.emacs.d directory (ELPA?). This looks to be Org v8.2.5h. However, > org-version still lists as v7.9.3f. Is something not loading? Three ideas: 1. Check the value of load-path to be sure that it contains emacs.d/elpa/org... 2. M-x org-reload 3. If that fails, restart emacs Matt
[O] [Bug] marking repeating task done destroys property/logbook drawers
When I mark a repeating task done (with the settings in the minimal.el file below), org mangles the :LOGBOOK: and :PROPERTY: drawers when trying to insert a :LAST_REPEAT: property. Here are the steps to reproduce consistently: 1. emacs -Q -l ~/minimal.el where minimal.el contains... minimal.el Description: application/emacs-lisp 2. Open an org-file containing the following entry. --8<---cut here---start->8--- * TODO Repeating task SCHEDULED: <2014-03-02 Sun .+2w> :LOGBOOK: - State "DONE" from "NOW"[2014-02-23 Sun 08:39] CLOCK: [2014-02-23 Sun 08:26]--[2014-02-23 Sun 08:39] => 0:13 - State "DONE" from "STARTED"[2014-01-28 Tue 20:17] :END: :PROPERTIES: :LAST_REPEAT: [2014-02-23 Sun 08:39] :END: --8<---cut here---end--->8--- 3. Mark the item DONE. Voilà... note the empty property drawer, the duplicate logbook drawers, and the misplaced :LAST_REPEAT: --8<---cut here---start->8--- * TODO Repeating task SCHEDULED: <2014-03-17 Mon .+2w> :LOGBOOK: - State "DONE" from "TODO" [2014-03-03 Mon 22:11] :END: :LAST_REPEAT: [2014-03-03 Mon 22:11] :LOGBOOK: - State "DONE" from "NOW"[2014-02-23 Sun 08:39] CLOCK: [2014-02-23 Sun 08:26]--[2014-02-23 Sun 08:39] => 0:13 - State "DONE" from "STARTED"[2014-01-28 Tue 20:17] :END: :PROPERTIES: :END: --8<---cut here---end--->8--- I am using... - Emacs version: 24.3.1 - Org-mode version: 8.2.5h ...on Arch Linux. Running edebug suggested that org-entry-put (which is invoked by org-auto-repeat-maybe) places the :LAST_REPEAT: in the wrong place. However, I couldn't discern why, since invocations of org-entry-put otherwise seem to work fine. Thanks, Matt
Re: [O] Blank page in LaTeX/PDF output
On Mon, Mar 3, 2014 at 7:13 PM, Peter Davis wrote:
[snip]
>> > > Regarding a bug report, if that's what this is, I just googled "latex
>> > > bugs" and got this page as the first hit:
>> > > - http://latex-project.org/bugs.html
>> > >
>> >
>> >
>> > Unfortunately, that site says they can't accept bugs that use any third
>> > party packages, and the org-exported LaTeX file starts:
>> >
>>
>> Can you delete all of those lines, recompile with pdflatex, and still
>> reproduce?
>>
>> If so, you're still good to go!
>>
>
> Unfortunately, it gets a lot of errors if I remove all the \usepackage lines,
> and I don't know which packages are third party or not.
I was able to get rid of them all except for graphicx, and I also was
able to replicate with the standard article class :) Here's the
pastebin:
- http://pastebin.com/WeJXAjw7
I cleaned up some of the text just to remove other contributing
candidates (such as changing the tabular to {lll} alignment as not to
use p{}, and using just tabular vs. tabular inside table).
>From my fiddling:
- As-is produces 4 pages, blank 3rd
- Commenting out the hyperref package does *not* produce a blank 3rd page
- Using \section* does *not* product a blank 3rd page
I added a comment linking to Wikipedia's Linux penguin that I used as
./image.png, just to make sure it wasn't possibly related to errors
related to no image being found.
I wondered if it had something to do with the numbered sections being
treated as links (since hyperref was the culprit package). I fiddled
with removing \label{sec-n}, but that didn't have an effect. I
wondered if that was triggering something due to it having links sort
of "ready" for the TOC even though none is present... no idea!
Anyway, as long as graphicx and hyperref are not considered "3rd
party," I think you could still submit the report. You may be told
that since there are overfull hbox and vbox's that it's not their
problem, but I'd still expect the results to be the same with \section
vs. \section*, and with[out] hyperref.
Good luck!
John
Re: [O] Namespace problem org-mode / Clojure
Hi Bastien- I will check it tomorrow and report. Thank you! Regarding TODOs related to Clojure code blocks; where is the best place for them? Greg On Mon, 2014-03-03 at 13:54 +0100, Bastien wrote: > Hi Volker and Greg, > > I hopefully fixed this in master. > > Can you pull and test? > > Thanks, >
Re: [O] Blank page in LaTeX/PDF output
On Mon, Mar 03, 2014 at 07:08:35PM -0600, John Hendy wrote: > > On Mar 3, 2014 6:51 PM, "Peter Davis" wrote: > > > > > > On Sat, Mar 1, 2014, at 02:19 PM, John Hendy wrote: > > > I can confirm Peter's results, ... > > > > Thanks, John. > > > > > > > > I searched things like "latex page break 'section*' vs section" with > > > no obvious lead on why the two section styles would be different. > > > Regarding a bug report, if that's what this is, I just googled "latex > > > bugs" and got this page as the first hit: > > > - http://latex-project.org/bugs.html > > > > > > > > > Unfortunately, that site says they can't accept bugs that use any third > > party packages, and the org-exported LaTeX file starts: > > > > Can you delete all of those lines, recompile with pdflatex, and still > reproduce? > > If so, you're still good to go! > Unfortunately, it gets a lot of errors if I remove all the \usepackage lines, and I don't know which packages are third party or not. -pd -- Peter Davis The Tech Curmudgeon www.techcurmudgeon.com
Re: [O] Blank page in LaTeX/PDF output
On Mar 3, 2014 6:51 PM, "Peter Davis" wrote:
>
>
> On Sat, Mar 1, 2014, at 02:19 PM, John Hendy wrote:
> > I can confirm Peter's results, ...
>
> Thanks, John.
>
> >
> > I searched things like "latex page break 'section*' vs section" with
> > no obvious lead on why the two section styles would be different.
> > Regarding a bug report, if that's what this is, I just googled "latex
> > bugs" and got this page as the first hit:
> > - http://latex-project.org/bugs.html
> >
>
>
> Unfortunately, that site says they can't accept bugs that use any third
> party packages, and the org-exported LaTeX file starts:
>
Can you delete all of those lines, recompile with pdflatex, and still
reproduce?
If so, you're still good to go!
John
>
\documentclass[article,letterpaper,times,12pt,listings-bw,microtype]{scrartcl}
>\usepackage{microtype}
> \usepackage{mathpazo}
>\usepackage[scale=.9]{tgheros}
>\usepackage{tgcursor}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{fixltx2e}
> \usepackage{graphicx}
> \usepackage{longtable}
> \usepackage{float}
> \usepackage{wrapfig}
> \usepackage{rotating}
> \usepackage[normalem]{ulem}
> \usepackage{amsmath}
> \usepackage{textcomp}
> \usepackage{marvosym}
> \usepackage{wasysym}
> \usepackage{amssymb}
> \usepackage{hyperref}
>
>
> Thanks!
> -pd
>
>
> --
> Peter Davis
> www.techcurmudgeon.com
> www.timebums.com
Re: [O] Blank page in LaTeX/PDF output
On Sat, Mar 1, 2014, at 02:19 PM, John Hendy wrote:
> I can confirm Peter's results, ...
Thanks, John.
>
> I searched things like "latex page break 'section*' vs section" with
> no obvious lead on why the two section styles would be different.
> Regarding a bug report, if that's what this is, I just googled "latex
> bugs" and got this page as the first hit:
> - http://latex-project.org/bugs.html
>
Unfortunately, that site says they can't accept bugs that use any third
party packages, and the org-exported LaTeX file starts:
\documentclass[article,letterpaper,times,12pt,listings-bw,microtype]{scrartcl}
\usepackage{microtype}
\usepackage{mathpazo}
\usepackage[scale=.9]{tgheros}
\usepackage{tgcursor}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{amssymb}
\usepackage{hyperref}
Thanks!
-pd
--
Peter Davis
www.techcurmudgeon.com
www.timebums.com
Re: [O] http link character mistranslated
Daimrod writes: Fixed by ngz in commit 567ec87 > mirko writes: > >> Hi, > > Hello, > >> (Org-mode version 8.2.5h (release_8.2.5h-651-g897b60) >> >> I have an https address with an equal sign `=': >>https://forums.virtualbox.org/viewforum.php?f=3 >> >> When I try to access the link, the `=' is translated as `%D': >>https://forums.virtualbox.org/viewforum.php?f%3D3 > > I have the same problem here. It causes problem with docview and gnus > links. > >> I looked in org-open-at-point, and the translation appears somewhere in >> org-element-property. I did not look deeper. > > IIUC, since I don't know when, org-mode encode links with percent > encoding (you can check it by turning off org-mode (e.g. M-x > fundamental-mode)). > > My guess is that it is now the job of the link handler (FOLLOW arg in > org-add-link-type) to unescape the path if necessary, but I'm not sure > of it. > >> I tested this in an Emacs session with only org mode loaded (no user init) >> >> Thanks, >> >> Mirko >> >> -- Daimrod/Greg
Re: [O] link interfering with brackets when abbreviated
I'm a user who doesn't much care about link following command behavior, but Bastien's point about context is important. The behavior of a command needs to depend upon much more than just syntax. Two really dramatic examples are region narrowing and outline folding. When operating on a narrowed region there are a great many differences in how commands behave. Similarly, when a headline is folded, commands behave very differently. So be very careful to include consideration of the context when defining commands. Some context is much more subtle. My one link related comment is that I'm very puzzled by those who think that links in comments should not be followed. In programs I make heavy use of links in comments so that the comment can include a "see this [document]" as part of the comment. It's a link that other programmers want to follow. I don't often put comments into my org files, but I would expect to follow links in them also. In programming a comment means "don't try to compile or execute this". It doesn't mean destruction of all other semantic value. It means a highly selective removal of semantics. I would expect links in comments to still be followable. R Horn
[O] Bug? -- installing and updating on Windows
I installed a pre-built version of GNU Emacs 24.3.1 on Windows 8.1. It came with v7.9.3f of Org. I used the package management option to update to the latest version which (I think) it installed into my ~/.emacs.d directory (ELPA?). This looks to be Org v8.2.5h. However, org-version still lists as v7.9.3f. Is something not loading? -- David Masterson
Re: [O] Exporting LaTeX source blocks with HTML backend
Le 03/03/2014 21:54, Richard Lawrence a écrit :
Xavier Garrido writes:
#+BEGIN_SRC latex
\begin{align*}
x&=x\\
y&=y
\end{align*}
#+END_SRC
When I export this using the HTML exporter, the LaTeX code is wrapped in
a with class="org-src-container", and the actual code appears
inside a tag. Is this the behavior you see? Is that not what you
want?
In my case, the code is not even wrapped into org-src-container class,
it just does not appear at all.
Hmm. If Ista's solution doesn't work for you, you may want to look into
why this is happening. Maybe you have a variable or option set
somewhere that is suppressing export of these blocks for some reason. I
am using the "maint" version of the exporter (8.2.5h) and I don't use
HTML export much, so I am pretty sure what I see is the current default
behavior.
The non export is due to this setup
#+BEGIN_SRC emacs-lisp
(org-babel-do-load-languages
'org-babel-load-languages
'((emacs-lisp . t)
(latex . t)))
#+END_SRC
Cheers,
Xavier
Best,
Richard
(If possible, please encrypt your reply to me using my PGP key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
Re: [O] Exporting LaTeX source blocks with HTML backend
Hi Ista,
Le 03/03/2014 20:55, Ista Zahn a écrit :
Hi Xavier,
I think
#+begin_src latex :results drawer :exports results
\begin{align*}
x&=x\\
y&=y
\end{align*}
#+end_src
will give both syntax highlighting (in the code block) as well as
properly displayed equations in both latex and html export.
This one works. Thanks for your help.
Xavier
Best,
Ista
On Mon, Mar 3, 2014 at 2:39 PM, Xavier Garrido wrote:
Hi Richard,
Le 03/03/2014 20:24, Richard Lawrence a écrit :
I am facing one issue when I am exporting from orgmode to html. I like
to write LaTeX code within #+BEGIN_SRC latex ... #+END_SRC block mainly
to take benefit/advantage of the syntax highlighting (debugging long
LaTeX equations is "simpler"). The problem is that these code blocks are
not exported at all by the html export backend whereas the LaTeX backend
does. Of course, an easy solution will be to remove the
#+BEGIN_SRC/#+END_SRC lines and both latex and html exporters will just
do it right. But, as I said, syntax highlighting is really useful and I
can't imagine living without it.
I don't quite understand what you're looking for here. Are you wanting
these blocks to be exported as source code? Or do you want them to be
interpreted somehow?
I would like to get them interpreted as raw LaTeX code in such way MathJax
can reinterpret them as you said.
Removing the BEGIN_SRC/END_SRC lines will just result in raw LaTeX code
getting dumped into your HTML, and a browser won't know what to do with
that (at least not without help...are you wanting MathJax to interpret
it?).
As a summary I would like to do the following
#+BEGIN_SRC org
* Test LaTeX block
Syntax highlighting is always nice but the following block is not
exported in html. An option will be to remove the #+BEGIN_SRC
latex/#+END_SRC lines
#+BEGIN_SRC latex
\begin{align*}
x&=x\\
y&=y
\end{align*}
#+END_SRC
When I export this using the HTML exporter, the LaTeX code is wrapped in
a with class="org-src-container", and the actual code appears
inside a tag. Is this the behavior you see? Is that not what you
want?
In my case, the code is not even wrapped into org-src-container class, it
just does not appear at all.
If you are instead looking to get something in your HTML output that
looks like the result of compiling the LaTeX code, I am not exactly sure
how to accomplish this, but it looks like there is some useful
information in the section "Math formatting in HTML export" in the Org
manual about either using MathJax or preprocessing LaTeX code into
images with dvipng.
Actually, I just want to get the LaTeX code translated into raw code. As I
wrote, there is one solution, pretty easy to implement and may be used by
most of the org users : write raw LaTeX inside org document and use MathJax
for example, to interpret it in a convenient way. It is going to work for
both exporter html and latex. The point here is that using raw LaTeX code
makes me lose the syntax highlighting which is really useful for debugging
long LaTeX equation.
Cheers,
Xavier
Hope that helps,
Richard
(If possible, please encrypt your reply to me using my PGP key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See http://www.ocf.berkeley.edu/~rwl/encryption.html for more
information.)
Re: [O] Bug -- Tag with space
Bastien writes: > Hi David, > > David Masterson writes: > >> I see that Org-mode places tags on the same line as the task header. It >> also puts whitespace between the header and the tags so that the tags >> line up on the right side of the screen. I think I've found that >> org-mode doesn't line up the tags on the right side of the screen *IF* >> one of the tags has a space in it. Anyone else noticed that? > > Spaces are not allowed in tags, see the manual: > > "Tags are normal words containing letters, numbers, ‘_’, and ‘@’." Had that suspicion which is why I didn't file it as an official bug. I ran across this when setting up org-toodledo which will sync Org tasks with Toodledo tasks. Org-toodledo treats Toodledo Contexts as Org Tags (with a prepended '@') and Toodledo allows Contexts with spaces. Something to add to the documentation... -- David Masterson
Re: [O] link interfering with brackets when abbreviated
On 3/3/14, Sebastien Vauban wrote: >> [[http://dangerous-place.com][know they are links]]. > > M-x visible-mode the whole point is that comments and footnote definitions obscure the fact that there is a link there. who wants to run visible-mode all the time? that would defeat the purpose of link collapsing. nobody is going to run it if there is no indication that there is a link there.
Re: [O] link interfering with brackets when abbreviated
Samuel Wales wrote: > if and only if it is not desirable to highlight links, then perhaps > they could be un-collapsed so that you > [[http://dangerous-place.com][know they are links]]. M-x visible-mode Best regards, Seb -- Sebastien Vauban
Re: [O] export ICal without evaluate code block
Greppig org confirms icalendar is likely the only exception. While i find this surprising I guess there is a good reason, right? Cheers, Simon On 02/26/2014 10:21 PM, Nicolas Goaziou wrote: Hello, Simon Thum writes: I have some worries here; Why is it so hard to avoid evaluation/modification in org files during export? I don't think it is. There is a single variable to switch in order to control this: `org-export-babel-evaluate'. Do you think that it doesn't behave as expected? I use -batch, I would have tought that was enough, but if I'm getting your answer below right, then setting those 2 parameters is not enough either, because some backends fiddle with them? I have searched the docs but did not find anything about backends overriding these settings. Besides `icalendar' in a very specific configuration (when exporting a calendar, not a single document) I don't think any back-end overwrites the previous variable. Regards,
Re: [O] Exporting LaTeX source blocks with HTML backend
Xavier Garrido writes:
>>> #+BEGIN_SRC latex
>>> \begin{align*}
>>> x&=x\\
>>> y&=y
>>> \end{align*}
>>> #+END_SRC
>> When I export this using the HTML exporter, the LaTeX code is wrapped in
>> a with class="org-src-container", and the actual code appears
>> inside a tag. Is this the behavior you see? Is that not what you
>> want?
> In my case, the code is not even wrapped into org-src-container class,
> it just does not appear at all.
Hmm. If Ista's solution doesn't work for you, you may want to look into
why this is happening. Maybe you have a variable or option set
somewhere that is suppressing export of these blocks for some reason. I
am using the "maint" version of the exporter (8.2.5h) and I don't use
HTML export much, so I am pretty sure what I see is the current default
behavior.
Best,
Richard
(If possible, please encrypt your reply to me using my PGP key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
[O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)
On Feb 28, 2014, at 15:26, Andreas Leha wrote: > "R. Michael Weylandt " > writes: > >> I've tried this with Org 7.9.3 and 8.2.5h to the same result: >> >> <--> >> #+TITLE: Test >> * One >> Here is a [[http://google.com/search?q=orgmode][link]] >> <--> >> >> Exporting to HTML doesn't transform the link but exporting to LaTeX results >> in the (non-working) http://google.com/search?%3Dorgmode >> >> Is there a reason for this behavior and, if so, a way to work around it? >> >> RFC 3986 2.2 explicitly says URLs may include `=` and =url-encode-url= >> doesn't change the link in question. >> >> I've played with org-url-hexify-p and read past ML discussions, but >> they seem primarily concerned with characters which should not appear >> in URIs. >> >> Thanks, >> Michael > > > > Hi Michael, > > I have recently been bitten by this as well. Based on a block > post [fn:1], I now have this in my .emacs as a work-around: > > --8<---cut here---start->8--- > (defun al-link-filter (contents backend info) > (let ((contents (replace-regexp-in-string "#\\+name:.*$" "" > contents)));; old and unrelated > (replace-regexp-in-string "%3D" "=" contents))) > (add-to-list 'org-export-filter-final-output-functions 'al-link-filter) > --8<---cut here---end--- Hi Andreas, Thanks for this. I had time to dig further and it seems that the 'problem' is the default value of org-link-escape-chars, which explicitly escapes = as well as other valid URL characters. Perhaps someone more familiar with this code could explain the choice these escapes. Michael [Subject updated because the problem isn't LaTeX specific in 8.2.5h, only in 7.9.3]
[O] How to ensure that (org-get-heading) is pretty?
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
Re: [O] Exporting LaTeX source blocks with HTML backend
Hi Xavier,
I think
#+begin_src latex :results drawer :exports results
\begin{align*}
x&=x\\
y&=y
\end{align*}
#+end_src
will give both syntax highlighting (in the code block) as well as
properly displayed equations in both latex and html export.
Best,
Ista
On Mon, Mar 3, 2014 at 2:39 PM, Xavier Garrido wrote:
> Hi Richard,
>
> Le 03/03/2014 20:24, Richard Lawrence a écrit :
>
>>> I am facing one issue when I am exporting from orgmode to html. I like
>>> to write LaTeX code within #+BEGIN_SRC latex ... #+END_SRC block mainly
>>> to take benefit/advantage of the syntax highlighting (debugging long
>>> LaTeX equations is "simpler"). The problem is that these code blocks are
>>> not exported at all by the html export backend whereas the LaTeX backend
>>> does. Of course, an easy solution will be to remove the
>>> #+BEGIN_SRC/#+END_SRC lines and both latex and html exporters will just
>>> do it right. But, as I said, syntax highlighting is really useful and I
>>> can't imagine living without it.
>>
>> I don't quite understand what you're looking for here. Are you wanting
>> these blocks to be exported as source code? Or do you want them to be
>> interpreted somehow?
>
>
> I would like to get them interpreted as raw LaTeX code in such way MathJax
> can reinterpret them as you said.
>
>
>> Removing the BEGIN_SRC/END_SRC lines will just result in raw LaTeX code
>> getting dumped into your HTML, and a browser won't know what to do with
>> that (at least not without help...are you wanting MathJax to interpret
>> it?).
>>
>>> As a summary I would like to do the following
>>>
>>> #+BEGIN_SRC org
>>> * Test LaTeX block
>>> Syntax highlighting is always nice but the following block is not
>>> exported in html. An option will be to remove the #+BEGIN_SRC
>>> latex/#+END_SRC lines
>>>
>>> #+BEGIN_SRC latex
>>> \begin{align*}
>>> x&=x\\
>>> y&=y
>>> \end{align*}
>>> #+END_SRC
>>
>> When I export this using the HTML exporter, the LaTeX code is wrapped in
>> a with class="org-src-container", and the actual code appears
>> inside a tag. Is this the behavior you see? Is that not what you
>> want?
>
> In my case, the code is not even wrapped into org-src-container class, it
> just does not appear at all.
>
>
>
>>
>> If you are instead looking to get something in your HTML output that
>> looks like the result of compiling the LaTeX code, I am not exactly sure
>> how to accomplish this, but it looks like there is some useful
>> information in the section "Math formatting in HTML export" in the Org
>> manual about either using MathJax or preprocessing LaTeX code into
>> images with dvipng.
>
>
> Actually, I just want to get the LaTeX code translated into raw code. As I
> wrote, there is one solution, pretty easy to implement and may be used by
> most of the org users : write raw LaTeX inside org document and use MathJax
> for example, to interpret it in a convenient way. It is going to work for
> both exporter html and latex. The point here is that using raw LaTeX code
> makes me lose the syntax highlighting which is really useful for debugging
> long LaTeX equation.
>
> Cheers,
> Xavier
>
>> Hope that helps,
>> Richard
>>
>>
>> (If possible, please encrypt your reply to me using my PGP key:
>> Key ID: CF6FA646
>> Fingerprint: 9969 43E1 CF6F A646.
>> See http://www.ocf.berkeley.edu/~rwl/encryption.html for more
>> information.)
>
>
>
Re: [O] link interfering with brackets when abbreviated
if and only if it is not desirable to highlight links, then perhaps they could be un-collapsed so that you [[http://dangerous-place.com][know they are links]].
Re: [O] Exporting LaTeX source blocks with HTML backend
Hi Richard,
Le 03/03/2014 20:24, Richard Lawrence a écrit :
I am facing one issue when I am exporting from orgmode to html. I like
to write LaTeX code within #+BEGIN_SRC latex ... #+END_SRC block mainly
to take benefit/advantage of the syntax highlighting (debugging long
LaTeX equations is "simpler"). The problem is that these code blocks are
not exported at all by the html export backend whereas the LaTeX backend
does. Of course, an easy solution will be to remove the
#+BEGIN_SRC/#+END_SRC lines and both latex and html exporters will just
do it right. But, as I said, syntax highlighting is really useful and I
can't imagine living without it.
I don't quite understand what you're looking for here. Are you wanting
these blocks to be exported as source code? Or do you want them to be
interpreted somehow?
I would like to get them interpreted as raw LaTeX code in such way
MathJax can reinterpret them as you said.
Removing the BEGIN_SRC/END_SRC lines will just result in raw LaTeX code
getting dumped into your HTML, and a browser won't know what to do with
that (at least not without help...are you wanting MathJax to interpret
it?).
As a summary I would like to do the following
#+BEGIN_SRC org
* Test LaTeX block
Syntax highlighting is always nice but the following block is not
exported in html. An option will be to remove the #+BEGIN_SRC
latex/#+END_SRC lines
#+BEGIN_SRC latex
\begin{align*}
x&=x\\
y&=y
\end{align*}
#+END_SRC
When I export this using the HTML exporter, the LaTeX code is wrapped in
a with class="org-src-container", and the actual code appears
inside a tag. Is this the behavior you see? Is that not what you
want?
In my case, the code is not even wrapped into org-src-container class,
it just does not appear at all.
If you are instead looking to get something in your HTML output that
looks like the result of compiling the LaTeX code, I am not exactly sure
how to accomplish this, but it looks like there is some useful
information in the section "Math formatting in HTML export" in the Org
manual about either using MathJax or preprocessing LaTeX code into
images with dvipng.
Actually, I just want to get the LaTeX code translated into raw code. As
I wrote, there is one solution, pretty easy to implement and may be used
by most of the org users : write raw LaTeX inside org document and use
MathJax for example, to interpret it in a convenient way. It is going to
work for both exporter html and latex. The point here is that using raw
LaTeX code makes me lose the syntax highlighting which is really useful
for debugging long LaTeX equation.
Cheers,
Xavier
Hope that helps,
Richard
(If possible, please encrypt your reply to me using my PGP key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
Re: [O] link interfering with brackets when abbreviated
tldr, and wary of bikeshedding, but a fool so i rush in: 1] currently in maint the awesome package org-mouse.el activates links in comments. RET does not. Perhaps this could be made more consistent or optional? 2] currently in maint links are not fontified in comments or footnote definitions. Perhaps they could be if they are active to avoid major surprises, or optionally for those who like me prefer [as a foolish bikeshedding user] to fontify them. then again, i am the guy who insists on multiple paragraphs in inline footnote definitions, including for fontification if the fontification ever gets parserified. how crazy can you get?! btw, the nuclear power plant MUST be painted blue.
Re: [O] MobileOrg
Some more tips: * I have some code to monitor the mobile org file that changes and automagically update the desktop based Org. This means if you forget to push and the mobile Org is stale, you can also remotely force a push by adding a dummy item and syncing 2x. http://kenmankoff.com/2012/08/17/emacs-org-mode-and-mobileorg-auto-sync/ * You can add "#+FILETAGS: REFILE" to the top of the file where mobile items get synced, and then in a custom agenda make sure those all appear in a section so you remember to file them once they are on the desktop Org. (C-w). Hope this helps, -k. On Mon, 3 Mar 2014, Sean Escriva wrote: Hi David, Yes, the maintainers are watching this list :) I'm one of them. It looks like John gave a nice thorough answer for most things, so I won't repeat his responses. David Masterson writes: Anyone using MobileOrg on iOS? I can't figure out how to set it up from the documentation -- I think I'm missing something. I have a number of questions: 1. What needs to be setup for the first time push from Emacs to the Dropbox Apps/MobileOrg directory? You will need to define org-mobile-directory, using Dropbox the correct default setting is: "~/Dropbox/Apps/MobileOrg" For example, I have (setq org-mobile-directory "~/Dropbox/Apps/MobileOrg") in my config. Then you can org-mobile-push to stage your files in this location. You should not manually create any folders in Dropbox. 2. What should the results of the first time push be that I should check to ensure that it worked? Your org-agenda-files will be staged and an index.org file and checksums.dat will be created. 3. What is MobileOrg looking for in the Dropbox directory? MobileOrg needs to be authorized as a dropbox app, this step will create the correct path. 4. What do I need to configure in MobileOrg? 5. What will MobileOrg put back in the Dropbox directory? 6. What do I need to do to get Emacs to pull from the Dropbox directory? org-mobile-pull will pull in changes. And so on. Are the maintainers of MobileOrg watching this mailing list? A while back I outlined basic troubleshooting steps that should help: https://github.com/MobileOrg/mobileorg/wiki/Troubleshooting Feel free to contact me directly with questions or hop in #mobileorg on freenode irc if that's better for you. I started work on an improved documentation site, but it needs an overhaul to be easier for others to contribute.
Re: [O] Exporting LaTeX source blocks with HTML backend
Hi Xavier,
Xavier Garrido writes:
> I am facing one issue when I am exporting from orgmode to html. I like
> to write LaTeX code within #+BEGIN_SRC latex ... #+END_SRC block mainly
> to take benefit/advantage of the syntax highlighting (debugging long
> LaTeX equations is "simpler"). The problem is that these code blocks are
> not exported at all by the html export backend whereas the LaTeX backend
> does. Of course, an easy solution will be to remove the
> #+BEGIN_SRC/#+END_SRC lines and both latex and html exporters will just
> do it right. But, as I said, syntax highlighting is really useful and I
> can't imagine living without it.
I don't quite understand what you're looking for here. Are you wanting
these blocks to be exported as source code? Or do you want them to be
interpreted somehow?
Removing the BEGIN_SRC/END_SRC lines will just result in raw LaTeX code
getting dumped into your HTML, and a browser won't know what to do with
that (at least not without help...are you wanting MathJax to interpret
it?).
> As a summary I would like to do the following
>
> #+BEGIN_SRC org
> * Test LaTeX block
>Syntax highlighting is always nice but the following block is not
> exported in html. An option will be to remove the #+BEGIN_SRC
> latex/#+END_SRC lines
>
>#+BEGIN_SRC latex
> \begin{align*}
> x&=x\\
> y&=y
> \end{align*}
>#+END_SRC
When I export this using the HTML exporter, the LaTeX code is wrapped in
a with class="org-src-container", and the actual code appears
inside a tag. Is this the behavior you see? Is that not what you
want?
If you are instead looking to get something in your HTML output that
looks like the result of compiling the LaTeX code, I am not exactly sure
how to accomplish this, but it looks like there is some useful
information in the section "Math formatting in HTML export" in the Org
manual about either using MathJax or preprocessing LaTeX code into
images with dvipng.
Hope that helps,
Richard
(If possible, please encrypt your reply to me using my PGP key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
Re: [O] MobileOrg 1.5.2 - Dropbox sync error
Erwin Panen writes: > Hi everybody, > > I'm trying to re-enable MobileOrg on my 1st gen iPad. > iOS is version 5.1.1 (9B206) > MobilOrg is version 1.5.2 > Unfortunately this version is outdated at this point. Due to the way the app store works for transitioning maintainership the current MobileOrg in the app store is actually viewed by Apple as a totally *new* app. > I've had login problems on iPhone too, but these have been solved by > reinstalling MobileOrg (1.6.1 now). > (There was no upgrade notification in the App Store..) > > Problem is I cannot upgrade the ios version on the iPad as the machine > is getting way too slow. > But it remains a perfect tool for a lot of jobs. > > MobileOrg throws the familiar Dropbox Error: > Bad username and password or network error.. My only guess is that is due to the outdated dropbox sdk in the older version of MobileOrg. I wish I could be of more help, but can't do much for the older versions at this point. sorry! -- -sean
Re: [O] MobileOrg
Hi David, Yes, the maintainers are watching this list :) I'm one of them. It looks like John gave a nice thorough answer for most things, so I won't repeat his responses. David Masterson writes: > Anyone using MobileOrg on iOS? I can't figure out how to set it up from > the documentation -- I think I'm missing something. I have a number of > questions: > > 1. What needs to be setup for the first time push from Emacs to the > Dropbox Apps/MobileOrg directory? You will need to define org-mobile-directory, using Dropbox the correct default setting is: "~/Dropbox/Apps/MobileOrg" For example, I have (setq org-mobile-directory "~/Dropbox/Apps/MobileOrg") in my config. Then you can org-mobile-push to stage your files in this location. You should not manually create any folders in Dropbox. > > 2. What should the results of the first time push be that I should check > to ensure that it worked? Your org-agenda-files will be staged and an index.org file and checksums.dat will be created. > > 3. What is MobileOrg looking for in the Dropbox directory? MobileOrg needs to be authorized as a dropbox app, this step will create the correct path. > > 4. What do I need to configure in MobileOrg? > > 5. What will MobileOrg put back in the Dropbox directory? > > 6. What do I need to do to get Emacs to pull from the Dropbox directory? org-mobile-pull will pull in changes. > > And so on. Are the maintainers of MobileOrg watching this mailing list? A while back I outlined basic troubleshooting steps that should help: https://github.com/MobileOrg/mobileorg/wiki/Troubleshooting Feel free to contact me directly with questions or hop in #mobileorg on freenode irc if that's better for you. I started work on an improved documentation site, but it needs an overhaul to be easier for others to contribute. -- -sean
Re: [O] Context of interaction vs. literal syntactic interpretation
Hello, On 3 March 2014 11:09, Matt Lundin wrote: > Bastien writes: > > > > For most commands, the first literal syntactic interpretation is the > > only relevant context of interaction: e.g., it would not make sense to > > try updating a tag outside of a headline (i.e. outside of where a tag > > is a tag, from the parser's view.) > > > > For some commands, another higher context can also be relevant: e.g., > > when the point is on a heading and the user hit C-c C-o, Org needs to > > know whether we are on a link (in this case it will open the link). If > > not, it checks for a higher context: when we are on a heading, it will > > look for multiple links and prompt the user for which one to open. > > > > (A generalization of this "links-in-a-heading" behavior for something > > like "links-in-a-paragraph", as suggested by Gustav, is a good idea.) > > Is the question here perhaps a simple one of refactoring? > > Nicolas is doing amazing work at making org file parsing more > systematic, precise, and predictable. (Thank you!) And I agree with him > that a function named org-open-link-at-point should, for the sake of > precision and consistency, only open a link at the point. > > I also agree that such a function should do nothing in the context of a > comment, which should simply be a string. FWIW, it seems to me that > there are still several places in the source code that could be cleaned > up in this way. For instance, org-mode code examples designated for > export have unwanted effects in the agenda. Try putting this in an > agenda file... > > --8<---cut here---start->8--- > * An example > : * Watch me > : <2014-03-03 Mon 9:00> > --8<---cut here---end--->8--- > > The problem, it seems to me, is that org-open-at-point is ambiguously > named. The last bit, "at-point", suggests a precise scope, but the > beginning "org-open" implies a broad, fuzzy scope (i.e., it is not clear > what is being opened). The problem is that org-open-at-point doubles as > a meta function and a more precise function to open links at the point > --- i.e., it implements within itself all the internals this more > precise task. > > Org, of course, has a lot of helpful "dwim" functions (e.g., > org-meta-return, org-cycle, etc.). I would not want to lose these. As > Bastien suggested, these functions are precisely what make org-mode so > easy and intuitive to use. However, org has historically implemented > many of its internals in an ad-hoc fashion within very large functions. > This has led to some redundancy and opacity. This is especially true for > a function like org-open-at-point, which is both precise and broad. This > is where org-mode stands a lot to gain from refactoring the code base > around Nicolas's parser. > > My view is that precision and usability need not be mutually exclusive. > Might we have a bunch of precise, modular functions that rely on the new > parser? E.g., something like org-open-link-at-point. This would do > exactly what it says -- i.e., open a link if one is at the point. Then, > on top of these function s we could rebuild fuzzier "meta" and "dwim" > functions (e.g., org-open-links-in-paragraph, org-open-links-in-entry, > org-meta-open, org-open-at-point,... whatever). > > In short, I am excited by the potential that the parser provides to make > the code base more transparent, granular, and precise. > > Matt I have to agree with Nicolas' opion and Matt's take on how it could be implemented. Have org-open-at-point do exactly what it says, act on what is at point (be it a link, a timestamp, a footnote definition, etc). Then have C-c C-o be a one of the meta overloaded functions that finds context and acts on it accordingly: - If object at point can be opened, opened it - If in a paragraph, find all actionable[1] items and offer them for selection - If on a headline, find all actionable[1] items and offer them for selection [1] Footnotes and links In my opinion you wouldn't want it to also include timestamps (for paragraphs and headlines) and tags (for headlines) because those are agenda commands rather than navigation commands. If I'm on a timestamp or tag, opening it makes sense. If I'm trying to open from a headline/paragraph, I'm likely looking for links (which can include footnotes since they link to another portion of the document) so wouldn't want agenda commands. Or have it customizable as a set of alists that map what should be collected at what level. For example: #+begin_src emacs-lisp (setq org-open-context '((point . 'org-open-at-point) (footnote . 'nil) (sourceblock . 'nil) (table . 'nil) (paragraph . 'org-open-collect-links) (headline . 'org-open-collect-links))) #+end_src If something of this sort is then implemented on all the various overloaded commands (M-Ret, C
[O] Exporting LaTeX source blocks with HTML backend
Dear Orgers,
I am facing one issue when I am exporting from orgmode to html. I like
to write LaTeX code within #+BEGIN_SRC latex ... #+END_SRC block mainly
to take benefit/advantage of the syntax highlighting (debugging long
LaTeX equations is "simpler"). The problem is that these code blocks are
not exported at all by the html export backend whereas the LaTeX backend
does. Of course, an easy solution will be to remove the
#+BEGIN_SRC/#+END_SRC lines and both latex and html exporters will just
do it right. But, as I said, syntax highlighting is really useful and I
can't imagine living without it.
I have tried different things from adding a "before parsing hook" which
delete lines containing #+BEGIN_SRC/#+END_SRC (then I get problem with
other source block such as 'sh' that I want to be exported to 'pre' code
in html) to trying to play with filters (so far, I do not get any
getting LaTeX source block when exporting to html).
As a summary I would like to do the following
#+BEGIN_SRC org
* Test LaTeX block
Syntax highlighting is always nice but the following block is not
exported in html. An option will be to remove the #+BEGIN_SRC
latex/#+END_SRC lines
#+BEGIN_SRC latex
\begin{align*}
x&=x\\
y&=y
\end{align*}
#+END_SRC
* Test shell block
Here, I would like to keep the following source block as it is to get
it exported properly by html backend (namely as code)
#+BEGIN_SRC sh
uname -a
#+END_SRC
#+END_SRC
Thanks for your help,
Xavier
Re: [O] Context of interaction vs. literal syntactic interpretation
Matt Lundin writes: > ... > My view is that precision and usability need not be mutually > exclusive.Might we have a bunch of precise, modular functions that > rely on the new parser? E.g., something like > org-open-link-at-point. This would do exactly what it says -- i.e., > open a link if one is at the point. Then, on top of these function s > we could rebuild fuzzier "meta" and "dwim" functions (e.g., > org-open-links-in-paragraph, org-open-links-in-entry, org-meta-open, > org-open-at-point,... whatever). > ... I've been composing an email in my head that ran almost exactly along the lines you describe, although I doubt it would have been as clear. Thank you for sending this! Nick
Re: [O] link interfering with brackets when abbreviated
Gustav Wikström wrote: > About the issue of links in comments (My opinion, for what it's worth): > It's a comment.. Expect it to behave as one. Worst case: copy the link and > paste it in the browser. Or use `M-x ffap' (find-file-at-point)... Best regards, Seb -- Sebastien Vauban
Re: [O] Context of interaction vs. literal syntactic interpretation
Bastien writes: > > For most commands, the first literal syntactic interpretation is the > only relevant context of interaction: e.g., it would not make sense to > try updating a tag outside of a headline (i.e. outside of where a tag > is a tag, from the parser's view.) > > For some commands, another higher context can also be relevant: e.g., > when the point is on a heading and the user hit C-c C-o, Org needs to > know whether we are on a link (in this case it will open the link). If > not, it checks for a higher context: when we are on a heading, it will > look for multiple links and prompt the user for which one to open. > > (A generalization of this "links-in-a-heading" behavior for something > like "links-in-a-paragraph", as suggested by Gustav, is a good idea.) Is the question here perhaps a simple one of refactoring? Nicolas is doing amazing work at making org file parsing more systematic, precise, and predictable. (Thank you!) And I agree with him that a function named org-open-link-at-point should, for the sake of precision and consistency, only open a link at the point. I also agree that such a function should do nothing in the context of a comment, which should simply be a string. FWIW, it seems to me that there are still several places in the source code that could be cleaned up in this way. For instance, org-mode code examples designated for export have unwanted effects in the agenda. Try putting this in an agenda file... --8<---cut here---start->8--- * An example : * Watch me : <2014-03-03 Mon 9:00> --8<---cut here---end--->8--- The problem, it seems to me, is that org-open-at-point is ambiguously named. The last bit, "at-point", suggests a precise scope, but the beginning "org-open" implies a broad, fuzzy scope (i.e., it is not clear what is being opened). The problem is that org-open-at-point doubles as a meta function and a more precise function to open links at the point --- i.e., it implements within itself all the internals this more precise task. Org, of course, has a lot of helpful "dwim" functions (e.g., org-meta-return, org-cycle, etc.). I would not want to lose these. As Bastien suggested, these functions are precisely what make org-mode so easy and intuitive to use. However, org has historically implemented many of its internals in an ad-hoc fashion within very large functions. This has led to some redundancy and opacity. This is especially true for a function like org-open-at-point, which is both precise and broad. This is where org-mode stands a lot to gain from refactoring the code base around Nicolas's parser. My view is that precision and usability need not be mutually exclusive. Might we have a bunch of precise, modular functions that rely on the new parser? E.g., something like org-open-link-at-point. This would do exactly what it says -- i.e., open a link if one is at the point. Then, on top of these function s we could rebuild fuzzier "meta" and "dwim" functions (e.g., org-open-links-in-paragraph, org-open-links-in-entry, org-meta-open, org-open-at-point,... whatever). In short, I am excited by the potential that the parser provides to make the code base more transparent, granular, and precise. Matt
Re: [O] Change Todo colors
Should be able to just use `org-todo-keyword-faces` the way he was trying
in the original post. I've got the following in my init.el. Re-evaluating
it after changes (C-M-x) and then switching back to an org buffer makes the
changes on the fly:
,
| (setq
org-todo-keyword-faces
| `(("TODO"
|:weight bold
|:foreground ,(jlp/zenburn-color "zenburn-cyan"))
| ("CLOSE"
|:weight bold
|:underline (:color
|,(jlp/zenburn-color
| "zenburn-blue"))
|:foreground ,(jlp/zenburn-color
| "zenburn-red"))
| ("WAIT"
|:weight bold
|:foreground ,(jlp/zenburn-color
| "zenburn-yellow"))
| ("PEND"
|:weight bold
|:foreground ,(jlp/zenburn-color
| "zenburn-orange"))
| ("MEET"
|:weight bold
|:foreground ,(jlp/zenburn-color
| "zenburn-yellow"))
| ("MET"
|:weight bold
|:foreground ,(jlp/zenburn-color
| "zenburn-yellow-2"))
| ("TIME"
|:weight bold
|:foreground ,(jlp/zenburn-color
| "zenburn-yellow"))
| ("CLOCKED"
|:weight bold
|:foreground ,(jlp/zenburn-color
|"zenburn-yellow-2"
`
jlp/zenburn-color is just a shortcut to pull the list of colors from the
Zenburn color theme rather than have to remember the equivalent HEX colors.
Regards,
Jon
On 3 March 2014 10:11, Fabrice Niessen wrote:
> zwz wrote:
> > Chris Henderson writes:
> >
> >> I'd like to change the color of Next to Red and Started to brown. At the
> >> moment, todo/ next and started all showing as red.
> >>
> >> Here is my .emacs snippet.
> >>
> >> (setq org-todo-keywords
> >> '((sequence "TODO(t)" "Next(n)" "Started(s)" "|" "DONE(d!)")
> >> (sequence "|" "CANCELED(c)")))
> >>
> >> (setq org-todo-keyword-faces
> >>'(("CANCELED" . (:foreground "blue" :weight bold
> >
> > You should use "custom-set-faces" instead of "setq".
>
> or `set-face-attribute', as I do in my Emacs configuration file[1]:
>
> --8<---cut here---start->8---
> (with-eval-after-load "org-faces"
>
> ;; faces for specific TODO keywords
> (setq org-todo-keyword-faces
> '(("NEW" . leuven-org-created-kwd)
> ("TODO" . org-todo)
> ("STRT" . leuven-org-inprogress-kwd)
> ("WAIT" . leuven-org-waiting-for-kwd)
> ("SDAY" . leuven-org-someday-kwd)
> ("DONE" . org-done)
> ("CANX" . org-done)))
>
> ;; Org standard faces
> (set-face-attribute 'org-todo nil
> :weight 'bold :box '(:line-width 1 :color
> "#D8ABA7")
> :foreground "#D8ABA7" :background "#FFE6E4")
>
> (set-face-attribute 'org-done nil
> :weight 'bold :box '(:line-width 1 :color
> "#BB")
> :foreground "#BB" :background "#F0F0F0")
>
> ;; Org non-standard faces
> (defface leuven-org-created-kwd
> '((t (:weight normal :box (:line-width 1 :color "#EEE9C3")
> :foreground "#1A1A1A" :background "#FDFCD8")))
> "Face used to display state NEW.")
> (defface leuven-org-inprogress-kwd
> '((t (:weight bold :box (:line-width 1 :color "#D9D14A")
> :foreground "#D9D14A" :background "#FCFCDC")))
> "Face used to display state STRT.")
> (defface leuven-org-waiting-for-kwd
> '((t (:weight bold :box (:line-width 1 :color "#89C58F")
> :foreground "#89C58F" :background "#E2FEDE")))
> "Face used to display state WAIT.")
> (defface leuven-org-someday-kwd
> '((t (:weight bold :box (:line-width 1 :color "#9EB6D4")
> :foreground "#9EB6D4" :background "#E0EFFF")))
> "Face used to display state SDAY."))
> --8<---cut here---end--->8---
>
> Best regards,
> Fabrice
>
> [1] https://github.com/fniessen/emacs-leuven/blob/master/emacs-leuven.el
>
> --
> Fabrice Niessen
> Leuven, Belgium
> http://www.pirilampo.org/
>
>
>
Re: [O] Change Todo colors
zwz wrote:
> Chris Henderson writes:
>
>> I'd like to change the color of Next to Red and Started to brown. At the
>> moment, todo/ next and started all showing as red.
>>
>> Here is my .emacs snippet.
>>
>> (setq org-todo-keywords
>> '((sequence "TODO(t)" "Next(n)" "Started(s)" "|" "DONE(d!)")
>> (sequence "|" "CANCELED(c)")))
>>
>> (setq org-todo-keyword-faces
>>'(("CANCELED" . (:foreground "blue" :weight bold
>
> You should use "custom-set-faces" instead of "setq".
or `set-face-attribute', as I do in my Emacs configuration file[1]:
--8<---cut here---start->8---
(with-eval-after-load "org-faces"
;; faces for specific TODO keywords
(setq org-todo-keyword-faces
'(("NEW" . leuven-org-created-kwd)
("TODO" . org-todo)
("STRT" . leuven-org-inprogress-kwd)
("WAIT" . leuven-org-waiting-for-kwd)
("SDAY" . leuven-org-someday-kwd)
("DONE" . org-done)
("CANX" . org-done)))
;; Org standard faces
(set-face-attribute 'org-todo nil
:weight 'bold :box '(:line-width 1 :color "#D8ABA7")
:foreground "#D8ABA7" :background "#FFE6E4")
(set-face-attribute 'org-done nil
:weight 'bold :box '(:line-width 1 :color "#BB")
:foreground "#BB" :background "#F0F0F0")
;; Org non-standard faces
(defface leuven-org-created-kwd
'((t (:weight normal :box (:line-width 1 :color "#EEE9C3")
:foreground "#1A1A1A" :background "#FDFCD8")))
"Face used to display state NEW.")
(defface leuven-org-inprogress-kwd
'((t (:weight bold :box (:line-width 1 :color "#D9D14A")
:foreground "#D9D14A" :background "#FCFCDC")))
"Face used to display state STRT.")
(defface leuven-org-waiting-for-kwd
'((t (:weight bold :box (:line-width 1 :color "#89C58F")
:foreground "#89C58F" :background "#E2FEDE")))
"Face used to display state WAIT.")
(defface leuven-org-someday-kwd
'((t (:weight bold :box (:line-width 1 :color "#9EB6D4")
:foreground "#9EB6D4" :background "#E0EFFF")))
"Face used to display state SDAY."))
--8<---cut here---end--->8---
Best regards,
Fabrice
[1] https://github.com/fniessen/emacs-leuven/blob/master/emacs-leuven.el
--
Fabrice Niessen
Leuven, Belgium
http://www.pirilampo.org/
Re: [O] [Bug] org-open-at-point no longer unescapes shell/elisp links
Hello, Matt Lundin writes: > When I create a link with org-insert-link, it automatically escapes > spaces. > > E.g., > > C-c C-l shell:ls *.org [RET] > a shell link [RET] > > results in > > [[shell:ls%20*.org][a shell link]] > > The problem is that the recent rewrite of org-open-at-point (commit > fc9ce86cfc1ecf7e86028027a12875a26500e774) removed all invocations of > org-unescape-link. Correct. This should be fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] org-agenda-do-date-late and emacs freeze
Am Sun, Mar 02, 2014 at 10:21:18PM -0600, Matt Lundin schrieb: > Does it happen when you have filtered the agenda? If so, then I can > confirm this bug... > > I am using... > > - emacs 24.3.1 > - org 8.2.5h yes. And I have the same versions as you.
Re: [O] [Bug] org-open-at-point no longer unescapes shell/elisp links
Hello, · Matt Lundin wrote: > When I create a link with org-insert-link, it automatically escapes > spaces. > > E.g., > > C-c C-l shell:ls *.org [RET] > a shell link [RET] > > results in > > [[shell:ls%20*.org][a shell link]] the same holds true for a link to a file which has spaces in the name: [[file:c:/Program Files/desktop.ini]] results in [[file:c:/Program%20Files/desktop.ini]] which does not work. It worked prior to the mentioned commit. > The problem is that the recent rewrite of org-open-at-point (commit > fc9ce86cfc1ecf7e86028027a12875a26500e774) removed all invocations of > org-unescape-link. Bis neulich ... Thomas
Re: [O] link interfering with brackets when abbreviated
Bastien writes: > Hi Nicolas, > > Nicolas Goaziou writes: > >> Sorry for not being clear. I did try, I didn't get any error. My dummy >> entry was: >> >> * TODO [[http://orgmode.org]] >> >> in a block agenda and >> >> * [[http://orgmode.org]] >> DEADLINE: <2014-03-01 sam.> >> >> in regular agenda. >> >> Both times, I could open the link. So, could you send me a dummy entry >> where the bug can be reproduced? It will save me a lot of time. > > Sorry, all my time has been swallowed by my rant, I will try to > provide a reproducible recipe later on -- but the error is real. > > It works for small files I tested, but not for my real agenda files. > I suspect maybe the lazy parsing of open-but-not-yet-visible agenda > files somehow prevents the links to get opened. > > Maybe someone else can also report if C-c C-o works on his agendas. I cannot reproduce this (though I do have trouble opening escaped links -- see bug report in another thread). Matt
Re: [O] Please confirm your message
Matt Lundin writes: > This email resulted from my attempt to reply to an obfuscated email from > the gmane public mailer. I have no idea why it sent my reply to the > list. > > As an aside, is there a graceful with these emails in gnus. When I do Should read: "is there a graceful way to deal with these emails in gnus?" Matt
Re: [O] Please confirm your message
This email resulted from my attempt to reply to an obfuscated email from
the gmane public mailer. I have no idea why it sent my reply to the
list.
As an aside, is there a graceful with these emails in gnus. ( When I do
a wide reply to emails with addresses obfuscated by gmane, I always get
these requests for confirmation.
Matt
Matt Lundin writes:
> Gmane Remailer
> writes:
>
>> This message was created automatically by mail delivery software (TMDA).
>>
>> Your message attached below is being held because the address
>> has not been verified.
>>
>> To release your message for delivery, please send an empty message
>> to the following address, or use your mailer's "Reply" feature.
>>
>>
>> public-emacs-orgmode-mXXj517/zsq-confirm-1393852159.12983.219...@plane.gmane.org
>>
>> This confirmation verifies that your message is legitimate and not
>> junk-mail. You should only have to confirm your address once.
>>
>> If you do not respond to this confirmation request within 14 days,
>> your message will not be delivered.
>>
>> From: Matt Lundin
>> Subject: Re: [bug] Incompatible agenda commands
>> To: Bastien
>> Cc: "Sebastien Vauban"
>> ,
>> public-emacs-orgmode-mXXj517/z...@plane.gmane.org
>> Date: Mon, 03 Mar 2014 07:09:04 -0600 (45 minutes, 53 seconds ago)
>> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
>>
>>
>> Bastien writes:
>>
>>> Hi Sébastien,
>>>
>>> "Sebastien Vauban"
>>> writes:
>>>
"Sebastien Vauban" wrote:
> Bastien wrote:
>> "Sebastien Vauban" writes:
>>
>>> While a custom agenda command such as the following used to work some
>>> time
>>> ago, it does not anymore.
>>>
>>> (add-to-list 'org-agenda-custom-commands
>>>'("D" "Stuck + agenda"
>>> ((stuck "")
>>> (agenda ""
>>> ((org-agenda-span 'week) t)
>>>
>>> Now, it seems that the "stuck" block view inhibits any extra view to be
>>> displayed afterward.
>>
>> do I understand correctly that you only get the stuck view and not the
>> agenda view? If so, I cannot reproduce it.
>
> I'll try to provide you with a reproducible recipe, then.
Add the following line to this ECM:
(setq org-agenda-sticky nil)
and you'll be bitten by that bug!
>>>
>>> Mhh... still can't reproduce the bug. Anyone else?
>>
>> Unfortunately, I cannot reproduce it either. Both the stuck agenda and
>> the weekly agenda display on my end.
>>
>> Matt
>>
>>
>> --
Re: [O] sorting TODO items?
Sharon Kimble writes: > I'm using C-c S-^ to sort my checkboxes very nicely and easily, but > how do I do it to sort my TODO items please? I've been looking in the > org-mode manual but can't see how to do it. If you call org-sort (C-c ^) on a heading, it will give options for sorting all the subheadings. If you call org-sort at the top of the file (i.e., while not on a heading), it will sort all the first-level headings in the file. Matt
Re: [O] Please confirm your message
Gmane Remailer
writes:
> This message was created automatically by mail delivery software (TMDA).
>
> Your message attached below is being held because the address
> has not been verified.
>
> To release your message for delivery, please send an empty message
> to the following address, or use your mailer's "Reply" feature.
>
>
> public-emacs-orgmode-mXXj517/zsq-confirm-1393852159.12983.219...@plane.gmane.org
>
> This confirmation verifies that your message is legitimate and not
> junk-mail. You should only have to confirm your address once.
>
> If you do not respond to this confirmation request within 14 days,
> your message will not be delivered.
>
> From: Matt Lundin
> Subject: Re: [bug] Incompatible agenda commands
> To: Bastien
> Cc: "Sebastien Vauban"
> ,
> public-emacs-orgmode-mXXj517/z...@plane.gmane.org
> Date: Mon, 03 Mar 2014 07:09:04 -0600 (45 minutes, 53 seconds ago)
> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
>
>
> Bastien writes:
>
>> Hi Sébastien,
>>
>> "Sebastien Vauban"
>> writes:
>>
>>> "Sebastien Vauban" wrote:
Bastien wrote:
> "Sebastien Vauban" writes:
>
>> While a custom agenda command such as the following used to work some
>> time
>> ago, it does not anymore.
>>
>> (add-to-list 'org-agenda-custom-commands
>>'("D" "Stuck + agenda"
>> ((stuck "")
>> (agenda ""
>> ((org-agenda-span 'week) t)
>>
>> Now, it seems that the "stuck" block view inhibits any extra view to be
>> displayed afterward.
>
> do I understand correctly that you only get the stuck view and not the
> agenda view? If so, I cannot reproduce it.
I'll try to provide you with a reproducible recipe, then.
>>>
>>> Add the following line to this ECM:
>>>
>>> (setq org-agenda-sticky nil)
>>>
>>> and you'll be bitten by that bug!
>>
>> Mhh... still can't reproduce the bug. Anyone else?
>
> Unfortunately, I cannot reproduce it either. Both the stuck agenda and
> the weekly agenda display on my end.
>
> Matt
>
>
> --
Re: [O] [bug] Incompatible agenda commands
Bastien writes:
> Hi Sébastien,
>
> "Sebastien Vauban"
> writes:
>
>> "Sebastien Vauban" wrote:
>>> Bastien wrote:
"Sebastien Vauban" writes:
> While a custom agenda command such as the following used to work some time
> ago, it does not anymore.
>
> (add-to-list 'org-agenda-custom-commands
>'("D" "Stuck + agenda"
> ((stuck "")
> (agenda ""
> ((org-agenda-span 'week) t)
>
> Now, it seems that the "stuck" block view inhibits any extra view to be
> displayed afterward.
do I understand correctly that you only get the stuck view and not the
agenda view? If so, I cannot reproduce it.
>>>
>>> I'll try to provide you with a reproducible recipe, then.
>>
>> Add the following line to this ECM:
>>
>> (setq org-agenda-sticky nil)
>>
>> and you'll be bitten by that bug!
>
> Mhh... still can't reproduce the bug. Anyone else?
Unfortunately, I cannot reproduce it either. Both the stuck agenda and
the weekly agenda display on my end.
Matt
[O] [Bug] org-open-at-point no longer unescapes shell/elisp links
When I create a link with org-insert-link, it automatically escapes
spaces.
E.g.,
C-c C-l shell:ls *.org [RET]
a shell link [RET]
results in
[[shell:ls%20*.org][a shell link]]
The problem is that the recent rewrite of org-open-at-point (commit
fc9ce86cfc1ecf7e86028027a12875a26500e774) removed all invocations of
org-unescape-link.
As a result, if I use org-open-at-point on the link above, it sends the
string "ls%20*.org" to my shell, which complains:
"zsh:1: no matches found: ls%20*.org"
At the bottom of the mail you'll find the backtrack that results when I
call org-open-at-point on an elisp link:
[[elisp:(org-agenda%20"a")][agenda]]
Thanks,
Matt
Debugger entered--Lisp error: (void-function org-agenda%20)
(org-agenda%20 "a")
eval((org-agenda%20 "a"))
(if (eq (string-to-char cmd) 40) (eval (read cmd)) (call-interactively (read
cmd)))
(message "%s => %s" cmd (if (eq (string-to-char cmd) 40) (eval (read cmd))
(call-interactively (read cmd
(if (or (and (org-string-nw-p org-confirm-elisp-link-not-regexp)
(org-string-match-p org-confirm-elisp-link-not-regexp cmd)) (not
org-confirm-elisp-link-function) (funcall org-confirm-elisp-link-function
(format "Execute \"%s\" as elisp? " (org-add-props cmd nil (quote face) (quote
org-warning) (message "%s => %s" cmd (if (eq (string-to-char cmd) 40) (eval
(read cmd)) (call-interactively (read cmd (error "Abort"))
(let ((cmd path)) (if (or (and (org-string-nw-p
org-confirm-elisp-link-not-regexp) (org-string-match-p
org-confirm-elisp-link-not-regexp cmd)) (not org-confirm-elisp-link-function)
(funcall org-confirm-elisp-link-function (format "Execute \"%s\" as elisp? "
(org-add-props cmd nil (quote face) (quote org-warning) (message "%s => %s"
cmd (if (eq (string-to-char cmd) 40) (eval (read cmd)) (call-interactively
(read cmd (error "Abort")))
(cond ((equal type "file") (if (string-match "[*?{]" (file-name-nondirectory
path)) (dired path) (apply (or (let ((app ...)) (nth 1 (assoc ...
org-link-protocols))) (function org-open-file)) path arg (let ((option
(org-element-property :search-option context))) (cond ((not option) nil)
((org-string-match-p "\\`[0-9]+\\'" option) (list ...)) (t (list nil
option))) ((assoc type org-link-protocols) (funcall (nth 1 (assoc type
org-link-protocols)) path)) ((equal type "help") (let ((f-or-v (intern path)))
(cond ((fboundp f-or-v) (describe-function f-or-v)) ((boundp f-or-v)
(describe-variable f-or-v)) (t (error "Not a known function or variable")
((equal type "mailto") (let ((cmd (car org-link-mailto-program)) (args (cdr
org-link-mailto-program)) (spec (format-spec-make 97 path 115 (let (...) (if
... "" ... final-args) (apply cmd (dolist (arg args (nreverse final-args))
(if (not (stringp arg)) (push arg final-args) (push (format-spec arg spec)
final-args)) ((member type (quote ("http" "https" "ftp" "news")))
(browse-url (org-link-escape-browser (concat type ":" path ((equal type
"doi") (browse-url (org-link-escape-browser (concat org-doi-server-url path
((equal type "message") (browse-url (concat type ":" path))) ((equal type
"shell") (let ((buf (generate-new-buffer "*Org Shell Output")) (cmd path)) (if
(or (and (org-string-nw-p org-confirm-shell-link-not-regexp) (string-match
org-confirm-shell-link-not-regexp cmd)) (not org-confirm-shell-link-function)
(funcall org-confirm-shell-link-function (format "Execute \"%s\" in shell? "
(org-add-props cmd nil ... ... (progn (message "Executing %s" cmd)
(shell-command cmd buf) (when (featurep (quote midnight)) (setq
clean-buffer-list-kill-buffer-names (cons buf
clean-buffer-list-kill-buffer-names (error "Abort" ((equal type
"elisp") (let ((cmd path)) (if (or (and (org-string-nw-p
org-confirm-elisp-link-not-regexp) (org-string-match-p
org-confirm-elisp-link-not-regexp cmd)) (not org-confirm-elisp-link-function)
(funcall org-confirm-elisp-link-function (format "Execute \"%s\" as elisp? "
(org-add-props cmd nil ... ... (message "%s => %s" cmd (if (eq
(string-to-char cmd) 40) (eval (read cmd)) (call-interactively (read cmd
(error "Abort" ((equal type "id") (require (quote ord-id)) (funcall (nth 1
(assoc "id" org-link-protocols)) path)) ((member type (quote ("coderef"
"custom-id" "fuzzy" "radio"))) (unless (run-hook-with-args-until-success (quote
org-open-link-functions) path) (if (not arg) (org-mark-ring-push)
(switch-to-buffer-other-window (org-get-buffer-for-internal-link
(current-buffer (let ((cmd (\` (org-link-search ... ... ...
(condition-case nil (let ((org-link-search-inhibit-query t)) (eval cmd)) (error
(progn (widen) (eval cmd))) (t (browse-url-at-point)))
(save-current-buffer (set-buffer (or reference-buffer (current-buffer)))
(cond ((equal type "file") (if (string-match "[*?{]" (file-name-nondirectory
path)) (dired path) (apply (or (let (...) (nth 1 ...)) (function
org-open-file)) path arg (let ((option ...)) (cond (... nil) (... ...)
[O] sorting TODO items?
I'm using C-c S-^ to sort my checkboxes very nicely and easily, but how do I do it to sort my TODO items please? I've been looking in the org-mode manual but can't see how to do it. Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots Debian testing, Fluxbox 1.3.5, emacs 24.3.50.1 Registered Linux user 561944 signature.asc Description: PGP signature
Re: [O] orgstruct-mode and strange keybindings
Hi Bart, "Bart Bunting" writes: > Has anyone seen this and or can suggest how I should go about tracking > it down? I have never seen this. Can you replay the problem with a bare emacs* and by activating orgstruct-mode manually in some buffer? * emacs -Q Thanks, -- Bastien
Re: [O] [ANN] Firefox extension for org-protocol and org-capture
Hi Olivier, Olivier Schwander writes: > I would like to announce the first version of an extension to > call org-capture through org-protocol from Firefox: > - http://chadok.info/firefox-org-capture/ This is very neat, thanks a lot. One question from a casual FF user: how can I bind the org-capture functionality to a key? (I don't display the Add-on Toolbar.) Thanks, -- Bastien
Re: [O] Namespace problem org-mode / Clojure
Hi Volker and Greg, I hopefully fixed this in master. Can you pull and test? Thanks, -- Bastien
Re: [O] encrypted items, but not timestamp
Nice.
So far I have made a capture template, which enters the timestamp into
heading. Surprisingly it works pretty nicely as the timestamp does not
appear in agenda heading 'name'. Have something like this:
(require 'org-crypt)
(org-crypt-use-before-save-magic)
(setq org-crypt-tag-matcher "@CRYPT")
(setq org-crypt-key "david@bleh")
and then org-capture-templates contains following record:
("C" "Encrypted journal" entry (file+datetree (concat my-org-files
"journal.org"))
"* %? %T :@CRYPT:\n %a\n")
works as a charm.
.d.
Bastien writes:
> Jonathan Leech-Pepin writes:
>
>> I can think of one possible method (although slightly more work to do
>> so):
>
> Indeed, good idea!
>
> --
> Bastien
Re: [O] encrypted items, but not timestamp
Jonathan Leech-Pepin writes: > I can think of one possible method (although slightly more work to do > so): Indeed, good idea! -- Bastien
Re: [O] encrypted items, but not timestamp
Hello, On 3 March 2014 07:28, Bastien wrote: > Hi David, > > David Belohrad writes: > > > I have followed this: > > > > http://orgmode.org/worg/org-tutorials/encrypting-files.html > > > > to encrypt subtree of my journal. So e.g. something like this: > > > > testing subree encryption > :crypt: > > this text should be encrypted when saved on the disk using my private > > key. will see if this works > > Entered on <2014-02-20 Thu 09:05> > > > > > > it works, however it encrypts entire subtree including 'entered on > > '. This puts a little issue on this, as when in journal, > > these timestamps are used in agenda buffer to display the heading. And I > > want this heading to be displayed in my agenda, including all the tags > > it exhibits. > > > > Is there any way how to achieve this? > > Nope, sorry. > I can think of one possible method (although slightly more work to do so): (written longhand so tags won't be properly aligned, sorry) Testing subtree encryption Entered on <2014-02-20 Thu 09:05> * Encrypted entry :crypt: this text should be encrypted when saved on the disk using my private key. will see if this works This will result in the encrypted subtree being encrypted, the headline with it's timestamp being visible. Regards, Jon > For the moment the only thing > > coming into my mind is to make a timestamp part of heading, which is not > > what I really want. > > That's also the only workaround I can think of right now. > > Best, > > -- > Bastien > >
Re: [O] [bug] Incompatible agenda commands
Hi Sébastien,
"Sebastien Vauban"
writes:
> "Sebastien Vauban" wrote:
>> Bastien wrote:
>>> "Sebastien Vauban" writes:
>>>
While a custom agenda command such as the following used to work some time
ago, it does not anymore.
(add-to-list 'org-agenda-custom-commands
'("D" "Stuck + agenda"
((stuck "")
(agenda ""
((org-agenda-span 'week) t)
Now, it seems that the "stuck" block view inhibits any extra view to be
displayed afterward.
>>>
>>> do I understand correctly that you only get the stuck view and not the
>>> agenda view? If so, I cannot reproduce it.
>>
>> I'll try to provide you with a reproducible recipe, then.
>
> Add the following line to this ECM:
>
> (setq org-agenda-sticky nil)
>
> and you'll be bitten by that bug!
Mhh... still can't reproduce the bug. Anyone else?
--
Bastien
Re: [O] [PATCH] Fix clock table when there are links in headings.
Hi Alexey, Alexey Lebedeff writes: > This screenshot > https://www.dropbox.com/s/g3obxpigr8gg69f/-Org%20Agenda-%20-%20emacs_017.png > shows how it looked before the patch. It's no good unless you have > very good memory for numbers ) Thanks for the patch. `org-all-links-display-format' is a bit redundant with `org-link-prettify'. Would you mind rewriting the change using `org-link-prettify'? Thanks, -- Bastien
Re: [O] encrypted items, but not timestamp
Hi David, David Belohrad writes: > I have followed this: > > http://orgmode.org/worg/org-tutorials/encrypting-files.html > > to encrypt subtree of my journal. So e.g. something like this: > > testing subree encryption :crypt: > this text should be encrypted when saved on the disk using my private > key. will see if this works > Entered on <2014-02-20 Thu 09:05> > > > it works, however it encrypts entire subtree including 'entered on > '. This puts a little issue on this, as when in journal, > these timestamps are used in agenda buffer to display the heading. And I > want this heading to be displayed in my agenda, including all the tags > it exhibits. > > Is there any way how to achieve this? Nope, sorry. > For the moment the only thing > coming into my mind is to make a timestamp part of heading, which is not > what I really want. That's also the only workaround I can think of right now. Best, -- Bastien
Re: [O] [PATCH] When computing clock table, remove arbitrary limit on hierarchy depth.
Hi Ilya, Ilya Shlyakhter writes: > From e48a76355307d4f30df4d0e19bf9815ff8eca4a4 Mon Sep 17 00:00:00 2001 > From: Ilya Shlyakhter > Date: Mon, 24 Feb 2014 12:27:28 -0500 > Subject: [PATCH] When computing clock table, remove arbitrary limit on > hierarchy depth. > > * org-clock.el (org-clock-sum): Enlarge array of per-level clock > totals as needed on demand. Pushed in master, thanks! -- Bastien
Re: [O] Including date in TaskJuggler exports
Bastien writes: > Hi Luck, s/Luck/Luke (sorry) -- Bastien
Re: [O] Including date in TaskJuggler exports
Hi Luck, Luke Crook writes: > The following small change to ox-taskjuggler.el will export the date stored > in #+DATE: the display is messed up -- can you - repost the patch as an attachement - use git format-patch to produce it - include a ChangeLog See http://orgmode.org/worg/org-contribute.html for details. Thanks! -- Bastien
[O] Radio targets with mixed capitalisation do not work in HTML export
Experiencing a bug with radio targets and html export. IF set a radio target like <<> then the text foo in the body will be linked to #foo, but the radio target has an anchor id of Foo, so the link doesn't work. I expected the foo text to be linked to #Foo instead.
Re: [O] link interfering with brackets when abbreviated
+1 -- Another user chiming in, broadly in agreement with Gustav, details below. Gustav Wikström writes: > Hi, a "user" signing in. Although not involved in the development of this > piece of software I'm taking the opportunity to chime in anyway. > > I'd like to give Nicolas Goaziou my support in this issue. It makes it much > simpler to understand, use, develop and maintain the software if it is > congruent. A well defined syntax, and tools that respect the rules of how > to parse it, will IMO be of big importance moving forward. I think we all agree on that. And I think the *presumption* should be that incongruent features will have to go. Still, Org is about letting users organize stuff as conveniently and flexibly as possible, and if some very convenient feature relies on some ad-hoc solution, it should be possible, on a case-by-case basis, to consider keeping it. > About the issue of two links on the same line.. From my perspective (for > what it's worth); Trying to open a link when not being inside a link with > the mark should give the same behaviour as trying to open a link when on a > headline. It is not certain which link is intended to be opened, so why not > give the user the options available instead of guessing? Set the scope to > parse to the current paragraph, to make a difference from calling C-c C-o > from the headline. That, to me, is the intuitive behaviour. +1? Sounds right to me. (This would also alert a user who *accidentally* hits C-c C-o, instead of unexpectedly moving point to a target he didn't mean to visit. Not sure if it's ever happened to me, but it could.) BTW, in years of using Org I never ever realized that you *could* use C-c C-o for anything outside a link... > About the issue of links in comments (My opinion, for what it's worth): > It's a comment.. Expect it to behave as one. Worst case: copy the link and > paste it in the browser. +1. I do have links in # comments. It's convenient, but I'd be OK with the inconvenience of giving them up, if it helps make Org easier to maintain. I can always put stuff in drawers. > About the issue of links in properties: Wouldn't it be nice to allow this? > Maybe a future functionality to consider? +1? As a user, I've never been quite sure if it's good practice to put Org links -- or timestamps -- in properties. But since it does actually work (still does in 8.2.3), I do put them there. And once they are there, I find it very convenient to be able to visit the link, and manipulate the timestamps in all the ways Org enables. Yours, Christian
Re: [O] Error with org-adaptive-fill-function and mu4e
Am Sat, Feb 08, 2014 at 06:41:49PM +0100, Igor Sosa Mayor schrieb: > Hi, > > I have the following enable in my .emacs: > > (add-hook 'message-mode-hook 'turn-on-orgstruct++) > (add-hook 'mail-mode-hook 'turn-on-orgstruct++) > > When I use mu4e (which mu4e-compose-mode is based upon the message-mode) > I get the following error in *Messages* > > org-adaptive-fill-function: Symbol's value as variable is void: > orgtbl-line-start-regex Just for the historical records. At the end I managed to solve this problem by just adding the following lines: (add-hook 'message-mode-hook 'orgstruct++-mode 'append) (add-hook 'mail-mode-hook 'orgstruct++-mode 'append) (add-hook 'message-mode-hook 'orgtbl-mode 'append) (add-hook 'mail-mode-hook 'orgtbl-mode 'append) -- :: Igor Sosa Mayor :: joseleopoldo1...@gmail.com :: :: GnuPG: 0x1C1E2890 :: http://www.gnupg.org/ :: :: jabberid: rogorido ::::
[O] Context of interaction vs. literal syntactic interpretation (was: link interfering with brackets when abbreviated)
Hi Gustav, Josiah and Michael, thanks *a lot* for your feedback, it triggered an idea I want to turn into a proposal. I changed the subject of this thread to better frame the issue at stake, and explain my proposal. Emacs commands depend on their context: this is the modal approach we love. For example, M-; will behave differently whether we are in an org-mode buffer or in a html-mode buffer. The context of interaction is the relevant syntactic environment that Emacs needs to know about when a command is called. By essence, a parser is very strict about the inclusion model of syntactic elements: e.g., a tag cannot be part of a paragraph, a TODO keyword cannot be part of a timestamp, a timestamp cannot be part of a property value, a link cannot be part of a comment, etc. This is *good* to have such a strict parser and it must be as strict and consistent as possible -- we all agree on that. For most commands, the first literal syntactic interpretation is the only relevant context of interaction: e.g., it would not make sense to try updating a tag outside of a headline (i.e. outside of where a tag is a tag, from the parser's view.) For some commands, another higher context can also be relevant: e.g., when the point is on a heading and the user hit C-c C-o, Org needs to know whether we are on a link (in this case it will open the link). If not, it checks for a higher context: when we are on a heading, it will look for multiple links and prompt the user for which one to open. (A generalization of this "links-in-a-heading" behavior for something like "links-in-a-paragraph", as suggested by Gustav, is a good idea.) For handling comments, my suggestion is this to let the user decide if she wants to activate C-c C-o in comments by temporarily considering the contents of a comment as a paragraph. Something like (let ((comment-contents (org-element-property :value (org-element-context (with-temp-buffer (insert comment-contents) (org-open-at-point))) provided we preserve the relative point position. (Another route is to change the syntactic meaning of comments: they could contain paragraphs and be contained within subtrees.) Note that this suggestion does not deviate from what we already do: see the example of C-c C-o checking for a higher context when hit in headlines. So while I suggest a change for handling links in paragraphs (I do support Gustav suggestion) and in comments (see the proposal above), I don't suggest a change in the role the parser has: I only describe a frame in which what seems inconsistent is not anymore. For example, it may seem inconsistent to allow using S- to update a timestamp in a property drawer, since property drawers don't allow timestamps. But it is not inconsistent if S- is allowed to refer to a higher context (the subtree's content instead of the property drawer.) For sure, such flexibility should be the exception, not the norm, but considering it is very important in terms of user experience IMO. I hope this is clear enough and can help us moving forward. Thanks, -- Bastien
