[O] A JavaScript Org-mode parser I'm experimenting with
Hi, people. Just want to share that, for the last few days, I'm playing with a JavaScript Org-mode parser written by Masafumi Oyamada, found here: https://github.com/mooz/org-js To my eyes at least, it is very speedy, and fairly clean internally (contrasting with other JavaScript Org parsers I've seen). It does a reasonable job for a particular set of practical cases I currently have. I found a few bugs which I reported today, and I hope, should not last for long. We'll see! :-) Might someone, familiar enough with the Org mode Web site, add a pointer for it in the http://orgmode.org/worg/org-tools/index.html page? François
[O] Some links not working anymore for me
Hi, Org people. For a little while, I've not been able to follow links to Org files, when the link contains a search to some header, and the searched header itself contains white space or non-ASCII characters. I just made this patch that apparently helps me out of this new little misery :-). The patch is only indicative: I'm not sure it is the proper way to solve the difficulty, as I do not really understand all the code surrounding it! diff --git a/lisp/org.el b/lisp/org.el index a0ed137..5c41b52 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10555,7 +10555,8 @@ is used internally by `org-open-link-from-string'. (cond ((not option) nil) ((org-string-match-p \\`[0-9]+\\' option) (list (string-to-number option))) - (t (list nil option + (t (list nil + (org-link-unescape option) ((assoc type org-link-protocols) (funcall (nth 1 (assoc type org-link-protocols)) path)) ((equal type help) François
[O] Org Grep news
Hi, gang. :-) I took last two days as holidays, to let the pressure out a bit, and used them to have mere fun with a few things, among which, Org Grep. The tool used to have one main output, with Emacs commands to transform that output one-way into two other formats. I shuffled the code and added more, so it can switch freely between those three formats, now called views. Buttons on the title line ease that switching. 1. The [browse] view is read-only, with a few extra Emacs commands. 2. The [edit] view is full-Org editable, and uses transient checklists. 3. The [tree] view regroups grep hits by directory, hierarchically. Org Grep yields [browse] view initially. When there are many hits, one can switch to the [tree] view and go pruning, using C-x C-c C-w, say, retaining only what is most promising. Then switch back to either [browse] or [edit] on the reduced set of hits. Convenient for me! :-) François P.S. For the curious, it's still https://github.com/pinard/org-grep .
[O] Spurious literal interpretation in :LOGBOOK: sections
Hi, Org fellows. I noticed a few times this little rendering problem in Org, so it might be worth reporting. First note that I set org-hide-emphasis-markers to t, which I find to be an extremely valuable option. :-) In a :LOGBOOK: entry containing many CLOCK: lines, a literal in the description following a CLOCK: may trigger an incorrect display of the CLOCK: line. The problem is that the = in the CLOCK: line spuriously starts the display of a literal, that display ends at the end of the literal in the description. For example, in these lines: CLOCK: [2014-01-27 lun 15:29]--[2014-01-27 lun 17:20] = 1:51 - Check for a =literal string= and be overwhelmingly happy! the display would look as: CLOCK: [2014-01-27 lun 15:29]--[2014-01-27 lun 17:20] 1:51 - Check for a literal string and be overwhelmingly happy! using literal face from the to the string word, included. François
[O] New org-grep
Hi, fellow Org lovers. I babbled a bit, here, about my org-grep[1] project. I just added some machinery to re-organize the hits buffer it produces, in such a way that the Org file uses an hierarchical structure of headers which reflects the directories where the various hits were found. This is triggered by the s (structure) command within an already produced hits buffer. The difficulty for me was to tame some trickery recursion, while still aiming algorithmic speed, but it was fun! Each one his own misery :-). Some slowness remains for the user, which comes from Emacs redisplay. I wrote this because, when there are many hits in a search, it is sometimes difficult to get a kind of project view on all the results. Keep happy, all! François - [1] https://github.com/pinard/org-grep
[O] Slight misbehaviour with `C-x r t' in Org
Hi, Org people. I hope you're all doing fine, and wish you much enjoy this new year! :-) Let me report a little strange behaviour I observed a few times. Here is the textual content of an Org file: --8---cut here---start-8--- * Trying a =b= *c* /d/ --8---cut here---end---8--- It is displayed like this, with org-hide-emphasis-markers to nil: , | * Trying blue | a normal | =b=grey | *c*bold | /d/italics ` But, as I keep org-hide-emphasis-markers to t, what I see is: , | * Trying blue | a normal | b grey | c bold | d italics ` Now, in this mode, if I put the mark on the `a' letter and the point on the `d' letter, and type `C-x r t SPC SPC RET', I then see: , | * Trying blue | anormal | = b= normal | * c*blue | / d/ normal ` So, the spaces are inserted after the opening marker, while I would have expected to see them inserted before it. My actual examples are of course bigger than the toy example above, but even then, this is easily corrected with some light edition. But yet, I find it inconvenient having to always revise text after shifting it (I often use `C-x r t'), in case of inline markup randomly happening at the beginning of a line. François
Re: [O] Long lines prevent Org mode!
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Using `C-c C-v C-d' to demarcate your region as code, and give the language, you'll get a nice highlighting of the code inside Gnus You mean that demarcated code #+BEGIN_SRC elisp ((lambda (x y) (+ x y))(length abc) 2) #+END_SRC will be automatically shown nicely by Gnus? Trying it right in this message! :-) (for the readers): that was on my first real patch for Org (in fact, for Gnus), back in November 2010 or so. A nice one then! Thanks! François
Re: [O] Parsing Org-mode in Python
Brett Viren b...@bnl.gov writes: I'm also (slowly) working toward some Python-based org processing. My strategy is to produce an intermediate file in JSON format which is designed to capture the full org document structure. I am calling this a shunt export as it is meant to do as little interpretation of the document as possible. Might be interesting, indeed! http://permalink.gmane.org/gmane.emacs.orgmode/79838 This yields: , | Not Found | | The requested URL /gmane.emacs.orgmode/79838 was not found on this server. ` At the end of the day one will have a DOM-style data structure representing the initial org document. Keep me (us!) posted! :-) François
Re: [O] Parsing Org-mode in Python
2014/1/8 Brett Viren b...@bnl.gov Huh, maybe a transient failure? It's there for me right now. Here is the same message from GNU's archive: http://lists.gnu.org/archive/html/emacs-orgmode/2013-12/msg00415.html Got it, thanks! :-) -- François Pinard http://pinard.progiciels-bpi.ca
Re: [O] gnus: link annoyance
Bastien b...@gnu.org writes: I attach a patch to see if it does what you want. This is from a quick exploration, and while testing it, somes links to gwene.org blog entries were throwing a 501 error message (but still display the article.) Take it as a basis for clarifying the discussion, not really a solution right now! Hi, Bastien. Thanks. I quickly tried the patch this morning, and it appears to be usable so far. I'll let it cook for a while, and report any misbehaviour I would observe :-). François
Re: [O] gnus: link annoyance
Rasmus ras...@gmx.us writes: Say you have a mail X that's semi-interesting. Do you then, read it, mark it as unread, close the buffer, go back later, read it again and unread it? I once used Gnus as a reader who tremendously helped me at handling the high email volume of email I got when I maintained many GNU packages (the Translation Project and also tar were pretty generative!) and following lots of newsgroups. Now that I got out of maintenance, Gnus as a mail reader is a bit of overkill, but I still use it to peruse archives I collected on many subjects, in about a thousand of nnfolders. Searching them all is often convenient. Normally, I only delete articles from one of these archives when I decide to ponder it whole and clean it up, and then read articles one after another the normal Gnus way. Otherwise, I prefer them untouched even if casually consulted, postponing the cleanup until I get motivation and a good chunk of time. For the detail, when not in clean mode, I often unread an article just after having read it, or when I know I am perusing a lot, just let them read but quit by Q instead of q, which reverts all the marks. From an hits buffer generated by org-grep, I can get many hits of many kinds (Org, non-Org, mailboxes or mailgroups), and while checking many of these links in speedy mode, it slows me down considerably if I have to stay alert and careful at unreading Gnus articles among the rest, and fairly dangerous if I get tired and stop being careful. François
Re: [O] gnus: link annoyance
Joseph Vidal-Rosset joseph.vidal.ros...@gmail.com writes: Org uses Gnus, is it possible of making uses of Org via Gnus? [...] Is it already possible to do that with Org and Gnus, or not? If it is not possible at the moment, would it be possible? Gnus and Org are both open source and very capable systems, both in themselves and when it comes to extensibility. The main problem is acquiring enough familiarity with their internals to find out the correct, short, compact way of doing about anything one wants. :-) I mean that it would be great to write a letter with for example the letter class in a file letter.org . After that you can export your letter.org to a letter.html as well as to letter.pdf via letter.tex, and with Gnus, thanks to the link system, you can send your nice letter.html to your colleague with letter.pdf as attachment. Many years ago, the message composition has been fairly decoupled from Gnus and brought back into Emacs for other mailers to use. So, I guess you are seeking some machinery between Org and Message, more than between Org and Gnus. I'm far from being sure, but if I wanted to use Org as a mean to write HTML or PDF as message attachments, I would think it could be done with a very moderate amount of Emacs Lisp customization. Unless mistaken, the Org editor to HTML might yield its output in a temporary Emacs buffer, (for PDF, maybe not) and I would be fairly surprised if message composition does not have facilities to receive attachments from buffers. And even if one would have to go through an external file, the extra overhead might be negligible in practice. Putting all the pieces together might require some work, but maybe not that much. François
Re: [O] gnus: link annoyance
Nick Dokos ndo...@gmail.com writes: I suspect however that my arguments are going to convince you just as much as your arguments have convinced me :-) Hi, Nick. You know, it always has been a pleasure corresponding with you, and enjoying your respectful attitude. In the case here, I'm not so trying to convince you, than to alleviate a bit of my misery! :-) The question is how one deals with those unusual cases where you do want to revisit an article (or a mail message: to gnus they are the same thing). Well, using Gnus interactively or through Emacs Lisp programming does not have to be the same thing, programs may bend Gnus behaviour. You call it checking but you are really reading them: how exactly is org or gnus to know that even though you are reading the articles, you are not really reading them? Org could tell Gnus that I am not really reading an article as if I was using Gnus interactively. When a user interactively created an Org link to a Gnus article (likely using C-c l), (s)he decided at the time if the article was to be left read, unread, ticked or otherwise. The human decision has been taken at the time the Org link was created. When Org later visits that link and triggers Gnus into displaying the article, it could get Gnus to do nothing else then display it, keeping the prior human decision unaltered, defeating a Gnus automatism that mainly make sense when reading interactively from Gnus (and not from Org), leaving the responsibility to the user to explicitly change the prior human decision if this is then deemed appropriate. the links in the org file [to previously read articles] still work. Which is wonderful, indeed. I can read an article, leave it read, and still save a working Org link on a article who disappeared out of sight. In any case, you must have read the article in order to determine that you want to save a link to it. Then following the link does not change the flags: it was read before, it's still read after. Exactly! :-) Your last sentence summarizes all of my desires! But I would complete it, just to make sure it extremely clear: Then following the link does not change the flags: it was read before, it's still read after; it was unread before, it's still unread after. Hoping that you forgive my friendly tease! Keep happy! François
[O] Long lines prevent Org mode!
Hi, Org maintainers. This morning, while using my little org-grep tool, I got a Stack overflow in regexp matcher diagnostic. I first looked for a bug in my things, but the problem lies in Org mode. It cannot be activated if the Org buffer happens to contain a long line. In the *Scratch* buffer, I wrote this little function: (defun essai (n) (with-temp-buffer (insert (make-string n ?x)) (org-mode))) and called it with various values of N. It works fine for small N, but breaks when (on the machine here) N reaches 3. I wonder if the following article could help: [[https://groups.google.com/forum/#!topic/gnu.emacs.help/pxfMC5f7JHg][Stack overflow in regexp matcher - Google Groupes]] François P.S. Would someone be kind enough to teach me the wisdom about how to insert Org mode fragments in an email so it is received the most legibly possible at the other end? Presumably, there is a Gnus way (which is it?) yet many people do not use it.
Re: [O] gnus: link annoyance
Achim Gratz strom...@nexgo.de writes: François Pinard writes: Org could tell Gnus that I am not really reading an article as if I was using Gnus interactively. You keep saying that; while clearly you could coerce Gnus into doing something like that I'm not sure Gnus would entertain to listen to such a request. This is probably best asked on a Gnus mailing list, but it seems that Gnus wants to present search results in an ephemeral group. If you treat a link as a search that finds one article, then the problem you're trying to solve goes away, I'd think. The whole discussion is about how Org mode should best follow gnus: links. I surely do not mind if Org uses ephemeral groups or any other kind of machinery. My only suggestion is that, whatever the mechanics, Org following a gnus: link should manage so Gnus does not change the article flags. If Org asks Gnus to perform a search to locate a given article, it seems like overkill to me, but I may well be wrong and not see the advantages. François
Re: [O] Long lines prevent Org mode!
Nick Dokos ndo...@gmail.com writes: you can leave org out of the picture altogether: create an empty buffer, insert 3 x's by hand, go to the beginning and evaluate (looking-at .*foo) As Stefan says in the thread you pointed out, it's a limitation of the emacs regexp engine. Yes, I got this from his article. However, it seems that [^\nf]*foo would succeed, avoiding the stack explosion. So, it is possible to rework the regexpes around the limitation. Surely not a fun job to do for Org regexpes, I know. Maybe not worth doing as very long lines are unusual, yet maybe worth doing nevertheless for Org files because long lines are still possible. The fact is that I was hit by this problem in the Org buffers generated by org-grep. However, as I am tempted to think that the problem is unlikely to be solved soon, I tried to alleviate it. org-grep now shortens the lines by removing, within each line, a good part of the context between hits. This does not guarantee that the above problem will never occur, but it considerably decreases the chance that it occurs. I cut and paste and then use either C-c m (bound to message-mark-inserted-region) or C-c q (bound to boxquote-region) Thanks for these hints, which I saved on keys here! :-) Of course, if your problem is that your mailer (or some mailer along the way) mangles the content, then the safest thing to do is to put it in an attachment or post it on some pastebin and send a link. Sure. My little problem was different. If I use Org in-line markup, like bold, italics, or links to Web sites, or even block markup like fragments between #+BEGIN_SRC and #+END_SRC, say, I was wondering how this is best transmitted within a message, in the text, without resorting to an attachment. Gnus as a reader surely has some capability somewhere, as I think I saw messages displaying Org code nicely; I just do not remember how it was done. Outside Gnus, it might be more problematic to find a useful way to have Org included. Sending Org all raw is sometimes a bit noisy, especially for links. Someone recently mentioned org-mime.el, new to me, maybe this is the proper avenue? I should at least play and experiment with it! :-). François
[O] gnus: link annoyance
Hi, Org people. Still playing with one of my little tools (called org-grep), I added the capability of searching Unix mailbox (producing rmail: links) and Gnus mailgroups (producing gnus: links). This resurrected an old gnus: annoyance I once reported on this mailing list, yet without being able to convince anybody there was a problem. I dare trying again! :-) Whenever I visit a gnus: type link from Org, it has the side effect of reading the article in Gnus parlance, forcing me to unread it each time afterwards. If I forget to unread it, which is a likely error, the article will not be shown if I later visit its mailgroup using Gnus in a regular way. So in practice, it is kind of forever lost. This is a sad side-effect of gnus: links. In this area, Org should immediately unread any gnus: link it follows, or else and maybe even better, leave the reached article with the flags it already has. If the user explicitly saved the article in an Org file using org-store-link, (s)he surely though of it as kind of permanent, and Org should then not read it, even the user did not bang it. If the link is dynamically created like with org-grep, and the user happens to follow one of these links among many others, the user should not be punished by loosing the article because (s)he forgot to explicitly unread it :-). François P.S. Who also has a question about rmail: and gnus: links. Is there a way in the link syntax allowing a precise line positioning within the article? It would be wonderful for org-grep, that would then make great use of such a possibility.
[O] org-cycle-hook from org-mode hook
Hi again, Org people. I noticed a recent change in Org mode behaviour, which I guess is related to a git pull of the org-mode project. This is so minor that it is hardly a problem for me, I only report it in case it would hint at some unwanted change that would have more consequences for others. Opening an Org file in Emacs executes the hooks on org-mode-hooks. Previously, it also executed the hooks on org-cycle-hook, while now, I have the impression it does not anymore. The solution is easy for me, I merely run my own Org cycle hook function from my main Org mode hook. François
Re: [O] org-cycle-hook from org-mode hook
Bastien b...@gnu.org writes: Now it uses `org-content` and `org-overview' instead, so that C-u C-u TAB always work. I did not immediately find the documentation about C-u C-u TAB, which is in the node Initial visibility. The node Global and local cycling documents TAB, C-u TAB and C-u C-u C-u TAB, but surprisingly, not C-u C-u TAB. Maybe some linking between those two manual nodes would be useful to other users, when they happen to be as anal as I am? :-) François P.S. anal in the Piagetian meaning of the word, of course! People suffering from anal disorder are either ultra-meticulous, or completely disorganized. Most of the time, I see myself as being from the former species, yet some days, I confess, I feel like I am from the later.
Re: [O] Implementing Org-mode tools in languages other than ELISP
Daniel Clemente n142...@gmail.com writes: I dream of having a general Python parser for Org mode files, knowing every bit about the current syntax for Org files, surrounded by enough Python machinery to make it useful. Try PyOrgMode (https://github.com/bjonnh/PyOrgMode), it works for some files (but still needs corrections: it crashes with date formats, with bold markers, etc.). Hi, Daniel. As Karl points out (in a kind way), PyOrgMode is rather far from knowing every bit about the current syntax for Org files. My feeling is that this effort should be restarted afresh. You don't need a Lisp interpreter written in Python, only Python code that understands org syntax without getting confused. Well, I would prefer a Python-only solution, rather than requiring Emacs and using it under the scene. François
Re: [O] Parsing Org-mode in Python
Karl Voit devn...@karl-voit.at writes: I did not get the impression that [ply] is a parsing engine that is done the Python way. PLY has pros and cons. SPARK[1] always attracted me as being more elegant. While it accepts a wider set of grammars than PLY, SPARK can become quite slow on grammars which are less natural (admittedly a very fuzzy, subjective term). For simpler grammars, recursive descent does the job at good enough speed, and often, grammars can be rearranged a bit so the lexer could cleverly help the parser. Of course, it looks like more work writing a recursive descent parser, yet many times in my experience, the programmer is amply repaid with simplicity and clarity. You don't need a Lisp interpreter written in Python, only Python code that understands org syntax without getting confused. if you are going to use a ELISP interpreter to parse Org-mode syntax for Python, this should completely re-use the original Org-parser and nothing else. I have no idea if this is possible or not. If you have to implement a parser on your own, you probably should stick to Python-only. Hey hey, it's fun! :-) You misunderstood me, but this is constructive actually, as you raise good points. In my dreams, a pure Python parser parses Org mode files. However, here and there in the parsed files, as data, we can see bits of Emacs Lisp code, or even Calc syntax at some places. That Emacs Lisp code could be mere constants or identifiers, but sometimes more complex, evalable S-expressions. A parser is probably of limited use if it does not come with some extra-tools covering most frequent use cases around the syntax, and I guess that pressure will develop to have some kind of Emacs Lisp interpreter, hardly complete, probably only mild or even ridiculous. The interesting idea in your comments is that, *if* we had an Emacs Lisp interpreter of serious quality, that interpreter could use the original Org-parser and nothing else. That would solve maintenance, as the parser would be wholly external, to be found in Org mode distribution, all standard. But this avenue is quite unlikely: it looks like a major undertaking to me, and while such a parser would be useful on small data excerpts within an Org file, it might be inordinately slow if it had to interpret a lot of Lisp code while deciphering big Org files. Worse, keeping a Python parser in sync with the true Emacs Lisp parser would require much energy, maybe only once in a while, but extended over a long period of time. Unless a great enthusiasm exists, distributed on many people, such projects are always doomed to fail. Not many people are ready to commit themselves for life in the required maintenance. François --- [1] http://pages.cpsc.ucalgary.ca/~aycock/spark/
Re: [O] gnus: link annoyance
Nick Dokos ndo...@gmail.com writes: François Pinard pin...@iro.umontreal.ca writes: Whenever I visit a gnus: type link from Org, it has the side effect of reading the article in Gnus parlance, forcing me to unread it each time afterwards. it's certainly not lost: the link continues to work, even if it points to a read article; and visiting the group with C-u SPACE in gnus also allows you to see previously read articles. Hi, Nick. Of course, you are fully right in that the article is still there, and likely unexpired. But in practice, from my viewpoint, it is not there anymore: I do not usually enter groups by C-u SPC. While possible, it is unusual that I want to find and read again an article which I once decided has been read for good. If I search all mailgroups for a certain string, and randomly check hits, I do not want these articles I check to later have disappeared from sight in practice. I was not really in the process of reading articles, but merely checking on them. It would not make sense that Org removes lines that I visit after a grep, and when grepping through many files, would they be Org, non-Org, mailboxes or articles in mailgroups, I am in a mode where I do not expect any kind of altering behaviour. François
Re: [O] gnus: link annoyance
Rasmus ras...@gmx.us writes: Thanks for working on org-grep. It looks interesting. Thanks for thanking! :-) But deep down, I'm really doing this tool for myself, and only then share it with others. Given the amount of notes I handle, such a tool is inescapable, it is a question of survival :-). Whenever I visit a gnus: type link from Org, it has the side effect of reading the article in Gnus parlance, forcing me to unread it each time afterwards. Excuse me if I misunderstood something below. You read it, no? How can it not be marked read when you read it? The list gnus-mark-article-hook, which is there for customization, has the function gnus-summary-mark-read-and-unread-as-read by default. I guess that if the hook list was empty, articles would be displayed and not automatically marked as read. Perhaps you would like to the following on mailgroups you care about (from the *Groups* buffer): G c C-s Display S-TAB RET TAB RET 1 TAB 100 M- TAB TAB RET Also, you can search with nnir using GG or C-u GG (but links probably won't work from a nnir buffer). I would not think one should modify his Gnus habits or methods merely because Org has a tool to search in Gnus. Org uses Gnus, but Gnus should not be disturbed because of that. 1. Mark an article as important with '!', (gnus-summary-tick-article-forward N) But I do not want to tick (or bang) articles because I do Org searches. When really in Gnus, if I want to keep an article, I unread it. But that does not mean I consider this article especially important. If I want to mark an article as important, I bang it, and as a consequence, Gnus unread it. Banging all articles I want to keep unread is not only overkill, but it spoils the bang mark, which I find very useful for other purposes than Org. I can also change the mark to gnus-summary-mark-as-expirable and preserve the link. One possibility (untested, so I'm not sure) is that when following a gnus: link, Org could use something like: (let ((gnus-mark-article-hook nil)) (ACCESS-THE-gnus:-LINK)) François
Re: [O] rmail: difficulty
Bastien b...@gnu.org writes: François Pinard pin...@iro.umontreal.ca writes: - rmail:~/ubity/Mail/admin This is now fixed, thanks for reporting this! Thanks, it now works! :-) François
Re: [O] Implementing Org-mode tools in languages other than ELISP
Bastien b...@gnu.org writes: Karl Voit devn...@karl-voit.at writes: Therefore, I develop all my Org-mode tools with Python which I am comfortably with. I have done various things and put it on http://github.com/novoid FWIW, I think it's good to develop tools for Org not only in Elisp but also in other languages: Org is not just an Emacs module, it's also a format, used outside Emacs. E.g. .org files on github. I dream of having a general Python parser for Org mode files, knowing every bit about the current syntax for Org files, surrounded by enough Python machinery to make it useful. One non-negligible problem is that such a tool, to be very complete, would need an Emacs Lisp interpreter, which is all of an undertaking in itself. Maybe that some half-heated compromise could be developed? A hundredth-hearted compromise is likely the most I could do! :-) François
[O] org-grep news
Hi, Org people. First of all, let me wish a Much Nice Year to everybody here! :-) This is about my little org-grep tool, available at: https://github.com/pinard/org-grep Right out of the README: This tool allows for grepping files in a set of Org directories, formatting the results as a separate Org buffer. This buffer is assorted with a few specific navigation commands so it works a bit like M-x rgrep. When I announced it, a while ago, someone reported to me that it was not finding anything at all for him. As it worked well for me, and the reporter did not pursue the exploration of the problem with me, I almost forgot it. Yesterday, I stumbled on a tiny bug visible to those using org-grep all bare, with no configuration. This is now corrected. People hit by this problem could happily retry the latest version. Yesterday, to cover one of my own needs, I added the capability to simultaneously search for other files, would they be Org or not. This is implemented by offering hooks able to receive user-defined Emacs Lisp functions. These functions return shell code. So, this capability requires some Emacs Lisp fluency to be activated, yet maybe not that much. The README file contains a small and simple example. While a few problems remain in the tool, it is already very usable in my opinion, and surely useful to me daily. By mere friendship, I feel like recommending it a bit to my Org fellow friends! François P.S. Who is not as pushy as he appears to be. Forgive him! :-)
Re: [O] Force blank line above level 1 heading
Bastien b...@altern.org writes: Sebastian Fischmeister sfisc...@uwaterloo.ca writes: Yes, but this inserts a blank line before every entry. I would like to have a blank line only before level 1 headings. Ah, then clearly this option is not enough. Sorry, I'm short of ideas here. Just for the record, I have the same need for some of my Org files. However, I find it easy enough to add the blank line myself. François
[O] Problem with #+BEGIN_SRC shell, and export
Hi, Org people. Let me make this report from memory, now that I'm back home! :-) In an Org file, a coworker used #+BEGIN_SRC shell where he should have written #+BEGIN_SRC sh. While this looks like a benign error to me, it broke my publishing script, and I did not figure at once what was happening. At export time, when Emacs is called in batch, the export procedure dies. Emacs says that some process disappeared, and I think I got that the batch Emacs tries to start M-x shell under the scene. Could the HTML exporter (or all of them) protect itself (themselves) better? Or else, maybe, if this is a reasonable to do, could Org tell us, somehow, whenever a source mode (like shell, here) is wrong? François
[O] rmail: difficulty
Hi, Org people. In one of my Org files, I have: - rmail:~/ubity/Mail/admin Of course, ~/ubity/Mail/admin is an mbox format email folder. Whenever I mouse-click on it (or use C-c C-o), I get this error: Debugger entered--Lisp error: (wrong-type-argument arrayp nil) org-add-angle-brackets(nil) org-rmail-follow-link(#(~/ubity/Mail/admin 0 17 (wrap-prefix #( 0 4 (face org-indent)) line-prefix #( 0 2 (face org-indent)) keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) (C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . org-open-at-mouse)) htmlize-link (:uri rmail:~/ubity/Mail/admin) face org-link mouse-face highlight org-category Ubity fontified t) 17 18 (wrap-prefix #( 0 4 (face org-indent)) line-prefix #( 0 2 (face org-indent)) rear-nonsticky (mouse-face highlight keymap invisible intangible help-echo org-linked-text htmlize-link) keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) (C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . org-open-at-mouse)) htmlize-link (:uri rmail:~/ubity/Mail/admin) face org-link mouse-face highlight org-category Ubity fontified t)) nil) org-rmail-open(#(~/ubity/Mail/admin 0 17 (fontified t org-category Ubity mouse-face highlight face org-link htmlize-link (:uri rmail:~/ubity/Mail/admin) keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) (C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . org-open-at-mouse)) line-prefix #( 0 2 (face org-indent)) wrap-prefix #( 0 4 (face org-indent))) 17 18 (fontified t org-category Ubity mouse-face highlight face org-link htmlize-link (:uri rmail:~/ubity/Mail/admin) keymap (keymap (down-mouse-3 . org-mouse-move-tree-start) (drag-mouse-3 . org-mouse-move-tree) (C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . org-open-at-mouse)) rear-nonsticky (mouse-face highlight keymap invisible intangible help-echo org-linked-text htmlize-link) line-prefix #( 0 2 (face org-indent)) wrap-prefix #( 0 4 (face org-indent) ad-Orig-org-open-at-point(nil nil) org-open-at-point() org-open-at-mouse((mouse-2 (#window 12 on Ubity.org 33203 (93 . 575) 15998773 nil 33203 (11 . 34) nil (5 . 14) (8 . 17 call-interactively(org-open-at-mouse nil nil) The problem seems to be related to the fact a #message-id is not given in the link, which is (happily!) allowed as per the Org manual. I also have two little suggestions in the same area. If message-id (in the #message-id suffix) has the form of a decimal number, maybe it could be taken as the message number to display? This is surely ill-designed and flaky, yet #1 would mean the first message. If a #message-id suffix is not given, there is no reason to prominently display a particular message, so org-rmail might use rmail-summary to show a summary of all messages. This seems the useful thing to do. François
Re: [O] Revealing when following file:NAME::LINENO
Bastien b...@gnu.org writes: François Pinard pin...@iro.umontreal.ca writes: Whenever one follows an Org link of the form file:NAME::LINENO, let me suggest that the found line be org-revealed automatically. In my opinion, this would be convenient for most people using such forms. Actually I think this is a good idea -- I pushed this change in master. Wow, thanks! I'll fetch a recent Org and try! François
Re: [O] Repeaters in plain timestamps
Hi, Org people.
Merely revisiting the Org mailing list after many days. Gosh! That
list is fairly active! :-)
Quoting an earlier message of mine:
The manual, section 8.3.2 Repeated tasks, says:
Some tasks need to be repeated again and again. Org mode helps to
organize such tasks using a so-called repeater in a DEADLINE, SCHEDULED,
or plain timestamp.
Examples and directions given in the page are related to DEADLINE, and
a few words suggest that SCHEDULED works the same. But the page does
not say how one may handle repeaters with plain timestamps. I merely
would like to update them so they show the date for the next
iteration, a bit like command t d already does on a DEADLINE
repeater.
For what it may be worth, I kludged this code for bumping the following
repeated timestamps on the current line. I stole most of the code, and
did not write much myself:
(defun fp-org-bump-timestamp ()
;; Adapted from (org.el) org-auto-repeat-maybe.
(interactive)
(save-excursion
(beginning-of-line)
(when (re-search-forward org-ts-regexp (line-end-position) t)
(let ((ts (match-string 1))
(whata '((h . hour) (d . day) (m . month) (y . year)))
n time)
(when (string-match \\([.+]\\)?\\(\\+[0-9]+\\)\\([hdwmy]\\) ts)
(setq n (string-to-number (match-string 2 ts))
what (match-string 3 ts))
(if (equal what w) (setq n (* n 7) what d))
(if (and (equal what h)
(not (string-match [0-9]\\{1,2\\}:[0-9]\\{2\\} ts)))
(user-error Cannot repeat in Repeat in %d hour(s) because no
hour has been set n))
;; Preparation, see if we need to modify the start date for the change
(when (match-end 1)
(setq time (save-match-data (org-time-string-to-time ts)))
(cond
((equal (match-string 1 ts) .)
;; Shift starting date to today
(org-timestamp-change
(- (org-today) (time-to-days time))
'day))
((equal (match-string 1 ts) +)
(let ((nshiftmax 10) (nshift 0))
(while (or (= nshift 0)
(= (time-to-days time)
(time-to-days (current-time
(when (= (incf nshift) nshiftmax)
(or (y-or-n-p (message %d repeater intervals were not
enough to shift date past today. Continue? nshift))
(error Abort)))
(org-timestamp-change n (cdr (assoc what whata)))
(org-at-timestamp-p t)
(setq ts (match-string 1))
(setq time (save-match-data (org-time-string-to-time ts)
(org-timestamp-change (- n) (cdr (assoc what whata)))
;; rematch, so that we have everything in place for the real shift
(org-at-timestamp-p t)
(setq ts (match-string 1))
(string-match \\([.+]\\)?\\(\\+[0-9]+\\)\\([hdwmy]\\) ts
(org-timestamp-change n (cdr (assoc what whata)) nil t))
Re: [O] Revealing when following file:NAME::LINENO
François Pinard pin...@iro.umontreal.ca writes: Bastien b...@gnu.org writes: François Pinard pin...@iro.umontreal.ca writes: Whenever one follows an Org link of the form file:NAME::LINENO, let me suggest that the found line be org-revealed automatically. In my opinion, this would be convenient for most people using such forms. Actually I think this is a good idea -- I pushed this change in master. Wow, thanks! I'll fetch a recent Org and try! François And Tadam! it works! :-) François P.S. Yet, only once removed that older Org spuriously installed in ~/.emacs.d/elpa/ by some third party. Grrr! :-)
[O] C-c ' and mail sources
Hi, Org people. Just observing this little nit. If I insert an email message (copy and pasted from Gnus in my case) within: #+BEGIN_SRC mail #+END_SRC the header lines of the message are highlighted with a reasonable set of colors. However, with the cursor within the message, I hid C-c ' twice, this has the effect of shifting the inserted message two columns to the right, the highlighting of the header is then lost. Not a big problem, and I expect that someone on this list will reply that this is an Org limitation (a way to say that the bug is innocuous enough to not deserve a correction). I rather use the word limitation for a bug which has been documented :-). In any case, this is a bug. I do not know what would be the reasonable way to correct it: preventing the shifting, or changing how highlighting interpret beginning of lines, in case of Org? François
[O] Slight l10n annoyances in Org, switching to Ubuntu 13.10
Hi, my fellow Orgers. I got annoyances in Org while switching to Ubuntu 13.10, and am sharing there here, in case others would inherit them, to save them some time. English users are not affected. The following problems are not pertaining to Org per se, they just show in there. The strange thing is that these problems have been reported years ago according to Google, and so, are apparently resurrecting. - Under the Unity window manager (maybe GNOME as well, I did not try), dead keys for applying diacritics stop working. One has to resort to the compose key or Emacs specific commands to type them. The problem is partly alleviated by adding this line in Emacs: (require 'iso-transl) but not completely: for example, the cedilla still does not work. Everything seems to work fine in applications other than Emacs, or using other window managers (I only tried spectrwm). - Within Org dates, the abbreviation of weekday is shown in English, while it used to be shown in French, which is appropriate in my case. Sebastien Vauban provided a solution: (setq system-time-locale (getenv LANG)) François P.S. I still have that my browser preference is not obeyed anymore despite I think I declared it, and will soon try to understand why.
Re: [O] org-grep, and problems
James Harkins jamshar...@gmail.com writes: I don't want to drag it out much further as it's well off topic, I'm sorry that my little grammar question, in the P.S. of the original message, generated all that traffic. I did not know the answers were so debatable, and was rather expecting a quick and conclusive reply from any English guy (or girl) around. Another notable point is that nobody replied to the Org questions in the original message, yet I quite understand that chasing bugs in someone else code is not an especially attractive activity :-). Keep happy all! François P.S. Who just upgraded Ubuntu to [...] Oops! No more P.S.'es :-)
Re: [O] org-grep, and problems
Suvayu Ali fatkasuvayu+li...@gmail.com writes: I can try debugging org-grep, but I don't know where I should start. I would either step through org-grep (using C-u C-M-x first over any line of the org-grep definition within org-grep.el, or add (message ...) lines within the function before to later check the *Messages* buffer, and after calling org-grep the normal way to trigger the trace, pay special attention to the argument given to shell-command. That command, repeated in a mere shell outside Emacs, should find hits in your Org files. If not, I would play with that command to see how it should have been written to be successful, then amend org-grep so it generates the proper command. If everything that should be found gets found, then I'd suspect the code after shell-command which reformats the output, and step through it to find where it does it wrong. The code is small, so the bug does not have much room to hide :-). François
Re: [O] org-grep, and problems
Suvayu Ali fatkasuvayu+li...@gmail.com writes: No matter what I search for, I get 0 results! I'm on Linux. Hmph! As it works nicely for me, I thought it would be useful to others. I'm saddened it does not work for you. How could we proceed so I try to help on this one? Write me privately if you feel like it (yet my replies may lag sometimes, I'm not always available). François
[O] org-grep, and problems
Hi, Org people. I recently rewrote my Emacs org-grep function, which surely nobody remember, as when we discussed it here, it was years ago! :-) The new writing gives nicer results, so I made it available as: https://github.com/pinard/org-grep However, I'm not satisfied. Maybe someone would be kind enough to explore and understand some of the problems I see, at least before I succeed in doing it myself. The two main problems are: - (save-current-buffer ...) or (save-excursion ...) fail to bring the cursor back into the current window, seemingly whenever an Org link gets followed within the Lisp form. - org-reveal leaves the cursor line collapsed. I can live with these two problems unsolved, as it only requires a few more manipulations as a user. They would be nicer solved, of course. Keep happy, all! François P.S. What is proper English: nobody remember or nobody remembers?
Re: [O] org-grep, and problems
Suvayu Ali fatkasuvayu+li...@gmail.com writes: No matter what I search for, I get 0 results! My org-directory points to the correct location: ~/org. Not sure what is wrong. Annoying! I just tried resetting org-grep-directories to nil here, as a way to force the default of org-directory, and it works well for me. Would you happen to be using Windows? I only tried it on Linux. It surely depend on find and grep being system commands. (And I should document that.) François
[O] Revealing when following file:NAME::LINENO
Hi, Org people. Whenever one follows an Org link of the form file:NAME::LINENO, let me suggest that the found line be org-revealed automatically. In my opinion, this would be convenient for most people using such forms. François
Re: [O] Spurious exporting of text before first header
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Hi François, Hello, Sebastien! :-) [...] if I have text and other contents prior to the first header of a file, those contents are indeed exported, while I would prefer not. [...] I have hundreds of Org files and for them all, have some personal conventions for their format and structure. [...} If you like text without initial heading in the exported file, but don't mind adding an heading in the Org buffer, you could add this: * Initial text :ignoreheading: and get what you want in the exported file. I might have no other choice, but it would be sad. As I said, I have hundreds of Org files, all carefully crafted, rather nice to my eyes, most of them using initial text for useful and special purpose. Adding an initial header everywhere would disrupt this nicety, for the sole purpose of getting around what I consider to be an Org bug, or limitation, or lack of happiness, depending on how you want to call it! The spirit behind :export: is that it marks exactly what is going to be exported. This implies, in my understanding, that everything else does not get exported. If the lines prior to the first header are exported whenever there is an :export: tag somewhere, it goes against the spirit and intent of :export: in my opinion. François
Re: [O] Spurious exporting of text before first header
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: If you like text without initial heading in the exported file, but don't mind adding an heading in the Org buffer, you could add this: * Initial text :ignoreheading: and get what you want in the exported file. As I had to move on this, I just added such headings everywhere. Sigh! :-) François
Re: [O] Spurious exporting of text before first header
Nicolas Goaziou n.goaz...@gmail.com writes: François Pinard pin...@iro.umontreal.ca writes: The spirit behind :export: is [...] I agree, this is a misfeature. This should be fixed in master. Thank you for bringing it out. Thanks as well. :-) François
[O] Spurious exporting of text before first header
Hi, Org people. This is an old annoyance of the Org exporter, yet I'm not sure what would be its best resolution. Whenever I use :export: tags on headers within an Org file, I expect only those headers and their contents to be exported (to HTML in my case), and almost nothing else, which I then consider private. However, if I have text and other contents prior to the first header of a file, those contents are indeed exported, while I would prefer not. Of course, #+TITLE and some other directives prior to the first header should be honored for their effect. One might surely debate on the best way to handle #+INCLUDE directive. I wish the above comments might generate either a correction in Org, or an advice for me! :-) François P.S. Some might suggest me that I avoid text prior to the first header. Surely, I have hundreds of Org files and for them all, have some personal conventions for their format and structure. For regularity reasons, I would much like to continue having private initial text.
[O] Repeaters in plain timestamps
Hi, Org people. The manual, section 8.3.2 Repeated tasks, says: Some tasks need to be repeated again and again. Org mode helps to organize such tasks using a so-called repeater in a DEADLINE, SCHEDULED, or plain timestamp. Examples and directions given in the page are related to DEADLINE, and a few words suggest that SCHEDULED works the same. But the page does not say how one may handle repeaters with plain timestamps. I merely would like to update them so they show the date for the next iteration, a bit like command t d already does on a DEADLINE repeater. François P.S. Someone on the list strongly advise me to avoid DEADLINE and SCHEDULED unless they are really meaningful for me, and so did I. But for many cases of events which are not heavy (birthdays are a good example), repeaters are still meaningful.
[O] GnuPlotMode reference in the manual
Hi, Org people. Long time no talk! :-) In the Org manual, we see: 3.6 Org-Plot Org-Plot can produce 2D and 3D graphs of information stored in org tables using `Gnuplot' `http://www.gnuplot.info/' and `gnuplot-mode' `http://xafs.org/BruceRavel/GnuplotMode'. The last link does not work properly. However, I found: https://github.com/bruceravel/gnuplot-mode which could probably replace it. I did not try the mode yet, however. François P.S. I've been away for a while, for health reasons. As I am not fully back yet, I may follow up and reply only sporadically.
Re: [O] Simplifying the weekly agenda a tiny bit, howto?
Eric Abrahamsen e...@ericabrahamsen.net writes: How do I get it quickly rescheduled then, when it is a regular activity? I find fairly convenient using t d to push an activity at its next slot in the future. Could I do something equivalent with mere time stamps? Hmm, I hadn't tried that with repeating events. I stole a few minutes this morning to make tries. Unless there are operator errors :-), I got the impression that t d over a simple time stamp with a repeating part dynamically turns in into a TODO entry, which would defeat the purpose of removing TODO. But, and this is where I'm still under the effect of surprise and some incredulity, it seems that I do not even have to use t d, the repeating nature of the time stamp being automatically taken into account while computing the agenda. In any case, I decided to follow your advice and see where it brings me: I removed the TODO keyword ans scheduling clauses the most I could, and merely doing that yields a cleaner agenda (cleaner by my own criteria, taste varies of course). There are a pile of commands for shifting timestamps/scheduled/deadline Which I often use. The annoyance of doing explicit shifting is that I have to look at the repeater to decide the shifting amount. I much prefer if it could be automatic, not requiring human scrutiny each time. If t d is your current solution, you're not actually re-scheduling meetings, just canceling them, right? Well, Org turns TODO into DONE. But if there is a repeating clause in the time stamp, the time stamp is advanced appropriately and the DONE gets immediately turned back into TODO again, all by magic. [...] or else use 'org-clone-subtree-with-time-shift' to just create a whole new heading for each meeting, with timestamps that can be adjusted individually. Oh! I found this command a bit polluting, enough to avoid it until now. Maybe I did not get how it could genuinely serve me? I do not feel the need yet! :-) There are many Org commands able to find, display and otherwise handle TODOs. If I stop using such keywords, wouldn't I give up the tools? It does take a bit of fooling to make the best use of the tools available... I'll try avoiding TODO in most cases, finding my way around without them and developing new habits as needed. I'll see where it will bring me... Thanks to you, and Richard as well, for the feedback! François
Re: [O] Simplifying the weekly agenda a tiny bit, howto?
Richard Lawrence richard.lawre...@berkeley.edu writes: If it's a regular activity, you can use a repeater in the timestamp, like: * Weekly meeting 2013-07-18 Thu 15:00 +1w Hi, Richard. I also noticed I may even write: * Weekly meeting 2013-07-18 Thu 15:00 +1w and the time stamp gets automatically hidden in the agenda. Nice! :-) For non-regular meetings, I have a capture template that allows me to easily enter them; Same here! you can do things like tag all your meetings with a :meeting: or :appointment: tag [...] I tried that too for a long while, tagging meeting and duties according to where I am, travelling between customers, and later understood that I could go without tags and still be happy, and even happier. The real truth is that I'm not much comfortable with the tag approach, just not in Org context, but in general. I once (a that has been quite a long once) tried Delicious, to found out that proper maintenance of tags requires a lot of energy when the collection grows significantly. The feeling of adding a tag and forgetting an item gives an impression of immediate speed, but one has to pay for it sooner or later, so all totaled, I now think I'm better to sort out information immediately where it should land in some hierarchical structure, and learn to do that efficiently, than to go the tag way. I do use tags with Org, but in small and specific ways; I try to avoid them otherwise. Hope that's helpful! Surely. Exchange of ideas and methods with nice and spekable people is always helpful, would it be only for the pleasure it gives! Keep happy! François
[O] Simplifying the weekly agenda a tiny bit, howto?
Hi, Org friends. Here is an (edited) copy of my weekly agenda: Week-agenda (W29): Lundi 15 Juillet 2013 W29 Mardi 16 Juillet 2013 Mercredi 17 Juillet 2013 Jeudi 18 Juillet 2013 notes: In 1 d.: TODO *Some meeting Automobile: In 4 d.: TODO Another thing [...] Vendredi 19 Juillet 2013 notes: 20:30.. Deadline: TODO *Some meeting Samedi 20 Juillet 2013 Dimanche 21 Juillet 2013 [...] The Vendredi (Friday) lines is clearly shown in red (yet in the quote above, it is likely shown in black and white!). So the Jeudi (Thursday) reference to the same activity is superfluous to me. I wonder if there is a (simple) way to inhibit, in a weekly agenda, any announced activity which appears later down in the same agenda. François
Re: [O] Simplifying the weekly agenda a tiny bit, howto?
Eric Abrahamsen e...@ericabrahamsen.net writes: First of all, if your event is a meeting, it should only be timestamped, not deadlined or scheduled. Then it will just show up where it's supposed to, and not before (or after). How do I get it quickly rescheduled then, when it is a regular activity? I find fairly convenient using t d to push an activity at its next slot in the future. Could I do something equivalent with mere time stamps? It probably shouldn't even be a TODO. Otherwise, scheduled TODOs show up on their schedule, and deadlined TODOs show up on their deadline, and also today's agenda, if you're coming up on the deadline. There are many Org commands able to find, display and otherwise handle TODOs. If I stop using such keywords, wouldn't I give up the tools? Maybe there are ways to reformulate them all using other commands, but at fist, it would require some searching, and acquiring new habits, presuming that there are alternative ways for all such tools. There are a host of variables [...] Check out variables starting org-agenda-skip-*, org-agenda-ignore-*, org-agenda-include-*, org-deadline-*, org-scheduled-* [...] Hope that helps, Undoubtedly :-). Thanks! François
Re: [O] feature request
Christian Moe m...@christianmoe.com writes: 42 147 writes: Is there anything like this available? Yes. Org-Babel supports Lilypond. It's magic. http://www.lilypond.org/ http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html Somewhere in my old files, I have a reference to an Emacs mode for entering music visually in a kind of ASCII mode, written by Neil Jerram if I remember correctly. But this was before Han-Wen and Jan wrote Lilypond. Now that Lilypond exists, it is an immensely more interesting avenue, in my opinion. Neil code would be fairly oldish anyway. I never tried using both Org and Lilypond as suggested, but it looks like a very appealing idea, I should try it. Thanks for the suggestion. François
Re: [O] feature request (rather off-topic)
Michael Brand michael.ch.br...@gmail.com writes: François Pinard pin...@iro.umontreal.ca wrote: Somewhere in my old files, I have a reference to an Emacs mode for entering music visually in a kind of ASCII mode, written by Neil Jerram if I remember correctly. I am very curios to see how this looked like and how it worked. With a quick search I was not able to find it. Hi, Michael. I looked around a bit, and found not much in my files. I cleaned up the GNU Music project many, many years ago and did not keep much of it. Even the Emacs mode (written by Neil Jerram unless I'm mistaken) did not survive for long in the project, as we (Neil included) selected another representation for music, still kind of 2-dimensional, but more compactly coded than an ASCII drawing. To edit this representation, instead of Emacs, we wrote a specialized curses-based program. I surprisingly still have scanner.l, parser.y, editor.c, and a few other files from that project, but really, this is of no interest nowadays. In my opinion, Lilypond is immensely more appealing! It seems that Neil Jerram, which sadly, I did not contact in ages, remained active in the Emacs communities, you should easily find him here and there by Googling. I see Neil Jerram nj...@cus.cam.ac.uk in http://stuff.mit.edu/afs/sipb/project/musictools/src/lilypond-2.6.3/AUTHORS.txt, but while I think unlikely that this address is still valid, I do not know. You might try to reach him there or otherwise, if you are curious enough: maybe that with some luck, he kept around some code or example? Let me share that I remember Neil as one of the most exquisite persons I ever worked with: it always has been a great pleasure. The GNU Music project underwent a long, dark episode when Richard Stallman forced a new direction and leadership upon us, seduced at the times by the promises of Robert Strandh, who brought the project into some moribund state. Han-Wen succeeded in getting the project back to life (I helped my best), to convey what later became Lilypond. Lilypond has been successful to the point GNU Music is never heard anymore by that name, and that's very OK: Lilypond goes much beyond our dreams and means. :-) The Lilypond musical notation is quite efficient. I often use it, with a pen on a sheet of paper, in the need of noting some music for myself, when away from home and any computer. For me, it's quicker than drawing staves and notes. I quite suspect that Lilypond notation, combined with the virtues of Babel, and the graphical capabilities of Emacs, might really be the best way to handle musical scores with Org. François
Re: [O] Org as a static site generator
Bastien b...@gnu.org writes: Oh, nice! I added a pointer in Worg: http://orgmode.org/worg/org-tools/index.html At the end of that page, there is: See the page Org Blogs and Wikis., with Org Blogs and Wikis clickable. However, the pointer resolves to file:///home/emacs/install/git/worg/org-blog-wiki.html. Some http://; was likely intended there? François
Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode
Thorsten Jolitz tjol...@gmail.com writes: it happened again [...]- François Pinard already had a fully fledged implementation of my new org-mode feature: 'org-weights.el' You're quite generous when you say full fledged :-). There are many details in which I find org-weights.el unsatisfactory, but as it is sufficient as it stands for my day-to-day usage, I'm not overly pushing on it (the pun is purely accidental). | * Header 1 *2 + 1... | ## * Header 1 [#1] I find the *2 + 1 far too verbose, in that it uses too much horizontal space, I much prefer the compact aspect of [#1]. What would be ideal, but I do not know if it can be organized, would keep the weights or hidden-lines information always glued to the ellipsis, and not hiding any underlying text as org-weights currently does. On the other hand, there are some virtue to the vertical alignment of weight information. Sigh! Nothing is perfect... [...] shows the overlay-info for *all* headlines except the one where point is on. That exception is a sad and questionable workaround, for being able to edit the current line. When, in normal and standard Org mode, I edit a line which has an ellipsis at the end, I may edit the line like any other one without seeing undesired effects. org-weights should be equally capable, and there should be no reason (ideally) to hide the information for the line where the point is, merely for editing to work. one problem I hit is that a visibility change does not uptdate all cookies/weights at once, they are only updated headline per headline when point is moved up and down. Is that for performance reasons? See the Caveats section at the end of org-weights documentation. Normally, the information to be updated may be minimized to the header above the line holding point, and then, recursively up. But there is a bug in this optimization when a header is demoted (as explained in Caveats). Another performance-related detail is the quadratic behaviour which may be seen in big, deeply nested Org files: it could be avoided by cleverly saving (in a hidden way) information on computations already done, and reusing it instead of recomputing it many times. But as usual with most cached optimization, it is difficult to get fully right. François
Re: [O] ical2org.py
Eric S Fraga e.fr...@ucl.ac.uk writes: I am not a python user [...] Hi, Eric. Nobody is perfect :-). Regards, François
Re: [O] RFQ - new contribution - org-screenshot.el
Max Mikhanosha m...@openchat.com writes: At Mon, 20 May 2013 13:45:48 -0500, Russell Adams wrote: What advantages would org-screenshot provide by comparison? To me the most useful feature is actually screenshot rotation shortcuts, I also have my own screenshot tool (this was my first own addition to Org mode, soon after I started to use it, quite a while ago now!) which is intermediate in features between Russell's and Max's. One thing I like in Max's approach is this capability of doing a Dired display, in which one segregates between used screenshots and orphan ones. When a document has many screenshots, such diagnostic help eases eliminating the dead wood and staying clean overall. François
Re: [O] GFDL
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: FMI, why is GNU GPL not applicable to the manual? While I would have long to say, here, I rather censor myself, mostly. I sometimes happen to think that the GDFL happened not so long after Richard Stallman and I had a harsh and long dispute about the GNU tar manual. In short, I wanted to publish it, Richard wanted that I refrain from doing so: he expected the manual to be a source of FSF revenue. The GDFL wording opens the door to Richard's restrictions, while the GPL, which I used, is more in the spirit of the remainder of the FSF. GNU tar has it own set of technical difficulties, and I hope I've been able to put it back on track so it became maintainable again. But in many non-technical ways, GNU tar has been an administrative nightmare. François
Re: [O] GFDL
Carsten Dominik carsten.domi...@gmail.com writes: I am curious, what passage does make such restrictions possible, and which kinds of restrictions? Oh, I did not read the GFDL in quite a years, and really have no interest in diving and scrutinizing it again :-). More away I am from all this, better I feel :-). Sorry, just forget I've written this morning, I was likely in some strange mood. I do love the FSF idea and theory, and supported the GNU project in an intense way for maybe more than twenty years. But by now, in practice, I just cannot stand their slightest abuse, anymore. I'm all for programming freedom, but this ought to include programmer freedom too! François
Re: [O] RFQ - new contribution - org-screenshot.el
Feng Shu tuma...@gmail.com writes: Haider Rizvi hari...@gmail.com writes: Max Mikhanosha m...@openchat.com writes: scrot screencapture import (imagemagick) https://wiki.archlinux.org/index.php/Taking_a_Screenshot http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272 Thanks for these links! :-) François
Re: [O] RFQ - new contribution - org-screenshot.el
Max Mikhanosha m...@openchat.com writes: [...] (require 'org-screenshot) [...] Thanks, Max, for sharing this! :-) François P.S. I appreciate the org-screenshot-image-directory function: by making it easy to override, the feature has been immediately useful to me.
Re: [O] initiate source edits and region
Carsten Dominik carsten.domi...@gmail.com writes: In a previous mail list discussion on this (delicate, almost heated) matter, Bastien finally ruled out that the preference in Org documentation and behaviour should use capitals. Could you please point me to that discussion? Thanks. I tried for a few jiffies to find pointers. I did find a few related messages written around or before 2012-05, but not that one containing Bastien's decision. The simplest would be to write Bastien directly (hoping he remembers). Do you read us, Bastien? The above command should also insert capitals, for Org being consistent with itself :-) Whatever the decision about capitals is retained or reversed, I would surely like if the manual was using one convention consistently, and that Org mode itself, while recognizing any capitalization, was consistently generating the same which the manual uses, of course. I think this would be one more useful option to add. An option could of course change how Org operates, but it would not change the manual. The default or implicit value for that option should then be consistent with the manual. - Carsten François :-)
Re: [O] initiate source edits and region
Sebastien Vauban writes: Yes, Eric: C-c C-v C-d Wow, I did not know that command, which seems quite useful! Thanks. However, it inserts the markers in lower case. In a previous mail list discussion on this (delicate, almost heated) matter, Bastien finally ruled out that the preference in Org documentation and behaviour should use capitals. As my preference then was then lower case, I edited all my Org files to use capitals instead, as a way towards consistency with Org. The above command should also insert capitals, for Org being consistent with itself :-) François
Re: [O] [PATCH] export to various flavors of (X)HTML
Christian Wittern cwitt...@gmail.com writes: On 2013-04-23 21:09, François Pinard wrote: If I remember well [...] Well, in this case you are misremembering, empty elements, aka as self-closing tags are one of the innovations of XML. Just my nit to pick, A friendly nit-picking is always a good way to get one another to improve. Thanks! François
Re: [O] [PATCH] export to various flavors of (X)HTML
Eric Abrahamsen e...@ericabrahamsen.net writes: I read that as just a better statement of what I was trying to say earlier: self-closing tags will render in HTML4, but they're not _strictly correct_ HTML4. I do not understand this assertion. I thought that HTML, up to but excluding HTML5, *is* also valid SGML. If I remember well, self-closing tags date back to SGML, not requiring (but also not forbidding) an introducing space to the closing slash. SGML does allow for closing tags to be optionally omitted (and for opening tags as well) but such optional omissions have to described in the DTD. These features were all meant to favor human legibility of SGML documents, and HTML did use them a lot. These, combined with the generality of the described grammar, made generic SGML validating parsers quite difficult to write, and also, quite expensive at the time (no real problem as most SGML projects usually involved big money). XML was all of a swing in the other direction: trading human legibility in favor of much easier parsing, and was quite successful as it addressed the same problems as SGML, but in a much cheaper and democratic way. But XML (and XHTML) are not SGML anymore. And HTML5 is neither :-). François
Re: [O] Org-mode documentation within Emacs
Alan Schmitt alan.schm...@polytechnique.org writes: Karl Voit writes: C-h i was my first guess but it does not list Org-mode at all :-( This is what I have in my configuration files: (add-to-list 'Info-directory-list /Users/schmitta/.emacs.d/org/info) Hi, Org people. Just in case useful, I added a command to Emacs just for listing the Org manual. Easy for me to remember: om == Org manual. Here is my little code, adapt to taste! (defvar fp-org-distribution ~/emacs/_/org-mode) ; [...] (defun fp-org-info () (interactive) (require 'info) (let ((Info-directory-list (cons (concat fp-org-distribution /doc) Info-directory-list))) (org-info))) ; [...] (global-set-key \C-com 'fp-org-info) François
Re: [O] Release 8.0
Bastien b...@gnu.org writes: I'm releasing Org 8.0. Fantastic work. Warm congratulations to all those involved! François
Re: [O] New maintainer
Bastien b...@gnu.org writes: Please raise your thumbs up or your concerns, if any. Bastien, your maintainership has been just outstanding, so far that I could judge. You're among the great maintainers I happened to meet, and I tremendously enjoyed your way of driving the project. Let me thank you for it all. I wish Carsten will get, from all of us — OK! given a proper email kill file :-) — the same level of good will, enthusiasm and collaboration we have seen on this user group all along for the recent year. François
Re: [O] Org-mode as a replacement for Google Reader
rai...@krugs.de (Rainer M. Krug) writes: Ack? That comes from ASCII (the first edition of the standard), which had two control characters (OK, it had more than two control characters, but I'm only looking at those two!): ACK and NAK, for Acknowledge and Negative Acknowledge. At this time, serial communications were often half duplex (only one side writes at a time), and prone to loosing characters. RS 232 defined RTS and CTS (Request to Send and Clear to Send) for implementing half duplex at the wire level. When at a higher level, things were differing depending on if you used asynchronous modems or rarer synchronous modems (where start bits and stop bits could be spared, so increasing the speed a tiny bit): asynchronous were using XON and XOFF (Transmission On and Transmission Off), synchronous were using ACK and NAK. Do I remember well? In ASCII 2, XON/XOFF/ACK/NAK were all renamed DC1/DC2/DC3/DC4 (not necessarily in that order), (DC stands for Data Control). Or was it SI and SO (Shift In and Shift Out)? I'm not sure. Yet, in any case, ACK and NAK remained in the culture for much longer. This is while going from ASCII 1 to ASCII 2 that NUL and BEL both acquired their second L :-). François
Re: [O] Attributes on HTML tables?
Bastien b...@gnu.org writes: Eric Abrahamsen e...@ericabrahamsen.net writes: The first step is probably to research the differences between xhtml and html 5. Well, I would even skip this step and just hack something usable. There are validators out there, that could help us staying on track, whatever the track :-). François
Re: [O] Enriched/Org is a colorful Org
Bastien b...@gnu.org writes: Thanks Eli, great to learn about the internals of Emacs display engine. Eli is, and always has been, quite a resourceful man. And along the years, I got the pleasure of discovering him as a good friend too! :-) François
Re: [O] Attributes on HTML tables?
Christian Moe m...@christianmoe.com writes: XHTML is also fussy about quoting attribute values, and about escaping special characters as HTML entities, including the ampersand (), and including inside attribute values. I'm guessing the exporter already does the right thing here. Org can of course take care of XTHML fussiness, there is likely no problem there. While on this subject! :-) Could Org allow the output of HTML5 rather than XHTML, under the control of some option? I've read that some frameworks really expect HTML5 to work properly, such an option might ease inter-operation between exported Org and such frameworks. François
Re: [O] CSS link in html export for v. 7.9.3e woes
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: I got into the same trouble days ago. Nicolas' answer was to use the new syntax therefore, that is: #+HTML_STYLE: ... There does not seem to be any reference to HTML_STYLE in the Org manual. (Org version 7.9.3e (7.9.3e-1751-g8c47da) — taken this morning). François
[O] Attributes on HTML tables?
Hi, Org people. I took a few hours today to move the Org generation for a few of my Web pages to the new exporter, and after a bit of debugging to understand how some changes were meant, got the impression that it mainly works! I'll have to wander around when I'll find some more free time, looking at the generated pages, to check that everything is OK. There is one little thing that does not seem to work, but I do not remember if it worked with the old exporter. The Org manual says: 12.5.5 Tables - Org mode tables are exported to HTML using the table tag defined in `org-html-table-tag'. The default setting makes tables without cell borders and frame. If you would like to change this for individual tables, place something like the following before the table: #+CAPTION: This is a table with lines around and between cells #+ATTR_HTML: border=2 rules=all frame=border Captions work indeed, but I do not see that attributes are transported on the generated table ... element. It seems to be always produced with the exact value of org-html-table-tag. François
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
Bastien b...@altern.org writes: It took me about one hour (my Gnus programming is rather rusty) for adding a Gnus command opening many tabs at once, in a graphical browser, for all articles I retain in Gnus for reading. That looks nice, is your hack public somewhere? No, but here it is, usage instructions follow. (defun fp-gnus-summary-open-links (arg) Open links in a browser for processable articles, like for Hacker News. (interactive P) (let ((articles (gnus-summary-work-articles arg))) (save-excursion (while articles (setq article (pop articles)) (gnus-summary-goto-article article) (gnus-summary-show-article t) (save-excursion (pop-to-buffer gnus-article-buffer) (re-search-forward a href=\\\([^\]+\\)\Link/a) (browse-url (match-string 1))) (gnus-summary-remove-process-mark article (gnus-summary-position-point)) (defun my-gnus-summary-mode-hook () (define-key gnus-summary-mode-map \C-cnl 'fp-gnus-summary-open-links) ;; ... ) (add-hook 'gnus-summary-mode-hook 'my-gnus-summary-mode-hook) The function selects articles according to the process/mark convention, and I want it to fail whenever an article does not have a Link button (that's why I do not catch the error if re-search fails). So, I use it this way. In an RSS summary buffer, I use C-k to read without opening any subject I want to skip. Once done, I use x M P A C-c n l to remove all article I C-k'ed, add a process mark on everything else, then transfer marked articles into a graphical browser, one tab per article. Transferred articles also get read in the summary buffer. I also use this bit of Emacs Lisp code in ~/.emacs, which is related: ;; Chrome (really xdg-open) ;; (defun browse-url-xdg-open (url optional new-window) Ask the default browser to load URL. Default to the URL around or before point. (interactive (browse-url-interactive-arg URL: )) (shell-command (concat xdg-open (shell-quote-argument (browse-url-encode-url url) (setq browse-url-browser-function 'browse-url-xdg-open) François
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
Suvayu Ali fatkasuvayu+li...@gmail.com writes: For me it is the other way around. I want to couple with Emacs more closely, but Gnus prevents me from doing so. A few gripes follow. 1. Emacs is single threaded, so a network interruption while reading my email over IMAP means my emacs server is stuck! It would be so appealing if Emacs was really using threading for its windows. Tom Tromey seems to be making a very courageous attempt at it, but is still hitting various problems and walls. I wonder if he will succeed at the end. In my case, Emacs is indeed stuck for a few seconds, not enough to bother me significantly. I read that some people combine fetchmail, procmail and other tools so Emacs does not IMAP itself; I just did not want to dive into all the locking and synchronization issues implied by such tools. 2. Oh that's easy to solve, use maildirs (sync with OfflineIMAP). That does not work well because Gnus uses its own flags (an example where Gnus actually breaks standards)! There are some hacks around that out in the wild, so let's let it slide. 3. Gnus stores some meta information/cache for maildirs in a .nnmaildir folder *inside* the maildir directory tree! maildir ├── .nnmaildir ├── cur ├── new └── tmp I do not know how, but this supposed meta information or cache takes about 2/3 of disk space as the original maildir! Obviously that is a problem for large mailboxes. I never really studies IMAP, and use it rather naively, so I take your word about Gnus not being straight about it. Sorry to hear that. I've not been bitten yet, or maybe I'm just too naive to know. However, I remember that I often had to read Gnus structures in external, non-Emacs programs, and it is indeed a challenge each time. I merely try to not do that anymore! :-) I use mutt-kz (mutt with notmuch integration) and emacsclient. With support for linking using org-notmuch, I couldn't be happier. Thanks for the hints, which I save, could be useful one day, who knows! :-) When I left Emacs for other lands, years ago, I decided for Mutt and used it for many years (before switching to others, and finally Thunderbird). With many stunts (a bit too much of them should I say), I could get Mutt to do about anything I wanted (but never had such success with Thunderbird). Back to Gnus, and configuring it as little as I can, I have the impression of recovering some simplicity on the user side. Moreover, Org nicely plays with Gnus (or almost). François
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
rai...@krugs.de (Rainer M. Krug) writes: Sanity - never heard of it. I am giving gnus a few weeks and then I wil see - I think I am getting used to it (*not* understanding it!) Hi Rainer! I surely tried many mail user agents (MUAs) in my life and, sad to say :-), Gnus is undoubtedly the most featured and flexible, while being the one which best respects various standards in the field. If I write sad to say, this is because Gnus coupled me more intimately with Emacs, while I tried hard to run away of it, to recover some sanity. To no avail: after many years of abstinence, and with reluctance and dismay, Org got me back in it. Org is so good that I could not resist. In the meantime, despite I found some MUAs quite impressive, I knew deep down that none really match Gnus. So, when Org thrown me back in Emacs, and given Org and Gnus integrate rather well with one another, Gnus was the next logical step, which I do not regret yet. A tiny example from yesterday. Knowing that Google Reader is soon going to leave us, and after a few other unsatisfying tries, I finally opted for Gwene + Gnus, and found out that the UI is even more efficient than Google Reader, at least for me, to sort out what I want to read and what I want to ignore. Some groups (Hacker News is typical) only yield links in Gnus, with no text. It took me about one hour (my Gnus programming is rather rusty) for adding a Gnus command opening many tabs at once, in a graphical browser, for all articles I retain in Gnus for reading. I do not see any other environment in which such tiny projects would stay reasonably small and tractable. François
Re: [O] Org-mode as a replacement for Google Reader
Jude DaShiell jdash...@shellworld.net writes: Now, how to get from what's in info newsticker to actually adding a real feed and have newsticker work is another matter entirely. I gave it a quick try, and found frustrating that it looks attractive in its display and specs, that it seems to be nicely done at first glance, but that it invariably throws Emacs in what seems to be an infinite CPU loop, leaving me no choice than to kill Emacs each time. Sigh! François
[O] Warning while publishing
Hi, gang. While publishing Org files in batch, I see these warnings: Warning: defvar ignored because org-agenda-archives-mode is let-bound Warning: defvar ignored because org-agenda-skip-function is let-bound which are likely innocuous, but I'm not sure. At first, I do not understand why agendas get into the picture of publication. Some more detailed information, in case useful. The publishing script (called many times from a Makefile) is: --- #!/bin/dash echo echo Publishing $1 echo Publishing $1 | sed 's/./-/g' echo if [ -n $2 ]; then rm -f $1 ln -s $2 $1 cp setup.org $1 fi emacs -Q --batch --load publish.el --eval '(org-publish '$1' t)' 21 \ | egrep --line-buffered -v '^(Fontifying|Publishing|Skipping) ' \ || : rm -f $1/*~ if [ -n $2 ]; then rm -f $1/setup.org $1 fi --- and publish.el is: --- (defvar api-org-distribution ~/emacs/_/org-mode) (add-to-list 'load-path (concat api-org-distribution /lisp)) (require 'org) (org-babel-do-load-languages 'org-babel-load-languages '((ditaa . t))) (setq org-confirm-babel-evaluate nil org-export-allow-BIND t org-export-default-language fr org-export-with-sub-superscripts nil org-html-coding-system 'utf-8 org-html-postamble nil) (setq org-publish-project-alist `((base :base-directory ~/ubity/org :exclude ^setup.org$ :publishing-directory ~/ubity/html :publishing-function org-html-publish-to-html) (asterisk :components (asterisk-data asterisk-text)) (asterisk-data :base-directory ~/ubity/org/asterisk :base-extension png :publishing-directory ~/ubity/html/asterisk :publishing-function org-publish-attachment) (asterisk-text :base-directory ~/ubity/org/asterisk :exclude ^setup.org$ :publishing-directory ~/ubity/html/asterisk :publishing-function org-html-publish-to-html) (control2 :components (control2-data control2-text)) (control2-data :base-directory ~/ubity/org/control2 :base-extension png :publishing-directory ~/ubity/html/control2 :publishing-function org-publish-attachment) (control2-text :base-directory ~/ubity/org/control2 :exclude ^setup.org$ :publishing-directory ~/ubity/html/control2 :publishing-function org-html-publish-to-html) (control3 :base-directory ~/ubity/org/control3 :exclude ^setup.org$ :publishing-directory ~/ubity/html/control3 :publishing-function org-html-publish-to-html) (octopasty :components (octopasty-data octopasty-text)) (octopasty-data :base-directory ~/ubity/org/octopasty :base-extension png :publishing-directory ~/ubity/html/octopasty :publishing-function org-publish-attachment) (octopasty-text :base-directory ~/ubity/org/octopasty :exclude ^setup.org$ :publishing-directory ~/ubity/html/octopasty :publishing-function org-html-publish-to-html) (prov_ng :components (prov_ng-data prov_ng-text)) (prov_ng-data :base-directory ~/ubity/org/prov_ng :base-extension png :publishing-directory ~/ubity/html/prov_ng :publishing-function org-publish-attachment) (prov_ng-text :base-directory ~/ubity/org/prov_ng :exclude ^setup.org$ :publishing-directory ~/ubity/html/prov_ng :publishing-function org-html-publish-to-html) (ubitopasty :base-directory ~/ubity/org/ubitopasty/ :exclude ^setup.org$ :publishing-directory ~/ubity/html/ubitopasty :publishing-function org-html-publish-to-html) )) (add-hook 'org-publish-before-export-hook 'save-buffer) ---
Re: [O] posting guide?
Jay Kerns gjkerns...@gmail.com writes: As Org grows there will be additional newbies (hopefully hundreds!) and additional hostile individuals (hopefully epsilon). Those are the two categories targeted by this proposal. I sadly have to agree somehow. The Perl crowd, for example, was warm and interesting when it began, long ago, before later turning in a boiling riot and a place to run away from. The Python crowd is still not so bad, but it is not anymore the cozy place it was in its beginnings. Popularity seemingly comes with a price. Sigh! For Org mode, maybe it is a bit premature, as it is not an urgent matter yet. Maybe energies could be best invested elsewhere for the time being. François
[O] colorg weekly report
Hi, people. Still had absolutely no time for computers this weekend. It may take maybe two weeks still before my move is complete enough that I can work again in my new location. I'll resume my weekly reports only then. François
Re: [O] Org Community
Scott Randby sran...@gmail.com writes: There is one individual who is poisoning the atmosphere by engaging in unfair and unfounded name calling that simply should not be included in messages to this list. The Internet wisdom (I mean, years of accumulated experience by lots of people) suggests that we completely ignore those who troll. This requires that we educate us, between ourselves, to ignore such people. They are fed by those who cannot resist replying to them. If none do, they usually disappear within a few months -- or a few years :-). Kill files (in email readers) are useful for ignoring poisoning people. Now this person wants to take some of their contributions out of org. This is in such circumstances that clear FSF assignments prove useful. I've seen this scenario repeating for other software, here and there, for years (I've been around for quite a while). People have opinions, that's OK. But when their way does not lead anymore, some of them attempt destruction, more or less progressively, by all means possible, psychological and technical. They only have the power we give them. When we get moved enough to reply, we give them power. Best is to ignore them, and learn to stay completely calm inside. See they are sick, do not get affected. Do not even attempt to heal them. If you do not have enough means of self-control and just cannot resist, then feed them privately, to spare the rest of the community. François
Re: [O] Org Community
Loyall, David david.loy...@nebraska.gov writes: the org-mode community should do what we can to oblige Jambunathan's request, even if/when we're not legally required to do so. I read you, but no, not in this case. (Don't each of you feel that your code is a part of you?) Yes, of course. However, when I put my own code under the GPL, and make my projects forkable, I really, really mean it. It did happen that I was not fully happy with the consequences, but not enough to kill my own generosity. If I ever change my mind, well, too late, and that's OK. I may act differently for the later code I'll write, but what is already given is well given. I might have been someone else when I gave it, before I changed. But as I'm not that another guy anymore, I should not claim anything about that previous me. Unless I'm pretty rotten, in which case I'm not even worth being listened to. Supposing that the group agrees that the code should be removed somehow, The only reason to remove code owned by the community would be that it is not pleasurable enough to maintain, then consequently gets obsolete and useless. If nobody cares about the code, it's a different story. François P.S. I only once advocated for the withdrawal of an FSF assignment, and I even got the related papers destroyed at the FSF headquarters. The related code was not so widely distributed that the withdrawal would really hurt people, and the requester was deeply polite and human in his way to explain his motivations. He was also well aware of the meaning of his previous commitment. So, it has been a pleasure for me, and everybody I contacted, to help. It was human on every side. Here, as far as humanity and politeness is concerned, one side is surely missing. Let's not spoil anymore time at that level, it would be a waste.
Re: [O] [RFC] Org syntax (draft)
Nicolas Goaziou n.goaz...@gmail.com writes: As discussed a few days ago, here is a document describing the complete Org syntax as read by the parser. Fantastique! :-) I'm preciously saving this! François
Re: [O] Support Freemind/Freeplane export
Jambunathan K kjambunat...@gmail.com writes: How many people are going to read HTML code? [...] In short, the concern you have raised is more cosmetic than functional. Replying to the org-mode mailing list. I did not closely followed the discussion, so maybe I'm missing the point. A lot of people are not going to read HTML, but it does not mean that nobody does. Many people still read HTML code, for a variety of reasons. I find HTML code should stay as legible as possible. As long as legibility is at stake, character entities are a pain in the neck (or anywhere else of your choice along the spine!). So, if the charset of the HTML can be ascertained, usually within the headers, the remainder of the HTML file should take full advantage of it, and limit character entities as much as possible. Character set entities are meaningful when the HTML file does not declare a charset. They should be avoided otherwise, in my opinion. François
[O] colorg report
Hi, Org people. Here is my (short) weekly status on the colorg project! This weekend either, I did not have much time to push on colorg. Yet, I got the inner guts of a test generator, using a fresh colorg server for each test. Starting and stopping colorg servers in quick succession showed latency problems, now solved. On my next visit (likely in one week), and following my plan, the generator will acquire test patterns. François
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Nicolas Goaziou n.goaz...@gmail.com writes: I can write a document describing Org syntax, as seen by the parser [...] That would undoubtedly be useful. There is a need I often have, and never found the time to fill so far, for a dependable Python parser for Org syntax. I thought I could read the Emacs Lisp code of the parser to get a firm grasp of the syntax first, but surely, a formal document acting as a reference might be easier for me to get me started, at least in that it separates what is official and what is incidental in the syntax. I got the vague impression (unsubstantiated right now, I've not been in that area of Org for a while) that it would help uncoupling Org syntax from some Emacs intricacies. I'd need a serious revision to get a firmer opinion. François P.S. Another need I think I'll soon have is some machinery for generating HTML out of dynamic Org snippets, using Python. I could of course have Emacs running in background to serve a Web application, but it looks rather awkward to me, and for one specific application of ours, I really starve for using Org instead of HTML, whenever possible.
Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)
Yagnesh Raghava Yakkala h...@yagnesh.org writes: There is a need I often have, and never found the time to fill so far, for a dependable Python parser for Org syntax. Not sure how complete it is [...] https://github.com/tkf/orgparse Thanks for the pointer. With about 150 commits already, it seems that a good effort was invested in it. Do you know happen to know how conforming it is? I wrote many ad hoc parsers for Org already, but what I would like is something really close to the parser which comes with the new exporter, both in syntax and concept nomenclature, so I could switch to it once and for all and delete all my hacks. :-) François
[O] tabulated-list
Hi, Org people. This morning, I could not load Org because ox.el calls function tabulated-list, which does not seem to exist on this version of Emacs. So I fetched the one at https://github.com/sigma/tabulated-list.el to get going, but others will likely have the same problem. François
Re: [O] tabulated-list
Nicolas Goaziou n.goaz...@gmail.com writes: this change because I was reinventing the wheel in `org-export-stack'. I hadn't realized [tabulated-list.el] was emacs24 only. Bastien, is there another solution besides reverting the commit? Could tabulated-list.el be conveyed within Org as org-tabulated-list.el and loaded only if tabulated-list is not already available? François
Re: [O] C-c ^ not fully useful
Bastien b...@altern.org writes: [1] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=30d6dc [2] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=662cb9 While your commits are rather small, I would likely never have figured out how to do them, the magic goes over my head. It's a little like playing go against someone who is far from your own level: you objectively observe that the heavens is falling apart on your head, but you just don't understand how nor why it is happening. :-) By the way, Bastien, it seems that your correction wonderfully works. It's so comfortable being able to see long lists of links (visually) sorted in a correct way. Thanks a lot for this. François P.S. About an option to sort the previous way, that is, by the physical contents of the line, visible or not, I do not have a use case for it, I would not need such an option. I sometimes, yet not often, need to group together links by their originating site, and then, the standard Emacs line sorting function gave me a very good approximation, good enough for my little needs.
[O] colorg status
Hi to all my Org friends. Sigh! I just had no freetime for colorg this weekend. With some luck, I should be able to resume with automated testing, next weekend. François
Re: [O] org-bullets extension
E Sabof esa...@gmail.com writes: In any case, I've updated org-bullets to use compose-region. You can get it from here: https://github.com/sabof/org-bullets Hi, Evgeni (and gang). I've been trying this new org-bullets today, and I did not meet yet some of the problems I observed before. So, at first glance, it looks good: I'll use it more regularly in the incoming days. Thanks for this! :-) François
[O] file-equal-p undefined
Hi again. In a recent checkout of Org mode, ox.el (org-export-output-file-name) calls function file-equal-p, which does not seem to exist for me, on this Emacs 23.4. It seems to exist in more recent Emacses however. François
[O] C-c ^ not fully useful
Hi, Org people. C-c ^ (org-sort) is not as useful to me as I would like it to be. I often have lists in which each item start with a link. When sorting such lists, because of the [[URL][TITLE]] coding, entries are sorted along the domain of the link (the URL), which is useful in itself of course, but often not as comfortable as if the sort was done on TITLE. One could provide a function for extracting the sorting key out of the current line (I did not try this facility yet, I presume this is how it works), so I could likely solve my own problem, as described above. The ideal for me would be that some Lisp function exists to extract the visual line out of the physical line, that is, the line once all invisible parts have been removed. This would take care not only for links, but also for highlighting marks (like =~*/) when they happen to be hidden. However, I guess I'm not alone wanting C-c ^ to do what is most expected. So, these few suggestions: - Could org-sort, by default and for most of its current option letters, sort alphabetically (or lexicographically as they say!) over the visual aspect of the line instead of its physical contents? It might be difficult if Emacs has no function to reach the visual aspect of a line. I guess that most users would expect a visual sort. - Options might be added to sort over the physical contents of the line instead. And there always is M-x sort-lines RET !). - Could some parameterisation be added so one could map user written functions over (free) option letters? François
Re: [O] Reloading uncompiled and testing from several git branches
Achim Gratz strom...@nexgo.de writes: François Pinard writes: Any Makefile which lists dependencies while expecting them to be satisfied sequentially, one after another, is broken. Make does not (theoretically) guarantee the order, while in practice, all make programs I know satisfy dependencies from left to right. Well, if you're going to pick nits: in this case, nothing is broken. It's known that we're going to use GNU make and that no parallel execution is taking place. I did not follow these things in years, they might have changed. At some time in the past, GNU packages had to follow GNU standards. We had to write portable Makefiles, could not depend on GNU make, and could not depend on the serial evaluation of dependencies. Many users had things like MAKEFLAGS=-j4 in their environment, so it blindly applied to all their builds. Maintainers would not know that no parallel execution is taking place, because it was the installers, and not them, to decide. GNU libc has been the first important GNU package which broke the rule and started to require GNU make; it's true that the GNU libc maintainer and the GNU make maintainer were the same guy. I guess that GNU libc was so late that Richard Stallman allowed that exception. Now that Linux exists, it is very frequent to see packages requiring GNU make, and GNU standards are taken much more lightly than they used to be. Looking at the GNU make documentation, I find something new to me: [If] .NOTPARALLEL is mentioned as a target, then this invocation of make will be run serially, even if the ‘-j’ option is given. Any recursively invoked make command will still run recipes in parallel (unless its makefile also contains this target). Any prerequisites on this target are ignored. So now, the maintainer may prohibit parallelism from his side, and while I did not see that GNU make explicitly guarantees left to right evaluation and execution, the above says serially without telling the order. I would be tempted to think that the GNU make documentation is voluntarily silent on the matter, as we may not depend on it. If you depend on the order, you depend on the implementation of Make, not on its specifications. That's why I use the work broken. All this is academical, and not much important. For a long while now, the effort for correct Makefiles faded away; this cannot be repaired. François
[O] Colorg weekly report
Hi, my Org friends. Real life rather caught me this weekend, to the point I had only very little free time, not enough to sensibly advance the colorg project. My plan was to program an automatic test generator for colorg-server. I wrote down notes about what it will be (but not worth committing). I came to realize that if I hand-write precise tests, I'll likely miss in my tests whatever cases I miss in the code. I'll rather have thousands of tests generated, and save only a few in a repeatable regression suite: some which are representative, or those which triggered problems. So, hopefully, next weekend will be about tests, and solidification. François
Re: [O] Reloading uncompiled and testing from several git branches
Achim Gratz strom...@nexgo.de writes: .PHONY: testclean # in case you'll ever have a file named testclean testclean: test clean In general all such targets that are simple combinations of existing teargets can be added that way. Allow me a pedantic nit-pick, yet nothing so important in practice nowadays. Any Makefile which lists dependencies while expecting them to be satisfied sequentially, one after another, is broken. Make does not (theoretically) guarantee the order, while in practice, all make programs I know satisfy dependencies from left to right. In theory, still, make and make -j4 (say) should yield the same actions and effect. Automake-generated Makefiles respect this — or at least, they once did, I did not check in a long while. François P.S. In fact, for the above reason and also for a flurry of other reasons, often related to portability, almost all Makefiles are broken. It is so difficult to get them right that an AM_MAINTAINER_MODE macro has been added to Automake as a way to generate and sanctify incorrect ones. A perfect Makefile is very rare.
[O] org-weights.el
Hi, gang. A few times already, I spoke on this list of my need to see the weights of subtrees on header lines. Nicolas Goaziou was kind enough to write the function for computing the weights, I wrapped some Lisp code around this, and shared the result on this list. In that code, I had a command which computes and displays the weights, and as soon as I modify the buffer, the weights were disappearing. I recently had the need to frequently re-evaluate the weights after modifications, and got tired of repeating the displaying command after each modification. So I modified the code so the weights get updated instead of disappearing. Bastien also suggested that I turn my code into a small library. If you are curious, see the results as: https://github.com/pinard/org-weights It works relatively OK for me. Bugs surely remain. :-) François
Re: [O] Offer for taking over maintainership
Bastien b...@altern.org writes: Actually, one of the reasons I want to step down in the long run is that I'm a bit frustrated of not having time enough to focus on big new features. But the flow of new users and new contributors is rewarding enough so that maintaining Org keeps being fun :) A good maintainer, in my opinion, does not necessarily have to be the main contributor in term of code or features. I more expecting him (or her) to have good judgment and take equilibrated decisions, meant to protect the overall spirit of a project and to nudge it in a sound direction. And of course, to have high human and communication skills. A maintainer who always says yes! and consider himself (or herself) as nothing more than a committer of service is likely to soon drive a project into a drab status. Behind anything nice, software included, there needs to be an artist and a mind, much more than a committee. And almost always, an artwork never fully pleases everybody. François
Re: [O] Offer for taking over maintainership
Jambunathan K kjambunat...@gmail.com writes: I never remember being rude to you. I do not remember you've ever been rude with me. It's not personal. It's just that I would like Org to return to its peaceful and happy road. You announced in some earlier message that you were unsubscribing from the list. Another avenue would be to rediscover what it is to be joyful. Either way, I wish you'll be successful at censoring yourself. Surely, it's a bit naive for me to think I could calm a flaming mind. I've met others in my life, and usually *completely* ignore them. I'm replying here only because of this tiny bit of admiration that still remains in me from your previous works and involvement. When nothing will remain, I'll very easily return to silence. François
