Re: [O] another example of org being slow, with some analysis
Eric S Fraga writes: > On Friday, 19 Jun 2015 at 10:28, Daniel Bausch wrote: > > [...] > >> If anyone could give me a hint how to reliably set the preferred (or >> internal) encoding I could check wether it might have something to do >> with the system locale. > > I have (only) the following encoding related settings in my > initialisation, some of which are very historical and may or may not be > needed... > > #+begin_src emacs-lisp > (prefer-coding-system 'utf-8) > (set-charset-priority 'unicode) > (setq default-process-coding-system '(utf-8-unix . utf-8-unix)) > #+end_src > > I think the first one is the most important. Thank you for the code, but unfortunately it does not help. The first line I already had and adding the other two did not help either. Executing M-x prefer-coding-system interactively works and that is what I am doing each day. Maybe I will look again how to set the expected LC_... environment variables for emacs daemon. Regards, Daniel -- MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universität Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch
Re: [O] another example of org being slow, with some analysis
Eric S Fraga writes: > On Friday, 19 Jun 2015 at 08:19, Daniel Bausch wrote: > > [...] > >> Line 6000 is indeed quite "lame". I have similar problems like Eric. A >> table recalculation at line 43868 takes about a minute at my quite fast >> machine. I also tracked that down to org-current-line. One interesting >> detail is that this depends on the buffer encoding. With ASCII the >> recalculation takes less than a second, with utf-8 about a minute. > > Adding some data: my table is at line 8438 in the buffer but character > position 398345 (I have very long lines as I use visual-line-mode in org > exclusively with org-indent). I do use utf-8 encoding. > > I have just tried updating the table on a different laptop (i7-2760, 8 > cores, 8 GB RAM, Ubuntu) and it was very fast. > > The two laptops are running different versions of emacs (tracking latest > emacs developments on Ubuntu and Debian testing lead to different > versions unfortunately) so my gut feeling is that there is an emacs > issue here and possibly one related to utf-8 as Daniel suggests. Maybe it is related (and maybe not - just some thoughts): Since some months I keep having a problem with my preferred encoding. Gentoo changed some things how the LC_... variables are set during boot. Now emacs daemon starts with "no encoding". I tried to fix that by inserting (prefer-coding-system 'utf-8) into mit ~/.emacs file, but that does not help. I still need to manually execute prefer-coding-system by hand and revert my org-file (which is automatically opened during login) with C-x RET r utf-8 every day. But if I remember correctly, I started observing the slowness of the table recalculation long before that change in Gentoo. Maybe it got worse since then but that might also be just because the file grew further. If anyone could give me a hint how to reliably set the preferred (or internal) encoding I could check wether it might have something to do with the system locale. (I can imagine that in some constellations there could be some otherwise unnecessary conversion happening. E.g. maybe utf-8 support is faster if the system locale is also utf-8.) Is there anything like an internal encoding in emacs at all? As far as I know I can type any character in any buffer regardless of the buffer encoding. I just cannot save the buffer if the encoding does not support a character. How is then a utf-8 *buffer* different from a buffer with no encoding (until being saved). Does goto-char work on bytes or really on characters? How does it maybe deal different with characters made up of multiple bytes in the on-disk encoding of the buffer? Regards, Daniel -- MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universität Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch
Re: [O] another example of org being slow, with some analysis
Daniel Bausch writes: > I think it actually is not an org-mode problem but depends on how > (count-lines 1 (point)) works, as it is using regex searches for the > line endings. I can imagine that the regex parser for utf-8 can be > inefficient. I just looked again at Eric's profile output. Why does count-lines not show up there at all? Could it be goto-char, bolp, or even save-excursion instead? I suspected count-lines because it is really doing heavy lifting. Regards, Daniel -- MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universität Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch
Re: [O] another example of org being slow, with some analysis
Hi! Nick Dokos writes: > Eric S Fraga writes: > > >> The output of the ELP profiler is here: >> >> ... >> org-goto-line 104 10.761145733 0.1034725551 >> .. >> org-current-line66 6.8422078910 0.1036698165 >> ... > > I find these two difficult to explain: they account for the vast > majority of the time, they don't call anything other than basic emacs > lisp functions (which should be very fast) and they take an unbelievably > long 0.1 s/call - I did a profile of a single call of each in a file > where wc reports these stats: > > 12961 270362 4317977 /home/nick/lib/notes/notes.org > > and I got 0.002s for the first (going to line 6000, about the middle of > the file) and 0.0004s for the second: a factor of 50 smaller for the > first and a factor of 250 smaller for the second. > > Maybe it's an artifact of profiling, but maybe you can try instrumenting > these two functions and doing something similar. Do you still get 0.1s > for each call? Line 6000 is indeed quite "lame". I have similar problems like Eric. A table recalculation at line 43868 takes about a minute at my quite fast machine. I also tracked that down to org-current-line. One interesting detail is that this depends on the buffer encoding. With ASCII the recalculation takes less than a second, with utf-8 about a minute. I think it actually is not an org-mode problem but depends on how (count-lines 1 (point)) works, as it is using regex searches for the line endings. I can imagine that the regex parser for utf-8 can be inefficient. Regards, Daniel -- MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universität Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch
Re: [O] Problem with links whose description looks like a link
Nicolas Goaziou writes: > Daniel Bausch writes: > >> Hmm, ok, I understand the intention regarding the detection and display >> of inline images as part of a link description; however, even for inline >> images following the link jumps to the target of the outer link and not >> the image itself -- as long as inline images are toggled on. Without >> showing inline images following the link opens the image regardless of >> the original link target. > > You're right. The current behaviour doesn't make sense. This is fixed in > master. Thanks for suggesting it. I confirm that my code bookmarks now work as intended. Thank you very much! Regards, Daniel -- MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universität Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch
Re: [O] Problem with links whose description looks like a link
Hello and thanks for the answer! Nicolas Goaziou writes: > Daniel Bausch writes: > >> I'm using Org from Git master. If I have a link like, e.g. >> >> [[file:somefile.c::int whatsoever][file:somefile.c::int whatsoever]] >> >> and a a file somefile.c with the lines >> >> int some; >> int whatsoever; >> >> then opening the link with the cursor before the space jumps to the >> first line, while opening the link on the word "whatsoever" jumps to the >> second line. It seems like Org detects a link within the link as if the >> brackets were missing. > > This is correct. > > Org allows plain links (e.g. file:foo.org) within bracket links. This is > the sole way to have, for example, an inline image as a link. Hmm, ok, I understand the intention regarding the detection and display of inline images as part of a link description; however, even for inline images following the link jumps to the target of the outer link and not the image itself -- as long as inline images are toggled on. Without showing inline images following the link opens the image regardless of the original link target. I think that the effective target of a link should never be affected by its description. Even fontification and mouse hovering info thinks that the link still targets at its target, i.e. when hovering over the link the whole link gets highlighted and not just the inner one and the tooltip shows the whole target of the outer link, while clicking jumps to the link contained within the description. If there is a real application/need for nested links (besides inline images used as part of link description) I would rather expect them to be written explicitly by typing another pair of brackets nested within the description; however, this syntax is currently not parsed as such. Regards, Daniel -- MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universität Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch
[O] Problem with links whose description looks like a link
Hi! I'm using Org from Git master. If I have a link like, e.g. [[file:somefile.c::int whatsoever][file:somefile.c::int whatsoever]] and a a file somefile.c with the lines int some; int whatsoever; then opening the link with the cursor before the space jumps to the first line, while opening the link on the word "whatsoever" jumps to the second line. It seems like Org detects a link within the link as if the brackets were missing. This also happens if the link looks (non-sensically) like the following [[file:somefile.c::int whatsoever][file:someotherfile.txt]] . Then it would try to open someotherfile.txt instead of somefile.c. In contrast, using [[file:somefile.c::int whatsoever]] works works as expected, i.e. it jumps to the second line. Regards, Daniel -- MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universität Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch
Re: [O] M-RET and C-RET turn current line of text into a heading?
Hi! > I still think it's pretty important to have an option for creating a new > headline *below* all the contents of the current subtree -- what C-RET > used to do. I like to second, that there needs to be a short key binding to insert a new headline below the current entry when the context is in the middle. (Could be C-M-RET or at least C-u C-RET, although I'm very used to type C-RET for doing that.). Regards, Daniel Bausch
Re: [O] Bug in structmode++?
Hi! Bastien writes: > My guess is that message-mode and mail-mode are the modes where > orgstruct-mode is the most used, so having it doing what the users > expect is important. Only for the record: I use orgstruct++ it in magit-log-edit-mode via magit-log-edit-mode-hook. I combine that with turn-on-auto-fill and set-fill-column 72 to enforce the most common git commit style. Regards, Daniel Bausch -- Daniel Bausch Wissenschaftlicher Mitarbeiter Technische Universität Darmstadt Fachbereich Informatik Fachgebiet Datenbanken und Verteilte Systeme Hochschulstraße 10 64289 Darmstadt Germany Tel.: +49 6151 16 6706 Fax: +49 6151 16 6229
Re: [O] agenda: personal priority for today
Hi,
Bastien writes:
>> How do you decide what to do next?
>
> I bind `=' to a custom agenda command that will find out what to do
> next depending on the Emacs context.
>
> For example, when reading emails, C-c a = will find next emails to
> process; when in *.el C-c a = will find next Emacs/Org bugs to deal
> with; when in my big garden.org file, C-c a = will find the next
> useless stuff I want to watch/read.
>
> (See `org-agenda-custom-commands-contexts' if you don't use it yet.)
>
> I don't use clocking that much, but I do set efforts nonetheless,
> because I like using `org-agenda-max-effort' in agenda views: this
> way I'm sure the agenda is not cluttered with tasks I didn't care
> enough about to set an effort for them.
That sounds interesting.
> And above all, I try to discipline myself not setting to many
> "NEXT" tasks. First my notion of "NEXT" was "Yeah, I can do this
> quickly!", now it is more like "This *needs* to be done next",
> obviously a small set.
I currently use the following agenda, which I have always visible on a
second monitor together with my single org file in a split view.
(setq org-agenda-custom-commands '(("g" "My GTD Agenda"
((agenda ""
((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:timestamp :sexp))
(org-agenda-overriding-header "Appointments")))
(agenda ""
((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:deadline))
(org-agenda-overriding-header "Upcoming Deadlines")
(org-agenda-sorting-strategy '(priority-down time-down))
(org-agenda-skip-function '(org-agenda-skip-entry-if 'todo 'done
(agenda ""
((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:scheduled))
(org-agenda-overriding-header "Scheduled")
(org-agenda-sorting-strategy '(priority-down time-down))
(org-agenda-skip-function '(org-agenda-skip-entry-if 'todo 'done
(todo "WAIT"
((org-agenda-sorting-strategy '(priority-down))
(org-agenda-overriding-header "Waiting For")))
(todo "NEXT"
((org-agenda-sorting-strategy '(priority-down effort-down))
(org-agenda-skip-function '(org-agenda-skip-entry-if 'scheduled
'deadline))
(org-agenda-overriding-header
"Next actions not being scheduled nor having a deadline")))
(todo "TODO"
((org-agenda-sorting-strategy '(priority-down effort-down))
(org-agenda-skip-function '(org-agenda-skip-entry-if 'scheduled
'deadline))
(org-agenda-overriding-header
"Future actions not being scheduled nor having a deadline")))
(todo "PROJ" ((org-agenda-overriding-header "Active Projects")))
Everything that consists of two or more sub-tasks is marked as a project
(PROJ) until it is DONE. A NEXT action is an action that could be done
immediately, i.e. there are no other actions that need to be done for
being able to do that. In GTD speech a loose end. If a task is just
marked with TODO, then there is one or more task that needs to be done,
before I will be able to do it. So I end up with a lot of open NEXT and
TODO tasks. To select some to be done on a specific day (e.g. today) I
use scheduling and deadlines. Sometimes I use efforts, but clocking I
use consequently. Project review is supported by using
'(org-enforce-todo-dependencies t). So projects with no defined next
action are colored differently. Sometimes I go through my big list of
open tasks and close some which I am not going to do anymore by setting
them to a special done state CNCL.
Even if I have only six tasks on my scheduled list for today, knowing
that I will not be able to finish all of them really today, I see me
constantly judging one against the others trying to find the most
important. This eats mental resources, that would be better used doing
one of them, but doing simply a random task, keeps me reconsidering,
what also eats up mental resources. Has anyone an idea how to escape
from that mental state of constant reconsidering?
Daniel
--
Daniel Bausch
Wissenschaftlicher Mitarbeiter
Technische Universität Darmstadt
Fachbereich Informatik
Fachgebiet Datenbanken und Verteilte Systeme
Hochschulstraße 10
64289 Darmstadt
Germany
Tel.: +49 6151 16 6706
Fax: +49 6151 16 6229
Re: [O] agenda: personal priority for today
Hi Bastien, Am 11.04.2013 09:04, schrieb Bastien: > Hi Daniel, > > Daniel Bausch writes: > >> I have got another idea: all we need for sorting (from a technical POV) >> is a partial order. Why not store exactly that as a property? Assume >> every TODO entry has an ID (if it has none and it is required to store >> the order, just create one automatically). Then if an entry on the >> agenda is reordered, store in a property (e.g. AGENDA_BEFORE), the IDs >> of the items that should be sorted after the moved item. To keep things >> minimal, maybe store only those IDs, which are absolutely required to >> enforce the desired position. But for an easy and effective >> implementation, it is also feasible to store all IDs of the currently >> visible items that should sort after the moved item. Maybe the IDs need >> to be prefixed with a filename or better a file ID so it works on >> different machines with different directory layout. Otherwise the IDs >> would need to be globally unique (which is not bad by its own, when >> items may move between files.) > > Yes, I see the idea. But one Org headline can be part of several > agendas, so an AGENDA_BEFORE property will not work globally. Just do not touch the IDs of items not currently visible or add the name of the agenda to which this applies and have an AGENDA_BEFORE per agenda. > I think we should start thinking from the existing functionalities > we have with `org-agenda-sorting-strategy', which is already quite > rich (30 strategies!) and flexible. > > But I cannot think of something that would match the OP request > at the moment. Then maybe a 31st is required ;-) I already use some of those 30 strategies, but am also not 100% satisfied with the result. Global priorities are somewhat hard to define. It is mentally easier to just say, hey this is more important than that. The sequence in the Org file can reflect the order of insertion or the typical order of processing within a tree of projects. But when steps from different projects mix within one daily agenda, it is not always possible to prioritize project A over project B. Repeatedly exchanging project A and project B in the file is cumbersome and if there are two projects from different files, one would need to adjust the org-agenda-files variable. I often have more TODOs on the daily agenda, than I will be able to resolve on that day. Deciding on the next most important one everytime when switching the task makes me tired. Doing things in a random order feels dangerous. How do you decide what to do next? Regards, Daniel Bausch -- Daniel Bausch Wissenschaftlicher Mitarbeiter Technische Universität Darmstadt Fachbereich Informatik Fachgebiet Datenbanken und Verteilte Systeme Hochschulstraße 10 64289 Darmstadt Germany Tel.: +49 6151 16 6706 Fax: +49 6151 16 6229
Re: [O] agenda: personal priority for today
Hi, Am 11.04.2013 01:32, schrieb Bastien: > Hi Christopher, > > Christopher Allan Webber writes: > >> I wonder if we had a property that was basically sorting on very large >> numbers? When you add something to the agenda and there aren't any >> sorted items, it creates a property with some median-ish very large >> number. As you move things up and down on the agenda it sorts in random >> ranges between the chunks of huge number space per item. This would be >> a goofy but workable solution? > > I don't know -- it's hard to make sure we speak about the same things > when brainstorming like this. Where would you store the property you > are talking to (for example)? Sorry for the non-romantic question :) > I have got another idea: all we need for sorting (from a technical POV) is a partial order. Why not store exactly that as a property? Assume every TODO entry has an ID (if it has none and it is required to store the order, just create one automatically). Then if an entry on the agenda is reordered, store in a property (e.g. AGENDA_BEFORE), the IDs of the items that should be sorted after the moved item. To keep things minimal, maybe store only those IDs, which are absolutely required to enforce the desired position. But for an easy and effective implementation, it is also feasible to store all IDs of the currently visible items that should sort after the moved item. Maybe the IDs need to be prefixed with a filename or better a file ID so it works on different machines with different directory layout. Otherwise the IDs would need to be globally unique (which is not bad by its own, when items may move between files.) Regards, Daniel Bausch -- Daniel Bausch Wissenschaftlicher Mitarbeiter Technische Universität Darmstadt Fachbereich Informatik Fachgebiet Datenbanken und Verteilte Systeme Hochschulstraße 10 64289 Darmstadt Germany Tel.: +49 6151 16 6706 Fax: +49 6151 16 6229
Re: [O] [dev] About a beamer back-end
Hi Nicolas,
first of all, I think the block idea is a good one, as long a notes will
remain headlines. Nevertheless I often had the problem in my documents,
that I wanted to insert code between frames. It would be great, if you
could provide a clean solution for such things, too. (ignoreheading
does not work in all cases) A special headline class or tag that does
not generate a frame but can contain LaTeX code that is inserted instead
of a frame would be enough. Inserting a great number of "newcommand"
calls before the first frame would be another use of such a thing, as
the alternative, multiple "#+LaTeX_HEADER" statements, is very ugly and
even sometimes fails because of parser problems.
Then I had another problem, for which I was forced to patch the org-mode
code: My university requires me to use a corporate design for my slides.
This design is implemented as a document class, so instead of
\documentclass{beamer} I need to use a different class name. However,
Org Beamer only works correctly, if the documentclass is "beamer".
(#+STARTUP: beamer is NOT enough) Therefore, I needed to change the
hardcoded string in the source code (and now can only output documents
with the corporate style). It would be very nice, if you could find a
solution that works without a hardcoded string at all. Maybe rely on
"#+STARTUP: beamer" or something else. (The function I needed to modify
is org-beamer-after-initial-vars)
Kind regards,
Daniel
--
Daniel Bausch
Wissenschaftlicher Mitarbeiter
Technische Universität Darmstadt
Fachbereich Informatik
Fachgebiet Datenbanken und Verteilte Systeme
Hochschulstraße 10
64289 Darmstadt
Germany
Tel.: +49 6151 16 6706
Fax: +49 6151 16 6229
Re: [O] Agenda, yellow bar "delayed"
There is even a more serious problem here: If I clock in from the agenda by pressing "I" (NOT from the org file itself), some function wrongly aligns all drawer boundaries to the column of the agenda's tags. After that all :PROPERTIES: and :END: are now right aligned to column 120 (my tags column of the agenda). Tags in the headlines seem to be re-aligned, physically, too. This also affects :CLOCK: drawers (if you have them). Seems to me there is some function, which was intended to format the agenda, going crazy and formats the org-mode file. Daniel using Org-mode version 7.8.03 (release_7.8.03.166.g3e13) Am Montag 16. Januar 2012, 19:23:58 schrieb Michael C Gilbert: > On Jan 14, 2012, at 6:33 PM, François Pinard wrote: > > Let me report a tiny annoyance, nothing serious. It seems to coincide > > with a recent "git pull", but the coincidence may be accidental. > > > > Whenever I use the "I" key to clock-in from the agenda, the background > > on the agenda line used to immediately go yellow. Now, it does not > > change immediately, yet if I do "r" to "redo", then it changes. Am I > > alone in having observed this? > > I'm seeing this as well. > > Along with the fact that that agenda line doesn't change the status to > STARTED, as it did before. > > And that J no longer jumps to the currently clocked in task. > > Running 7.8.03 (release_7.8.03.137.g812d0) > > — M
Re: [O] Way to replace normal tabular env with booktabs?
Hello! > On a usage note, I was surprised that the patch causes automatic insertion > of top and bottom rules even when the org table doesn't use ascii > top/bottom rules. In fact, if you use "|-" to put ascii rules on an org > chart using this patch, you get double rules. Disclaimer: I did not test this at all, but am interested in a convenient booktabs support, too. I think it is reasonable to put the top and bottom rules automatically, as booktabs somewhat defines that as the intended look. So it would be redundant to require a |- on top and bottom for all tables on the org side. I even think that org tables with top and bottom rules do not look good, because the vertical lines do not stop at the horizontal lines (from a visual point of view). This way it looks like is a very small empty table line above and below the table. Daniel
Re: [O] [BUG] org-table: time difference delivers wrong results
What may be a leading hint is that even | -28799 | -08:00:01 | #+TBLFM: $2=$1;T does not deliver correct results. It should deliver -07:59:59. Daniel Am Mittwoch 23. November 2011, 11:23:49 schrieb Nick Dokos: > Martyn Jago wrote: > > Martyn Jago writes: > > > > Apologies I had a typo - please ignore the previous mail. So this looks more sensible: > > > Daniel Bausch writes: > > >> Anyone? It might be a duplicate of what Gustav Wiktrom reported on > > >> 1st of September, but his problem was not resolved, either. > > >> > > >> Daniel > > >> > > >> Am Dienstag 15. November 2011, 22:12:45 schrieb Daniel Bausch: > > >>> Hello list, > > >>> > > >>> consider the following example: > > >>> |A | B | C | > > >>> | > > >>> |--+---+---| > > >>> | > > >>> | 07:11:00 | -08:00:00 | -01:11:00 | > > >>> > > >>> #+TBLFM: $3=$1+$2;T > > > > > > [...] > > > > > | Data 1 | Data 2 | Total | > > | > > |--+--+---| > > | > > | 00:00:00 | 00:00:00 | 00:00:00 | > > | 00:00:00 | 00:00:01 | -01:59:59 | > > | 00:00:00 | 00:00:02 | -01:59:58 | > > | 00:00:00 | 00:00:03 | -01:59:57 | > > | 00:00:00 | 00:00:04 | -01:59:56 | > > | 00:00:00 | 00:00:05 | -01:59:55 | > > | 00:00:00 | 00:00:06 | -01:59:54 | > > | 00:00:00 | 00:00:07 | -01:59:53 | > > | 00:00:00 | 00:00:08 | -01:59:52 | > > | 00:00:00 | 00:00:09 | -01:59:51 | > > | 00:00:00 | 00:00:10 | -01:59:50 | > > | 00:00:00 | 00:00:11 | -01:59:49 | > > | 00:00:00 | 00:00:12 | -01:59:48 | > > | 00:00:00 | 00:00:13 | -01:59:47 | > > | 00:00:00 | 00:00:14 | -01:59:46 | > > | 00:00:00 | 00:00:15 | -01:59:45 | > > > > #+TBLFM: > > @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7 > > $3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12 > > $3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@ > > 17$3=$1-$2;T > > > > | Data 1 | Data 2 | Total | > > | > > |--+--+---| > > | > > | 00:00:00 | 00:00:16 | -01:59:44 | > > | 00:00:00 | 00:00:17 | -01:59:43 | > > | 00:00:00 | 00:00:18 | -01:59:42 | > > | 00:00:00 | 00:00:19 | -01:59:41 | > > | 00:00:00 | 00:00:20 | -01:59:40 | > > | 00:00:00 | 00:00:21 | -01:59:39 | > > | 00:00:00 | 00:00:22 | -01:59:38 | > > | 00:00:00 | 00:00:23 | -01:59:37 | > > | 00:00:00 | 00:00:24 | -01:59:36 | > > | 00:00:00 | 00:00:25 | -01:59:35 | > > | 00:00:00 | 00:00:26 | -01:59:34 | > > | 00:00:00 | 00:00:27 | -01:59:33 | > > | 00:00:00 | 00:00:28 | -01:59:32 | > > | 00:00:00 | 00:00:29 | -01:59:31 | > > | 00:00:00 | 00:00:30 | -01:59:30 | > > | 00:00:00 | 00:00:31 | -01:59:29 | > > > > #+TBLFM: > > @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7 > > $3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12 > > $3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@ > > 17$3=$1-$2;T > > > > | Data 1 | Data 2 | Total | > > | > > |--+--+---| > > | > > | 00:00:00 | 00:00:59 | -01:59:01 | > > | 00:00:00 | 00:01:00 | -01:59:00 | > > | 00:00:00 | 00:01:01 | -01:58:59 | > > | 00:00:00 | 00:01:02 | -01:58:58 | > > | 00:00:00 | 00:01:03 | -01:58:57 | > > | 00:00:00 | 00:01:04 | -01:58:56 | > > | 00:00:00 | 00:01:05 | -01:58:55 | > > | 00:00:00 | 00:01:06 | -01:58:54 | > > | 00:00:00 | 00:01:07 | -01:58:53 | > > | 00:00:00 | 00:01:08 | -01:58:52 | > > | 00:00:00 | 00:01:09 | -01:58:51 | > > | 00:00:00 | 00:01:10 | -01:58:50 | > > | 00:00:00 | 00:01:11 | -01:58:49 | > > | 00:00:00 | 00:01:12 | -01:58:48 | > > | 00:00:00 | 00:01:13 | -01:58:47 | > > | 00:00:00 | 00:01:14 | -01:58:46 | > > > > #+TBLFM: > > @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7 > > $3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12 > > $3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@ > > 17$3=$1-$2;T > > > > Best, Martyn > > > > -- > > > > I _will_ engage brain before posting to the ML :( > > I can't see straight at this time of the night, but aren't all these > formulas equivalent to a column formula? > > #+TBLFM: $3 = $1 - $2;T > > Assuming that's the case, the problem is that org-table-time-to-string > assumes that it is given a positive number and mishandles negative > numbers, eg. the first row in the last table invokes: > > , > > | (org-table-time-seconds-to-string -59 nil) > | "-01:59:01" > > ` > > > I didn't check carefully, but it looks as if the other-way function, > org-table-time-string-to-seconds, deals correctly with "negative" time > strings. > > Nick
Re: [O] [BUG] org-table: time difference delivers wrong results
Anyone? It might be a duplicate of what Gustav Wiktröm reported on 1st of September, but his problem was not resolved, either. Daniel Am Dienstag 15. November 2011, 22:12:45 schrieb Daniel Bausch: > Hello list, > > consider the following example: > |A | B | C | > | > |--+---+---| > | > | 07:11:00 | -08:00:00 | -01:11:00 | > > #+TBLFM: $3=$1+$2;T > > I think the result in the third column is wrong. I expect 0 hours and 49 > minutes, negative (-00:49:00). > > The following does not work, too: > |A | C | > | > |--+---| > | > | 07:11:00 | -01:11:00 | > > #+TBLFM: $2=$1-28800;T > > Daniel
[O] [BUG] org-table: time difference delivers wrong results
Hello list, consider the following example: |A | B | C | |--+---+---| | 07:11:00 | -08:00:00 | -01:11:00 | #+TBLFM: $3=$1+$2;T I think the result in the third column is wrong. I expect 0 hours and 49 minutes, negative (-00:49:00). The following does not work, too: |A | C | |--+---| | 07:11:00 | -01:11:00 | #+TBLFM: $2=$1-28800;T Daniel
Re: [O] C-c C-c not working at end of #+end_src line (was: [RFC] Standardized code block keywords)
Am Montag 31 Oktober 2011, 20:01:14 schrieb Eric Schulte: > Daniel Bausch writes: > > I did some tests with my documents and they look fine. Thanks for your > > work. > > Great, good to know. > > > (A minor remark, offtopic: If the document ends just below a source > > code block, no results are inserted when the block is executed. You > > have to insert an additional blank line, for a result to can appear.) > > I can't reproduce this problem. Ok, I played around and found that what I saw has nothing to do with a blank line existing or not, but only with the position of point. What I observed happens if point is at the end of the #+end_src line. If you press C-c C-c there then you get "Local setup has been refreshed" if there is a newline following. If the documents ends just there, then you get "org-mode fontification error". In both cases no result is produced. I think it is a very common case that one wants to execute a code block right after typing #+end_src, so that point position should "belong" to the code block. If you move one character left, so you are between r and c, then C-c C-c works as expected. If you need an example, use that #+begin_src R 42 #+end_src It even does not matter, whether there is additional text following.
Re: [O] [RFC] Standardized code block keywords
I did some tests with my documents and they look fine. Thanks for your work. (A minor remark, offtopic: If the document ends just below a source code block, no results are inserted when the block is executed. You have to insert an additional blank line, for a result to can appear.) Daniel Am Freitag 28 Oktober 2011, 20:52:48 schrieb Eric Schulte: > Nick Dokos writes: > > Eric Schulte wrote: > >> The attached updated patch fixes a bug in the original. > > > > Minor problem in applying: > > > > , > > > > | $ git apply ~/Mail/inbox/724 > > | /home/nick/Mail/inbox/724:671: trailing whitespace. > > | #+name: > > | /home/nick/Mail/inbox/724:599: new blank line at EOF. > > | + > > | warning: 2 lines add whitespace errors. > > > > ` > > The attached version fixes these issues, Thanks -- Eric
Re: [O] [RFC] Standardized code block keywords
> > Daniel (who used Babel to write his thesis in one big file with all data > > and chart generating code interleaved with the text -- faboulous!) > > Indeed - could we hope to get a glimpse at some examples (or even the whole > thing) at some point? Unfortunately not at the moment, because we're still in the process of getting the topic published. > Nick > > PS. I presume it's clear to all that this silliness I started has a big > smilie wrapped around the whole thing, but just in case somebody decides > that I'm serious: pthvhtththth :-) Yeah, that's clear. :-D Have a nice day Daniel
Re: [O] [RFC] Standardized code block keywords
Am Mittwoch 26 Oktober 2011, 15:10:03 schrieb Giovanni Ridolfi: > Nick Dokos writes: > > Eric Schulte wrote: > >> Surprisingly (to me) srcname is the winner here, but luckily I haven't > >> yet voted, and although I would have though #+source: would have been > >> the winner I like the simplicity of using #+name: for named code blocks > >> as well as named data. So I'll vote for #+name: here making it a tie, > >> and I'll also take tie-breaking powers upon myself giving #+name: the > >> win. > > > > This is going to cost you, Schulte! It's not going to go down that > > easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the > > BDFL, the NFL and the MLB: an outrage I tell you! An affront to the > > democratic rules some of us cherish! We'll fight to the death! Who's > > with me? > > +1 srcname > > :-) > > Power to the people! Democracy forever! > > Giovanni /who has not used babel yet. Hmm, then you don't know what we are talking about and should abstain from voting. ;-) -- Daniel (who used Babel to write his thesis in one big file with all data and chart generating code interleaved with the text -- faboulous!)
Re: [O] [RFC] Standardized code block keywords
Am Dienstag 25 Oktober 2011, 19:21:22 schrieb Nick Dokos: > Eric Schulte wrote: > > Martyn Jago writes: > > > Nick Dokos writes: > > >> Eric Schulte wrote: > > >>> Surprisingly (to me) srcname is the winner here, but luckily I > > >>> haven't yet voted, and although I would have though #+source: would > > >>> have been the winner I like the simplicity of using #+name: for > > >>> named code blocks as well as named data. So I'll vote for #+name: > > >>> here making it a tie, and I'll also take tie-breaking powers upon > > >>> myself giving #+name: the win. > > >> > > >> This is going to cost you, Schulte! It's not going to go down that > > >> easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, > > >> the BDFL, the NFL and the MLB: an outrage I tell you! An affront to > > >> the democratic rules some of us cherish! We'll fight to the death! > > >> Who's with me? > > > > Ha! > > > > Well at least SCOTUS should be on my side, as they seem to have no > > problem giving some people more freedom than others. > > Indeed - but what about the NFL? I bet they have more integrity. > > > On second thought... > > > > +1 #+name > > Back stabber! Oops, I didn't want to split the community. Be nice to each other. > > Well thank goodness, even if I can't put my own thumb on the scale it > > seems I can advertise enough to sway voters to my cause. :) > > Bribery and Corruption - what is the world coming to? > > > Cheers -- Eric > > > > > mj
Re: [O] [RFC] Standardized code block keywords
> > However, I'd like to ask, what happens, if one refers to a > > name of a source block where data is expected, does it then refer to > > the results produced by that source block? How are such situations > > handeled at the moment? > > Try it out, but be ready to press C-g, because I would guess that it > results in an infinite loop. Isn't it possible to refer to the results of a code block as input data for another? I thought it was. If not currently then at least I suppose that it will be in the future. The new syntax should be ready for that. Daniel
Re: [O] [RFC] Standardized code block keywords
Am Dienstag 25 Oktober 2011, 03:30:46 schrieb Eric Schulte: > "Sebastien Vauban" writes: > > Hi Daniel, > > > > Daniel Bausch wrote: > >>> named code blocks [1] -- "source" "srcname" "function" > >>> > >>> calling external functions [2] -- "call" "lob" > >>> > >>> named data [3] -- "tblname" "resname" "results" "data" > >> > >> what about "#+name:" for [1] and [3], and "#+call:" for [2] ? > >> > >> That a table or list contains data is obvious. The only thing, the > >> additional line is for, is to "name" it. > > > > As Eric showed us, this is not always to name it... If the table is the > > results of an unamed block, you will have #+name: followed by no name! > > > > #+name: > > | line 1 | data1 | > > | line 2 | data2 | > > > > what I also find quite disturbing. > > I also find this to be disconcerting. -- Eric > > > Best regards, > > > > Seb Then maybe #+results for (anonymous) results only, but #+name for anything else from [1] and [3]. Wasn't there a concept of linking a results block to its originiating source block by some id and we need a place to put the checksum in. So I see some arguments for treating results special. But for the others I do not see pressing arguments against a common "name" at the moment. However, I'd like to ask, what happens, if one refers to a name of a source block where data is expected, does it then refer to the results produced by that source block? How are such situations handeled at the moment? In other words: is there any type checking? Type checking could be facilitated by using different words, although I think that is not neccessary, because there are other means to distinguish the type of a block (look at the next line in the buffer). Daniel
Re: [O] [RFC] Standardized code block keywords
Am Sonntag 23 Oktober 2011, 18:09:01 schrieben Sie:
> Daniel Bausch writes:
> > Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
> >> Eric Schulte writes:
> >> >>> I'm confused by [3] so I will say nothing for now, except to ask
> >> >>> some questions: are we talking about what a human would use to
> >> >>> label a piece of data for consumption by a block (including perhaps
> >> >>> the future possibilities of lists and paragraphs that Tom brought
> >> >>> up)? what babel would use to label a results block (possibly so
> >> >>> that it could be consumed by another block in a chain)? both? would
> >> >>> that mean that #+tblname would go the way of the dodo and that
> >> >>> tables would be labelled with #+data (or #+object or whatever else
> >> >>> we come up with)?
> >> >>
> >> >> +1 (Confused, too)
> >> >
> >> > well, I guess it is good that this discussion has begun if only to
> >> > clear up this lingering uncertainty.
> >> >
> >> >> I wasn't even aware of #+DATA. Does it do anything TBLNAME and
> >> >> SRCNAME don't?
> >> >
> >> > from the prospective of code blocks it is exactly synonymous with
> >> > tblname. Srcname is different in that it labels code blocks.
> >> >
> >> >> A reason to keep TBLNAME is that it's also used by the spreadsheet
> >> >> remote references. If Babel looked for DATA instead, a table that is
> >> >> both a remote reference for another spreadsheet and a data source for
> >> >> a src block would need both TBLNAME and DATA, which seems redundant.
> >> >
> >> > agreed, I'm thinking that tblname will at least remain an option no
> >> > matter what decision is made.
> >> >
> >> >> As for labeling lists and paragraphs, I recall from the list that
> >> >> Nicolas Goaziou is working on a generalized way to set captions,
> >> >> labels and attributes for various kinds of Org block, as is possible
> >> >> now for tables and images. I thought that sounded promising. I don't
> >> >> know if he planned for block names, too (currently we have tblname
> >> >> but no imgname), but that could make sense. In which case it might
> >> >> be a good idea to coordinate.
> >> >
> >> > Agreed, I was not aware of this work. Thanks for sharing. In this
> >> > vein I would like to voice my desire to be able to add captions to
> >> > code blocks, the lack of this feature has bitten me in the past.
> >>
> >> Hi Eric,
> >>
> >> For LaTeX export, the listings package has support for code block
> >> captions.
> >
> > Not in org AFAIK, org only supports these for my use cases not very
> > useful "function name = " exports. I patched org to produce real
> > captions instead, but my changes are not that well tested and required
> > some changes in the central export logic. If there is interest I could
> > share what I have so far. The code quality is a mess, as I do not really
> > know elisp.
> >
> > Daniel
>
> Yes, source code block captions currently have to be handled outside the
> usual Org-mode mechanism. If you use org-special-blocks and the
> listings package, then the following template will give you floating
> code block listings with captions in LaTeX export.
>
> : #+BEGIN_listing
> :
> :
> :
> : #+LATEX: \caption[The short caption]{The long caption.}\ref{fig:src_blk}
> : #+END_listing
>
> This doesn't do anything for export to other formats, but it works well
> for LaTeX export. There is even \listoflistings command to produce a
> list of source code listings in the front matter.
>
> All the best,
> Tom
Thank you for this hint, but with my patches, I'm able to write
#+caption: A Code Snippet
#+label: lst:xyz
#+begin_src lang
#+end_src
What I'd like to add, is that the listings implementation in org has a bug,
which I also fixed. If you mix #+begin_src and #+begin_example blocks in one
document, then the #+begin_example blocks are syntax highlighted analog to the
previous #+begin_src block because the language is selected by \lstset.
In my patches I'm using the 'language' attribute of \begin{lstlisting}, which
does not affect following blocks that do not have this attribute.
I have attached my patch. I suspect that there might be a b
Re: [O] [RFC] Standardized code block keywords
Hi, > named code blocks [1] -- "source" "srcname" "function" > calling external functions [2] -- "call" "lob" > named data [3] -- "tblname" "resname" "results" "data" what about "#+name:" for [1] and [3], and "#+call:" for [2] ? That a table or list contains data is obvious. The only thing, the additional line is for, is to "name" it. That a source block contains source is also obvious and is already noted by the use of #+begin_src, so why duplicate the "src"-part? Daniel
Re: [O] [RFC] Standardized code block keywords
Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye: > Eric Schulte writes: > >>> I'm confused by [3] so I will say nothing for now, except to ask some > >>> questions: are we talking about what a human would use to label a piece > >>> of data for consumption by a block (including perhaps the future > >>> possibilities of lists and paragraphs that Tom brought up)? what babel > >>> would use to label a results block (possibly so that it could be > >>> consumed by another block in a chain)? both? would that mean > >>> that #+tblname would go the way of the dodo and that tables would be > >>> labelled with #+data (or #+object or whatever else we come up with)? > >> > >> +1 (Confused, too) > > > > well, I guess it is good that this discussion has begun if only to clear > > up this lingering uncertainty. > > > >> I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME > >> don't? > > > > from the prospective of code blocks it is exactly synonymous with > > tblname. Srcname is different in that it labels code blocks. > > > >> A reason to keep TBLNAME is that it's also used by the spreadsheet > >> remote references. If Babel looked for DATA instead, a table that is > >> both a remote reference for another spreadsheet and a data source for > >> a src block would need both TBLNAME and DATA, which seems redundant. > > > > agreed, I'm thinking that tblname will at least remain an option no > > matter what decision is made. > > > >> As for labeling lists and paragraphs, I recall from the list that > >> Nicolas Goaziou is working on a generalized way to set captions, > >> labels and attributes for various kinds of Org block, as is possible > >> now for tables and images. I thought that sounded promising. I don't > >> know if he planned for block names, too (currently we have tblname but > >> no imgname), but that could make sense. In which case it might be a > >> good idea to coordinate. > > > > Agreed, I was not aware of this work. Thanks for sharing. In this vein > > I would like to voice my desire to be able to add captions to code > > blocks, the lack of this feature has bitten me in the past. > > Hi Eric, > > For LaTeX export, the listings package has support for code block > captions. Not in org AFAIK, org only supports these for my use cases not very useful "function name = " exports. I patched org to produce real captions instead, but my changes are not that well tested and required some changes in the central export logic. If there is interest I could share what I have so far. The code quality is a mess, as I do not really know elisp. Daniel
Re: [O] What do you use to identify projects (in the GTD sense)
Hi Marcelo,
its nothing special:
* Working Area (the order of these models some kind of global priorization)
:PROPERTIES:
:CATEGORY: CAT-A (<- some identifier to be displayed on the left of agenda)
:END:
** PROJ outcome or project title
*** DONE something done
*** NEXT the next action
*** TODO something currently not actionable (because of dependencies or so)
PROJ some subproject
* ... you get it
Often I prefix the individual action items with short identifiers for the
containing project to give me some context in the agenda. Instead of
extending the strings it helps to keep them shorter.
For example:
TODO software-x: talk to Fred about the missing requirements
instead of
TODO talk to Fred about the missing requirements of software-x
In english its not very efficient, but in German it can save you a lot of
letters and you have a fixed position to look for the context. A tag may fit
the same needs but they are located less prominently and I think one needs the
context first.
Daniel
Am Montag 10 Oktober 2011, 20:44:46 schrieb Marcelo de Moraes Serpa:
> Hi Daneil,
>
> Looks interesting. Could you share a sample tree with projects and actions?
>
> Cheers,
>
> - Marcelo.
>
> On Mon, Oct 10, 2011 at 6:30 AM, Daniel Bausch wrote:
> > Hello,
> >
> > I use a todo keyword "PROJ" and a custom block agenda, that filters
> > different
> > interesting groups for review.
> >
> > (setq org-agenda-custom-commands
> >
> > '(("g" "My GTD Agenda"
> >
> > ((agenda "" ((org-agenda-ndays 1)
> >
> > (org-agenda-start-on-weekday nil)
> > (org-agenda-entry-types '(:timestamp :sexp))
> > (org-agenda-overriding-header "Appointments")))
> >
> > (agenda "" ((org-agenda-ndays 1)
> >
> > (org-agenda-start-on-weekday nil)
> > (org-agenda-entry-types '(:deadline))
> > (org-agenda-overriding-header "Upcoming Deadlines")
> > (org-agenda-sorting-strategy '(priority-down
> >
> > time-down))
> >
> > (org-agenda-skip-function '(org-agenda-skip-entry-if
> >
> > 'todo
> > 'done
> >
> > (agenda "" ((org-agenda-ndays 1)
> >
> > (org-agenda-start-on-weekday nil)
> > (org-agenda-entry-types '(:scheduled))
> > (org-agenda-overriding-header "Scheduled")
> > (org-agenda-sorting-strategy '(priority-down
> >
> > time-down))
> >
> > (org-agenda-skip-function '(org-agenda-skip-entry-if
> >
> > 'todo
> > 'done
> >
> > (todo "WAIT" ((org-agenda-sorting-strategy '(priority-down))
> >
> >(org-agenda-overriding-header "Waiting For")))
> >
> > (todo "NEXT" ((org-agenda-sorting-strategy '(priority-down
> > effort-
> >
> > down))
> >
> >(org-agenda-skip-function
> >'(org-agenda-skip-entry-if
> >
> > 'scheduled 'deadline))
> >
> >(org-agenda-overriding-header "Next actions not
> >
> > being
> > scheduled nor having a deadline")))
> >
> > (todo "TODO" ((org-agenda-sorting-strategy '(priority-down
> > effort-
> >
> > down))
> >
> >(org-agenda-skip-function
> >'(org-agenda-skip-entry-if
> >
> > 'scheduled 'deadline))
> >
> >(org-agenda-overriding-header "Future actions not
> >
> > being scheduled nor having a deadline")))
> >
> > (todo "PROJ" ((org-agenda-overriding-header "Active
> >
> > Projects")))
> >
> >
> > Along with colors
> >
> > '(org-todo-keyword-faces (quote (("PROJ" :foreground "Orange" :weight
> >
> > bold)
> > ("MSTN" :foreground "VioletRed" :weight bold) ("WAIT" :foreground "Blue"
> >
> > :weight bold) ("CNCL" :foreground "MediumSeaGreen" :weight bold
> >
> > and
> &
Re: [O] What do you use to identify projects (in the GTD sense)
Hello,
I use a todo keyword "PROJ" and a custom block agenda, that filters different
interesting groups for review.
(setq org-agenda-custom-commands
'(("g" "My GTD Agenda"
((agenda "" ((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:timestamp :sexp))
(org-agenda-overriding-header "Appointments")))
(agenda "" ((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:deadline))
(org-agenda-overriding-header "Upcoming Deadlines")
(org-agenda-sorting-strategy '(priority-down time-down))
(org-agenda-skip-function '(org-agenda-skip-entry-if
'todo
'done
(agenda "" ((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:scheduled))
(org-agenda-overriding-header "Scheduled")
(org-agenda-sorting-strategy '(priority-down time-down))
(org-agenda-skip-function '(org-agenda-skip-entry-if
'todo
'done
(todo "WAIT" ((org-agenda-sorting-strategy '(priority-down))
(org-agenda-overriding-header "Waiting For")))
(todo "NEXT" ((org-agenda-sorting-strategy '(priority-down effort-
down))
(org-agenda-skip-function '(org-agenda-skip-entry-if
'scheduled 'deadline))
(org-agenda-overriding-header "Next actions not being
scheduled nor having a deadline")))
(todo "TODO" ((org-agenda-sorting-strategy '(priority-down effort-
down))
(org-agenda-skip-function '(org-agenda-skip-entry-if
'scheduled 'deadline))
(org-agenda-overriding-header "Future actions not
being scheduled nor having a deadline")))
(todo "PROJ" ((org-agenda-overriding-header "Active Projects")))
Along with colors
'(org-todo-keyword-faces (quote (("PROJ" :foreground "Orange" :weight bold)
("MSTN" :foreground "VioletRed" :weight bold) ("WAIT" :foreground "Blue"
:weight bold) ("CNCL" :foreground "MediumSeaGreen" :weight bold
and
'(org-enforce-todo-checkbox-dependencies t)
'(org-enforce-todo-dependencies t)
this works really well for GTD.
Kind regards,
Daniel
Am Montag 10 Oktober 2011, 08:21:57 schrieb Marcelo de Moraes Serpa:
> Hey list,
>
> I'm wondering if you make the distinction between projects and actionable
> items. If you stop to think about it (specially if you read GTD by David
> Allen), you see that you can't really "do" a project, but only actions
> related to it. It's a powerful and underestimated concept. Of course, a
> todo list is still a reminder of things, and any list can be useful, but
> the more specific you are, the less you have to think (process) and the
> more you can actually execute.
>
> Anyway, I was wondering how you guys differentiate between projects and
> next actions (todo's) in your org lists. I myself use a :project: tag for
> projects and todos have todo keywords before them. Projects never have a
> todo keyword, except when DONE. I used to use a PROJECT keyword before,
> but I felt that a tag seems to work better (and allows you to actually
> filter todos without mixing projects). So, a typical list looks like this:
>
> * New feature :project:
> ** TODO Create a mockup for the index page
> ** TODO Convert the mockup to html
> * Renew passport :project:
> ** DONE Call for appointment
> ** TODO Interveiw
> SCHEDULED <...>
> ** DONE Buy groceries :project: ...
>
> How do you do it?
>
> Thanks in advance,
>
> - Marcelo.
Re: [O] Time range end in agenda view not displayed
Hi Michael, it's much easier to achieve, what you want. Just write <2011-09-30 Fri 14:00-18:00> (at least as long as the times refer to the same day) Daniel Am Freitag 30 September 2011, 12:00:56 schrieb michael holzer: > Hi everyone, > > I'm having a problem with the agenda view, hopefully someone can tell me > what I'm doing wrong: > > When I have an entry that contains a time range, for example: > > * timerange > <2011-09-30 Fri 14:00>--<2011-09-30 Fri 18:00> > > this shows up in the agenda view as: > > uni:14:00.. timerange > > while I would expect something like: > > uni:14:00-18:00 timerange > > as the manual says > (http://orgmode.org/org.html#Time_002dof_002dday-specifications). > > Thanks for any help, > michael
Re: [O] Surprising behaviour with agenda file
It's not a bug, it's a feature (although I don't know what it's for -- maybe speed). However, there is a customizable option to switch it off: org-agenda-skip-additional-timestamps-same-entry Daniel Am Donnerstag 29 September 2011, 14:16:10 schrieb Andreas Amann: > Hi list, > > I encounter the following surprising situation when using Org Agenda. > > Suppose you have an agenda file which looks like this: > test.org -- > * bar > <2011-09-29 Thu 12:00> > <2011-09-30 Fri 13:00> > > > * foo > <2011-09-29 Thu 15:00> > <2011-09-29 Thu 16:00> > > > M-x org-agenda-week-view > then shows: > > Week-agenda (W39): > Monday 26 September 2011 W39 > Tuesday27 September 2011 > Wednesday 28 September 2011 > Thursday 29 September 2011 >8:00.. > 10:00.. > test: 12:00.. bar > 12:00.. > 13:09.. now - - - - - - - - - - - - - - - - - - - - - - - > - - 14:00.. > test: 15:00.. foo > 16:00.. > 18:00.. > 20:00.. > Friday 30 September 2011 > test: 13:00.. bar > Saturday1 October 2011 > Sunday 2 October 2011 > > -- > > What surprises me, is that "foo" only appears once (Thurs 15:00) > although I specified it twice in the agenda file. If the two entries in > question refer to two different days, like "bar" in the above example, > everything works as expected. > > Is this a bug? If it is considered a feature I would be interested to > know, how to work around it. > > Thanks, > Andreas
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Hi, I'd like to note, that ".~" would lead to a hard space, that disallows a line break, so I think only ".\ " is correct, although Emacs M-q does not break after ". " with a single space, too, to be able to detect sentence ends. Daniel Am Freitag, 19. August 2011, 08:50:52 schrieb Andras Major: > in TeX and LaTeX, the width of the glue (blank space) after a "." can > be one of two different values, depending on the context. There is > always a longer space between sentences than after a "." that doesn't > mark the end of a sentence (abbreviations, dates, etc.). Since > TeX/LaTeX usually can't recognize the latter case by itself, one can > help out by writing ".\ " or ".~" explicitly to enforce a short space. > Without these hints, printed output will look typographically wrong. > > Org-mode export doesn't allow me to easily include these hints without > affecting readability and export to other formats. Therefore I ask > that LaTeX export places ". " or ".\ " in the output automatically > depending on the context: > > - If, in the source, the "." precedes a double space " " or a newline, > use ". ". > > - In any other case, use ".\ ". > > The reason this would work is the Emacs convention of writing ASCII > such that there is at least one more space (at least two) between > sentences. I believe that the Emacs fill-* functions also make use of > this convention. > > Thanks, > > András
Re: [O] [bug] Asterisks in source and example blocks interpreted as headings
Hi, AFAIK that is exactly the case, for which the "," rule is for. Just put a "," in front of the offending line and everything will be fine. On export the "," is removed. best regards, Daniel Am Dienstag 16 August 2011, 20:27:01 schrieb Jason Dunsmore: > Hello, > > I noticed that lines with leading asterisks inside of source and example > blocks are interpreted as headings: > > --8<---cut here---start->8--- > * Heading 1 > > #+begin_example > foo > * bar > blah > #+end_example > > * Heading 2 > --8<---cut here---end--->8--- > > If you put the point on "Heading 1" and hit TAB, you'll see the > following: > > --8<---cut here---start->8--- > * Heading 1... > * bar > blah > #+end_example > > * Heading 2 > --8<---cut here---end--->8--- > > I'm using GNU Emacs 23.2.1 and Org-mode version 7.7 > (release_7.7.97.g9d5c5) > > Regards, > Jason
Re: [O] Durations and time values combined with the clock table..
Hello everyone,
I would like to bump this question as I am interested in a similar way.
I like to do independent (from normal time tracking) work time calculations to
get an overview of my overtime. Of course, overtime can be negative.
Hierarchically summing up days and weeks is also a wish. I think HH:MM is a
better default interpretation, too, as it would be consistent with the rest of
org-mode. What would be nice is a keystroke than inserts the current time.
What about time calculations including dates? (Should be optional and only be
a result, if non-dated time value is combined with a dated.)
* non-dated + non-dated = non-dated // normal time calculation
* non-dated - non-dated = non-dated // normal time calculation
* dated + non-dated = dated // interval addition
* dated - non-dated = dated // interval substraction
* non-dated + dated = dated // interval addition (operands switched)
* - non-dated + dated = dated // interval substract (operands switched)
* dated - dated = non-dated // get the time difference
* non-dated - dated = non-sense // time difference not calculable
* dated + dated = non-sense // maybe throw an #ERROR
* scalar * non-dated = non-dated // interval multiplication
* non-dated * scalar= non-dated // interval multiplication
* scalar / non-dated = scalar// datatype "per hour"
* non-dated / scalar= non-dated // time share
So there has to be two different data types, I think. Current time insert
would default to non-dated with C-u, it could insert a dated time value.
There could be some operator that converts from scalar to non-dated and back
(1:30 -> 1.5 ("h")).
Of course, only ideas, and sadly I currently have no time to look into it
myself ( because of the overtime ;-) ).
Best regards,
Daniel Bausch
Am Samstag 09 Juli 2011, 12:10:18 schrieb Gustav Wikström:
> Hello!
>
> Great work with the new functions allowing time calculations in the
> spreadsheet! Just a few remarks.. The default format is MM:SS and hours
> have to be qualified by using three positions HH:MM:SS.
>
> Would it not be smart if the default for this calculations is the same as
> the time-format for the clock table? There the default is HH:MM - i presume
> due to the superfluity of seconds.
>
> I do not really care which format is the default but being able to use the
> time calculation on my org-mode-generated time-table, without having to
> manually add :SS to each string, would be great..
>
> And another question, negative time? I realize that this sounds strange
> from a philosophical point of view... but being able to use minus in
> time-cells would be neat.
>
> As an example i've attached a dummy-timetable to this mail to illustrate my
> point. Column 6 and Row 2, column 5 & 6 is generated by the time-function.
>
> Clock summary at [2011-07-09 Sat 11:50]
>
> | Headline | Time || Proj Δ | Task Δ |Proj |
> |
> |--+--++++-|
> |
> | *Total time* | *359:50* || 10 | -285 |2:13 |
> |
> |--+--++++-|
> |
> | Project 1| 287:55 || 05:00 || 0 |
> | Task 1 | | 239:50 || 10:00 | 4:09:50 |
> | Task 2 | | 48:05 || -300 | 43:05 |
> | Project 2|71:55 || 05:00 || 0 |
> | Task 1 | | 47:50 || 10:00 | 57:50 |
> | Task 2 | | 24:05 || -5:00 | 29:05 |
>
> #+TBLFM: $6=$3+$5;T::@2$4='(apply '+ '(@3..@8));T::@2$5=vsum(@3..@8);T::@2
> $6=vsum(@3..@8);T
>
> Also, summations over multiple columns or rows does not seem to be working
> =/
>
> Regards Gustav
Re: [O] Export to LaTeX class beamer
Hello John, search for allowframebreak, a LaTeX beamer option. Maybe this will fit your needs. For org-mode this may be placed in org-beamer-frame-default-options. However, when it is present, you will not be able to use overlays anymore. Daniel Am Mittwoch, 27. April 2011, 11:01:40 schrieb Tait John: > Hi > > When I export to class beamer, much of the content can be pushed off the > bottom of the slide. > > Other than restricting the amount of content under headings, is there a > simple way of allowing the content to spill onto the next slide? > > Thanks > > John > *** > *** > ** > > The content of this email (and any attachment) is confidential. It may also > be legally privileged or otherwise protected from disclosure. > > This email should not be used by anyone who is not an original intended > recipient, nor may it be copied or disclosed to anyone who is not an > original intended recipient. > > If you have received this email by mistake please notify us by emailing the > sender, and then delete the email and any copies from your system. > > Liability cannot be accepted for statements made which are clearly the > senders own and not made on behalf of Network Rail. > > Network Rail Infrastructure Limited registered in England and Wales No. > 2904587, registered office Kings Place, 90 York Way London N1 9AG > > *** > *** > **
Re: [Orgmode] Re: [PATCH] org-export-generic, "text markup" -- and a request
Hi Tomas! I have nothing to contribute to the real topic, but I wanted to inform you that there is a software called dokuwiki - so I got a bit irritated, whether you are reffering to that or to mediawiki, as you first stated. And (at least on the mailinglist) your patch is delivered as an empty file. Kind regards Daniel ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
