[O] #+TOC: figures in ox-html?
Hi, The `#+TOC: tables` construct does export nicely to HTML. Just wondering if `#+TOC: figures` and maybe `#+TOC: equations` is on the roadmap, or could anyone provide a hook to make this work in the meantime? Thanks, --Mel. -- Melanie BACOU International Food Policy Research Institute Snr. Program Manager, HarvestChoice E-mail m.ba...@cgiar.org Visit www.harvestchoice.org
[O] [ANN] org-link-edit.el --- Slurp and barf with Org links
Hello,
When working with links in Org documents, I noticed that I often kill
surrounding text to bring it into the description, or vice versa. At
some point, this made me think that it'd be nice to be able to add and
remove description words like Paredit lets you do with S-expressions.
I've put these Paredit-inspired slurping and barfing commands for Org
link descriptions in org-link-edit.el [1], in case others find them
useful. Below is an example for each command.
- org-link-edit-forward-slurp
The [[http://orgmode.org/][Org mode]] site
|
v
The [[http://orgmode.org/][Org mode site]]
- org-link-edit-backward-slurp
The [[http://orgmode.org/][Org mode]] site
|
v
[[http://orgmode.org/][The Org mode]] site
- org-link-edit-forward-barf
The [[http://orgmode.org/][Org mode]] site
|
v
The [[http://orgmode.org/][Org]] mode site
- org-link-edit-backward-barf
The [[http://orgmode.org/][Org mode]] site
|
v
The Org [[http://orgmode.org/][mode]] site
As I mention in the package commentary, I think this works well with
Oleh Krehel's excellent Hydra [2] because it allows you to repeat any of
these commands with a single key after the initial key sequence to
invoke the popup.
(define-key org-mode-map YOUR-KEY
(defhydra hydra-org-link-edit ()
"Org Link Edit"
("j" org-link-edit-forward-slurp "forward slurp")
("k" org-link-edit-forward-barf "forward barf")
("u" org-link-edit-backward-slurp "backward slurp")
("i" org-link-edit-backward-barf "backward barf")
("q" nil "cancel")))
[1]: https://github.com/kyleam/org-link-edit/blob/master/org-link-edit.el
[2]: https://github.com/abo-abo/hydra
--
Kyle
[O] ox-html: stand-alone export option?
Hi, I'm using ox-html to work on shared documents with my collaborators. We're working off a Dropbox account and converting our org files to HTML periodically. Problem with all cloud storages is they don't work with relative links inside HTML (links to external images, CSS, and JS resources). We would really benefit from having a "stand-alone" HTML exporter feature that automatically embeds all external references into one single HTML file, so they can be shared with Dropbox, Google Drive, OneDrive and the likes. Has this been discussed previously? Would there be any other work around? Thanks all, --Mel. -- Melanie BACOU International Food Policy Research Institute Snr. Program Manager, HarvestChoice E-mail m.ba...@cgiar.org Visit www.harvestchoice.org
Re: [O] Citation syntax: a revised proposal
Hi Tom,
t...@tsdye.com (Thomas S. Dye) writes:
> Thanks for your thoughtful responses and your work on the citation
> syntax. My "author" concerns have been addressed in this thread and I
> look forward to development now. I'm +1 and optimistic about the switch
> from home-brew links to citations in my Org mode work.
Great! I'm really glad to hear that.
Actually, your post has convinced me that it may be worth allowing some
explicit name for a type in the [cite: ...] part of the syntax, although
I am still leery about what this would mean for non-LaTeX backends. I
did not appreciate before that switching from one type to another is
something you probably want to be able to do really easily, like with
query-replace, even if you are making use of the other parts of the
syntax to express distinctions like in-text vs. parenthetical citations.
So, two questions for the group:
1) Is it worth allowing a name for a user-defined type in the [cite: ...]
part, or is it OK to confine user-defined types to the second part
(like: [cite: ...] %%(:type foo) or [cite: ...]{:type foo})?
2) If a user-defined type can go in the [cite: ...] part, where should
it go? Nicolas has suggested:
[cite:subtype ...]
or
[cite:subtype: ...]
I would personally (aesthetically, don't ask me why) prefer:
[cite/subtype: ...]
or
[cite|subtype: ...]
But maybe there are other options I haven't thought of.
Best,
Richard
Re: [O] Citation syntax: a revised proposal
Hi Rasmus, Rasmus writes: > Richard Lawrence writes: > >> Basically, I think you could ignore the distinctions that the [cite: >> ...] syntax is capable of expressing, and just write all your citations >> like: >> >> [cite: See @Doe99 for more on this point.] %%(:type footnoted) >> >> You would then use an export filter to transform citations with this >> :type into the appropriate command, something along the lines of: > > This seems backward and wrong /to me/. Why not global options? I > actually think we "agreed" on this earlier. > > #+cite: text-cite > #+(cite): parenthesis-cite > > Or > > #+cite: numeric > #+(cite): footnote-cite > > This is why I asked Tom earlier if he normally uses more than two citation > TYPES. Presumably citeauthor and citeyear works irrespective of the main > citation type. So I still think that having two TYPES handy will meet > most requirements. That may be so. But surely it is at least conceivable that more than three types will be used in a document (say, mostly textcite and parencite, with a few footfullcites sprinkled in); and Tom's concern was that he doesn't want to have to worry about which parts of the syntax of a citation he has to change to effect a change from one type to another. So, if this approach doesn't seem right to you, don't do it that way. The point is just that Tom's style of working is possible to achieve in this syntax. Hopefully, yours is too, though it may be quite different. Best, Richard
Re: [O] How to set a default language for source blocks?
Rasmus: Thanks
Jorge: Yes probably
On Tue, Feb 17, 2015 at 2:09 PM, Jorge A. Alfaro-Murillo
wrote:
> Hi, Grant.
>
> Grant Rettke writes:
>
>> It would be simpler to say "this whole document will be R source blocks,
>> unless I specify other wise". I looked at [the spec]. I wanted to obtain
>> this behavior. I couldn't figure out how. Is it possible?
>
>
> The problem is that if there is nothing after #+BEGIN_SRC, then
> org-babel-get-src-block-info returns nil. Probably you would have to modify
> org-babel-get-src-block-info so that it returns a default when there is
> nothing after #+BEGIN_SRC. But isn't it easier to set
> org-structure-template-alist as a local buffer variable, say in the first
> line of your file something like:
>
> #+BEGIN_EXAMPLE
> # -*- org-structure-template-alist: '(("s" "#+BEGIN_SRC
> python\n?\n#+END_SRC")) -*-
> #+END_EXAMPLE
>
> Then example.
>
> Best,
>
> --
> Jorge.
>
>
--
Grant Rettke
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson
Re: [O] Citation syntax: a revised proposal
Hi Richard,
Thanks for your thoughtful responses and your work on the citation
syntax. My "author" concerns have been addressed in this thread and I
look forward to development now. I'm +1 and optimistic about the switch
from home-brew links to citations in my Org mode work.
Thanks for your patience as I digested your proposals. Let me know if
you think I can help in some way.
All the best,
Tom
Richard Lawrence writes:
> Hi Tom,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> I want a syntax that recognizes arbitrary citation commands because I
>> write in Org mode for publication. You want a syntax that recognizes a
>> few commands that it might be possible to support in Org mode backends,
>> some of which are tied loosely, if at all, to publication. Yours might
>> be a noble goal that many Org mode users will find useful (I hope it
>> is!), but I don't think it is (or will be) a syntax useful in my work,
>> for the following reasons:
>>
>> 1) It is easier for me to have the citation command in one place. The
>> decision to represent selected aspects of the citation command in the
>> syntax and other parts in extensions means that I'd have to learn the
>> syntax and then remember which aspects were chosen for representation
>> and which I'd need to develop through extensions of my own. This is a
>> lot more work than I do now to get exactly what I want through links.
>> I'm keen to simplify the authoring process, not make it more complex.
>>
>> 2) Treating footnote citations differently from author-date citations is
>> a non-starter for me. When Science turns me away and the editor
>> suggests that my rant is well suited for another journal, one that
>> happens to use author-date citations, I'll just search all my citation
>> links and replace footcite with parencite before exporting the rant to
>> the suggested journal. IIUC, with the official Org mode syntax, I'd be
>> faced with the tedious process of cutting and pasting footnote text back
>> into the document body.
>
> I do think it is important to support these kinds of uses, and I think
> it would be a shame if the official Org syntax did not make them
> relatively straightforward. You are surely not the only person using
> Org to prepare documents for publication, and I'm sure this kind of
> per-journal `refactoring' is common and important to make easy.
>
> (You're right that our goals differ to some extent. I am still in grad
> school. Preparing documents for academic publication is a privilege I
> hope to have one day; but I am not presently one of the people using Org
> for this on a regular basis, though I hope I can in the future. One
> reason I am concerned to have a citation syntax that can be exported by
> other backends is this: I am anxious that, unless I can also export my
> dissertation to HTML, the final document may never be read by anyone
> except backup programs on the library servers. Another, more serious
> reason is that I work in a field where some journals do not accept LaTeX
> submissions, or disprefer them; so having some citation support in ODT
> export is important.)
>
> I *think* it should be possible to do the kinds of things you've
> described here using the syntax I proposed, but I may not understand
> everything you'd like to do. If not, let's figure out what the other
> things are, and how to accommodate them.
>
> Basically, I think you could ignore the distinctions that the [cite:
> ...] syntax is capable of expressing, and just write all your citations
> like:
>
> [cite: See @Doe99 for more on this point.] %%(:type footnoted)
>
> or, in the syntax Nicolas proposed, something like:
>
> [cite: See @Doe99 for more on this point.]{:type footnoted}
>
> You would then use an export filter to transform citations with this
> :type into the appropriate command, something along the lines of:
>
> (defun footnoted-citation (citation backend info)
> (let ((type (get-citation-type citation)
> (pre (get-citation-prefix citation))
> (post (get-citation-suffix citation))
> (key (get-citation-key citation)))
> (when (and (org-export-derived-backend-p backend 'latex)
> (eq type 'footnoted))
>(format "\footcite[%s][%s]{%s}" pre post key
>
> (It would be more complicated than this in the general case, since a
> citation can contain more than one reference as well as common prefix
> and suffix text, but hopefully that illustrates the idea.)
>
> Then, when Science sends you elsewhere, you can just query-replace
> ":type footnoted" with ":type author-date", or whatever the appropriate
> type for the new journal is, which will have a different export filter
> (or a different clause in the same filter).
>
> That is more work than letting Org export citations for you, because it
> means manually processing every :type you use. But maybe it is about
> the same amount of work as what you are doing now with custom links.
>
> This way, although you wouldn't be r
[O] bug#19887: 24.4; Cannot kill buffer; Wrong type argument: overlayp, nil
Hello, Alexis writes: > On 2015-02-18T06:25:57+1100, Glenn Morris said: > > GM> Damian Nadales wrote: > >>> - Run emacs -Q >>> - Create an org-mode file (i.e. ``myorgfile.org``) >>> - Insert the following text: >>> o #+BEGIN_SRC C++ >>> #+END_SRC >>> - Edit the source block by placing the cursor inside the SRC block. >>> - Start C++ mode (c++-mode) >>> - Try to kill the buffer. > > GM> Please do > > GM> M-x toggle-debug-on-error > > GM> repeat the problem, and post the resulting backtrace. (I can't > GM> reproduce it.) > > Running a manually compiled Emacs 24.4.1 on Debian Wheezy(+updates) > x86_64, and following the above steps, i can't reproduce this either. > > From the above description, i assume by the "Start C++ mode" line, > you're not moving the cursor inside the source block and then doing: > >C-c ' > > (i.e. `org-edit-special`) in order to open a c++-mode buffer for > editing the block contents? This should be fixed. Thank you. However, it is not a good idea to change major mode in an edit buffer, as it removes local variables used to synchronize with the source block. Proper major mode, when non-trivial, should be defined with ``org-src-lang-modes' instead. Regards, -- Nicolas Goaziou
Re: [O] [patch] better(?) indention for cdlatex-environment
Nicolas Goaziou writes:
> Rasmus writes:
>
>> Perhaps there are clever ways to figure it out. I say there are too many
>> dynamics and "fixes" in the code to get cdlatex-environment to work
>> already. Just consider this example where | is cursor
>>
>>- foo | bar
>>
>> Midway through, when ENV is reinserted, but before indentation the
>> end-marker will be *after* bar which is a line after \end{ENV}...
>
> This is exactly what we want: indent (non empty) lines starting in
> [BEG ; END[. Or am I missing something?
Maybe I'm missing something.
Bar is already indented through ord-return-indent. So it would get double
indented. I could use "normal" return or "\n", but then I think I would
not get a good metric for indentation.
>> Anyway it reminded me that I missed "re-implementing" one feature of
>> cdlatex, namely moving the cursor to the right place. I refind this
>> place do it by inserting a funny string and replacing it. A poor man's
>> marker, I guess...
>
> Another option: when ENV is inserted the first time, store (e.g., in N)
> how many (forward-line -1) are needed to go back to BEG. At the end of
> the process, move to BEG then (forward-line n). I assume point is always
> left on an empty lines. If it is not the case, you also need to store
> current column, relatively to end of line.
Cdlatex inserts a "random" amount of newlines which I remove with trim
(depending mostly on bolp). Then I insert 0 or 1 newlines based on
context. It can probably be done, but I don't know if it's as robust.
> BTW, You didn't update the patch.
Ups. The old new patch is attached.
--
Together we'll stand, divided we'll fall
>From 0a639d79f67a2aceadf6edbb334a4e6d9d16c88e Mon Sep 17 00:00:00 2001
From: rasmus
Date: Tue, 10 Feb 2015 12:02:59 +0100
Subject: [PATCH] org.el: Change indention for cdlatex environments
* org.el (org-cdlatex-environment-indent): Use different indent
algorithm based on content above the new latex-environment.
---
lisp/org.el | 56 ++--
1 file changed, 50 insertions(+), 6 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 4f047b2..8ea8b28 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18645,13 +18645,57 @@ Revert to the normal definition outside of these fragments."
(call-interactively (key-binding (vector last-input-event))
(defun org-cdlatex-environment-indent (&optional environment item)
- "Execute `cdlatex-environment' and indent the inserted environment."
- (interactive)
- (cdlatex-environment environment item)
- (let ((element (org-element-at-point)))
-(org-indent-region (org-element-property :begin element)
- (org-element-property :end element
+ "Execute `cdlatex-environment' and indent the inserted environment.
+
+ENVIRONMENT and ITEM are passed to `cdlatex-environment'.
+The inserted environment is indented to current indentation
+unless point is at the beginning of the line, in which the
+environment remains unintended."
+ (interactive)
+ ;; cdlatex-environment always return nil. Therefore, capture output
+ ;; first and determine if an environment was selected.
+ (let* ((beg (point-marker))
+ (end (copy-marker (point) t))
+ (pointstr "*?*")
+ (env (progn (ignore-errors (cdlatex-environment environment item))
+ (when (> end beg) (insert pointstr))
+ (org-trim (delete-and-extract-region beg end)
+(when (org-string-nw-p env)
+ ;; Get indentation of next line unless at column 0.
+ (let ((ind (if (bolp) 0
+ (save-excursion
+ (org-return-indent)
+ (prog1 (org-get-indentation)
+ (when (progn (skip-chars-forward " \t") (eolp))
+ (delete-region beg (point)))
+ (bol (progn (skip-chars-backward " \t") (bolp
+ ;; Insert a newline before environment unless at column zero
+ ;; to "escape" the current line. Insert a newline if
+ ;; something is one the same line as \end{ENVIRONMENT}.
+ (insert (concat (unless bol "\n")
+ env
+ (when (and (skip-chars-forward " \t") (not (eolp)))
+ "\n")))
+ (unless (zerop ind)
+ (let* ((elm (org-element-at-point))
+ (elm-beg (org-element-property :begin elm))
+ (elm-end (copy-marker
+ (save-excursion
+ (goto-char (org-element-property :end elm))
+ (skip-chars-backward " \t\n\r")
+ (point)
+ (save-excursion
+ (goto-char elm-beg)
+ (while (< (point) elm-end)
+ (unless (eolp) (org-indent-to-column ind))
+ (forward-line)))
+ (set-marker elm-end nil
+ (goto-char beg)
+ (search-forward pointstr)
+ (replace-match ""))
+(set-marker beg nil)
+(set-marker end nil)))
LaTeX fragments
--
2.3.0
Re: [O] [RFC] Simplify `org-show-context' configuration
looks good. thanks for your effort on making a single variable.
Re: [O] Citation syntax: a revised proposal
On Feb 17, 2015 1:12 PM, "Rasmus" wrote:
>
> Richard Lawrence writes:
>
> > Basically, I think you could ignore the distinctions that the [cite:
> > ...] syntax is capable of expressing, and just write all your citations
> > like:
> >
> > [cite: See @Doe99 for more on this point.] %%(:type footnoted)
> >
> > or, in the syntax Nicolas proposed, something like:
> >
> > [cite: See @Doe99 for more on this point.]{:type footnoted}
> >
> > You would then use an export filter to transform citations with this
> > :type into the appropriate command, something along the lines of:
>
> This seems backward and wrong /to me/. Why not global options? I
> actually think we "agreed" on this earlier.
>
> #+cite: text-cite
> #+(cite): parenthesis-cite
>
> Or
>
> #+cite: numeric
> #+(cite): footnote-cite
>
> This is why I asked Tom earlier if he normally uses more than two citation
> TYPES. Presumably citeauthor and citeyear works irrespective of the main
> citation type. So I still think that having two TYPES handy will meet
> most requirements.
This is clearly preferable. Using zotero in odt , rtf , or docx, you
would normally just set a citation style and let zotero take care of the
reformatting. Rasmus's solution is almost as convenient as that, and
presumably backend-independent.
>
> —Rasmus
>
> --
> m-mm-mmm- bacon!
>
>
Re: [O] [patch] better(?) indention for cdlatex-environment
Rasmus writes:
> Perhaps there are clever ways to figure it out. I say there are too many
> dynamics and "fixes" in the code to get cdlatex-environment to work
> already. Just consider this example where | is cursor
>
>- foo | bar
>
> Midway through, when ENV is reinserted, but before indentation the
> end-marker will be *after* bar which is a line after \end{ENV}...
This is exactly what we want: indent (non empty) lines starting in
[BEG ; END[. Or am I missing something?
>> Also you shouldn't apply `org-indent-to-column' when line is empty.
>
> I don't see why not, but OK...
Because it introduces trailing white spaces, which can irritate some
users.
> Anyway it reminded me that I missed "re-implementing" one feature of
> cdlatex, namely moving the cursor to the right place. I refind this
> place do it by inserting a funny string and replacing it. A poor man's
> marker, I guess...
Another option: when ENV is inserted the first time, store (e.g., in N)
how many (forward-line -1) are needed to go back to BEG. At the end of
the process, move to BEG then (forward-line n). I assume point is always
left on an empty lines. If it is not the case, you also need to store
current column, relatively to end of line.
BTW, You didn't update the patch.
Regards,
[O] bug#19887: 24.4; Cannot kill buffer; Wrong type argument: overlayp, nil
On 2015-02-18T06:25:57+1100, Glenn Morris said: GM> Damian Nadales wrote: >> - Run emacs -Q >> >> - Create an org-mode file (i.e. ``myorgfile.org``) >> >> - Insert the following text: >> >> o #+BEGIN_SRC C++ >> >> #+END_SRC >> >> - Edit the source block by placing the cursor inside the SRC >> block. >> >> - Start C++ mode (c++-mode) >> >> - Try to kill the buffer. GM> Please do GM> M-x toggle-debug-on-error GM> repeat the problem, and post the resulting backtrace. (I can't GM> reproduce it.) Running a manually compiled Emacs 24.4.1 on Debian Wheezy(+updates) x86_64, and following the above steps, i can't reproduce this either. From the above description, i assume by the "Start C++ mode" line, you're not moving the cursor inside the source block and then doing: C-c ' (i.e. `org-edit-special`) in order to open a c++-mode buffer for editing the block contents? Alexis.
Re: [O] [RFC] Simplify `org-show-context' configuration
Samuel Wales writes: > that is not canonical. i thought we were working from my previous > posts over the years where i used the term "canonical". > > you cannot create the visibility state you show from a fully-folded > buffer using only arrow keys and tab. You are right. Time for a third round, I guess. This patch removes `full', which is useless, makes `canonical' really canonical, and adds `tree' view, which is basically old wrong `canonical'. Original buffer, full view * Grandmother ** Uncle *** Heir ** Father Ancestor text *** Sister Sibling text *** Self Match First born Child text The other child *** Brother ** Aunt `minimal' * Grandmother *** Self Match `local' * Grandmother *** Self Match First born `ancestors' * Grandmother ** Father *** Self Match `lineage' * Grandmother ** Father *** Sister *** Self Match First born *** Brother `tree' * Grandmother ** Uncle ** Father *** Sister *** Self Match First born The other child *** Brother ** Aunt `canonical' * Grandmother ** Uncle ** Father Ancestor text *** Sister *** Self Match First born The other child *** Brother ** Aunt Regards, >From 6f903362065ab34bcf3a85658d2f2f178e1ecb78 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Mon, 16 Feb 2015 21:43:35 +0100 Subject: [PATCH] Simplify `org-show-context' configuration * lisp/org.el (org-show-context-detail): New variable. (org-context-choice, org-show-following-heading, org-show-siblings, org-show-entry-below, org-show-hierarchy-above): Remove variables. (org-show-set-visibility): New function. (org-get-location, org-show-context, org-reveal): Use new function. (org-link-search): Update docstring. * lisp/org-agenda.el (org-agenda-cycle-show): Use new function. Configuration of `org-show-context' is done with a single variable offering six different views, instead of four variables for a total of 16 configurations. --- lisp/org-agenda.el | 15 ++-- lisp/org.el| 230 ++--- 2 files changed, 118 insertions(+), 127 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9f2d9d1..7adf351 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8696,11 +8696,12 @@ if it was hidden in the outline." (defvar org-agenda-cycle-counter nil) (defun org-agenda-cycle-show (&optional n) "Show the current entry in another window, with default settings. -Default settings are taken from `org-show-hierarchy-above' and siblings. -When use repeatedly in immediate succession, the remote entry will cycle -through visibility -children -> subtree -> folded +Default settings are taken from `org-show-context-detail'. When +use repeatedly in immediate succession, the remote entry will +cycle through visibility + + children -> subtree -> folded When called with a numeric prefix arg, that arg will be passed through to `org-agenda-show-1'. For the interpretation of that argument, see the @@ -9521,11 +9522,7 @@ a timestamp can be added there." (unless (bolp) (insert "\n")) (unless (org-looking-at-p "^[ \t]*$") (save-excursion (insert "\n"))) (when org-adapt-indentation (org-indent-to-column col))) - (let ((org-show-following-heading t) - (org-show-siblings t) - (org-show-hierarchy-above t) - (org-show-entry-below t)) -(org-show-context))) + (org-show-set-visibility 'lineage)) (defun org-agenda-diary-entry () "Make a diary entry, like the `i' command from the calendar. diff --git a/lisp/org.el b/lisp/org.el index 4f047b2..1b20d50 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -1165,87 +1165,80 @@ effective." :tag "Org Reveal Location" :group 'org-structure) -(defconst org-context-choice - '(choice -(const :tag "Always" t) -(const :tag "Never" nil) -(repeat :greedy t :tag "Individual contexts" - (cons - (choice :tag "Context" - (const agenda) - (const org-goto) - (const occur-tree) - (const tags-tree) - (const link-search) - (const mark-goto) - (const bookmark-jump) - (const isearch) - (const default)) - (boolean - "Contexts for the reveal options.") - -(defcustom org-show-hierarchy-above '((default . t)) - "Non-nil means show full hierarchy when revealing a location. -Org-mode often shows locations in an org-mode file which might have -been invisible before. When this is set, the hierarchy of headings -above the exposed location is shown. -Turning this off for example for sparse trees makes them very compact. -Instead of t, this can also be an alist specifying this option for different -contexts. Valid contexts are +(defcustom org-show-context-detail '((isearch . lineage) + (bookmark-jump . lineag
Re: [O] [RFC] Simplify `org-show-context' configuration
hi nicolas, On 2/17/15, Nicolas Goaziou wrote: > I don't understand. Body text is not shown in ancestors. Considering the > following buffer: > > * Grandmother > ** Uncle > *** Heir > ** Father >Ancestor text > *** Sister > Sibling text > *** Self > Match > First born > Child text > The other child > *** Brother > ** Aunt > > `canonical' view is > > * Grandmother > ** Uncle > ** Father > *** Sister > *** Self > Match > First born > The other child > *** Brother > ** Aunt thanks for showing a complete example. that is not canonical. i thought we were working from my previous posts over the years where i used the term "canonical". you cannot create the visibility state you show from a fully-folded buffer using only arrow keys and tab. there are exactly two types of visibility. each type has many variants in principle, but we only need a few for each. 1] can be created using arrows and tab from a fully-folded buffer 2] cannot this is a critical distinction. org so far is not capable of doing any of the [1] states when going to a location. that's the problem that needs solving imo. i actually don't care about any of the [2] states until [1] is possible. within [1], there is a minimal state. let's call it minimal-canonical. /that/ is the state that is most needed. it's roughly like what you show except with the body text for all ancestors. what you show is [2]. it is a great view, and needed, but it is not minimal-canonical. i don't want the term canonical to be used for any of the [2] states, because then we will be back to missing the need for the minimal-canonical view and the need for preserving an org buffer's [1] status. hope that clarifies. samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] [patch] better(?) indention for cdlatex-environment
Nicolas Goaziou writes:
> I don't think you need `org-element-at-point' at all. You already have
> BEG and END markers available. I didn't test it, but this should be
> enough to indent the environment.
Perhaps there are clever ways to figure it out. I say there are too many
dynamics and "fixes" in the code to get cdlatex-environment to work
already. Just consider this example where | is cursor
- foo | bar
Midway through, when ENV is reinserted, but before indentation the
end-marker will be *after* bar which is a line after \end{ENV}... I think
playing the "deterministic" card is non-trivial to get right in all cases
and org-cdlatex-environment-indent is already longer than
cdlatex-environment.
> Also you shouldn't apply `org-indent-to-column' when line is empty.
I don't see why not, but OK... Anyway it reminded me that I missed
"re-implementing" one feature of cdlatex, namely moving the cursor to the
right place. I refind this place do it by inserting a funny string and
replacing it. A poor man's marker, I guess...
—Rasmus
--
I hear there's rumors on the, uh, Internets. . .
>From 7381526412dc6e36e2c5c1b4e92cb102dda8c965 Mon Sep 17 00:00:00 2001
From: rasmus
Date: Tue, 10 Feb 2015 12:02:59 +0100
Subject: [PATCH] org.el: Change indention for cdlatex environments
* org.el (org-cdlatex-environment-indent): Use different indent
algorithm based on content above the new latex-environment.
---
lisp/org.el | 52 +++-
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 4f047b2..6de53f1 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18645,12 +18645,54 @@ Revert to the normal definition outside of these fragments."
(call-interactively (key-binding (vector last-input-event))
(defun org-cdlatex-environment-indent (&optional environment item)
- "Execute `cdlatex-environment' and indent the inserted environment."
+ "Execute `cdlatex-environment' and indent the inserted environment.
+
+ENVIRONMENT and ITEM are passed to `cdlatex-environment'.
+
+The inserted environment is indented to current indentation
+unless point is at the beginning of the line, in which the
+environment remains unintended."
(interactive)
- (cdlatex-environment environment item)
- (let ((element (org-element-at-point)))
-(org-indent-region (org-element-property :begin element)
- (org-element-property :end element
+ ;; cdlatex-environment always return nil. Therefore, capture output
+ ;; first and determine if an environment was selected.
+ (let* ((beg (point-marker))
+ (end (copy-marker (point) t))
+ (env (org-trim
+ (or (progn (ignore-errors (cdlatex-environment environment item))
+ (delete-and-extract-region beg end))
+ ""
+(when (org-string-nw-p env)
+ ;; Get indentation of next line unless at column 0.
+ (let ((ind (if (bolp) 0
+ (save-excursion
+ (org-return-indent)
+ (prog1 (org-get-indentation)
+ (when (and (skip-chars-forward " \t") (eolp))
+ (delete-region beg (point)))
+ (bol (and (skip-chars-backward " \t") (bolp
+ ;; Insert a newline before environment unless at column zero
+ ;; to "escape" the current line. Insert a newline if
+ ;; something is one the same line as \end{ENVIRONMENT}.
+ (insert (concat (unless bol "\n")
+ env
+ (and (skip-chars-forward " \t") (not (eolp)) "\n")))
+ (unless (zerop ind)
+ (let* ((element (org-element-at-point))
+ (elm-beg (org-element-property :begin element))
+ (elm-end (copy-marker
+ (save-excursion
+ (goto-char (org-element-property :end element))
+ (skip-chars-backward " \t\n\r")
+ (point)
+ (save-excursion
+ (goto-char elm-beg)
+ (beginning-of-line)
+ (while (<= (point) elm-end)
+ (org-indent-to-column ind)
+ (forward-line)))
+ (set-marker elm-end nil)
+(set-marker beg nil)
+(set-marker end nil)))
LaTeX fragments
--
2.3.0
Re: [O] [BUG] org-clock-display is partial (only some entries are counted)
Hello, Sebastien Vauban writes: > As you can see on http://screencast.com/t/B0knccOCqco, the output of the > command org-clock-display (bound to C-c C-x C-d) -- which displays > subtree times in the entire buffer -- is partial: for a reason which > still escapes me, meetings A and B are not counted... See `org-clock-display-default-range'. Basically, clock display only consider clocks in the current year, by default. > PS- Another weird thing is to see that "Org clock display" reports some > time (0:13 in the screenshot) for the section "Worked Hours > Report"... which has no LOGBOOK! I cannot reproduce it. Regards, -- Nicolas Goaziou
Re: [O] on the fragility of export to ODT
Eric S Fraga writes: > I have many internal references; in this document, all are to named > tables and figures. The error comes from a figure, not a table, if that helps. > I have tried but haven't managed to track down which one is causing > problems in this case. > > I have tried extracting various bits into smaller org files but then the > problems disappear... :( > > Part of the problem, I think (but please correct me if I'm wrong), is > that the positions indicated in the error messages are in the buffer > being exported after a certain amount of processing (including, I would > imagine, babel) and so it's difficult to find the actual location of the > problem. > > If this is indeed the case, is there any way to retain the buffer that > is being processed at the point the error occurs? You're right, buffer positions mean nothing here. However, there's a simpler solution. In- "ox-odt.el", function `org-odt-link--infer-description', line 2655 (but it depends on Org version), there is (t (error "FIXME: Resolve %s" destination)) Replace it with (t (error "FIXME: Resolve %s" (org-element-interpret-data destination reload Org then trigger the error. The backtrace should be more interesting. Regards,
Re: [O] [PATCH] Recognize property blocks even after text
Sacha Chua writes: > Ah, that makes perfect sense. I'll try to train myself out of adding > stuff everywhere, then. Thank you! If you the keybind it will do the right thing. In ORG-NEWS there's a script to fix old files. Worst case use it as a save-hook... –Rasmus -- And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [O] [RFC] Simplify `org-show-context' configuration
Samuel Wales writes: > it would be good to also have semi-canonical [i.e. > canonical-without-ancestor-body-text], where ancestor nodes do not > show body text. text can obscure structure. i use this view for > blogs. otherwise i'd have to make fake headlines just to hide text. I don't understand. Body text is not shown in ancestors. Considering the following buffer: * Grandmother ** Uncle *** Heir ** Father Ancestor text *** Sister Sibling text *** Self Match First born Child text The other child *** Brother ** Aunt `canonical' view is * Grandmother ** Uncle ** Father *** Sister *** Self Match First born The other child *** Brother ** Aunt > does full show the entry below the headline that point is on? i > wouldn't use this view if it is not canonical [i.e. does not show > children also]. `full', as its name suggests, shows complete subtree: all children and their contents. > do we presume that the entire buffer's visibility is changed for > showing context, or are things that already shown left showing? `canonical' change visibilty in subtree, so some parts of it could be hidden in the process. Other views only augment current visibility. Regards,
Re: [O] [PATCH] Recognize property blocks even after text
Rasmus writes: >> Hi! I noticed that the refactored org-get-property-block no longer >> allows for any text (aside from the SCHEDULED / DEADLINE / CLOSED) text >> between the heading and the property drawer, which gave me problems when > Did you see this discussion? I think it's a feature. > http://permalink.gmane.org/gmane.emacs.orgmode/91752 Ah, that makes perfect sense. I'll try to train myself out of adding stuff everywhere, then. Thank you! Sacha
Re: [O] How to set a default language for source blocks?
Hi, Grant.
Grant Rettke writes:
It would be simpler to say "this whole document will be R source
blocks, unless I specify other wise". I looked at [the spec]. I
wanted to obtain this behavior. I couldn't figure out how. Is it
possible?
The problem is that if there is nothing after #+BEGIN_SRC, then
org-babel-get-src-block-info returns nil. Probably you would have
to modify org-babel-get-src-block-info so that it returns a
default when there is nothing after #+BEGIN_SRC. But isn't it
easier to set org-structure-template-alist as a local buffer
variable, say in the first line of your file something like:
#+BEGIN_EXAMPLE
# -*- org-structure-template-alist: '(("s" "#+BEGIN_SRC
python\n?\n#+END_SRC")) -*-
#+END_EXAMPLE
Then file, for example.
Best,
--
Jorge.
Re: [O] Refile not working as desired
Michael Ziems wrote: > Awesome :) > > Thank you so much, that was the solution! > > (setq org-refile-use-outline-path 'file) > (setq org-refile-targets '((org-agenda-files :maxlevel . 24))) > > the command ist taking quite a while during "Getting targets" can i > speed this actualy up? You could try 1. decreasing maxlevel, unless you really refile to levels that deep 2. setting `org-refile-cache' to a non-nil value -- Kyle
Re: [O] Refile not working as desired
Awesome :) Thank you so much, that was the solution! (setq org-refile-use-outline-path 'file) (setq org-refile-targets '((org-agenda-files :maxlevel . 24))) the command ist taking quite a while during "Getting targets" can i speed this actualy up? Am 17.02.2015 um 20:34 schrieb Kyle Meyer: Michael Ziems wrote: [...] (setq org-refile-use-outline-path 'file) (setq org-refile-targets '((org-agenda-files :level . 4))) [...] but ord mode is only allowing me to go exactly to one level deep (i assume level 4) but when i leave: [...] Do you have any idea, what could be the reason? Have your tried :maxlevel instead of :level?
Re: [O] How to set a default language for source blocks?
Grant Rettke writes: > Just read [this] question. It is interesting. We always want to optimize > our documents. Re-use reduces errors. Defining `:header-args:foo: > :session *bar*' is a great example. Rather than having to type it 100 > times all over, just do it once. It never occurred to be that we might > want to default the language for a source block. It should have. It > would be simpler to say "this whole document will be R source blocks, > unless I specify other wise". I looked at [the spec]. I wanted to obtain > this behavior. I couldn't figure out how. Is it possible? I didn't look > at the parser, is that the right place to look to answer questions like > this? You don't have to check the implementation, you can simply check the Org syntax¹. Blocks Like greater blocks, pattern for blocks is: #+BEGIN_NAME DATA CONTENTS #+END_NAME NAME cannot contain any whitespace character. [...] If it is “SRC”, it will be a “source block” [...] DATA can contain any character but a new line. It can be ommitted, unless the block is a “source block”. In this case, it must follow the pattern “LANGUAGE SWITCHES ARGUMENTS”, where SWITCHES and ARGUMENTS are optional. —Rasmus Footnotes: ¹ http://orgmode.org/worg/dev/org-syntax.html -- The right to be left alone is a human right
[O] How to set a default language for source blocks?
Good afternoon, Just read [this] question. It is interesting. We always want to optimize our documents. Re-use reduces errors. Defining `:header-args:foo: :session *bar*' is a great example. Rather than having to type it 100 times all over, just do it once. It never occurred to be that we might want to default the language for a source block. It should have. It would be simpler to say "this whole document will be R source blocks, unless I specify other wise". I looked at [the spec]. I wanted to obtain this behavior. I couldn't figure out how. Is it possible? I didn't look at the parser, is that the right place to look to answer questions like this? [this] https://emacs.stackexchange.com/questions/8314/set-default-language-for-code-blocks-in-orgmode/9316#9316 [the spec] http://orgmode.org/manual/Structure-of-code-blocks.html#Structure-of-code-blocks -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] Refile not working as desired
Michael Ziems wrote: [...] > (setq org-refile-use-outline-path 'file) > (setq org-refile-targets '((org-agenda-files :level . 4))) [...] > but ord mode is only allowing me to go exactly to one level deep (i > assume level 4) > but when i leave: [...] > Do you have any idea, what could be the reason? Have your tried :maxlevel instead of :level? -- Kyle
Re: [O] [RFC] Simplify `org-show-context' configuration
i use maint, but looks good. i'd use canonical most of the time. it would be good to also have semi-canonical [i.e. canonical-without-ancestor-body-text], where ancestor nodes do not show body text. text can obscure structure. i use this view for blogs. otherwise i'd have to make fake headlines just to hide text. does full show the entry below the headline that point is on? i wouldn't use this view if it is not canonical [i.e. does not show children also]. do we presume that the entire buffer's visibility is changed for showing context, or are things that already shown left showing? -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] on the fragility of export to ODT
On Monday, 16 Feb 2015 at 21:20, Nicolas Goaziou wrote: > Hello, > > Eric S Fraga writes: > >> At this point, I get very long data structures dumped to >> *Messages*... difficult to figure out what is wrong. It's often my >> mistake but tracking it down is difficult. > > You're using an internal link to target a paragraph (possibly a image or > some such). This is apparently not supported yet by ox-odt (see > `org-odt-link--infer-description'). > > Could you try to find out the culprit and explain what you expected so > I can fix it? Hi Nicolas, I have many internal references; in this document, all are to named tables and figures. I have tried but haven't managed to track down which one is causing problems in this case. I have tried extracting various bits into smaller org files but then the problems disappear... :( Part of the problem, I think (but please correct me if I'm wrong), is that the positions indicated in the error messages are in the buffer being exported after a certain amount of processing (including, I would imagine, babel) and so it's difficult to find the actual location of the problem. If this is indeed the case, is there any way to retain the buffer that is being processed at the point the error occurs? >> However, more importantly, the failure is complete and nothing is >> exported which does not help me at all. It would be great if offending >> paragraphs (elements, objects, whatever) would be skipped over and the >> rest of the document generated. Is this possible? > > At the moment, I think it is better to fix the errors than to ignore > them. There are quite a few "FIXME" in ox-odt. Okay, that's fine. In any case, I'm in no panic as I have simply sent the PDF to my co-author and that's good enough for now. Eventually, I may need to get the DOC version but I can keep my fingers crossed and hope it doesn't come to that... thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-820-gd92ef9
[O] Refile not working as desired
Hello, i am using the following in my .emacs: (setq org-refile-use-outline-path 'file) (setq org-refile-targets '((org-agenda-files :level . 4))) i would now like to drop a certain headline when pressing C-c C-w anywhere: maybe directly in: work.org as first headline work.org/routine/customerABC/ or maybe work.org/routine/customerABC/Calls/meeting20150217/notes/whatever but ord mode is only allowing me to go exactly to one level deep (i assume level 4) but when i leave: (setq org-refile-targets '((org-agenda-files :level . 4))) out it is still not allowing it. Do you have any idea, what could be the reason?
Re: [O] Citation syntax: a revised proposal
Richard Lawrence writes:
> Basically, I think you could ignore the distinctions that the [cite:
> ...] syntax is capable of expressing, and just write all your citations
> like:
>
> [cite: See @Doe99 for more on this point.] %%(:type footnoted)
>
> or, in the syntax Nicolas proposed, something like:
>
> [cite: See @Doe99 for more on this point.]{:type footnoted}
>
> You would then use an export filter to transform citations with this
> :type into the appropriate command, something along the lines of:
This seems backward and wrong /to me/. Why not global options? I
actually think we "agreed" on this earlier.
#+cite: text-cite
#+(cite): parenthesis-cite
Or
#+cite: numeric
#+(cite): footnote-cite
This is why I asked Tom earlier if he normally uses more than two citation
TYPES. Presumably citeauthor and citeyear works irrespective of the main
citation type. So I still think that having two TYPES handy will meet
most requirements.
—Rasmus
--
m-mm-mmm- bacon!
Re: [O] [patch, ox-html] mathjax changes
Hi,
Rasmus writes:
>>> and *why* is orgmode.org hosting it? Privacy?
>>
>> I don't think CDN service was available at the time mathjax support was
>> implemented. IMO, it hardly makes sense to host it now.
>
> This patch switches the cdn to upstream and removes a lot of stuff that I
> believe mathjax will figure out on it own. I'm no mathjax or webs export,
> though. Notably, mathml stuff is gone.
>
> OTOH, I added some display options, which I believe one might care about.
> If more "user-sensible" options exists I can add them.
>
> It would be good if someone who knows MathJax better could reviews this.
Added font, better scale support, linebreaks, linebreaks and possibility
for the browser to chose MathMl if support is good enough.
If you are uncomfortable with Org linking against cdn.mathjax.org it would
be good to let me know. If no other inputs, I will install this patch
soonish.
—Rasmus
--
The second rule of Fight Club is: You do not talk about Fight Club
>From bc57c2daa56838487f183931aead4fd9720307d1 Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Mon, 16 Feb 2015 02:04:02 +0100
Subject: [PATCH] ox-html: Use upstream MathJax CDN
* ox-html.el (org-html-mathjax-options): Add multlinewidth,
autonumber, tagindent, font, linebreaks and tagside. Remove MathML.
Change default indent to correspond to upstream default. Change
default MathJax path to point to upstream CDN.
(org-html--build-mathjax-config): Remove MathML-related parts.
(org-html-mathjax-template): Simplifiy template.
* org.texi (@LaTeX{} fragments), (Math formatting in HTML export):
Reflect change in default CDN.
---
doc/org.texi| 51 -
lisp/ox-html.el | 168 +++-
2 files changed, 116 insertions(+), 103 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index bec46a9..de79e94 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -10258,20 +10258,17 @@ format sub- and superscripts in a WYSIWYM way.
Going beyond symbols and sub- and superscripts, a full formula language is
needed. Org mode can contain @LaTeX{} math fragments, and it supports ways
to process these for several export back-ends. When exporting to @LaTeX{},
-the code is obviously left as it is. When exporting to HTML, Org can invoke
-the @uref{http://www.mathjax.org, MathJax library} (@pxref{Math formatting in
-HTML export}) to process and display the math@footnote{If you plan to use
-this regularly or on pages with significant page views, you should install
-@file{MathJax} on your own server in order to limit the load of our server.}.
-It can also process the mathematical expressions into images that can be
-displayed in a browser (see @pxref{Previewing @LaTeX{} fragments}).
+the code is left as it is. When exporting to HTML, Org can use either
+@uref{http://www.mathjax.org, MathJax} (@pxref{Math formatting in HTML
+export}) or transcode the math into images (see @pxref{Previewing @LaTeX{}
+fragments}).
@LaTeX{} fragments don't need any special marking at all. The following
snippets will be identified as @LaTeX{} source code:
@itemize @bullet
@item
-Environments of any kind@footnote{When @file{MathJax} is used, only the
-environments recognized by @file{MathJax} will be processed. When
+Environments of any kind@footnote{When MathJax is used, only the
+environments recognized by MathJax will be processed. When
@file{dvipng} program or @file{imagemagick} suite is used to create images,
any @LaTeX{} environment will be handled.}. The only requirement is that the
@code{\begin} statement appears on a new line, at the beginning of the line
@@ -10307,7 +10304,7 @@ either $$ a=+\sqrt@{2@} $$ or \[ a=-\sqrt@{2@} \].
@vindex org-export-with-latex
@LaTeX{} processing can be configured with the variable
@code{org-export-with-latex}. The default setting is @code{t} which means
-@file{MathJax} for HTML, and no processing for ASCII and @LaTeX{} back-ends.
+MathJax for HTML, and no processing for ASCII and @LaTeX{} back-ends.
You can also set this variable on a per-file basis using one of these
lines:
@@ -11466,25 +11463,23 @@ You could use @code{http} addresses just as well.
@cindex imagemagick
@LaTeX{} math snippets (@pxref{@LaTeX{} fragments}) can be displayed in two
-different ways on HTML pages. The default is to use the
-@uref{http://www.mathjax.org, MathJax system} which should work out of the
-box with Org mode installation because @uref{http://orgmode.org} serves
-@file{MathJax} for Org mode users for small applications and for testing
-purposes. @b{If you plan to use this regularly or on pages with significant
-page views, you should install@footnote{Installation instructions can be
-found on the MathJax website, see
-@uref{http://www.mathjax.org/resources/docs/?installation.html}.} MathJax on
-your own server in order to limit the load of our server.} To configure
-@file{MathJax}, use the variable @code{org-html-mathjax-options} or
-insert something like the
Re: [O] Citation syntax: a revised proposal
Hi Tom,
t...@tsdye.com (Thomas S. Dye) writes:
> I want a syntax that recognizes arbitrary citation commands because I
> write in Org mode for publication. You want a syntax that recognizes a
> few commands that it might be possible to support in Org mode backends,
> some of which are tied loosely, if at all, to publication. Yours might
> be a noble goal that many Org mode users will find useful (I hope it
> is!), but I don't think it is (or will be) a syntax useful in my work,
> for the following reasons:
>
> 1) It is easier for me to have the citation command in one place. The
> decision to represent selected aspects of the citation command in the
> syntax and other parts in extensions means that I'd have to learn the
> syntax and then remember which aspects were chosen for representation
> and which I'd need to develop through extensions of my own. This is a
> lot more work than I do now to get exactly what I want through links.
> I'm keen to simplify the authoring process, not make it more complex.
>
> 2) Treating footnote citations differently from author-date citations is
> a non-starter for me. When Science turns me away and the editor
> suggests that my rant is well suited for another journal, one that
> happens to use author-date citations, I'll just search all my citation
> links and replace footcite with parencite before exporting the rant to
> the suggested journal. IIUC, with the official Org mode syntax, I'd be
> faced with the tedious process of cutting and pasting footnote text back
> into the document body.
I do think it is important to support these kinds of uses, and I think
it would be a shame if the official Org syntax did not make them
relatively straightforward. You are surely not the only person using
Org to prepare documents for publication, and I'm sure this kind of
per-journal `refactoring' is common and important to make easy.
(You're right that our goals differ to some extent. I am still in grad
school. Preparing documents for academic publication is a privilege I
hope to have one day; but I am not presently one of the people using Org
for this on a regular basis, though I hope I can in the future. One
reason I am concerned to have a citation syntax that can be exported by
other backends is this: I am anxious that, unless I can also export my
dissertation to HTML, the final document may never be read by anyone
except backup programs on the library servers. Another, more serious
reason is that I work in a field where some journals do not accept LaTeX
submissions, or disprefer them; so having some citation support in ODT
export is important.)
I *think* it should be possible to do the kinds of things you've
described here using the syntax I proposed, but I may not understand
everything you'd like to do. If not, let's figure out what the other
things are, and how to accommodate them.
Basically, I think you could ignore the distinctions that the [cite:
...] syntax is capable of expressing, and just write all your citations
like:
[cite: See @Doe99 for more on this point.] %%(:type footnoted)
or, in the syntax Nicolas proposed, something like:
[cite: See @Doe99 for more on this point.]{:type footnoted}
You would then use an export filter to transform citations with this
:type into the appropriate command, something along the lines of:
(defun footnoted-citation (citation backend info)
(let ((type (get-citation-type citation)
(pre (get-citation-prefix citation))
(post (get-citation-suffix citation))
(key (get-citation-key citation)))
(when (and (org-export-derived-backend-p backend 'latex)
(eq type 'footnoted))
(format "\footcite[%s][%s]{%s}" pre post key
(It would be more complicated than this in the general case, since a
citation can contain more than one reference as well as common prefix
and suffix text, but hopefully that illustrates the idea.)
Then, when Science sends you elsewhere, you can just query-replace
":type footnoted" with ":type author-date", or whatever the appropriate
type for the new journal is, which will have a different export filter
(or a different clause in the same filter).
That is more work than letting Org export citations for you, because it
means manually processing every :type you use. But maybe it is about
the same amount of work as what you are doing now with custom links.
This way, although you wouldn't be relying much on the default export
behavior of citations, you could still get the other advantages of
having them represented in Org syntax. Those are things like having
prefix/suffix text stand in a more readable relation to the key, having
Org parse the different parts out for you, and having individual keys be
clickable so you can look up the reference in your reference database or
find an associated PDF.
Would that be sufficient? And are there other kinds of situation where
you don't think the proposed syntax would work well?
Best,
Richard
Re: [O] orgmode-contacts "wrong type arguments"
Thanks Nick for the tip; I've recently learned about debug-on-entry, which I
attempted to use to no avail last night, but the functions listed in the info
manual you cited are useful. Following them I have found that the problem seems
to be a conflict bewteen Org-Contacts and Helm; loading without helm enabled
fixes the problem. Unfortunately, this seems like a lose-lose tradeoff to
disable helm or go without mailing list functionality. I'm open to any
suggestions, now that I know that a Helm conflict is apparently causing the
listp error.
Nick Dokos writes:
> torys.ander...@gmail.com (Tory S. Anderson) writes:
>
>> Presumably this is related to my having upgraded to:
>> Org-mode version 8.2.10 (8.2.10-33-g880a2b-elpa)
>> GNU Emacs 25.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.9) of
>> 2015-02-10 on localhost.localdomain
>>
>> I use org-contacts[1] to autofill addresses in GNUs. Normally can use
>> "+CATEGORY" to add all names in a category; but now that particular
>> functionality seems to be broken (although the package is otherwise
>> functional). In my efforts to improve my elisp, can anyone tell me why
>> the code doesn't work, and what might have changed to cause it to
>> break?
>>
>> Error:
>> completion-in-region: Wrong type argument: listp, #("NAME
>> , NAME , NAME ,
>> NAME " 0 15 (fontified nil org-category
>> "contacts") 44 65 (fontified nil org-category "contacts") 88 99
>> (fontified nil org-category "contacts") 127 141 (fontified nil
>> org-category "contacts"))
>>
>> Footnotes:
>> [1] https://julien.danjou.info/projects/emacs-packages#org-contacts
>>
>
> When you get an error, the first thing you should do is get a backtrace:
>
>(info "(org) Feeback")
>
> It's far more likely that you can find the error (or somebody can find
> it for you) with a backtrace in hand.
Re: [O] orgmode-contacts "wrong type arguments"
torys.ander...@gmail.com (Tory S. Anderson) writes:
> Presumably this is related to my having upgraded to:
> Org-mode version 8.2.10 (8.2.10-33-g880a2b-elpa)
> GNU Emacs 25.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.9) of
> 2015-02-10 on localhost.localdomain
>
> I use org-contacts[1] to autofill addresses in GNUs. Normally can use
> "+CATEGORY" to add all names in a category; but now that particular
> functionality seems to be broken (although the package is otherwise
> functional). In my efforts to improve my elisp, can anyone tell me why
> the code doesn't work, and what might have changed to cause it to
> break?
>
> Error:
> completion-in-region: Wrong type argument: listp, #("NAME
> , NAME , NAME ,
> NAME " 0 15 (fontified nil org-category
> "contacts") 44 65 (fontified nil org-category "contacts") 88 99
> (fontified nil org-category "contacts") 127 141 (fontified nil
> org-category "contacts"))
>
> Footnotes:
> [1] https://julien.danjou.info/projects/emacs-packages#org-contacts
>
When you get an error, the first thing you should do is get a backtrace:
(info "(org) Feeback")
It's far more likely that you can find the error (or somebody can find
it for you) with a backtrace in hand.
--
Nick
[O] Org open link in new window
Navigating through the labyrinth of org commands and wrappers, I've not been able to find out if there's already a way to open a link (particularly a footnote link) in a new window, so that I could retain my in-line location and context while reading the linked/footnoted text. I realize this functionality is probably out there, but I'm not seeing it in the manual section on links. How can I open links in new window (splitting my screen)?
Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags search agendas
Sebastien Vauban writes: > PS- If there was just one other issue I'd like to see resolved from that > list, it's #27, but (IIRC) it will be part of a change you'll make to > fontify the Org buffer from the parser info, right? I'm not sure it would solve anything. You may want to change the order in which faces are applied (see `org-set-font-lock-defaults'). Regards,
Re: [O] [RFC] Simplify `org-show-context' configuration
Actually, the first patch didn't pay attention to children, if any, of the current headline. Here is a new patch, including feedback from Kyle and Sébastien. Considering the following buffer, "Text" being the matched location * Grandmother ** Uncle *** Heir ** Father *** Sister *** Self Text First born Other text The other child *** Brother ** Aunt `minimal' is * Grandmother *** Self Text `local' is * Grandmother *** Self Text First born `ancestors' is * Grandmother ** Father *** Self Text `lineage' is * Grandmother ** Father *** Sister *** Self Text First born *** Brother `canonical' is * Grandmother ** Uncle ** Father *** Sister *** Self Text First born The other child *** Brother ** Aunt `full' is * Grandmother ** Uncle ** Father *** Sister *** Self Text First born Other text The other child *** Brother ** Aunt Regards, -- Nicolas Goaziou >From 7108b6a5fc2332f05979796af734b1d55e7a8172 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Mon, 16 Feb 2015 21:43:35 +0100 Subject: [PATCH] Simplify `org-show-context' configuration * lisp/org.el (org-show-context-detail): New variable. (org-context-choice, org-show-following-heading, org-show-siblings, org-show-entry-below, org-show-hierarchy-above): Remove variables. (org-show-set-visibility): New function. (org-get-location, org-show-context, org-reveal): Use new function. (org-link-search): Update docstring. * lisp/org-agenda.el (org-agenda-cycle-show): Use new function. Configuration of `org-show-context' is done with a single variable offering six different views, instead of four variables for a total of 16 configurations. --- lisp/org-agenda.el | 15 ++-- lisp/org.el| 228 + 2 files changed, 114 insertions(+), 129 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9f2d9d1..7adf351 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8696,11 +8696,12 @@ if it was hidden in the outline." (defvar org-agenda-cycle-counter nil) (defun org-agenda-cycle-show (&optional n) "Show the current entry in another window, with default settings. -Default settings are taken from `org-show-hierarchy-above' and siblings. -When use repeatedly in immediate succession, the remote entry will cycle -through visibility -children -> subtree -> folded +Default settings are taken from `org-show-context-detail'. When +use repeatedly in immediate succession, the remote entry will +cycle through visibility + + children -> subtree -> folded When called with a numeric prefix arg, that arg will be passed through to `org-agenda-show-1'. For the interpretation of that argument, see the @@ -9521,11 +9522,7 @@ a timestamp can be added there." (unless (bolp) (insert "\n")) (unless (org-looking-at-p "^[ \t]*$") (save-excursion (insert "\n"))) (when org-adapt-indentation (org-indent-to-column col))) - (let ((org-show-following-heading t) - (org-show-siblings t) - (org-show-hierarchy-above t) - (org-show-entry-below t)) -(org-show-context))) + (org-show-set-visibility 'lineage)) (defun org-agenda-diary-entry () "Make a diary entry, like the `i' command from the calendar. diff --git a/lisp/org.el b/lisp/org.el index 4f047b2..c707ff4 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -1165,87 +1165,72 @@ effective." :tag "Org Reveal Location" :group 'org-structure) -(defconst org-context-choice - '(choice -(const :tag "Always" t) -(const :tag "Never" nil) -(repeat :greedy t :tag "Individual contexts" - (cons - (choice :tag "Context" - (const agenda) - (const org-goto) - (const occur-tree) - (const tags-tree) - (const link-search) - (const mark-goto) - (const bookmark-jump) - (const isearch) - (const default)) - (boolean - "Contexts for the reveal options.") - -(defcustom org-show-hierarchy-above '((default . t)) - "Non-nil means show full hierarchy when revealing a location. -Org-mode often shows locations in an org-mode file which might have -been invisible before. When this is set, the hierarchy of headings -above the exposed location is shown. -Turning this off for example for sparse trees makes them very compact. -Instead of t, this can also be an alist specifying this option for different -contexts. Valid contexts are +(defcustom org-show-context-detail '((isearch . lineage) + (bookmark-jump . lineage) + (default . ancestors)) + "Alist between context and visibility span when revealing a location. + +\\Some actions may move point into invisible +locations. As a consequence, Org always expose a neighborhood +around point. How much is shown depends on the
Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags search agendas
Hello Nicolas, Nicolas Goaziou wrote: > Sebastien Vauban writes: > >> I guess it's directly linked to a problem I reported last >> September. This is indeed annoying... >> >> See issue #29 on http://orgmode.org/worg/org-issues.html (and see the >> pointed thread). > > This isssue seems fixed. Can you confirm it? Yes, I do. Thanks! PS- If there was just one other issue I'd like to see resolved from that list, it's #27, but (IIRC) it will be part of a change you'll make to fontify the Org buffer from the parser info, right? Best regards, Seb -- Sebastien Vauban
Re: [O] Sverweis like function for orgtbl
* Thorsten Grothe wrote: > Dear Org-users, > > I got this table: > >| Menge (x) | P(x) | E(x) | K(x) | Gewinn | >|---+--+++-| >| 0 | 20 | 0.00 | 140.00 | -140.00 | >|10 | 18 | 180.00 | 180.00 | 0.00| >|20 | 16 | 320.00 | 220.00 | 100.00 | >|30 | 14 | 420.00 | 260.00 | 160.00 | > > and would like to find the highest value in the column "Gewinn" = 160 go > two cells left to E(x), read out the value (420) and put this in a remote > orgtbl. This is something similar to Sverweis in Excel. You might be interested in: http://sachachua.com/blog/2015/01/getting-data-org-mode-tables/ or https://github.com/tbanel/orgaggregate I'd give it a try with orgaggregate since it provides a lot of reference methods. Did not try it by myself - it's on my todo list for the weekend (again) :-) -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] [RFC] Simplify `org-show-context' configuration
Eric Abrahamsen wrote: > Sebastien Vauban writes: >> Nicolas Goaziou wrote: >>> Sebastien Vauban writes: >>> Question: are the level-1 headlines always visible, all of them I mean? I know that's the case as of now, but wondered if it'd be good to hide the ones which are not significant. Not a very sharp advice on this, though. >>> >>> I have no strong opinion about this, but I think it would be odd if >>> they were invisible. After all, this is the basic structure of the >>> document. >> >> Yes, that's why I'm not so pushy about it. OTOH, it's nice to hide them >> when you have a lot of level-1 sections -- I remember that being asked >> here by someone. >> >> But, once again, for me, it's not that important. > > I'd prefer not to do that -- it's easy to get confused, and we've got > narrowing when we need to really focus. Well, I never said it had to be the only (or default) behavior... Just mentioning that some people express that wish, from time to time. But I won't push for it. Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Simplify `org-show-context' configuration
Sebastien Vauban writes: > Nicolas Goaziou wrote: >> Sebastien Vauban writes: >> >>> Question: are the level-1 headlines always visible, all of them >>> I mean? I know that's the case as of now, but wondered if it'd be >>> good to hide the ones which are not significant. Not a very sharp >>> advice on this, though. >> >> I have no strong opinion about this, but I think it would be odd if >> they were invisible. After all, this is the basic structure of the >> document. > > Yes, that's why I'm not so pushy about it. OTOH, it's nice to hide them > when you have a lot of level-1 sections -- I remember that being asked > here by someone. > > But, once again, for me, it's not that important. I'd prefer not to do that -- it's easy to get confused, and we've got narrowing when we need to really focus. "if required"/"if needed" means the entry will only be shown if point is within the entry (i.e., not on the headline). Thus, for example, `canonical' and `full' only differ when match is on a headline, since only latter will show the entry. I think this is enough, but I can add more views if needed. WDYT? >>> >>> My /personal/ preference is to see the ancestors, so that I can know >>> which path lead to the entry, and avoid confusion in case some "sub >>> sub sections" are repeated in many different "sub sections". >>> >>> With your proposal, I then only have the choice between `lineage', >>> `full' and `canonical', while I'd like something which would give me: >>> >>> * H1 >>> * H2 >>> ** Sub 2 >>> *** Sub sub 2 >>> Text >>> >>> WDYT? >> >> I can add `ancestors' view, which would basically be `lineage' without >> siblings. > > That'd certainly be good -- and match my current Org config. > > And, if I may, to be sure we are somehow "symmetrical", it'd be good to > have as well: > > * H1 > * H2 > ** Sub 2 > *** Sub sub 1 > *** Sub sub 2 > Text > *** Sub sub 3 > *** Sub sub 4 > > That is "ancestors" + the siblings of the leaf entry. This is the view I'd be interested in having, as well. Thanks! Eric
Re: [O] [RFC] Simplify `org-show-context' configuration
Nicolas Goaziou wrote: > Sebastien Vauban writes: > >> Question: are the level-1 headlines always visible, all of them >> I mean? I know that's the case as of now, but wondered if it'd be >> good to hide the ones which are not significant. Not a very sharp >> advice on this, though. > > I have no strong opinion about this, but I think it would be odd if > they were invisible. After all, this is the basic structure of the > document. Yes, that's why I'm not so pushy about it. OTOH, it's nice to hide them when you have a lot of level-1 sections -- I remember that being asked here by someone. But, once again, for me, it's not that important. >>> "if required"/"if needed" means the entry will only be shown if >>> point is within the entry (i.e., not on the headline). Thus, for >>> example, `canonical' and `full' only differ when match is on >>> a headline, since only latter will show the entry. >>> >>> I think this is enough, but I can add more views if needed. >>> >>> WDYT? >> >> My /personal/ preference is to see the ancestors, so that I can know >> which path lead to the entry, and avoid confusion in case some "sub >> sub sections" are repeated in many different "sub sections". >> >> With your proposal, I then only have the choice between `lineage', >> `full' and `canonical', while I'd like something which would give me: >> >> * H1 >> * H2 >> ** Sub 2 >> *** Sub sub 2 >> Text >> >> WDYT? > > I can add `ancestors' view, which would basically be `lineage' without > siblings. That'd certainly be good -- and match my current Org config. And, if I may, to be sure we are somehow "symmetrical", it'd be good to have as well: --8<---cut here---start->8--- * H1 * H2 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 --8<---cut here---end--->8--- That is "ancestors" + the siblings of the leaf entry. Best regards, Seb -- Sebastien Vauban
[O] [BUG] org-clock-display is partial (only some entries are counted)
Hello, As you can see on http://screencast.com/t/B0knccOCqco, the output of the command org-clock-display (bound to C-c C-x C-d) -- which displays subtree times in the entire buffer -- is partial: for a reason which still escapes me, meetings A and B are not counted... On the other hand, the dynamic block (at the bottom of the ECM) is correct. PS- Another weird thing is to see that "Org clock display" reports some time (0:13 in the screenshot) for the section "Worked Hours Report"... which has no LOGBOOK! --8<---cut here---start->8--- #+TITLE: ECM * Events ** Meeting A :LOGBOOK: CLOCK: [2014-12-01 Mon 11:49]--[2014-12-01 Mon 17:12] => 5:23 :END: <2014-12-01 Mon 13:00-17:00> ** Meeting B :LOGBOOK: CLOCK: [2014-12-19 Fri 08:02]--[2014-12-19 Fri 15:02] => 7:00 CLOCK: [2014-12-19 Fri 16:47]--[2014-12-19 Fri 17:35] => 0:48 CLOCK: [2014-12-23 Tue 10:44]--[2014-12-23 Tue 12:49] => 2:05 CLOCK: [2014-12-24 Wed 08:40]--[2014-12-24 Wed 08:54] => 0:14 CLOCK: [2014-12-24 Wed 15:17]--[2014-12-24 Wed 15:32] => 0:15 :END: <2014-12-19 Fri 09:00-13:00> ** Meeting C <2015-01-09 Fri 10:00-18:00> :LOGBOOK: CLOCK: [2015-01-09 Fri 08:50]--[2015-01-09 Fri 18:02] => 9:12 :END: ** Meeting D :LOGBOOK: CLOCK: [2015-01-27 Tue 13:09]--[2015-01-27 Tue 16:50] => 3:41 CLOCK: [2015-01-28 Wed 11:40]--[2015-01-28 Wed 12:23] => 0:43 CLOCK: [2015-01-28 Wed 13:44]--[2015-01-28 Wed 14:59] => 1:15 CLOCK: [2015-01-29 Thu 09:32]--[2015-01-29 Thu 10:10] => 0:38 CLOCK: [2015-02-11 Wed 11:07]--[2015-02-11 Wed 11:52] => 0:45 :END: <2015-01-27 Tue 14:00-16:00> * Worked Hours Report #+BEGIN: clocktable :maxlevel 2 :scope file #+CAPTION: Clock summary at [2015-02-17 Tue 10:05] | Headline| Time | | |-+---+---| | Total time | 31:59 | | |-+---+---| | Events | 31:59 | | | \emsp Meeting A | | 5:23 | | \emsp Meeting B | | 10:22 | | \emsp Meeting C | | 9:12 | | \emsp Meeting D | | 7:02 | #+END: --8<---cut here---end--->8--- Best regards, Seb -- Sebastien Vauban
Re: [O] orgmode-contacts "wrong type arguments"
On 2015-02-17T00:17:59+1100, Tory S. Anderson said:
TSA> In my efforts to improve my elisp, can anyone tell me why
the code TSA> doesn't work, and what might have changed to cause
it to break?
TSA> Error: completion-in-region: Wrong type argument: listp,
#("NAME TSA> , NAME , NAME
TSA> , NAME " 0 15
(fontified TSA> nil org-category "contacts") 44 65 (fontified nil
org-category TSA> "contacts") 88 99 (fontified nil org-category
"contacts") 127 TSA> 141 (fontified nil org-category "contacts"))
It looks like something in `completion-in-region` wanted a plain
old list of items, but instead got a propertized string. For
further information, check out section "31.19.2, Changing Text
Properties" of the Emacs Lisp Reference Manual - in particular,
the entry for the `propertize` function.
Alexis.
Re: [O] [patch] better(?) indention for cdlatex-environment
Rasmus writes:
> + ;; cdlatex-environment always return nil. Therefore, capture output
> + ;; first and determine if an environment was selected.
> + (let* ((beg (point-marker))
> + (end (copy-marker (point) t))
> + (env (org-trim
> +(or (progn (ignore-errors (cdlatex-environment environment item))
> + (delete-and-extract-region beg end))
> +""
The `or' is not necessary: `delete-and-extract-region' already returns
the empty string when markers don't move.
(env (progn (ignore-errors (cdlatex-environment environment item))
(org-trim (delete-and-extract-region beg end)))
> +(when (org-string-nw-p env)
> + ;; Get indentation of next line unless at column 0.
> + (let ((ind (if (bolp) 0
> +(save-excursion
> + (org-return-indent)
> + (prog1 (org-get-indentation)
> +(when (and (skip-chars-forward " \t") (eolp))
> + (delete-region beg (point)))
Nitpick
(when (progn (skip-chars-forward " \") (eolp))
...)
since you're not really interested in the return value of
`skip-chars-forward' (which is always non-nil).
> + (bol (and (skip-chars-backward " \t") (bolp
Ditto.
> + ;; Insert a newline before environment unless at column zero
> + ;; to "escape" the current line. Insert a newline if
> + ;; something is one the same line as \end{ENVIRONMENT}.
> + (insert (concat (unless bol "\n")
> + env
> + (and (skip-chars-forward " \t") (not (eolp)) "\n")))
Ditto.
> + (unless (zerop ind)
> + (let* ((element (org-element-at-point))
> + (elm-beg (org-element-property :begin element))
> + (elm-end (copy-marker
> +(save-excursion
> + (goto-char (org-element-property :end element))
> + (skip-chars-backward " \t\n\r")
> + (point)
> + (save-excursion
> + (goto-char elm-beg)
> + (beginning-of-line)
> + (while (<= (point) elm-end)
> + (org-indent-to-column ind)
> + (forward-line)))
> + (set-marker elm-end nil)
I don't think you need `org-element-at-point' at all. You already have
BEG and END markers available. I didn't test it, but this should be
enough to indent the environment.
Also you shouldn't apply `org-indent-to-column' when line is empty.
Regards,
Re: [O] [RFC] Simplify `org-show-context' configuration
Sebastien Vauban writes: > Question: are the level-1 headlines always visible, all of them I mean? > I know that's the case as of now, but wondered if it'd be good to hide > the ones which are not significant. Not a very sharp advice on this, > though. I have no strong opinion about this, but I think it would be odd if they were invisible. After all, this is the basic structure of the document. >> "if required"/"if needed" means the entry will only be shown if point is >> within the entry (i.e., not on the headline). Thus, for example, >> `canonical' and `full' only differ when match is on a headline, since >> only latter will show the entry. >> >> I think this is enough, but I can add more views if needed. >> >> WDYT? > > My /personal/ preference is to see the ancestors, so that I can know > which path lead to the entry, and avoid confusion in case some "sub sub > sections" are repeated in many different "sub sections". > > With your proposal, I then only have the choice between `lineage', > `full' and `canonical', while I'd like something which would give me: > > * H1 * H2 ** Sub 2 *** Sub sub 2 Text > > WDYT? I can add `ancestors' view, which would basically be `lineage' without siblings. Regards,
Re: [O] [RFC] Simplify `org-show-context' configuration
Hello Nicolas, Nicolas Goaziou wrote: > As explained in its commit message, the following patch is an attempt at > simplifying `org-show-context' configuration by offering a set of > 5 predefined views to choose from instead of setting 4 different > variables (`org-show-following-heading', `org-show-siblings', > `org-show-entry-below' and `org-show-hierarchy-above'). These views are > > minimalshow current headline, and entry below if needed > local show current headline, entry below and next headline > lineageshow direct ancestors and all siblings of current headline; > show entry only if required > canonical show direct ancestors and all of their siblings; show entry > only if required > full show direct ancestors, all their siblings and entry > > To sum it up, if original buffer is > > * H1 > * H2 > ** Sub 1 > ** Sub 2 > *** Sub sub 1 > *** Sub sub 2 > Text > *** Sub sub 3 > *** Sub sub 4 > ** Sub 3 > > and match is on "Text", minimal is > > * H1 > * H2 > * Sub sub 2 > Text > > `local' is > > * H1 > * H2 > *** Sub sub 2 > Text > *** Sub sub 3 > > `lineage' is > > * H1 > * H2 > ** Sub 2 > *** Sub sub 1 > *** Sub sub 2 > Text > *** Sub sub 3 > *** Sub sub 4 > > `canonical' and `full' are > > * H1 > * H2 > ** Sub 1 > ** Sub 2 > *** Sub sub 1 > *** Sub sub 2 > Text > *** Sub sub 3 > *** Sub sub 4 > ** Sub 3 > > Note that neither `canonical' nor `full' are possible to obtain with the > 4 original variables. Question: are the level-1 headlines always visible, all of them I mean? I know that's the case as of now, but wondered if it'd be good to hide the ones which are not significant. Not a very sharp advice on this, though. > "if required"/"if needed" means the entry will only be shown if point is > within the entry (i.e., not on the headline). Thus, for example, > `canonical' and `full' only differ when match is on a headline, since > only latter will show the entry. > > I think this is enough, but I can add more views if needed. > > WDYT? My /personal/ preference is to see the ancestors, so that I can know which path lead to the entry, and avoid confusion in case some "sub sub sections" are repeated in many different "sub sections". With your proposal, I then only have the choice between `lineage', `full' and `canonical', while I'd like something which would give me: --8<---cut here---start->8--- * H1 * H2 ** Sub 2 *** Sub sub 2 Text --8<---cut here---end--->8--- WDYT? Best regards, Seb -- Sebastien Vauban
