Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Hi Bastien, Bastien wrote: Hi Sébastien, Bastien b...@altern.org writes: Here's a patch to allow for a different prefix for deadline entries which are in the past: for example, 3 d ago instead of In -3 d... Please make sure the change is backward compatible so that users don't have to change the value of their `org-agenda-deadline-leaders' (i.e. simply fall back on (nth 1 ...) when (nth 2 ...) returns nil. I finally added this, with a slightly different patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=c8c991e Nice... Though, one question: why did you change the spacing (and, in fact, the width) of the leaders? --8---cut here---start-8--- -(defcustom org-agenda-scheduled-leaders '(Scheduled: Sched.%2dx: ) +(defcustom org-agenda-scheduled-leaders '( Scheduled: Sched.%3dx: ) Text preceding scheduled items in the agenda view. (...) -(defcustom org-agenda-deadline-leaders '(Deadline: In %3d d.: ) +(defcustom org-agenda-deadline-leaders '( Deadline: In %3d d.: %3d d. ago: ) --8---cut here---end---8--- Thanks for the suggestion, Thanks as well ;-) Best regards, Seb PS- Another question: some time ago, there was a ML with all the commits done on Org. This seems to have disappeared (at least from Gmane). A reason for that, or an alternative? -- Sebastien Vauban
Re: [O] 5f095f5 is the first bad commit (for my use case)
Hi Aaron, Aaron Ecay wrote: 2013ko otsailak 27an, Sebastien Vauban-ek idatzi zuen: Do you know if there was a way out -- other than killing Emacs -- in such a case where `C-g' is not working? If you are on Linux (or OS X, I suppose), you can sometimes break an infloop by sending emacs the SIGUSR2 signal (in the shell, “kill -USR2 `pidof emacs`”). This also generates a backtrace in the lisp debugger, which is useful for debugging. See C-h v debug-on-event . Thanks for the info! Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Hi Sébastien, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Though, one question: why did you change the spacing (and, in fact, the width) of the leaders? -(defcustom org-agenda-scheduled-leaders '(Scheduled: Sched.%2dx: ) +(defcustom org-agenda-scheduled-leaders '( Scheduled: Sched.%3dx: ) Text preceding scheduled items in the agenda view. (...) -(defcustom org-agenda-deadline-leaders '(Deadline: In %3d d.: ) +(defcustom org-agenda-deadline-leaders '( Deadline: In %3d d.: %3d d. ago: ) For the change in Scheduled: and Deadline: it's because I think it's cleaner to align them on the right, like the Sched. and In %3d.: strings. For the change in the width (from 11 to 12), it's because I wanted to correctly display %3d d. ago: , not %2d d. ago: , so that now any string with a warning delay more than 100 will be correctly displayed. Before, we allowed 100+ days for the future deadlines, but not for past scheduled items (i.e. they were not aligned properly.) I feel the change is not too intrusive. Best, -- Bastien
Re: [O] Exporter interface question
On 27.2.2013, at 16:22, Nicolas Goaziou n.goaz...@gmail.com wrote: Carsten Dominik carsten.domi...@gmail.com writes: OK, I see that this is a bit less trivial then I thought, requires that I study the ui interface a bit more. I think the only pieces of the UI involved are `org-export-dispatch' function and `org-export-dispatch-last-action' variable. If you want to rush ahead and implement it let me know - otherwise this will be a few days before I find the time. There's no hurry. It can wait a few days. OK, I pushed this change, maybe it is good if you have a brief look, Nicolas. It was great fun and educational to study your very clear code. Cheers - Carsten
[O] :wrap behaviour
I've been using the :wrap parameter extensively, to give me control over the formatting of results from code blocks. For files with many such blocks, it makes sense to specify the formatting at the file level. This works well, unless I want a particular block to be unwrapped. Just specifying :wrap with no parameter wraps the output in #+BEGIN_RESULTS...#+END_RESULTS, which is *not* what I want. The only way to get what I want is to move :wrap from the file level to each block I *do* want wrapped. I'd like to be able to disable wrapping for particular blocks. I've started experimenting with code to do that, but I'm not sure what the best behaviour should be, and would appreciate suggestions. Some ideas I've considered: + Have :wrap by itself disable wrapping; if you want to wrap in BEGIN_RESULTS..END_RESULTS you'll have to specify :wrap RESULTS. + Use a special string (e.g., :wrap off) to disable wrapping. Of course, this makes it impossible to wrap your output in a BEGIN_OFF..END_OFF block, should you ever want to do that. + Use a special symbol instead of a string to turn off wrapping (e.g., :wrap :off) Kind Regards, Mike Gauland
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Hi Sébastien, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: PS- Another question: some time ago, there was a ML with all the commits done on Org. This seems to have disappeared (at least from Gmane). A reason for that, or an alternative? I can't remember of such a mailing list. You can subscribe to the RSS feed from http://orgmode.org/cgit.cgi/org-mode.git/ And to the dedicated newsgroup on gwene.org: gwene.org.org-mode.git -- Bastien
Re: [O] Org-Mode Reference Card bug
Hello Frank and Nick, Nick Dokos wrote: Frank Mueller fm.em...@web.de wrote: Just a remark to the Org-Mode Reference Card (http://orgmode.org/orgcard.pdf). There is a little bug in the spreadsheet description. wrong: sum from 2nd to 3rd hline |:=vsum(@II..@III)| correct: sum from 2nd to 3rd hline |:=vsum(@II..III)| The second at symbol must be deleted for correct working. Why do you think so? I second Nick: your proposition is wrong; it can't work like that. Now, maybe you're hit by a feature here: when setting `org-hide-emphasis-markers' to t, some `@' disappear from the formula (as you see them, while they're there: enable visible-mode and check it!). Is this what happens to you? That's a feature... Best regards, Seb -- Sebastien Vauban
Re: [O] Org-Mode Reference Card bug
Hi Sébastien, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Now, maybe you're hit by a feature here: when setting `org-hide-emphasis-markers' to t, some `@' disappear from the formula (as you see them, while they're there: enable visible-mode and check it!). Why would @ disappear with `org-hide-emphasis-markers' set to t? -- Bastien
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Hi Nicolas, thanks for the thorough feedback. I reverted the change I made. I need to think more about the issue. Best, -- Bastien
Re: [O] org-agenda-write taking very long (probably because of babel)
Hi Achim, Achim Gratz strom...@nexgo.de writes: * lisp/ob-core.el (org-babel-execute-src-block): Do not ask for confirmation if the cached result is current. Since `org-babel-confirm-evaluate´ does additional things besides asking for confirmation, call it first with `org-confirm-babel-evaluate´ bound to nil. This has the effect that it will never ask the user, but will indicate if the block should be evaluated. If yes, determine whether the cached result block is current (this is deferred until now since `org-babel-process-params´ might trigger expensive operations). If `cache-current-p´ is t or `org-confirm-babel-evaluate´ is nil, evaluate the source block without asking. In case the cache is current the evaluation will not actually do anything but return the cached value, so this is safe. In case `org-confirm-babel-evaluate´ is nil the user would not be asked anyway, so the call of `org-babel-confirm-evaluate´ is not necessary. Otherwise run `org-babel-confirm-evaluate´ again to ask permission from the user and act depending on the answer. Sorry to nitpick on this but please keep the Emacs-like change log small, if not terse. Additionnal details are more than welcome in the commit message though. Thanks! -- Bastien
Re: [O] [babel] Commenting out src blocks for tangling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/02/13 00:33, Darlan Cavalcante Moreira wrote: I also converted my Emacs configuration to an org-mode file a long time ago and I hit the same spot you did. As you, I initially assumed (wished) that the COMMENT marker would disable tangling of blocks in that subtree. After that I found out the tangle property, which solves the problem but has no visual indication as you mentioned. Nowadays I use both approaches. Whenever I set the tangle property to no I also set the COMMENT mark and vice-verse. It is just a very minor annoyance to do both things and I'm used to it now. I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? Rainer -- Darlan At Wed, 27 Feb 2013 19:32:41 +, Eric S Fraga wrote: Alan L Tyree alanty...@gmail.com writes: [...] G'day Eric, If I understand your problem correctly, doesn't the property :tangle: do what you want? Yes, thanks; Aaron Ecay has also pointed out to me. It works and does exactly what I said I needed. And you have both been very polite :-) -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1285-g6cc600 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLxzfAAoJENvXNx4PUvmCuaAIAOITFnoNMB5EIyaPib6JC/wU WcD5e0J8+kQMcowYEoLrJmPOupw3sXj2tQoyq0gHhdcCVgBx0ZJh+WNkbC7QUlWh ruSJYuPQhbkFr+FjUpas3iyNmuxPIghpmmhMPKK/NhLGaE3tVgvEtMXeY9IEp2ai a0P+7g32yAv80kmJE2FXy8UdWGo/Cya8MFueRH2YxRv7cYRA63qFj8Wl4+hCM7sD comvN6wZue8ZTi32O203PQueafEA37+AZgUdcdLU13TQDRj4PytFjjsHGr64LRK8 zYTQr3+YiUDq9Nr0j+B4uxPZWXJgAcTMzW6+0FqbPdnSPoTpGnwLblQbZ/MnG1E= =sgpY -END PGP SIGNATURE-
Re: [O] Exporter interface question
On 28.2.2013, at 09:39, Carsten Dominik carsten.domi...@gmail.com wrote: On 27.2.2013, at 16:22, Nicolas Goaziou n.goaz...@gmail.com wrote: Carsten Dominik carsten.domi...@gmail.com writes: OK, I see that this is a bit less trivial then I thought, requires that I study the ui interface a bit more. I think the only pieces of the UI involved are `org-export-dispatch' function and `org-export-dispatch-last-action' variable. If you want to rush ahead and implement it let me know - otherwise this will be a few days before I find the time. There's no hurry. It can wait a few days. OK, I pushed this change, maybe it is good if you have a brief look, Nicolas. It was great fun and educational to study your very clear code. Sorry for following up on my own post. I forgot to mention that I did put in the restriction to make this work only if the export command is called in the same buffer. However, I am not checking if the cursor is in the same subtree - it seems to me that the behavior would become too unpredictable. Also, I have not yet documented the change in the manual, of course. - Carsten
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Bastien, Bastien wrote: Sebastien Vauban writes: Though, one question: why did you change the spacing (and, in fact, the width) of the leaders? -(defcustom org-agenda-scheduled-leaders '(Scheduled: Sched.%2dx: ) +(defcustom org-agenda-scheduled-leaders '( Scheduled: Sched.%3dx: ) Text preceding scheduled items in the agenda view. (...) -(defcustom org-agenda-deadline-leaders '(Deadline: In %3d d.: ) +(defcustom org-agenda-deadline-leaders '( Deadline: In %3d d.: %3d d. ago: ) For the change in Scheduled: and Deadline: it's because I think it's cleaner to align them on the right, like the Sched. and In %3d.: strings. I don't mind, I customize them anyway ;-) For the change in the width (from 11 to 12), it's because I wanted to correctly display %3d d. ago: , not %2d d. ago: , so that now any string with a warning delay more than 100 will be correctly displayed. Before, we allowed 100+ days for the future deadlines, but not for past scheduled items (i.e. they were not aligned properly.) I feel the change is not too intrusive. I think the change of width can impact people who customize a bit the look of their agenda, and rely upong *all* the leaders to be of width 11. That was the motivation for my other patch, about clocking info (to make it go into a 11-char slot). Let's see how people react to that -- or if some are impacted. Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Commenting out src blocks for tangling
Rainer M Krug r.m.k...@gmail.com writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Thanks! -- Bastien
Re: [O] [babel] Commenting out src blocks for tangling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/02/13 10:25, Bastien wrote: Rainer M Krug r.m.k...@gmail.com writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Brilliant - makes life so much easier and consistent. I'll update immediately. Cheers, Rainer Thanks! - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLyMWAAoJENvXNx4PUvmCUZoIAMl3G6yoXTUlSKV3jwzAKwtl ppwDRmgmy7Hqsk3KAl/yZdRdypXg4Ziom9zsiOSzHYz5agiPDplePbZ/fKbeOJKU kNr4Rsy+or9h1UHyzMCJnKg3yuy1hv7htFXcMpFeLe+ohQcM0xd0ehLPvcutj5nx W/d3bbIVL5GXTPdVYT8UO2CuPLfVJURnv7RvAFlaiVhkXiwKfSrE78bsm96ZkZK1 kWvAhESSwgWDSa+/2w/PESpt80iz7OZufsfKCEga8ZrJkkFFpzHgpA7uaqGYSzYA eIJ9vrGkUsi12UC2USwT7mxF0Wic7Yj+4Nvq+t0yH7f92VnqQCeHp8ztt/fxics= =HQRW -END PGP SIGNATURE-
Re: [O] Org-Mode Reference Card bug
Bastien, Bastien wrote: Sebastien Vauban writes: Now, maybe you're hit by a feature here: when setting `org-hide-emphasis-markers' to t, some `@' disappear from the formula (as you see them, while they're there: enable visible-mode and check it!). Why would @ disappear with `org-hide-emphasis-markers' set to t? They should not visually disappear, but they do. Consider the following formula line: |---+---| | | | |---+---| #+TBLFM: @1$1=vsum(@-I..@-II) It becomes this: #+TBLFM: 1$1=vsum(-I..@-II) ^^ when `org-hide-emphasis-markers' is turned on. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Hi Sébastien, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: I think the change of width can impact people who customize a bit the look of their agenda, and rely upong *all* the leaders to be of width 11. That was the motivation for my other patch, about clocking info (to make it go into a 11-char slot). The thread about your other patch is still open, see my last reply. Also, a width of 12 should make it easier to fix alignment issues, so feel free to have a go and fix the ones that disturb you. Please remember not every user has a 3k configuration file, so implementing TRT with emacs -Q is highly recommended here :) -- Bastien
Re: [O] [babel] Commenting out src blocks for tangling
Bastien, Bastien wrote: Rainer M Krug r.m.k...@gmail.com writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Does it work as well for the `:noexport:' tag? Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Commenting out src blocks for tangling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/02/13 10:30, Sebastien Vauban wrote: Bastien, Bastien wrote: Rainer M Krug r.m.krug-re5jqeeqqe8avxtiumw...@public.gmane.org writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Does it work as well for the `:noexport:' tag? I don't think it should. Tangling is something different to export, so there should not be ay interactions between the two in this respect. On the other hand, COMMENT is generic - it is a COMMENT and does not concern anything. So it is applicable for tangling as well. I would actually say it would be counterintuitive if :noexport: would influence tangling as it is governed by a completely different approach in org as well as in what I am doing with the org file. Cheers, Rainer Best regards, Seb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLyahAAoJENvXNx4PUvmCy7UIAMEFBm2FV3MaCaJuurMdh9g4 3JyoLMmgvAEhDHjIfyLHviN+RC7jr/77Xcc+2WwSlMY2RAPE6isRVIFkFR+roSHy TTyYzQu8DOCsZjWHqQM+FLl5sxPvqU0KvUlXXVzND1m48uehJkU07E77eH43AM/Q ThSanN0cIwC25u5PyPe7xi9SRoWXUYGTmsu9Ymg3J2zzmYOn8l9rSb7l68Y3fQTA 9i3SFzgyyXAJy453zNkZsoyOhCgP4kNtwZ9iLVW934sNJE1pVhMsr8wNfYfY+S+s FjNqePE+izC4uHIrSaGaw3COlar6qgPSTKQmF+ueNw/FjPL+TJsPVgSH2pig3+k= =b7/g -END PGP SIGNATURE-
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Bastien, Bastien wrote: Sebastien Vauban writes: PS- Another question: some time ago, there was a ML with all the commits done on Org. This seems to have disappeared (at least from Gmane). A reason for that, or an alternative? I can't remember of such a mailing list. You can subscribe to the RSS feed from http://orgmode.org/cgit.cgi/org-mode.git/ And to the dedicated newsgroup on gwene.org: gwene.org.org-mode.git That must be it: `org-mode.git', which I accessed from Gmane. Thanks. It seems there are now 2 redundants such groups: - nntp+gmane:gwene.cz.or.repo.w.org-mode.git - nntp+gmane:gwene.org.org-mode.git Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Hi Bastien, Bastien b...@altern.org writes: [ ... ] You can subscribe to the RSS feed from http://orgmode.org/cgit.cgi/org-mode.git/ Sorry for hijacking this thread, and sorry for my ignorance. But where can I find this RSS feed? [ ... ] Regards, Andreas
Re: [O] [babel] Commenting out src blocks for tangling
Hi Rainer, Rainer M Krug wrote: On 28/02/13 10:30, Sebastien Vauban wrote: Bastien wrote: Rainer M Krug r.m.k...@gmail.com writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Does it work as well for the `:noexport:' tag? I don't think it should. Tangling is something different to export, so there should not be ay interactions between the two in this respect. On the other hand, COMMENT is generic - it is a COMMENT and does not concern anything. So it is applicable for tangling as well. I would actually say it would be counterintuitive if :noexport: would influence tangling as it is governed by a completely different approach in org as well as in what I am doing with the org file. I've always used :noexport: instead of COMMENT (as I hate the visual clutter of that wide keyword). So, for me, they were equivalent. You must be right, though, that they aren't: COMMENT seems more generic than just export. So, dismiss my request. Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Commenting out src blocks for tangling
Bastien b...@altern.org writes: Rainer M Krug r.m.k...@gmail.com writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Does this ONLY affect tangling or also other code? For instance I often keep LATEX_HEADER, Emacs lisp and the like in a COMMENTed headline. This should still be processed. –Rasmus -- Need more coffee. . .
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Hello, Bastien b...@altern.org writes: thanks for the thorough feedback. I reverted the change I made. Thank you. I need to think more about the issue. I can write a document describing Org syntax, as seen by the parser, if needed. It may serve as a first draft for an appendix in the Org manual. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Andreas, Andreas Leha wrote: Bastien b...@altern.org writes: You can subscribe to the RSS feed from http://orgmode.org/cgit.cgi/org-mode.git/ Sorry for hijacking this thread, and sorry for my ignorance. But where can I find this RSS feed? You can find the group on Gmane (available, then, by NNTP at least). Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Commenting out src blocks for tangling
Hi Rasmus, Rasmus ras...@gmx.us writes: Does this ONLY affect tangling or also other code? Only tangling. HTH, -- Bastien
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: I can write a document describing Org syntax, as seen by the parser, if needed. It may serve as a first draft for an appendix in the Org manual. It will be useful in general; it will spare us miscommunication on various aspects of the parser. So please feel free to go ahead. But be prepared for dealing with some stubbornness on my side: documenting the parser does not mean every issue should be solved thinking in terms of the parser. Sometimes there should be a tradeoff between what the parser can parse and what the UI should offer. More on this later on, probably tomorrow! Thanks in any case, -- Bastien
Re: [O] Exporter interface question
Hello, Carsten Dominik carsten.domi...@gmail.com writes: OK, I pushed this change, maybe it is good if you have a brief look, Nicolas. Thanks for the patch. It looks good. I have one minor suggestion, though. In the following snippet: (eq (marker-buffer org-export-dispatch-last-position) (current-buffer)) wouldn't it be better to check equality with: (org-base-buffer (current-buffer)) instead or simply (current-buffer)? It was great fun and educational to study your very clear code. Thank you. Regards, -- Nicolas Goaziou
Re: [O] :wrap behaviour
Mike Gauland mikely...@no8wireless.co.nz schrieb: I've been using the :wrap parameter extensively, to give me control over the formatting of results from code blocks. For files with many such blocks, it makes sense to specify the formatting at the file level. This works well, unless I want a particular block to be unwrapped. Just specifying :wrap with no parameter wraps the output in #+BEGIN_RESULTS...#+END_RESULTS, which is *not* what I want. The only way to get what I want is to move :wrap from the file level to each block I *do* want wrapped. I'd like to be able to disable wrapping for particular blocks. I've started experimenting with code to do that, but I'm not sure what the best behaviour should be, and would appreciate suggestions. Some ideas I've considered: + Have :wrap by itself disable wrapping; if you want to wrap in BEGIN_RESULTS..END_RESULTS you'll have to specify :wrap RESULTS. + Use a special string (e.g., :wrap off) to disable wrapping. Of course, this makes it impossible to wrap your output in a BEGIN_OFF..END_OFF block, should you ever want to do that. + Use a special symbol instead of a string to turn off wrapping (e.g., :wrap :off) Kind Regards, Mike Gauland Hi, I'd suggest: nowrap regards Tom -- http://www.tomsdiner.de xmpp: t...@goochesa.de
Re: [O] org-agenda-write taking very long (probably because of babel)
Bastien bzg at altern.org writes: Sorry to nitpick on this but please keep the Emacs-like change log small, if not terse. I've thought about this, but then decided that the change does some seemingly superfluous things and I'd better explain why they are necessary. Additionnal details are more than welcome in the commit message though. So I'll cut the changelog after the first sentence and relegate the rest of the explanation to the commit message (if the patch works, of course) -- OK? Regards, Achim.
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Bastien b...@altern.org writes: But be prepared for dealing with some stubbornness on my side: documenting the parser does not mean every issue should be solved thinking in terms of the parser. Sometimes there should be a tradeoff between what the parser can parse and what the UI should offer. Obviously, it depends on the tradeoff. For example, `org-fill-paragraph' contains one. Here is an excerpt of its docstring: For convenience, when point is at a plain list, an item or a footnote definition, try to fill the first paragraph within. This is perfectly fine because it doesn't go against the parser. It merely acts as if the point was elsewhere in the buffer. But it doesn't pretend that the buffer is different. Another possible kind of tradeoff is commands working on a region. Regions don't mean anything for the parser, so commands acting of them may ignore what the parser knows about the buffer. Nevertheless, in other cases, I highly suggest to never discard the output from the parser. A command ought to always consider that the parser is correct. So, if it means to go against it, it should be specified explicitly somewhere (e.g. C-S-up can clearly break the syntax). Commands activated through simple keys (i.e. TAB) on basic syntax (i.e. an headline) shouldn't, IMO, belong to that category, as it would confuse users even more. Regards, -- Nicolas Goaziou
Re: [O] bug: org-export-preprocess-string: Wrong number of arguments when doing org-export-as-html
Karl Voit devnull at Karl-Voit.at writes: #+BEGIN_SRC elisp (org-export-as-html 3 nil nil htmlized-output nil nil) #+END_SRC Am I doing something wrong or is this a bug? You are trying to use the old exporter and pick up code from an earlier version of Org. Regards, Achim.
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Nicolas Goaziou n.goaziou at gmail.com writes: I can write a document describing Org syntax, as seen by the parser, if needed. It may serve as a first draft for an appendix in the Org manual. This would be very welcome. If you think I can be of help with any of this, please let me know. Regards, Achim.
Re: [O] bug: org-export-preprocess-string: Wrong number of arguments when doing org-export-as-html
As I learned the correct name for elisp to use with begin_src is emacs-lisp, not elisp On Feb 28, 2013, at 12:13 PM, Achim Gratz strom...@nexgo.de wrote: Karl Voit devnull at Karl-Voit.at writes: #+BEGIN_SRC elisp (org-export-as-html 3 nil nil htmlized-output nil nil) #+END_SRC Am I doing something wrong or is this a bug? You are trying to use the old exporter and pick up code from an earlier version of Org. Regards, Achim.
[O] Regression: org-export-as-html failure
Using the org-mode included in Emacs HEAD as of yesterday, the following content causes an error when exporting as html: https://gist.github.com/purcell/5055957 Backtrace: Debugger entered--Lisp error: (wrong-type-argument stringp nil) string-match(\\([^]\\)\\([_^]\\) nil) org-export-protect-sub-super(nil) org-export-normalize-links() org-export-preprocess-string(...) org-export-as-html(nil) call-interactively(org-export-as-html) Export as iCal works fine. The list of bare http links seems to be the problem, but until recently org-mode happily exported this content to html. -Steve
Re: [O] Exporter interface question
On 28.2.2013, at 11:22, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: OK, I pushed this change, maybe it is good if you have a brief look, Nicolas. Thanks for the patch. It looks good. I have one minor suggestion, though. In the following snippet: (eq (marker-buffer org-export-dispatch-last-position) (current-buffer)) wouldn't it be better to check equality with: (org-base-buffer (current-buffer)) instead or simply (current-buffer)? I agree, but I think then also setting the mark need to take care to set the mark in the base buffer. Will do this. - Carsten
Re: [O] Exporter interface question
Carsten Dominik carsten.domi...@gmail.com writes: I agree, but I think then also setting the mark need to take care to set the mark in the base buffer. Will do this. AFAICT, this is not necessary. Indirect buffers share markers with base buffer. Regards, -- Nicolas Goaziou
Re: [O] [babel] Commenting out src blocks for tangling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/02/13 10:47, Sebastien Vauban wrote: Hi Rainer, Rainer M Krug wrote: On 28/02/13 10:30, Sebastien Vauban wrote: Bastien wrote: Rainer M Krug r.m.krug-re5jqeeqqe8avxtiumw...@public.gmane.org writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Does it work as well for the `:noexport:' tag? I don't think it should. Tangling is something different to export, so there should not be ay interactions between the two in this respect. On the other hand, COMMENT is generic - it is a COMMENT and does not concern anything. So it is applicable for tangling as well. I would actually say it would be counterintuitive if :noexport: would influence tangling as it is governed by a completely different approach in org as well as in what I am doing with the org file. I've always used :noexport: instead of COMMENT (as I hate the visual clutter of that wide keyword). So, for me, they were equivalent. Follow up: would it be possible to have the same mechanism for tangling, i.e. a tag :notangle:? functioning would be equivalent to property tangle: no but more visible and consistent with the :noexport:? One could also define properties to be tangled and not tangled for different scenarios? Rainer You must be right, though, that they aren't: COMMENT seems more generic than just export. So, dismiss my request. Best regards, Seb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRL03rAAoJENvXNx4PUvmCsGQIAKlPTGJzSlRSvPamZCs2XZqp kR6YIU20QdSLs3Eei7p1VAFTdb4i9Ci6GaX8LfmForM4jrmkUYPqGNFHOl6Q6rwq tCSCxAhIvEWZirs1tmhvj+jIZ2so61LTudMfzToEXPcowoCJXOzjS4GVb/QAysmX qYrY/5OlEw7Qj8YlkmDoeTep4HtSKM941po1VWxm4AJPiyFkipgiQJ3bpVTq5g4p /QIoG7QhNug1kstDx/2LfTXMZMU1zamBS1T5i0rzYHSkpoZwHCAjozXHtpNeW5VB UOJTTctGNERb7sk70SM5ACoQxNne3Ojd5iQdjj+lJf0gKGbz20kT6rHrXUS7d9g= =ryTy -END PGP SIGNATURE-
[O] adding calc formatting to table formulas
Hallo, I've been messing about with getting tables to display formula results as for instance 30,00.00: two-place floating-point precision, and commas grouping digits. I realize I can set these as the defaults in org-calc-default-modes, but I wanted to alter the table formula format string to allow per-field formatting. I made a small edit to org-table.el, which you can see in the attached patch. It assigns the key G to add calc-group-digits t to the front of org-tbl-calc-modes. I think it's uncovered a bug: it only works if I already have calc-group-digits present in org-calc-default-modes, because of the end of org-set-calc-mode: #+BEGIN_SRC emacs-lisp (if (memq var org-tbl-calc-modes) (setcar (cdr (memq var org-tbl-calc-modes)) value) (cons var (cons value org-tbl-calc-modes))) org-tbl-calc-modes) #+END_SRC If the mode is already present (with any value), it is set. If it's not, it's consed onto org-tbl-calc-modes, the resulting new list is jettisoned into the ether, and the original value of org-tbl-calc-modes is returned. I think it would have to look like this to work: #+BEGIN_SRC emacs-lisp (if (memq var org-tbl-calc-modes) (progn (setcar (cdr (memq var org-tbl-calc-modes)) value) org-tbl-calc-modes) (cons var (cons value org-tbl-calc-modes #+END_SRC I'm not terribly confident about this, but perhaps someone could take a look? Thanks, Eric From b2dffa997e59702dfd6480363adb66d0e1e62adf Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen e...@ericabrahamsen.net Date: Thu, 28 Feb 2013 19:40:46 +0800 Subject: [PATCH 36/36] Allow calc-group-digits to be specified in TBLFMT format string. --- lisp/org-table.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index 9cfb4b9..8c684b2 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -2504,6 +2504,7 @@ of the new mark. (if (stringp var) (setq var (assoc var '((D calc-angle-mode deg) (R calc-angle-mode rad) + (G calc-group-digits t) (F calc-prefer-frac t) (S calc-symbolic-mode t))) value (nth 2 var) var (nth 1 var))) @@ -2611,7 +2612,7 @@ not overwrite the stored one. (if (string-match E fmt) (setq keep-empty t fmt (replace-match t t fmt))) - (while (string-match [DRFS] fmt) + (while (string-match [DRFGS] fmt) (setq org-tbl-calc-modes (org-set-calc-mode (match-string 0 fmt))) (setq fmt (replace-match t t fmt))) (unless (string-match \\S- fmt) -- 1.8.1.4
Re: [O] Org-Mode Reference Card bug
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: They should not visually disappear, but they do. No... chances are that it comes from your configuration. Please always assume it does first, then provide a recipe if it's with emacs -Q. Thanks! -- Bastien
Re: [O] [babel] Commenting out src blocks for tangling
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Bastien wrote: Rainer M Krug r.m.krug-re5jqeeqqe8avxtiumw...@public.gmane.org writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Does it work as well for the `:noexport:' tag? No. :noexport: is meaningful in the context of exporting, not in the context of tangling. -- Bastien
Re: [O] Org-Mode Reference Card bug
Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hello Frank and Nick, Nick Dokos wrote: Frank Mueller fm.em...@web.de wrote: Just a remark to the Org-Mode Reference Card (http://orgmode.org/orgcard.pdf). There is a little bug in the spreadsheet description. wrong: sum from 2nd to 3rd hline |:=vsum(@II..@III)| correct: sum from 2nd to 3rd hline |:=vsum(@II..III)| The second at symbol must be deleted for correct working. Why do you think so? I second Nick: your proposition is wrong; it can't work like that. I heard from Frank privately: there was another error in the formula and he thought he had to get rid of the second @ to make it work. That's not correct: the @III form works fine However, the formula without the @ in front of III *also* works in this case. I don't know whether that's an accident or intended behavior. Nick Now, maybe you're hit by a feature here: when setting `org-hide-emphasis-markers' to t, some `@' disappear from the formula (as you see them, while they're there: enable visible-mode and check it!). Is this what happens to you? That's a feature... Best regards, Seb -- Sebastien Vauban
Re: [O] Org-Mode Reference Card bug
Bastien,
Bastien wrote:
Sebastien Vauban writes:
They should not visually disappear, but they do.
No... chances are that it comes from your configuration. Please always
assume it does first, then provide a recipe if it's with emacs -Q. Thanks!
Yes, it does. I still had the following code, from when `@' was unofficially
supported in Beamer to render alert calls:
--8---cut here---start-8---
(defface my/org-alert-face
'((t (:weight bold :foreground black :foreground #FF)))
Face used to display alert'ed items.)
(add-to-list 'org-emphasis-alist
'(@ my/org-alert-face span class=\alert\ /span))
(add-to-list 'org-export-latex-emphasis-alist
'(@ \\alert{%s} nil))
--8---cut here---end---8---
Without that, the problem disappears.
Sorry for the noise.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [patch] ox-koma-letter
Rasmus, On Wed, Feb 27, 2013 at 01:13:25PM +0100, Rasmus wrote: [...] In fact to use the scrlttr2 support in Org I had to adjust a LCO files because it's currently loaded after LATEX_HEADER arguments (so all customization was overwritten). I didn't like that. After this remark I checked my changes and compared them with the default code and behaviour of ox-koma-letter with the result that I reverted all of my deletions. The mentioned feature provides just the right hierarchy for my use case. - LCO overrides everything - options in the file override options in customization - options in customization override defaults in ox-koma-letter Nevertheless I agree that the nil check solution would allow more flexibility. [...] Maybe we should write a user guide *before* further implementation steps. I agree. A question zero is whether we eventually want to have an org-letter which could, in principle, output to something different than scrlttr2. IMO one *good* solution for writing letters is enough. scrlttr2 is perfect for me and covers at least European conventions about how letters should look like. I don't know which LaTeX classes people from other parts of the globe prefer. At least we should try to make the user interface (the list of variables) universal enough to cover other classes as well. Other things: - Cleaning defaults - Only insert KOMAVARs when non-nil. - Which variables to include. E.g. Michael's list vs. every komavar. - consider the order of KOMAVARs, e.g. do we really want LATEX_HEADER before LCO-like stuff? Do we want a KOMA_HEADER (or LETTER_HEADER) which comes after LCO? What to you think? Good plan. I will provide you with the last version of my modification by PM and write a How To. Best regards -- Michael Strey www.strey.biz
Re: [O] org-caldav can't find org-prepare-agenda-buffers
Bastien writes: David Engster d...@randomsample.de writes: Of course I can fix this. But I hope you realize that any third-party code out there that requires an exporter will load the old one from Emacs proper. Yes, I'm well aware of this. The change now lives in the master branch, and will happen when we release 8.0, hopefully in a not so distant future. We will document all incompatible changes in the release notes, as we usually do. I expect third-party maintainers to read these notes. Well, I don't expect it. I'm wondering why you felt the need to rename them. If the new exporters are compatible with the old ones, why not keep the names? This would also avoid that the provided feature differs from the used name prefix (ox-icalendar != org-icalendar). There are several good reasons for this: 1) conflicting library names: we now have org-man.el (for links to man pages) and ox-man.el (for exporting); 2) using the dedicated prefix ox- makes it clear that the library is an export backend, the same way that the ob- prefix makes it clear it is to support a language for Org Babel. In general, the change is incompatible for third-part libraries by is clearly useful for future maintainance, so the trade-off was in favor of making it, and 8.0 is a good time for it. I'm afraid I remain unconvinced. 1) is just one name clash, so just rename one of it. Also, like all the other ox-* packages now, ox-man uses 'org-man' as a prefix for its names; what will 'org-man' use, then? 2) is nice, but IMO not a good enough reason to break compatibility in such a major way. Anyway, you've made a decision and did the rename. Let's just agree to disagree here. The most serious issue is that things will often seem to work because old exporters are pulled in from Emacs, possibly *very* old exporters. They might work, or they might fail for various reasons, making it difficult for users and developers to see what went wrong. Just look at the other bug report by Karl Voit from yesterday; I guess it's the same issue. So if you change your API in an incompatible way (and packages names are part of that), you should at least throw a clear error when the old API is used, and tell the user what happened and how it can be fixed. Hence I would suggest to use something like (eval-after-load org-icalendar '(error The old org-icalendar exporter is deprecated; use ox-icalendar instead.)) An alternative would be to remove the bundled Org from load-path when a newer version is loaded. We do that with CEDET, but it is difficult to do right (because of autoloading, for instance), so I think the eval-after-load hack is better. -David
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Nicolas Goaziou n.goaz...@gmail.com writes: I can write a document describing Org syntax, as seen by the parser [...] That would undoubtedly be useful. There is a need I often have, and never found the time to fill so far, for a dependable Python parser for Org syntax. I thought I could read the Emacs Lisp code of the parser to get a firm grasp of the syntax first, but surely, a formal document acting as a reference might be easier for me to get me started, at least in that it separates what is official and what is incidental in the syntax. I got the vague impression (unsubstantiated right now, I've not been in that area of Org for a while) that it would help uncoupling Org syntax from some Emacs intricacies. I'd need a serious revision to get a firmer opinion. François P.S. Another need I think I'll soon have is some machinery for generating HTML out of dynamic Org snippets, using Python. I could of course have Emacs running in background to serve a Web application, but it looks rather awkward to me, and for one specific application of ours, I really starve for using Org instead of HTML, whenever possible.
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
On Mar 01 2013, François Pinard pin...@iro.umontreal.ca wrote: Nicolas Goaziou n.goaz...@gmail.com writes: I can write a document describing Org syntax, as seen by the parser [...] That would undoubtedly be useful. There is a need I often have, and never found the time to fill so far, for a dependable Python parser for Org syntax. Not sure how complete it is here is one project., https://github.com/tkf/orgparse -- ఎందరో మహానుభావులు అందరికి వందనములు. YYR
Re: [O] emphasis changes filling
Hi Bastien, On 2/20/13, Bastien b...@altern.org wrote: Fixed, thanks! Thank you. Not working though. Reverted? Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] Has anybody noticed ellipses instead of the top line of the window?
The ellipses still occur. Here is an ECM. === # -*- coding: utf-8 -*- #+CATEGORY: executive the long line and logbook are necessary. try with fewer lines and columns. * a *** a /a/ a a a a a a a a a a a a a a a a :LOGBOOK: - Not scheduled, was 2012-08-01 Wed 02:00 .+1d on [2012-12-01 Sat 02:29] :END: *** REF cycling this always puts the ellipsis in :norefile: :PROPERTIES: :CATEGORY: remember :END: * a * a * a * a * a * a * a * a * a * a * a * a * a * a * a * a * a * a * a * a * a === Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] [HTML] region export exports footnotes title
On 2/28/13, Nicolas Goaziou n.goaz...@gmail.com wrote: Anyway, I've moved title out of inner template, which means it shouldn't appear anymore in body-only export. Thank you. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] org-caldav can't find org-prepare-agenda-buffers
David Engster writes: An alternative would be to remove the bundled Org from load-path when a newer version is loaded. We do that with CEDET, but it is difficult to do right (because of autoloading, for instance), so I think the eval-after-load hack is better. That part is actually relatively easy, I have posted code to do that here. The part that gives me headaches is the defcustom definitions, which are nowhere near as easy to defeat and provide yet another way of autoloading stuff in Emacs. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] Exporter interface question
On 28.2.2013, at 13:30, Nicolas Goaziou n.goaz...@gmail.com wrote: Carsten Dominik carsten.domi...@gmail.com writes: I agree, but I think then also setting the mark need to take care to set the mark in the base buffer. Will do this. AFAICT, this is not necessary. Indirect buffers share markers with base buffer. I think it is necessary. If I move a marker to a position in a buffer and another marker to the same position in a connected indirect buffer, both markers are different and point to different buffers. So if I start an export from an indirect buffer, the dispatch marker will point to the indirect buffer. If I later compare the marker-buffer with (org-base-buffer (current-buffer)) I do get a mismatch. So if you want to compare to org-base-buffer, I think I clearly need to set the marker to a position in the base buffer. Regards - Carsten
Re: [O] org-caldav can't find org-prepare-agenda-buffers
Achim Gratz writes: David Engster writes: An alternative would be to remove the bundled Org from load-path when a newer version is loaded. We do that with CEDET, but it is difficult to do right (because of autoloading, for instance), so I think the eval-after-load hack is better. That part is actually relatively easy, I have posted code to do that here. The part that gives me headaches is the defcustom definitions, which are nowhere near as easy to defeat and provide yet another way of autoloading stuff in Emacs. You mean this cus-load thingie? CEDET is actually excluded from that, so we don't have to deal with it. But wouldn't it be enough to remove all properties beginning with 'org-' from custom-loads? -David
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Yagnesh Raghava Yakkala h...@yagnesh.org writes: There is a need I often have, and never found the time to fill so far, for a dependable Python parser for Org syntax. Not sure how complete it is [...] https://github.com/tkf/orgparse Thanks for the pointer. With about 150 commits already, it seems that a good effort was invested in it. Do you know happen to know how conforming it is? I wrote many ad hoc parsers for Org already, but what I would like is something really close to the parser which comes with the new exporter, both in syntax and concept nomenclature, so I could switch to it once and for all and delete all my hacks. :-) François
Re: [O] org-caldav can't find org-prepare-agenda-buffers
David Engster writes: You mean this cus-load thingie? CEDET is actually excluded from that, so we don't have to deal with it. But wouldn't it be enough to remove all properties beginning with 'org-' from custom-loads? First you have to find all symbols, then remove the property and then there are one or two undocumented internal variables that I don't really know yet what they're used for. I don't know if they're any functions for doing this. I'll get around to it eventually. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [babel] Commenting out src blocks for tangling
Bastien b...@altern.org writes: Rainer M Krug r.m.k...@gmail.com writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Thanks! Brilliant! Many thanks. Works like a charm. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1313-g7d4812
Re: [O] Add agenda entries into diary to export weelky calendar
Torsten Wagner torsten.wag...@gmail.com writes: Hi Eric, thanks for the tip. I tried this already. Its printing but has some drawbacks. E.g. I use high resolution monitors in vertical (pivot) mode and a tiling window manager. calfw scales to the current buffer size and this is unfortunately not really compatible with printing. In summary this solution might have to many ways to go wrong. Yes, calfw's output is dependent on window size which is sometimes annoying. It would be nice to be able to override this. However, I noticed a much more interesting way. calfw buffer look almost like org-tables. And voila saving the buffer as org-file and a minimum of Interesting! Never thought of doing that. It does sound like a possible route. Best of luck! -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1313-g7d4812
Re: [O] Has anybody noticed ellipses instead of the top line of the window?
On 02/28/2013 09:59 AM, Samuel Wales wrote: The ellipses still occur. Here is an ECM. === # -*- coding: utf-8 -*- #+CATEGORY: executive the long line and logbook are necessary. try with fewer lines and columns. * a *** a /a/ a a a a a a a a a a a a a a a a :LOGBOOK: - Not scheduled, was 2012-08-01 Wed 02:00 .+1d on [2012-12-01 Sat 02:29] :END: *** REF cycling this always puts the ellipsis in :norefile: [...] can't reproduce this on my computer. If I move the cursor onto cycling and do shift-TAB everything seems normal. First shift-tab collapses everything to * a..., second time I get all the headlines (e.g. just the lines that start with a *), third time I also see the second line of the a-entry and the folded LOGBOOG and PROPERTY drawers. If I remove LOGBOOK and/or make the lines shorter things stay the same. I'm using release_7.9.3f-1257-g5bdb84. Arun
[O] Fixed Re: Bug: turn-on-font-lock b
On 26 Feb 2013, Bastien wrote: [...] The second line made a bit of a mess of my .org files with the 20130224 version of emacs-snapshot ;; (add-hook 'org-mode-hook 'turn-on-font-lock) ; org-mode buffers only org files would still open, but show up as (imaginary example) [[gnus:982.3334][link]] instead of the nice underlined clickable links. Mhh... you mean that, with `global-font-lock-mode' already turned on and (add-hook 'org-mode-hook 'turn-on-font-lock), then the links are not clickable anymore? If so, please try ~$ emacs -Q test.org and report the problem, together with your Emacs and Org versions. Finally had some time to investigate further. But! The problem has gone away, with GNU Emacs 24.3.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2), the Debian Snapshot from 2013-02-26 whether I have (add-hook 'org-mode-hook 'turn-on-font-lock) on or off (;;), org files are fully functional.
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
[CC'ed to Takafumi Arakaki, author of orgparse] Hello François, Do you know happen to know how conforming it is? I can't comment on that, since I haven't really used it for anything. I wrote many ad hoc parsers for Org already, but what I would like is something really close to the parser which comes with the new exporter, both in syntax and concept nomenclature, AFAIU it is pretty cleanly written and even includes tests., though its just a reader and can't be used for exporting right now. By glancing through It seems it doesn't entirely know Org's syntax, especially babel related. tkf may tell us more. Thanks., -- ఎందరో మహానుభావులు అందరికి వందనములు. YYR
Re: [O] :wrap behaviour
Tom Regner tom at goochesa.de writes: I'd suggest: nowrap regards Tom That inspires another idea: specifying :nowrap to turn off wrapping for the block. Thus, #+BEGIN_SRC emacs-lisp :nowrap ... would not be wrapped, even if :wrap were set at a higher level.
Re: [O] Exporter interface question
Carsten Dominik carsten.domi...@gmail.com writes: On 28.2.2013, at 13:30, Nicolas Goaziou n.goaz...@gmail.com wrote: Carsten Dominik carsten.domi...@gmail.com writes: I agree, but I think then also setting the mark need to take care to set the mark in the base buffer. Will do this. AFAICT, this is not necessary. Indirect buffers share markers with base buffer. I think it is necessary. If I move a marker to a position in a buffer and another marker to the same position in a connected indirect buffer, both markers are different and point to different buffers. So if I start an export from an indirect buffer, the dispatch marker will point to the indirect buffer. If I later compare the marker-buffer with (org-base-buffer (current-buffer)) I do get a mismatch. So if you want to compare to org-base-buffer, I think I clearly need to set the marker to a position in the base buffer. Then what about comparing base buffer for both entities? Regards, -- Nicolas Goaziou
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou n.goaziou at gmail.com writes: I can write a document describing Org syntax, as seen by the parser, if needed. It may serve as a first draft for an appendix in the Org manual. This would be very welcome. If you think I can be of help with any of this, please let me know. Thank you for your offer. I appreciate it. To begin with, I am going to produce a terse initial document, on my own. I'll post it on the ML and then, we will able to discuss what can be improved, and how. At this point I'll probably need some help. Regards, -- Nicolas Goaziou
[O] suggest a small change in the doc for org-drill
Being the noob that I am, it took me a few of my rare spare hours to figure out what I was doing wrong with org-drill (sorry Paul!) at: http://orgmode.org/worg/org-contrib/org-drill.html it says Load the file spanish.org. load? m-x load-file /path/to/spanish.org will give (invalid-read-syntax #) and m-x org-drill will immediately finish with 0 results. So, that error (invalid-read-syntax...) sent me on a goose chase. Amusing, but quite time-consuming. It is not load but find file as in C-x f /path/to/spanish.org Maybe that could be changed, or clearified in the docs. Gijs But now that i got it working, I shall start anew on my French! yay
Re: [O] Add agenda entries into diary to export weelky calendar
Hi Torsten, I gave calfw a new try yesterday. It works well now and I really like it! I tried to do, as you suggested, a export via htmlfontify-buffer. It seems like it has problems with the cell alignment for those cells which contain an appointment. Please see the attached picture (I can send you the html file in a private mail if you are interested to see the html code). Could be the trouble of a non-monospace font, As far as I know Japanese fonts are monospace? Calfw assumes that the calfw buffer uses the monospace font. If you usually use proportional fonts in emacs, you can change the buffer font with cfw:calendar-mode-hook. Ref: Re: [O] Calendar-like view of the org-agenda http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg00882.html The generic htmlfontify-buffer might be a bit to simple. E.g. as you can see in the image, I use a dark colour scheme in emacs. This is also used in the export, making it difficult to print. How about a real export function in calfw? Similar to what the calendar/diary offers. I could help to work on a LaTeX template using graphical elements e.g. by using TikZ [1]. There are SVG-based generators and solutions written in python as well. However, I have no idea how move the data of calfw into a template or into such a script. My elisp knowledge is almost non existing. Calfw has extension point for the many view styles, however I think it is not easy to implement. Anyway, I will consider the function cfw:export-view-to-org which is mentioned by the another message. Regards, -- SAKURAI, Masashi (family, given) m.saku...@kiwanami.net
Re: [O] suggest a small change in the doc for org-drill
Gijs Hillenius g...@hillenius.net writes: Hi Gijs, Load the file spanish.org. load? I've replaced it by Open. Thanks for reporting this. -- Daimrod/Greg pgpd4frI70f1U.pgp Description: PGP signature
Re: [O] [Orgmode] Extending paste to auto-archive a copied image
Hi,
I wrote some code to fulfill the proposal you discussed two years ago, using
xclip and perl to yank image file in link format for org, and save the file
named after the image's timestamp.
Which means it's working for xwin clones, and I'm currently using Ubuntu 12.10.
The function is named x-selection-value2, attached at the end of this mail.
I'm binding it to C-v.
The naming of the yanked file is kind of casual. Please feel free to change it.
From: Bastien
Subject: Re: [Orgmode] Extending paste to auto-archive a copied image
Date: Sat, 12 Feb 2011 12:25:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
Hi Marcelo,
Marcelo de Moraes Serpa address@hidden writes:
What I am suggesting is, somehow hook into the moment the file is
pasted/dragged and run some code.
This would require code in Emacs. I'm not familiar at all with Emacs
ability to recognize drag'n droped files (as I don't use drag'n drop)
but perhaps other do and might suggest how to set a hook when Emacs
copies external content/files/whatever from X.
--
Bastien
(defun x-selection-value2 ()
using xclip and perl to yank image file in link format for org, and save the
file named after the image's timestamp
(interactive)
(when (and (executable-find xclip) (getenv DISPLAY))
(let (clip-targets clip-text)
(when t
(progn
(setq clip-targets (shell-command-to-string xclip -o -selection
clipboard -t TARGETS|perl -e '$ret=0;while(){if ($_ eq
\image/png\\n\){$ret+=4 ;$result = `xclip -o -selection clipboard -t
TIMESTAMP`;}$ret=+1 if ($_ eq \STRING\\n\) or ($_ eq
\UTF8_STRING\\n\);$ret+=2 if $_ eq \text/html\\n\;}if($ret eq 6){print
\webimg\};if($ret eq 4){print \clipboardimg\};if($ret eq 1){print
\string\};if($ret eq 0){print \nothing\};'))
(message (concat type : clip-targets))
(when (string= webimg clip-targets)
(progn
(setq clip-text (shell-command-to-string (concat perl -e '$buffn=\
(file-name-directory (buffer-file-name)) \;$result = `xclip -o -selection
clipboard -t TIMESTAMP`;chomp($result);$fn = `xclip -o -selection clipboard -t
text/html`;$fn=~/src=\(.*?)\/i;system(\xclip -o -selection clipboard -t
image/png $buffn$result.png\);print
\[[file:\.$result.\.png]\.$1.\]\;')))
(insert clip-text)
)
)
(when (string= clipboardimg clip-targets)
(progn
(setq clip-text (shell-command-to-string (concat perl -e '$buffn=\
(file-name-directory (buffer-file-name)) \;$result = `xclip -o -selection
clipboard -t TIMESTAMP`;chomp($result);system(\xclip -o -selection clipboard
-t image/png $buffn$result.png\);print
\[[file:\.$result.\.png]\.$result.\.png]$buffn\;')))
(insert clip-text)
)
)
)
)
))
(or clip-text (x-selection-value))
)
[O] Code blocks (partially) inherit buffer colors
When I export a code block to HTML, I've noticed that some (but not all) of the characters in the resulting HTML file have the same background color as my Emacs buffer at the time I exported. For example, if I export --- #+begin_src python a = 5 #+end_src the code block in the resulting HTML file has a very pale background, except for the characters a and 5, both of which are displayed with a dark blue background that looks like it's the same as the background color in my Emacs buffer. This looks rather odd... I can work around this problem by changing the color-theme in my Emacs buffer before exporting, but is there a better solution? Thanks. Richard Stanton
Re: [O] Code blocks (partially) inherit buffer colors
Richard Stanton stan...@haas.berkeley.edu writes: When I export a code block to HTML, I've noticed that some (but not all) of the characters in the resulting HTML file have the same background color as my Emacs buffer at the time I exported. For example, if I export --- #+begin_src python a = 5 #+end_src the code block in the resulting HTML file has a very pale background, except for the characters a and 5, both of which are displayed with a dark blue background that looks like it's the same as the background color in my Emacs buffer. This looks rather odd... I can work around this problem by changing the color-theme in my Emacs buffer before exporting, but is there a better solution? Thanks. Richard Stanton See the documentation of the `org-export-htmlize-output-type' variable. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Code blocks (partially) inherit buffer colors
Thanks, Eric. -Original Message- From: Eric Schulte [mailto:schulte.e...@gmail.com] Sent: Thursday, February 28, 2013 9:29 PM To: Richard Stanton Cc: emacs-orgmode@gnu.org Subject: Re: [O] Code blocks (partially) inherit buffer colors Richard Stanton stan...@haas.berkeley.edu writes: When I export a code block to HTML, I've noticed that some (but not all) of the characters in the resulting HTML file have the same background color as my Emacs buffer at the time I exported. For example, if I export --- #+begin_src python a = 5 #+end_src the code block in the resulting HTML file has a very pale background, except for the characters a and 5, both of which are displayed with a dark blue background that looks like it's the same as the background color in my Emacs buffer. This looks rather odd... I can work around this problem by changing the color-theme in my Emacs buffer before exporting, but is there a better solution? Thanks. Richard Stanton See the documentation of the `org-export-htmlize-output-type' variable. -- Eric Schulte http://cs.unm.edu/~eschulte
