Re: [O] LaTeX export: Problem with clipped tables
Am 10.07.2011 00:29, schrieb Bastien: > Hi Frederik, > > Frederik writes: > >> I experience some problems when exporting clipped tables to LaTeX: >> The text in the fields doesn't get properly expanded, the `=>' is not >> removed. > > thanks for reporting this -- should be fixed now. > > Best, > Cool -- Thanks! Regards -- Frederik
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
Achim Gratz 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. I went ahead with splitting the Makefile up, it now looks like this: --8<---cut here---start->8--- # # Master Makefile for the org-mode distribution # include default.mk -include local.mk .DEFAULT_GOAL := help # Describe valid make targets for org-mode. targets help: @echo @echo "Check the settings in default.mk first. If you need to adjust them, please" @echo "copy default.mk to local.mk and then make your edits in local.mk." @echo @echo "Usage:" @echo @echo "make # compile Org ELisp files" @echo "make clean# clean Elisp and documentation files" @echo "make all # compile Org ELisp files and documentation" @echo @echo "make doc # make all documentation" @echo "make info # make Info documentation" @echo "make html # make HTML documentation" @echo "make pdf # make pdf documentation" @echo "make card # make refcards documentation" @echo @echo "make install # install Org" @echo "make install-lisp # install Org ELisp files" @echo "make install-info # install Org Info file" @echo include maint.mk include standard.mk include deps.mk -include server.mk --8<---cut here---end--->8--- Calling make without a target or with a target of "help" or "targets" will give a short overview on how to set things up and use it. Customization is done by creating a local.mk file that overrides the settings in default.mk. By doing this in your local branch, you never need to worry that some change in the main repository will overwrite your customizations and developing on a local branch with merging should become easier (that was my main reason to always rebase my local branch). Merging back into the main branch requires some care, so the repository should probably be configured to never allow a push that has local.mk in it. The same thing is done for the orgmode server.mk part so that it is not distributed with the standard orgmode repository anymore. For illustration I've also separated the dependencies into deps.mk so that they may be auto-generated (in which case they'd be removed from the repository and get their own target). I'll probably merge maint.mk and standard.mk again, but for now they're separated. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Feature request or did I overlook ..
Am 09.07.2011 23:55, schrieb Bastien: > Hi Rainer, > > Rainer Stengele 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.
Re: [O] Inline tasks: tiny export problem
Hello, "Sebastien Vauban" 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] Thanks for Lilypond export (and minor comments)
Hi Bastien, On Sat, 09 Jul 2011 10:44:45 +0200 Bastien 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_. 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] [PATCH] Fix html export of footnotes with lists, tables, quotes, etc.
> > On Sun, Mar 27, 2011 at 4:28 PM, Jambunathan K 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] Calendar-like view of the org-agenda
Hello Tassilo, Tassilo Horn 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 | 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] Regression bug in tangle/weave
Neeum Zawan writes: > Eric Schulte 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] [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 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] Don't ask, don't run
Eric S Fraga writes: > 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] 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 writes: > -- Forwarded message -- > From: Robert McIntyre > 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 > > > 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 wrote: > >> Hi Robert, >> >> Robert McIntyre 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/
[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] Calendar-like view of the org-agenda
Marcus Klemm 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 | for another row etc.. You don't want to have to insert unicode characters there. Bye, Tassilo
[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] Release 7.6
Hi Bastien, > Joost Kremers 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
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 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] patch makefile solve a couple debian build problems and a slackware build problem
Achim Gratz 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
Nick Dokos 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
Bastien wrote: > Hi Jude, > > Jude DaShiell 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] RFC: Revisit org-export-content-div (in the context of org-s5)
> #+begin_src emacs-lisp > (defcustom org-export-html-content-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.
[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
[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 is essentially replaced by " with a bunch of leading and trailing stuff. #+begin_src emacs-lisp (lambda () (save-excursion (replace-regexp (regexp-quote "") (let ((info `(("author" . ,author) ("title" . ,title) ("date" . ,(substring date 0 10) (join `("" "" "" "" "" ,(org-fill-template org-s5-title-string-fmt info) "" "" "" "" ,(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 %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. --
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
Bastien 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
Re: [O] patch makefile solve a couple debian build problems and a slackware build problem
Hi Jude, Jude DaShiell 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
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 org-mode Makefile - solve a couple debian build problems and a slackware build problem
Hi Jude, Jude DaShiell 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 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 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
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 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] Calendar-like view of the org-agenda
Hi Masashi, SAKURAI Masashi 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
Hi Jude, Jude DaShiell 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 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 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] Calendar-like view of the org-agenda
Hi Bastien At Thu, 07 Jul 2011 17:32:44 +0200, Bastien wrote: > : > SAKURAI Masashi 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