Re: [O] [patch] extend org-meta-return to keywords
Le 23/11/2014 00:20, Nicolas Goaziou a écrit : M-RET, is, first and foremost, an important keybinding for editing the /structure/ of the document. The behaviour you want to add has nothing to do with structure. I guess this is the main decision point about Rasmus's proposal. I'm not sure I understand the /structure/ argument. (Is structure about hiding blocks? Parsing org docs?). Nicolas, you have worked a lot on this topic (org-element, new drawer syntax). May be you could elaborate on this. As a consequence, I'm not sure it should go with M-RET, and if it does, I'm pretty sure it should not override the main purpose of the binding. Inserting headlines, and possibly items, is much more important than duplicating keywords. We already have M-RET for splitting a table cell (org-table-wrap-region). Should this feature be remapped to some other key-binding? Regards, Thierry
[O] yasnippet and Org-mode: depressing relationship
Hi! If you're using Org-mode together with yasnippet: how do you do it without getting performance issues or expand-key troubles? Background with a specific issue: My yas-specific init-lines: #+BEGIN_EXAMPLE 812:(require 'yasnippet) 813:(setq yas-root-directory ~/.emacs.d/snippets) 814:(yas-load-directory yas-root-directory) 887:(add-hook 'org-mode-hook 'yas-minor-mode-on) 888:(setq yas-indent-line 'fixed) ;; fixes Org-mode issue with yasnippets: https://github.com/capitaomorte/yasnippet/iss #+END_EXAMPLE - Org-mode version 8.3beta (release_8.3beta-544-g77f088) from Git - yasnippet (version 0.8.0beta) (Github) - GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) Issue: Whenever I change table cells via TAB, it takes twelve seconds with 100% CPU core: org-table-next-field very slow: #+BEGIN_EXAMPLE - command-execute 31397 99% - call-interactively 31397 99% - yas-expand 31298 98% - yas--fallback 31298 98% - call-interactively31298 98% - org-cycle31298 98% - call-interactively 31291 98% - org-table-next-field 31291 98% - org-table-align 15676 49% + org-activate-bracket-links 36 0% [...] #+END_EXAMPLE In org-table-next-field I suspect the re-calculation process. And yes, also the simple ~C-c C-c~ on a table takes very long. Even within the primitive table | |. Profiling the re-calculation ends up with: #+BEGIN_EXAMPLE - command-execute 43157 99% - call-interactively 43157 99% - yas-expand31871 73% - yas--fallback31871 73% - call-interactively 31871 73% - org-cycle 31871 73% - call-interactively31864 73% - org-table-next-field 31864 73% - org-table-align 15782 36% - org-activate-bracket-links46 0% [...] #+END_EXAMPLE So I guess that yas-expand has a certain role in this drama. - http://orgmode.org/worg/org-faq.html#YASnippet - Note: yasnippet is not compatible with org-indent-mode currently there is no known way to use both successfully with yas/trigger-key set to TAB (or [tab] etc…) I tried both methods to fix the issue and none had any positive effect on this. Fun fact: my Windows machine (same Emacs config, same Emacs major version) does *not* have this issue! So: how to have both Org-mode and yasnippet? Do I have to switch the trigger key of yasnippet? What trigger key do you use if you also changed it? -- 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
[O] C-c C-c in table takes 12 seconds (was: yasnippet and Org-mode)
Hm. Maybe I wrongly suspected yasnippet: * Karl Voit devn...@karl-voit.at wrote: Background with a specific issue: Issue: Whenever I change table cells via TAB, it takes twelve seconds with 100% CPU core: org-table-next-field very slow: #+BEGIN_EXAMPLE - command-execute 31397 99% - call-interactively 31397 99% - yas-expand 31298 98% - yas--fallback 31298 98% - call-interactively31298 98% - org-cycle31298 98% - call-interactively 31291 98% - org-table-next-field 31291 98% - org-table-align 15676 49% + org-activate-bracket-links 36 0% [...] #+END_EXAMPLE In org-table-next-field I suspect the re-calculation process. And yes, also the simple ~C-c C-c~ on a table takes very long. Even within the primitive table | |. Profiling the re-calculation ends up with: #+BEGIN_EXAMPLE - command-execute 43157 99% - call-interactively 43157 99% - yas-expand31871 73% - yas--fallback31871 73% - call-interactively 31871 73% - org-cycle 31871 73% - call-interactively31864 73% - org-table-next-field 31864 73% - org-table-align 15782 36% - org-activate-bracket-links46 0% [...] #+END_EXAMPLE So I guess that yas-expand has a certain role in this drama. Hm, I have to admit I forgot to test without yas-minor-mode (silly me): #+BEGIN_EXAMPLE - command-execute 10993 99% - call-interactively 10993 99% - org-ctrl-c-ctrl-c 10905 99% org-table-align5450 49% + run-hook-with-args-until-success 6 0% + byte-code 34 0% + minibuffer-complete 26 0% + previous-line 18 0% + execute-extended-command 10 0% + timer-event-handler 6 0% + redisplay_internal (C function) 3 0% + ... 0 0% #+END_EXAMPLE Well, this does not involve yasnippet and also lasts too long :-( How about this? -- 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
[O] Beamer export, file-link format
I'm using org + beamer, and I've put in some links like this:
\href{media/something.mp3}{Listen: Something}
I want Listen: Something to appear in another color. LaTeX is steadfastly
refusing to do this: all links appear in the normal document font and color.
Hyperref is invoked in the preamble like so:
\usepackage{hyperref}
That is, I am not using hidelinks for this presentation.
What do I need to do so that the links stand out in the export?
hjh
[O] Custom export backend based on HTML: how to implement own blocks?
Hello, I'd like to (ab)use the underline syntax for something else. Basically, I'd like to translate _underlined_ to span class=my-ownvariantunderlinedvariant/span and _underlined|with variant_ to span class=my ownvariantunderlined/variantvariantwith variant/variant/span but only if the underlining is between #+BEGIN_MYBLOCK ... #+END_MYBLOCK How to achieve this? In particular, I'd like to know: 1. How can I know (in org-html-underline, for instance) whether I am in a MYBLOCK or not? 2. How do I best translate the | syntax into variants? More specifically: is it a good idea to do it in org-my-html-underline, by analysing the underlined text (as a string) or maybe it's better to write a filter? (I guess the former idea is better.) Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Bug: [Capture] wrongly duplicated date tree outlines [8.2.10]
So sorry to everyone, I just found this is problem is caused by `pangu-spacing'. https://github.com/coldnew/pangu-spacing/issues/5
[O] Export backends are loaded after code block evaluation
Org-mode version 8.3beta (release_8.3beta-584-g3953cb @ /usr/local/share/emacs/site-lisp/org/) GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.4) of 2014-11-17 Hello. Just noticed that after evaluating a code block with C-c C-c (org-babel-execute-src-block?) all export backends stored in 'org-export-backends' are loaded---or 'required'---automatically. Once I commented out my 'org-export-backends' setup those backends weren't loaded, but the default ones did (ascii html icalendar latex). Is this the intended behavior? Tried to grep my way through Org's source files looking for a clue with no success. Also, is there a way to prevent this from happening? It doesn't seem extremely necessary to me.
Re: [O] Export backends are loaded after code block evaluation
Hello, Vicente Vera vicente...@gmail.com writes: Hello. Just noticed that after evaluating a code block with C-c C-c (org-babel-execute-src-block?) all export backends stored in 'org-export-backends' are loaded---or 'required'---automatically. Once I commented out my 'org-export-backends' setup those backends weren't loaded, but the default ones did (ascii html icalendar latex). Is this the intended behavior? `org-babel-execute-src-block' probably requires ox.el or some back-end, triggering. Back-ends are loaded as soon as ox.el is required. Tried to grep my way through Org's source files looking for a clue with no success. Also, is there a way to prevent this from happening? It doesn't seem extremely necessary to me. It doesn't really hurt either. Regards, -- Nicolas Goaziou
Re: [O] [patch] extend org-meta-return to keywords
Hello, Thierry Banel tbanelweb...@free.fr writes: I'm not sure I understand the /structure/ argument. (Is structure about hiding blocks? Parsing org docs?). Nicolas, you have worked a lot on this topic (org-element, new drawer syntax). May be you could elaborate on this. M-RET, C-RET are the major mean to insert headlines (the structure of the document) and items, which are very important features. I'm pretty sure these bindings are in muscle memory of many Org users. Asking them to take into account context before using M-RET is a big downside. I think, on the contrary, that it should do its job without exception. We already have M-RET for splitting a table cell (org-table-wrap-region). Should this feature be remapped to some other key-binding? Binding `org-table-wrap-region' to an important keybinding such as M-RET is wrong IMO. Anyway, that's not the subject here, which is to avoid adding more clutter to M-RET. Let's not make it another C-c C-c. Regards, -- Nicolas Goaziou
Re: [O] C-c C-c in table takes 12 seconds
Hello, Karl Voit devn...@karl-voit.at writes: Issue: Whenever I change table cells via TAB, it takes twelve seconds with 100% CPU core: org-table-next-field very slow: #+BEGIN_EXAMPLE - command-execute 31397 99% - call-interactively 31397 99% - yas-expand 31298 98% - yas--fallback 31298 98% - call-interactively31298 98% - org-cycle31298 98% - call-interactively 31291 98% - org-table-next-field 31291 98% - org-table-align 15676 49% + org-activate-bracket-links 36 0% [...] #+END_EXAMPLE Could you provide an ECM? I'm unable to reproduce it. In fact I remember encountering issues using yasnippet within Org tables, but never related to speed. Regards, -- Nicolas Goaziou
Re: [O] [patch] extend org-meta-return to keywords
Hi, Thanks for the comments. This email is long (sorry); fortunately there are many blank lines. . . Thierry Banel tbanelweb...@free.fr writes: If not, maybe it would be better to keep the oriGiNaL cASe. Yeah, fixed. Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rasmus ras...@gmx.us writes: Moreover, it can get in the way of expected M-RET behaviour, as in the following example - item | #+caption: test untenrsiu I don't know if I should do something about this case. I guess it would be possible, but I find it awkward when behavior $BUTTON depends not only on not only the adjacent element, but also the previous element. If it's important, I guess it should be toggled explicitly on by a custom variable. M-RET, is, first and foremost, an important keybinding for editing the /structure/ of the document. The behaviour you want to add has nothing to do with structure. I see it differently. I see M-RET as a function that magically adds more of what is adjacent to point. I—obviously—think what I propose is better than what we have now. Let's go through the current functionality. * Example 1: #+LATEX_HEADER: foo Click M-RET anywhere above (line-beginning-position) and you get something like #+LATEX * _HEADER: foo This is nonsense. Click M-RET at (line-beginning-position) and you get * #+LATEX_HEADER: foo This is nonsense. * Example 2 - s #+LATEX_HEADER: foo % no space between ^ and #. Same as example 2. * Next case - s #+LATEX_HEADER: foo % space between ^ and # M-RET at a position greater than (line-beginning-position) yields something like - s #+LATEX - _HEADER: tes This is nonsense. M-RET at (line-beginning-position) will yield - s - | ← that's point #+LATEX_HEADER: foo % space between ^ and # Thus far this is the only sensible result that we'd loose with the patch. If this is a great loss (rather than a bug in the current implementation) this can be dealt with, though it adds complexity to the meaning of M-RET (since it's a function of the previous element rather than the adjacent one). * Example 4 - s #+LATEX_HEADER: foo % three spaces This works like example 1. As a consequence, I'm not sure it should go with M-RET, and if it does, I'm pretty sure it should not override the main purpose of the binding. Inserting headlines, and possibly items, is much more important than duplicating keywords. IMO the examples above show that M-RET fails at doing this in a sensible manner is all but one case above. The case where it does not fail requires (i) that the keyword is not at the beginning of the line and (ii) that the use has point before the keyword. I don't care strongly about this feature—It's just check that point is not at bol in `org-meta-return'. In fact I would be happy to go further. One also get nonsense result doing M-RET on #+begin_src lines and probably elsewhere. Also, `org-insert-keyword' is not really using org-element anymore. It should since you make it interactive and can, therefore, be called on its own. I moved the check to a separate function, `org-looking-at-repeatable-keyword-p'. There are now the following issues: 1. it's called twice: once in org-meta-return and once in org-insert-keyword. I'm not sure if it's possible to emit a signal to avoid the second check somehow... Perhaps the performance-loss is such that we should not worry about it. 2. The name is terrible. I'm also not sure if this function should reside in org.el. Same for the regexp. Thoughts? Some comments follow: Thanks for these! + (indention + (buffer-substring + (line-beginning-position) + (save-excursion + (beginning-of-line) + (skip-chars-forward \t) + (point Another option: (ind (org-get-indentation)) Cool. I really need to internalize to look for org-prefixed functions! + (keyword-re #\\+\\(.+?\\):) + (key (save-excursion (beginning-of-line) + (skip-chars-forward \t) + (looking-at keyword-re) + (upcase (org-match-string-no-properties 1 As discussed above, this is too fragile. You need to duplicate the checks done in `org-meta-return' or refactor the code. Yeah, I see your point. Casual testing suggest it's more solid now albeit there's now the double check as outlined above. + (end-of-keyword (save-excursion + (beginning-of-line) + (re-search-forward keyword-re (line-end-position) t) + (point (end-of-keyword (save-excursion (beginning-of-line) (search-forward :)) [...] I think end-of-keyword should be bound after KEY is checked to avoid errors. Since there's now a check before entering the function I guess this should be safe. Still I added extra checks, that I'm pretty sure are unnecessary. I'd be happy to remove these. —Rasmus -- Don't
Re: [O] [patch] extend org-meta-return to keywords
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Thierry Banel tbanelweb...@free.fr writes: I'm not sure I understand the /structure/ argument. (Is structure about hiding blocks? Parsing org docs?). Nicolas, you have worked a lot on this topic (org-element, new drawer syntax). May be you could elaborate on this. M-RET, C-RET are the major mean to insert headlines (the structure of the document) and items, which are very important features. I'm pretty sure these bindings are in muscle memory of many Org users. Asking them to take into account context before using M-RET is a big downside. I think, on the contrary, that it should do its job without exception. I don't find it complicated at all. . . It's DWIM! We already have M-RET for splitting a table cell (org-table-wrap-region). Should this feature be remapped to some other key-binding? Binding `org-table-wrap-region' to an important keybinding such as M-RET is wrong IMO. Anyway, that's not the subject here, which is to avoid adding more clutter to M-RET. Let's not make it another C-c C-c. The fact that `org-table-wrap-region' is bound to M-RET is the reason I'd bind `org-insert-keyword' to M-RET. . . Anyway, do we have /another/ key that these two functions could be migrated to? Cheers, Rasmus -- And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [O] C-c C-c in table takes 12 seconds
* Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Hello, Hi! Could you provide an ECM? I'm unable to reproduce it. Yeah, I can do that. However, because I never did this before and I suppose this is going to take me at least two hours, I will post it whenever I got time to do the ECM. Is this correct that for an ECM I have to provide a complete (minimal) init.el and Org-mode files? -- 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] Custom export backend based on HTML: how to implement own blocks?
Hi Marcin, Marcin Borkowski mb...@wmi.amu.edu.pl writes: 1. How can I know (in org-html-underline, for instance) whether I am in a MYBLOCK or not? I don't know whether this is the best approach, but given an element, you can walk up its parents in the parse tree until you either reach a MYBLOCK (in which case, you are in such a block) or the top of the tree (in which case, you aren't). Here's an approach I use in a custom backend[1] to do something similar. The following function is used to identify paragraphs (or other elements) that are within lists which have an #+ATTR_LINGUISTICS declaration specifying a :package property. (Because it recursively walks up the parse tree, this works even for paragraphs in arbitrarily-nested sublists.) #+BEGIN_SRC emacs-lisp (defun org-linguistics-find-enclosing-pkg (element) Find the enclosing linguistics package of a (list) element during export. (let ((pkg (org-export-read-attribute :attr_linguistics element :package)) (parent (org-export-get-parent element))) (cond ; return if we found a :package attribute on element (pkg pkg) ; recurse on the parent if element has a parent but we found no ; :package attribute (parent (org-linguistics-find-enclosing-pkg parent)) ; otherwise, no :package attribute was found (t nil #+END_SRC (In your case, a similar function might only need to return a boolean value that indicates whether an element is inside a MYBLOCK, rather than returning a string, as this function does.) Then, in other code, I can treat paragraphs differentially based on whether they are in a list with this :package attribute set, e.g. #+BEGIN_SRC emacs-lisp (defun some-function-that-handles-paragraphs (paragraph) (let* ((enclosing-pkg (org-linguistics-find-enclosing-pkg paragraph)) ; ... ) ; (cond ((string= enclosing-pkg gb4e) ; do something for paragraphs in lists with :package gb4e ... ) ((string= enclosing-pkg linguex) ; do something for paragraphs in lists with :package linguex ... ) (t ; do a default thing for paragraphs that are not in such lists #+END_SRC Hope that's helpful! Best, Richard [1] The backend is ox-linguistics, a package for writing linguistics-style examples in Org: https://github.com/wyleyr/ox-linguistics
Re: [O] [patch] extend org-meta-return to keywords
Rasmus ras...@gmx.us writes: I see it differently. I see M-RET as a function that magically adds more of what is adjacent to point. Your definition is fuzzy: * Headline [lots of text] -- M-RET here will insert a headline, which is by no mean adjacent to point. I—obviously—think what I propose is better than what we have now. Let's go through the current functionality. In this case I value simplicity over complexity (or smartness, whatever you call it). Anyone, including newcomers, should be able to use M-RET without knowing about (affiliated) keywords, or be bothered with them. IMO, it /is/ sensible to insert a headline (or an item) without trying to outsmart the user. Also, headlines are first-class citizens in Org. Keybindings acting on them shouldn't be bothered with other citizens. Regards,
Re: [O] [patch] extend org-meta-return to keywords
Rasmus ras...@gmx.us writes: I don't find it complicated at all. . . It's DWIM! I understand your DWIM argument. But we're talking about one of the most central keybindings in Org, much like C-c C-c. Except I do not consider C-c C-c as a usability model. Also, C-c C-c is not really dedicated to headlines. The fact that `org-table-wrap-region' is bound to M-RET is the reason I'd bind `org-insert-keyword' to M-RET. . . I really don't understand the reason behind binding `org-table-wrap-region' (how often do you use that?) on M-RET. Anyway, do we have /another/ key that these two functions could be migrated to? There is `org-table-copy-down' bound to S-RET. The idea is similar. Regards,
Re: [O] Check for compilation error
Hi Achim On Sat, Nov 22, 2014 at 12:30 PM, Achim Gratz strom...@nexgo.de wrote: Michael Brand writes: What is the reason that make check does not stop at the first compilation error with a non-zero exit status? Emacs doesn't behave like a compiler ... when used as [...] --batch --eval '(batch-byte-recompile-directory 0)' But as [...] --batch --eval '(batch-byte-compile)' `find . -name '*.el'` the non-zero exit status is available. Could make check use this to indicate a compilation error? Alternatively of help may be a new optional parameter for byte-recompile-directory to return its fail-count instead of nothing useful as now and batch-byte-recompile-directory would then also on request use it for (kill-emacs fail-count) instead of only the current undifferentiated (kill-emacs 0). Michael
Re: [O] C-c C-c in table takes 12 seconds
Hello, Rasmus ras...@gmx.us writes: When looking at the profiler, I notice avl-tree--do-delete (and other avl functions) and org-element--cache-compare taking lots of speed. I think I have also had this issues in mail-buffers where I use orgstruct modes. Again org-element--cache showed up. It means the cache is corrupted. Alas, it doesn't explain how it get into that state. Attached is a backtrace from yesterday where I had to stop Emacs with kill -usr2. The file I was working on has many tables with conjugations of words and some entities. Unfortunately, a backtrace isn't helpful in this case. I'd rather have a relatively small Org document where the problem is guaranteed to occur, and a bunch of commands possibly triggering it. Regards, -- Nicolas Goaziou
Re: [O] [patch] extend org-meta-return to keywords
Hi,
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
I—obviously—think what I propose is better than what we have now. Let's
go through the current functionality.
In this case I value simplicity over complexity (or smartness,
whatever you call it). Anyone, including newcomers, should be able to
use M-RET without knowing about (affiliated) keywords, or be bothered
with them.
Newcomers ain't stupid. My guess is it would feel very intuitive to
be able to repeat e.g. LATEX_HEADINGs.
Also, headlines are first-class citizens in Org. Keybindings acting on
them shouldn't be bothered with other citizens.
But * #+LATEX_HEADER: \usepackage{foo} or whatever is possibly the
most useless headline in the history of Org. . .
I don't find it complicated at all. . . It's DWIM!
I understand your DWIM argument. But we're talking about one of the most
central keybindings in Org, much like C-c C-c. Except I do not consider
C-c C-c as a usability model. Also, C-c C-c is not really dedicated to
headlines.
I guess I mainly use C-c C-c for tags. I don't know what else it's used
for (without looking at the code). . .
The fact that `org-table-wrap-region' is bound to M-RET is the reason
I'd bind `org-insert-keyword' to M-RET. . .
I really don't understand the reason behind binding
`org-table-wrap-region'
(how often do you use that?) on M-RET.
Very rarely. I obviously use M-RET all the time for items and
headlines. `org-table-wrap-region' seems like a solution looking for a
problem.
Anyway, do we have /another/ key that these two functions could be
migrated to?
There is `org-table-copy-down' bound to S-RET. The idea is similar.
That seems less crowded. In fact it doesn't work outside of tables ATM.
Still, I think overload M-RET is more intuitive, but I fear our opinions
will fail to converge.
—Rasmus
--
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio
Re: [O] Patch org-capture-set-target-location
Hello, Roberto Huelga rhue...@gmail.com writes: Patch proposal for org-capture-set-target-location Thanks for the patch. The idea is that when somebody use the function or file+function targets you can make the template subheading from the heading where the custom-function set the point. org-capture-set-target-loction force the org-capture-plist :exact-position to (point). So the template is inserted in the same level not as subheading With my patch the custom-function can (org-capture-put :exact-position nil), and now if point its placed in a heading the template is created as his subheading. AFAIU, :exact-position is an internal property (it isn't documented in (info (org) Template elements). You are not expected to set it directly. After a cursory look into org-capture.el, if (point) is on a headline, the template should create a subheading (see `org-capture-place-entry'). Can't you use that instead? Regards, -- Nicolas Goaziou
Re: [O] C-c C-c in table takes 12 seconds
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rasmus ras...@gmx.us writes: When looking at the profiler, I notice avl-tree--do-delete (and other avl functions) and org-element--cache-compare taking lots of speed. I think I have also had this issues in mail-buffers where I use orgstruct modes. Again org-element--cache showed up. It means the cache is corrupted. Alas, it doesn't explain how it get into that state. Is there a way to reset the cache? To get out of the bad state. Attached is a backtrace from yesterday where I had to stop Emacs with kill -usr2. The file I was working on has many tables with conjugations of words and some entities. Unfortunately, a backtrace isn't helpful in this case. I'd rather have a relatively small Org document where the problem is guaranteed to occur, and a bunch of commands possibly triggering it. I'm have still not found a consistent receipt to reproduce this state. . . Today I have been editing the same file without expiring issues. —Rasmus -- C is for Cookie
Re: [O] C-c C-c in table takes 12 seconds
Rasmus ras...@gmx.us writes: Is there a way to reset the cache? To get out of the bad state. M-x org-element-cache-reset Regards,
Re: [O] Bernt Hansen's
rene jl...@yahoo.com writes: I wonder whether Bernt would agree to turn his config file into an actual lisp package that could be available via Elpa? I find his code pretty close to what GTD should look like. There are a few things though that could be twicked a bit in order to comply with David Allen's new book on Getting Things Done. I will try to contact Bernt and ask him to deliver such an org-gtd.el package. That would be great for the orgmode community. Hi Rene, I don't have time to maintain an Elpa package of this stuff currently. This past Friday I just did a 'catch up' in gnus on this mailing list and skipped 8600+ unread articles (including this one) due to lack of available time. Thanks for the email in private that brought this thread to my attention. It should be possible to extract the lisp from my document (http://doc.norang.ca/org-mode.org) and generate a lisp file with C-c C-v C-t. This is described at the end of http://doc.norang.ca/org-mode#HowToUseThisDocument From there you can edit whatever you need to for your settings. I personally don't want to conform strictly to David Allen's idea of how GTD should work. I like to roll-my-own way of doing things and if an Elpa packaging of this code would require learning and modifying the workflows to match David Allen's latest book I simply don't have time for that undertaking. Someone else is welcome to take that on if they are interested. I just discovered late last week that one of my settings relies on a feature of the org-mode master branch (and has for over a year) and this change has not been included in any maintenance release of org-mode. Lots of people have contacted me about the breaking signature change in org-remove-drawer-at which is posted in my config since I use the master branch of org-mode. I think most people will be using official released versions of org-mode so I'm not sure how best to handle this issue until Org 8.3 is released which is supposed to include this signature change. I will probably just document the signature change and provide alternative code to use in the extracted version for maintenance releases until 8.3 is created. Best Regards, Bernt
Re: [O] Missing commit in maint
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Bernt Hansen be...@norang.ca writes: The following commit 6202ec7 (Remove need to declare drawers before using them, 2013-10-20) has been in the master branch for over a year but I can't find it in any maintenance releases since then. Is this intentional? It is. This is a breaking change, so it is installed in master instead of maint. I am using the function (defun org-remove-empty-drawer-at (pos) in my .emacs setup and this changed signature in the above commit in the master branch only a year ago. Is this commit supposed to be applied to maint? Yes, when Org 8.3 is released. Thanks for the explanation :) I will update my document to add an explanation for this until Org 8.3 is released. Best regards, Bernt
Re: [O] C-c C-c in table takes 12 seconds
Karl Voit devn...@karl-voit.at writes: * Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Hello, Hi! Could you provide an ECM? I'm unable to reproduce it. Yeah, I can do that. However, because I never did this before and I suppose this is going to take me at least two hours, I will post it whenever I got time to do the ECM. Is this correct that for an ECM I have to provide a complete (minimal) init.el and Org-mode files? Hi Karl, In case it is useful here is what I use for ECMs (I haven't done one in well over a year though) This is on my Linux system: Shell script to start emacs with a minimal setup ,[ minimal-emacs ] | #!/bin/sh | TESTEL= | TESTFILE=/tmp/test.el | if test -e $TESTFILE | then | TESTEL=-l /tmp/test.el | fi | emacs -q -l ~/minimal.emacs $TESTEL $1 ` Minimal .emacs file to enable org-mode from git ,[ minimal.emacs ] | (add-to-list 'load-path ~/git/org-mode/lisp/) | ;(add-to-list 'load-path (expand-file-name ~/git/org-mode/lisp)) | (add-to-list 'auto-mode-alist '(\\.\\(org\\|org_archive\\|txt\\)$ . org-mode)) | (require 'org) | | (global-set-key \C-cl 'org-store-link) | (global-set-key \C-ca 'org-agenda) | (global-set-key \C-cb 'org-iswitchb) ` I put test settings that show the problem in /tmp/test.el which is automatically included when I run 'minimal-emacs'. Hope that helps. Regards, Bernt
Re: [O] Custom export backend based on HTML: how to implement own blocks?
Marcin Borkowski mbork at wmi.amu.edu.pl writes: Hello, I'd like to (ab)use the underline syntax for something else. Basically, I'd like to translate _underlined_ to span class=my-ownvariantunderlinedvariant/span and _underlined|with variant_ to span class=my ownvariantunderlined/variantvariantwith variant/variant/span but only if the underlining is between #+BEGIN_MYBLOCK ... #+END_MYBLOCK How to achieve this? In particular, I'd like to know: 1. How can I know (in org-html-underline, for instance) whether I am in a MYBLOCK or not? You do not need to know this directly. See below: 2. How do I best translate the | syntax into variants? More specifically: is it a good idea to do it in org-my-html-underline, by analysing the underlined text (as a string) or maybe it's better to write a filter? (I guess the former idea is better.) Define two derived backends: backend 1) Use 'html as the parent. Add 'MYBLOCK' to the `:export-block' list and define your own `org-backend1-export-block' transcoder with a fallback to the parent backend for HTML blocks. You will have access to the :value of MYBLOCK as a string. You can use `org-export-string-as' to process that value according to an arbitrary backend - in this case you use `backend2'. backend 2) Use html as the parent of this backend and define `org-backend2-underline' to use the rules you outline above. You can parse the `contents' arg for the `|' etc. There might be a case for making `backend2' anonymous since you only replace one transcoder of the parent. There is an example in ` org-html--format-toc-headline'. HTH, Chuck
Re: [O] Code, Sessions, and org-edit-special
* On 2014-11-22 at 19:17, Ken Mankoff wrote: Hi List, A simpler phrasing of my previous question. How do I find out if an Org function, `org-ctrl-c-ctrl-c`, was called somewhere up the stack. I'm trying to modify a function python-shell-get-process-name, but I don't want it to be modified when somewhere, possibly far upstream, Org is happening. (equal this-command 'org-ctrl-c-ctrl-c) Tells me if a function is in a call stack initiated by C-c C-c from Org. I now have Org behaving as it always has with un-named sessions or named sessions. Importantly, something Org was lacking, I can edit a file via C-' (org-edit-special), and when I execute the code from there, which is not part of Org, I can send it to the named session, rather than to the standard executable as before. If anyone wants this feature for Python let me know and I can share the code. -k.
Re: [O] [patch] extend org-meta-return to keywords
Rasmus ras...@gmx.us writes:
Newcomers ain't stupid.
I never said that.
However, here is an historical data point. SCHEDULED, DEADLINE and
CLOSED keywords, aka planning info, are not included as properties in
properties drawer so newcomers do not encounter invisible contents for
such basic tasks.
This is the same logic here.
My guess is it would feel very intuitive to be able to repeat e.g.
LATEX_HEADINGs.
M-RET is a good fit for almost anything. That's all the problem.
As far as UI goes, I think we should prevent some keybindings from being
context sensitive. This is particularly true for those related to core
features (outliner, agenda, TODO list). Why ? Because basic Org features
should ideally be very simple to use.
Org is mostly geared towards power users. The feature you're
implementing is also for power users. However, /any/ user should be
able to master the core features in 5 minutes.
But * #+LATEX_HEADER: \usepackage{foo} or whatever is possibly the
most useless headline in the history of Org. . .
Who knows? It depends on the context, on the next commands (e.g. C-o)...
Hitting B key at
#+|LATEX_HEADER: \usepackage{foo}
is as useless. Nevertheless, I suppose you don't want to bind B key to
something else than `org-self-insert-command' here.
Still, I think overload M-RET is more intuitive,
Intuitiveness is in the eye of the beholder... Maybe some users will
not find intuitive that M-RET usually inserts a headline... unless it is
in a plain list, in which case it inserts an item... oh wait, if it is
at a keyword it can duplicate it... but, wait, it doesn't happen for
every keyword... ah! and in source blocks it...
but I fear our opinions will fail to converge.
If you want to convince me, show me that this binding makes Org simpler
to use, or, at least, equally simple. Until then, I stand on my ground.
Regards,
[O] #+BIBLIOGRAPHY multiple entries
I am trying to figure out how to use multipe bibliography files in org-mode. What I've used so far is the #+BIBLIOGRAPHY statement which lets me enter one .bib file, but I have been unable to use more than one file. How would one go about to achieve this? I use #+BIBLIOGRAPHY mybibliographyfile plain which works, but #+BIBLIOGRAPHY myfirstbibliographyfile mysecondbibliographyfile plain does not. Cheers, Johnny
Re: [O] [patch] extend org-meta-return to keywords
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Still, I think overload M-RET is more intuitive, Intuitiveness is in the eye of the beholder... Clearly. Maybe some users will not find intuitive that M-RET usually inserts a headline... unless it is in a plain list, in which case it inserts an item... oh wait, if it is at a keyword it can duplicate it... but, wait, it doesn't happen for every keyword... ah! and in source blocks it... Not to forget tables. . . but I fear our opinions will fail to converge. If you want to convince me, show me that this binding makes Org simpler to use, or, at least, equally simple. Until then, I stand on my ground. This is a Sisyphean task. Even if a number of participants of this ML would chime in, we would still not know whether it would confuse or benefit new users. From my point of view, we can make every function tied to M-RET beyond `org-insert-headline' configurable and turned off by default. This may, however, also add confusion (why did M-RET work in X's Org but not in mine...). At this point, I doubt I can add novel, useful inputs to the discussion. Cheers, Rasmus -- And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [O] #+BIBLIOGRAPHY multiple entries
Hi Johnny,
On 24 November 2014 at 08:08, yggdra...@gmx.co.uk wrote:
I use
#+BIBLIOGRAPHY mybibliographyfile plain
which works, but
#+BIBLIOGRAPHY myfirstbibliographyfile mysecondbibliographyfile plain
does not.
Instead of #+BIBLIOGRAPHY I tend to use
#+LATEX: \bibliographystyle{plainnat}
#+LATEX: \bibliography{C:/Users/andreas/Dropbox/_biblio/refs}
were all my bibtex entries are in refs.bib. I keep everything in the one
place and hence need to use the full path.
You can put these where you want the bibliography placed and you can
include multiple files in LaTeX' \bibliography{} command.
In your case I imagine it would look something like this.
#+LATEX: \bibliographystyle{plainnat}
#+LATEX: \bibliography{C:/Users/andreas/Dropbox/_biblio/refs}
HTH.
Cheers,
Andreas
[O] Modifications in org-src.el
Hello, In an attempt to unify various external editing functions (`org-edit-fixed-width', `org-edit-src-code'...), I widely modified org-src.el. These changes are mostly internal and no user-visible change (besides bug fixes) is expected. However I removed some functions, not used in the code base, and changed a few signatures (`org-edit-src-code' and `org-edit-src-exit'). I also added export block sub-editing. Please report anything suspicious in this area. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] Modifications in org-src.el
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: In an attempt to unify various external editing functions (`org-edit-fixed-width', `org-edit-src-code'...), I widely modified org-src.el. These changes are mostly internal and no user-visible change (besides bug fixes) is expected. However I removed some functions, not used in the code base, and changed a few signatures (`org-edit-src-code' and `org-edit-src-exit'). I also added export block sub-editing. Cool! Please report anything suspicious in this area. I don't know if this is a bug, but when I open Emacs and open a buffer without (require 'ox) first, org-element will not recognize export-blocks. —Rasmus -- Hooray!
