Re: [O] The Answer to Life the Universe and Caching Your Passwords (it's not, 42).
> Suddenly a ray of sunshine illuminated the problem. Thanks, this is nice to know and a good read! I will probably face the same problem at one point or another. -- Thanks, Rasmus
[O] Re: Question about org-beamer overlays
Hi Eric,
Eric S Fraga writes:
> Matt Lundin writes:
>> Any ideas how I might accomplish similar effects in org-beamer (without
>> having too hack up the org file with too much LaTeX code)?
>
> The attached (with three different figures...) will do the job although
> it does use latex for graphics statements unfortunately. It may be
> possible to use the ATTR_LATEX feature to bring in the
> specifications but I don't know how if so. I have to change the column
> widths to fractions of \textwidth as that is the default. Again, it may
> be possible to specify actual sizes but I don't know how. I prefer
> fractions in any case as I don't have to worry about the actual "size"
> then (and so works for posters as well!).
>
Thanks so much for your helpful examples. There is clearly a lot more to
learn about org-beamer!
> Start by having latex snippets where you need them until you figure out
> how to do things natively in org. The nice thing about org is that you
> can have pretty much as much latex as you want and it works just fine.
> I used the babel approach in the attachment but I could have done:
> *** right column :BMCOL:B_ignoreheading:
> :PROPERTIES:
> :BEAMER_col: 0.6
> :BEAMER_env: ignoreheading
> :END:
>
>
> #+begin_src latex
> \includegraphics<1>[height=3in]{mip.png} % first slide only
> \includegraphics<2>[height=3in]{sequence.png} % second slide only
> \includegraphics<3>[height=3in]{test.png} % third slide only
> #+end_src
I discovered one org-mode solution here. I can use
org-beamer-environments-extra to wrap an only macro around an image
link.
--8<---cut here---start->8---
(add-to-list 'org-beamer-environments-extra
'("only" "o" "\\only%a{%h%x" "}"))
--8<---cut here---end--->8---
A sequence of images in the same column can thus be accomplished with
the following:
--8<---cut here---start->8---
*** right column :BMCOL:B_ignoreheading:
:PROPERTIES:
:BEAMER_col: 0.6
:BEAMER_env: ignoreheading
:END:
[[file:image1.png]] :B_only:
:PROPERTIES:
:BEAMER_envargs: <1>
:BEAMER_env: only
:END:
[[file:image2.jpg]]:B_only:
:PROPERTIES:
:BEAMER_envargs: <2>
:BEAMER_env: only
:END:
[[file:image3.png]] :B_only:
:PROPERTIES:
:BEAMER_envargs: <3>
:BEAMER_env: only
:END:
--8<---cut here---end--->8---
Thanks again!
Matt
[O] [org-list] problem with checkbox intermediate state
Previously, when one hit C-c C-c on an item with an intermediate state, the item would be checked as completed. I.e., - [-] Do something ...would become... - [X] Do something After the recent changes to org-list, typing C-c C-c on an item with an intermediate state clears the item: - [ ] Do something One must then hit C-c C-c again to check the item off. Would it be possible to restore the old behavior? A progression from partial completion to full completion seems the most logical sequence. Thanks, Matt
[O] Re: [org-list] problem with checkbox intermediate state
Hello, Matt Lundin writes: > Previously, when one hit C-c C-c on an item with an intermediate state, > the item would be checked as completed. I.e., [...] > Would it be possible to restore the old behavior? A progression from > partial completion to full completion seems the most logical sequence. Agreed, and done. Thanks. Regards, -- Nicolas
[O] [PATCH] Auto-fill shouldn't insert new items
* lisp/org-list.el (org-list-in-valid-context-p): renamed from org-list-in-valid-block-p. (org-at-item-p,org-list-search-generic): use renamed function. * lisp/org.el (org-fill-item-nobreak-p): new function. (org-set-autofill-regexps): modify `fill-nobreak-predicate' to prevent auto-fill from breaking line just before an item regexp. --- lisp/org-list.el |6 +++--- lisp/org.el |9 + 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index 4b50910..bdef14e 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -400,7 +400,7 @@ group 4: description tag") (goto-char (match-end 0))) (looking-at regexp -(defun org-list-in-valid-block-p () +(defun org-list-in-valid-context-p () "Non-nil if point is in a valid block. Invalid blocks are referring to `org-list-forbidden-blocks'." (save-match-data @@ -487,7 +487,7 @@ This checks `org-list-ending-method'." "Is point in a line starting a hand-formatted item?" (save-excursion (beginning-of-line) -(and (looking-at (org-item-re)) (org-list-in-valid-block-p +(and (looking-at (org-item-re)) (org-list-in-valid-context-p (defun org-at-item-bullet-p () "Is point at the bullet of a plain list item?" @@ -1049,7 +1049,7 @@ in `re-search-forward'." nil))) ;; 2. Match in valid context: return point. Else, continue ;;searching. - (when (org-list-in-valid-block-p) (throw 'exit (point))) + (when (org-list-in-valid-context-p) (throw 'exit (point))) (defun org-list-search-backward (regexp &optional bound noerror) "Like `re-search-backward' but stop only where lists are recognized. diff --git a/lisp/org.el b/lisp/org.el index 96ad8ff..4a3efc4 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -19113,6 +19113,11 @@ the functionality can be provided as a fall-back.") ;; and fixed-width regions are not wrapped. That function will pass ;; through to `fill-paragraph' when appropriate. (org-set-local 'fill-paragraph-function 'org-fill-paragraph) + ;; Prevent auto-fill from inserting unwanted new items. + (org-set-local 'fill-nobreak-predicate +(if (memq 'org-fill-item-nobreak-p fill-nobreak-predicate) +fill-nobreak-predicate + (cons 'org-fill-item-nobreak-p fill-nobreak-predicate))) ;; Adaptive filling: To get full control, first make sure that ;; `adaptive-fill-regexp' never matches. Then install our own matcher. (unless (local-variable-p 'adaptive-fill-regexp (current-buffer)) @@ -19128,6 +19133,10 @@ the functionality can be provided as a fall-back.") (regexp . "^#\\+[A-Z_]+:\\(\\s-*\\)\\S-+") (modes . '(org-mode)) +(defun org-fill-item-nobreak-p () + "Non-nil when a line break at point would insert a new item." + (and (looking-at (org-item-re)) (org-list-in-valid-context-p))) + (defun org-fill-paragraph (&optional justify) "Re-align a table, pass through to fill-paragraph if no table." (let ((table-p (org-at-table-p)) -- 1.7.4.1
[O] [BUG] Unmatched #+end-src
Hi --8<---cut here---start->8--- * Unmatched #+end-src bug #+end_src --8<---cut here---end--->8--- With the above simple org file, placing the cursor at the end of #+end_src and hitting return causes emacs to hang. The bug can be replicated with the following simple test which also causes emacs to hang... --8<---cut here---start->8--- (ert-deftest test-headless-end-src () (with-temp-buffer (insert "\n\n\n\n\n\n#+end_") (should-not (org-in-item-p --8<---cut here---end--->8--- It appears to be related to the following in 'org-in-item-p (org-list.el)... --8<---cut here---start->8--- ((looking-at "^[ \t]*#\\+end_") (re-search-backward "^[ \t]*#\\+begin_" nil t)) --8<---cut here---end--->8--- I've tried to pin down the bug but its left me perplexed, so I'm going to defer to more experienced org lispers! Regards Martyn --- Org-mode version 7.5 (release_7.5.32.gdf26.dirty) GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.0) of 2011-02-25
Re: [O] [BUG] Unmatched #+end-src
Hi, On Sat, Mar 12, 2011 at 22:26, Martyn Jago wrote: > --8<---cut here---start->8--- > * Unmatched #+end-src bug > > #+end_src > --8<---cut here---end--->8--- > > With the above simple org file, placing the cursor at the end of > #+end_src and hitting return causes emacs to hang. > > The bug can be replicated with the following simple test which also > causes emacs to hang... > > [snip] > > It appears to be related to the following in 'org-in-item-p > (org-list.el)... > > --8<---cut here---start->8--- > ((looking-at "^[ \t]*#\\+end_") > (re-search-backward "^[ \t]*#\\+begin_" nil t)) > --8<---cut here---end--->8--- > > I've tried to pin down the bug but its left me perplexed, so I'm going > to defer to more experienced org lispers! The =cond= is part of a =while= loop; it just keeps looping, entering that branch and doing nothing (rather than moving point and picking up again from there). Going by the other branches, I think the correct thing to do is just exit the loop: --8<---cut here---start->8--- diff --git a/lisp/org-list.el b/lisp/org-list.el --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -450,17 +450,19 @@ This checks `org-list-ending-method'." ;; At upper bound of search or looking at the end of a ;; previous list: search is over. ((<= (point) lim-up) (throw 'exit nil)) ((and (not (eq org-list-ending-method 'indent)) (looking-at org-list-end-re)) (throw 'exit nil)) ;; Skip blocks, drawers, inline-tasks, blank lines ((looking-at "^[ \t]*#\\+end_") - (re-search-backward "^[ \t]*#\\+begin_" nil t)) + (condition-case nil + (re-search-backward "^[ \t]*#\\+begin_" nil) + (search-failed (throw 'exit nil ((looking-at "^[ \t]*:END:") (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at "^[ \t]*$") (forward-line -1)) ;; Text at column 0 cannot belong to a list: stop. --8<---cut here---end--->8--- Hope this helps, Aankhen
[O] Automatically clocking into parent items
Hi,
I’ve been working on getting org-mode to automatically clock into an
item’s ancestor when clocking out of that item. The way I have it set
up now, it walks up the tree looking for an item that has a particular
property set. If that property is non-nil, it clocks in; if it’s nil,
it doesn’t. Either way, it stops looking at that point. Here’s what
I have so far:
,[ Conditionally resuming parent clocks ]
| (defconst +aankh/org-resume-parent-clock-property+ "AUTO_RESUME_CLOCK"
| "The name of the property that indicates whether a task's clock
| should be restarted upon clocking out of its subtasks. When
| this is not `nil' according to `org-not-nil', the task's clock
| will be restarted.")
|
| (defun aankh/maybe-resume-parent-clock ()
| (save-excursion
| (loop
| until (= (org-current-level) 1)
| do (org-up-heading-all 1)
| when (member +aankh/org-resume-parent-clock-property+
| (mapcar 'car (org-entry-properties)))
| do (let ((resume
|(org-entry-get
| nil
| +aankh/org-resume-parent-clock-property+)))
| (when (org-not-nil resume)
| (org-clock-in))
| (return resume)
|
| (setq aankh/org-resume-parent-clock-enable t)
|
| (defun aankh/read-resume-parent-clock-property (&rest rest)
| (declare (ignore rest))
| (org-icompleting-read
|"Automatically restart this task's clock when clocking out of a subtask? "
|'("t" "nil")))
|
| (when aankh/org-resume-parent-clock-enable
| (add-hook 'org-clock-out-hook 'aankh/maybe-resume-parent-clock)
| (add-to-list 'org-default-properties
|+aankh/org-resume-parent-clock-property+)
| (add-to-list 'org-property-set-functions-alist
|`(,+aankh/org-resume-parent-clock-property+
| . aankh/read-resume-parent-clock-property)))
`
So given this structure:
,[ example.org ]
| * Foo
|
| * Bar
| :PROPERTIES:
| :AUTO_RESUME_CLOCK: t
| :END:
|
| *** Quux
| :PROPERTIES:
| :AUTO_RESUME_CLOCK: t
| :END:
|
| * Frob
|
| * Baz
`
When I clock out of ‘Frob’, I’m automatically clocked into ‘Quux’, and
when I clock out of ‘Quux’, I’m automatically clocked into ‘Bar’.
This works pretty well, except for one problem: it happens *every
time* I clock out, meaning that if I’m clocked into ‘Quux’ and I then
hit C-c C-x C-i on ‘Frob’, I end up being clocked into both ‘Bar’ and
‘Frob’, because I’m automatically clocked out of ‘Quux’; my code is
run, clocking me into ‘Bar’; and then the normal clocking mechanism
clocks me into ‘Frob’ (at least, I *think* the hook runs first).
I guess what I’m wondering is, what’s a good way to avoid this
double-clocking? And while I’m asking for help, can anyone think of
some less obnoxious names for the functions, variables and property?
:-)
I hope all this makes sense. Thanks for your time.
Aankhen
[O] Re: [BUG] Unmatched #+end-src
Hello, Aankhen writes: >> --8<---cut here---start->8--- >> * Unmatched #+end-src bug >> >> #+end_src >> --8<---cut here---end--->8--- >> >> With the above simple org file, placing the cursor at the end of >> #+end_src and hitting return causes emacs to hang. >> > The =cond= is part of a =while= loop; it just keeps looping, entering > that branch and doing nothing (rather than moving point and picking up > again from there). Going by the other branches, I think the correct > thing to do is just exit the loop: I don't think exiting the loop that way is the right thing to do, as it always return nil, even though the #+end_ might be in the list. Moreover, there are other parts of the file that should also be fixed. I think there are 3 options here: 1. Effectively stop everything, but at least throw an informative error. 2. Consider the #+end_ as normal text after all, and resume the loop. 3. Consider #+end_ as normal text and message the user about his syntax problem. I'm not sure yet what's the best way to go, but I think option 2 is sufficient. Regards, -- Nicolas
[O] Re: [BUG] Unmatched #+end-src
Hi, On Sun, Mar 13, 2011 at 01:37, Nicolas wrote: > Aankhen writes: > >>> --8<---cut here---start->8--- >>> * Unmatched #+end-src bug >>> >>> #+end_src >>> --8<---cut here---end--->8--- >>> >>> With the above simple org file, placing the cursor at the end of >>> #+end_src and hitting return causes emacs to hang. >>> >> The =cond= is part of a =while= loop; it just keeps looping, entering >> that branch and doing nothing (rather than moving point and picking up >> again from there). Going by the other branches, I think the correct >> thing to do is just exit the loop: > > I don't think exiting the loop that way is the right thing to do, as it > always return nil, even though the #+end_ might be in the list. > > [snip] You’re right, I lost the context. My apologies for the ill-conceived patch. Aankhen
[O] highlighting overdue tasks in block agendas
Hi all, I've looked everywhere I can think of, but I can't find any info on if/how it's possible to automatically have overdue tasks highlighted or somehow set off from other tasks, in a todo style block agenda. I know about doing that in daily/weekly style agendas, but I was hoping to be able to do it in todo agenda views too. Cheers. Fil -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: salus...@ryerson.ca http://deseng.ryerson.ca/~fil/
Re: [O] [BUG] Unmatched #+end-src
Aankhen writes: Thanks for the heads-up Aankhen, I had indeed missed the enclosing infinite loop. I modified your patch slightly since my test still failed, and made further tests. >From b55d846b57fc2ebf3c282cb1fbb27becfdd7d4fd Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Sat, 12 Mar 2011 20:38:14 + Subject: [PATCH] Fix endless loop in 'org-in-item-p where #+end_ block has no matching beginning block --- lisp/org-list.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index 4b50910..7d8692b 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -465,8 +465,9 @@ This checks `org-list-ending-method'." (looking-at org-list-end-re)) (throw 'exit nil)) ;; Skip blocks, drawers, inline-tasks, blank lines - ((looking-at "^[ \t]*#\\+end_") - (re-search-backward "^[ \t]*#\\+begin_" nil t)) + ((and (looking-at "^[ \t]*#\\+end_") + (not (re-search-backward "^[ \t]*#\\+begin_" nil t))) + (throw 'exit nil)) ((looking-at "^[ \t]*:END:") (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) -- 1.7.4.1 Regards Martyn > Hi, > > On Sat, Mar 12, 2011 at 22:26, Martyn Jago wrote: >> --8<---cut here---start->8--- >> * Unmatched #+end-src bug >> >> #+end_src >> --8<---cut here---end--->8--- >> >> With the above simple org file, placing the cursor at the end of >> #+end_src and hitting return causes emacs to hang. >> >> The bug can be replicated with the following simple test which also >> causes emacs to hang... >> >> [snip] >> >> It appears to be related to the following in 'org-in-item-p >> (org-list.el)... >> >> --8<---cut here---start->8--- >> ((looking-at "^[ \t]*#\\+end_") >> (re-search-backward "^[ \t]*#\\+begin_" nil t)) >> --8<---cut here---end--->8--- >> >> I've tried to pin down the bug but its left me perplexed, so I'm going >> to defer to more experienced org lispers! > > The =cond= is part of a =while= loop; it just keeps looping, entering > that branch and doing nothing (rather than moving point and picking up > again from there). Going by the other branches, I think the correct > thing to do is just exit the loop: > > diff --git a/lisp/org-list.el b/lisp/org-list.el > --- a/lisp/org-list.el > +++ b/lisp/org-list.el > @@ -450,17 +450,19 @@ This checks `org-list-ending-method'." >;; At upper bound of search or looking at the end of a >;; previous list: search is over. >((<= (point) lim-up) (throw 'exit nil)) >((and (not (eq org-list-ending-method 'indent)) > (looking-at org-list-end-re)) > (throw 'exit nil)) >;; Skip blocks, drawers, inline-tasks, blank lines >((looking-at "^[ \t]*#\\+end_") > - (re-search-backward "^[ \t]*#\\+begin_" nil t)) > + (condition-case nil > + (re-search-backward "^[ \t]*#\\+begin_" nil) > + (search-failed (throw 'exit nil >((looking-at "^[ \t]*:END:") > (re-search-backward org-drawer-regexp nil t) > (beginning-of-line)) >((and inlinetask-re (looking-at inlinetask-re)) > (org-inlinetask-goto-beginning) > (forward-line -1)) >((looking-at "^[ \t]*$") (forward-line -1)) >;; Text at column 0 cannot belong to a list: stop. > > Hope this helps, > Aankhen
[O] Something like 'org-clock-in-at-time'?
Hi, Could someone fill me in on your process for clocking in things after the fact? I've been trying to get into to clocking, but, especially at home, I don't return to my computer in between every different thing. Instead, I stop at it when I get a pause and try to fill in what I've been doing. So far, this has been something akin to: - create a new sub-headline and call it what I was doing - C-c C-c to tag it - C-c C-x C-i followed by C-c C-x C-o to create a clocked time stamps - Manually edit the times - C-c C-c to update the count This gets quite tedious when adding several things. I have to expand the logbook, and then fiddle with the times. Could there be (or is there already) a function that might act like the date selection screen for clocking? I looked at the completion list for org-clock-* commands and none of them looked promising. I could envision something like: - M-x org-clock-in-at-time - Minibuffer presents date selection, you select date just like for timestamps - Minibuffer requests time in form HH:MM and you can type it in Same type of function for clocking out. This would *vastly* simplify how I end up clocking. I'm absolutely open to suggestions from others on how you deal with this. Perhaps this is an opportunity to learn about how the *experts* access some functionality I'm currently unaware of! Thanks, John
Re: [O] Re: [BUG] Unmatched #+end-src
Nicolas writes: Hi > Hello, > > Aankhen writes: > >>> --8<---cut here---start->8--- >>> * Unmatched #+end-src bug >>> >>> #+end_src >>> --8<---cut here---end--->8--- >>> >>> With the above simple org file, placing the cursor at the end of >>> #+end_src and hitting return causes emacs to hang. >>> >> The =cond= is part of a =while= loop; it just keeps looping, entering >> that branch and doing nothing (rather than moving point and picking up >> again from there). Going by the other branches, I think the correct >> thing to do is just exit the loop: > > I don't think exiting the loop that way is the right thing to do, as it > always return nil, even though the #+end_ might be in the list. > Moreover, there are other parts of the file that should also be fixed. I've supplied a patch which passes all of my tests, but I will look at providing additional tests looking at other cases within this loop since I'm currently in the habit of writing tests anyway. > > I think there are 3 options here: > > 1. Effectively stop everything, but at least throw an informative error. > 2. Consider the #+end_ as normal text after all, and resume the loop. > 3. Consider #+end_ as normal text and message the user about his syntax >problem. > > I'm not sure yet what's the best way to go, but I think option 2 is > sufficient. > > > Regards, Regards Martyn
[O] RE: Alinea filling (hanlding of explicit line-breaks)
Karl: I put you in the loop for info, because in Texinfo mode I think that @* is used as an alinea separator similar to \\ in Org mode. > From: monn...@iro.umontreal.ca > To: vincent@hotmail.fr > Date: Wed, 16 Feb 2011 10:02:37 -0500 > CC: emacs-orgmode@gnu.org; emacs-de...@gnu.org > Subject: Re: Alinea filling (hanlding of explicit line-breaks) > > >> An important question here is: is it important for M-} to ignore those \\? > > I guess so, this is the current default Org behaviour anyhow. > > Good. > > > as far as I understand, it would be anyhow possible to move point on > > an alinea-by-alinea basis just by configuring the tailing \\ as > > anohter paragraph separator. > > Actually, no, because paragraph-separate would cause the whole line > that ends with \\ to be treated as not being part of a paragraph, and > paragraph-start wouldn't be appropriate either. Hence the "good" > above :-( > > >> Of course fill-paragraph-function sucks because it only applies to > >> fill-paragraph and not to fill-region. > > > Do you mean that `fill-paragraph-function' is some kind of obsolete > > feature and that people should use another kind of hook, and if so > > which one? > > Yes and no: there is no replacement for it. There is > fill-forward-paragraph-function, which can handle some of the cases > for which fill-paragraph-function has been used, but there would need > to be something like a fill-region-as-paragraph-function and we don't > have that yet :-( > > > Stefan > Hello Stefan & al, I have implemented the thing locally on my machine. It works well but there is still something missing: the line containing the `\\' alinea separtor is not filled. Here is what I did: + In org-set-autofill-regexps function I added (org-set-local 'fill-forward-paragraph-function 'org-fill-foward-paragraph) + I created the following function: (defun org-fill-foward-paragraph (&optional arg) (let ((paragraph-separate (concat ".*$\\|" paragraph-separate ))) (forward-paragraph arg))) Note that I my 7.01h version of org --- which is older than the latest one --- org-fill-paragraph is roughly like this: (defun org-fill-paragraph (&optional justify) "Re-align a table, pass through to fill-paragraph if no table." (let ((table-p (org-at-table-p)) (table.el-p (org-at-table.el-p))) (cond ((and (equal (char-after (point-at-bol)) ?*) (save-excursion (goto-char (point-at-bol)) (looking-at outline-regexp))) t); skip headlines (table.el-p t) ; skip table.el tables (table-p (org-table-align) t) ; align org-mode tables (t nil); let fill.el do the job ))) That is to say there is a case where org lets fill.el do the job, while in a later version (e.g. 7.4) org does some "$" detection on its own without the use of the fill-forward-paragraph-function. So, after more thinking about it the problem is the following: the fill-forward-paragraph has only one parameter which is the paragraph number --- with n = 0 => current --- but for finding the paragraph boundary we need *two* parameter => 1st argument: paragraph number => 2nd argument: whether we want to point at the beginning the paragraph or to the end of the paragraph. => maybe paragraph-separate could be a list of 3 items (REGEXP BEG END) where REGEXP is the usual regexp matching the separator, and BEG and END when non nil are function to go the the beginning of next or to the end of previous assuming that the match data corresponds to a match of REGEXP. This way would be really the most flexible. VBR, Vincent
Re: [O] dates before 1970
> So I am not sure what 64 bit systems do now or in the future, but > it seems that we need to live with a restriction for now. > Maybe this should be documented somewhere. > > - Carsten Most 64-bit systems use a 64-bit int. All of the 64-bit Linux systems that I've used use a signed 64-bit int. Some systems use a 64-bit unsigned int. Some use a double. The only way to know for sure is to look at their definition of time_t in time.h, as provided by the system. http://en.wikipedia.org/wiki/Time_t is as good a starting point as any. The precise words from the Open Group Base standard are: time_t and clock_t shall be integer or real-floating types. The usage of time_t in various functions is specified, but range and type is not defined. R Horn
[O] Re: [BUG] Unmatched #+end-src
Hello, Martyn Jago writes: > I've supplied a patch which passes all of my tests, but I will look at > providing additional tests looking at other cases within this loop since > I'm currently in the habit of writing tests anyway. Your patch has the same weakness as the previous one and I explained why. For example, in the following example, calling (org-in-item-p) with point anywhere on line "some text" will return nil, which is obviously wrong. - item 1 #+end_ some text - item 2 Actually, it is not a matter of patch, which is just changing #+begin_src emacs-lisp ((looking-at "^[ \t]*#\\+end_") (re-search-backward "^[ \t]*#\\+begin_" nil t)) #+end_src into #+begin_src emacs-lisp ((and (looking-at "^[ \t]*#\\+end_") (re-search-backward "^[ \t]*#\\+begin_" nil t))) #+end_src once for blocks and once for drawers, in both org-in-item-p and org-list-struct. The real problem is: how should Org react when parsing syntactically erroneous buffers? I concede that freezing Emacs isn't nice, but otoh, code can't deal with every possible user error. So, what is the expected behavior here? Consider orphan #+end_ as normal text, throw an error, or both? An answer to this question would be more useful than code, honestly. I hope I am clearer now. Regards, -- Nicolas
[O] Re: Alinea filling (hanlding of explicit line-breaks)
>> Actually, no, because paragraph-separate would cause the whole line >> that ends with \\ to be treated as not being part of a paragraph, and >> paragraph-start wouldn't be appropriate either. Hence the "good" >> above :-( [...] > I have implemented the thing locally on my machine. It works well but > there is still something missing: the line containing the `\\' alinea > separtor is not filled. As you can see above, I'm not surprised. Just don't use paragraph-separate. What I'd do is to use a fill-forward-paragraph-function which calls forward-paragraph, then searches for a "$" between the start and end point, and if found adjust the end result accordingly. If/when you come up with this function, please submit for inclusion in tex-mode.el where it will come in handy as well. > So, after more thinking about it the problem is the following: the > fill-forward-paragraph has only one parameter which is the paragraph > number --- with n = 0 => current --- but for finding the paragraph > boundary we need *two* parameter > => 1st argument: paragraph number > => 2nd argument: whether we want to point at the beginning the > paragraph or to the end of the paragraph. AFAIK the sign of the argument gives you this information. > => maybe paragraph-separate could be a list of 3 items (REGEXP BEG END) >where REGEXP is the usual regexp matching the separator, and BEG and >END when non nil are function to go the the beginning of next or to >the end of previous assuming that the match data corresponds to a >match of REGEXP. This way would be really the most flexible. Could be, but once you're in fill-forward-paragraph-function, you can do it by hand with Elisp code, so it's not that important. If/when we have enough fill-forward-paragraph-functions we may revisit this opinion, but I don't think we have enough experience yet to make a good design. Stefan
[O] Org file switches to lower case
Hi Orgers, One (out of five) of my org agenda files has spontaneously shifted to lower case. Can anyone give me a clue what might have happened? Thanks, Alan -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206
[O] Re: Org file switches to lower case
On Sun, 13 Mar 2011 17:07:14 +1100 Alan L Tyree wrote: > Hi Orgers, > > One (out of five) of my org agenda files has spontaneously shifted to > lower case. Can anyone give me a clue what might have happened? Pilot error is what happened. I accidentally hig C-x C-l when I was trying to make a link. Not an org mode issue at all, so sorry for the noise. Cheers, Alan > > Thanks, > Alan > > -- > Alan L Tyreehttp://www2.austlii.edu.au/~alan > Tel: 04 2748 6206 > -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206
Re: [O] dates before 1970
Hi everyone, On 11.3.2011, at 09:31, Bastien wrote: > Hi, > > Nick Dokos writes: > >> So I'd guess raising an exception might be the simplest way to deal with >> this. Here's a patch to try out: > > This patch has side-effects that Carsten have been recently exploring a > bit. Those side-effects seem to depend on how Emacs has been compiled. > > For now it's best to stick to this restriction. I am attaching a patch which tries to implement some kind of a solution for this problem. The patch introduces a new variable which will allow you to use dates outside the safe range 1970-2037 once you have convinced yourself that all Emacs implementation you are likely to use now and in the future will support the extended range. To be clear, I do not recommend to make use of this, the danger that you will find yourself on a system where this issue is not resolved is not negligible. That is also why I would recommend the default `t' for this variable, and why I will continue to use diary-sexp dates for the few dates where I need a greater range. The patch also introduces a warning with a beep when Org has forced the year, which, I think, was really the main concern in this thread. Here is the docstring of the new variable - it explains what is going on. (defcustom org-read-date-force-compatible-dates t "Should date/time prompt force dates that are guaranteed to work in Emacs? Depending on the system Emacs is running on, certain dates cannot be represented with the type used internally to represent time. Dates between 1970-1-1 and 2038-1-1 can always be represented correctly. Some systems allow for earlier dates, some for later, some for both. One way to find out it to insert any date into an Org buffer, putting the cursor on the year and hitting S-up and S-down to test the range. When this variable is set to t, the date/time prompt will not let you specify dates outside the 1970-2037 range, so it is certain that these dates will work in whatever version of Emacs you are running, and also that you can move a file from one Emacs implementation to another. WHenever Org is forcing the year for you, it will display a message and beep. When this variable is nil, Org will check if the date is representable in the specific Emacs implementation you are using. If not, it will force a year, usually the current year, and beep to remind you. Currently this setting is not recommended because the likelihood that you will open your Org files in an Emacs that has limited date range is not negligible. A workaround for this problem is to use diary sexp dates for time stamps outside of this range." :group 'org-time :type 'boolean) 0001-Improve-handling-of-years-with-limitations-on-repres.patch Description: Binary data
