Re: [O] Calendar-like view of the org-agenda
Hi Bastien At Thu, 07 Jul 2011 17:32:44 +0200, Bastien wrote: : SAKURAI Masashi m.saku...@kiwanami.net writes: Then, I use the function org-agenda-get-day-entries to get schedule items of the org-agenda-files. The function can receive some arguments to limit the tasks, but I didn't understand exactly. See the attached patch -- org-agenda-get-day-entries can take more arguments like :scheduled :deadline to help reduce the size of listed entries. See the docstring of org-diary, which understands the same list of arguments. Thank you for your advice and patch. I will merge it. One question, is it fixed variable for an user? I mean, one often changes the argument parameter to change the filtering in a single Emacs session. If one frequently changes it, should I design the UI to change it and re-draw the calendar? -- SAKURAI, Masashi (family, given) m.saku...@kiwanami.net
Re: [O] Calendar-like view of the org-agenda
Hi Tassilo and Bastien +(defvar cfw:org-agenda-schedule-args '(:scheduled) + Default arguments for collecting agenda entries.) I'd go with a default value of `nil' meaning put every org entry with a timestamp into the calfw view. Only getting SCHEDULED org tasks there is a somewhat peculiar default. Agreed -- I used :scheduled in this example just to make sure to illustrate the filtering. Thank you for your advice. I merged and pushed it to master branch. -- SAKURAI, Masashi (family, given) m.saku...@kiwanami.net
Re: [O] patch org-mode Makefile - solve a couple debian build problems and a slackware build problem
Hi Jude, Jude DaShiell jdash...@shellworld.net writes: If a make is done on debian squeeze with default org-mode install-info which is debian's version of install-info complains that it's not gnu info and tells you to use ginstall-info when a make install-info-debian or make install-info is tried and neither one of those switches for make upgrades the info documentation. If it tells you that it is GNU info, then you've actually called /usr/bin/install-info and it should — aside from this message — work: what did you set $infodir to? Does this directory exist and have the new info files been copied into it (there may be old files still there, so please check the date)? Anyway, from the man pages it looks like this patch should remove the incompatibility between dpkg install-info and GNU install-info on Debian and not change anything for others. From a2399077495e716d0dd1faa3d491a379d2015065 Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Sun, 10 Jul 2011 08:42:20 +0200 Subject: [PATCH] possible solution for Debian install-info charade --- Makefile |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index a09ed83..a2940b0 100644 --- a/Makefile +++ b/Makefile @@ -221,9 +221,6 @@ install-lisp: $(LISPFILES) $(ELCFILES) install-info: $(INFOFILES) if [ ! -d $(infodir) ]; then $(MKDIR) $(infodir); else true; fi ; $(CP) $(INFOFILES) $(infodir) - $(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir) - -install-info-debian: $(INFOFILES) $(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES) autoloads: lisp/org-install.el -- 1.7.6 You will still get the warning about the two install-info versions on Debian if you call it through their wrapper script, but based on my (limited) testing it should work with all versions of install-info if the rest of the setup is OK. Can you please test this? 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] Calendar-like view of the org-agenda
Hi Masashi, SAKURAI Masashi m.saku...@kiwanami.net writes: I merged and pushed it to master branch. thanks a lot! -- Bastien
Re: [O] patch org-mode Makefile - solve a couple debian build problems and a slackware build problem
I just ran make update make all sudo make install sudo make install-info-debian and updated org-mode to 7.6. I put two mods into the org-mode default Make file. The prefix I changed to /usr and the change suggested on install-info-debian target changing out $(infodir) with ginstall-info I think on line 227 and won't know if this patch will work since the message nothing to be done for install-info-debian came back. A command of info org tells me the documentation is current for org 7.50. When either documentation gets updated or version of documentation gets updated (may be enough to install new documentation just doing that) I'll be able to do some testing. I need to read up on patch before trying to extract patches from messages and applying them locally so I do it right.On Sun, 10 Jul 2011, Achim Gratz wrote: Hi Jude, Jude DaShiell jdash...@shellworld.net writes: If a make is done on debian squeeze with default org-mode install-info which is debian's version of install-info complains that it's not gnu info and tells you to use ginstall-info when a make install-info-debian or make install-info is tried and neither one of those switches for make upgrades the info documentation. If it tells you that it is GNU info, then you've actually called /usr/bin/install-info and it should ? aside from this message ? work: what did you set $infodir to? Does this directory exist and have the new info files been copied into it (there may be old files still there, so please check the date)? Anyway, from the man pages it looks like this patch should remove the incompatibility between dpkg install-info and GNU install-info on Debian and not change anything for others.
Re: [O] patch org-mode Makefile - solve a couple debian build problems and a slackware build problem
I'll know when the documentation gets an update. Thanks.On Sat, 9 Jul 2011, Nick Dokos wrote: Jude DaShiell jdash...@shellworld.net wrote: If a make is done on debian squeeze with default org-mode install-info which is debian's version of install-info complains that it's not gnu info and tells you to use ginstall-info when a make install-info-debian or make install-info is tried and neither one of those switches for make upgrades the info documentation. OK. Since a debian-specific target exists and is documented, how about using ginstall-info explicitly in the install-info-debian target in the Makefile like this: --8---cut here---start-8--- install-info-debian: $(INFOFILES) ginstall-info --infodir=$(infodir) $(INFOFILES) --8---cut here---end---8--- Will this work for debian? Nick
Re: [O] patch org-mode Makefile - solve a couple debian build problems and a slackware build problem
Hi Jude, Jude DaShiell jdash...@shellworld.net writes: I just ran make update make all sudo make install sudo make install-info-debian and updated org-mode to 7.6. That does not work, you would need to do sudo make install-info sudo make install-info-debian with the original Makefile - only change the prefix, not anything else. The patch I gave you removes the install-info-debian target and can be applied by saving the whole message to patchfile and then calling git apply patchfile Alternatively you can just say patch patchfile in the org directory. Then a make update make all sudo make install sudo make install-info should result in an updated info documentation (i.e. the first page should have This manual is for Org version 7.6. HTH, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
The latest patch by Achim Gratz works for this problem for make install-info on debian squeeze. The warning about using ginstall-info comes up, but the documentation updates from 7.5 to 7.6 none the less.
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
Hi Jude, Jude DaShiell jdash...@shellworld.net writes: The latest patch by Achim Gratz works for this problem for make install-info on debian squeeze. The warning about using ginstall-info comes up, but the documentation updates from 7.5 to 7.6 none the less. Thanks for confirming. Achim and Nick, can I safely apply your patch or was it still a beta version? Thanks, -- Bastien
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
Bastien b...@altern.org writes: Achim and Nick, can I safely apply your patch or was it still a beta version? My patch obsolotes what Nick was trying to achieve, but I'm just looking at some other stuff in the Makefile that looks like it needs a makeover, so I'd suggest we discuss this first and I'll submit a proper patch that goes into patchwork. Here it goes: It looks like the two targets relase and fixrelease have not actually been used and at least fixrelease would not do what the comment is trying to imply it should be doing. If nobody uses them, these two targets should probably be removed. Then there's all the stuff that makes sense only on the orgmode server, do not run on your computer: if so, would it not be preferrable to fail these targets when not run on the orgmode server, either by checking an environment variable or a file that only exists on the server? Is there any reason why the phony targets are not declared to be phony? Even if GNU make is not used that should be compatible. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
[O] RFC: Revisit org-export-content-div (in the context of org-s5)
Couple of comments wrt org-export-content-div: 1. Should be renamed to org-export-html-content-div 2. If we look at org-s5.el[1], we see the following usage where apparently div id=content is essentially replaced by div class=presentation with a bunch of leading and trailing stuff. #+begin_src emacs-lisp (lambda () (save-excursion (replace-regexp (regexp-quote div id=\content\) (let ((info `((author . ,author) (title . ,title) (date . ,(substring date 0 10) (join `(div class=\layout\ div id=\controls\!-- no edit --/div div id=\currentSlide\!-- no edit --/div div id=\header\/div div id=\footer\ ,(org-fill-template org-s5-title-string-fmt info) /div /div div class=\presentation\ ,(org-fill-template org-s5-title-page-fmt info))) #+end_src 3. Considering (2) above it might be worthwhile defining the customization as below (for a first cut) #+begin_src emacs-lisp (defcustom org-export-html-content-div %s div %s %s ; note the html in prefix The name of the container DIV that holds all the page contents. :group 'org-export-htmlize :type 'string) #+end_src With the above re-definition I believe there is an opportunity to suck #+begin_src emacs-lisp-mode (if (or link-up link-home) (concat (format org-export-html-home/up-format (or link-up link-home) (or link-home link-up)) \n) ) #+end_src and even the entire preamble in to #+begin_src emacs-lisp (when (plist-get opt-plist :html-preamble) ;; etc etc etc ) #+end_src the suffix %s in the above custom definition. Or alternatively one can suck the suffix %s in to preamble string. Just a thought. WDYT. Jambunathan K. Footnotes: [1] https://github.com/eschulte/org-S5/blob/master/org-export-as-s5.el at around line 60 or so. --
[O] default PRIORITY
Hi all It seems to me that there is an inconsistency with the default PRIORITY in searches and custom agenda blocks of types like tags or tags-todo. Assume org-default-priority B and an agenda file #+begin_src org ,* TODO [#C] low prio ,* TODO default prio ,* TODO [#A] high prio #+end_src When org-agenda-custom-commands contains #+begin_src emacs-lisp (x test ((tags-todo PRIORITY=\C\))) #+end_src the agenda block looks like this: TODO [#A] high prio TODO default prio TODO [#C] low prio This is like expected: The item without PRIORITY gets the default B for sorting from org-get-priority called in org-scan-tags. When org-agenda-custom-commands contains #+begin_src emacs-lisp (x test ((tags-todo PRIORITY=\B\))) #+end_src the agenda block is empty. I expected that the item without PRIORITY matches and is shown because I expect it to get the default B also when matching. But this is not the case for org-cached-entry-get called in org-scan-tags at (eval matching). Even worse: The item without PRIORITY is shown with PRIORITY\B\. During debugging it seemed to me that this is simply because the item gets the PRIORITY when matching. Now I am not sure whether I would be able to provide a patch and how this should be solved: Only in org-scan-tags or better in org-entry-properties and/or friends like org-entry-get, org-cached-entry-get and maybe more? Tested with current release_7.5-416-g27360b1 and Emacs 23.3.1 Michael
Re: [O] RFC: Revisit org-export-content-div (in the context of org-s5)
#+begin_src emacs-lisp (defcustom org-export-html-content-div %s div %s %s ; note the html in prefix The name of the container DIV that holds all the page contents. :group 'org-export-htmlize :type 'string) #+end_src Btw, The :group tag seems NOT OK to me as well. Jambunathan K.
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
Bastien b...@altern.org wrote: Hi Jude, Jude DaShiell jdash...@shellworld.net writes: The latest patch by Achim Gratz works for this problem for make install-info on debian squeeze. The warning about using ginstall-info comes up, but the documentation updates from 7.5 to 7.6 none the less. Thanks for confirming. Achim and Nick, can I safely apply your patch or was it still a beta version? Achim's patch is different from mine (which might very well be wrong: I was trying to divine what is happening without access to a system that runs Debian or Slackware). I applied Achim's patch and it works on my Ubuntu system (I get the same warning that this is GNU install-info, not dpkg install-info that Jude gets, which is fine - if that's all that's different, then we can document that). However, I don't understand how changing the command affects other systems: in particular OS X and/or Windows (as well as other Linux distros and other Unixes), so I will plead nolo contendere here, but I wouldn't apply it until people on those systems test it and report success. My worry is this: before Achim's patch, the other systems run the following command: $(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir) I presume without trouble. After his patch, they run $(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES) Does the install-info on other systems really grok the --infodir option? Isn't it just straight GNU install-info? What am I missing? Nick
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
Nick Dokos nicholas.do...@hp.com writes: My worry is this: before Achim's patch, the other systems run the following command: $(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir) The invocation with --info-files is only understood by GNU install-info, that was presumably the reason for introducing the extra target install-info-debian. I presume without trouble. After his patch, they run $(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES) This invocation does the same thing (per the man and info manuals) on GNU install-info, but is also compatible with the older install-info supplied by Debian, which does not know about some options of GNU info. So whichever install-info gets chosen (since we cannot know what $PATH is set to) should work. If it is GNU install-info, then the warning message is printed that we actually called a wrapper script that hands off its arguments to ginstall-info. If it is the dpkg install-info, then we get a bunch of verbose output that GNU install-info doesn't produce, but it also results in a working info page. Does the install-info on other systems really grok the --infodir option? Isn't it just straight GNU install-info? What am I missing? On Windows you can either have MSys or Cygwin to get install-info. Both really are GNU install-info, so unless there is yet another install-info I don't see why this would not work. 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] patch makefile solve a couple debian build problems and a slackware build problem
Achim Gratz strom...@nexgo.de writes: [...] I just realize that the Makefile already uses several GNU make extensions. If it's OK to use them (specifically include files and conditional variable assignment), that would help to restructure the Makefile so that it can be customized and maintained more easily. Let me know if I should work on a proposal in that direction or not. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
I'm on my slackware system right now. Here's the contents of /etc/issue and I left this as the out of the box default: Welcome to \s \r (\l) I had to do git close with the line in the installation notes to get org-mode to update. The git program refused to overwrite the original Makefile. So having done that I ran make all sudo make install sudo make install-info and there were no errors or warnings of any kind. info org tells me org documentation is at 7.6 now too. On Sun, 10 Jul 2011, Achim Gratz wrote: Nick Dokos nicholas.do...@hp.com writes: My worry is this: before Achim's patch, the other systems run the following command: $(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir) The invocation with --info-files is only understood by GNU install-info, that was presumably the reason for introducing the extra target install-info-debian. I presume without trouble. After his patch, they run $(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES) This invocation does the same thing (per the man and info manuals) on GNU install-info, but is also compatible with the older install-info supplied by Debian, which does not know about some options of GNU info. So whichever install-info gets chosen (since we cannot know what $PATH is set to) should work. If it is GNU install-info, then the warning message is printed that we actually called a wrapper script that hands off its arguments to ginstall-info. If it is the dpkg install-info, then we get a bunch of verbose output that GNU install-info doesn't produce, but it also results in a working info page. Does the install-info on other systems really grok the --infodir option? Isn't it just straight GNU install-info? What am I missing? On Windows you can either have MSys or Cygwin to get install-info. Both really are GNU install-info, so unless there is yet another install-info I don't see why this would not work. Regards, Achim.
Re: [O] Release 7.6
Hi Bastien, Joost Kremers joostkrem...@fastmail.fm writes: On Thu, Jul 07, 2011 at 09:16:24AM +0200, Bastien wrote: I'm releasing Org 7.6. could it be that the new release hasn't been merged into maint yet? You're right -- it's done now, let me know if that's okay for you. Yes, I've just upgraded. Thanks! -- Joost Kremers Life has its moments
[O] Bulk cut in agenda view
I often need to purge DONE items from my org files. I have set up a special agenda view for checking those items and cutting some subtrees from it using bulk commands. I'm using a function adapted from the example in the manual (I've no idea if it's the best way to do it however) : , | (defun bulk-cut () | (interactive P) | (let* ((marker (or (org-get-at-bol 'org-hd-marker) |(org-agenda-error))) |(buffer (marker-buffer marker))) | (with-current-buffer buffer | (save-excursion | (save-restriction | (widen) | (goto-char marker) | (org-back-to-heading t) | (org-cut-subtree)) ` Typing B f bulk-cut RET removes the selected items but it's a lot of typing for a very useful action in my opinion. Could it be added to the list of default bulk actions, with a X key for example ?
Re: [O] Calendar-like view of the org-agenda
Marcus Klemm marcus.kl...@googlemail.com writes: Hi Marcus, I've also made the characters used for table rendering customizable, so that you can use nice unicode glyphs. This is awesome! Could it somehow incorporated into orgmode to draw the tables there? I don't think that would be a good idea, cause in org you partly draw the tables on your own, that is, you write |TAB for another row etc.. You don't want to have to insert unicode characters there. Bye, Tassilo
[O] New backend for org-agenda: (Was Calendar-like view of the org-agenda)
Hi Bastien, At Fri, 08 Jul 2011 10:53:08 +0200, Bastien wrote: : the re-design of the whole org-agenda-list algorithm seems to be needed, because the key function org-agenda-get-day-entries requires only one date and the subsequent dependent functions also are designed by the API. FWIW, I'm all ears -- if you have ideas on how to make org-agenda-list more effective please let us know, I could try to implement them. How about caching of schedule items? My idea is as follows. When one query schedule items for the first time, the backend parses the org buffer and stores all schedule items with a buffer local variable. From the next time of the query, the backend can use the cache data without parsing the buffer text. Then, because The backend has a model of schedule items, in addition to org-agenda-get-day-entries, we can define some useful API for schedule items, such as org-agenda-get-entries-by-range(begin end). I illustrated this idea: [Diagram for caching schedule items] https://cacoo.com/diagrams/RcNaxILLHDGZlr1L#4B823 Org schedule seems to consist of two types, simple items and repeat items. So, I think that the backend should execute two type queries. [Query and Data Structure] https://cacoo.com/diagrams/RcNaxILLHDGZlr1L#C071E Of course, because I have used orgmode not so long time, this idea is not useful or too simple to handle the org schedules. Here are other implementations: The Howm schedule API (howm-reminder-search) enumerates all schedule items. The API user can filter them easily. However, the enumeration employs full-text searching using grep command, so it takes a long time to be done the query. calfw-howm.el has a cache data and the user can refresh it explicitly. Another schedule API is CalDAV. This is a specification for the schedule server, such as Apple iCal server and Google Calendar. [Calendaring Extensions to WebDAV (CalDAV) RFC 4791] http://www.webdav.org/specs/rfc4791.html http://en.wikipedia.org/wiki/CalDAV This specification has many API for query. It is very heavy spec, but I think it may be a hint for designing query API for orgmode schedule items. Regards -- SAKURAI, Masashi (family, given) m.saku...@kiwanami.net
Re: [O] Fwd: Some bugs with ob-clojure.el and some more with ob-sh.el
Hi Robert, I've pushed some updates to ob-clojure which should address the overly eager parsing of results which was splitting your literal string results. I've also pushed up more general enforcement of the verbatim keyword. Clojure still does not support the :results output keyword combination. For some reason the clojure-specific slime evaluation functions do not seem to hand back STDOUT information as readily as common lisp slime evaluation functions. I unfortunately don't have a local Clojure-swank/slime install, and can't check this out, but if you can find a way to access STDOUT from Clojure-swank/slime I'll be happy to integrate it into ob-clojure. Please let me know if you notice any other problems. Best -- Eric Robert McIntyre r...@mit.edu writes: -- Forwarded message -- From: Robert McIntyre r...@mit.edu Date: Sat, Jul 9, 2011 at 11:04 AM Subject: Re: [O] Some bugs with ob-clojure.el and some more with ob-sh.el To: Bastien b...@altern.org Great idea --- I updated my version of Org such that: M-x org-version returns: Org-mode version 7.6 (release_7.6.32.ga493b.dirty) Now even more of my tests fail :( I've updated the gist accordingly. It's at https://gist.github.com/1073383 In particular, ob-clojure.el doesn't seem to respect spaces when a function returns a literal string. Thanks for responding so fast, and If I can do anything else to help please let me know. sincerely, --Robert McIntyre On Sat, Jul 9, 2011 at 7:13 AM, Bastien b...@altern.org wrote: Hi Robert, Robert McIntyre r...@mit.edu writes: I've made a gist at https://gist.github.com/1073383 Thanks for this feedback. that details some problems with ob-clojure.el and ob-sh.el. In particular, there are a few problems with :results verbatim/scalar and :results output for the two modes. M-x org-version returns: Org-mode version 7.5 (release_7.5.516.gf06e.dirty) Can you check if you have the same errors with the latest Org version -- either 7.6 or the one from git? Thanks a lot, -- Bastien -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Don't ask, don't run
Eric S Fraga e.fr...@ucl.ac.uk writes: ken.willi...@thomsonreuters.com writes: Hi, I know from the manual that I can set 'org-confirm-babel-evaluate' to t, or nil, or a function, to control whether I'm asked permission to run a code block. However, that only gives me two choices - ask the user, or pretend the user said yes. Sometimes I'd like to pretend the user said no, without asking. Specifically, I'd like to always manually control when code blocks are executed. When exporting, I don't want them executed (and I don't want to be asked about my dozens of blocks each time). When hitting C-c C-c manually, I just want it to run (and I don't want to be asked whether I'm sure). Is there a similar variable, or perhaps an export option, that will give me this kind of workflow? Thanks. I can't help you directly although I also often want the behaviour you are describing. One workaround that should give you what you want is to enable evaluation without prompting (org-confirm-babel-evaluate: nil) and to have the results from runs cached so that, when exporting, the source code blocks shouldn't have to execute; see [[info:org#cache]]. There is no way to customize `org-confirm-evaluate' to achieve this behavior, however it can be accomplished through creative use of the :eval header argument, by using the `org-export-current-backend' variable to inhibit evaluation during export. #+begin_src emacs-lisp :eval (if org-export-current-backend never yes) :exports results (message launch missles) #+end_src Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [babel] inline call within table formula?
Hi Eric, The `sbe' macro can be used to evaluate code blocks in table formula. For Example: | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 3.5 | #+TBLFM: @7$1='(sbe mean (lst @1..@6)) #+source: mean #+begin_src emacs-lisp :var lst=() (let ((num (car lst)) (nums (cdr lst))) (/ (float (+ num (apply #'+ nums))) (1+ (length nums #+end_src See the documentation string of this macro for more information. Best -- Eric Eric S Fraga e.fr...@ucl.ac.uk writes: Hi, Quick question: I'd like to use a babel inline call to calculate something in a table based on other values in the table. Is this possible? Probably using elisp directly? If so, I cannot figure out what the magic incantation should be! I hope somebody can help. For illustration, I'd like to do something like this: #+source: f #+begin_src octave :var x=[1 3 5] sin(x) #+end_src | x1 | x2 | x3 | f| |+++--| | 1 | 3 | 5 | Apply call_f($1..$3) here | Thanks, eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Regression bug in tangle/weave
Neeum Zawan mailingli...@nawaz.org writes: Eric Schulte schulte.e...@gmail.com writes: Hi, Indeed this example below no longer works, however I believe the new behavior is both desired and permanent. I'll explain and include an option for how your example could be restructured to work with the new code. We ran into problems automatically removing trailing newlines from code block bodies as in some languages (looking at you Python and Haskell) things like trailing newlines are of syntactic importance. In your example this behavior results in the insertion of newlines after file-name and file-version. Babel is careful to preserve line prefixes when expanding references in comments, so it then reproduces the # Generated from portion of that line for every line of the expanded noweb references. I would suggest the following alternatives, either using a data references in stead of a code block reference as in the file-version example below, or using an evaluated code block as in the file-name example below. Hope this helps. Oh dear. Am I to blame for this? When I reported the newline issue, somewhere in the back of my mind I knew it probably would have some ugly consequences. Now I see them. An evaluated code block seems inelegant/confusing if one intends to export that code as part of the document. A data reference seems OK, but I take it you can't have references within it? Unfortunately, I see no easy solution... In these cases, I feel that a data reference is the simplest, most natural solution, and lightest-syntax solution in these cases, and I don't see it as an ugly compromise. Just my opinion. As I mentioned above I feel that the current behavior is both desired and permanent, and I'm happy that you raised the newline issue that help lead to this behavior. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Calendar-like view of the org-agenda
Hello Tassilo, Tassilo Horn tassilo at member.fsf.org writes: I don't think that would be a good idea, cause in org you partly draw the tables on your own, that is, you write |TAB for another row etc.. You don't want to have to insert unicode characters there. You are right, it would not be enough to simply replace the characters, one would have to translate the traditional input to the unicode characters on the fly. But it looks sooo much better and would be, strictly speaking, still just plain text. I love org-mode for its power and flexibility but I grew up using an Amiga, laughing at the MS-DOS users with their ancient text mode interfaces and I still can't force myself to like that aspect of org. So everything that makes it look more graphic is welcome to me.
Re: [O] [PATCH] Fix html export of footnotes with lists, tables, quotes, etc.
On Sun, Mar 27, 2011 at 4:28 PM, Jambunathan K kjambunat...@gmail.com wrote: Puneeth Attached is a patch that allows having lists, tables, blockquotes and other org blocks in footnotes. Source code blocks still don't work. Would you mind posting an example test case that covers all the above cases. I am trying to merge my branch with the most recent changes in the master. I would like to make sure that I break nothing when my changes gets merged to the master. Hi Jambunathan, Sorry for the delayed response, but here is a test case that covers the above cases. I have added your org sample to my test.org file. org-parse.el Co seems DTRT even without a fix. During the verification process, I discovered that having a Table in a Footnote section is forbidden by atleast OpenOffice i.e., While creating the footnote definition, Insert of Tables is greyed out in the UI. I am not sure what the OpenDocument spec says about having Tables in Footnotes. Anyways that is where things stand wrt tables in footnotes. This is for the sake of public record. Jambunathan K. --
Re: [O] Thanks for Lilypond export (and minor comments)
Hi Bastien, On Sat, 09 Jul 2011 10:44:45 +0200 Bastien b...@altern.org wrote: http://www.kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt Nice read, thanks. I guess the relevance of such a development model mainly depends on how many developers are trying to collaborate, and at what pace. Let's see if a problem emerges from our current development model, and how to fix it then. Of course. :) A model based on Junio's notes just came to my mind and I thought maybe I should share it just so that it stays in the archive for the future. So far I think we can break down the development of org into certain feature enhancements or new features and bug fixes. So maybe there could be topic branches based on master for the various features (lists, babel, latex export, odt export, any future attempt at code refactoring and so on) and a bugfix branch based on maint. Since usually a small set of devs work on each feature, it might be easier to collaborate and be more adventurous (since its not a change to master) during development. Also this would mean people interested in a specific feature could simply pull in the HEAD of these branches from time to time. And once the feature devs think the enhancements are relatively stable, you could pull it into master (a simple two way merge). Now since the bugfix branch is based on maint, it will be a lot easier to release critical fixes and could be merged into all branches (any topic branch or master). This will let you release point releases very easily (just fast-forward maint and tag). Master could host documentation or other non-critical bug fixes. For major releases you would need to do a few three-way merges (i.e. pulling several topic branches into master or pulling the bugfix branch into master) and finally make a commit changing the release tags and version strings and merge into maint and tag it as release_n+1. Then the bugfix branch could be fast-forwarded to the new release and the process can start over again. To summarise, the above is solely based on merges and no need for tracking down individual commits (unless something goes wrong of course :-p). This makes full use of git's capability of three way merges and hopefully simplifies a lot of the maintainer tasks. :) PS: On the downside this does imply you would have to understand the various merge strategies git uses very well. :-p -- Suvayu Open source is the future. It sets us free.
Re: [O] Inline tasks: tiny export problem
Hello,
Sebastien Vauban
wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:
When using italic and bold attributes in the contents of inline task, these
are not properly exported.
- Org Input:
#+begin_src org
*** Test
- This is out of /scope/.
- That *maybe*.
*** END
#+end_src
- LaTeX Output:
#+begin_src latex
\todo[inline,caption={}]{\textbf{\textsf{ Test}}\\
\begin{itemize}
\item This is out of /scope/.
\item That *maybe*.
\end{itemize}
}
#+end_src
I can't reproduce it on default setup. Would you mind sharing your
configuration or, better, bisecting it until you find the culprit?
Regards,
--
Nicolas Goaziou
Re: [O] Feature request or did I overlook ..
Am 09.07.2011 23:55, schrieb Bastien: Hi Rainer, Rainer Stengele rainer.steng...@diplan.de writes: Unfortunately I get this no matter on what part of which of the two timestamps I am: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) org-clock-timestamps-change(up) org-clock-timestamps-up() org-shiftcontrolup() call-interactively(org-shiftcontrolup nil nil) Do you need more information which helps to debug? Nope -- just a stupid leftover. Should work now, thanks! Hi Bastien! excellent, works and is most useful - at least for me!!! Thanks a lot! -- Mit freundlichen Grüßen / Best Regards Rainer Stengele __|___ | Dipl. Inf. (Univ.) Rainer Stengele | Technical Control - System Administration | | email: rainer.steng...@diplan.de | voice/fax: ++49-9131-7778-85/88 | WWW : http://www.diplan.de | | diplan GmbH | Wetterkreuz 27 | 91058 Erlangen, Germany Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
