Re: [O] Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
On Wed, Aug 24 2011, Samuel Wales wrote: > Here is a different solution. It is from my notes from long ago. > > To me, one issue with indenting is that you expect the previous line > to be a direct parent, analogously with the outline. This conflicts > with sorting and non-child descendents. > > If you sort, you can't take advantage of the feature and have it look > right. If it's not a direct child, you can't take advantage of it > either because you either confusingly indent too much or modify the > semantics. Also, indenting interferes with putting as much > information on the line as possible. Those with large fonts or small > (e.g. mobile) displays value the real estate. > > === > > Here is an alternate, which might or might not satisfy the OP's needs > tangentially, but might spark discussion in either case. > > One feature I have long wanted, but have not been able to implement, > is to dim (or color) any agenda entry that has a descendant in the > same agenda view. > > === > > This is a completely different thing from dimming blocked > tasks, because it only looks at other tasks in the same > view, and doesn't care about todo keywords. > > The pseudocode is this: > > loop for i in all headlines in agenda (even a combined agenda) > if i has an ancestor in agenda, dim that ancestor > This is interesting, and certainly could be a potential display option. It still sort of begs the question of how to get level and/or child/ancestor information attached to the collected TODOs as they're being produced for the agenda views. I'm starting with the easiest use-case: attaching a "level" text property to each TODO. I'm trying to do this for TODOs produced by `org-todo-list' (used by the ?t and ?T dispatch commands) and `org-tags-view' (used by the ?m and ?M dispatchers). The former employs `org-agenda-get-day-entries' and then `org-agenda-get-todos' to find its TODOs, the latter uses `org-scan-tags'. I've put code into both `org-agenda-get-todos' and `org-scan-tags' that attaches a "level" property to outgoing TODOs, and so far that's working okay. A smarter thing to do would probably be attaching a "parent" property that points to the parent headline. Different display options could then use that information to munge the agenda display in different ways: dimming, indenting, prefixing a path, etc. Anyway, I'm just thinking out loud here! If the org gurus have any pointers or warnings, that would be appreciated… Eric
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major writes: > Hi Tom, > >> > To me, the documentation is the leading specification of a piece of >> > software. Anything the software doesn't do that is in the docs is a >> > bug, but likewise anything it does do which the docs don't cover is >> > also a bug. >> >> Aloha Andras, >> >> As an avocational programmer who has had the pleasure of making small >> changes to the Org-mode manual and on-line documentation, this last bit >> seems to raise the bar impractically high. Part of Org-mode's appeal to >> me is that people frequently find new, and at least to me unexpected, >> ways to use it productively. I find it interesting to see how best to >> change the documentation to incorporate the new "discovery." That said, >> the idea that the docs cover *everything* that Org-mode is capable of >> doing is wonderful and I'll be happy to chip in when I can to help you >> achieve that goal. > > I fully agree with you, but it looks like I didn't express my point > clearly enough. I'm talking about very particular behaviour when, for > instance, a certain keyword is encountered. The example in this bug > report is a good illustration: if the tag :noexport: is only supposed > to work in headlines, then I consider it a bug if it works elsewhere, > so the developers must actually make sure that this never happens. > > Otherwise, an unsuspecting new user (like myself) reads the > documentation, and accidentally tries the tag on something other than > what's in the documentation. "Hooray, it works, and what a great > piece of software this is" -- but that doesn't last long since a newer > version of org-mode behaves differently and his undocumented and > unintended "feature" no longer works. As a software user (in this > case), I want to have a clear idea of what works and what doesn't, and > if I try something and it works, I suppose it to be an official way of > doing it. Had I not filed this bug report, I might have carried on > using :noexport: on tables until, one day, suddenly all my documents > break because this "feature" silently goes away. > > By saying that a "feature" must work if and only if it is so > documented I refer to individual features (such as keywords, tags, > keystrokes, etc.), not use cases. > > András > > > Aloha Andras, I think I understand. Would it suffice to add this disclaimer to the documentation for starters? "Features used in ways not explicitly documented here cannot be guaranteed future support." I agree with you that the documentation can be improved. I think it is good now, but look forward to working with you when I can to make it better. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Jambunathan K writes: >> It does seem that you are, for now, letting them be within org-mode >> (your other mail). But it would still help if you express your >> apprehensions and discuss them openly on this list. 1. I had a test.org file that I had created for testing the exporter. Now this file was simply thrown away because it seemed it was inappropriate to him. Any caring maintainer would not throw away a fruits of labour without a moment's reflection. Even if he felt that the test.org is in the wrong place, he could always SAVE it in whatever suitable place he deems fit. 2. Look at another interaction where is showing his total lack of awareness of how software development happens. He ignores my suggestion and tops it up with a tangential reply. To add more amusement to the whole thing, the changes were non-backward compatible and broke Orgmode Homepage. This particular amuses me because I have taken enormous pains to maintain backward compatibility in org-xhtml.el changes. , See http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01294.html | > ps: I would desire that any changes to org-html.el also need to be | > ported to org-lparse.el and (or) org-xhtml.el. | | (Can you take charge of this?) | | This is the main reason why having duplicate code in this area is a | burden. | | I still think our energy will be better spent by progressively adding | things from org-xhtml.el to org-html.el, feature by feature. This is a | lot of (possibly boring) work, but being lazy now will just make it even | more difficult later. | | In any case, working on porting changes from org-html.el to org-xhtml.el | isn't the right direction. | | Let's keep up the good work! ` 3. I have a body of work queued up for review and he picks up a variable name and comments on it. http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00735.html I am a professional programmer of 10+ years and in my experience only fresh college graduates pick up the way the variables are named and subject it to serious scrutiny. 4. Sometimes I resent when he indulgently comments on Nicolas Goazious commits. 5. Has anyone noticed this: He commiting a fix and reverting it or he immediately re-fixing a just committed stuff. No this doesn't happen once in a blue moon. Nothing I list is a serious error. But put everything together, I get a picture of a person who is holding the maintainership and falling seriously short of the role he is expected to play. There is a limit to person's patience. I am pouring all out because he called me "frustrated". Honesly who in his right mind would dare call a serious and committed contributor as "frustrated". I hope after all these discussions he understands once and for all that Lennart Borgman has ZERO code in all the three files org-xhtml.el, org-lparse.el and org-odt.el. I hope he brings some insight in to review process. Jambunathan K.
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Eric Schulte gmail.com> writes: > Are you /sure/ that this doesn't work for you? On my system C-c C-e A > in the following attached org-mode file (posted earlier in this thread) I've just pulled the code again, now it seems to work. I'm not sure what went wrong last night (release_7.7.174.g63fae), but with the current release_7.7.187.g0019b it appears to work just fine. Thanks a lot! András
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Hi Jambunathan, I'm glad you decided to continue sharing your improvements to the Org=>ODT exporter with the rest of the world. I suggest the merge of this exporter into Org's core goes through these steps: 1. Make sure there is no name clash on 8+3 systems. As per last git version of Org, these two files in contrib/odt/OASIS will clash: OpenDocument-v1.2-cs01-manifest-schema.rng OpenDocument-v1.2-cs01-schema.rng 2. Make sure there is no license problem with the schema files. My model here is emacs/etc/schemas/ where: - the README file clearly says what files have what permissions; - most of the time, when the copyright does not belong to the FSF, permissions are stated directly within the file. See emacs/etc/schema/calstbl.rnc for example. When checking OpenDocument-schema-v1.1.rng from Org's contrib directory (I've only checked this one) I saw a non-FSF copyright with no license mentioned, so I thought this could be a problem. If this is not a problem, I need to understand why -- perhaps this will not be a problem because the license of the file will be mentioned in etc/schema/README. 3. Last but not least, I would like us to work on merging org-html.el and org-xhtml.el. I know this is a daunting task, but there is too much duplicate code in these two files, the more we wait, the heavier the maintainance burden will be. I'm open to any suggestion that would spare us this (boring) work... Let me know what you think about my suggestion above. I am not a professional programmer and I'm always willing to learn, so please bare with me. Best, -- Bastien
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Hi Jambunathan, Jambunathan K writes: > Nothing I list is a serious error. But put everything together, I get a > picture of a person who is holding the maintainership and falling > seriously short of the role he is expected to play. If the overall Org community is sharing your view, and if someone if willing to step up as a maintainer, I am glad to step down as the Org maintainer. > There is a limit to person's patience. I am pouring all out because he > called me "frustrated". Honesly who in his right mind would dare call a > serious and committed contributor as "frustrated". I meant it. The word sounds harsh and I should have taken care of making it clear I'm not _accusing_ you or whatsoever. The fact that my task is so big forces me to rely on people's patience, and I fully recognize this can create frustration of some sort -- small examples: Michael Brand has been mentioning a possible bug with priorities and I have not had the time to look closely into it; I've not yet replied to the thread about the possible APPT/EVENT feature raised by Jason a while ago; etc. I understand people can feel frustrated about things I don't have time to do, and I'm (silently) thankful to them that they don't get more mad at me. > I hope after all these discussions he understands once and for all that > Lennart Borgman has ZERO code in all the three files org-xhtml.el, > org-lparse.el and org-odt.el. Sorry, this was not clear to me, because Lennart was the original author of org-parse.el. But I believe you and I'm glad this is the case! I hope we can move forward to improve Org again together. Best, -- Bastien
Re: [O] [PATCH] Fix regression introduced in 15798836
Hi Noorul, Noorul Islam writes: > [[[ > * lisp/org-agenda.el > (org-agenda-get-todos): Set category-pos before usage. > ]]] Applied, thanks. For the next patch, please provide a ChangeLog: http://orgmode.org/worg/org-contribute.html#sec-5 Best, -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András, András Major writes: > I fully agree with you, but it looks like I didn't express my point > clearly enough. Thanks for taking the time to make this clear. > if the tag :noexport: is only supposed > to work in headlines, then I consider it a bug if it works elsewhere, > so the developers must actually make sure that this never happens. Fully agreed. The right thing to do is to fix it. > By saying that a "feature" must work if and only if it is so > documented I refer to individual features (such as keywords, tags, > keystrokes, etc.), not use cases. Yes, let's try to be consistent about this. Now, taking practically, this is something we can do on a use-case basis: in the issue your raised, we fix the problem then fix the doc if necessary. And we can deal with future similar issues like this. Thanks again, -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András, András Major writes: > To me, the documentation is the leading specification of a piece of > software. Anything the software doesn't do that is in the docs is a > bug, Yes, a *major documentation bug*. > but likewise anything it does do which the docs don't cover is > also a bug. I would call this a *minor documentation bug* (depending on the importance of the side-effects, of course). For example, not all variables get documented in the manual, and each variable plays a role somewhere, as documented in its docstring -- it would not be reasonable to try to document each variable in the manual because it would make it completely unreadable. So I'd rephrase your statement above: "Features that the user needs to know about and is not covered by the documentation is a bug." But again, this is stating the obvious :) Let's not spend too much time discussing theoretically -- patches welcome! :) Best, -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Tom, t...@tsdye.com (Thomas S. Dye) writes: > I think I understand. Would it suffice to add this disclaimer to the > documentation for starters? > > "Features used in ways not explicitly documented here cannot be > guaranteed future support." This is stating the obvious, and this gives a feeling that there might be a lot of unintentional features -- I doubt this is the case. I'd rather concentrate on eliminating those "ghost features" rather than advertising their possible existence. Best, -- Bastien
Re: [O] [PATCH] Add customisable face for inlinetasks
Hi Suvayu, Suvayu Ali writes: > Attached is a small patch that defines a customisable face for > inlinetasks. Thanks for this patch. Can you improve it with two small changes? - use `shadow' as the inherited face for the new defface; - add a ChangeLog message to the patch (see http://orgmode.org/worg/org-contribute.html#sec-5) Thanks again! -- Bastien
[O] Code vanishes on export
I have been having some strange behaviour with my orgmode files containing R code. When I export the file (to html), the code vanishes and is replaced by value that is calculated by the code. I obviously do not want the code to be removed from my org file. I did not have this problem earlier and it seems to have appeared after a recent upgrade. Could someone please help trace the problem. Vikas
Re: [O] Code vanishes on export
Hi Vikas, Vikas Rawal wrote: > I have been having some strange behaviour with my orgmode files > containing R code. When I export the file (to html), the code vanishes > and is replaced by value that is calculated by the code. I obviously > do not want the code to be removed from my org file. > > I did not have this problem earlier and it seems to have appeared > after a recent upgrade. > > Could someone please help trace the problem. Could you demonstrate the problem in an ECM (example, complete... but minimal)? Then, (I hope that) it would not be too difficult for us to help you. Best regards, Seb -- Sebastien Vauban
Re: [O] Schedule event
Hi Jason, Jason Dunsmore writes: > Carsten Dominik writes: > >> Why do you want this special interface for setting an event date. >> How is that better than `C-c .'? Is it that you don't need to >> position the cursor? > > Yes, that was my original reason. But your suggestion of adding a > special keyword for events is another good reason. Also, as recently > discussed, consistent formatting conventions and clarifying the > frequently-misunderstood issue of SCHEDULED vs. no-keyword active > timestamps are good reasons. I agree adding an EVENT: (or "APPT:") would be nice. What I suggest is this: 1. merge org-schedule and org-deadline into a new org-plan function. 2. allow org-plan to set a new org-schedule-special keyword (this keyword would be "EVENT" by default, but customizable.) Now I'm unclear yet whether the set of features that is available for scheduled entries should also return special-keyword entries (e.g. org-agenda-get-scheduled) or if this should be a completely separate set of features -- in which case I have the feeling we are really emulating the use of an :EVENT: property. What is your take on this? Thanks for bringing this up anyway! PS: it took me long to reply because I'm also considering using the property drawer to store timestamps like SCHEDULED, DEADLINE and so on. But it is a big move and we can't delay your request by relying on such a change. -- Bastien
Re: [O] git diff: hunk header config
Hi folks, suvayu ali writes: > This is a very useful config. Thanks for pointing it out. But don't > you think this is a client side setting? As far as I am aware, > settings don't carry over from the remote repository. Its distributed > versioning after all. :) > > To make this a server side setting, you would have to add .git/config > and .gitattributes to the repo. But I think that is not correct as > many users might have their own settings that will have to be remerged > at every update. I let Jason decide upon this. > What do you think? In any case, I think this would be a wonderful > addition to org-faq.org on Worg. Suvayu, please feel free to add it to Worg! Best, -- Bastien
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Bastien writes: > Hi Jambunathan, > > Jambunathan K writes: > >> Nothing I list is a serious error. But put everything together, I get a >> picture of a person who is holding the maintainership and falling >> seriously short of the role he is expected to play. > > If the overall Org community is sharing your view, and if someone if > willing to step up as a maintainer, I am glad to step down as the Org > maintainer. I have a task at hand which I am hoping to bring to fruition and it is immaterial (in neutral sense of the word) who the maintainer is. I was reflecting on what a maintainer's role is and what is expected of him. There is no need for others to pitch in with their one cents and two cents worth here and make sure that the discussions hit a bottomless pit. Heed to your heart and stay away from responding to this. >> I hope after all these discussions he understands once and for all that >> Lennart Borgman has ZERO code in all the three files org-xhtml.el, >> org-lparse.el and org-odt.el. > > Sorry, this was not clear to me, because Lennart was the original author > of org-parse.el. But I believe you and I'm glad this is the case! README.org has this entry. Users can afford to NOT read README or manuals. Maintainers are different beast altogether and they have higher responsibilities. They are supposed to take full cognisance of material presented to them. As a maintainer you cannot afford to MISATTRIBUTE authorship. , | ** Is OpenDocumentExporter part of Orgmode or Emacs? | |Not yet. I have expressed my willingness to merge this package in |to official Orgmode and thus to Emacs. The current maintainer of |Orgmode - =Bastien Guerry bzg at gnu.org= - has agreed to consider |the package for integration. If you are interested in having this |package merged with Orgmode send your requests to the maintainer. | |For the sake of record, I am the sole author of the changes |included in this package and I am consenting to have this work or |derivative works make it's way into Emacs proper. My FSF copyright |assignment number is #618390. `
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
> I understand people can feel frustrated about things I don't have time > to do, and I'm (silently) thankful to them that they don't get more > mad at me. People wouldn't feel frustrated about things you don't have time to do but they will definitely get frustrated with things that you don't do but have implicitly or explicitly committed yourself to do. Re-read the sentence again. The difference is subtle. For example, users will get frustrated with me if I don't fix bugs in the odt exporter or take efforts to answer their questions. Jambunathan K.
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
> Let me know what you think about my suggestion above. I will spawn a separate thread and let's strictly stick to that particular thread for all merge related discussions. > I am not a professional programmer and I'm always willing to learn, > so please bare with me. I would be the last person in the world to thump my chest over the most useless of labels. I used the word only to set some context and bring some gravity to the discussion. Jambunathan K.
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
On Wed, 24 Aug 2011 01:46:35 +0200 Jambunathan K. wrote: >> Hi Jambunathan, >> >>> I have made a decision not to merge org-lparse, org-xhtml & org-odt in >>> to Orgmode core. It is a very difficult decision for me to take >>> considering that I had put all my heart in to it. (Btw, this decision >>> has nothing to with me not having enough time at hand.) >> >> As all, I'm puzzled by this statement, and wonder what went wrong >> somehow. > > Without mincing words, Bastien has to learn how to respect and engage > with serious contributors. He should take time to look at the data > presented to him and put some serious effort before sending out an > email. I am willing to overlook the fact that he seriously pissed me off > with unkind words and committed a greater faux paus by inviting Lennart > Borgman in to merge discussions. I am sorry to say this - Lennart > Borgman did a half-baked work. > > I have been patient and tried my best to be as co-operative as > possible. He just manages to get me on my nerves somehow. He simply > didn't have the courtesy to reply to my mails when he simply disappeared > from the list for 3 months or so. I hate to such callous attitude who > claims to be a maintainer and wants to act like a maintainer. > >> What you did is a really important piece of the puzzle, as it finally >> let us cooperate more easily with people we can't convert as >> Org'ers. At least, they won't bother us to fit their software >> requirement: we can work in Org up till the very end, and then produce >> a final result in the expected (by others) format. >> >>> I leave it up to the community on what would be the best place to "host" >>> this software. >> >> For me, the answer to this was/is clear: Org-mode itself, hence the reason >> why I don't understand the above. > > I have definite ideas on how the merge should proceed. He should be > willing to concede to the fact that I have a far better understanding on > what the most effective method of merge is. > > Bastien has stepped in to big shoes and he has to measure up. So "frustrated" is a dirty word for you? How about "a conceited moron"? Bastien might be an incompetent maintainer or programmer (in any case, you seem to be the first to make such claims), but he's certainly more than willing to deal with it. You've shown more than once here that you're rather incompetent as a contributor and a person[1]. I find it quite surprising that people on this list, including Bastien, are even willing to reply to the dirt you're spitting up. [1] Another example of the Jambunathan style: http://thread.gmane.org/gmane.emacs.orgmode/42544/focus=42563 -- Štěpán
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Please stay away from the discussion. > [1] Another example of the Jambunathan style: > http://thread.gmane.org/gmane.emacs.orgmode/42544/focus=42563 You are mixing stlye with intent. style != intent. Read that again. The intent of hte post is to prod him to post ONLY when he can afford to post. I resent when someone relies on Free Software but suffixes every bug report he files with "No I cannot add more". I can show Samuel's posts which are detailed and which an average poster wouldn't have patience to write. I don't want him to file detailed bug reports. He simply has to remove his signature statement which repeatedly brings focus to what he cannot do and not what he has already brought to the table. When you are on internet you don't have to declare who you are or what you are endowed with. My contributions are non-trivial and useful. Bastien or Thomas or even Carsten (in the post that you point to) are taking a balanced opinion. They are taking a position which would take the discussion forward. You are hell bent on sabotaging the discussion. ps: Please stay away from the discussion. You don't have what it takes to generate a consensus. Jambunathan K.
Re: [O] [PATCH] Add customisable face for inlinetasks
Hi Bastien, On Wed, 24 Aug 2011 10:39:12 +0200 Bastien wrote: > Can you improve it with two small changes? > > - use `shadow' as the inherited face for the new defface; > > - add a ChangeLog message to the patch (see > http://orgmode.org/worg/org-contribute.html#sec-5) I have made the changes. Let me know if they are up to your expectations. -- Suvayu Open source is the future. It sets us free. >From 006046bd20758c387e9cb2340e1d97610365b060 Mon Sep 17 00:00:00 2001 From: Suvayu Ali Date: Tue, 2 Aug 2011 00:24:50 +0200 Subject: [PATCH] Define org-inlinetask face * org-inlinetask.el (org-inlinetask): New customisable face for inlinetasks --- lisp/org-inlinetask.el |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el index c743423..a186517 100644 --- a/lisp/org-inlinetask.el +++ b/lisp/org-inlinetask.el @@ -405,6 +405,12 @@ (defun org-inlinetask-get-current-indentation () (current-column))) (defvar org-indent-indentation-per-level) ; defined in org-indent.el + +(defface org-inlinetask + (org-compatible-face 'shadow '((t (:bold t + "Face for inlinetask headlines." + :group 'org-faces) + (defun org-inlinetask-fontify (limit) "Fontify the inline tasks down to LIMIT." (let* ((nstars (if org-odd-levels-only @@ -425,7 +431,7 @@ (defun org-inlinetask-fontify (limit) (add-text-properties (match-beginning 2) (match-end 2) '(face org-hide font-lock-fontified t)) (add-text-properties (match-beginning 3) (match-end 3) - '(face shadow font-lock-fontified t) + '(face org-inlinetask font-lock-fontified t) (defun org-inlinetask-toggle-visibility () "Toggle visibility of inline task at point." -- 1.7.4.4
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
> So "frustrated" is a dirty word for you? How about "a conceited > moron"? Labels have no meanings. They are merely quick conveniences. (Does this remark make me a MORE CONCEITED MORON) > Bastien might be an incompetent maintainer or programmer (in any case, > you seem to be the first to make such claims) I use words judiciously. I made no mention of incompetence. I was only listing the expectations that I have of him and where I felt he seriously falls short. If I say that I am a professional programmer will that make Bastien a poor programmer. Did you ever have a course in logic? > You've shown more than once here that you're rather incompetent as a > contributor and a person[1]. I am a incompetent contributor to Orgmode if you measure my competence (or incompetence thereof) based on say how many miles I can manage to run in a marathon. You are conveniently ignoring good things that people are saying about org-odt just because you are in ill-mood. Advising a person to refrain from posting after bringing attention to the fact that contrary to his intention he seriously falls short is according to me not unkind. If you force a sick person to sit when it could harm him are you helping him or you harming him. I don't want to confront you with a Zen koan but your reasoning is seriously flawed and your intent is malicious. Btw, if I am dog will org-odt be less useful? > I find it quite surprising that people on this list, including Bastien, > are even willing to reply to the dirt you're spitting up. > > [1] Another example of the Jambunathan style: > http://thread.gmane.org/gmane.emacs.orgmode/42544/focus=42563 --
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
We all need Zen slaps at various points in time. http://c2.com/cgi/wiki?ZenSlap Hope it will soften your mood. Jambunathan K.
[O] two tools may be useful for org-export
Those days I came across two tools which I thought interesting and helpful if could be combined with org-export in some way. 1. Deck.js: a js lib for making modern html presentation. See http://imakewebthings.github.com/deck.js/#intro for more info. 2. Tralics: a LaTeX to XML translator, http://www-sop.inria.fr/apics/tralics/
[O] Todo with checkboxes is grayed out in agenda
I have a todo like this: * todo something - [ ] first - [ ] next In the agenda, the todo something header is displayed grayed out. I see the reason for this -- org-mode considers this to be a parent headline of child TODOs because of the checkboxes. Is there a way to turn this off? I'd like to see TODOs with checkboxes under them as regular TODOs, not as parent TODOs in the agenda. Thanks, --Nate
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Hi all, I probably shouldn't butt into this, and I understand the technical issues too poorly to offer suggestions on merging. But as a grateful user, and and a semi-active participant on this list, I'd like to voice three concerns. 1. Org-mode maintained by someone able and happy to do it. We are fortunate that Bastien stepped up to take over from Carsten as maintainer. Serving the Org-mode community as maintainer on a voluntary basis is a major personal commitment, and requires community support, including emotional backing and /helpful/ feedback. Jambunathan, please keep criticism of how Bastien has handled your work constructive and to the point. 2. Jambunathan's excellent org-odt maintained as an integral part of Org-mode. Org-odt opens up Org-mode as an all-round authoring environment for users like me who are expected to deliver their work in wp formats. Bastien, and other core developers who may be involved, please go an extra mile if necessary to make sure it will end up actively maintained as core Org. 3. The friendly atmosphere of this mailing list preserved. I think Bastien's replies around noon today are exemplary in this regard. Yours, Christian
Re: [O] [PATCH] Add customisable face for inlinetasks
Hi Suvayu, Suvayu Ali writes: > I have made the changes. Applied, thanks a lot! > Let me know if they are up to your expectations. That's perfect. I've just added the "TINYCHANGE" tag at the bottom of the commit message, I forgot to mention this again. Thanks again, -- Bastien
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Dear Christian, many thanks for your contribution - my sentiments exactly! Warm regards, Stefan On 24.08.2011, at 15:00, Christian Moe wrote: > I probably shouldn't butt into this, and I understand the technical issues > too poorly to offer suggestions on merging. But as a grateful user, and and a > semi-active participant on this list, I'd like to voice three concerns. > > 1. Org-mode maintained by someone able and happy to do it. > > We are fortunate that Bastien stepped up to take over from Carsten as > maintainer. Serving the Org-mode community as maintainer on a voluntary basis > is a major personal commitment, and requires community support, including > emotional backing and /helpful/ feedback. Jambunathan, please keep criticism > of how Bastien has handled your work constructive and to the point. > > 2. Jambunathan's excellent org-odt maintained as an integral part of Org-mode. > > Org-odt opens up Org-mode as an all-round authoring environment for users > like me who are expected to deliver their work in wp formats. Bastien, and > other core developers who may be involved, please go an extra mile if > necessary to make sure it will end up actively maintained as core Org. > > 3. The friendly atmosphere of this mailing list preserved. > > I think Bastien's replies around noon today are exemplary in this regard. > > Yours, > Christian > -- Dr. Stefan Vollmar, Dipl.-Phys. Head of IT group Max-Planck-Institut für neurologische Forschung Gleuelerstr. 50, 50931 Köln, Germany Tel.: +49-221-4726-213 FAX +49-221-4726-298 Tel.: +49-221-478-5713 Mobile: 0160-93874279 Email: voll...@nf.mpg.de http://www.nf.mpg.de smime.p7s Description: S/MIME cryptographic signature
Re: [O] Code vanishes on export
Vikas Rawal writes: > I have been having some strange behaviour with my orgmode files > containing R code. When I export the file (to html), the code vanishes > and is replaced by value that is calculated by the code. I obviously > do not want the code to be removed from my org file. > > I did not have this problem earlier and it seems to have appeared > after a recent upgrade. > > Could someone please help trace the problem. > There are ways of controlling whether code or results or both or neither are included in code export. Please see the following sections of the manual. http://orgmode.org/manual/Working-With-Source-Code.html http://orgmode.org/manual/Header-arguments.html http://orgmode.org/manual/exports.html If those don't solve your problem then please (as suggested elsewhere in this thread) do share a complete minimal example. Thanks -- Eric > > Vikas > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
On Wed, Aug 24, 2011 at 9:00 AM, Christian Moe wrote: > Hi all, > > I probably shouldn't butt into this, and I understand the technical issues > too poorly to offer suggestions on merging. But as a grateful user, and and > a semi-active participant on this list, I'd like to voice three concerns. > > 1. Org-mode maintained by someone able and happy to do it. > > We are fortunate that Bastien stepped up to take over from Carsten as > maintainer. Serving the Org-mode community as maintainer on a voluntary > basis is a major personal commitment, and requires community support, > including emotional backing and /helpful/ feedback. Jambunathan, please keep > criticism of how Bastien has handled your work constructive and to the > point. > > 2. Jambunathan's excellent org-odt maintained as an integral part of > Org-mode. > > Org-odt opens up Org-mode as an all-round authoring environment for users > like me who are expected to deliver their work in wp formats. Bastien, and > other core developers who may be involved, please go an extra mile if > necessary to make sure it will end up actively maintained as core Org. > > 3. The friendly atmosphere of this mailing list preserved. > > I think Bastien's replies around noon today are exemplary in this regard. > > Yours, > Christian > > just +1ing this -- I think when people work really hard on these voluntary contributions it's not at all unusual for them to feel frustrated when the process doesn't move as smoothly as it could. But I truly believe both Bastien and Jambunathan are doing the very best they can and making fantastic contributions to the tool we all love. And I am very thankful to people like Christian for making it a priority to keep this list a friendly and enormously helpful resource for developers and users both. Matt
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
>> Nothing I list is a serious error. But put everything together, I get >> a picture of a person who is holding the maintainership and falling >> seriously short of the role he is expected to play. > If the overall Org community is sharing your view, and if someone if > willing to step up as a maintainer, I am glad to step down as the Org > maintainer. I appreciate Bastien's engagement as an Org maintainer. I can appreciate that the learning curve for being (the Org) maintainer is steep. Further, I echo Christian Moe: Org-odt is an important contribution. I cannot judge whether someone has done anythin wrong, but in any case it is `human' to make mistakes. The important thing is to correct ones future behavior IMO (I haven't had any philosophy classes beside `worldly' ones). From my perspective Bastien and the rest of the Org-devs seems to live up to this. I hope this issue can be resolved and that we can enjoy odt export in a not to distant future without having to go through extra hoops such as ELPA. —Rasmus -- Sent from my Emacs
Re: [O] Attachments and refiling
Hi Darlan, Darlan Cavalcante Moreira writes: > At Fri, 19 Aug 2011 10:46:26 +0200, > Bastien wrote: > > What about org-add-link-type? Mmhh.. yes. We should be able to use something like: (org-add-link-type "attach" 'org-attach-open 'org-attach-export) > However, I could not make the the "export" part work because I can't use > org-attach-expand in it. Therefore, I don't know how to get the attach > directory inside a function that I can pass to org-add-link-type as the > export function. That's not possible for now. That's something we can keep in mind while working an a new export engine: exporting part of the content should be done in a context-aware fashion, where it's possible to get the value of org-attach-dir. > Unfortunately, my elisp skills are very limited to go any further for > now. Even with good elisp skills I'm afraid we cannot achieve this for the moment. HTH, -- Bastien
Re: [O] TODO type problem on speedbar and imenu.
Hi Nicolas, Nicolas Goaziou writes: > I don't mind providing a commit for this, but the list wasn't > exhaustive. I'd rather have a set of rules which would be part of the > Org format specification. Agreed. > What about : allow mixing tabs and spaces only when indenting or > filling. One or more spaces everywhere[1] else. If you feel confident this is flexible enough, please go ahead. We only need to make sure that a task like * TODO Task ^^ <= unintentional mixed tabs/spaces is okay. In other words: enforce a set of rules, but in a way that will not surprise users if they accidently hit spaces or tabs in position like the end of a line. > An heading regexp would then be: > > "^\\*\\+\\( +TODO\\)?\\( +\\[#.\\]\\)?\\( +.*?\\)?\\([ > \t]+\\(:[[:alnum:]]_@#%:\\)\\)?[ \t]*$" > > Note the use of [ \t]+ to fill the tags to the right. Also note that > regexp means "^***" is a valid regexp (which isn't the case actually). Yes, I think keeping "^***" as a valid regexp is a good idea. > [1] As for every rule, some exceptions: check-boxes cookies and > counters, which can be sticked to respectively the headline text and the > check-box. Okay. Thanks for looking again into this when you have some time! -- Bastien
Re: [O] TODO type problem on speedbar and imenu.
On Aug 24, 2011, at 4:18 PM, Bastien wrote: > Hi Nicolas, > > Nicolas Goaziou writes: > >> I don't mind providing a commit for this, but the list wasn't >> exhaustive. I'd rather have a set of rules which would be part of the >> Org format specification. > > Agreed. > >> What about : allow mixing tabs and spaces only when indenting or >> filling. One or more spaces everywhere[1] else. Hi Nicolas Org currently also uses \t before the tags, when it aligns them. - Carsten > > If you feel confident this is flexible enough, please go ahead. > We only need to make sure that a task like > > * TODO Task > ^^ <= unintentional mixed tabs/spaces > > is okay. In other words: enforce a set of rules, but in a way > that will not surprise users if they accidently hit spaces or tabs > in position like the end of a line. > >> An heading regexp would then be: >> >> "^\\*\\+\\( +TODO\\)?\\( +\\[#.\\]\\)?\\( +.*?\\)?\\([ >> \t]+\\(:[[:alnum:]]_@#%:\\)\\)?[ \t]*$" >> >> Note the use of [ \t]+ to fill the tags to the right. Also note that >> regexp means "^***" is a valid regexp (which isn't the case actually). > > Yes, I think keeping "^***" as a valid regexp is a good idea. > >> [1] As for every rule, some exceptions: check-boxes cookies and >> counters, which can be sticked to respectively the headline text and the >> check-box. > > Okay. > > Thanks for looking again into this when you have some time! > > -- > Bastien > - Carsten
Re: [O] Code vanishes on export
Hi Eric, On Wed, Aug 24, 2011 at 3:58 PM, Eric Schulte wrote: > Vikas Rawal writes: > >> I obviously do not want the code to be removed from my org file. >> > > There are ways of controlling whether code or results or both or neither > are included in code export. > As far as I understand from Vikas' last remark, his org file is getting changed. -- Suvayu Open source is the future. It sets us free.
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Please, all, take a step back and take a deep breath. There are always frustrations and there are different ways of dealing with them. But we have to keep the larger goal in mind: whether I like or hate Bastien's maintainership or Jambunathan K.s code or email style is *completely irrelevant*. Things are what they are: what we have to think about is how to improve org. In this connection, the best advice that I can offer is what your mother told you: "if you can't say anything nice, then don't say anything at all." This list has always been an island of civility and calmness in an otherwise crazy ocean. Let us keep it that way. Thanks, Nick
Re: [O] Attachments and refiling
At Wed, 24 Aug 2011 16:12:01 +0200, Bastien wrote: > > Hi Darlan, > > Darlan Cavalcante Moreira writes: > > > At Fri, 19 Aug 2011 10:46:26 +0200, > > Bastien wrote: > > > > What about org-add-link-type? > > Mmhh.. yes. We should be able to use something like: > > (org-add-link-type "attach" 'org-attach-open 'org-attach-export) > > > However, I could not make the the "export" part work because I can't use > > org-attach-expand in it. Therefore, I don't know how to get the attach > > directory inside a function that I can pass to org-add-link-type as the > > export function. > > That's not possible for now. That's something we can keep in mind > while working an a new export engine: exporting part of the content > should be done in a context-aware fashion, where it's possible to > get the value of org-attach-dir. Thanks for the confirmation Bastien. At least for me the export part is not very important right now. A context aware export engine would make this easy to achieve with org-add-link-type and probably open up many other possibilities, but I understand it is a lot of work. > > > Unfortunately, my elisp skills are very limited to go any further for > > now. > > Even with good elisp skills I'm afraid we cannot achieve this for > the moment. > > HTH, > > -- > Bastien -- Darlan
Re: [O] include no longer working in (ledger) code blocks
Viktor Rosenfeld writes: > Hi, > > I have the following code block in my org file: > > #+begin_src ledger :results raw :cmdline ... > !include /Users/he-sk/org/files/finanzen/2011.ledger > #+end_src > > If I evaluate this code block I get an error message: Code block > produced no output. This works fine for me with recent git org (with :results value but also with :results raw as you have it). What version are you using? > This used to work as of 6 weeks ago. The specified file exists, I > double-checked with ls. If I paste the contents of the file into the > code block, everything works as expected. What are your command line options? Does the same set of options work from the shell? Have you updated ledger in the meantime possibly? sorry for the delay in responding but I've been swamped with work and then took a much needed holiday! came back to 1000+ org emails... sure glad that I have proper email filtering in place ;-) -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.7 (release_7.7.175.g8478)
Re: [O] LaTeX export of lists
t...@tsdye.com (Thomas S. Dye) writes:
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> t...@tsdye.com (Thomas S. Dye) writes:
>>
>>> Nicolas Goaziou writes:
That raises an interesting question: can a list belong to a paragraph in
Org? According to paragraph-related regexps, it can't, for now. And your
request is more a "LaTeXism" than an "Orgism" (!).
>>
>>> I probably don't understand your question fully, but it seems obvious to
>>> me that a list can either belong to a paragraph or it can be separate.
>>> I'm not certain why Org-mode would want to choose one over the other.
>>
>> It isn't obvious. For example, in HTML, a list within a paragraph
>> doesn't even make sense[1].
>>
>> There's no harm in it, but you're basically faking Org and its LaTeX
>> exporter, as lists and paragraphs are two distinct entities[2].
[...]
>
> Aloha Nicolas,
>
> Interesting observations. Thanks.
>
> The relation seems obvious to me because my model comes from printed
> works, which commonly include enumerated lists typeset within
> paragraphs.
>
> Perhaps given the limitation of the HTML spec and the structure of
> paragraphs in Org-mode it will always be necessary to have the LaTeX
> exporter take care of setting lists inside paragraphs.
>
> Thanks again for your help with this.
>
> All the best,
> Tom
Latex does have the concept of lists within paragraphs in that
paragraph boundaries are defined by blank lines. So, if you have a
begin{itemize}...end{itemize} with no blank lines before and after, the
list implicitly is part of the enclosing paragraph.
whether lists exported from org should automatically be within
paragraphs or not is unclear. I personally prefer having them outside
but that's because, in latex, I tend to have 0 paragraph separation with
indented first lines. If I want a list to look like it's embedded
within a paragraph, I put a \nonindent on the "paragraph" following the
list.
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.7 (release_7.7.175.g8478)
[O] HTML5 presentations
On Wed, Aug 24, 2011 at 8:14 AM, zwz wrote: > Those days I came across two tools which I thought interesting and > helpful if could be combined with org-export in some way. > > 1. Deck.js: a js lib for making modern html presentation. See > http://imakewebthings.github.com/deck.js/#intro for more info. > I would really like to see an exporter for this, in part because Drupal integration for deck.js is underway. We already have several html5 presentation modes described on worg: http://orgmode.org/worg/org-tutorials/non-beamer-presentations.html but there are lots of html5 methods out there; here are some resources: http://slides.html5rocks.com/#landing-slide http://usepow.com/about/# http://code.google.com/p/html5slides/ http://code.google.com/p/sfeir/source/browse/trunk/html5-slides/ so here are a couple of questions: - is one of these frameworks better than/easier to work with than the others? Can any of them be shared on slideshare or another archiving service? - can we standardize on a feature-rich exporter and start building a useful interface to it (e.g., on e that allows users to specify transitions & so forth in a property)? - what would be the best starting point for a new exporter? Jambunathan has the generic html exporter, surely that could be a starting point? But the simple html5presentation exporter (see link above) produces pretty good presentations already. Anyway, I'm very glad to see these possibilities emerging in recent months. I'm looking forward to the end of powerpoint! If I never have to use OOo Present again it'll be too soon... Matt
Re: [O] LaTeX export of lists
Hello,
Eric S Fraga writes:
> Latex does have the concept of lists within paragraphs in that
> paragraph boundaries are defined by blank lines. So, if you have a
> begin{itemize}...end{itemize} with no blank lines before and after, the
> list implicitly is part of the enclosing paragraph.
That's why I talked about "LaTeXism".
> whether lists exported from org should automatically be within
> paragraphs or not is unclear.
For the record:
>From Org view, lists and paragraphs are distinct elements. More
accurately, lists can hold paragraphs, but not the opposite.
>From LaTeX view, it's true that a list can belong to a paragraph. But,
again, such a thing is impossible in HTML, in OpenDocument, where "the
list is a paragraph-level element"[1], and in DocBook.
So this is consistent with most of the exporters encountered in
Org. Now, to provide compatibility with LaTeX, Org export system has to
respect blank lines (or the absence thereof) in the buffer.
Regards,
[1]
http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html#4.3.Lists|outline
--
Nicolas Goaziou
Re: [O] Todo with checkboxes is grayed out in agenda
Hello, Nathan Neff writes: > I have a todo like this: > > * todo something > - [ ] first > - [ ] next > > In the agenda, the todo something header is displayed grayed out. > > Is there a way to turn this off? I'd like to see TODOs with > checkboxes under them as regular TODOs, not as parent TODOs > in the agenda. What is the value of `org-enforce-todo-checkbox-dependencies'? Regards, -- Nicolas Goaziou
[O] src blocks, listings package and captions
I'm using the listings package and org-version 7.4 to generate latex/pdf
output including source snippets. I'd like to add captions: "Figure 1:
My code" and tried with the following to no avail:
#+caption: My code
#+begin_src clojure
;; stuff
#+end_src
Do I have to wrap this in \begin{figure}\caption{} or is there a simpler
way?
--
Giles Chamberlin
Engineering Director
Cisco Systems Ltd
Re: [O] LaTeX export of lists
Eric S Fraga writes:
> Latex does have the concept of lists within paragraphs in that
> paragraph boundaries are defined by blank lines. So, if you have a
> begin{itemize}...end{itemize} with no blank lines before and after, the
> list implicitly is part of the enclosing paragraph.
It can probably be argued that LaTeX merely agnostic of the issue, but
has a way to infer where \parskip\indent should go. This distinction
may seem to be a too fine one to make, but as far as the formatting
machinery of TeX is concerned, it becomes all vmode and hmode boxes
anyway.
Importantly however, in the HTML4 document model paragraphs cannot
contain any blocklevel elements and that includes lists and paragraphs
themselves. The visual result could be faked much in the same way that
LaTeX does by having two different classes for the element, but this
adds another level of complexity that all export backends need to deal
with when the construct should be portable.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Bastien writes: > Hi Tom, > > t...@tsdye.com (Thomas S. Dye) writes: > >> I think I understand. Would it suffice to add this disclaimer to the >> documentation for starters? >> >> "Features used in ways not explicitly documented here cannot be >> guaranteed future support." > > This is stating the obvious, and this gives a feeling that there might > be a lot of unintentional features -- I doubt this is the case. I'd > rather concentrate on eliminating those "ghost features" rather than > advertising their possible existence. > > Best, Sounds good to me. Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] LaTeX export of lists
Eric S Fraga writes:
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>> t...@tsdye.com (Thomas S. Dye) writes:
>>>
Nicolas Goaziou writes:
> That raises an interesting question: can a list belong to a paragraph in
> Org? According to paragraph-related regexps, it can't, for now. And your
> request is more a "LaTeXism" than an "Orgism" (!).
>>>
I probably don't understand your question fully, but it seems obvious to
me that a list can either belong to a paragraph or it can be separate.
I'm not certain why Org-mode would want to choose one over the other.
>>>
>>> It isn't obvious. For example, in HTML, a list within a paragraph
>>> doesn't even make sense[1].
>>>
>>> There's no harm in it, but you're basically faking Org and its LaTeX
>>> exporter, as lists and paragraphs are two distinct entities[2].
>
> [...]
>
>>
>> Aloha Nicolas,
>>
>> Interesting observations. Thanks.
>>
>> The relation seems obvious to me because my model comes from printed
>> works, which commonly include enumerated lists typeset within
>> paragraphs.
>>
>> Perhaps given the limitation of the HTML spec and the structure of
>> paragraphs in Org-mode it will always be necessary to have the LaTeX
>> exporter take care of setting lists inside paragraphs.
>>
>> Thanks again for your help with this.
>>
>> All the best,
>> Tom
>
> Latex does have the concept of lists within paragraphs in that
> paragraph boundaries are defined by blank lines. So, if you have a
> begin{itemize}...end{itemize} with no blank lines before and after, the
> list implicitly is part of the enclosing paragraph.
>
> whether lists exported from org should automatically be within
> paragraphs or not is unclear. I personally prefer having them outside
> but that's because, in latex, I tend to have 0 paragraph separation with
> indented first lines. If I want a list to look like it's embedded
> within a paragraph, I put a \nonindent on the "paragraph" following the
> list.
Hi Eric,
I'm thinking of enumerated lists inside paragraphs, of the kind (i)
found frequently in print, and (ii) made possible in LaTeX with the
paralist package's =inpara= commands. Here the list can either end
the paragraph, or not. If Org-mode's lists are going to serve this
purpose, then there will need to be some way to indicate that the list
is to be part of the paragraph.
LaTeX uses blank lines (which is how I typically get paragraph breaks in
Org-mode, though perhaps this isn't the only way to do so?) and a year
or so ago the presence/absence of a blank line following an Org-mode
list was used to trigger whether or not the following text would be set
as a continuation of the paragraph or set as a new paragraph. A blank
line feels natural to me because I've written in LaTeX for a long time,
but I'd be happy with some other solution if the blank line turns out to
be too difficult to maintain in the Org-mode code.
IIUC, you are describing the case where a displayed (not set within a
paragraph) list is followed immediately by flush left text. I agree
that it is useful to be able to do this, but it wasn't what I had in
mind.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
On 08/24/2011 06:55 AM, Štěpán Němec wrote: I find it quite surprising that people on this list, including Bastien, are even willing to reply to the dirt you're spitting up. Jambunathan is abrupt and speaks without much concern for the feelings of the recipients of his messages. He has great concern for the exact meaning of his words, and for being technically correct. This makes him an extremely uncomfortable conversational partner, and an extremely rewarding collaborator. I'd suggest trying to avoid emotional involvement with things that he says. He's not even a patch on Xah Lee. :) - Allen S. Rout
[O] problem with find-file in --eval from command line
I'm trying to start emacs from the command line and using an --eval section to open a file and do some operations. I'm having a problem with the Linux version. Here's how I do it without error using the strange quoting in Windows: ---> emacs --eval ^"( find-file c:/users/myname/somefile.org\^" )^" In Linux I'm not sure how to do the quoting. I tried this: ---> emacs --eval "( find-file "/home/somefile.org" )" And I get the error: Symbols' value as variable is void: /home/somefile\.org It seems there's some problem with the period in the filename, but maybe it's more than that. Can anyone explain how to properly quote the Linux commandline version? (File comes up fine if I just do find-file in a running emacs.) Thanks, Herb
Re: [O] LaTeX export of lists
Nicolas Goaziou writes:
> Hello,
>
> Eric S Fraga writes:
>
>> Latex does have the concept of lists within paragraphs in that
>> paragraph boundaries are defined by blank lines. So, if you have a
>> begin{itemize}...end{itemize} with no blank lines before and after, the
>> list implicitly is part of the enclosing paragraph.
>
> That's why I talked about "LaTeXism".
>
>> whether lists exported from org should automatically be within
>> paragraphs or not is unclear.
>
> For the record:
>
> From Org view, lists and paragraphs are distinct elements. More
> accurately, lists can hold paragraphs, but not the opposite.
>
> From LaTeX view, it's true that a list can belong to a paragraph. But,
> again, such a thing is impossible in HTML, in OpenDocument, where "the
> list is a paragraph-level element"[1], and in DocBook.
>
> So this is consistent with most of the exporters encountered in
> Org. Now, to provide compatibility with LaTeX, Org export system has to
> respect blank lines (or the absence thereof) in the buffer.
>
Aloha Nicolas,
I've just browsed the Document Structure chapter of the Org-mode manual:
paragraphs aren't mentioned!
I've always indicated paragraph breaks in Org-mode with a blank line,
but I realize that this might just be a holdover from my long use of
LaTeX. Are there other ways to indicate a paragraph break in Org-mode?
As for lists within paragraphs being a Latexism, I would say that the
other specs you cite appear to lack a structured way to accomplish
something that is, in fact, quite common in printed text. There is
nothing wrong with leaving a common print structure like this
unstructured, but I find it very convenient to use a structured
approach, as provided by the paralist package in LaTeX.
I'm not trying to be pedantic here and hold out for the presence or
absence of blank lines to indicate a paragraph break in Org-mode. For
the use case of lists set within a paragraph some other mechanism might
be more appropriate.
But this circles back to the more general question of how paragraphs are
indicated in Org-mode. Is it the blank line alone, or the blank line and
other mechanisms?
All the best,
Tom
>
> Regards,
>
> [1]
> http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html#4.3.Lists|outline
--
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] problem with find-file in --eval from command line
Herbert Sitz writes: > In Linux I'm not sure how to do the quoting. I tried this: > > ---> emacs --eval "( find-file "/home/somefile.org" )" Provided you don't use any completely exotic shell, that is what Emacs gets to see: ( find-file /home/somefile.org ) > And I get the error: > >Symbols' value as variable is void: /home/somefile\.org > > It seems there's some problem with the period in the filename, but maybe it's > more than that. Can anyone explain how to properly quote the Linux > commandline > version? (File comes up fine if I just do find-file in a running emacs.) A safe way to quote this particular invocation: emacs --eval '( find-file "/home/somefile.org" )' This only works in tcsh emacs --eval "( find-file \\"/home/somefile.org\\" ) " Bash needs this instead emacs --eval "( find-file "'"'"/home/somefile.org"'"'" ) " THere may be other solutions for bash, but I never really got the hang of their quoting rules. Regards, 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] problem with find-file in --eval from command line
Achim Gratz nexgo.de> writes: > > Bash needs this instead > > emacs --eval "( find-file "'"'"/home/somefile.org"'"'" ) " > > THere may be other solutions for bash, but I never really got the hang > of their quoting rules. > > Regards, > Achim. Achim -- Thanks a lot, that Bash version works great. I'll have to check into quoting rules for the Linux shells. Regards, Herb
Re: [O] Code vanishes on export
suvayu ali writes: > Hi Eric, > > On Wed, Aug 24, 2011 at 3:58 PM, Eric Schulte wrote: >> Vikas Rawal writes: >> >>> I obviously do not want the code to be removed from my org file. >>> >> >> There are ways of controlling whether code or results or both or neither >> are included in code export. >> > > As far as I understand from Vikas' last remark, his org file is getting > changed. FWIW, I experienced this myself. "#+begin_src R" blocks vanished from the *.org file during export (but I was saved by version control!). I think this behavior showed up after 7.7, but I cannot reproduce it now (I did a git pull at release_7.7.170.gcaaad.dirty and have since modified the *.org file on which it happened). IIRC, it did not happen for exports when :export never was set for the buffer and not circumvented by '#+begin_src R :eval t'. Maybe this has (coincidentally) been corrected by the recent update of ob-exp.el, ob.el, and org-exp-blocks.el? Chuck -- Charles C. Berry
Re: [O] Odd behavior in custom agenda (was "done" keyword red)
Hi John, John Hendy writes: > It's as if the face changes based both on whether it's scheduled or > deadlined and what day it's showing up on. Any input on this, or is it > normal? I guess I'd expect the todo keyword "done" to be green no > matter what, but perhaps the headline is shown as red because the > deadline is soon/tomorrow? Can you hit `C-u C-x =' on the word displaying the wrong face, report what the buffer says, and tell what face do you expect instead? Also, do you have the same problem when only using uppercase DONE keywords? Thanks for further input! -- Bastien
Re: [O] [bug] removing last column with a column formula
Hi Carsten, Nicolas Goaziou writes: > Let's consider the following table: > > #+begin_src org > | 1 | 2 | 3 | > | 1 | 2 | 3 | > #+TBLFM: @2$1..@2$3=@1 > #+end_src > > If I remove the second column (M-S-Left), the formula is correctly > updated. But when I remove the last column, the formula gets partly > deleted and becomes: > > #+TBLFM: @2$1.. > > Also, if this times, the first column is removed, that line becomes: > > #+TBLFM: @2$INVALID..@2$2=@1 > > This is with latest Org and no user configuration. Is this something that we can (easily) fix? Thanks! -- Bastien
Re: [O] Blog-like sitemap for org-publish
Hi Jon, Jon Anders Skorpen writes: > Yes. Here is a link to a test blog with some test posts, and one real > post in norwegian. > > http://beta.mindmutation.net This looks really great! Maybe the most simple thing to do for now is to submit org-blog.el as a separate file to the mailing list, and add FIXME comments in functions that borrow too much code from org-publish.el -- it will help refactoring. For the license: I would suggest using GPLv3. For the copyright: using your name is okay, as long as org-blog.el lives in contrib/. If we move it to Org's core, you will need to sign the FSF papers. > Since my initial email I have found a couple of things that should be > done a little different, but I haven't had time to fix them. This > includes the way keywords and dates are exported, and a couple of > other things. Great -- let us know! Best, -- Bastien
Re: [O] org-toggle-inline-images bug
Hi William, William Xu writes: > M-x org-toggle-inline-images doesn't work for links like this: > [[./ref/diskStructures.png]] It works well here on Emacs GNU Emacs 24.0.50.1 or 23.3.1 and Org 7.7 (latest git version.) What version of Emacs and Org are you using? Thanks, -- Bastien
Re: [O] Column view arrow keys issue
Hi Noorul, Noorul Islam writes: > In column view mode, my arrow keys are not working properly. For > example consider the following view. > > Task| Effort >| CLOCKSUM | > > Item1 | 8:00 > | 7:00 | > > Now, when I press right arrow key to reach the effort column the > cursor moves to the far end of the row. This is something I've observed from time to time. Such problems are hard to reproduce and to fix... from what I've observed, they occur for headlines that are not folded. Is this something you've seen too? Any further input on how to isolate this problem is welcome! Best, -- Bastien
Re: [O] problem with find-file in --eval from command line
Hi, This works on Bash (tested on 4.2.10) and should be easy to remember: emacs --eval "(find-file \"/home/somefile.org\" )" Cheers, Viktor Achim Gratz wrote: > Bash needs this instead > > emacs --eval "( find-file "'"'"/home/somefile.org"'"'" ) " > > THere may be other solutions for bash, but I never really got the hang > of their quoting rules.
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
[As most people here apparently consider Jambunathan's communication style acceptable, there is little point for me to continue replying in this thread, but I really couldn't resist in this case, sorry.] On Wed, 24 Aug 2011 19:30:54 +0200 Allen S. Rout wrote: > Jambunathan is abrupt and speaks without much concern for the feelings of the > recipients of his messages. He has great concern for the exact meaning of his > words, and for being technically correct. This makes him an extremely > uncomfortable conversational partner, and an extremely rewarding > collaborator. I'm (sincerely) glad you have some positive experience to share, but you're really being much too generous with regard to this thread. Utterances like "I am willing to overlook the fact that he seriously pissed me off with unkind words and committed a greater faux paus by inviting Lennart Borgman in to merge discussions." or "When I criticized him he is labelling me insulting, patronizing and frustrated. Seriously to how low a level this person has to go." (and many others, as well as the general "everybody except me is an idiot" spirit permeating many of Jambunathan's e-mails) have nothing to do with "concern for the exact meaning" of anything. Such words are not even condescending. They're just insane and for me personally disqualify their originator from any possible collaboration until he comes to his senses again _precisely_ because I value not only basic civity, but also rationality and exactness. -- Štěpán
Re: [O] LaTeX export of lists
t...@tsdye.com (Thomas S. Dye) writes: > I've just browsed the Document Structure chapter of the Org-mode manual: > paragraphs aren't mentioned! They are in "11.1 Structural markup elements" > I'm not trying to be pedantic here and hold out for the presence or > absence of blank lines to indicate a paragraph break in Org-mode. For > the use case of lists set within a paragraph some other mechanism might > be more appropriate. I would suggest #+begin_latex #+end_latex for such specific needs (paralist). > But this circles back to the more general question of how paragraphs are > indicated in Org-mode. Is it the blank line alone, or the blank line and > other mechanisms? There is no strict definition of a paragraph in Org core, yet. That's why every exporter comes out with its own. Though, a blank line is definitely seen as a paragraph break, as any paragraph starter. So, what are these paragraph starters? Here are some: - any line starting with #+, maybe indented. That includes keywords, blocks, comments... - fixed-width lines - items - headlines. Now, defining a paragraph in Org wouldn't necessary be a bad thing for exporters. This would just add information they could deliberately throw away. That's why, again, keeping the exact number of blank lines is important (for when they will throw the information away). Regards, -- Nicolas Goaziou
Re: [O] Odd behavior in custom agenda (was "done" keyword red)
On Wed, Aug 24, 2011 at 1:35 PM, Bastien wrote: > Hi John, > > John Hendy writes: > >> It's as if the face changes based both on whether it's scheduled or >> deadlined and what day it's showing up on. Any input on this, or is it >> normal? I guess I'd expect the todo keyword "done" to be green no >> matter what, but perhaps the headline is shown as red because the >> deadline is soon/tomorrow? > > Can you hit `C-u C-x =' on the word displaying the wrong face, > report what the buffer says, and tell what face do you expect > instead? > Here is the output on the "d" in a red "done": -- character: d (100, #o144, #x64) preferred charset: ascii (ASCII (ISO646 IRV)) code point: 0x64 syntax: wwhich means: word category: .:Base, a:ASCII, l:Latin, r:Roman buffer code: #x64 file code: #x64 (encoded by coding system iso-latin-1-dos) display: by this font (glyph code) uniscribe:-outline-Courier New-bold-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x47) Character code properties: customize what to show name: LATIN SMALL LETTER D general-category: Ll (Letter, Lowercase) There are text properties here: date 734372 day 734372 done-faceorg-agenda-done dotime time duration nil effort "" effort-minutes nil extra"Deadline: " face org-todo format [Show] help-echo"mouse-2 or RET jump to org file ~/org/tf.org" mouse-face highlight org-agenda-type agenda org-category "tf" org-complex-heading-regexp [Show] org-day-cnt 2 org-hd-marker# org-heading t org-highest-priority 65 org-lowest-priority 67 org-marker # org-not-done-regexp "\\<\\(todo\\|next\\|proj\\)\\>" org-todo-regexp "\\<\\(todo\\|next\\|proj\\|waiting\\|done\\|cancelled\\)\\>" priority 1000 tags [Show] time "" time-of-day nil todo-state [Show] txt [Show] type "deadline" undone-face org-warning -- I don't know what I expect as I have never played with faces before. I expect the done should be green, even if it's scheduled/deadlined... because it's done and that's how done shows up everywhere else. I'm trying to figure out why it would show up as red even though it's done. The description for "done" shows up in green despite "done" being red. The description of "todo" shows up in red and "todo" is also in red. > Also, do you have the same problem when only using uppercase > DONE keywords? The screenshot in the original post and the example file should reveal everything. Here is a new one from today: http://i.imgur.com/HyjAj.png And here is a commented basic org file that produces that picture for me: #+begin_src org #+todo: todo(t) next(n!) proj(p) | waiting(w@/@) done(d/@) cancelled(c@/@) * done no schedule/no deadline - in org buffer: green "done" - does not show in agenda buffer (as expected) * done scheduled SCHEDULED: <2011-08-24 Wed> - in org buffer: green "done" - agenda buffer 8/24: red "done", lt. green title - agenda buffer 8/25: not shown (as expected) * done deadline DEADLINE: <2011-08-25 Thu> - in org buffer: green "done" - agenda buffer 8/24: red "done", lt. green title - agenda buffer 8/25: red "done", lt. green title * done deadline + scheduled DEADLINE: <2011-08-25 Thu> SCHEDULED: <2011-08-24 Wed> - in org buffer: green "done" - agenda buffer 8/24: not shown (as expected) - agenda buffer 8/25: red "done", lt. green title * DONE no schedule/no deadline - in org buffer: blue "DONE" (not registered as todo keyword) - does not show in agenda buffer (as expected) * DONE scheduled SCHEDULED: <2011-08-24 Wed - in org buffer: blue "DONE" - agenda buffer 8/24: dark green "DONE", dark green title - agenda buffer 8/25: not shown (as expected) * DONE deadline DEADLINE: <2011-08-25 Thu> - in org buffer: blue "DONE" - agenda buffer 8/24: not shown (as expected) - agenda buffer 8/24: shown again with "In 1d." with brown "DONE" and title - agenda buffer 8/25: red "DONE", red title * DONE deadline + scheduled DEADLINE: <2011-08-25 Thu> SCHEDULED: <2011-08-24 Wed> - in org buffer: blue "DONE" - agenda buffer 8/24: dark green "DONE", dark green title - agenda buffer 8/24: shown again with "In 1d." with brown "DONE" and title - agenda buffer 8/25: red "DONE", red title #+end_src My .emacs contains this relevant section: -- (setq org-todo-keywords '((sequence "todo(t)" "next(n)" "proj(p)" "|" "waiting(w@/@)" "done(d)" "cancelled(c@/@)"))) -- So, to sum up... - "done" is recognized by the org buffer, but seems to trigger the "todo" face in agenda. It also isn't seeming to trigger advance warnings for deadlines (In 1d.). - "DONE" is not recognized by the org buffer as a
Re: [O] Blog-like sitemap for org-publish
Jon Anders Skorpen writes: > Yes. Here is a link to a test blog with some test posts, and one real > post in norwegian. > > http://beta.mindmutation.net Looks good, but is not yet "valid XHTML1.0 strict". :-) 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] git diff: hunk header config
On Sat, Aug 20, 2011 at 23:47, suvayu ali wrote: > On Sat, Aug 20, 2011 at 6:12 PM, Michael Brand >> [...] >> "@@ -12991,7 +12991,7 @@ (defun org-align-tags-here (to-col)" >> instead of the current >> "@@ -12991,7 +12991,7 @@ If ONOFF is `on' or `off', don't toggle but set to >> thi" > > [...] > To make this a server side setting, you would have to add .git/config > and .gitattributes to the repo. But I think that is not correct as > many users might have their own settings that will have to be remerged > at every update. According to the git manual there is a cleaner way for local changes: - gitattributes(5) Manual Page: - "Attributes which should be version-controlled and distributed to other repositories (i.e., attributes of interest to all users) should go into .gitattributes files." - "If you wish to affect only a single repository (i.e., to assign attributes to files that are particular to one user’s workflow for that repository), then attributes should be placed in the $GIT_DIR/info/attributes file." - git-config(1) Manual Page: - "$GIT_DIR/config: Repository specific configuration file." and "The .git/config file in each repository is used to store the configuration for that repository" - "~/.gitconfig: User-specific configuration file." and "$HOME/.gitconfig is used to store a per-user configuration as fallback values for the .git/config file." For .gitattributes it seems to be ok to make it a versioned git repo element. Proposal for the content (changed from first post): #+begin_src # This file is intended to be effective for all users of this repository. # Use ".git/info/attributes" for changes specific to the local user(s). *.eldiff=el *.texi diff=texinfo #+end_src For .git/config I am not sure if it can be made a versioned git repo element. If not, I don't know how it can become part of the transfer during git pull which it should be in any case. Proposal for the content (changed from first post): #+begin_src # This file is intended to be effective for all users of this repository. # Use "$HOME/.gitconfig" for changes specific to one user. [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git://orgmode.org/org-mode.git [branch "master"] remote = origin merge = refs/heads/master [diff "el"] xfuncname = "^(\\(def[a-z]+ .+)$" [diff "texinfo"] xfuncname = "^(@(sub)*section.*)$" #+end_src > What do you think? In any case, I think this would be a wonderful > addition to org-faq.org on Worg. What I would like is that the hunk headers of all future patches from all contributers look like proposed. Without requiring them to change their config now and with every new git clone. For me it is not enough if only a few contributers that stumble upon this FAQ entry and then even care about, change their config. Michael
Re: [O] git diff: hunk header config
Michael Brand writes: > For .git/config I am not sure if it can be made a versioned git repo > element. If not, I don't know how it can become part of the transfer > during git pull which it should be in any case. Proposal for the > content (changed from first post): You can't and I don't think that is an oversight. As a general principle such configurations should not be part of the repository at all. Please note that if you do configure it that way locally, all tools in git will show all diffs in the new format, so there is nothing lost if everybody doesn't have the same configuration. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] LaTeX export of lists
Nicolas Goaziou writes: > t...@tsdye.com (Thomas S. Dye) writes: > >> I've just browsed the Document Structure chapter of the Org-mode manual: >> paragraphs aren't mentioned! > > They are in "11.1 Structural markup elements" > Yes, somewhat incongruously. To my mind, the markup elements are blank lines and \\, not paragraphs. >> I'm not trying to be pedantic here and hold out for the presence or >> absence of blank lines to indicate a paragraph break in Org-mode. For >> the use case of lists set within a paragraph some other mechanism might >> be more appropriate. > > I would suggest #+begin_latex #+end_latex for such specific needs > (paralist). > Yes, but this solution misses the great pleasure and convenience of working with Org-mode lists. It is something I can live with if it proves impractical to keep the current configuration, however. >> But this circles back to the more general question of how paragraphs are >> indicated in Org-mode. Is it the blank line alone, or the blank line and >> other mechanisms? > > There is no strict definition of a paragraph in Org core, yet. That's > why every exporter comes out with its own. > > Though, a blank line is definitely seen as a paragraph break, as any > paragraph starter. So, what are these paragraph starters? Here are some: > - any line starting with #+, maybe indented. That includes keywords, > blocks, comments... > - fixed-width lines > - items > - headlines. > > Now, defining a paragraph in Org wouldn't necessary be a bad thing for > exporters. This would just add information they could deliberately throw > away. That's why, again, keeping the exact number of blank lines is > important (for when they will throw the information away). > Thanks very much for this, to me, clear explanation of the issue. I'm convinced that I've been able to make my points understood and will happily use the Org-mode that you and others are so kind to develop, with or without the ability to set Org-mode lists within paragraphs via LaTeX. All the best, Tom > Regards, -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Re: [O] Code vanishes on export
Can you supply a minimal example file with instructions to reproduce this behavior? Thanks -- Eric cbe...@tajo.ucsd.edu writes: > suvayu ali writes: > >> Hi Eric, >> >> On Wed, Aug 24, 2011 at 3:58 PM, Eric Schulte wrote: >>> Vikas Rawal writes: >>> I obviously do not want the code to be removed from my org file. >>> >>> There are ways of controlling whether code or results or both or neither >>> are included in code export. >>> >> >> As far as I understand from Vikas' last remark, his org file is getting >> changed. > > FWIW, I experienced this myself. "#+begin_src R" blocks vanished from > the *.org file during export (but I was saved by version control!). > > I think this behavior showed up after 7.7, but I cannot reproduce it now > (I did a git pull at release_7.7.170.gcaaad.dirty and have since modified > the *.org file on which it happened). > > IIRC, it did not happen for exports when :export never was set for the > buffer and not circumvented by '#+begin_src R :eval t'. > > Maybe this has (coincidentally) been corrected by the recent update of > ob-exp.el, ob.el, and org-exp-blocks.el? > > Chuck -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug: named columns in tables not working if name contains "_"
On Tue, Aug 23, 2011 at 20:29, Carsten Dominik wrote: > I have checked, underscore is aceptable, calc allows it in variables names. > However, I would not recommend adding any more characters to this regexp. Just to mention: Although "_" is the subscript operator that takes the nth vector element in Calc, I don't mind the change since the formula below that uses "$vector_1" did also not work before the change probably because some other regexp to parse the field name already included "_". And the alternative formula with "subscr($vector, 1)" seems to be syntactically more robust/flexible/clear/etc. anyway. | | [x y] | x | x | #ERROR | x | | ^ | vector | | || | #+TBLFM: @<$3 = $2_1 :: @<$4 = subscr($2, 1) :: @<$5 = $vector_1 :: @<$6 = subscr($vector, 1) Michael
[O] Underline ONLY the first character of a word?
Greetings. I've "inherited" an HTML document that uses the construct: event for instance, to underline the initial 'e' in the word. The context is something like: e event to show that the choice of option 'e' corresponds to choosing an "event". In preparation for a revision of the document, I'm trying to create a *.org file that will duplicate as much of the original style of the HTML document as possible (i.e., when exported to HTML). I haven't been able to find a way to underline just the first character of a word. For instance, _e_vent doesn't produce what I want. I tried: _e_ vent and that underlined the 'e' but, of course, left an unwanted space. Is there some way to do this? A better way? Thanks, -- Mike
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
Štěpán Němec wrote: > [As most people here apparently consider Jambunathan's communication > style acceptable, there is little point for me to continue replying in > this thread, but I really couldn't resist in this case, sorry.] > That is what *you* read into it: as long as we understand that this viewpoint is not necessarily shared by others, I don't have much problem with you believing that. But please do not ascribe motives to others: you just don't know what they do or do not consider acceptable. IME, flame wars erupt and eventually die down, but not before they have done some damage. Whatever damage has been done in this case is done and we can't do much about it. But it behooves us (all of us) to limit the spread. I repeat: if you cannot stand Jambunathan K., or if Jambunathan K. cannot stand Samuel Wales or ... cannot stand ... (fill in the blanks), there is an easy solution: do not read the offending messages. But in any case, do not reply in an uncivil manner and if you cannot be civil, do not reply at all. Nick PS. Don't be like this guy: http://xkcd.com/386/
Re: [O] Bug: named columns in tables not working if name contains "_"
On Tue, Aug 23, 2011 at 18:24, Achim Gratz wrote: > Nick Dokos writes: >> The only characters permitted are alphanumerics. That can probably be >> easily relaxed. > > Only if you don't want to have _underlined_ still working [...] I use _underlined_ in tables and I'm glad it still works. Michael
Re: [O] Bug: named columns in tables not working if name contains "_"
Michael Brand wrote: > On Tue, Aug 23, 2011 at 20:29, Carsten Dominik > wrote: > > I have checked, underscore is aceptable, calc allows it in variables names. > > However, I would not recommend adding any more characters to this regexp. > > Just to mention: Although "_" is the subscript operator that takes the > nth vector element in Calc, I don't mind the change since the formula > below that uses "$vector_1" did also not work before the change > probably because some other regexp to parse the field name already > included "_". And the alternative formula with "subscr($vector, 1)" > seems to be syntactically more robust/flexible/clear/etc. anyway. > > | | [x y] | x | x | #ERROR | x | > | ^ | vector | | || | > #+TBLFM: @<$3 = $2_1 :: @<$4 = subscr($2, 1) :: @<$5 = $vector_1 :: > @<$6 = subscr($vector, 1) > That's worth recording somewhere in Worg, methinks. Nick
Re: [O] Bug: named columns in tables not working if name contains "_"
Michael Brand wrote: > On Tue, Aug 23, 2011 at 18:24, Achim Gratz wrote: > > Nick Dokos writes: > >> The only characters permitted are alphanumerics. That can probably be > >> easily relaxed. > > > > Only if you don't want to have _underlined_ still working [...] > > I use _underlined_ in tables and I'm glad it still works. > Yeah, but Achim has a point: do underlined column names work? I'd guess not if the name contains an underscore. Does it matter if they don't? Not to me, but others might disagree. Nick
[O] agenda: "void: category-pos"
Hi all Since http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=15798836e2bb84bebfb005375e08e38830fc90ee from yesterday or with the newest release_7.7-194-gd203b61 when I try to open the agenda with a minimal setup I get "save-excursion: Symbol's value as variable is void: category-pos". Anybody else too? Michael
Re: [O] Underline ONLY the first character of a word?
On Wed, Aug 24, 2011 at 10:16 PM, Michael Hannon wrote: > I haven't been able to find a way to underline just the first character of a > word. For instance, > > _e_vent > > doesn't produce what I want. I tried: > > _e_ vent > > and that underlined the 'e' but, of course, left an unwanted space. > > Is there some way to do this? A better way? > I don't believe you can. -- Suvayu Open source is the future. It sets us free.
Re: [O] agenda: "void: category-pos"
Michael Brand wrote: > Hi all > > Since > http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=15798836e2bb84bebfb005375e08e38830fc90ee > from yesterday or with the newest release_7.7-194-gd203b61 when I try > to open the agenda with a minimal setup I get "save-excursion: > Symbol's value as variable is void: category-pos". Anybody else too? > > Michael > Yup - I patched it with a band-aid for now (I had to to get emacs started), but I haven't really looked deeper: diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index e3236e5..e26d08c 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3793,7 +3793,7 @@ (defun org-search-view (&optional todo-only string edit-at) (full-words org-agenda-search-view-force-full-words) (org-agenda-text-search-extra-files org-agenda-text-search-extra-files) regexp rtn rtnall files file pos -marker category tags c neg re boolean +marker category category-pos tags c neg re boolean ee txt beg end words regexps+ regexps- hdl-only buffer beg1 str) (unless (and (not edit-at) (stringp string) @@ -4730,7 +4730,7 @@ (defun org-agenda-get-timestamps () "\\|\\(<[0-9]+-[0-9]+-[0-9]+[^>\n]+?\\+[0-9]+[dwmy]>\\)" "\\|\\(<%%\\(([^>\n]+)\\)>\\)")) marker hdmarker deadlinep scheduledp clockp closedp inactivep -donep tmp priority category ee txt timestr tags b0 b3 e3 head +donep tmp priority category category-pos ee txt timestr tags b0 b3 e3 head todo-state end-of-match show-all) (goto-char (point-min)) (while (setq end-of-match (re-search-forward regexp nil t)) DEVS: please don't apply this without some investigation - afaik, it's just a workaround for the problem. Thanks, Nick
Re: [O] Correction for org-archive-location documentation?
Hi John, John Hendy writes: > ,- > |"~/org/archive.org::From %s" > | Archive in file ~/org/archive.org (absolute path), under headlines > | "From FILENAME" where file name is the current file name. > `- > > I may just be reading this wrong, but I thought that if I were to set > this option like so in a file: You're right there is a typo here, I just fixed it. It now reads "~/org/archive.org::* From %s" Thanks! -- Bastien
Re: [O] Underline ONLY the first character of a word?
Thanks, Suvayu. I'll bet somebody on this list could knock out 400 lines of elisp code that would do the trick, but I'm happy to punt on it. It isn't that important a feature. -- Mike > >From: suvayu ali >To: Michael Hannon >Cc: Org-Mode List >Sent: Wednesday, August 24, 2011 2:51 PM >Subject: Re: [O] Underline ONLY the first character of a word? > >On Wed, Aug 24, 2011 at 10:16 PM, Michael Hannon wrote: >> I haven't been able to find a way to underline just the first character of a >> word. For instance, >> >> _e_vent >> >> doesn't produce what I want. I tried: >> >> _e_ vent >> >> and that underlined the 'e' but, of course, left an unwanted space. >> >> Is there some way to do this? A better way? >> > >I don't believe you can. > >-- >Suvayu > >Open source is the future. It sets us free. > > > >
Re: [O] Correction for org-archive-location documentation?
On Wed, Aug 24, 2011 at 5:34 PM, Bastien wrote: > Hi John, > > John Hendy writes: > >> ,- >> | "~/org/archive.org::From %s" >> | Archive in file ~/org/archive.org (absolute path), under headlines >> | "From FILENAME" where file name is the current file name. >> `- >> >> I may just be reading this wrong, but I thought that if I were to set >> this option like so in a file: > > You're right there is a typo here, I just fixed it. > > It now reads "~/org/archive.org::* From %s" Yay -- I helped! > > Thanks! > > -- > Bastien >
Re: [O] Underline ONLY the first character of a word?
>
>
> From: suvayu ali
> To: Michael Hannon
> Cc: Org-Mode List
> Sent: Wednesday, August 24, 2011 2:51 PM
> Subject: Re: [O] Underline ONLY the first character of a word?
>
> On Wed, Aug 24, 2011 at 10:16 PM, Michael Hannon
> wrote:
>> I haven't been able to find a way to underline just the first character of
>> a
>> word. For instance,
>>
>> _e_vent
>>
>> doesn't produce what I want. I tried:
>>
>> _e_ vent
>>
>> and that underlined the 'e' but, of course, left an unwanted space.
>>
>> Is there some way to do this? A better way?
>>
What are you exporting to? I almost exclusively use LaTeX, so I will
take to forcing something like this on the rare occasion I need it:
,-
| \underline{T}his is a test.
| Ti\emph{k}Z
`-
John
>
> I don't believe you can.
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
>
>
>
Re: [O] Underline ONLY the first character of a word?
Michael Hannon wrote:
> Greetings. I've "inherited" an HTML document that uses the construct:
>
> event
>
> for instance, to underline the initial 'e' in the word. The context is
> something like:
>
> eevent
>
> to show that the choice of option 'e' corresponds to choosing an "event".
>
> In preparation for a revision of the document, I'm trying to create a *.org
> file that will duplicate as much of the original style of the HTML document as
> possible (i.e., when exported to HTML).
>
> I haven't been able to find a way to underline just the first character of a
> word. For instance,
>
> _e_vent
>
> doesn't produce what I want. I tried:
>
> _e_ vent
>
> and that underlined the 'e' but, of course, left an unwanted space.
>
> Is there some way to do this? A better way?
>
Not without some code I think.
I can *almost* do it with babel, but there is some manual work involved.
For example, in the following file:
--8<---cut here---start->8---
* Table :noexport:
#+TBLNAME: actions
| abbrev | action |
|+-|
| a | actionable |
| b | bibulous|
| c | califragilistic |
#+begin_src python :results output :exports none :var table=actions
print "* Results"
print "#+begin_html"
for row in table:
print "%s %s%s" % (row[0], row[1][0:1], row[1][1:])
print "#+end_html"
#+end_src
--8<---cut here---end--->8---
I can evaluate the source block with C-c C-c and get a results block
like this[fn:1]:
--8<---cut here---start->8---
#+results:
#+begin_example
* Results
#+begin_html
a actionable
b bibulous
c califragilistic
#+end_html
#+end_example
--8<---cut here---end--->8---
then manually delete the #+{begin,end}_example lines and *then* export the
resulting file.
You might also be able to do something with radio tables or dynamic blocks
but I have not gone down that path.
Nick
Footnotes:
[fn:1] You might have to do something like this
(setq org-babel-min-lines-for-block-output 1)
to convince babel to produce an example block rather than colon-preceded
literals.
Re: [O] Underline ONLY the first character of a word?
Nick Dokos wrote: > Not without some code I think. > D'oh - as John Hendy points out, you can do it by hand: --8<---cut here---start->8--- #+begin_html a actionable b bibulous c califragilistic #+end_html --8<---cut here---end--->8--- It always amazes me how fixated I can get on the wrong approach. Nick
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
> Please, all, take a step back and take a deep breath. +1. Now that various people have given vent to their feelings (and I hope others have managed to swallow what they did not like), let us just move on. May I suggest: go watch a film, grab a beer, or simply sit down and code. Do whatever it takes to cool down, and laugh at one more flame war that we will hopefully manage to douse. Vikas
Re: [O] Code vanishes on export
> > As far as I understand from Vikas' last remark, his org file is getting > changed. This is correct. I am glad at least one more person has reported having faced the problem. For the last few days, I have been manually copying my org file before every export to save it. The problem is that the file I am talking about reads a mysql database, and does a lot of processing using R. The file will simply not work for anyone else because you will not have the database that it needs. And even on that file, it is not as if the code vanishes everytime I export. It happens on some occassions, and at the moment, I am unable to say what triggers it. I am aware that I am being ridiculously vague. But please give me a day to experiment and I will hopefully figure out at least what exactly is happenning. In the meanwhile, I am sure it will help if somebody else who may be facing the same problem can report with some details. Vikas
Re: [O] Underline ONLY the first character of a word?
Here is an amusing aside[fn:1]. Take the org file I posted previously:
--8<---cut here---start->8---
* Table :noexport:
#+TBLNAME: actions
| abbrev | action |
|+-|
| a | actionable |
| b | bibulous|
| c | califragilistic |
#+begin_src python :results output :exports none :var table=actions
print "* Results"
print "#+begin_html"
for row in table:
print "%s %s%s" % (row[0], row[1][0:1], row[1][1:])
print "#+end_html"
#+end_src
--8<---cut here---end--->8---
If I export this to html, I get nothing in the body because of the :noexport:
tag.
But if I evaluate the source block:
--8<---cut here---start->8---
* Table
:noexport:
#+TBLNAME: actions
| abbrev | action |
|+-|
| a | actionable |
| b | bibulous|
| c | califragilistic |
#+begin_src python :results output :exports none :var table=actions
print "* Results"
print "#+begin_html"
for row in table:
print "%s %s%s" % (row[0],
row[1][0:1],
row[1][1:])
print "#+end_html"
#+end_src
#+results:
#+begin_example
* Results
#+begin_html
a actionable
b bibulous
c califragilistic
#+end_html
#+end_example
--8<---cut here---end--->8---
and then export (*without* the manual excision of the #+{begin,end}_example),
I get:
--8<---cut here---start->8---
1 Results
a actionable
b bibulous
c califragilistic
--8<---cut here---end--->8---
which surprised me: the "* Results" line is interpreted as a new headline
during export, despite the fact that it appears within an example block
(that's probably a consequence of the ordering of actions
in org-export-preprocess-string [fn:2]): the noexport tag strips everything
to the "* Results" line, which I guess is surprising at first but makes sense,
and the #+end_example line is silently discarded).
Oh, no! Look what I've done: András will now insist that the whole thing has
to be either documented completely or thrown out bodily :-)
With-tongue-firmly-in-cheek-ly yours,
Nick
Footnotes:
[fn:1] For some value of "amusing".
[fn:2] See somewhere in this thread:
http://thread.gmane.org/gmane.emacs.orgmode/46021.
Re: [O] TODO type problem on speedbar and imenu.
Hello,
Bastien writes:
> Yes, I think keeping "^***" as a valid regexp is a good idea.
In fact, it isn't. "^***" shouldn't match an headline. Not yet
actually. If we want such headlines, org-outline-regexp and al. have to
be set to something like "\\*+". That would break many things, and
outline functions would match unexpected things, like *bold* at
column 0.
Anyway, here's another attempt to improve headline regexps consistency.
Regards,
--
Nicolas Goaziou
>From 758f1342b01a0dd2b36873a1fa948c6cbf7b1ab0 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Thu, 25 Aug 2011 01:58:29 +0200
Subject: [PATCH] Provide more consistent regexps for headlines
* lisp/org-agenda.el (org-search-view): simplify regexp.
(org-agenda-get-todos): use new format string.
* lisp/org-archive.el (org-archive-all-done): simplify regexp.
* lisp/org-ascii.el (org-export-as-ascii): more accurate regexp.
* lisp/org-colview-xemacs.el (org-columns-capture-view): use new
format string and new string.
* lisp/org-colview.el (org-columns-capture-view): use new format
string and new string.
* lisp/org-docbook.el (org-export-as-docbook): more accurate
regexp. Also use new regexp to match generic headlines.
* lisp/org-exp.el (org-export-protect-quoted-subtrees): more accurate
regexp. Also use new regexp to match generic headlines.
* lisp/org-html.el (org-export-as-html): more accurate regexp. Also
use new regexp to match generic headlines.
* lisp/org-mouse.el (org-mouse-match-todo-keyword): removed unused
and now erroneous function.
* lisp/org.el (org-heading-regexp, org-heading-keyword-regexp-format):
new variables.
(org-set-regexps-and-options): create regexps according to the
following rule: use spaces only to separate elements from an headline,
while allowing mixed tabs and spaces for any indentation job.
(org-nl-done-regexp, org-looking-at-done-regexp): removed variables.
(org-set-font-lock-defaults): fontify again headlines with a keyword
and no other text. Use new format strings.
(org-get-heading, org-toggle-comment, org-prepare-agenda-buffers,
org-toggle-fixed-width-section): use new format string.
(org-todo): more accurate regexps.
(org-point-at-end-of-empty-headline): simplify regexp.
This patch attempts to reduce the number of hard-coded headlines, by
providing two format strings and one generic string to cover most of
the cases of headline construction.
---
lisp/org-agenda.el | 30 ---
lisp/org-archive.el|2 +-
lisp/org-ascii.el |4 +-
lisp/org-colview-xemacs.el |5 +-
lisp/org-colview.el|5 +-
lisp/org-docbook.el|7 +-
lisp/org-exp.el|6 +-
lisp/org-html.el |7 +-
lisp/org-mouse.el |7 --
lisp/org.el| 179 +---
10 files changed, 139 insertions(+), 113 deletions(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index b157d39..22d3ab7 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3868,7 +3868,7 @@ in `org-agenda-text-search-extra-files'."
(if (not regexps+)
(setq regexp org-outline-regexp-bol)
(setq regexp (pop regexps+))
- (if hdl-only (setq regexp (concat "^" org-outline-regexp ".*?"
+ (if hdl-only (setq regexp (concat org-outline-regexp-bol " .*?"
regexp
(setq files (org-agenda-files nil 'ifmode))
(when (eq (car org-agenda-text-search-extra-files) 'agenda-archives)
@@ -4574,15 +4574,19 @@ the documentation of `org-diary'."
'help-echo
(format "mouse-2 or RET jump to org file %s"
(abbreviate-file-name buffer-file-name
- (regexp (concat "^\\*+[ \t]+\\("
- (if org-select-this-todo-keyword
- (if (equal org-select-this-todo-keyword "*")
- org-todo-regexp
- (concat "\\<\\("
- (mapconcat 'identity (org-split-string org-select-this-todo-keyword "|") "\\|")
- "\\)\\>"))
- org-not-done-regexp)
- "[^\n\r]*\\)"))
+ (regexp (format org-heading-keyword-regexp-format
+ (cond
+ ((and org-select-this-todo-keyword
+(equal org-select-this-todo-keyword "*"))
+ org-todo-regexp)
+ (org-select-this-todo-keyword
+ (concat "\\("
+ (mapconcat 'identity
+ (org-split-string
+ org-select-this-todo-keyword
+ "|")
+ "\\|") "\\)"))
+ (t org-not-done-regexp
marker priority category tags todo-state
ee txt beg end)
(goto-char (point-min))
@@ -4596,11 +4600,11 @@ the documentation of `org-diary'."
(goto-char (1+ beg))
(or org-agenda-todo-list-sublevels (org-end-of-subtree 'invisible))
(throw :skip nil)))
- (goto-char (match-beginning 1))
+ (goto-char (match-beginning 2))
(setq marker (org-agenda-new-marker (match-beginning 0))
category (org-get-category)
category-pos (get-text-property (point) 'org-category-position)
- txt (match-string 1)
+ txt (match-string 2)
tags (org-get-tags-at
[O] Problem with exporting image to PDF
Hello,
I am new to org-mode so really just trying to learn the ropes. If anyone can
help me figure out how to export images to PDF I would appreciate it as I can't
get it to work despite trying various methods in the .org file.
1. [[./images/1.png]]
2. [[./images/1.eps]]
3. #+LaTeX: \includegraphics[width=5em]{./images/1.eps}
The above produce no graphics (or showing the link to the file) in the PDF
which is successfully created with C-c C-e d
I have tried different classes (article and koma-article) such as:
#+LaTeX_CLASS: koma-article
#+LaTeX_CLASS_OPTIONS: [a4paper]
I am using:
Debian Squeeze
GNU Emacs 23.2.1 (powerpc-unknown-linux-gnu, GTK+ Version 2.20.1)
I have installed: texlive and texlive-latex-extra
Thank you in advance for any suggestions on where I should be looking, or
further information I should be providing to help diagnose the problem.
Cheers,
Toby
Re: [O] Problem with exporting image to PDF
Toby writes:
> Hello,
>
> I am new to org-mode so really just trying to learn the ropes. If anyone can
> help me figure out how to export images to PDF I would appreciate it as I
> can't get it to work despite trying various methods in the .org file.
>
> 1. [[./images/1.png]]
> 2. [[./images/1.eps]]
> 3. #+LaTeX: \includegraphics[width=5em]{./images/1.eps}
>
> The above produce no graphics (or showing the link to the file) in the PDF
> which is successfully created with C-c C-e d
>
> I have tried different classes (article and koma-article) such as:
> #+LaTeX_CLASS: koma-article
> #+LaTeX_CLASS_OPTIONS: [a4paper]
>
> I am using:
> Debian Squeeze
> GNU Emacs 23.2.1 (powerpc-unknown-linux-gnu, GTK+ Version 2.20.1)
> I have installed: texlive and texlive-latex-extra
>
> Thank you in advance for any suggestions on where I should be looking, or
> further information I should be providing to help diagnose the problem.
>
> Cheers,
> Toby
>
>
Aloha Toby,
Welcome to Org-mode.
Typically, for questions like yours, you will need to provide something
the Org-mode community calls an ECM, which is an acronym for a minimal
complete example. The example should fail to produce the results you
expect, which you should specify, and it should contain as little other
material as possible. In your case you might want to share the ECM
Org-mode file and the resulting .tex file.
Out of the box, Org-mode uses pdflatex to create pdf from LaTeX source
(although this can be modified). Pdflatex does not accept eps files for
graphic input, so this might have been part of your problem. It does
accept png files, though, so it appears something else might be going
on.
You might also check your Org-mode version. I don't keep up with the
various Linux distributions but I understand that some of them ship old
versions of Org-mode. The current version is 7.7 and you'll want to use
something fairly close to that.
hth,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] problem with find-file in --eval from command line
Viktor Rosenfeld googlemail.com> writes: > > This works on Bash (tested on 4.2.10) and should be easy to remember: > > emacs --eval "(find-file \"/home/somefile.org\" )" > > Cheers, > Viktor I thought I had tried already that but I hadn't. Thanks Viktor. -- Herb
Re: [O] Problem with exporting image to PDF
Thomas S. Dye wrote:
> Toby writes:
>
> > Hello,
> >
> > I am new to org-mode so really just trying to learn the ropes. If anyone
> > can help me figure out how to export images to PDF I would appreciate it as
> > I can't get it to work despite trying various methods in the .org file.
> >
> > 1. [[./images/1.png]]
> > 2. [[./images/1.eps]]
> > 3. #+LaTeX: \includegraphics[width=5em]{./images/1.eps}
> >
> > The above produce no graphics (or showing the link to the file) in the PDF
> > which is successfully created with C-c C-e d
> >
> > I have tried different classes (article and koma-article) such as:
> > #+LaTeX_CLASS: koma-article
> > #+LaTeX_CLASS_OPTIONS: [a4paper]
> >
> > I am using:
> > Debian Squeeze
> > GNU Emacs 23.2.1 (powerpc-unknown-linux-gnu, GTK+ Version 2.20.1)
> > I have installed: texlive and texlive-latex-extra
> >
> > Thank you in advance for any suggestions on where I should be looking, or
> > further information I should be providing to help diagnose the problem.
> >
> > Cheers,
> > Toby
> >
> >
> Aloha Toby,
>
> Welcome to Org-mode.
>
> Typically, for questions like yours, you will need to provide something
> the Org-mode community calls an ECM, which is an acronym for a minimal
> complete example. The example should fail to produce the results you
> expect, which you should specify, and it should contain as little other
> material as possible. In your case you might want to share the ECM
> Org-mode file and the resulting .tex file.
>
> Out of the box, Org-mode uses pdflatex to create pdf from LaTeX source
> (although this can be modified). Pdflatex does not accept eps files for
> graphic input, so this might have been part of your problem. It does
> accept png files, though, so it appears something else might be going
> on.
>
It's probably the case that even though there is a processing error with
.eps files, in some circumstances, a PDF file *is* produced, but it's
just a skeleton and therefore does not properly render even the "good"
image. If the OP deletes the .eps lines, the .png one will probably
work.
I say "probably", because in one of my experiments, I was able to
duplicate the OP's results and get no images rendered - but try as I
might, I cannot do it again :-) The .png image was rendered properly in
all other experiments, and I don't know what I did in the "successful"
(unsuccessful?) one.
In any case, when bafflement strikes, it's probably a good idea to do
the export in two steps: export to LaTeX and then compile the .tex file
on the command line or with AucTeX to PDF. Any errors raised will be
readily apparent - in particular, the .eps error with pdflatex.
Nick
PS. BTW, width=5em makes for a rather small image.
> You might also check your Org-mode version. I don't keep up with the
> various Linux distributions but I understand that some of them ship old
> versions of Org-mode. The current version is 7.7 and you'll want to use
> something fairly close to that.
>
> hth,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>
[O] My apprehensions listed (Re: Not merging org-lparse, org-xhtml & org-odt to the core)
Bastien (Now with courtesy copy to the list) > Really, Jambunathan, let's get over this useless discussion. I don't think that the discussion was intended to be useless. I have raised or recorded numerous issues that I was apprehensive about. > As someone said, we both are doing our best, we should not let > frustration (mine too!) guide our reactions. My only goal is this - I would like to have all three files in the core with minimum of effort expended by all parties (including you and volunteer testers). > My point now is: how can we make it easy for *other people* to help us > in merging org-html.el and org-xhtml.el (assuming that you agree > having org-xhtml.el in core is not a good idea, tell me otherwise)? My point is having org-xhtml.el is a good idea. It takes zero effort to merge it. We only need some serious testers to give an independent assessment that org-xhtml.el is good to go. All checkins to org-html.el should merge back to org-lparse.el and/or org-odt.el and org-html.el. It is the responsibility of the whoever makes the commit to that file. (There has been checkin to org-html.el yesterday) Anyone should think twice before making widestpread changes to org-html.el. It is difficult for me to work when the ground beneath me is shifting. As a maintainer, it is your responsibility to make sure that you don't do it yourself and nobody else does it. I have said it twice already. As I said, I will open a new thread with my merge proposals. > I think I've perhaps put too much pressure on you by implicitly > expecting that *you* would do this merge -- but this can be a > task for several people. Most people who have participated on this thread are onlookers (in a non-derogatory sense) and none of them have committed upfront so much as 10 month of effort into sole purpose improving something while also living with uncertainty of whether their efforts will make it's way back in to the core. My situation is akin to a first-time would-be-mother who has confused sense of high hope and worst fears. It is a daunting feeling. I am sure there are enough fathers (if no mothers) in this list. I will tell Nick Dokos only this. Whether a person is civil or uncivil shouldn't really matter. Etiquette matters but doesn't matter so much as understanding. IMHO, everyone should make sincere effort to cut through and look in to a person's innermost fears, concerns and apprehensions. If this doesn't happen the person has failed in a moral sense. I fear that 1. I will end up doing too much work. 2. Maintainers have not invested or unwilling/unable to expend sufficient time to assess the changes in org-lparse.el and org-xhtml.el. This fuels the fear because it is easy to discard something than to assess something and embrace it. 3. I will end up just walking away being annoyed throwing everything that I have put my heart in to. I have a life-long record of doing this. 4. People will move on to other things and start talking about the next awesone way to improve in Orgmode. I need an assurance on 2. I want a freeze on org-html.el going forward. Whatever happens the last thing that I want is an abandonware. There lies my bottomline. Jambunathan K.
Re: [O] My apprehensions listed (Re: Not merging org-lparse, org-xhtml & org-odt to the core)
Bastien > All checkins to org-html.el should merge back to org-lparse.el and/or > org-odt.el and org-html.el. It is the responsibility of the whoever > makes the commit to that file. (There has been checkin to org-html.el > yesterday) Anyone should think twice before making widestpread changes > to org-html.el. > > It is difficult for me to work when the ground beneath me is > shifting. As a maintainer, it is your responsibility to make sure that > you don't do it yourself and nobody else does it. I have said it twice > already. I am re-sending this for emphasis. I am not convinced that you have paid heed to what I have been trying to say (because there had been a checkin yesterday) This is what I expressed sometime back. , See http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01294.html | > ps: I would desire that any changes to org-html.el also need to be | > ported to org-lparse.el and (or) org-xhtml.el. ` There is also one post roughly (I believe in February or March) Requesting a feature freeze is a common practice. You either accept the freeze or reject the freeze. You don't overlook it. Because the later leaves me confused on where you stand on the matter. Jambunathan K.
Re: [O] agenda: "void: category-pos"
Yes, happened to me today too. On 08/24/2011 04:20 PM, Michael Brand wrote: Hi all Since http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=15798836e2bb84bebfb005375e08e38830fc90ee from yesterday or with the newest release_7.7-194-gd203b61 when I try to open the agenda with a minimal setup I get "save-excursion: Symbol's value as variable is void: category-pos". Anybody else too? Michael
[O] [PATCH 0/5] loop over headlines in active region
Hi Bastien, > Great -- can you submit a patch against current git head? Following 5 patches implement looping over headlines in active region for org-schedule and org-deadline. Invisible headlines are skipped and bulk-agenda commands work by binding the customization variable to nil before executing a command. I've been running with this modification for 2 weeks now, using the feature occassionally without a visibile problem. As for the macro: What stop me to implement a macro for the generic operation is that for now the macro would depend on the global customization variable. That's not a problem per se but according to my readings about macros (mostly in context of Common Lisp, but that shouldn't matter) it should be considered bad style. I did some experiments with defining an `org-map-entries' MATCH of 'current that causes FUNC to be applied to the current heading only, but I'm not sure if this would be a right thing (tm) to do. Best, -- David David Maus (5): Extend scope 'region to include body of last headline in active region Immediately return if scope is region but no region is active New customization variable: Loop over headlines in active region Skip invisible headlines when mapping over headlines in active region Avoid conflict between bulk command and loop-over-headlines
[O] [PATCH 1/5] Extend scope 'region to include body of last headline in active region
* org.el (org-map-entries): Extend scope 'region to include entire body of last headline in active region. --- lisp/org.el |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index de8c72b..b69b77c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13633,8 +13633,12 @@ a *different* entry, you cannot use these techniques." (org-narrow-to-subtree) (setq scope nil)) ((and (eq scope 'region) (org-region-active-p)) - (narrow-to-region (region-beginning) (region-end)) - (setq scope nil))) + (let ((end (save-excursion + (goto-char (region-end)) + (outline-next-heading) + (point +(narrow-to-region (region-beginning) end) +(setq scope nil (if (not scope) (progn -- 1.7.2.5
[O] [PATCH 2/5] Immediately return if scope is region but no region is active
* org.el (org-map-entries): Immediately return if scope is region but no region is active. --- lisp/org.el | 116 ++- 1 files changed, 59 insertions(+), 57 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index b69b77c..27bad52 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13608,65 +13608,67 @@ with `org-get-tags-at'. If your function gets properties with to t around the call to `org-entry-properties' to get the same speedup. Note that if your function moves around to retrieve tags and properties at a *different* entry, you cannot use these techniques." - (let* ((org-agenda-archives-mode nil) ; just to make sure -(org-agenda-skip-archived-trees (memq 'archive skip)) -(org-agenda-skip-comment-trees (memq 'comment skip)) -(org-agenda-skip-function - (car (org-delete-all '(comment archive) skip))) -(org-tags-match-list-sublevels t) -matcher file res -org-todo-keywords-for-agenda -org-done-keywords-for-agenda -org-todo-keyword-alist-for-agenda -org-drawers-for-agenda -org-tag-alist-for-agenda) + (unless (and (eq scope 'region) + (not (org-region-active-p))) +(let* ((org-agenda-archives-mode nil) ; just to make sure + (org-agenda-skip-archived-trees (memq 'archive skip)) + (org-agenda-skip-comment-trees (memq 'comment skip)) + (org-agenda-skip-function + (car (org-delete-all '(comment archive) skip))) + (org-tags-match-list-sublevels t) + matcher file res + org-todo-keywords-for-agenda + org-done-keywords-for-agenda + org-todo-keyword-alist-for-agenda + org-drawers-for-agenda + org-tag-alist-for-agenda) -(cond - ((eq match t) (setq matcher t)) - ((eq match nil) (setq matcher t)) - (t (setq matcher (if match (cdr (org-make-tags-matcher match)) t + (cond + ((eq match t) (setq matcher t)) + ((eq match nil) (setq matcher t)) + (t (setq matcher (if match (cdr (org-make-tags-matcher match)) t -(save-excursion - (save-restriction - (cond ((eq scope 'tree) - (org-back-to-heading t) - (org-narrow-to-subtree) - (setq scope nil)) - ((and (eq scope 'region) (org-region-active-p)) - (let ((end (save-excursion - (goto-char (region-end)) - (outline-next-heading) - (point -(narrow-to-region (region-beginning) end) -(setq scope nil - - (if (not scope) - (progn - (org-prepare-agenda-buffers - (list (buffer-file-name (current-buffer - (setq res (org-scan-tags func matcher))) - ;; Get the right scope - (cond - ((and scope (listp scope) (symbolp (car scope))) - (setq scope (eval scope))) - ((eq scope 'agenda) - (setq scope (org-agenda-files t))) - ((eq scope 'agenda-with-archives) - (setq scope (org-agenda-files t)) - (setq scope (org-add-archive-files scope))) - ((eq scope 'file) - (setq scope (list (buffer-file-name - ((eq scope 'file-with-archives) - (setq scope (org-add-archive-files (list (buffer-file-name)) - (org-prepare-agenda-buffers scope) - (while (setq file (pop scope)) - (with-current-buffer (org-find-base-buffer-visiting file) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (setq res (append res (org-scan-tags func matcher)) -res)) + (save-excursion + (save-restriction + (cond ((eq scope 'tree) +(org-back-to-heading t) +(org-narrow-to-subtree) +(setq scope nil)) + ((eq scope 'region) +(let ((end (save-excursion + (goto-char (region-end)) + (outline-next-heading) + (point + (narrow-to-region (region-beginning) end) + (setq scope nil + + (if (not scope) + (progn + (org-prepare-agenda-buffers +(list (buffer-file-name (current-buffer + (setq res (org-scan-tags func matcher))) + ;; Get the right scope + (cond +((and scope (listp scope) (symbolp (car scope))) + (setq scope (eval scope))) +((eq scope 'agenda) + (setq scope (org-agenda-files t))) +((eq scope 'agenda-with-archives) + (setq scope (org-agenda-files t)) + (setq scope (org-add-archive-files scope))) +((eq scope 'file) +
[O] [PATCH 3/5] New customization variable: Loop over headlines in active region
* org.el (org-loop-over-headlines-in-active-region): New customization variable. Loop over headlines in active region. (org-schedule, org-deadline): Apply to headlines in region depending on new customization variable. --- lisp/org.el | 159 ++ 1 files changed, 93 insertions(+), 66 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 27bad52..d15c946 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -402,6 +402,25 @@ XEmacs user should have this variable set to nil, because (const :tag "When outside special context" t) (const :tag "Everywhere except timestamps" always))) +(defcustom org-loop-over-headlines-in-active-region nil + "Shall some commands act upon headlines in the active region? + +When set to `t', some commands will be performed in all headlines +within the active region. + +When set to a string, those commands will be performed on the +matching headlines within the active region. Such string must be +a tags/property/todo match as it is used in the agenda tags view. + +The list of commands is: +- `org-schedule' +- `org-deadline'" + :type '(choice (const :tag "Don't loop" nil) +(const :tag "All headlines in active region" t) +(string :tag "Tags/Property/Todo matcher")) + :group 'org-todo + :group 'org-archive) + (defgroup org-startup nil "Options concerning startup of Org-mode." :tag "Org Startup" @@ -11807,39 +11826,43 @@ With argument REMOVE, remove any deadline from the item. With argument TIME, set the deadline at the corresponding date. TIME can either be an Org date like \"2011-07-24\" or a delta like \"+2d\"." (interactive "P") - (let* ((old-date (org-entry-get nil "DEADLINE")) -(repeater (and old-date - (string-match -"\\([.+-]+[0-9]+[dwmy]\\(?:[/ ][-+]?[0-9]+[dwmy]\\)?\\) ?" - old-date) - (match-string 1 old-date -(if remove - (progn - (when (and old-date org-log-redeadline) - (org-add-log-setup 'deldeadline nil old-date 'findpos - org-log-redeadline)) - (org-remove-timestamp-with-keyword org-deadline-string) - (message "Item no longer has a deadline.")) - (org-add-planning-info 'deadline time 'closed) - (when (and old-date org-log-redeadline -(not (equal old-date -(substring org-last-inserted-timestamp 1 -1 - (org-add-log-setup 'redeadline nil old-date 'findpos - org-log-redeadline)) - (when repeater - (save-excursion - (org-back-to-heading t) - (when (re-search-forward (concat org-deadline-string " " - org-last-inserted-timestamp) - (save-excursion -(outline-next-heading) (point)) t) - (goto-char (1- (match-end 0))) - (insert " " repeater) - (setq org-last-inserted-timestamp - (concat (substring org-last-inserted-timestamp 0 -1) - " " repeater - (substring org-last-inserted-timestamp -1)) - (message "Deadline on %s" org-last-inserted-timestamp + (if (and (org-region-active-p) org-loop-over-headlines-in-active-region) + (let (org-loop-over-headlines-in-active-region) + (org-map-entries +`(org-deadline ',remove ,time) org-loop-over-headlines-in-active-region 'region)) +(let* ((old-date (org-entry-get nil "DEADLINE")) + (repeater (and old-date + (string-match + "\\([.+-]+[0-9]+[dwmy]\\(?:[/ ][-+]?[0-9]+[dwmy]\\)?\\) ?" + old-date) + (match-string 1 old-date + (if remove + (progn + (when (and old-date org-log-redeadline) + (org-add-log-setup 'deldeadline nil old-date 'findpos +org-log-redeadline)) + (org-remove-timestamp-with-keyword org-deadline-string) + (message "Item no longer has a deadline.")) + (org-add-planning-info 'deadline time 'closed) + (when (and old-date org-log-redeadline + (not (equal old-date + (substring org-last-inserted-timestamp 1 -1 + (org-add-log-setup 'redeadline nil old-date 'findpos +org-log-redeadline)) + (when repeater + (save-excursion + (org-back-to-heading t) + (when (re-search-forward (concat org-deadline-string " " +org-last-inserted-timestamp) +(save-excursion + (outline-next-heading) (point)) t) + (goto-char (1- (match-end 0))) + (in
[O] [PATCH 5/5] Avoid conflict between bulk command and loop-over-headlines
* org-agenda.el (org-agenda-bulk-action): Bind `org-loop-over-headlines-in-active-region' to nil to avoid conflict with bulk command. --- lisp/org-agenda.el |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 07f3c12..bb0062d 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8306,7 +8306,8 @@ The prefix arg is passed through to the command if possible." (progn (message "Skipping removed entry at %s" e) (setq cntskip (1+ cntskip))) (goto-char pos) - (eval cmd) + (let (org-loop-over-headlines-in-active-region) + (eval cmd)) (setq org-agenda-bulk-marked-entries (delete e org-agenda-bulk-marked-entries)) (setq cnt (1+ cnt -- 1.7.2.5
[O] [PATCH 4/5] Skip invisible headlines when mapping over headlines in active region
* org.el (org-deadline, org-schedule): Skip invisible headlines when mapping over headlines in active region. --- lisp/org.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index d15c946..03c4c13 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -11829,7 +11829,7 @@ can either be an Org date like \"2011-07-24\" or a delta like \"+2d\"." (if (and (org-region-active-p) org-loop-over-headlines-in-active-region) (let (org-loop-over-headlines-in-active-region) (org-map-entries -`(org-deadline ',remove ,time) org-loop-over-headlines-in-active-region 'region)) +`(org-deadline ',remove ,time) org-loop-over-headlines-in-active-region 'region (if (outline-invisible-p) (org-end-of-subtree nil t (let* ((old-date (org-entry-get nil "DEADLINE")) (repeater (and old-date (string-match @@ -11873,7 +11873,7 @@ either be an Org date like \"2011-07-24\" or a delta like \"+2d\"." (if (and (org-region-active-p) org-loop-over-headlines-in-active-region) (let (org-loop-over-headlines-in-active-region) (org-map-entries -`(org-schedule ',remove ,time) org-loop-over-headlines-in-active-region 'region)) +`(org-schedule ',remove ,time) org-loop-over-headlines-in-active-region 'region (if (outline-invisible-p) (org-end-of-subtree nil t (let* ((old-date (org-entry-get nil "SCHEDULED")) (repeater (and old-date (string-match -- 1.7.2.5
Re: [O] My apprehensions listed (Re: Not merging org-lparse, org-xhtml & org-odt to the core)
Jambunathan K wrote: > ... > I will tell Nick Dokos only this. Whether a person is civil or uncivil > shouldn't really matter. Etiquette matters but doesn't matter so much as > understanding. IMHO, everyone should make sincere effort to cut through > and look in to a person's innermost fears, concerns and apprehensions. > > I disagree: it most definitely matters and it's not just "etiquette" either that I'm talking about. I'm talking about respect for the other person's point of view; in fact, something very close to what you express in your last sentence above. If I'm ranting and raving against you, how can I possibly look in at your "...fears, concerns and apprehensions"? All I'd be thinking about is how to hurt you. And remember that I only felt compelled to say something when I saw what I considered an ad hominem attack. Before that, even though I most definitely did not like the tone of the discussion, there were reasonable technical points being addressed. The trouble is that when the tone becomes grating (as it did), it gets harder and harder to avoid the ad hominem part and whatever discussion was going on cannot continue being a discussion on the matters of interest. It becomes a "me against you" and "whoever is not for me is against me" kind of thing - there are no shades of gray, only black and white. That's why incivility matters. There are of course cases where no such respect should be given: if someone is consistently making an ass of himself, then shouting him down may be the only alternative. But I hope that we all understand that we are not in this situation here: there has been frustration (on both sides), some of it legitimate, some of it perhaps not. But I think that both Bastien and you know deep down that you both care very much for orgmode (that's why we are *all* here), so it behooves you (both of you) to find a way forward. > If this doesn't happen the person has failed in a moral sense. [I don't understand what you mean here: which person has failed? The same person whose fears, concerns and apprehensions have not been understood? Or the "other"? ] In any case, I have said more than I wanted to say on the matter at hand, so I'll shut up for now and hope that things proceed in a more constructive direction in the future. Nick
Re: [O] [PATCH 1/5] Extend scope 'region to include body of last headline in active region
On 25.8.2011, at 06:25, David Maus wrote: > * org.el (org-map-entries): Extend scope 'region to include entire > body of last headline in active region. > --- > lisp/org.el |8 ++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/lisp/org.el b/lisp/org.el > index de8c72b..b69b77c 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -13633,8 +13633,12 @@ a *different* entry, you cannot use these > techniques." > (org-narrow-to-subtree) > (setq scope nil)) > ((and (eq scope 'region) (org-region-active-p)) > -(narrow-to-region (region-beginning) (region-end)) > -(setq scope nil))) > +(let ((end (save-excursion > + (goto-char (region-end)) > + (outline-next-heading) > + (point > + (narrow-to-region (region-beginning) end) > + (setq scope nil Hi David, I think the better algorithm here would be this: If region-end is at the beginning of a line and that line is a headline, use region-end as it is. If not, jump to the next headline. Cheers - Carsten > > (if (not scope) > (progn > -- > 1.7.2.5 > >
