Re: [O] "Smart" quotes
Hello, "Mark E. Shoulson" writes: >> The regexp may be able to tell level 1 from level 2 quotes. > > Do you mean that the author would use the same characters for both > first and second level quotes, and the regexp would be smart enough to > distinguish which level each was at? I don't think that's possible, > and you probably don't either. Actually, I do. Since you can tell an opening quote from a closing one by the position of the white space (or parenthesis, beginning/end of line) near it, I think you can deduce the quote level. I may be wrong, though. > "this is a 'quote', and that's all you need to know." > > becoming, for instance > > «this is a ‹quote›, and that’s all you need to know.» "this is a "quote", and that's all you need to know" is as parsable to me. As a side note, at least in French, many typographers would recommend "this is a /quote/, and that's all you need to know" here. Oh, and I know that was just an example. > I'd love to get org more export-friendly. I'll see what I can > understand of the (new) export code. Do not hesitate to ask questions about it. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Let org-agenda-time-grid control if the grid is displayed
Hi Matt, Matt Lundin writes: > Bastien writes: > >> Christophe Junke writes: >> >>> Let org-agenda-time-grid control if the grid is displayed >> >> Applied, thanks -- and special thanks for the ChangeLog and >> clear explanations. > > This is a problematic patch. On my machine, it causes duplicate entries > to show up in the agenda. The reason, I believe, is because > org-agenda-add-time-grid-maybe takes the list of agenda items and > returns that list with time-grid stuff added. This patch appends the > list of agenda items to the list that org-agenda-add-time-grid-maybe > returns, thus resulting in the duplicates. Mhh.. I've been testing too hastily. Thanks for reporting this, I reverted the commit. Christophe, can you look again and amend your patch if needed? Thanks! -- Bastien
Re: [O] [PATCH] Let org-agenda-time-grid control if the grid is displayed
Bastien writes: > Christophe Junke writes: > >> Let org-agenda-time-grid control if the grid is displayed > > Applied, thanks -- and special thanks for the ChangeLog and > clear explanations. This is a problematic patch. On my machine, it causes duplicate entries to show up in the agenda. The reason, I believe, is because org-agenda-add-time-grid-maybe takes the list of agenda items and returns that list with time-grid stuff added. This patch appends the list of agenda items to the list that org-agenda-add-time-grid-maybe returns, thus resulting in the duplicates. Best, Matt
Re: [O] Org-mode repeating tasks issue
Thanks for the responses. After fiddling around a bunch and not getting it to work, I just recreated my .emacs.d folder (and config) and it seems to work now. Must have been some corruption, but can't figure out what. Thanks a bunch for the responses c.b On Mon, May 21, 2012 at 6:06 AM, Bernt Hansen wrote: > John Hendy writes: > > > On Sat, May 19, 2012 at 7:41 PM, c b <24x7x...@gmail.com> wrote: > >> > >> Hi, > >> > >> I have been using org-mode with emacs(23) for about a year now and love > it. > >> > >> However, sometime in the last couple of weeks, I did a git pull on the > master branch (and I redid the same today) and noticed that my recurring > tasks are broken. > >> > >> E.g. > >> > >> I have a task > >> > >> ** TODO Pay Creditcard bill > >>DEADLINE: <2012-05-15 Tue +1m -7d> > >> > >> and when I marked it done, it changed state to DONE > >> ** DONE Pay Creditcard bill > >>CLOSED: [2012-05-18 Fri 22:13] DEADLINE: <2012-05-15 Tue +1m -7d> > >> > >> > >> I have been trying to figure out what went wrong, but am clueless. Any > pointers on what might be wrong, would be appreaciated. > >> > > > > I don't use this much, but have been contemplating it and thus the > > various org-mode pages on repeating tasks are somewhat fresh in my > > head. Here was my initial thought: > > > > - The org-mode manual itself on repeated tasks does not mention that > > kind of repeating task syntax > > --- http://orgmode.org/manual/Repeated-tasks.html#Repeated-tasks > > --- Only +1, ++1, and .+1 are discussed > > > > - The /org-habit/ page, on the other hand, does mention such syntax > > (well, kind of) > > --- http://orgmode.org/manual/Tracking-your-habits.html > > --- Note that this page uses .+2d/4d syntax > > > > Anyway, I very likely missed something, but I can't find the specific > > syntax you're looking for in the manual sections above. If the > > functionality of org-habit /does/ do what you want, perhaps you could > > switch to that? If you use this syntax widely, that could be a pain. > > > > Let me know what you think? Also, please point to the documentation > > illustrating the +1m -7d usage. I'd like to see it as well as I'm > > curious about the various time stamp options. > > > > DEADLINE: <2012-05-15 Tue -7d> > is a standard deadline with a 7 day warning period as defined in section > 8.3 Deadlines and scheduling. > > DEADLINE: <2012-05-15 Tue +1m -7d> > > This just adds a monthly repeater to the syntax and is perfectly legal > syntax AFAIK. > > This entry repeats normally for me. > Org-mode version 7.8.10 (release_7.8.10-578-g42f7ba @ > /home/bernt/git/org-mode/lisp/) > GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on > raven, modified by Debian > > Regards, > Bernt >
Re: [O] Largest org file you have + performance
Hi, SW writes: > Is this performance overhead just a result of poorly-scalable overlays, rather > than an inherent shortcoming of Emacs and/or org-mode? I would say this is a combination of the implementation overlays and the use of overlays in outline.el. Perhaps we should dive into outline.el and see how we can improve things from there. (We tend to forget that Org is just a derived mode from outline.el!) -- Bastien
Re: [O] PATCH: follow timestamp link also in heading
Samuel Wales writes: > Perhaps we should make RET do this also when RET follows links. Indeed, that's now the case. Thanks! -- Bastien
Re: [O] [PATCH] Add section describing prerequisites.
Hi Greg, Greg Troxel writes: > Note that building org requires GNU make, and that 3.82 is known to > work. Thanks for this. I've been minimalist: http://orgmode.org/w/?p=org-mode.git;a=commit;h=0103d1 I don't want to update the README file each time a new version of GNU Make is released and known to work. > Begin to list the versions of emacs that org can work with. (It seems > clear taht some versions of XEmacs work, but I couldn't find out > which.) Stating that Emacs is needed to an Emacs library is pretty obvious. Listing the oldest Emacs and XEmacs versions is more useful, but we need to be more precise: can someone tell me what is the oldest Emacs version the current master is running fine with? Same for XEmacs? Thanks, -- Bastien
Re: [O] #+STARTUP: showstars (#+STARTUP: showlaststar)
Nick Dokos writes: > Then you have to live with the stars. I think it is awesome to live with the stars. :) -- Bastien
Re: [O] Escaping links while doing an org-publish to html
Hi c (?), c b <24x7x...@gmail.com> writes: > Is there a way to do prevent org-mode from setting up A-links or > IMG-links? Not with the current HTML exporter (perhaps Nicolas as a solution for the next HTML exporter.) But you can use `org-export-html-final-hook' to postprocess the exported buffer. HTH, -- Bastien
Re: [O] [PATCH] Let org-agenda-time-grid control if the grid is displayed
Hi Christophe, Christophe Junke writes: > Let org-agenda-time-grid control if the grid is displayed Applied, thanks -- and special thanks for the ChangeLog and clear explanations. All best, -- Bastien
Re: [O] [PATCH] Add section describing prerequisites.
Bastien writes: > http://orgmode.org/w/?p=org-mode.git;a=commit;h=0103d1 > > I don't want to update the README file each time a new version of > GNU Make is released and known to work. Understood - what I meant was to have the oldest version that was needed, but I suspect that while org needs GNU make, anything from the last 5 years is ok, so it's not important. >> Begin to list the versions of emacs that org can work with. (It seems >> clear taht some versions of XEmacs work, but I couldn't find out >> which.) > > Stating that Emacs is needed to an Emacs library is pretty obvious. agreed, but > Listing the oldest Emacs and XEmacs versions is more useful, but we > need to be more precise: can someone tell me what is the oldest Emacs > version the current master is running fine with? Same for XEmacs? yes, proking that knowledge was my intent. Thanks for adjusting the docs. Greg pgpg0UU3zKegE.pgp Description: PGP signature
Re: [O] Feature request: don't store bookmark for some capture templates
Hi XeCycle, XeCycle writes: > I want to disable the behaviour for org-capture to store a > bookmark pointing to the last stored item, preferably for some > templates. You can now (setq org-capture-bookmark nil) to unconditionally prevent the creation of a bookmark. This is not dependant of the capture template (yet) -- patch welcome for this. > No documentation for this, so I looked into the > source --- seems we're storing the bookmark unconditionaly. Fixed, thanks. Best, -- Bastien
Re: [O] [PATCH] Allow datetree to find years with trailing whitespace.
Hi Matt, Matt Lundin writes: > * lisp/org-datetree.el: Fix regexp to allow datetree to find headings > with trailing whitespace. This fixes a bug in which an existing > datetree heading (e.g., "* 2012 ") would not be found by > org-datetree-find-year-create if it had trailing whitespace. This can > cause problems, for instance, if one is using column view on the date > tree, since editing subheadings with column view adds whitespace at > the end of the top heading. Applied in master, thanks! -- Bastien
Re: [O] [PATCH] Add entities for /, +, _, =
Hi Mark, "Mark E. Shoulson" writes: > On 05/25/2012 11:04 AM, Nicolas Goaziou wrote: >> Hello, >> You're right, there could be another entity for ^. asciicirc is good >> enough as a name. Would you want to make a patch for it? >> >> Also, you may want to consider signing FSF papers for more important >> contributions. > > Yes, I'll do both those things, so don't worry about the patch. Might have > to wait until next week though. Thanks for doing this. Note that the process of getting your papers from FSF might take some time. Best, -- Bastien
Re: [O] #+STARTUP: showstars
Hi Mark, "Mark E. Shoulson" writes: > Furthermore, hidestars isn't good enough, because Enda wants the file > *really to be like that*, without the stars there at all, so that it still > looks good when being edited in vi or something. Thanks for taking the time to state Enda's position more clearly. The stars will stay here. Based from this, I guess Vi(m) can be clever enough to hide them. Best, -- Bastien
Re: [O] [New Contrib Feature] Automatic URL shortening via Bitly
Hi Neil, Neil Smithline writes: > Just thought I'd let you know about two projects I've been working on that, > when combined, make Org even cooler than it already is. Thanks for this contribution! I've added a link to this page: http://orgmode.org/worg/org-contrib/ All best, -- Bastien
Re: [O] org-agenda-sticky
Hi Rainer, Rainer Thiel writes: > I use org version 7.8.11 with GNU Emacs 24.1.50.1 under Windows XP. > > I can't seem to find a way to use the new org-agenda-sticky option. This option is not part of the officially released version of Org, yet. It is available through the master branch of the git repo, though. Org 7.9 will be released somewhere in June. HTH, -- Bastien
Re: [O] Agenda view column mode: How to a column showing just today's time?
Hi Brian, Brian Wood writes: > To clarify my question: Sorry no-one had to answer it with a constructive answer yet... > I'd like to replace CLOCKSUM with a column like CLOCK_TODAY which shows > just today's time logged on the subtree. ... but that's because it is not easily feasible yet. I store this request somewhere because I think that would be useful. Ping me in one month if this is not implemented. Thanks, -- Bastien
Re: [O] Bug: org-preview-latex-fragment-region fails [7.8.03] [Xemacs 21.5.31 Mule]
Hi Uwe, Uwe Brauer writes: > A while ago I could make org-preview-latex-fragment work for > Xemacs and I also sent a corresponding patch. I never > bothered to check the corresponding `region' function, but > when I did I received an error. I debugged the function and > when I reached(narrow-to-region beg end) > I obtained an error, whose backtrace I attach. I don't see any backtrace, did you forgot to attached it? In any case, I don't use XEmacs so please send a patch for this if you can. Thanks, -- Bastien
Re: [O] Opening an odt file - problem solved
Hi Jambunathan, Jambunathan K writes: > This fix is back-firing. I have pushed an updated fix. Fixed in Org 7.8.11 and Emacs 24.1 branches. > Note:: nxml-mode is not really needed for ODT export to go through > [1]. I will remove this dependency for the new exporter (org-e-odt.el) > but retain it for the current exporter (org-odt.el) [2]. That's good news, thanks. > [2] I don't want to distrub the stability of org-odt.el in Emacs-24.1 > due to last minute changes. It was about to happen because Emacs RC will be released this week-end and I thought I would not have any internet connection between today noon and tuesday. But that's okay. -- Bastien
Re: [O] Org-mode release 7.8.11
Hi Rainer, Rainer Stengele writes: > I think the version number ist still old? > > Org-mode version 7.8.10 (release_7.8.10-598-g747d71H) The tag was pushed on maint and since you are using the master version and org-version is inferred from the tag, you had this wrong org-version. Fixed, thanks. -- Bastien
Re: [O] "Smart" quotes
On 05/25/2012 01:14 PM, Nicolas Goaziou wrote: Hello, "Mark E. Shoulson" writes: Hm. I like the idea, but it raises some questions for me. It would be particularly good if this could share code/custom variables with the pieces of the (new) exporter that make smart quotes on export. That way we could be sure that what it looks like onscreen would also be what it looked like when exported. I could be interesting, but keep in mind that no matter how "smart" your quotes are, they will fail in some situations. So, it will have to be optional for export, independently on their in-buffer status. The OPTIONS keyword may be used, with q:t and q:nil items. "Smart" quotes absolutely have to be optional, and probably disabled by default. They're going to fail sometimes, so they should only be there when you ask for them. Smart-quotes-for-export and smart-quotes-onscreen need to be settable independently, yes. Smart-quotes-for-export needs to be settable per-file/per-buffer, with OPTIONS or something. Smart-quotes-onscreen doesn't have to be buffer-local, though it might be a good idea. Using q:t or maybe ":t in options seems perfectly good for setting exporting smart quotes. It still would be good if onscreen and export could share code. Looking at contrib/lisp/org-e-latex.el at an upcoming exporter for such things, I see a variable org-e-latex-quotes, which has nice language-aware parts... but misses an important point. Each language gets to define one regexp for opening quotes, one for closing quotes, and one for single quotes. But don't we want to talk about (at least) two levels of quotes, see your own reference[fn:1]? Probably. But that's going to be somewhat harder. Single quotes would be for inner, second-level quotes (if we're using double straight quotes according to (American) English usage, I would guess we'd be using single straight quotes the same way). That works okay for English, where a single apostrophe not part of a grouping construct is going to be interpreted as a "close" single quote and look right for an apostrophe. The regexp may be able to tell level 1 from level 2 quotes. Do you mean that the author would use the same characters for both first and second level quotes, and the regexp would be smart enough to distinguish which level each was at? I don't think that's possible, and you probably don't either. What I meant, and you probably did as well, was that if we use apostrophes for second-level quotes, a regexp can be smart enough to tell the difference between a second-level quote and a non-quote apostrophe It might not work so good in French where apostrophes are also used, There are no spaces around apostrophes, so they shouldn't be caught by the regexp. which is what you say here. They *should* be caught by a regexp, but not the same one; they need to be smartified also, just not necessarily treated the same as second-level quotes. but also single guillemets for inner-level quotes. What are single guillemets? I don't think there is such thing in French. You're right; the Wikipedia page says that French uses quote-marks or the same double-chevrons for inner quotes. I thought it used \lsaquo and \rsaquo, « like ‹ this › ». Looks like it does in Swiss typography for various languages, according to the page. Danish also uses the single-chevrons (pointing the other direction), and Azerbaijani and Basque, etc... Whatever. What I meant was, if people are going to be writing using straight ascii quotes and expect them to be changed into language-appropriate quotes, they're going to want something like "this is a 'quote', and that's all you need to know." becoming, for instance «this is a ‹quote›, and that’s all you need to know.» that is, it should be possible to use the single quotes for inner quotes, which would mean more than just opening/closing/single in the org-e-latex-quotes (and analogous variables in other exporters). Being able to determine when you need ‹› and when ’ might be a little uncertain, but it isn't hard to make a regexp that can make a decent guess at it. Should/can we consider extending this for the new exporters? I think it would be a good addition to the export mechanism, if you want to give it a try. I'd love to get org more export-friendly. I'll see what I can understand of the (new) export code. (I'm looking forward to HTML and ODT exporters that can do smart quotes; the straight quotes are really the main jarring things about using Org as a lightweight markup and exporting into something fancier) A function, provided in org-export, could help changing dumb quotes into smart quotes in plain text. Then, it would be easier for back-ends to provide the feature, if they wanted to. That sounds like a possibility, might make for good generic handling, only one bit of code to treat everything consistently... yeah, I didn't like the idea at first, I'm starting to like it more. I
Re: [O] italicise across lines
Enda writes: > Is there is a way to italicise across lines like > > /italicised > text/ > > rather than > > /italicised/ > /text/ Actually, Org will italicize items like your first example, but only for blocks of text of up to two lines in length. For a longer block you want italicized, you would likely be better off using a #+BEGIN_QUOTE...#+END_QUOTE block and then tweaking your exporter to handle putting QUOTE blocks into italics.
Re: [O] #+STARTUP: showstars
Enda writes: Otherwise is like in vi, the additional stars (like **, opposed to *) are too noisy, and since I do not want to see them whether it is in org-mode or in vi, etc, so I wondered was there a way to have the file like * first level heading =C2=A0* second level heading =C2=A0=C2=A0 * third level heading There seems to be some confusion getting across. As I understand it, this is what the OP is after: Problem: doesn't like the look of multiple *s for headline; prefers the look of hidestars-mode. Furthermore, hidestars isn't good enough, because Enda wants the file *really to be like that*, without the stars there at all, so that it still looks good when being edited in vi or something. It needs to look like hidestars *all the time*, even outside of org, to avoid seeing the s. OP's requested fix: change the syntax so that a line which begins with N spaces followed by a star and then more spaces after that acts as if the N spaces at the beginning were stars. That is, * at the start of the line should be a third-level headline, as if it started with ***. OP, please let me know if I'm stating your position correctly. Problem with requested fix: In addition to being a pretty major change to start with, it also already conflicts with established usage. A line that starts with spaces and then a star-space is considered an item in a plain list. Using *s for plain lists is discouraged, because of the potential confusion with headlines if there are no spaces before it, but it is permitted (and if it could have been dropped it would have been already). So, no, this isn't going to happen. I _guess_ one could try defining something like a NO-BREAK-SPACE character to behave like a star at the beginning of the line when it comes to determining headlines, so you basically have a character that *looks* blank you can use for the non-final stars, but that would also be a pretty enormous change and I don't see it looking like a good move either. I hope that accurately portrays the request (and responses thereto). ~mark
[O] Escaping links while doing an org-publish to html
Hi, I have been using org-mode for a year now and love it. I just started experimenting with org-publish and am trying to use org-mode with octopress as described here http://jaderholm.com/blog/blogging-with-org-mode-and-octopress When I export an org file using org-publish, I want to export/convert everything normally, but want to escape hyperlink conversion so that the octopress plugins can process them. I found that whenever I have text like http://something.somewhere/ it is automatically converted to a hyperlink or an image link (if it ends with an image extension) Is there a way to do prevent org-mode from setting up A-links or IMG-links? I dont' need to be selective. It's ok if all the links in a file are not converted. Thanks, c.b.
Re: [O] [PATCH] Add entities for /, +, _, =
On 05/25/2012 11:04 AM, Nicolas Goaziou wrote: Hello, You're right, there could be another entity for ^. asciicirc is good enough as a name. Would you want to make a patch for it? Also, you may want to consider signing FSF papers for more important contributions. Yes, I'll do both those things, so don't worry about the patch. Might have to wait until next week though. ~mark
Re: [O] #+STARTUP: showstars
Hello Enda, Enda writes: > Otherwise is like in vi, the additional stars (like **, opposed to > *) are too noisy, and since I do not want to see them whether > it is in org-mode or in vi, etc, so I wondered was there a way to have > the file like > > * first level heading > * second level heading > * third level heading are you looking for org-indent-mode.? --8<---cut here---start->8--- (add-hook 'org-mode-hook (lambda () (org-indent-mode 1))) --8<---cut here---end--->8--- -- YYR
Re: [O] makefile regression
Greg Troxel writes: > If GNU make is required it needs to be documented. I've added a comment into Makefile as a stopgap measure. > Separately from that, the makefiles look much more complicated than I > would have thought necessary, and if there aren't good reasons to > require more than POSIX make, it would be nice to stay with POSIX. Last I looked it didn't seem possible to achieve the functionality of the build system without resorting to generated makefiles, which would either imply the use of further external tools or yet another make flavor. In light of the fact that orgmode was already using GNU make extensions, it seemed more prudent to use GNU make extensions to a fuller extent. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] Priorities do not work on lists
I am using Org-mode version 7.8.11 and priorities in items are colored just like I want, however nicholas.do...@hp.com says "That's an artifact of font-lock-mode." Best wishes, Enda From: Nicolas Goaziou To: Enda Cc: "emacs-orgmode@gnu.org" Sent: Friday, May 25, 2012 7:28 PM Subject: Re: Priorities do not work on lists Hello, Enda writes: > Yet, they are colored as such if they are typed in manually. This shouldn't happen anymore with latest commit. Can you confirm it? Thanks for reporting this. Regards, -- Nicolas Goaziou
Re: [O] #+STARTUP: showstars (#+STARTUP: showlaststar)
Enda wrote: > I might want to edit the file where Emacs is not installed, so I do not want > to be exporting to ascii. > Then you have to live with the stars. Nick > Best wishes, > > Enda > > > From: Nick Dokos > > But the suggestion of exporting to ascii (and editing that in vi) has > not been rejected (yet), so that may be a way forward. > > > > Alternatives: > >
Re: [O] Priorities do not work on lists
Enda wrote: > Yet, they are colored as such if they are typed in manually. > That's an artifact of font-lock-mode. Nick > Best wishes, > > Enda > > > From: Nicolas Goaziou > To: Enda > Cc: "emacs-orgmode@gnu.org" > Sent: Friday, May 25, 2012 7:15 PM > Subject: Re: Priorities do not work on lists > > Hello, > > Enda writes: > > > priorities do not work on lists > > - item 1 > > - item 2 > > > > and does not work (yet if you manually insert them by > > typing [#B] they are coloured properly). > > There is no such thing as priorities in lists. > > Regards, > > -- > Nicolas Goaziou > > > > Alternatives: > >
Re: [O] Priorities do not work on lists
Hello, Enda writes: > Yet, they are colored as such if they are typed in manually. This shouldn't happen anymore with latest commit. Can you confirm it? Thanks for reporting this. Regards, -- Nicolas Goaziou
Re: [O] #+STARTUP: showstars (#+STARTUP: showlaststar)
I might want to edit the file where Emacs is not installed, so I do not want to be exporting to ascii. Best wishes, Enda From: Nick Dokos But the suggestion of exporting to ascii (and editing that in vi) has not been rejected (yet), so that may be a way forward.
[O] [PATCH] Let org-agenda-time-grid control if the grid is displayed
Let org-agenda-time-grid control if the grid is displayed * lisp/org-agenda.el (org-agenda-list): ensures that the list returned by org-agenda-add-time-grid-maybe is appended to rtnall before checking if the latter is emtpy. In the case where rtnall is empty (no item for current day), we do not call org-agenda-add-time-grid-maybe. This seems bogus because that function is already computing whether the time grid must be included, and does so according to the user's preferences. In particular, the org-agenda-time-grid variable has a 'require-timed' parameter controlling the visibility of the time grid. So, this patch : - removes the premature check for rtnall being empty, - inconditionally calls org-agenda-add-time-grid-maybe, - and finally checks the emptiness of the resulting list before pretty printing. My previous patch had a bug (no need to append), please do not consider it. I apologize for the noise. TINYCHANGE --- lisp/org-agenda.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index cfd3e25..de555c0 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3886,10 +3886,10 @@ given in `org-agenda-start-on-weekday'." (put-text-property s (1- (point)) 'org-day-cnt day-cnt) (when todayp (put-text-property s (1- (point)) 'org-today t)) + (setq rtnall + (org-agenda-add-time-grid-maybe rtnall ndays todayp)) (if rtnall (insert ;; all entries - (org-finalize-agenda-entries -(org-agenda-add-time-grid-maybe - rtnall ndays todayp)) + (org-finalize-agenda-entries rtnall) "\n")) (put-text-property s (1- (point)) 'day d) (put-text-property s (1- (point)) 'org-day-cnt day-cnt -- 1.7.10.2.484.gcd07cc5 From 5b1b0603ac72f8482c03596a4dadcc6692852503 Mon Sep 17 00:00:00 2001 From: Christophe Junke Date: Fri, 25 May 2012 11:40:47 +0200 Subject: [PATCH] Let org-agenda-time-grid control if the grid is displayed * lisp/org-agenda.el (org-agenda-list): ensures that the list returned by org-agenda-add-time-grid-maybe is appended to rtnall before checking if the latter is emtpy. In the case where rtnall is empty (no item for current day), we do not call org-agenda-add-time-grid-maybe. This seems bogus because that function is already computing whether the time grid must be included, and does so according to the user's preferences. In particular, the org-agenda-time-grid variable has a 'require-timed' parameter controlling the visibility of the time grid. So, this patch : - removes the premature check for rtnall being empty, - inconditionally calls org-agenda-add-time-grid-maybe, - appends the result to rtnall, - and finally checks the emptiness of the resulting list before pretty printing. TINYCHANGE --- lisp/org-agenda.el | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index cfd3e25..eebb66f 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3886,10 +3886,11 @@ given in `org-agenda-start-on-weekday'." (put-text-property s (1- (point)) 'org-day-cnt day-cnt) (when todayp (put-text-property s (1- (point)) 'org-today t)) + (setq rtnall + (append rtnall + (org-agenda-add-time-grid-maybe rtnall ndays todayp))) (if rtnall (insert ;; all entries - (org-finalize-agenda-entries - (org-agenda-add-time-grid-maybe - rtnall ndays todayp)) + (org-finalize-agenda-entries rtnall) "\n")) (put-text-property s (1- (point)) 'day d) (put-text-property s (1- (point)) 'org-day-cnt day-cnt -- 1.7.10.2.484.gcd07cc5
[O] [PATCH] Let org-agenda-time-grid control if the grid is displayed
Let org-agenda-time-grid control if the grid is displayed * lisp/org-agenda.el (org-agenda-list): ensures that the list returned by org-agenda-add-time-grid-maybe is appended to rtnall before checking if rtnall is emtpy. In the case where rtnall is empty (no item for current day), we do not call org-agenda-add-time-grid-maybe. This seems bogus because that function is already computing whether the time grid must be included, and does so according to the user's preferences. In particular, the org-agenda-time-grid variable has a 'require-timed' parameter controlling the visibility of the time grid. So, this patch : - removes the premature check for rtnall being empty, - inconditionally calls org-agenda-add-time-grid-maybe, - appends the result to rtnall, - and finally checks the emptiness of the resulting list before pretty printing. TINYCHANGE --- lisp/org-agenda.el | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index cfd3e25..eebb66f 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3886,10 +3886,11 @@ given in `org-agenda-start-on-weekday'." (put-text-property s (1- (point)) 'org-day-cnt day-cnt) (when todayp (put-text-property s (1- (point)) 'org-today t)) + (setq rtnall + (append rtnall + (org-agenda-add-time-grid-maybe rtnall ndays todayp))) (if rtnall (insert ;; all entries - (org-finalize-agenda-entries -(org-agenda-add-time-grid-maybe - rtnall ndays todayp)) + (org-finalize-agenda-entries rtnall) "\n")) (put-text-property s (1- (point)) 'day d) (put-text-property s (1- (point)) 'org-day-cnt day-cnt -- 1.7.10.2.484.gcd07cc5 From 5b1b0603ac72f8482c03596a4dadcc6692852503 Mon Sep 17 00:00:00 2001 From: Christophe Junke Date: Fri, 25 May 2012 11:40:47 +0200 Subject: [PATCH] Let org-agenda-time-grid control if the grid is displayed * lisp/org-agenda.el (org-agenda-list): ensures that the list returned by org-agenda-add-time-grid-maybe is appended to rtnall before checking if the latter is emtpy. In the case where rtnall is empty (no item for current day), we do not call org-agenda-add-time-grid-maybe. This seems bogus because that function is already computing whether the time grid must be included, and does so according to the user's preferences. In particular, the org-agenda-time-grid variable has a 'require-timed' parameter controlling the visibility of the time grid. So, this patch : - removes the premature check for rtnall being empty, - inconditionally calls org-agenda-add-time-grid-maybe, - appends the result to rtnall, - and finally checks the emptiness of the resulting list before pretty printing. TINYCHANGE --- lisp/org-agenda.el | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index cfd3e25..eebb66f 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3886,10 +3886,11 @@ given in `org-agenda-start-on-weekday'." (put-text-property s (1- (point)) 'org-day-cnt day-cnt) (when todayp (put-text-property s (1- (point)) 'org-today t)) + (setq rtnall + (append rtnall + (org-agenda-add-time-grid-maybe rtnall ndays todayp))) (if rtnall (insert ;; all entries - (org-finalize-agenda-entries - (org-agenda-add-time-grid-maybe - rtnall ndays todayp)) + (org-finalize-agenda-entries rtnall) "\n")) (put-text-property s (1- (point)) 'day d) (put-text-property s (1- (point)) 'org-day-cnt day-cnt -- 1.7.10.2.484.gcd07cc5
Re: [O] Priorities do not work on lists
Yet, they are colored as such if they are typed in manually. Best wishes, Enda From: Nicolas Goaziou To: Enda Cc: "emacs-orgmode@gnu.org" Sent: Friday, May 25, 2012 7:15 PM Subject: Re: Priorities do not work on lists Hello, Enda writes: > priorities do not work on lists > - item 1 > - item 2 > > and does not work (yet if you manually insert them by > typing [#B] they are coloured properly). There is no such thing as priorities in lists. Regards, -- Nicolas Goaziou
Re: [O] Priorities do not work on lists
Hello, Enda writes: > priorities do not work on lists > - item 1 > - item 2 > > and does not work (yet if you manually insert them by > typing [#B] they are coloured properly). There is no such thing as priorities in lists. Regards, -- Nicolas Goaziou
[O] [PATCH] Allow datetree to find years with trailing whitespace.
* lisp/org-datetree.el: Fix regexp to allow datetree to find headings with trailing whitespace. This fixes a bug in which an existing datetree heading (e.g., "* 2012 ") would not be found by org-datetree-find-year-create if it had trailing whitespace. This can cause problems, for instance, if one is using column view on the date tree, since editing subheadings with column view adds whitespace at the end of the top heading. --- lisp/org-datetree.el |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-datetree.el b/lisp/org-datetree.el index 192d1d6..8c04507 100644 --- a/lisp/org-datetree.el +++ b/lisp/org-datetree.el @@ -63,7 +63,7 @@ tree can be found." (goto-char (prog1 (point) (widen)) (defun org-datetree-find-year-create (year) - (let ((re "^\\*+[ \t]+\\([12][0-9][0-9][0-9]\\)$") + (let ((re "^\\*+[ \t]+\\([12][0-9][0-9][0-9]\\)\\s-*$") match) (goto-char (point-min)) (while (and (setq match (re-search-forward re nil t)) -- 1.7.10.2
Re: [O] #+STARTUP: showstars
Yagnesh Raghava Yakkala wrote: > > Hello Enda, > > Enda writes: > > > Otherwise is like in vi, the additional stars (like **, opposed to > > *) are too noisy, and since I do not want to see them whether > > it is in org-mode or in vi, etc, so I wondered was there a way to have > > the file like > > > > * first level heading > > =C2=A0* second level heading > > =C2=A0=C2=A0 * third level heading > > are you looking for org-indent-mode.? > > (add-hook 'org-mode-hook > (lambda () > (org-indent-mode 1))) > I may be putting words into the OP's mouth, but I don't think he is looking for org-indent-mode: the multiple asterisks would be there, whether org-indent-mode is on or off (and it would not affect how the file is seen in vi, to use his example). I think he is looking for something that does not exist. But the suggestion of exporting to ascii (and editing that in vi) has not been rejected (yet), so that may be a way forward. Nick
Re: [O] #+STARTUP: showstars (#+STARTUP: showlaststar)
I just saw that #+STARTUP: showstars is the opposite of #+STARTUP: hidestars, #+STARTUP: showlaststar would have been a more appropriate subject header. org-indent-mode can be activated using #+STARTUP: indent according to http://orgmode.org/manual/Clean-view.html, however in the same page I see that " All headline stars but the last one are made invisible using the org-hide face", however I want there to be no actual stars except the last and then org-mode using the right color for each heading like: * first heading * second heading * third heading Best wishes, Enda From: Yagnesh Raghava Yakkala To: Enda Cc: "nicholas.do...@hp.com" ; "emacs-orgmode@gnu.org" Sent: Friday, May 25, 2012 6:52 PM Subject: Re: #+STARTUP: showstars Hello Enda, Enda writes: > Otherwise is like in vi, the additional stars (like **, opposed to > *) are too noisy, and since I do not want to see them whether > it is in org-mode or in vi, etc, so I wondered was there a way to have > the file like > > * first level heading > * second level heading > * third level heading are you looking for org-indent-mode.? --8<---cut here---start->8--- (add-hook 'org-mode-hook (lambda () (org-indent-mode 1))) --8<---cut here---end--->8--- -- YYR
Re: [O] #+STARTUP option that hides everything not a list heading
Enda wrote: > #+STARTUP: content > hides the items (- item) like so: > > * shown > ** shown... > > opposed to > > * shown > ** shown... > - shown... > Yup - missed that detail: sorry. No way to do what you want. Nick
Re: [O] italicise across lines (stop comments and weblinks from being coloured and names of directories from being italised, /etc/)
Don't read my reply literally. I am urging you to do some navel gazing. That's what the `meta' in in my reply implied.. > Disabling font-lock would not work because then the headings (* > Headings) would not be in color. > > Best wishes, > > Enda > > > From: Jambunathan K > To: Enda > Cc: "emacs-orgmode@gnu.org" > Sent: Friday, May 25, 2012 6:32 PM > Subject: Re: [O] italicise across lines > > > [Not a reply to this thread, but kind of meta] > > What exactly are you trying to do? Please share the underlying > motivation behind the series of questions you have been posting > lately. > > Will disabling font-lock for Orgmode files accomplish what you want? > > If you are new to Orgmode, look at the manual, browse the mailing > list > and then post the questions. > --
Re: [O] "Smart" quotes
> I could be interesting, but keep in mind that no matter how "smart" your > quotes are, they will fail in some situations. So, it will have to be > optional for export, independently on their in-buffer status. > > The OPTIONS keyword may be used, with q:t and q:nil items. I don't see an entry for this in `org-export-options-alist'. So I believe you are soliciting opinion on a fresh addition. >> (I'm looking forward to HTML and ODT exporters that can do smart >> quotes; the straight quotes are really the main jarring things about >> using Org as a lightweight markup and exporting into something >> fancier) > > A function, provided in org-export, could help changing dumb quotes into > smart quotes in plain text. Then, it would be easier for back-ends to > provide the feature, if they wanted to. I can use it, if made available. I think, It will be help if we force all exporters to produce utf-8 files. --
Re: [O] #+STARTUP option that hides everything not a list heading
#+STARTUP: content hides the items (- item) like so: * shown ** shown... opposed to * shown ** shown... - shown... Best wishes, Enda From: Nick Dokos To: Enda Cc: "emacs-orgmode@gnu.org" Sent: Friday, May 25, 2012 6:23 PM Subject: Re: [O] #+STARTUP option that hides everything not a list heading Enda wrote: > Can there be #+STARTUP option that hides everything not a list heading > or a heading on startup like: > > * shown > ** shown > not shown > - shown > not shown > #+STARTUP: content See (info "(org) In-buffer settings") for a complete list. Nick
Re: [O] italicise across lines (stop comments and weblinks from being coloured and names of directories from being italised, /etc/)
Disabling font-lock would not work because then the headings (* Headings) would not be in color. Best wishes, Enda From: Jambunathan K To: Enda Cc: "emacs-orgmode@gnu.org" Sent: Friday, May 25, 2012 6:32 PM Subject: Re: [O] italicise across lines [Not a reply to this thread, but kind of meta] What exactly are you trying to do? Please share the underlying motivation behind the series of questions you have been posting lately. Will disabling font-lock for Orgmode files accomplish what you want? If you are new to Orgmode, look at the manual, browse the mailing list and then post the questions. --
Re: [O] #+STARTUP: showstars
Otherwise is like in vi, the additional stars (like **, opposed to *) are too noisy, and since I do not want to see them whether it is in org-mode or in vi, etc, so I wondered was there a way to have the file like * first level heading * second level heading * third level heading highlighted like in hidestars except there would be no stars to hide. Best wishes, Enda From: Nick Dokos To: Enda Cc: "emacs-orgmode@gnu.org" Sent: Friday, May 25, 2012 6:30 PM Subject: Re: [O] #+STARTUP: showstars Enda wrote: > With #+STARTUP: hidestars, the output looks nice in Emacs org-mode but > not otherwise, can there be an option where a line beginning with a > space and a star is like two stars with the hidestars option and a > line beginning with two spaces and a star is like three stars (it > could be called #+STARTUP: showstars (and even enabled by default)) > What do you mean by "otherwise"? Something like fundamental mode? Or when you cat the file? If the former, all I can suggest is to enable org-mode in the buffer. If the latter, try exporting to ascii. In any case, such an option would require major changes to the code, I believe. It's unlikely to be implemented. Nick PS My opinion only, and bear in mind I'm not a maintainer.
Re: [O] italicise across lines
[Not a reply to this thread, but kind of meta] What exactly are you trying to do? Please share the underlying motivation behind the series of questions you have been posting lately. Will disabling font-lock for Orgmode files accomplish what you want? If you are new to Orgmode, look at the manual, browse the mailing list and then post the questions. --
Re: [O] #+STARTUP: showstars
Enda wrote: > With #+STARTUP: hidestars, the output looks nice in Emacs org-mode but > not otherwise, can there be an option where a line beginning with a > space and a star is like two stars with the hidestars option and a > line beginning with two spaces and a star is like three stars (it > could be called #+STARTUP: showstars (and even enabled by default)) > What do you mean by "otherwise"? Something like fundamental mode? Or when you cat the file? If the former, all I can suggest is to enable org-mode in the buffer. If the latter, try exporting to ascii. In any case, such an option would require major changes to the code, I believe. It's unlikely to be implemented. Nick PS My opinion only, and bear in mind I'm not a maintainer.
Re: [O] links in comments and footnotes
Hello, Samuel Wales writes: > On 5/23/12, Nicolas Goaziou wrote: >> That's normal. If it's commented, the link shouldn't be recognized >> anymore (but I suppose it sill is) > > For some people (not necessarily you) it would be nice to know that > there is a link there. We probably are misunderstanding each other. I am saying that "# [[http://orgmode.org][Org mode]]" should appear as-is and not as "# Orgmode" because nothing in a comment should be interpreted. In other words, there shouldn't be links in comments, nor anything else. So, I think the fix should be to _not_ fontify a "link" in a comment in the first place. I hope my point is clearer now. Regards, -- Nicolas Goaziou
Re: [O] #+STARTUP option that hides everything not a list heading
Enda wrote: > Can there be #+STARTUP option that hides everything not a list heading > or a heading on startup like: > > * shown > ** shown > not shown > - shown > not shown > #+STARTUP: content See (info "(org) In-buffer settings") for a complete list. Nick
Re: [O] "Smart" quotes
Hello, "Mark E. Shoulson" writes: > Hm. I like the idea, but it raises some questions for me. It would > be particularly good if this could share code/custom variables with > the pieces of the (new) exporter that make smart quotes on export. > That way we could be sure that what it looks like onscreen would also > be what it looked like when exported. I could be interesting, but keep in mind that no matter how "smart" your quotes are, they will fail in some situations. So, it will have to be optional for export, independently on their in-buffer status. The OPTIONS keyword may be used, with q:t and q:nil items. > Looking at contrib/lisp/org-e-latex.el at an upcoming exporter for > such things, I see a variable org-e-latex-quotes, which has nice > language-aware parts... but misses an important point. Each language > gets to define one regexp for opening quotes, one for closing quotes, > and one for single quotes. But don't we want to talk about (at least) > two levels of quotes, see your own reference[fn:1]? Probably. But that's going to be somewhat harder. > Single quotes would be for inner, second-level quotes (if we're using > double straight quotes according to (American) English usage, I would > guess we'd be using single straight quotes the same way). That works > okay for English, where a single apostrophe not part of a grouping > construct is going to be interpreted as a "close" single quote and > look right for an apostrophe. The regexp may be able to tell level 1 from level 2 quotes. > It might not work so good in French where apostrophes are also used, There are no spaces around apostrophes, so they shouldn't be caught by the regexp. > but also single guillemets for inner-level quotes. What are single guillemets? I don't think there is such thing in French. > Should/can we consider extending this for the new exporters? I think it would be a good addition to the export mechanism, if you want to give it a try. > (I'm looking forward to HTML and ODT exporters that can do smart > quotes; the straight quotes are really the main jarring things about > using Org as a lightweight markup and exporting into something > fancier) A function, provided in org-export, could help changing dumb quotes into smart quotes in plain text. Then, it would be easier for back-ends to provide the feature, if they wanted to. Regards, -- Nicolas Goaziou
Re: [O] [babel, patch] ob-octave does not catch EOE from matlabShell on MS Windows
> -Original Message-
> From: emacs-orgmode-bounces+mlt=gmx...@gnu.org [mailto:emacs-orgmode-
> bounces+mlt=gmx...@gnu.org] On Behalf Of Mikhail Titov
> Sent: Friday, May 25, 2012 11:31 AM
> To: emacs-orgmode@gnu.org
> Subject: Re: [O] [babel] ob-octave does not catch EOE from matlabShell on MS
> Windows
>
> > > ...
> > >
> > > I have a simple test block like
> > >
> > > #+begin_src matlab :session *MATLAB*
> > > a=2
> > > #+end_src
> > >
> > > When I try to execute it with C-c C-c , emacs never returns unless I hit
> C-
> > g.
> > > If I do M-x toggle-debug-on-quit RET I see that for some reason it keeps
> > > waiting for EOE.
>
> It looks like org-babel-octave-eoe-output and org-babel-octave-eoe-indicator
> were swapped around in org-babel-octave-evaluate-session .
>
> I have the following in dot emacs
>
> (setq org-babel-octave-eoe-output "
> ans =
>
> org_babel_eoe
>
> ")
For the sake of completeness I'm attaching the patch. Also one should override
(setq org-babel-matlab-emacs-link-wrapper-method
"%s
if ischar(ans), fid = fopen('%s', 'w'); fprintf(fid, '%%s\\n', ans);
fclose(fid); else, save -ascii %s ans ; end
delete('%s')
")
as matlabShell does not like commands split across multiple lines.
M.
ob-octave_matlab.patch
Description: Binary data
[O] italicise across lines
Is there is a way to italicise across lines like /italicised text/ rather than /italicised/ /text/ For long pieces of text, italicising the ends of each line is inefficient (maybe there could be a #+BEGIN_ITALICS, #+END_ITALICS, I know of #+BEGIN_VERSE, just without the indentation without affecting verses.) Best wishes, Enda
[O] #+STARTUP: showstars
With #+STARTUP: hidestars, the output looks nice in Emacs org-mode but not otherwise, can there be an option where a line beginning with a space and a star is like two stars with the hidestars option and a line beginning with two spaces and a star is like three stars (it could be called #+STARTUP: showstars (and even enabled by default)) Best wishes, Enda
[O] #+STARTUP option that hides everything not a list heading
Can there be #+STARTUP option that hides everything not a list heading or a heading on startup like: * shown ** shown not shown - shown not shown Best wishes, Enda
[O] Priorities do not work on lists
priorities do not work on lists - item 1 - item 2 and does not work (yet if you manually insert them by typing [#B] they are coloured properly). Best wishes, Enda
Re: [O] stop comments and weblinks from being coloured and names of directories from being italised, /etc/
Original Question: Can there be an #+OPTION to stop comments and weblinks from being coloured and names of directories from being italised, /etc/ In an org file that I use the hold code snippets, org-mode colors these which I do not want, is there a way to create an +OPTION: option that stops this. Also I keep directory names in the org file like /usr/bin/ which in the org file as you know would become italicized. Main Headings are blue (* Heading), but also weblinks are blue, which highlights them and I do not want them to be highlighted. Best wishes, Enda From: Bastien To: nicholas.do...@hp.com Cc: Enda ; "emacs-orgmode@gnu.org" Sent: Tuesday, May 22, 2012 11:40 PM Subject: Re: [O] stop comments and weblinks from being coloured and names of directories from being italised, /etc/ Nick Dokos writes: > BTW, we now have four cents between us. Yes -- one day I'll count how much money has been spent in emails that never got answered back :) -- Bastien
[O] org-mobile-push revert buffer error
Hi All, I'm try to set up MobileOrg on my iPhone. When I called org-mobile-push, I received a Cannot revert nonexistent buffer error. *Messages* BEGIN-- loaded /Users/barak/.emacs.d/starter-kit-eshell.el Loading /Users/barak/.emacs.d/barak.el (source)...done loaded /Users/barak/.emacs.d/barak.el Loading /Users/barak/.emacs.d/starter-kit.el (source)...done loaded /Users/barak/.emacs.d/starter-kit.el Starting Emacs daemon. Importing 1/2... Preparing icalendar...done Current buffer does not contain icalendar contents! Importing 2/2... Preparing icalendar...done Current buffer does not contain icalendar contents! (New file) Diary updated from Google Calendar. When done with this frame, type C-x 5 0 Creating agendas... OVERVIEW Starting new Ispell process [default] ... Loading vc-git...done OVERVIEW [13 times] Preparing diary...done Preparing diary... revert-buffer: Cannot revert nonexistent file /Users/barak/diary -END-- Nothing gets pushed to my ~/Dropbox/MobileOrg directory. Any ideas? Thanks in advance, Bastre
Re: [O] [babel] ob-octave does not catch EOE from matlabShell on MS Windows
> -Original Message-
> From: emacs-orgmode-bounces+mlt=gmx...@gnu.org [mailto:emacs-orgmode-
> bounces+mlt=gmx...@gnu.org] On Behalf Of Mikhail Titov
> Sent: Thursday, May 24, 2012 4:31 PM
> To: emacs-orgmode@gnu.org
> Subject: Re: [O] [babel] ob-octave does not catch EOE from matlabShell on MS
> Windows
>
> > ...
> >
> > I have a simple test block like
> >
> > #+begin_src matlab :session *MATLAB*
> > a=2
> > #+end_src
> >
> > When I try to execute it with C-c C-c , emacs never returns unless I hit C-
> g.
> > If I do M-x toggle-debug-on-quit RET I see that for some reason it keeps
> > waiting for EOE.
It looks like org-babel-octave-eoe-output and org-babel-octave-eoe-indicator
were swapped around in org-babel-octave-evaluate-session .
I have the following in dot emacs
(setq org-babel-octave-eoe-output "
ans =
org_babel_eoe
")
M.
> >
> > ...
> >
> > Here is what I see in *MATLAB* buffer:
> >
> > 8<-*MATLAB*-->8-
> > >> a=2
> > if ischar(ans), fid = fopen('c:/DOCUME~1/user/LOCALS~1/Temp/babel-
> > 7560HUp/matlab-7560PPd', 'w'); fprintf(fid, '%s\n', ans); fclose(fid); else,
> > dlmwrite('c:/DOCUME~1/user/LOCALS~1/Temp/babel-7560HUp/matlab-7560PPd', ans,
> > '\t'); end
> > 'org_babel_eoe'
> >
> > a =
> >
> > 2
> >
> > >> >>
> > ans =
> >
> > org_babel_eoe
> >
> > >>
> > 8<-*MATLAB*-->8-
>
> I feel like it is about
>
> (defvar org-babel-octave-eoe-output "ans = org_babel_eoe")
>
> as Matlab's return has newlines. I'm not sure so far how to make universal
> regex for re-search-forward in org-babel-comint-with-output .
>
> Mikhail
>
>
>
Re: [O] Agenda view column mode: How to a column showing just today's time?
To clarify my question: I'd like to replace CLOCKSUM with a column like CLOCK_TODAY which shows just today's time logged on the subtree. -- Brian Wood Applications Programmer UC Berkeley IST Application Services
[O] Bug: org-preview-latex-fragment-region fails [7.8.03] [Xemacs 21.5.31 Mule]
Hello
A while ago I could make org-preview-latex-fragment work for
Xemacs and I also sent a corresponding patch. I never
bothered to check the corresponding `region' function, but
when I did I received an error. I debugged the function and
when I reached (narrow-to-region beg end)
I obtained an error, whose backtrace I attach.
I thought narrow-to-region works similar in both Emacsen.
Thanks
Uwe Brauer
Emacs : XEmacs 21.5 (beta31) "ginger" [Lucid] (i686-pc-linux, Mule) of Thu
Dec 1 2011 on gilgamesch.quim.ucm.es
Package: Org-mode version 7.8.03
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metaup-hook '(org-babel-load-in-session-maybe)
outline-mode-hook '(hide-body)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-export-preprocess-before-selecting-backend-code-hook
'(org-beamer-select-beamer-code)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-agenda-include-diary t
outline-minor-mode-hook '(my-outline-keys)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#
org-babel-hide-all-hashes my-org-keys
turn-on-flyspell iso-accents-mode
turn-on-auto-capitalize-mode)
org-confirm-elisp-link-function 'yes-or-no-p
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src
org-babel-exp-inline-src-blocks))
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
org-blank-before-new-entry nil
org-export-latex-format-toc-function 'org-export-latex-format-toc-default
org-export-with-LaTeX-fragments 'dvipng
org-export-preprocess-before-normalizing-links-hook
'(org-remove-file-link-modifiers)
org-confirm-shell-link-function 'yes-or-no-p
org-table-default-size "3x3"
org-export-first-hook '(org-beamer-initialize-open-trackers)
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe)
org-export-blocks '((src org-babel-exp-src-block nil) (comment
org-export-blocks-format-comment t)
(ditaa org-export-blocks-format-ditaa
nil) (dot org-export-blocks-format-dot nil))
org-occur-hook '(org-first-headline-recenter)
org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc
org-beamer-auto-fragile-frames
org-beamer-place-default-actions-for-lists)
outline-regexp ";;; \\|("
outline-heading-end-regexp "[\n]"
)
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
apply(debug error (wrong-type-argument integer-or-marker-p nil))
edebug(error (wrong-type-argument integer-or-marker-p nil))
narrow-to-region(nil nil)
(edebug-after (edebug-before 55) 58 (narrow-to-region (edebug-after 0 56 beg)
(edebug-after 0 57 end)))
(let (beg end at msg) (edebug-after (edebug-before 5) 51 (cond ... ... ...))
(edebug-after (edebug-before 52) 54 (message ... "")) (edebug-after
(edebug-before 55) 58 (narrow-to-region ... ...)) (edebug-after (edebug-before
59) 61 (goto-char ...)) (edebug-after (edebug-before 62) 73 (org-format-latex
... ... ... ... ... ... ...)) (edebug-after (edebug-before 74) 76 (message ...
"done. Use `C-c C-c' to remove images.")))
(edebug-after (edebug-before 4) 77 (let (beg end at msg) (edebug-after ... 51
...) (edebug-after ... 54 ...) (edebug-after ... 58 ...) (edebug-after ... 61
...) (edebug-after ... 73 ...) (edebug-after ... 76 ...)))
(save-restriction (edebug-after (edebug-before 4) 77 (let ... ... ... ... ...
... ...)))
(edebug-after (edebug-before 3) 78 (save-restriction (edebug-after ... 77
...)))
(save-excursion (edebug-after (edebug-before 3) 78 (save-restriction ...)))
(edebug-after (edebug-before 2) 79 (save-excursion (edebug-after ... 78 ...)))
(lambda nil (edebug-after (edebug-before 0) 1
(org-remove-latex-fragment-image-overlays)) (edebug-after (edebug-before 2) 79
(save-excursion ...)))()
edebug-enter(org-preview-latex-fragment-region (1 9 nil) (lambda nil
(edebug-after (edebug-before 0) 1 (org-remove-latex-fragment-image-overlays))
(edebug-after (edebug-before 2) 79 (save-excursion ...
edebug-enter(org-preview-latex-fragment-region (1 9 nil) (lambda nil
(edebug-after (edebug-before 0) 1 (org-remove-latex-fragment-image-overlays))
(edebug-after (edebug-before 2) 79 (save-excursion ...
org-preview-latex-fragment-re
Re: [O] [PATCH] Add entities for /, +, _, =
Hello, "Mark E. Shoulson" writes: > I hadn't counted \circ because it expands under Unicode to ˆ (U+02C6) > and not to the true ascii circumflex ^ (U+005E); the point of these > entities is to represent ascii characters that otherwise would confuse > things. Maybe \circ should expand to ^; maybe there should be another > entity for it (maybe neither). You're right, there could be another entity for ^. asciicirc is good enough as a name. Would you want to make a patch for it? Also, you may want to consider signing FSF papers for more important contributions. > Anyway; attaching the relevant patch (changelog tweaked), once again > hoping I got the formatting and everything right. Applied. Thanks again. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Fix for displaying entities ending in a number
Hello, "Mark E. Shoulson" writes: > I was trying to copy the format seen in other patches on the list; > I guess I missed some details. I've set the subject of this thread as > I've seen done with other patches, and I attach only a single patch, > as requested by the website, and created the changelog with C-x > 4 a and everything. I hope I got it right. That's perfect. I have applied your patch. Thank you. Regards, -- Nicolas Goaziou
[O] org-agenda-sticky
I use org version 7.8.11 with GNU Emacs 24.1.50.1 under Windows XP. I can't seem to find a way to use the new org-agenda-sticky option. It seems the variable doesn't exist even after (require 'org-install) nor after an agenda has been displayed with (org-agenda-list 14) Does anyone have an idea on what I may be doing wrong? Many thanks in advance Rainer -- Prof. Dr. Rainer Thiel Wöllnitzer Str. 12 07749 Jena Germany
Re: [O] Opening an odt file - problem solved
Bastien writes: > Jambunathan K writes: > >>> Can you fix it? >> >> OK. Fixed in both maint and master. The exported ODT file will not >> have multiple XML declrations. > > Great, thanks a lot! This fix is back-firing. I have pushed an updated fix. I ignored the following warning Warning: defvar ignored because nxml-auto-insert-xml-declaration-flag is let-bound which leads to the following error while creating a new xml file File mode specification error: (void-variable nxml-auto-insert-xml-declaration-flag) To workaround above issue (i.e., if this fix is not applied for whatever reasons), make sure you do M-x load-library RET nxml-mode RET before starting a ODT export or add a (require 'nxml-mode) to your init file. Note:: nxml-mode is not really needed for ODT export to go through [1]. I will remove this dependency for the new exporter (org-e-odt.el) but retain it for the current exporter (org-odt.el) [2]. Footnotes: [1] nxml-mode is triggered because of the auto-mode activities on XML buffer. The mode chosen by auto-mode would depend upon user configuration and it is not guaranteed to be nxml-mode in all cases. [2] I don't want to distrub the stability of org-odt.el in Emacs-24.1 due to last minute changes.
Re: [O] Code for feature for showing progress in lisp code for creation of Gantt charts
On Fri, May 25, 2012 at 2:49 AM, wrote:
>> I can't seem to get this to compile. I assumed I was to C-c C-c on the
>> elisp source block, which appears to have run, though this is in
>> *Messages* buffer:
>>
>> --
>> executing Emacs-Lisp code block...
>>
>> (table (quote (("" "type" "label" "activity" "depends" "start"
>> "duration" "end" "align" "progress") hline (1 "date" "Start" "" "" 0
>> "" 0 "" "") (2 "task" 1.1 "Lit survey" "" 0 2 2 "right" 75) (3
>> "task" 1.2 "experiments" "" 2 6 8 "" 40) (4 "milestone" "M1" "data
>> collected" 3 8 "" 8 "" "") (5 "task" 1.3 "Report" 3 8 6 14 "" 30) (6
>> "date" "6 weeks" "" "" 14 "" 14 "" "") (7 "milestone" "M2" "Release" 5
>> 14 "" 14 "" "") hline (8 "task" 2.1 "Discuss" 5 14 1 15 "left" 90) (9
>> "task" 2.2 "Correct mistakes" 8 15 1 16 "left" 10) (10 "task" 2.3 "Add
>> feedback" 5 14 2 16 "left" 50) (11 "date" "End" "" "" 16 "" 16 "" "")
>> hline)))
>>
>> Initial: (( type label activity depends start duration end align
>> progress) hline (1 date Start 0 0 ) (2 task 1.1 Lit survey
>> 0 2 2 right 75) (3 task 1.2 experiments 2 6 8 40) (4 milestone M1
>> data collected 3 8 8 ) (5 task 1.3 Report 3 8 6 14 30) (6 date 6
>> weeks 14 14 ) (7 milestone M2 Release 5 14 14 ) hline (8 task
>> 2.1 Discuss 5 14 1 15 left 90) (9 task 2.2 Correct mistakes 8 15 1 16
>> left 10) (10 task 2.3 Add feedback 5 14 2 16 left 50) (11 date End
>> 16 16 ) hline)
>>
>> Entries: ((1 date Start 0 0 ) (2 task 1.1 Lit survey 0 2 2
>> right 75) (3 task 1.2 experiments 2 6 8 40) (4 milestone M1 data
>> collected 3 8 8 ) (5 task 1.3 Report 3 8 6 14 30) (6 date 6 weeks
>> 14 14 ) (7 milestone M2 Release 5 14 14 ) hline (8 task 2.1
>> Discuss 5 14 1 15 left 90) (9 task 2.2 Correct mistakes 8 15 1 16 left
>> 10) (10 task 2.3 Add feedback 5 14 2 16 left 50) (11 date End 16 16
>> ) hline)
>>
>> Ignoring non-list entry hline
>>
>> Ignoring non-list entry hline
>>
>> Code block evaluation complete.
>> --
>>
>> Then I used export to PDF via the normal method =C-d p= but just get a
>> blank PDF with a title, your name, and first section, "Time line."
>>
>> I checked and do have emacs-lisp enabled in my babel section.
>>
>> Suggestions?
>>
>>
>> John
>
>
> Hello John,
>
> Thanks for your answer. The key-combination C-c C-c unfortunately creates the
> new additional block of code surrounded by the lines
> #+RESULTS:
> #+begin_latex
> Here's the created LaTeX code
> #+end_latex
> right after the lisp function.
>
> This code block has to be moved just before the line beginning with
> #+ \\draw...
> to get the order right again.
Yup. That worked. I missed that results block (though I wouldn't have
known where to put it anyway :) )
>
> I tried to include the results of the evaluation of the lisp function there
> by placing
> #+RESULTS: elispgantt
> there (because there's a line saying #+source: elispgantt), but for unknown
> reasons,
> the results of code evaluation are always placed just after the elispgantt
> function.
> Any help to fix that is appreciated.
>
Really like it! There's got to be a way to put code block results
where one wants. Kind like radio tables or something. I'm also sure
one could figure out how to use only start and one of duration/end.
It's definitely nice for just generating a quick and pleasing gantt
chart.
Thanks for sharing!
John
> Hopefully you can now compile my example,
> Julia
[O] Feature request: don't store bookmark for some capture templates
Hello, I want to disable the behaviour for org-capture to store a bookmark pointing to the last stored item, preferably for some templates. No documentation for this, so I looked into the source --- seems we're storing the bookmark unconditionaly. Do tell me if I should upgrade my org mode. org-version "7.8.09" emacs-version "24.1.50.1" Thank you. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591 pgpIf7FubN0kN.pgp Description: PGP signature
Re: [O] Support for a and p suffix for morning/afternoon scheduling
On Fri, 25 May 2012 01:45:14 -0400, Tom wrote: I use the scheduling prompt very often and I usually give times in 8pm/9am/etc. format, because they are conveniently short to type. Today it occured to me the m is unnecessary, because a and p already gives the necessary info. Could we also support 8a and 9p format for times like 8am and 9pm, so that the m does not have to be typed when scheduling? It's unambiguous, this form is not used for other things AFAIK, so we could easily support this shorter form too. Here is a pedantic excursion through the ambiguity of time... 12a and 12p are ambiguous, as are 12am and 12pm. Which is noon, and which is midnight? Standards differ. I generally favor, in English, the unambiguous use of noon and midnight, or 12 noon and 12 midnight. Unfortunately those terms do not fit into a scenario of abbreviation. Furthermore, midnight itself is ambiguous unless rendered as or 2400. Does "midnight Thursday" refer to the start of Thursday, or to its end? See this article: http://en.wikipedia.org/wiki/Midnight One might suggest 12n for noon and 12m for midnight, but this conflicts madly with prior use of abbreviations borrowed from Latin, where 12m is meridies (noon) and 12n is noctis (midnight). 12m, noon, is the origin of the "m" in "am" and "pm" : ante meridiem, post meridiem, for before noon and after noon. We probably have little choice but to adopt the obvious standard, "look at your digital clock," in which (contrary to some published standards) 12:00 AM is midnight and 12:00 PM is noon.
Re: [O] Org-mode release 7.8.11
Am 25.05.2012 09:51, schrieb Bastien: > Hi all, > > I've released Org 7.8.11. > > This is a minor release which mainly fixes an important bug > about matching TODO when building the agenda. > > http://orgmode.org/org-7.8.11.zip > http://orgmode.org/org-7.8.11.tar.gz > http://orgmode.org/org-mode-download.html > > Enjoy, > Hi Bastien, I think the version number ist still old? Org-mode version 7.8.10 (release_7.8.10-598-g747d71H) Cheers, Rainer
[O] Org-mode release 7.8.11
Hi all, I've released Org 7.8.11. This is a minor release which mainly fixes an important bug about matching TODO when building the agenda. http://orgmode.org/org-7.8.11.zip http://orgmode.org/org-7.8.11.tar.gz http://orgmode.org/org-mode-download.html Enjoy, -- Bastien
Re: [O] Code for feature for showing progress in lisp code for creation of Gantt charts
> I can't seem to get this to compile. I assumed I was to C-c C-c on the
> elisp source block, which appears to have run, though this is in
> *Messages* buffer:
>
> --
> executing Emacs-Lisp code block...
>
> (table (quote (("" "type" "label" "activity" "depends" "start"
> "duration" "end" "align" "progress") hline (1 "date" "Start" "" "" 0
> "" 0 "" "") (2 "task" 1.1 "Litsurvey" "" 0 2 2 "right" 75) (3
> "task" 1.2 "experiments" "" 2 6 8 "" 40) (4 "milestone" "M1" "data
> collected" 3 8 "" 8 "" "") (5 "task" 1.3 "Report" 3 8 6 14 "" 30) (6
> "date" "6 weeks" "" "" 14 "" 14 "" "") (7 "milestone" "M2" "Release" 5
> 14 "" 14 "" "") hline (8 "task" 2.1 "Discuss" 5 14 1 15 "left" 90) (9
> "task" 2.2 "Correct mistakes" 8 15 1 16 "left" 10) (10 "task" 2.3 "Add
> feedback" 5 14 2 16 "left" 50) (11 "date" "End" "" "" 16 "" 16 "" "")
> hline)))
>
> Initial: (( type label activity depends start duration end align
> progress) hline (1 date Start 0 0 ) (2 task 1.1 Litsurvey
> 0 2 2 right 75) (3 task 1.2 experiments 2 6 8 40) (4 milestone M1
> data collected 3 8 8 ) (5 task 1.3 Report 3 8 6 14 30) (6 date 6
> weeks 14 14 ) (7 milestone M2 Release 5 14 14 ) hline (8 task
> 2.1 Discuss 5 14 1 15 left 90) (9 task 2.2 Correct mistakes 8 15 1 16
> left 10) (10 task 2.3 Add feedback 5 14 2 16 left 50) (11 date End
> 16 16 ) hline)
>
> Entries: ((1 date Start 0 0 ) (2 task 1.1 Litsurvey 0 2 2
> right 75) (3 task 1.2 experiments 2 6 8 40) (4 milestone M1 data
> collected 3 8 8 ) (5 task 1.3 Report 3 8 6 14 30) (6 date 6 weeks
> 14 14 ) (7 milestone M2 Release 5 14 14 ) hline (8 task 2.1
> Discuss 5 14 1 15 left 90) (9 task 2.2 Correct mistakes 8 15 1 16 left
> 10) (10 task 2.3 Add feedback 5 14 2 16 left 50) (11 date End 16 16
> ) hline)
>
> Ignoring non-list entry hline
>
> Ignoring non-list entry hline
>
> Code block evaluation complete.
> --
>
> Then I used export to PDF via the normal method =C-d p= but just get a
> blank PDF with a title, your name, and first section, "Time line."
>
> I checked and do have emacs-lisp enabled in my babel section.
>
> Suggestions?
>
>
> John
Hello John,
Thanks for your answer. The key-combination C-c C-c unfortunately creates the
new additional block of code surrounded by the lines
#+RESULTS:
#+begin_latex
Here's the created LaTeX code
#+end_latex
right after the lisp function.
This code block has to be moved just before the line beginning with
#+ \\draw...
to get the order right again.
I tried to include the results of the evaluation of the lisp function there by
placing
#+RESULTS: elispgantt
there (because there's a line saying #+source: elispgantt), but for unknown
reasons,
the results of code evaluation are always placed just after the elispgantt
function.
Any help to fix that is appreciated.
Hopefully you can now compile my example,
Julia
