Re: [O] Braced inline math no longer supported: ($ ... $)
On Thu, Oct 30 2014, Nick Dokos wrote: See the recent discussion here: http://thread.gmane.org/gmane.emacs.orgmode/92136 Thanks, and sorry, I actually did a cursory search, for braces and math-mode. Didn't occur to me to use the word parentheses. signature.asc Description: PGP signature
[O] Braced inline math no longer supported: ($ ... $)
Hi dear list, I just updated my org-mode to latest master and found, that the behaviour of inline math seems to have changed; with the unwelcome side-effect, that inline math in braces is not exported correctly to latex anymore: ($\varepsilon = 0$) used to be exported to latex as ($\varepsilon = 0$), but recently became somewhat like: (\$\(\varepsilon\) = 0\$) producing spurious dollar signs. is there a workaround? thank you, jonas signature.asc Description: PGP signature
Re: [O] [PATCH] hide inline-tasks in 'children visibility state
Hi, On Thu, Oct 31 2013, Nicolas Goaziou wrote: co...@online.de (Jonas Hörsch) writes: + (cond ((eq state 'contents) I suggest to use `case' here, but it's really a matter of style. fine with me. i wasn't sure about the usage convention for cl. i switched to the namespaced cl-case variant, for now. + (hide-sublevels (1- org-inlinetask-min-level + (while (and (outline-next-heading) + (org-inlinetask-at-task-p)) I think it is more efficient to directly look for inlinetasks since you can use `org-inlinetask-outline-regexp'. hmm ... i'm not so sure. as you can see in the attached patch, now i have to perform an extra search on each headline to find the boundary for the inline task search. it feels to me like this would be faster for a situation with more than one inline task per headline in the mean? (which i don't think is the likely situation). well, what do you think? From 763f4d8c8daa0c09809a677c8cd8358476336f24 Mon Sep 17 00:00:00 2001 From: Jonas Hoersch co...@online.de Date: Wed, 30 Oct 2013 15:39:33 +0100 Subject: [PATCH] org-inlinetask: Hide inline tasks in 'children visibility state * lisp/org.el (org-cycle-hide-inline-tasks): Re-hide inline tasks when switching to 'children visibility state. TINYCHANGE --- lisp/org.el | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 4f3bf4b..c94e2ee 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7074,11 +7074,23 @@ open and agenda-wise Org files. (org-flag-drawer t)) (defun org-cycle-hide-inline-tasks (state) - Re-hide inline task when switching to 'contents visibility state. - (when (and (eq state 'contents) - (boundp 'org-inlinetask-min-level) - org-inlinetask-min-level) -(hide-sublevels (1- org-inlinetask-min-level + Re-hide inline tasks when switching to 'contents or 'children +visibility state. + (cl-case state +(contents + (when (org-bound-and-true-p org-inlinetask-min-level) + (hide-sublevels (1- org-inlinetask-min-level +(children + (when (featurep 'org-inlinetask) + (let ((end (save-excursion + (if (re-search-forward + (concat [\r\n]\\( org-outline-regexp \\)) nil t) + (match-beginning 1) + (point-max) + (save-excursion + (while (re-search-forward (org-inlinetask-outline-regexp) end t) + (org-inlinetask-toggle-visibility) + (org-inlinetask-goto-end (defun org-flag-drawer (flag) When FLAG is non-nil, hide the drawer we are within. -- 1.8.4 p.s.: for some weird reason, i was convinced i submitted this mail a few days ago ... but my mail program says otherwise. pgp7i2XnocdUF.pgp Description: PGP signature
[O] [PATCH] hide inline-tasks in 'children visibility state
hej, one more patch, which takes care of re-hiding inline-tasks properly. finally it is possible to work with longer inline tasks without them getting always in the way. just bump me, if anything is not to your liking cheers, jonas From 447d528263728ea56f390ae8dfdfa99880d6ccb4 Mon Sep 17 00:00:00 2001 From: Jonas Hoersch co...@online.de Date: Wed, 30 Oct 2013 15:39:33 +0100 Subject: [PATCH] org-inlinetask: hide inline tasks in 'children visibility state * lisp/org.el (org-cycle-hide-inline-tasks): re-hide inline tasks when switching to 'children visibility state. TINYCHANGE --- lisp/org.el | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 4f3bf4b..b93f3f4 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7074,11 +7074,19 @@ open and agenda-wise Org files. (org-flag-drawer t)) (defun org-cycle-hide-inline-tasks (state) - Re-hide inline task when switching to 'contents visibility state. - (when (and (eq state 'contents) - (boundp 'org-inlinetask-min-level) - org-inlinetask-min-level) -(hide-sublevels (1- org-inlinetask-min-level + Re-hide inline tasks when switching to 'contents or 'children +visibility state. + (cond ((eq state 'contents) + (when (and (boundp 'org-inlinetask-min-level) + org-inlinetask-min-level) + (hide-sublevels (1- org-inlinetask-min-level + ((eq state 'children) + (when (featurep 'org-inlinetask) + (save-excursion + (while (and (outline-next-heading) + (org-inlinetask-at-task-p)) + (org-inlinetask-toggle-visibility) + (org-inlinetask-goto-end))) (defun org-flag-drawer (flag) When FLAG is non-nil, hide the drawer we are within. -- 1.8.4 pgpGN2vVjEvqP.pgp Description: PGP signature
[O] [PATCH] Re: [BUG] org-cycle on hidden inline task makes also other inline tasks visible
hi, ok, this has been bothering me long enough. the attached patch fixes the issue [1] for me. cheers, jonas Footnotes: [1] http://thread.gmane.org/gmane.emacs.orgmode/76034 From 3073cb181f607a0cc65031fe68e86cf73347e152 Mon Sep 17 00:00:00 2001 From: Jonas Hoersch co...@online.de Date: Tue, 29 Oct 2013 17:07:49 +0100 Subject: [PATCH] org-inlinetask: [FIX] correct inlinetask cycling org-show-entry can't be used to expand a folded inlinetask, as it relies on org-outline-regexp to find the end of the entry, which has been altered to exclude inline-tasks by org-cycle. instead show the inline task directly using the bounds already computed by org-inlinetask-toggle-visibility. --- lisp/org-inlinetask.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el index 112d3df..ca7572b 100644 --- a/lisp/org-inlinetask.el +++ b/lisp/org-inlinetask.el @@ -315,7 +315,8 @@ If the task has an end part, also demote it. ((= end start)) ;; Inlinetask was folded: expand it. ((get-char-property (1+ start) 'invisible) - (org-show-entry)) + (outline-flag-region start end nil) + (org-cycle-hide-drawers 'children)) (t (outline-flag-region start end t) (defun org-inlinetask-remove-END-maybe () -- 1.8.4 pgp8DcJLlm2SG.pgp Description: PGP signature
Re: [O] [PATCH] Re: [BUG] org-cycle on hidden inline task makes also other inline tasks visible
Hej, On Tue, Oct 29 2013, Nicolas Goaziou wrote: You need to detail which function is modified and how. Also, if you haven't signed FSF papers, you need to add TINYCHANGE at the end of the message. thanks for bearing with me. is this alright? From 1c6e67b06d0eb22c6d79387c8c6d07c23500f91d Mon Sep 17 00:00:00 2001 From: Jonas Hoersch co...@online.de Date: Tue, 29 Oct 2013 17:07:49 +0100 Subject: [PATCH] org-inlinetask: fix inlinetask unfolding * lisp/org-inlinetask.el (org-inlinetask-toggle-visibility): Don't use `org-show-entry` as it cannot unfold an inlinetask properly. TINYCHANGE --- lisp/org-inlinetask.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el index 112d3df..ca7572b 100644 --- a/lisp/org-inlinetask.el +++ b/lisp/org-inlinetask.el @@ -315,7 +315,8 @@ If the task has an end part, also demote it. ((= end start)) ;; Inlinetask was folded: expand it. ((get-char-property (1+ start) 'invisible) - (org-show-entry)) + (outline-flag-region start end nil) + (org-cycle-hide-drawers 'children)) (t (outline-flag-region start end t) (defun org-inlinetask-remove-END-maybe () -- 1.8.4 pgpAeFoXbYVgx.pgp Description: PGP signature
[O] [BUG] org-cycle on hidden inline task makes also other inline tasks visible
hello everyone, just found a strange behaviour of inline tasks: calling org-cycle in a situation like * Heading1 *** inline1... *** inline2... *** inline3... * Heading2 *** inline4... with point on the inline2 heading results in * Heading1 *** inline1... *** inline2 *** END *** inline3 *** END * Heading2 *** inline4... tested with emacs -Q on org-mode's master branch of sep 3rd. cheers, jonas * Heading1 *** inline1 *** END *** inline2 *** END *** inline3 *** END * Heading2 *** inline4 *** END pgpj0DU0Ql8L4.pgp Description: PGP signature
Re: [O] [SYNC] How do you sync your org-mode files between n devices (n 2)
On Thu, Sep 05 2013, Karl Voit wrote: * Alan Schmitt alan.schm...@polytechnique.org wrote: I can't promise anything, but I can try to write something. What external merging tool should I use? I haven't used it yet but I read that Emacs offers some kind of a 3-way-merger ... and then there is an early git-merge-tool[1] or rather the org-merge-driver for git. i've been using it for half a year now for my org files in git, although i seldom have conflicts, as we're just a small group. maybe somebody on the list has more info on its status? cheers, jonas Footnotes: [1] http://orgmode.org/worg/org-contrib/gsoc2012/student-projects/git-merge-tool/index.html pgp8Skx0v2CKJ.pgp Description: PGP signature
[O] Switch org-agenda-get-* defuns to operate on date ranges
hello everyone,
i've just started to use calfw to get a nice calendar-like display of my
agenda. unfortunately i was slighly dismayed at the build-up speed
easily exceeding a few seconds on my not so packed schedule. profiling
into the code i found that the problem mainly is:
there exists only the possibility to retrieve agenda data for one day
day, org-agenda.el's org-agenda-get-day-entries, rather than for a range
of days. this makes it necessary to loop over --get-day-entries to collect
all entries to show in the monthly calendar.
--get-day-entries for its part has to parse (basically regex-search
through) the respective org agenda file completely on each invocation;
effectively done by org-agenda-get-{todos,blocks,sexps,...}.
i imagine it is quite feasible to implement
(defun org-agenda-get-entries (file beg end rest args) ...)
to sift through FILE but once and return an alist like
((date . (entry1 entry2 ..)) ..)
containing all entries between dates BEG and END, inclusive.
neglecting the extra overhead for sorting entries into the alist, this
promises to speed up typical weekly agenda collection by a factor of 7
and calfw even by a factor of approx. 30, shouldn't it?
before i start a local branch to try myself on this refactoring work,
i'd welcome a few comments, why i should be likely to fail or succeed!
cheers,
jonas
[O] org-element.el doesn't support interpreting repeating range timestamps
hej, i just noticed, that although org-element properly parses the repeating information of an active-range :type timestamp, it is not able to interpret it again (unless the :raw-value is still present, of course). minimal working example below: * ❢ Tagesschau 2013-01-15 Tue 20:00 +1d--2013-01-15 Tue 20:15 +1d * Parsing #+name: timestamp #+begin_src emacs-lisp (org-element-put-property (org-element-put-property (org-element-map (org-element-parse-buffer) 'timestamp 'identity nil t) :parent nil) ; so we don't clutter the output uselessly :raw-value nil) ; with raw-value it works, trivially #+end_src #+RESULTS: timestamp | timestamp | (:type active-range :raw-value nil :year-start 2013 :month-start 1 :day-start 15 :hour-start 20 :minute-start 0 :year-end 2013 :month-end 1 :day-end 15 :hour-end 20 :minute-end 15 :begin 17 :end 71 :post-blank 0 :repeater-type cumulate :repeater-value 1 :repeater-unit day :parent nil) | * Interpreting #+begin_src emacs-lisp :var elem=timestamp (org-element-interpret-data elem) #+end_src #+RESULTS: : 2013-01-15 Tue 20:00--2013-01-15 Tue 20:15 cheers, jonas
Re: [O] org-sync doesn't work with recent org-element.el
hej aurélien, list, as hoped for i got it to work with the current org-element.el with only few changes to org-sync. i pushed my changes to my github at [1]. please feel free to comment and/or merge. the commit bdcbae os-github: use authentication data also for os-github-fetch-json-page is optional and i wouldn't mind moving that to a separate feature branch if you prefer. cheers, jonas Footnotes: [1] https://github.com/coroa/org-sync.git https://github.com/coroa/org-sync
Re: [O] org-sync doesn't work with recent org-element.el
hi all, hi aurélien, then, i suppose the answer to my main question, whether someone has started updating org-sync, is a no and i'll thus try. i'm not too proficient in elisp yet, so any hints of a clean transition are appreciated. i plan to alter any parts, which read/write cons lists (i mean those ( key . value ) pairs which used to go under the :properties key) to node-property elements directly. if you think a bit of that chore could be abstracted away in a function, let me know. cheers, jonas
[O] retrieve value of a property from a property-drawer (was: org-sync doesn't work with recent org-element.el)
Hej, org-element-wizards, i found that the following use of org-element-map retrieves reliably the value of a key from a property drawer. is such a use, especially the temporary overriding of the headline's type to org-data, to be considered allowed usage or rather a hack and thus to be avoided? * First headline :PROPERTIES: :url: http://orgmode.org/ :END: #+begin_src emacs-lisp (defun retrieve-property-value (headlineitem key) (org-element-map (cons 'org-data (cdr headlineitem)) 'node-property (lambda (x) (and (string= (org-element-property :key x) key) (org-element-property :value x))) nil t 'headline)) (let* ((doc (org-element-parse-buffer)) (firstheadline (org-element-map doc 'headline 'identity nil t))) (retrieve-property-value firstheadline url)) #+end_src #+RESULTS: : http://orgmode.org/ thanks for any comments, jonas
[O] org-sync doesn't work with recent org-element.el
hej list, i've just now been playing around with org-sync [1] and want to start using it for at least a github and eventually a redmine project. the first thing which is making me stumble is that while org-sync works fine with org-element from [2] a current (as in from head of master) one fails to work at all. as far as i could track the problem, i understand that the handling of property drawers changed significantly: while in the former version a property drawer was just represented by a simple plist, the latter now introduced a new org-element-type node-property, so it also provides access to information about f.ex. spacing of individual items in the property drawer. and org-sync hasn't been adapted to this yet. am i correct? did someone start the work on updating org-sync yet? thanks, jonas Footnotes: [1] http://orgmode.org/worg/org-contrib/gsoc2012/student-projects/org-sync/ [2] http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=contrib/lisp/org-element.el;hb=5057ae0fc2c0d551a83d3c3e9bd621b751db9f09
[O] org-edit-special on inline latex
hi list,
i recently switched from using the verbose
#+begin_latex
\begin{eqnarray}
8 = 7 + 1
\end{eqnarray}
#+end_latex
to just the inline version
\begin{eqnarray}
8 = 7 + 1
\end{eqnarray}
which is: shorter to write thus also clearer to read and as a welcome
gadget even exports to html as well.
but i see also two drawbacks:
1. syntax highlighting is lost
2. org-edit-special (C-') doesn't switch to auctex anymore[fn:1]
it would be fantastic if it was possible for org-edit-special to work on
an enclosing \begin -- \end region the same way it did on a latex block,
i.e. show a new window with the snippet in latex mode.
in there one would have all the pleasures of syntax highlighting and
auctex shortcuts and whatelse.
is this already possible?
thanks,
jonas
Footnotes:
[fn:1] while org-cdlatex-mode is great, i sometimes prefer auctex
[O] babel: is it possible to cache #+call executed blocks
Hello everyone,
i'm looking for a possibilty to call lengthy codeblocks a few times with
different parameters, but would like the results to be cached.
hopefully wiw becomes clear enough with a minimal example.
the code block speak, if directly evaluated, produces the correct result
hallo on the first run. all subsequent runs just return immediately,
until the code block is changed.
if one evaluates the #+call line, as expected the right result is
returned and the hash necessary for caching is added to #+RESULTS.
but subsequent evaluations always seem to evaluate the code block again,
i.e. one has to wait the 5 seconds.
is there a way to avoid this?
thanks,
jonas
#+begin_src org
* Test
#+name: speak
#+begin_src sh :var say=hallo :results output :cache yes
echo $say
sleep 5
#+end_src
#+RESULTS[4370bde991d63488bcb6d297718919fcf2b4fa1f]: speak
: hallo
#+call: speak('welt') :cache yes
#+RESULTS[c393aea840734e972880a4a38512765d345e7125]: speak('welt'):cache yes
: welt
#+end_src
Re: [O] table of contents and numbers
On Thu, Apr 12 2012, Julian Burgos wrote:
Thanks for the answer Nick. So to get a TOC without numbers I would
need to edit the TEX file directly, right?
Hi there,
another option might be to remove the num:nil org option and instead
tell latex not to number any sections by setting secnumdepth to 0.
so for instance
---start org file ---
#+TITLE: Test
#+OPTIONS: toc:t
#+LATEX_HEADER: \setcounter{secnumdepth}{0}
* Part 1
Some text
* Part 2
Some more text
---end org file ---
should do the trick.
the only drawback is that one still needs the num:nil option for the
other export formats.
perhaps this could become another way to implement num:nil for the latex
export in general. though i don't think it would work reliably for just a
subtree then.
Greets,
Jonas
On mið 11.apr 2012 19:00, John Hendy wrote:
On Wed, Apr 11, 2012 at 12:12 PM, Nick Dokosnicholas.do...@hp.com wrote:
Julian Burgosjul...@hafro.is wrote:
Dear list,
My apologies for another very basic question. I'm wondering why I do
not get a table of contents when exporting the following file as pdf
---start org file ---
#+TITLE: Test
#+OPTIONS: toc:t num:nil
* Part 1
Some text
* Part 2
Some more text
---end org file ---
I do get the TOC when exporting as hmtl, though.
I believe it's because of a rather technical latex limitation: latex
writes TOC entries into a .toc file, which is then read back in when the
\tableofcontents macro is expanded. When you specify num:nil asking for
unnumbered sections, the latex exporter produces \section* markers,
instead of the standard \section markers. But when latex processes
those, it does not add anything to the .toc file. If org added a
\tableofcontents, you would get just the title and an empty TOC. In
order to prevent that, the latex exporter requires that both toc and num
be non-nil - see l.1487 ff in lisp/org-latex.el:
,
| ...
| ;; table of contents
| (when (and org-export-with-toc
| (plist-get opt-plist :section-numbers))
|(funcall org-export-latex-format-toc-function
| ...))
`
One can work around this by manually adding sections under each headline.
-
#+options: num:nil toc:t
#+text: \tableofcontents
* Introduction
\addcontentsline{toc}{section}{Introduction}
-
Tedious for long documents, but does work.
John
The HTML exporter does this by hand, so to speak, so it is not as
constrained and can do the right thing.
Nick
Re: [O] table of contents and numbers
On Thu, Apr 12 2012, Julian Burgos wrote:
Thanks for the answer Nick. So to get a TOC without numbers I would
need to edit the TEX file directly, right?
Hi there,
another option might be to remove the num:nil org option and instead
tell latex not to number any sections by setting secnumdepth to 0.
so for instance
---start org file ---
#+TITLE: Test
#+OPTIONS: toc:t
#+LATEX_HEADER: \setcounter{secnumdepth}{0}
* Part 1
Some text
* Part 2
Some more text
---end org file ---
should do the trick.
the only drawback is that one still needs the num:nil option for the
other export formats.
perhaps this could become another way to implement num:nil for the latex
export in general. though i don't think it would work reliably for just a
subtree then.
Greets,
Jonas
P.S.: sorry to those fellow newsgroup-reading people, who now got this
answer twice, but i just realized, this is originally a mailing list.
On mið 11.apr 2012 19:00, John Hendy wrote:
On Wed, Apr 11, 2012 at 12:12 PM, Nick Dokosnicholas.do...@hp.com wrote:
Julian Burgosjul...@hafro.is wrote:
Dear list,
My apologies for another very basic question. I'm wondering why I do
not get a table of contents when exporting the following file as pdf
---start org file ---
#+TITLE: Test
#+OPTIONS: toc:t num:nil
* Part 1
Some text
* Part 2
Some more text
---end org file ---
I do get the TOC when exporting as hmtl, though.
I believe it's because of a rather technical latex limitation: latex
writes TOC entries into a .toc file, which is then read back in when the
\tableofcontents macro is expanded. When you specify num:nil asking for
unnumbered sections, the latex exporter produces \section* markers,
instead of the standard \section markers. But when latex processes
those, it does not add anything to the .toc file. If org added a
\tableofcontents, you would get just the title and an empty TOC. In
order to prevent that, the latex exporter requires that both toc and num
be non-nil - see l.1487 ff in lisp/org-latex.el:
,
| ...
| ;; table of contents
| (when (and org-export-with-toc
| (plist-get opt-plist :section-numbers))
|(funcall org-export-latex-format-toc-function
| ...))
`
One can work around this by manually adding sections under each headline.
-
#+options: num:nil toc:t
#+text: \tableofcontents
* Introduction
\addcontentsline{toc}{section}{Introduction}
-
Tedious for long documents, but does work.
John
The HTML exporter does this by hand, so to speak, so it is not as
constrained and can do the right thing.
Nick
Re: [O] Too clumsy to promote/demote a region by multiple levels
On Sun, Mar 18 2012, James Harkins wrote: That is, if I use C-space and move the point to select a number of headings, and I want to demote them by three levels, currently after hitting M-right, the region goes away -- so I actually have to do C-space (move the point) M-right C-space (move the point) M-right C-space (move the point) M-right as a workaround, you can shorten the procedure a bit by typing C-space (move the point) M-right C-x C-x M-right C-x C-x M-right still a bit suboptimal i agree. cheers, jonas
Re: [O] AUCTex within org-babel
hi riccardo, On Thu, Feb 09 2012, Riccardo Romoli wrote: I do not understand why the code works only if I use: #+begin_src latex :exports results :results latex #+end_src for this to work you have to add (latex . t) to org-babel-load-languages. but it's actually thought to be used to automatically include some generated latex code as f.ex. an org table as in [1]. org-babel then creates a #+begin_latex...#+end_latex - block with the whole latex inside, which is then exported the same way as if you had directly used the latex-block. cheers, jonas [1] http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-13-2
Re: [O] AUCTex within org-babel
hi riccardo,
On Thu, Feb 09 2012, Riccardo Romoli wrote:
if you enter in the AUCTeX buffer (C-c') and than you use the AUCTeX C-c
C-e, you can choose the environment you need in the emacs minibuffer such
as in LaTeX.
yes, indeed. and my claim was, that the completion facility of AUCTeX
then only shows the environment
\begin{document}..\end{document} and not f.ex. figure.
but when i tried to verify that claim right now, it curiously seems not
to be true any longer.
so sorry for the noise, my problem (if it ever was one) is solved.
cheers,
jonas
Re: [O] AUCTex within org-babel
On Thu, Feb 09 2012, Riccardo Romoli wrote:
I have a further question: how can I export a code like this:
#+begin_src latex
\begin{figure}
\centering
\includegraphics[width=1\textwidth]{foo.jpg}
\caption{Figure example}
\label{fig:foo}
\end{figure}
#+end_src
to LaTeX to obtain a working figure code??
it seems to do what you want, when you instead use
#+begin_latex
...
#+end_latex
C-' also still does the same. only the native fontification in the org
buffer doesn't work irrespective of the org-src-fontify-natively
setting. perhaps there is another variable for that.
mind that you could also use org constructs, for instance
#+CAPTION: Figure example
#+LABEL: fig:foo
[[foo.jpg]]
exports to something rather similar.
cheers,
jonas
Re: [O] AUCTex within org-babel
Hi list, On Wed, Feb 08 2012, Riccardo Romoli wrote: thanks a lot for your answer!! I completely ignore that C-c' lunch the small buffer for all the code within the src blocks. I belive it was used only for ESS the only remaining problem is that the AUCTeX mode tries to be smart about what environments it allows to insert. f.ex. inserting #+begin_src latex #+end_src then C-', brings one to a source buffer with AUCTeX-mode enabled. But a C-c C-e to insert an environment doesn't want to complete on itemize or figure, but instead only allows to choose document (Which would be perfectly sane under the assumption that the buffer contains the whole tex-document). Does anybody know how to deactivate this feature of AUCTeX? Perhaps setting TeX-master-file to something special? Thanks, Jonas
Re: [O] Dynamically generating todo entries
[fn:1] Footnotes: [fn:1] Mail
