Re: [O] sitemap seems to cache old #+TITLE
On 19.3.2011, at 04:13, lbml...@hethcote.com wrote: On Fri, 18 Mar 2011, Nick Dokos wrote: Do you have a :sitemap-title entry in your config? Better yet, if there are no privacy concernts, why don't you post your publishing configuration? Nick From my .emacs: (setq org-publish-project-alist '((org-notes :base-directory /home/lbmoore/notebook/org/ :publishing-directory /home/lbmoore/public_html/org/ :base-extension org :recursive t :style link rel=\stylesheet\ href=\css/org-a.css\ type=\text/css\/ :link-home http://caritas/; :makeindex t ) (tchkb :base-directory /home/lbmoore/notebook/tchkb/ :publishing-directory /home/lbmoore/public_html/tchkb/ :base-extension org :recursive t :auto-sitemap t :style link rel=\stylesheet\ href=\css/org-a.css\ type=\text/css\/ :link-home http://caritas/; :makeindex t ) (org-static :base-directory /home/lbmoore/notebook/org/ :base-extension css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf :publishing-directory /home/lbmoore/public_html/org/ :recursive t :publishing-function org-publish-attachment ) (org-static-kb :base-directory /home/lbmoore/notebook/tchkb/ :base-extension css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf :publishing-directory /home/lbmoore/public_html/tchkb/ :recursive t :publishing-function org-publish-attachment ) (org :components (org-notes org-static tchkb org-static-kb)) )) when I cp the .org files and the .emacs to another machine it generates fine which make me think that there is a cache or tmp file somewhere that holds the original title. Have you tried forcing republishing of all files by using a C-u prefix to your publishing command? - Carsten
Re: [O] [dev] org-indent-mode patch
Hello, On Mon, Mar 14, 2011 at 08:51:27AM +0100, Carsten Dominik wrote: Hi Nicolas, On 13.3.2011, at 17:21, Nicolas wrote: Hello, I'd like to submit the following org-indent-mode patch for testing. git://github.com/ngz/org-mode-lists.git indent-patch-no-timer It implements two things: 1. It indents correctly text when using visual-line-mode; 2. It removes the idle timer previous implementation was using, which means it won't refresh indentation more often than necessary. Unfortunately, there is a price to pay: 1. Initialization will be much longer for large Org files, but I've added a message to the user saying so. 2. It is a bit slower, as the algorithm has more things to check. Last point is obviously my main concern. Although not noticeable on my not-so-recent laptop, I don't know how it behaves on old machines. That's why a testing is necessary to determine (bugs and) if it is usable. Any help welcome. initial testing seems to show that this works well, very nice. The delay at the beginning is long, and it might be annoying when org pulls in a buffer just to look something up, without org-inhibit-startup scoped into the file loading. Maybe one could arrange for the initialization to happen just before the buffer is first *displayed* (I do not know if that is possible). From my tests, the delay at the beginning is only long for a file with unreasonably long lists. I tested a sample file with 1000 lists each with 1140 characters and it took me roughly 12 seconds on an Intel Q6600 2.4Ghz. On the other hand, 1000 lists with 304 characters took me a little over 3 seconds. Lastly, 1000 lists with only 102 characters each took me just over a second. So, I think the startup delay is very reasonable, since only very long list lines slow down the startup time, and such list items are almost always rarer than shorter list items. Just one nitpicking: The idle timer may force updating when not necessary - but using after-change-functions will update after each character inserted. So in fact your code might be updating more often at least while typing - maybe not while looking at the buffer and jumping around. I am not a fast typist, but maybe fast typists will notice significant delays, in particular while writing inside a very long section? In my 1000 list (1140-characters per list) file, I smashed my keys as fast as I could inside one of those lists, and there was no slowdown at all. The only time there was a slowdown was when I held down a key to let it repeat (although I have an unusually fast key repeat rate on my keyboard --- I have xset r rate 250 80 in my ~/.xinitrc). According to the xset man page this means 80 characters per second. -Linus
Re: [O] org-insert-link-global vs. org-insert-link
On 19.3.2011, at 03:10, bozo...@gmx.de wrote: Hi, I have just, as suggested in http://orgmode.org/manual/Using-links-outside-Org.html, added a new keybinding for org-insert-link-global. However, it seems like in org files this seems to just fall back to org-insert-link. Does that mean that I can safely rebind C-c C-l to org-insert-link-global I think so. Cheers - Carsten instead of having to distinguish between the two variants? Cheers, michael
Re: [O] C-0 C-c | throws emacs into infinite loop
On 18.3.2011, at 15:29, Le Wang wrote: The doc-string of `org-table-convert-region' doesn't specifically address 0 as SEPARATOR, but 0 is an integer. It shouldn't hang in any case. When I C-g out of the loop, my undo limit was exceeded because the line filled with hundreds of thousands of empty cells. I think the correct behavior is to convert region into table using 0 spaces as a separator -- so each character forms its own column. While this might be nice, it is such a border case that, for now, I have only added an error message to prevent the converter from going into an infinite loop. Or do you have a *really* goo use case for this? - Carsten
Re: [O] Custom Agenda View for Projects
2011/3/18 Josh Berry d...@condordes.net: On Fri, Mar 18, 2011 at 10:57, Jason McBrayer jmcb...@carcosa.net wrote: On Thu, Mar 17, 2011 at 6:55 PM, Josh Berry d...@condordes.net wrote: I think org considers child tasks to be dependencies of the parent task -- so if a parent task (such as your PROJ) has children, it won't be displayed in a tags-todo agenda view, because that takes dependencies into account. That's a logical explanation, but shouldn't this only be the case if the parent has the :ORDERED: property set? No, if :ORDERED: is set, then each child is a dependency of the next child. So if you have: * TODO top ... :ORDERED: t ... ** TODO a ** TODO b ** TODO c Only a will appear in your agenda view. But if you have: * TODO top ** TODO a ** TODO b ** TODO c All children of top--that is, a, b and c--will appear. However, in neither case will top appear, because it has children that are not yet completed. Have you tried just a tags view with a match of TODO=\PROJ\? IIRC this will do what you want. I gave this a test, and apparently it does not. What's shown is still dependent on the value of org-enforce-todo-dependencies. I see, it does not, my bad. I tried experimenting a bit on my own, and didn't find an easy way using just agendas. You might consider experimenting with Stuck Projects though. If you consider all projects to be stuck, you could probably build an agenda view that shows you all projects regardless of what's in them. (I don't use stuck projects myself, so YMMV.) -- Josh Dear Josh, dear Jason, thanks a lot for evaluating the options! That makes things a lot clearer for me, and for the moment I'll stick with org-enforce-todo-dependencies nil. Cheers, Christian
Re: [O] Re: Merging .org files
On Sat, Mar 19, 2011 at 02:08, Matt Lundin m...@imapmail.org wrote: Pere Quintana Seguí pquint...@obsebre.es writes: Now I have to learn to better navigate within my much longer org files. Before, I used ido-mode to jump from buffer to buffer, now I guess I have to practise more sparse trees to jump from headline to headline. I use this function to jump quickly (via ido) to a first level headline in my org files: [snip] Do you normally have ‘org-completion-use-ido’ turned off or something? (Just wondering why you couldn’t use ‘org-refile’ directly.) Aankhen
[O] Re: org-src-fontify-natively makes things very, very slow
Hi Eric,
Eric S Fraga wrote:
Sébastien Vauban wxhgmqzgw...@spammotel.com writes:
Maybe this is (partly?) due to the overlay I added:
#+begin_src emacs-lisp
(overlay-put (make-overlay beg1 block-end)
'face 'org-block-background))
#+end_src
This could indeed be one cause, especially depending on what this does when
there is no block-end line, or at least not anywhere near in the buffer. I
seem to get a slowdown when I have a situation like this:
#+begin_example
[... some text ...]
#+begin_src somelanguage
[... text which is part of the source block...]
point here
[... lots of other text ...]
[... including other source blocks]
#+end_example
where there is no matching #+end_src or, more precisely, the next #+end_src
line is one that does not belong to this current source block. Your search
(in org.el) for the end of the block assumes that it does have the end
statement in place already. I'm not sure how to fix this because it's an
ill-defined situation.
You say your search... but I only added the overlay-put command... and I
must admit this whole block is difficult to follow (so many cases).
It may be worthwhile making the overlay optional? Although I must admit that
I like it!
I simply can't live without it, either.
My solution, by the way, is to insert the #+end_src line immediately upon
writing a #+begin_src line and then back up a line to start writing the
code.
My solution is even simpler: just use a yasnippet template, that prompts you
for the language and puts the begin/end upfront:
--8---cut here---start-8---
#name : #+begin_src...#+end_src
# --
#+srcname: ${1:name}
#+begin_src ${2:language} $3
$0
#+end_src
--8---cut here---end---8---
Best regards,
Seb
--
Sébastien Vauban
Re: [O] C-0 C-c | throws emacs into infinite loop
On Sat, Mar 19, 2011 at 2:43 PM, Carsten Dominik carsten.domi...@gmail.comwrote: On 18.3.2011, at 15:29, Le Wang wrote: The doc-string of `org-table-convert-region' doesn't specifically address 0 as SEPARATOR, but 0 is an integer. It shouldn't hang in any case. When I C-g out of the loop, my undo limit was exceeded because the line filled with hundreds of thousands of empty cells. I think the correct behavior is to convert region into table using 0 spaces as a separator -- so each character forms its own column. While this might be nice, it is such a border case that, for now, I have only added an error message to prevent the converter from going into an infinite loop. Or do you have a *really* goo use case for this? No, I don't have a use case for this. IMO, a reasonable argument should result in some reasonable non-surprising behaviour. We can argue whether 0 is a reasonable argument, though. I'm okay as long as it doesn't hang. - Carsten -- Le
Re: [O] Re: Problem with agenda and diary
Padawan, Julien Danjou jul...@danjou.info writes: Kids, look at the `message-subscribed-*' variables to configure this at home. I use (setq nnmail-treat-duplicates 'delete) so I don't need to mess around with `message-subscribed-*' variables manually to avoid receiving duplicates. It's confusing not to see your email address when doing a wide reply, as Nick and I found out. It's okay now that we know it, but nobody can guess what is the value of your `message-subscribed-*'. :) -- Bastien
Re: [O] Re: Problem with agenda and diary
Padawan, Julien Danjou jul...@danjou.info writes: Kids, look at the `message-subscribed-*' variables to configure this at home. I use (setq nnmail-treat-duplicates 'delete) so I don't need to mess around with `message-subscribed-*' variables manually to avoid receiving duplicates. It's confusing not to see your email address when doing a wide reply, as Nick and I found out. It's okay now that we know it, but nobody can guess what is the value of your `message-subscribed-*'. :) -- Bastien
[O] Re: [Bug] MCE for HTML test of export
Hi Nicolas,
Nicolas wrote:
Sébastien Vauban wxhgmqzgw...@spammotel.com writes:
Regarding this problem only, it must be an interaction then with my
following setting for the inline task in HTML:
#+begin_src emacs-lisp
;; templates for inline tasks in various exporters
(setq org-inlinetask-export-templates
'((html pre class=\inlinetask\b%s%s/bbr%s/pre
'((unless (eq todo )
(format span class=\%s %s\%s%s/span
class todo todo priority))
heading content))
(latex \\todo[inline]{\\textbf{\\textsf{%s
%s}}\\linebreak{} %s}
'((unless (eq todo )
(format \\textsc{%s%s} todo priority))
heading content))
(ascii -- %s%s%s
'((unless (eq todo )
(format %s%s todo priority))
heading
(unless (eq content )
(format \n ¦ %s
(mapconcat 'identity
(org-split-string content
\n)
\n ¦ )))
#+end_src
Indeed, it came from your templates. To prevent this, I made sure, with the
following patch, that CONTENT is always enclosed by newline characters.
Would you mind testing it before I apply it ?
Perfect. Works like a charm. Please do apply it...
Also, you may have a look at default templates, as your HTML variant is
slightly wrong (wrt br tag).
I'm not sure to understand what's wrong. You mean the fact I added manually
a br tag after the title?
If yes, it was to have the title line (task subject, with TODO keyword) on
its own line, followed by the rest of the entry on subsquent paragraphs.
But, indeed (after testing it), it seems I am not (anymore?) forced to insert
that. Was it this you were talking about?
Thanks for the comment, anyway... and for the patch!
Best regards,
Seb
--
Sébastien Vauban
Re: [O] gnowsys-mode update?
On Fri, Mar 18, 2011 at 8:25 PM, Martin Weigele mar...@weigele.de wrote: Hi all, I've run into some texts about gnowsys as a major mode extending org, e.g. - http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-514/paper12.pdf - http://lab.gnowledge.org/documentation which seems to be about linking org-mode to semantic web ideas like OWL. But it seems also there is nothing much to be found after 2009. Is this still an active thing going on on top of orgmode? yes. we still maintain it and runs well on top of and depends on orgmode. If not what happened to it? Any hints greatly appreciated. Yes. We use the gnowsys-mode interface for sites running using gnowsys. So far this is the only complete interface for gnowsys. Mostly used by the developers and those who maintain the sites, such as atlas.gnowledge.org Currently we are exporting the knowledge base only as RDF statements. OWL export and import are not yet written. The work stalled since the developer who knows elisp in our team is no longer very active. We still need to fix some bugs. I am glad that somewhere some one is interested in this project. It is very encouraging. Let me know what kind of usecase you have thought about for using gnowsys-mode. -- GN
[O] Re: org-advertized-archive-subtree: Symbol's function definition is void: org-datetree-find-year-create
Urs Rau urs@uk.om.org writes: I am trying to archive completed tasks to a datetree. I am using Move Subtree to Archive file (C-c C-x -C-s) And I get the following error: release_7.4-419-g68114f Org-mode version 7.4 (release_7.4.419.g68114f) afile=/Users/ursr/org/tasksnotes.org_archive org-advertized-archive-subtree: Symbol's function definition is void: org-datetree-find-year-create I think you'll need (require 'org-datetree) in your .emacs. The problem is that the advice calls functions from that file that are not autoloaded. Best, Matt And I had done a C-c C-x ! to reload all org files, jsut in case. ;-) I have added the following settings taken from the worg site page: http://orgmode.org/worg/org-hacks.html Topic: Archive in a date tree Posted to Org-mode mailing list by Osamu Okano (setq org-archive-location %s_archive::date-tree) (defadvice org-archive-subtree (around org-archive-subtree-to-data-tree activate) org-archive-subtree to date-tree (if (string= date-tree (org-extract-archive-heading (org-get-local-archive-location))) (let* ((dct (decode-time (org-current-time))) (y (nth 5 dct)) (m (nth 4 dct)) (d (nth 3 dct)) (this-buffer (current-buffer)) (location (org-get-local-archive-location)) (afile (org-extract-archive-file location)) (org-archive-location (format %s::*** %04d-%02d-%02d %s afile y m d (format-time-string %A (encode-time 0 0 0 d m y) (message afile=%s afile) (unless afile (error Invalid `org-archive-location')) (save-excursion (switch-to-buffer (find-file-noselect afile)) (org-datetree-find-year-create y) (org-datetree-find-month-create y m) (org-datetree-find-day-create y m d) (widen) (switch-to-buffer this-buffer)) ad-do-it) ad-do-it)) ;; How do I fix this and make sure I can file into a datetree? Also is this going to be based on USA dates or will it work right with European dates? Thanks. -- Urs Rau ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [O] [PATCH] Bugfix: org-agenda-open-link
Bert Burgemeister tre...@googlemail.com writes: * Org-agenda.el (org-agenda-open-link): C-c C-o didn't open links inserted via the `%%( )' mechanism, affecting usability of `%%(org-bbdb-anniversaries). TINYCHANGE --- The bug was apparently introduced in commit ba1e90893d128d8004e4cb6763af692c5a6cd677. -- Bert lisp/org-agenda.el | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 4b4dd68..123668c 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -6742,13 +6742,13 @@ at the text of the entry itself. (+ (point-at-bol) (or (org-get-at-bol 'prefix-length) 0) (cond - (buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char marker) - (org-offer-links-in-entry arg prefix) + ((and buffer +(with-current-buffer buffer + (save-excursion +(save-restriction + (widen) + (goto-char marker) + (org-offer-links-in-entry arg prefix)) ((or (org-in-regexp (concat \\( org-bracket-link-regexp \\))) (save-excursion (beginning-of-line 1) Ok, perhaps I should complement my patch with a bug report. %%(org-bbdb-anniversaries) inserts birthdays into the agenda that contain links to the respective BBDB entry. These links are broken. Here is a demonstration of the bug that doesn't require BBDB. Put the following line into one of your agenda files: %%((lambda () (concat [[ http ://example.com ] ]))) M-x org-agenda-list now includes decent links to http://example.com. C-c C-o on one of them answers No links. -- Bert
Re: [O] Re: org-src-fontify-natively makes things very, very slow
2011/3/19 Sébastien Vauban wxhgmqzgw...@spammotel.com: My solution, by the way, is to insert the #+end_src line immediately upon writing a #+begin_src line and then back up a line to start writing the code. My solution is even simpler: just use a yasnippet template, that prompts you for the language and puts the begin/end upfront: Or use org's own template mechanism[fn:1], 1. s - for source blocks 2. e - for example blocks and so on ... Footnotes: [fn:1] [[info:org#Easy%20Templates][info:org#Easy Templates]] -- Suvayu Open source is the future. It sets us free.
[O] Re: Merging .org files
Aankhen aank...@gmail.com writes: On Sat, Mar 19, 2011 at 02:08, Matt Lundin m...@imapmail.org wrote: Pere Quintana Seguí pquint...@obsebre.es writes: Now I have to learn to better navigate within my much longer org files. Before, I used ido-mode to jump from buffer to buffer, now I guess I have to practise more sparse trees to jump from headline to headline. I use this function to jump quickly (via ido) to a first level headline in my org files: [snip] Do you normally have ‘org-completion-use-ido’ turned off or something? (Just wondering why you couldn’t use ‘org-refile’ directly.) Yes, that is correct. I normally have org-completion-use-ido turned off. You could easily call org-refile with a prefix argument directly from within an org-buffer. However, I find it more convenient to bind (org-refile t) to one of the function keys than to type C-u C-c C-w. The latter works only on org buffers, while the former is global. Moreover, when navigating org files in this way, I only want to see first level headlines, whereas my default refile binding uses deeper levels. Best, Matt
[O] OT: Another great application for Org
Another great way to use Org-mode.. http://xkcd.com/874/
[O] Re: [Accepted] org-export-preprocess-string: Use backend var
Jambunathan K kjambunat...@gmail.com writes: Bastien + ;; Backend-specific preprocessing + (let* ((backend-name (symbol-name backend)) +(f (intern (format org-export-%s-preprocess backend-name + (require (intern (concat org- backend-name)) nil) + (funcall f parameters)) A few words of explanation from my side. Summary: Facilitate transparent plugging-in of per-backend pre-processing logic to the org exporter. Jambunathan K. This patch (0135cb9c) breaks Wes Hardaker's generic export (in contrib). Since the backend is nil, the following line causes org-export to try to require org-nil: (require (intern (concat org- backend-name)) nil) --8---cut here---start-8--- Debugger entered--Lisp error: (file-error Cannot open load file org-nil) require(org-nil nil) --8---cut here---end---8--- I ask because even though org-export-generic.el is a contributed package, an option to call it is hard-coded into org-export: --8---cut here---start-8--- \[g] export using Wes Hardaker's generic exporter --8---cut here---end---8--- Best, Matt
[O] Re: Symbol's function definition is void: org-datetree-find-year-create / autoload org-datetree library?
Urs Rau (UK) urs@om.org writes:
On latest git version release_7.4-419-g68114f, [Org-mode version 7.4
(release_7.4.419.g68114f)] , I am trying to archive to a date-tree and
get the error:
Symbol's function definition is void: org-datetree-find-year-create
I found that if I '(load org-datetree.el)' in the scratch buffer, it then
succeeds.
Does org-datetree not get auto-loaded?
I mentioned this in a previous email, but I'll elaborate a bit here.
Only one function from org-datetree is autoloaded:
org-datetree-find-date-create. None of the other functions is loaded
until this function is called *or* until you evaluate (require
'org-datetree).
To solve the problem, you could either rewrite the defadvice to use
org-datetree-find-date-create or add (require 'org-datetree) to your
emacs.
To change the advice, simply replace the following lines
--8---cut here---start-8---
(org-datetree-find-year-create y)
(org-datetree-find-month-create y m)
(org-datetree-find-day-create y m d)
--8---cut here---end---8---
with
--8---cut here---start-8---
(org-datetree-find-date-create `(,m ,d ,y))
--8---cut here---end---8---
Also I have searched the *.el files to find the definition of
org-datetree-find-year-create and found inconsistent use of the
keep-restriction check, sometimes it is all lower case, sometimes it
is all uppercase, I guess lisp is not case sensitive?
$ find ./ -type f -exec grep -i keep-restriction {} /dev/null \;
./lisp/org-agenda.el: (date optional keep-restriction))
./lisp/org-capture.el: (DATE optional KEEP-RESTRICTION))
./lisp/org-datetree.el:(defun org-datetree-find-date-create (date optional
keep-restriction)
./lisp/org-datetree.el:If KEEP-RESTRICTION is non-nil, do not widen the
buffer.
./lisp/org-datetree.el:(or keep-restriction (widen))
Look at the context in which the uppercase occurs (e.g., a docstring).
Best,
Matt
Re: [O] Re: Symbol's function definition is void: org-datetree-find-year-create / autoload org-datetree library?
On 19.3.2011, at 14:51, Matt Lundin wrote:
Urs Rau (UK) urs@om.org writes:
On latest git version release_7.4-419-g68114f, [Org-mode version 7.4
(release_7.4.419.g68114f)] , I am trying to archive to a date-tree and
get the error:
Symbol's function definition is void: org-datetree-find-year-create
I found that if I '(load org-datetree.el)' in the scratch buffer, it then
succeeds.
Does org-datetree not get auto-loaded?
I mentioned this in a previous email, but I'll elaborate a bit here.
Only one function from org-datetree is autoloaded:
org-datetree-find-date-create. None of the other functions is loaded
until this function is called *or* until you evaluate (require
'org-datetree).
To solve the problem, you could either rewrite the defadvice to use
org-datetree-find-date-create or add (require 'org-datetree) to your
emacs.
A third possibility it to wrap the defadvice form into
(eval-after-load org-datetree
'(defadvice..
)
This will wait for the time when org-datetree is loaded.
Cheers
- Carsten
To change the advice, simply replace the following lines
--8---cut here---start-8---
(org-datetree-find-year-create y)
(org-datetree-find-month-create y m)
(org-datetree-find-day-create y m d)
--8---cut here---end---8---
with
--8---cut here---start-8---
(org-datetree-find-date-create `(,m ,d ,y))
--8---cut here---end---8---
Also I have searched the *.el files to find the definition of
org-datetree-find-year-create and found inconsistent use of the
keep-restriction check, sometimes it is all lower case, sometimes it
is all uppercase, I guess lisp is not case sensitive?
$ find ./ -type f -exec grep -i keep-restriction {} /dev/null \;
./lisp/org-agenda.el: (date optional keep-restriction))
./lisp/org-capture.el: (DATE optional KEEP-RESTRICTION))
./lisp/org-datetree.el:(defun org-datetree-find-date-create (date optional
keep-restriction)
./lisp/org-datetree.el:If KEEP-RESTRICTION is non-nil, do not widen the
buffer.
./lisp/org-datetree.el:(or keep-restriction (widen))
Look at the context in which the uppercase occurs (e.g., a docstring).
Best,
Matt
Re: [O] OT: Another great application for Org
On Sat, Mar 19, 2011 at 8:03 AM, Carsten Dominik carsten.domi...@gmail.com wrote: Another great way to use Org-mode.. http://xkcd.com/874/ That is *fantastic*. Maybe if I actually wrote out a plan like that on a schedule, I'd feel better about myself... since that's about how things often happen :)
[O] Re: Capture question
Suvayu Ali fatkasuvayu+li...@gmail.com writes: As far as I understand GMail sends a multipart message, plain text and html mixed. I can't comment further as I don't know much more about email technologies and standards. And FWIW, Gnus users can make sure they don't see the html parts of multipart/alternative messages sent by Gmail by setting the variable mm-discouraged-alternatives or by converting the html to text via mm-text-html-renderer. This doesn't fix the underlying problem of Gmail users sending multipart messages, but it at least makes the emails readable. Best, Matt
[O] Re: Capture question
On Sat, 19 Mar 2011 10:41:34 -0400 Matt Lundin m...@imapmail.org wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: As far as I understand GMail sends a multipart message, plain text and html mixed. I can't comment further as I don't know much more about email technologies and standards. And FWIW, Gnus users can make sure they don't see the html parts of multipart/alternative messages sent by Gmail by setting the variable mm-discouraged-alternatives or by converting the html to text via mm-text-html-renderer. This doesn't fix the underlying problem of Gmail users sending multipart messages, but it at least makes the emails readable. Something similar with claws and thunderbird. With claws by default it strips all html and shows only plain text and for Tbird, you can configure it to do that. :) -- Suvayu Open source is the future. It sets us free.
[O] Re: [Bug] MCE for HTML test of export
Hello, Sébastien Vauban wxhgmqzgw...@spammotel.com writes: Perfect. Works like a charm. Please do apply it... Done. Also, you may have a look at default templates, as your HTML variant is slightly wrong (wrt br tag). I'm not sure to understand what's wrong. You mean the fact I added manually a br tag after the title? I just meant that you could replace br by br /. I think both are valid HTML-wise, but Emacs doesn't report an error with the latter. Regards, -- Nicolas
[O] Re: Merging .org files
On Sat, Mar 19, 2011 at 18:23, Matt Lundin m...@imapmail.org wrote: Aankhen aank...@gmail.com writes: [snip] Do you normally have ‘org-completion-use-ido’ turned off or something? (Just wondering why you couldn’t use ‘org-refile’ directly.) Yes, that is correct. I normally have org-completion-use-ido turned off. You could easily call org-refile with a prefix argument directly from within an org-buffer. However, I find it more convenient to bind (org-refile t) to one of the function keys than to type C-u C-c C-w. The latter works only on org buffers, while the former is global. Moreover, when navigating org files in this way, I only want to see first level headlines, whereas my default refile binding uses deeper levels. A’right, makes sense. I appreciate the detailed explanation. Aankhen
Re: [O] Bug: Recurring items don't always show up in timeline
On 2011-03-18 21:20, Nick Dokos wrote: Mark Sthroa...@yahoo.com wrote: I posted this before as a question, but since it has been confirmed by others, and shows up under Linux and Windows, I'll now post the details as a bug. The Timeline view *would* be very useful for scheduling months in advance, reviewing history, or printing a year event calendar. Unfortunately, it appears that it can't really be trusted. The basic problem is that in AGENDA TIMELINE view (C-a L) recurring items are frequently and unpredictably dropped from the view. The regular AGENDA view works fine AFAIK -- its the TIMELINE that is at issue. AFAICT, the culprit is org-get-all-dates: it matches date strings, translates to number of days since the (imaginary) date 0001-12-31bce, accumulates them in a list, sorts them, takes care of gaps - but completely ignores any repeaters: iow, the don't always show in the Subject line should more accurately say never show. Unless I'm missing something (again!), when I try it, they *do* repeat *sometimes*. For example, the entry TODO [#A] Bath for dog 2011-03-10 Thu +1w appears in agenda timeline as follows: 2011-03-10, miss 1 week, 2011-03-24, 2011-03-31, 2011-04-07, miss 7 weeks, 2011-06-02, miss 8 weeks (agenda terminates 2011-07-31). -- Chris Randle
Re: [O] Re: [Bug] MCE for HTML test of export
On Sat, Mar 19, 2011 at 22:55, Nicolas n.goaz...@gmail.com wrote: [snip] Also, you may have a look at default templates, as your HTML variant is slightly wrong (wrt br tag). I'm not sure to understand what's wrong. You mean the fact I added manually a br tag after the title? I just meant that you could replace br by br /. I think both are valid HTML-wise, but Emacs doesn't report an error with the latter. br is valid HTML, br / is valid XHTML. Browsers will treat both the same way in almost every case since it’s all tag soup to them.[1] Org uses XHTML as far as I can tell, so br / is the correct choice here. Aankhen [1]: Unless you’re serving it up as real XHTML, which I highly doubt. ;-)
Re: [O] OT: Another great application for Org
On Sat, Mar 19, 2011 at 6:33 PM, Carsten Dominik wrote: Another great way to use Org-mode.. http://xkcd.com/874/ Sounds like me alright (minus the blog post bit ;-) ) Thanks for sharing. -- Manish
Re: [O] Bug: Recurring items don't always show up in timeline
Chris Randle ch...@amlog.co.uk wrote: On 2011-03-18 21:20, Nick Dokos wrote: Mark Sthroa...@yahoo.com wrote: I posted this before as a question, but since it has been confirmed by others, and shows up under Linux and Windows, I'll now post the details as a bug. The Timeline view *would* be very useful for scheduling months in advance, reviewing history, or printing a year event calendar. Unfortunately, it appears that it can't really be trusted. The basic problem is that in AGENDA TIMELINE view (C-a L) recurring items are frequently and unpredictably dropped from the view. The regular AGENDA view works fine AFAIK -- its the TIMELINE that is at issue. AFAICT, the culprit is org-get-all-dates: it matches date strings, translates to number of days since the (imaginary) date 0001-12-31bce, accumulates them in a list, sorts them, takes care of gaps - but completely ignores any repeaters: iow, the don't always show in the Subject line should more accurately say never show. Unless I'm missing something (again!), when I try it, they *do* repeat *sometimes*. For example, the entry TODO [#A] Bath for dog 2011-03-10 Thu +1w appears in agenda timeline as follows: 2011-03-10, miss 1 week, 2011-03-24, 2011-03-31, 2011-04-07, miss 7 weeks, 2011-06-02, miss 8 weeks (agenda terminates 2011-07-31). That's true. I believe that's when it coincides with another entry: it sneaks in on the heels of the other entry. But I may very well be wrong: I have only scratched the surface a bit. Nick
[O] Re: [Accepted] org-export-preprocess-string: Use backend var
Matt Lundin m...@imapmail.org writes: Jambunathan K kjambunat...@gmail.com writes: This patch (0135cb9c) breaks Wes Hardaker's generic export (in contrib). Since the backend is nil, the following line causes org-export to try to require org-nil: (require (intern (concat org- backend-name)) nil) Debugger entered--Lisp error: (file-error Cannot open load file org-nil) require(org-nil nil) I ask because even though org-export-generic.el is a contributed package, an option to call it is hard-coded into org-export: \[g] export using Wes Hardaker's generic exporter I missed Nick's earlier patch to fix this. Everything is working properly now. Sorry for the noise. Best, Matt
Re: [O] Re: org-src-fontify-natively makes things very, very slow
Sébastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric S Fraga wrote: [...] where there is no matching #+end_src or, more precisely, the next #+end_src line is one that does not belong to this current source block. Your search (in org.el) for the end of the block assumes that it does have the end statement in place already. I'm not sure how to fix this because it's an ill-defined situation. You say your search... but I only added the overlay-put command... and I must admit this whole block is difficult to follow (so many cases). Yes but the overlay needs to know where to end; I am using search in a more general sense here in that you are defining the start and end of a region to overlay using regular expressions, are you not? [...] My solution, by the way, is to insert the #+end_src line immediately upon writing a #+begin_src line and then back up a line to start writing the code. My solution is even simpler: just use a yasnippet template, that prompts you for the language and puts the begin/end upfront: yes, I used to use yasnippet a lot but I don't any longer. I am actually in confusion as to which completion mechanism to use in Emacs these days and am going a little crazy... :( I'm currently playing with auto-complete. Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.83.g1bd87.dirty)
Re: [O] Re: org-src-fontify-natively makes things very, very slow
suvayu ali fatkasuvayu+li...@gmail.com writes: 2011/3/19 Sébastien Vauban wxhgmqzgw...@spammotel.com: My solution, by the way, is to insert the #+end_src line immediately upon writing a #+begin_src line and then back up a line to start writing the code. My solution is even simpler: just use a yasnippet template, that prompts you for the language and puts the begin/end upfront: Or use org's own template mechanism[fn:1], 1. s - for source blocks 2. e - for example blocks and so on ... Footnotes: [fn:1] [[info:org#Easy%20Templates][info:org#Easy Templates]] Thanks for this! I am always forgetting about these and they do work well. For some reason, I always find it difficult to find them in the info manual. I guess it's because I don't think of them as templates and always search for short-cut and abbreviation in the table of contents for the org manual and neither is useful. Could I suggest that maybe the heading for this section be something like Short-cut keys for easy templates? Or something similar? Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.83.g1bd87.dirty)
Re: [O] Re: Making GTD more mangeable with org
Marcelo de Moraes Serpa celose...@gmail.com writes: Thanks, this works for me :) Anyway, I just wanted to debate over this particular overview file. Not sure if this really worths it, but has been working for me lately. You guys use something similar? For day to day GTD type things, the agenda with diary entries and todos works perfectly for me. For individual tasks, the outline and specific sparse-tree views of the file(s) associated with that task will give me everything else I need! I start my working day with three things, all within emacs (as the focal point of my computer interactions most of the day): eshell, agenda day view for today, and gnus. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.83.g1bd87.dirty)
[O] hide #+ lines?
Hi, I've started using #+ blocks here and there, and (meaning no disrespect) I find them a bit ugly. I would much rather there were some way to hide the #+ directives (without, of course, impeding their functionality). I believe I've done my due diligence, checking doc google, but I can't find anything to help. Anyone got something to offer? Cheers. Fil -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: salus...@ryerson.ca http://deseng.ryerson.ca/~fil/
Re: [O] sitemap seems to cache old #+TITLE
On Sat, 19 Mar 2011, Carsten Dominik wrote: On 19.3.2011, at 04:13, lbml...@hethcote.com wrote: Have you tried forcing republishing of all files by using a C-u prefix to your publishing command? I have now, and there is no change in result. C-u C-c C-e P does cause a longer export/publish time but result appears the same. - Carsten Louis
Re: [O] Having problem with latex export of image file
On 3/17/11 Mar 17 -4:35 AM, Bastien wrote: Hi Nick, Nick Dokos nicholas.do...@hp.com writes: I didn't look very hard, but I didn't find documentation on these. If Robert or you can provide a documentation patch for this, it would be nice. It's not (only) laziness from me: since you stumbled on the issue, I guess you can better explain what is at stake. Thanks! I'm ordinarily willing to chime in with a manual patch, but this seems odd enough that I wonder if there isn't a bug that needs fixing. In particular, it seems very weird to me that the latex exporter would treat un-directoried pathnames as files to be exported as links rather than inline images *even if there is a #+CAPTION present*. Is it worth re-examining this, instead of documenting it? cheers, r
Re: [O] hide #+ lines?
Hi, If you are referring to directives such as export templates, etc., these can in general be placed anywhere in the document. For example, inside a COMMENT'ed heading at the end of the document, with folded view as default. You can also have all that in another file and use #+setupfile or #include for inclusion. Other things such as #+category have their equivalent as properties, which are normally folded. Regards, .j. On Sat, Mar 19, 2011 at 05:27:23PM -0400, Filippo A. Salustri wrote: I've started using #+ blocks here and there, and (meaning no disrespect) I find them a bit ugly. I would much rather there were some way to hide the #+ directives (without, of course, impeding their functionality). I believe I've done my due diligence, checking doc google, but I can't find anything to help. Anyone got something to offer?
Re: [O] hide #+ lines?
Juan Pechiar j...@pechiar.com wrote:
On Sat, Mar 19, 2011 at 05:27:23PM -0400, Filippo A. Salustri wrote:
I've started using #+ blocks here and there, and (meaning no
disrespect) I find them a bit ugly. I would much rather there were
some way to hide the #+ directives (without, of course, impeding their
functionality).
I believe I've done my due diligence, checking doc google, but I
can't find anything to help.
Anyone got something to offer?
If you are referring to directives such as export templates, etc.,
these can in general be placed anywhere in the document. For example,
inside a COMMENT'ed heading at the end of the document, with folded
view as default.
You can also have all that in another file and use #+setupfile or
#include for inclusion.
Other things such as #+category have their equivalent as properties,
which are normally folded.
Another similar solution (cribbed from this list, but I don't remember
who suggested it) is to define a drawer and put all that stuff in it -
isn't that what drawers are for? :-) Keep the drawer closed and the mess
is hidden - and it is not affected by general visibility cycling: you
have to open the drawer deliberately.
The top of one of my org files looks like this:
--8---cut here---start-8---
:SETUP:
#+STARTUP: showall lognotedone
#+SEQ_TODO: TODO(t) STARTED(s) WAITING(w) | DONE(d) DEFERRED CANCELLED(c)
#+TAGS: { FINANCES(f) HOME(h) PACC(p) SCHOOL(s) WORK(w) } CALL(c) ERRAND(e)
:END:
--8---cut here---end---8---
You need to set up the variable org-drawers - see section 2.8 of the Org manual.
Nick
Re: [O] gnowsys-mode update?
Thank you very much Nagarjuna G - Am Samstag, 19. März 2011, 12:19:46 schrieb Nagarjuna G: On Fri, Mar 18, 2011 at 8:25 PM, Martin Weigele mar...@weigele.de wrote: Hi all, I've run into some texts about gnowsys as a major mode extending org, ... ... Yes. We use the gnowsys-mode interface for sites running using gnowsys. So far this is the only complete interface for gnowsys. Mostly used by the developers and those who maintain the sites, such as atlas.gnowledge.org OK I understand now the starting point to understand gnowsys, and, hence, for gnowsys on top of orgmode is http://www.gnu.org/software/gnowsys . This is so great. I am glad that somewhere some one is interested in this project. It is very encouraging. Let me know what kind of usecase you have thought about for using gnowsys-mode. The project is even in pre-infancy state, but it is about using such modelling to understand and learn structures in humanities (for me coming from a CS background). Martin
Re: [O] hide #+ lines?
Juan Nick,
I like your ideas, but my case is a little different. I only want to
hide the BEGIN/END statements, not what comes between them.
That is, I'm using a trick Ido Magal suggested
(http://permalink.gmane.org/gmane.emacs.orgmode/39226).
It works fine, except I see all the distracting block directives.
Cheers.
Fil'
On 19 March 2011 18:26, Nick Dokos nicholas.do...@hp.com wrote:
Juan Pechiar j...@pechiar.com wrote:
On Sat, Mar 19, 2011 at 05:27:23PM -0400, Filippo A. Salustri wrote:
I've started using #+ blocks here and there, and (meaning no
disrespect) I find them a bit ugly. I would much rather there were
some way to hide the #+ directives (without, of course, impeding their
functionality).
I believe I've done my due diligence, checking doc google, but I
can't find anything to help.
Anyone got something to offer?
If you are referring to directives such as export templates, etc.,
these can in general be placed anywhere in the document. For example,
inside a COMMENT'ed heading at the end of the document, with folded
view as default.
You can also have all that in another file and use #+setupfile or
#include for inclusion.
Other things such as #+category have their equivalent as properties,
which are normally folded.
Another similar solution (cribbed from this list, but I don't remember
who suggested it) is to define a drawer and put all that stuff in it -
isn't that what drawers are for? :-) Keep the drawer closed and the mess
is hidden - and it is not affected by general visibility cycling: you
have to open the drawer deliberately.
The top of one of my org files looks like this:
--8---cut here---start-8---
:SETUP:
#+STARTUP: showall lognotedone
#+SEQ_TODO: TODO(t) STARTED(s) WAITING(w) | DONE(d) DEFERRED CANCELLED(c)
#+TAGS: { FINANCES(f) HOME(h) PACC(p) SCHOOL(s) WORK(w) } CALL(c) ERRAND(e)
:END:
--8---cut here---end---8---
You need to set up the variable org-drawers - see section 2.8 of the Org
manual.
Nick
--
Filippo A. Salustri, Ph.D., P.Eng.
Mechanical and Industrial Engineering
Ryerson University
350 Victoria St, Toronto, ON
M5B 2K3, Canada
Tel: 416/979-5000 ext 7749
Fax: 416/979-5265
Email: salus...@ryerson.ca
http://deseng.ryerson.ca/~fil/
Re: [O] sitemap seems to cache old #+TITLE
I see that the old title is cached in ~/.org-timestamps, I'll try clearing that and see what happens. L On Sat, 19 Mar 2011, lbml...@hethcote.com wrote: On Sat, 19 Mar 2011, Carsten Dominik wrote: On 19.3.2011, at 04:13, lbml...@hethcote.com wrote: Have you tried forcing republishing of all files by using a C-u prefix to your publishing command? I have now, and there is no change in result. C-u C-c C-e P does cause a longer export/publish time but result appears the same. - Carsten Louis
Re: [O] sitemap seems to cache old #+TITLE
Hi, lbml...@hethcote.com writes: At one point in the recent past I had a file org.org with #+TITLE: LBM TCH KB Org Eventually I changed it to be #+TITLE: KBorg no matter what I do, the generated sitemap pick up the old title. This was a bug in Org 7.5 which has been fixed in Org 7.5 -- upgrading to the latest release should fix your problem. HTH, -- Bastien
Re: [O] sitemap seems to cache old #+TITLE
Bastien b...@altern.org writes: This was a bug in Org 7.5 which has been fixed in Org 7.5 -- Ahem -- I mean it was a bug in Org 7.4, of course. -- Bastien
Re: [O] gnowsys-mode update?
I too am interested in gnowsys-mode and have been meaning to look more deeply into it. I remember reviewing gnowsys-mode and it looked very interesting and related to the semantic web and there was a semantic web workshop in Reston, VA recently--gnowsys-mode was on the agenda. THere may be some exciting apps one could make with a mashup with org-mode and gnowsys-mode (with one or the other as an emacs sub/minor-mode). On Sat, Mar 19, 2011 at 6:33 PM, Martin Weigele mar...@weigele.de wrote: Thank you very much Nagarjuna G - Am Samstag, 19. März 2011, 12:19:46 schrieb Nagarjuna G: On Fri, Mar 18, 2011 at 8:25 PM, Martin Weigele mar...@weigele.de wrote: Hi all, I've run into some texts about gnowsys as a major mode extending org, ... ... Yes. We use the gnowsys-mode interface for sites running using gnowsys. So far this is the only complete interface for gnowsys. Mostly used by the developers and those who maintain the sites, such as atlas.gnowledge.org OK I understand now the starting point to understand gnowsys, and, hence, for gnowsys on top of orgmode is http://www.gnu.org/software/gnowsys . This is so great. I am glad that somewhere some one is interested in this project. It is very encouraging. Let me know what kind of usecase you have thought about for using gnowsys-mode. The project is even in pre-infancy state, but it is about using such modelling to understand and learn structures in humanities (for me coming from a CS background). Martin
Re: [O] hide #+ lines?
Filippo A. Salustri salus...@ryerson.ca wrote: On 19 March 2011 18:26, Nick Dokos nicholas.do...@hp.com wrote: ... Another similar solution (cribbed from this list, but I don't remember who suggested it) is to define a drawer and put all that stuff in it - That was Carsten: see http://thread.gmane.org/gmane.emacs.orgmode/2722/focus=2732 and there is another bit of setup needed to keep the drawer closed to begin with. Carsten suggested (add-hook 'org-mode-hook (lambda () (org-cycle-hide-drawers 'all))) Juan Nick, I like your ideas, but my case is a little different. I only want to hide the BEGIN/END statements, not what comes between them. That is, I'm using a trick Ido Magal suggested (http://permalink.gmane.org/gmane.emacs.orgmode/39226). It works fine, except I see all the distracting block directives. The first line in the posting you point to is not org-mode related at all: it asks emacs to eval the form when the file is visited. Since emacs requires that to be the *first* line you cannot do anything about that. However, there is another way to specify local variables: in a Local variables section at the end of the file. That *can* be put into a drawer: :SETUP: # Local variables: # eval: (org-update-all-dblocks) # End: :END: but it becomes the personal property of the last headline, so if that is folded, the drawer is completely invisible and if it's deep in the tree it becomes difficult to find. I would put it under its own headline, perhaps * COMMENT setup. The #+BEGIN: ... / #+END surrounding the output of the dblock cannot be hidden afaik, but are they really distracting? I find them helpful in focusing my eyes on the output. Nick
[O] [BUG] fill-paragraph in orgstruct mode blows up
I use orgstruct mode when composing email and fill-paragraph blew up with the following backtrace when I tried to fill a paragraph after a drawer, as described in the last paragraph of this email. :SETUP: # Local variables: # eval: (org-update-all-dblocks) -*- # End: :END: This is a dummy paragraph after the drawer. Put cursor here and call fill-paragraph after enabling orgstruct-mode. You should get the error below. Nick Org-mode version 7.5 (release_7.5.86.g6daa.dirty) , | Debugger entered--Lisp error: (wrong-type-argument stringp nil) | re-search-backward(nil nil t) | (cond ((and (looking-at item-re) (or ( ind ind-ref) (eq org-list-ending-method (quote regexp (throw (quote exit) (point))) ((= (point) lim-up) (throw (quote exit) nil)) ((and (not (eq org-list-ending-method (quote indent))) (looking-at org-list-end-re)) (throw (quote exit) nil)) ((looking-at ^[ ]*#\\+end_) (re-search-backward ^[]*#\\+begin_ nil t)) ((looking-at ^[ ]*:END:) (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at ^[ ]*$) (forward-line -1)) ((zerop ind) (throw (quote exit) nil)) (( ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1))) | (let ((ind (org-get-indentation))) (cond ((and (looking-at item-re) (or ( ind ind-ref) (eq org-list-ending-method (quote regexp (throw (quote exit) (point))) ((= (point) lim-up) (throw (quote exit) nil)) ((and (not (eq org-list-ending-method (quote indent))) (looking-at org-list-end-re)) (throw (quote exit) nil)) ((looking-at ^[ ]*#\\+end_) (re-search-backward ^[ ]*#\\+begin_ nil t)) ((looking-at ^[ ]*:END:) (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at ^[ ]*$) (forward-line -1)) ((zerop ind) (throw (quote exit) nil)) (( ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1 | (while t (let ((ind (org-get-indentation))) (cond ((and (looking-at item-re) (or ( ind ind-ref) (eq org-list-ending-method (quote regexp (throw (quote exit) (point))) ((= (point) lim-up) (throw (quote exit) nil)) ((and (not (eq org-list-ending-method (quote indent))) (looking-at org-list-end-re)) (throw (quote exit) nil)) ((looking-at ^[ ]*#\\+end_) (re-search-backward ^[]*#\\+begin_ nil t)) ((looking-at ^[ ]*:END:) (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at ^[ ]*$) (forward-line -1)) ((zerop ind) (throw (quote exit) nil)) (( ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1) | (catch (quote exit) (while t (let ((ind (org-get-indentation))) (cond ((and (looking-at item-re) (or ( ind ind-ref) (eq org-list-ending-method ...))) (throw (quote exit) (point))) ((= (point) lim-up) (throw (quote exit) nil)) ((and (not (eq org-list-ending-method ...)) (looking-at org-list-end-re)) (throw (quote exit) nil)) ((looking-at ^[]*#\\+end_) (re-search-backward ^[]*#\\+begin_ nil t)) ((looking-at ^[ ]*:END:) (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at ^[ ]*$) (forward-line -1)) ((zerop ind) (throw (quote exit) nil)) (( ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1)) | (cond ((eq (nth 2 context) (quote invalid)) nil) ((looking-at item-re) (point)) (t (let ((hl 0) (i -1) end-bounds) (when (and (not (eq org-list-ending-method (quote indent))) (progn (while (setq i ...) (setq hl ...)) (setq end-bounds (org-in-regexp org-list-end-re hl))) (= (point) (car end-bounds)) ( (point) (cdr end-bounds))) (goto-char (car end-bounds)) (forward-line -1))) (catch (quote exit) (while t (let ((ind (org-get-indentation))) (cond ((and ... ...) (throw ... ...)) ((= ... lim-up) (throw ... nil)) ((and ... ...) (throw ... nil)) ((looking-at ^[ ]*#\\+end_) (re-search-backward ^[]*#\\+begin_ nil t)) ((looking-at ^[ ]*:END:) (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re ...) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at ^[]*$) (forward-line -1)) ((zerop ind) (throw ... nil)) (( ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1 | (let* ((case-fold-search t) (context (org-list-context)) (lim-up (car context)) (inlinetask-re (and (featurep (quote org-inlinetask)) (org-inlinetask-outline-regexp))) (item-re (org-item-re)) (ind-ref (if (or (looking-at ^[]*$) (and inlinetask-re (looking-at inlinetask-re))) 1 (org-get-indentation (cond ((eq (nth 2 context) (quote invalid)) nil) ((looking-at item-re)
Re: [O] hide #+ lines?
You're right of course. Sorry about the mixup with the attribution. Nick, your previous post that mentioned org-drawers helped my hide the eval line. Thanks for that. As for the #+BEGIN block, my installation shows these lines in a rather gaudy orange, which I do find distracting. I found that those lines do have their own face, so I made 'em dark grey (my background is black). I can still see them, but it's the text in the block that stands out now. Cheers. Fil On 19 March 2011 21:42, Nick Dokos nicholas.do...@hp.com wrote: Filippo A. Salustri salus...@ryerson.ca wrote: On 19 March 2011 18:26, Nick Dokos nicholas.do...@hp.com wrote: ... Another similar solution (cribbed from this list, but I don't remember who suggested it) is to define a drawer and put all that stuff in it - That was Carsten: see http://thread.gmane.org/gmane.emacs.orgmode/2722/focus=2732 and there is another bit of setup needed to keep the drawer closed to begin with. Carsten suggested (add-hook 'org-mode-hook (lambda () (org-cycle-hide-drawers 'all))) Juan Nick, I like your ideas, but my case is a little different. I only want to hide the BEGIN/END statements, not what comes between them. That is, I'm using a trick Ido Magal suggested (http://permalink.gmane.org/gmane.emacs.orgmode/39226). It works fine, except I see all the distracting block directives. The first line in the posting you point to is not org-mode related at all: it asks emacs to eval the form when the file is visited. Since emacs requires that to be the *first* line you cannot do anything about that. However, there is another way to specify local variables: in a Local variables section at the end of the file. That *can* be put into a drawer: :SETUP: # Local variables: # eval: (org-update-all-dblocks) # End: :END: but it becomes the personal property of the last headline, so if that is folded, the drawer is completely invisible and if it's deep in the tree it becomes difficult to find. I would put it under its own headline, perhaps * COMMENT setup. The #+BEGIN: ... / #+END surrounding the output of the dblock cannot be hidden afaik, but are they really distracting? I find them helpful in focusing my eyes on the output. Nick -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: salus...@ryerson.ca http://deseng.ryerson.ca/~fil/
[O] Re: Org expert mode?
Rainer M Krug r.m.k...@gmail.com writes: But following on your statement that the features will still be there, I would actually suggest to introduce an Org Babel Mode which would *disable* features like archiving - the archiving feature (very useful for time management et al) is quite useless in the use of babel for literate programming. This Org Babel mode should not be a mode for the whole of org, but rather on a per file basis. I would suggest that archiving can fit very well into a literate programming and/or writing workflow. One can use org-archive-subtree, for instance, to remove unneeded sections of code/prose without deleting them altogether. I do this all the time when drafting a new bit of code or an essay. Best, Matt
Re: [O] hide #+ lines?
Filippo A. Salustri salus...@ryerson.ca wrote: You're right of course. Sorry about the mixup with the attribution. There was nothing wrong with your attribution. I was just adding some information to my previous posting about who suggested the drawer solution, but more importantly, adding the bit of setup needed: I think it's important to make each thread complete or provide enough references so that future wanderers can find their way without too much trouble. Nick, your previous post that mentioned org-drawers helped my hide the eval line. Thanks for that. As for the #+BEGIN block, my installation shows these lines in a rather gaudy orange, which I do find distracting. I found that those lines do have their own face, so I made 'em dark grey (my background is black). I can still see them, but it's the text in the block that stands out now. That sounds like a good solution. Nick
Re: [O] Re: org-src-fontify-natively makes things very, very slow
On Sun, Mar 20, 2011 at 4:34 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: yes, I used to use yasnippet a lot but I don't any longer. I am actually in confusion as to which completion mechanism to use in Emacs these days and am going a little crazy... :( I'm currently playing with auto-complete. Why did you give up on yasnippet? -- Le
