Re: [O] [PATCH] org-agenda tag completion works with ido
New patch attached. I have already signed the FSF copyright papers, so I haven't marked as TINYCHANGE - let me know if I still should. On Thu, Jul 13, 2017 at 4:31 PM, Kyle Meyer wrote: > Nathaniel Flath writes: > >> I suppose so. I still think this is a correct patch, since it doesn't >> make sense to filter for non-existent tags. > > I agreed that require-match should be t earlier in the thread, but it > turns out that that's not the source of your issue. I took time to > clarify this in order to a) help you solve your ido completion issue > everywhere, not just one specific case in one particular package, and b) > make the description in your commit message accurate, which it currently > isn't. > > Feel free to send a new patch with an updated commit message. Also, > based on the contributor list [*], you should mark it with a TINYCHANGE > cookie. It looks like you're hitting up against your TINYCHANGE code > limit, so please consider signing FSF copyright papers for future > patches. > > [*] http://orgmode.org/worg/org-contribute.html > > -- > Kyle 0001-completing-read-in-org-agenda-filter-by-tag-only-acc.patch Description: Binary data
Re: [O] [PATCH] org-agenda tag completion works with ido
I suppose so. I still think this is a correct patch, since it doesn't make sense to filter for non-existent tags. On Thu, Jul 13, 2017 at 12:19 PM, Kyle Meyer wrote: > Nathaniel Flath writes: > >> Confirmed it's a difference in ido configuration - I'm using >> ido-everywhere, not ido-ubiquitous. > > OK, thanks. So you were just seeing the default Emacs completion rather > than ido's. My understanding is that ido-everywhere only adds ido for > buffer/file prompts, and so you'll need to use ido-ubiquitous to get ido > completion in with Org 9. (Any package that overrides > completing-read-function should work, so you can also use helm, ivy, > etc). > > -- > Kyle
Re: [O] [PATCH] org-agenda tag completion works with ido
Confirmed it's a difference in ido configuration - I'm using
ido-everywhere, not ido-ubiquitous.
On Thu, Jul 13, 2017 at 11:19 AM, Nathaniel Flath wrote:
> On Thu, Jul 13, 2017 at 11:02 AM, Kyle Meyer wrote:
>> Nathaniel Flath writes:
>>
>> [...]
>>
>>>> I'm not an ido user, but testing with
>>>>
>>>> (require 'ido-ubiquitous)
>>>> (ido-ubiquitous-mode 1)
>>>>
>>>> partial completion seems to work fine when I hit tab after calling
>>>> org-agenda-filter-by-tag. Are you using ido-ubiquitous, or are you
>>>> using some other package to get ido completion for non-file/buffer
>>>> completion?
>>>
>>> The issue is that that 'tab' is required - in the previous version of
>>> org, this was not required and 'enter' would do the completion for
>>> you.
>>
>> I'm only using tab right after calling org-agenda-filter-by-tag to get
>> to the initial tag prompt, following the instructions in the minibuffer.
>> Isn't that always needed?
>>
>> Here is how I'm testing (with emacs -Q):
>>
>> * list TODOs with the agenda (org-agenda, follow by "t")
>> * on an entry, hit "/" for org-agenda-filter-by-tag
>> * hit tab to get to the tag prompt
>>
>> Once in the prompt, I can select a partial completion by just hitting
>> enter.
>
> I follow the same steps:
> * list TODOs with the agenda (org-agenda, follow by "t")
> * on an entry, hit "/" for org-agenda-filter-by-tag
> * hit tab to get to the tag prompt
> * type 'ho' + enter - this causes everything to disappear, because it
> is trying to filter for 'ho' instead of 'home' ('ho' is not a valid
> tag)
>
> I've upgraded to the lastest version of ido-ubiquitous and this
> behaviour persists.
> (This is also my understanding of what the expected behaviour should
> be, based on testing of completing-read and reading the function
> docs).
>
>>
>> I've executed the above steps with two setups:
>> release_8.3.6/org-completion-use-ido and release_9.0.9/ido-ubiquitous.
>> I couldn't spot any differences. Hitting enter for partial completion
>> worked in both cases.
>>
>>>> In this particular case, your change looks OK because I think all useful
>>>> values should be in the collection. But I don't understand why you're
>>>> not able to do partial completion without this change. Are you running
>>>> into the same issue everywhere else that completing-read is called with
>>>> a nil value for require-match?
>>>
>>> I haven't checked everywhere else - presumably.
>>
>> It'd be good to figure out why you're seeing different behavior than I
>> am. Perhaps the steps I list above aren't the right steps to trigger
>> it. Or maybe you have some non-default ido configuration. Or maybe the
>> difference comes from an ido version mismatch. (I'm using the ido from
>> Emacs 25.2 and ido-ubiquitous checked out at v3.14-4-ga1c2965.)
>
> I'm on emacs 24.5.1 - I'll try updating, but I suspect the problem will
> persist.
>>
>> As it stands, I can't reproduce the problem described in your commit
>> message.
>>
>> --
>> Kyle
Re: [O] [PATCH] org-agenda tag completion works with ido
On Thu, Jul 13, 2017 at 11:02 AM, Kyle Meyer wrote:
> Nathaniel Flath writes:
>
> [...]
>
>>> I'm not an ido user, but testing with
>>>
>>> (require 'ido-ubiquitous)
>>> (ido-ubiquitous-mode 1)
>>>
>>> partial completion seems to work fine when I hit tab after calling
>>> org-agenda-filter-by-tag. Are you using ido-ubiquitous, or are you
>>> using some other package to get ido completion for non-file/buffer
>>> completion?
>>
>> The issue is that that 'tab' is required - in the previous version of
>> org, this was not required and 'enter' would do the completion for
>> you.
>
> I'm only using tab right after calling org-agenda-filter-by-tag to get
> to the initial tag prompt, following the instructions in the minibuffer.
> Isn't that always needed?
>
> Here is how I'm testing (with emacs -Q):
>
> * list TODOs with the agenda (org-agenda, follow by "t")
> * on an entry, hit "/" for org-agenda-filter-by-tag
> * hit tab to get to the tag prompt
>
> Once in the prompt, I can select a partial completion by just hitting
> enter.
I follow the same steps:
* list TODOs with the agenda (org-agenda, follow by "t")
* on an entry, hit "/" for org-agenda-filter-by-tag
* hit tab to get to the tag prompt
* type 'ho' + enter - this causes everything to disappear, because it
is trying to filter for 'ho' instead of 'home' ('ho' is not a valid
tag)
I've upgraded to the lastest version of ido-ubiquitous and this
behaviour persists.
(This is also my understanding of what the expected behaviour should
be, based on testing of completing-read and reading the function
docs).
>
> I've executed the above steps with two setups:
> release_8.3.6/org-completion-use-ido and release_9.0.9/ido-ubiquitous.
> I couldn't spot any differences. Hitting enter for partial completion
> worked in both cases.
>
>>> In this particular case, your change looks OK because I think all useful
>>> values should be in the collection. But I don't understand why you're
>>> not able to do partial completion without this change. Are you running
>>> into the same issue everywhere else that completing-read is called with
>>> a nil value for require-match?
>>
>> I haven't checked everywhere else - presumably.
>
> It'd be good to figure out why you're seeing different behavior than I
> am. Perhaps the steps I list above aren't the right steps to trigger
> it. Or maybe you have some non-default ido configuration. Or maybe the
> difference comes from an ido version mismatch. (I'm using the ido from
> Emacs 25.2 and ido-ubiquitous checked out at v3.14-4-ga1c2965.)
I'm on emacs 24.5.1 - I'll try updating, but I suspect the problem will persist.
>
> As it stands, I can't reproduce the problem described in your commit
> message.
>
> --
> Kyle
Re: [O] [PATCH] org-agenda tag completion works with ido
On Wed, Jul 12, 2017 at 9:35 PM, Kyle Meyer wrote: > Nathaniel Flath writes: > >> After upgrading to the latest org-mode, tag completion when filtering >> in the agenda was broken - I had to fully enter the tag, despite using >> ido (eg I would have a tag 'home', and 'ho-enter' would not compete). > > [...] > >> * org-agenda.el (org-agenda-filter-by-tag): >> (org-agenda-filter-by-tag): pass t to require-match argument of >> completing-read. > > ^ repeated function name > Removed that in patch attached. >> This causes ido-mode to complete tags properly when inputting partial >> matches, rather >> that just sending the typed input. > > Wouldn't this mean that, in general, ido won't complete partial matches > properly when require-match is nil? That doesn't sound right. > > I'm not an ido user, but testing with > > (require 'ido-ubiquitous) > (ido-ubiquitous-mode 1) > > partial completion seems to work fine when I hit tab after calling > org-agenda-filter-by-tag. Are you using ido-ubiquitous, or are you > using some other package to get ido completion for non-file/buffer > completion? The issue is that that 'tab' is required - in the previous version of org, this was not required and 'enter' would do the completion for you. > > In this particular case, your change looks OK because I think all useful > values should be in the collection. But I don't understand why you're > not able to do partial completion without this change. Are you running > into the same issue everywhere else that completing-read is called with > a nil value for require-match? I haven't checked everywhere else - presumably. > > -- > Kyle 0001-completing-read-in-org-agenda-filter-by-tag-complete.patch Description: Binary data
[O] [PATCH] org-agenda tag completion works with ido
After upgrading to the latest org-mode, tag completion when filtering in the agenda was broken - I had to fully enter the tag, despite using ido (eg I would have a tag 'home', and 'ho-enter' would not compete). Minor patch to fix this behaviour is attached. Let me know if there are any issues. Thanks, Nathaniel Flath 0001-completing-read-in-org-agenda-filter-by-tag-complete.patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Fixed. On Fri, Dec 5, 2014 at 3:57 PM, Nicolas Goaziou wrote: > Nathaniel Flath writes: > > > Sorry, that was incorrect - real patches attached. > > Thanks. > > > +(defun org-table-message-once-per-second (t1 &rest args) > > + "If there has been more than one second since T1, display message. > > +ARGS are passed as arguments to the 'message' function. Returns > > +current time if a message is printed, otherwise returns t1.. If > > +T1 is nil, always messages." > > + (let ((curtime (current-time))) > > +(when (or (not t1) (< 0 (nth 1 (time-subtract curtime t1 > > + (apply message args) > > + curtime)) > > +t1) > > The docstring seems incorrect, as the function always returns T1, no > matter if a message is printed or not. > > > + (setq log-last-time > > + (org-table-message-once-per-second > > +(when all log-last-time) > > Nitpick: (and all log-last-time) > > > + (when all log-last-time) > > Ditto. > > + (when all log-first-time) > > Ditto. > > > Regards, > 0001-org-table.el-org-table-recalculate-early-returns(1).patch Description: Binary data 0001-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Sorry, that was incorrect - real patches attached. On Mon, Dec 1, 2014 at 1:02 AM, Nathaniel Flath wrote: > Changed it to just a function - you are correct, for this purpose I don't > need a macro. > > On Fri, Nov 21, 2014 at 6:30 PM, Nicolas Goaziou > wrote: > >> Nathaniel Flath writes: >> >> > OK, I think I fixed that. >> >> Thanks. >> >> I didn't verify it compiles, but your macro still looks suspicious. >> >> > +(defmacro org-table-execute-once-per-second (t1 &rest body) >> > + "If there has been more than one second since T1, execute BODY. >> > +Updates T1 to 'current-time' if this condition is met. If T1 is >> > +nil, always execute body." >> > + `(let ((t1 ,t1)) >> > + (if t1 >> > + (let ((curtime (current-time))) >> > +(when (< 0 (nth 1 (time-subtract curtime t1))) >> > + (setq t1 curtime) >> > +,@body)) >> > + ,@body))) >> >> You shouldn't splice BODY twice in your macro. Also, I don't get why you >> need to (setq t1 curtime). >> >> Do you need a macro at all for this task? ISTM you only need to display >> a message conditionally and update a time value. >> >> >> Regard, >> > > 0001-org-table.el-org-table-recalculate-early-returns(1).patch Description: Binary data 0001-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Changed it to just a function - you are correct, for this purpose I don't need a macro. On Fri, Nov 21, 2014 at 6:30 PM, Nicolas Goaziou wrote: > Nathaniel Flath writes: > > > OK, I think I fixed that. > > Thanks. > > I didn't verify it compiles, but your macro still looks suspicious. > > > +(defmacro org-table-execute-once-per-second (t1 &rest body) > > + "If there has been more than one second since T1, execute BODY. > > +Updates T1 to 'current-time' if this condition is met. If T1 is > > +nil, always execute body." > > + `(let ((t1 ,t1)) > > + (if t1 > > + (let ((curtime (current-time))) > > +(when (< 0 (nth 1 (time-subtract curtime t1))) > > + (setq t1 curtime) > > +,@body)) > > + ,@body))) > > You shouldn't splice BODY twice in your macro. Also, I don't get why you > need to (setq t1 curtime). > > Do you need a macro at all for this task? ISTM you only need to display > a message conditionally and update a time value. > > > Regard, > 0001-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data 0001-org-table.el-org-table-recalculate-early-returns(1).patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
OK, I think I fixed that. Yes, I have signed FSF papers. On Sat, Nov 15, 2014 at 4:07 AM, Nicolas Goaziou wrote: > Hello, > > Michael Brand writes: > > > In my opinion the newest patches can be applied, tests passed on my > > side. Thank you. > > Thanks. > > However, I get compilation errors, probably due to the macro > `org-table-execute-once-per-second'. In particular, using multiple ",t1" > isn't a good idea. > > BTW, Nathaniel, these patches are no tiny changes. Have you signed FSF > papers yet? > > > Regards, > > -- > Nicolas Goaziou > 0001-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data 0001-org-table.el-org-table-recalculate-early-returns(1).patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Bleh. Took out the wrong cnt, and that didn't show up in my testing for some reason. On Fri, Nov 14, 2014 at 11:10 PM, Michael Brand wrote: > Hi Nathaniel > > On Fri, Nov 14, 2014 at 2:33 PM, Nathaniel Flath > wrote: > > Aaaand another try. > > I tested them and got an error because of a missing cnt: > > > + (message "Re-applying formulas to %d lines...done" > > Michael > 0001-org-table.el-org-table-recalculate-early-returns(1).patch Description: Binary data 0002-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Aaaand another try. On Thu, Nov 13, 2014 at 12:39 AM, Michael Brand wrote: > Hi Nathaniel > > On Wed, Nov 12, 2014 at 12:51 PM, Nathaniel Flath > wrote: > > New patches attached! > > Now that they apply I found: > > > + "Re-applying formulas to full table...(line %d)"))) > > Missing cnt. > > > + (message "Re-applying formulas...done" cnt)) > > Superfluous cnt. > > Michael > 0002-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data 0001-org-table.el-org-table-recalculate-early-returns(1).patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
New patches attached! On Sun, Nov 9, 2014 at 9:12 PM, Michael Brand wrote: > Hi Nathaniel > > On Sun, Nov 9, 2014 at 11:18 AM, Nathaniel Flath > wrote: > > Updated patches attached. > > The second does not apply after the first on today's > release_8.3beta-552-ga95cfeb. Unrelated: The second has new closing > parentheses on an own line. > > Michael > 0002-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data 0001-org-table.el-org-table-recalculate-early-returns.patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Updated patches attached. 0001-org-table.el-org-table-recalculate-early-returns.patch Description: Binary data 0002-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Hi Michael
On Mon, Oct 20, 2014 at 12:41 PM, Michael Brand
wrote:
> Hi Nathaniel
>
> On Mon, Oct 20, 2014 at 3:56 AM, Nathaniel Flath
> wrote:
> > Thanks for the review! Updated patches attached. I believe I've fixed
> > everything you mentioned -
>
> Yes, thank you. I tried them out.
>
> > let me know if I missed something.
>
> > Subject: [PATCH 1/2] org-table.el: Add early return check to
> > org-table-recalculate
>
> > Subject: [PATCH 2/2] org-table.el: Print far fewer messages when
> recalculating
> > tables.
>
> http://orgmode.org/worg/org-contribute.html
> says: Line 2 is an empty line.
>
> I try to limit my commit subjects to 50 chars which is a rule for some
> projects and helpful for e. g. git log with certain options.
>
OK, will fix these in next set of pathces.
>
> > +(and all (org-table-execute-once-per-second
> > + log-last-time
> > + (message
> > + "Re-applying formulas to full table...(line %d)"
> > + (setq cnt (1+ cnt)
>
> Before trying out I have overseen it, setq does not increment on each
> line any more so it has to move before
> org-table-execute-once-per-second. Now probably better wrapped in a
> `when' instead of the original `and' with an added `progn'.
>
OK, good catch
>
> > +(org-table-execute-once-per-second
> > + log-first-time
> > + (message "Re-applying formulas...done" cnt))
>
> cnt is superfluous.
>
OK.
>
> Only during trying out I noticed: This message could still be kept as
> a feedback at least for single row updates, like e. g. Tab on a row
> with "#" in the first column, by changing log-first-time to (when all
> log-first-time).
>
> Or more conservative why not leave this message unconditional to avoid
> that any user could complain for any use case that all feedback
> messages disappeared like it would be the case for e. g. the typical
> "C-c C-c" on TBLFM? I think that would be a simple, safe compromise.
>
I'm fine with adding the (when all log-first-time). I don't want to leave
it
unconditional because as we discussed before, one message in my case
significantly slows down the table recalculation - and if there has
been no feedback then we are dealing with a small case where it could be
significant.
>
> Otherwise the right but not so simple thing to do would be to log this
> message for a simple "C-c C-c" on TBLFM and to not log it for only
> those cases that throw after other feedback messages like e. g.
> sometimes "C-u C-u C-c C-c" on TBLFM ("Table was already stable"), M-x
> org-table-iterate-buffer-tables and more. These repetition intensive
> use cases are the only ones that can profit noticeable from the
> conditional removal of this last message, aren't they?
>
I got tired of having to force tables to be reformated, so I advised
org-cycle to always recalculate a table, so I notice whenever I'm in a
table.
>
> Michael
>
Re: [O] [PATH] Speedups to org-table-recalculate
Hi Michael, Thanks for the review! Updated patches attached. I believe I've fixed everything you mentioned - let me know if I missed something. On Sun, Oct 19, 2014 at 3:57 PM, Michael Brand wrote: > Hi Nathaniel > > On Sat, Oct 18, 2014 at 7:11 AM, Nathaniel Flath > wrote: > > Patches are attached. > > I am not an expert for all the following comments, please correct me > or contradict where necessary. > > The patches do not apply on current master, so I did not try them out > yet. > > You might want to add a def-edebug-spec like there is one for many > other defmacro in Org. > Limit lines to max. 80 chars. > > It will make it easier for the maintainer Bastien to apply the patches > when you format them with git including a changelog etc. as described > here > http://orgmode.org/worg/org-contribute.html > > > + (if (not all) (message "Re-applying formula to field: %s" > (car eq)) > > +(org-table-execute-once-per-second log-last-time (message > "Re-applying formula to field: %s" (car eq > > Good idea to still log always when only one table row is recalculated. > > The doubling of the message makes it more complicated to maintain its > string. I suggest to change the macro to allow > > (org-table-execute-once-per-second > (when all log-last-time) ; Log just always when `all' is nil. > (message "Re-applying formula to field: %s" (car eq))) > Why not test `all' also for the other message with "to field"? > > > > + ,@body > > + ))) > > > > +(and all (org-table-execute-once-per-second log-last-time > (message "Re-applying formulas to %d lines...done" cnt > > Shouldn't this use `log-first-time'? > > > Michael > 0001-org-table.el-Add-early-return-check-to-org-table-rec.patch Description: Binary data 0002-org-table.el-Print-far-fewer-messages-when-recalcula.patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Hi On Sat, Oct 11, 2014 at 12:16 PM, Michael Brand wrote: > Hi Nathaniel > > On Fri, Oct 10, 2014 at 9:43 PM, Nathaniel Flath > wrote: > > Mine is a pretty simple table (takes less than a second even in the > original > > case): > > Earlier I assumed that the issue is a very high number of messages > from the loops. Now your example table clarifies to me that the issue > is that already just one single message can take a significant time of > a message-less table recalculation (your 17 ms). > > Only with this I understand now why you want to remove also the > beginning/end processing messages. Good point as it should be > noticeable at least for org-table-iterate-buffer-tables in a buffer > with many tables where each one takes a short time to recalculate. > > I really wonder what the reason is that this > > (progn > (message "%d" (random)) ;; Prevent collapsing of message lines. > (time (message nil))) > > in a terminal (emacs -nw) shows most of the times only 0.05 to 0.10 ms > but in a window it shows most of the times 8 to 22 ms (here: GNU Emacs > 24.3.1 on Mac OS X 10.9). Which Emacs version and OS are you using? > I'm running 24.3.1 on Mac OS X 10.8.4. > > For your patch I suggest to remove only the first message and to add > the time check to all other messages. This should not make the patch > noticeably slower but would keep showing the progress for table > recalculations that last more than one second. To clean up the last > loop message from the mode line I suggest to check the end messages > against the very first log time in contrast to the next log time used > for the loop messages (variables "log_first" and "log_next" instead of > just "log"). > > I suggest you split your patch: One for "(when eqlist" and one for the > messages. The change with the messages will then become human readable > also with a simple line diff. OK, sounds reasonable. Patches are attached. > > > Original recalculation: (0 0 396224 0) > > > Version w/ time checks for per-field messages (still always printing at > > beginning/end of processing):(0 0 56929 0) > > > Version w/ time checks and removing all beginning/end of processing > > messages: (0 0 22077 0) > > > My patch: (0 0 17405 0) > > I could not reproduce a reliable difference between the last two. As > expected both did not log any message. Can you? > Rrunning more iterations they seemed to be mostly equal. Patches are attached. > > Michael > org-table-speedup-1.patch Description: Binary data org-table-speedup-2.patch Description: Binary data
Re: [O] [PATH] Speedups to org-table-recalculate
Mine is a pretty simple table (takes less than a second even in the original case): | Category | Budget | Spent | Remaining | |--++---+---| | A|100 | 0 | 100 | | B|100 | 0 | 100 | | C|100 | 0 | 100 | | D|100 | 0 | 100 | | E|100 | 0 | 100 | | F|100 | 0 | 100 | | G|100 | 0 | 100 | | H|100 | 0 | 100 | | I|100 | 0 | 100 | | J|100 | 0 | 100 | | K|100 | 0 | 100 | | L|100 | 0 | 100 | | M|100 | 0 | 100 | | N|100 | 0 | 100 | | O|100 | 0 | 100 | | K|100 | 0 | 100 | |--++---+---| | Total| 1600 | 0 | 1600 | #+TBLFM: $4=$2-$3::@18$2=vsum(@2$2..@-1)::@18$3=vsum(@2$3..@-1) With the macro: (defmacro time (block) `(let (start end) (setq start (current-time)) ,block (setq end (current-time)) (print (time-subtract end start and running (time (org-table-recalculate t)) Original recalculation: (0 0 396224 0) Version w/ time checks for per-field messages (still always printing at beginning/end of processing):(0 0 56929 0) Version w/ time checks and removing all beginning/end of processing messages: (0 0 22077 0) My patch: (0 0 17405 0) So, it's still a 26% performance degradation to going with the patch and removing the 'global' messaging, but I could probably live with that - qualitatively, there doesn't seem to be too much difference between my patch and doing that, but the original version is obviously slow and with the on-begin/end calculation messages the delay is much more noticable. On Fri, Oct 10, 2014 at 3:35 AM, Michael Brand wrote: > Hi Nathaniel > > On Fri, Oct 10, 2014 at 7:56 AM, Nathaniel Flath > wrote: > > That's still much more slow than not doing it - slightly modifying your > > example,: > > > > (progn > > (setq start (current-time)) > > (let ((row 0) (log (time-add (current-time) '(0 1 0 0 > > (while (< row 6543210) > > (setq row (1+ row)) > > (when (time-less-p log (current-time)) > > (setq log (time-add (current-time) '(0 1 0 0))) > > (message "row %d" row > > (setq end (current-time)) > > (print (time-subtract end start))) > > > > prints (0 43 386499 0) on my computer. > > > > Removing the when clause: > > > > (progn > > (setq start (current-time)) > > (let ((row 0) (log (time-add (current-time) '(0 1 0 0 > > (while (< row 6543210) > > (setq row (1+ row > > (setq end (current-time)) > > (print (time-subtract end start))) > > > > Results in: > > (0 1 277641 0) > > > > So adding the logging here slows it down by about 43x - It doesn't seem > > worth it. > > Your measurement shows that "(when (time-less-p log (current-time)) > [...]" takes 6.4 microseconds or can run 150'000 times per second. I > would expect it to be negligible compared to what Org has to do for > each row or field like parse, calculate, format etc. Otherwise it > would mean that Org can perform more or not significantly less than > 150'000 rows or fields per second on an appropriate example table. > > Tersely formulated I expect this performance comparison: nothing or > empty loop << a conditional message with time check << Org performs a > simple formula on one row or field << an unconditional message > > Can you make a performance comparison on your table between (a) your > patch and (b) without your patch but with "(when (time-less-p log > (current-time)) [...]" plus describe or share this table? > > Michael >
Re: [O] [PATH] Speedups to org-table-recalculate
Sorry for the late response - missed this for a while. That's still much more slow than not doing it - slightly modifying your example,: (progn (setq start (current-time)) (let ((row 0) (log (time-add (current-time) '(0 1 0 0 (while (< row 6543210) (setq row (1+ row)) (when (time-less-p log (current-time)) (setq log (time-add (current-time) '(0 1 0 0))) (message "row %d" row (setq end (current-time)) (print (time-subtract end start))) prints (0 43 386499 0) on my computer. Removing the when clause: (progn (setq start (current-time)) (let ((row 0) (log (time-add (current-time) '(0 1 0 0 (while (< row 6543210) (setq row (1+ row (setq end (current-time)) (print (time-subtract end start))) Results in: (0 1 277641 0) So adding the logging here slows it down by about 43x - It doesn't seem worth it. On Sun, Aug 17, 2014 at 6:39 AM, Michael Brand wrote: > Hi Nathaniel > > On Thu, Aug 7, 2014 at 4:57 PM, Nathaniel Flath > wrote: > > I'd be fine with displaying every > > second, but I don't see a good way of doing this - do you have any > > suggestions? > > I thought of something like in this example: > > (let ((row 0) (log (time-add (current-time) '(0 1 0 0 > (while (< row 6543210) > (setq row (1+ row)) > (when (time-less-p log (current-time)) > (setq log (time-add (current-time) '(0 1 0 0))) > (message "row %d" row > > Michael >
Re: [O] [PATH] Speedups to org-table-recalculate
Yes, that wouldn't be supported - although certainly in my case what was making it slow *were* the messages. I'd be fine with displaying every second, but I don't see a good way of doing this - do you have any suggestions? On Fri, Aug 1, 2014 at 2:56 PM, Michael Brand wrote: > Hi Nathaniel > > On Tue, Jul 29, 2014 at 2:03 PM, Nathaniel Flath > wrote: > > This patch speeds up org-table-recalculate by removing all 'message' > > function calls. Additionally adds an early check for whether there are > any > > formulas and only executes the rest of the function if so. > > As far as I understand these `message' were added to see the progress > of a long lasting recalculation which would not be supported any more > with your patch. But I agree that it would be sufficient to report the > current field/line only every let's say one second and suppress the > others to gain speed for use cases like yours. > > Michael >
Re: [O] [PATH] Speedups to org-table-recalculate
Hi Bastien, I believe I did that a long time ago, juste been inactive. I've definitely contributed to org before, although searching through my email I can only find a copyright assignment for Emacs itself (dated 8/23/09), do I have to re-do this? Thanks, Nathaniel Flath On Tue, Jul 29, 2014 at 2:30 PM, Bastien wrote: > Hi Nathaniel, > > Nathaniel Flath writes: > > > This patch speeds up org-table-recalculate by removing all 'message' > > function calls. Additionally adds an early check for whether there > > are any formulas and only executes the rest of the function if so. > > The patch is bigger than what can be accepted without requiring a > copyright assignment. Here is the form you would need to send if > you agree: > > http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt > > It can take a month, especially since this is summer time. > > Thanks in advance! > > -- > Bastien >
[O] [PATH] Speedups to org-table-recalculate
This patch speeds up org-table-recalculate by removing all 'message' function calls. Additionally adds an early check for whether there are any formulas and only executes the rest of the function if so. org-table-speedup.patch Description: Binary data
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Updated patch attached. Thanks, Nathaniel Flath On Mon, Dec 20, 2010 at 10:25 AM, Nicolas Goaziou wrote: > Hello, > >>>>>> Nathaniel Flath writes: > >> Sory for the long delay - I got caught up in other work. A >> patchaddressing the sisues brought up is attached. > > I've had a look at your patch. > > I think the modifications to HTML and DocBook exporters are nice. It > could be possible to do the same thing in LaTeX, but it would require > yet another package (enumitem) by default. Anyway, here are the code > comments : > > - in your patch, you should try to list modifications to the > functions, and which functions were created. For example : > > * org-list.el (org-alphabetical-lists): new variable > (org-cycle-list-bullet): added "A)" "a)" "A." and "a." to the list > of bullets in cycle. None of them is allowed in a description list. > > - The "yes" at the beginning of org-docbook.el should be removed > > - I advise against using (org-next-item) programmatically. It means > you compute the structure associated to the list for each item in > the list. I left a note about this circa line 847 in org-list.el > > - There's a bug with the following situation : > > A) test > B) tersi > C) teirsu > D) tersiu > E) tesiu > F) teisru > G) etisu > - sub-item 1 > - sub-item 2 > - sub-item 3 > - sub-item 4 > H) tesinu > I) tesinru > J) etnrsiu > K) tesriun > L) etnsiu > M) estinu > N) etsniu > O) etsinu > P) tesnu > Q) etsinu > R) etsiun > S) etsnriu > T) etsnriu > U) etsinu > V) etsiu > W) etinrsu > X) last item > > If you outdent sub-items 2 to 4 at the same time (with a region), > bullet of the last item will become "AA)" and will not be recognized > as a list item anymore. > > - There's also a bug with counters: > > * [0/0] Counter > > A. [X] first box > B. [X] second box > > These boxes are not counted when bullets are literals (try C-c #). > > > HTH, > > Regards, > > -- Nicolas > 0001-Added-support-for-alphabetical-patches-to-org-list.patch Description: Binary data ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Sory for the long delay - I got caught up in other work. A patchaddressing the sisues brought up is attached. Let me know of anything else. Thanks, Nathaniel Flath On Fri, Nov 26, 2010 at 8:39 PM, Nathaniel Flath wrote: > I'm working on your comments, should have another patch in the next day or so. > > The only thing I had issue with was the comment about > org-item-beginning-re: I prefer it as a function for the reasons you > mention, but I'm not particularly attached to this. Does anyone else > have an opinion? > > Thanks, > Nathaniel Flath > > On Mon, Nov 22, 2010 at 10:37 AM, Nicolas Goaziou wrote: >> Hello, >> >>>>>>> Nathaniel Flath writes: >> >>> although I'm not an expert in the exporting. Let me know if there's >>> anything else, or if I screwed up anything when trying to figure out >>> how to make a git patch(looks like it worked, though.) >> >> I looked at your patch and here is what I've noticed so far: >> >> >> - There's a bug in `org-cycle-list-bullet' where >> org-list-can-be-alphabetical is called with argument missing. >> >> - In `org-cycle-list-bullet', variable `top' stores list top point, >> make use of it instead of recomputing it. >> >> - There's a typo in `org-list-parse-list' (ogr-looking-at-p instead of >> org-looking-at-p) >> >> - Some parts of the patch are only white-space changes (for example a >> change in `org-list-automatic-rules' but there are others). You >> shouldn't include them, as it is not the purpose of the patch. >> >> It doesn't help understanding your patch either. >> >> - Why did you remove all code comments about lists in org-docbook.el? >> >> - This is not a bug but are you sure you want to make >> org-item-beginning-re a function? I understand that it permits an >> user changing the value of `org-alphabetical-lists' to avoid >> reloading Org, but it looks like syntax overweight to me. >> >> I mean, anyone wanting to look for a list item will have to remember >> that it must do a re-search on a function and not a string. >> >> >> Hoping that helps, >> >> Regards, >> >> -- Nicolas >> > 0001-Added-support-for-alphabetical-patches-to-org-list.patch Description: Binary data ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
I'm working on your comments, should have another patch in the next day or so. The only thing I had issue with was the comment about org-item-beginning-re: I prefer it as a function for the reasons you mention, but I'm not particularly attached to this. Does anyone else have an opinion? Thanks, Nathaniel Flath On Mon, Nov 22, 2010 at 10:37 AM, Nicolas Goaziou wrote: > Hello, > >>>>>> Nathaniel Flath writes: > >> although I'm not an expert in the exporting. Let me know if there's >> anything else, or if I screwed up anything when trying to figure out >> how to make a git patch(looks like it worked, though.) > > I looked at your patch and here is what I've noticed so far: > > > - There's a bug in `org-cycle-list-bullet' where > org-list-can-be-alphabetical is called with argument missing. > > - In `org-cycle-list-bullet', variable `top' stores list top point, > make use of it instead of recomputing it. > > - There's a typo in `org-list-parse-list' (ogr-looking-at-p instead of > org-looking-at-p) > > - Some parts of the patch are only white-space changes (for example a > change in `org-list-automatic-rules' but there are others). You > shouldn't include them, as it is not the purpose of the patch. > > It doesn't help understanding your patch either. > > - Why did you remove all code comments about lists in org-docbook.el? > > - This is not a bug but are you sure you want to make > org-item-beginning-re a function? I understand that it permits an > user changing the value of `org-alphabetical-lists' to avoid > reloading Org, but it looks like syntax overweight to me. > > I mean, anyone wanting to look for a list item will have to remember > that it must do a re-search on a function and not a string. > > > Hoping that helps, > > Regards, > > -- Nicolas > ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
I think I've fixed these, although I'm not an expert in the exporting. Let me know if there's anything else, or if I screwed up anything when trying to figure out how to make a git patch(looks like it worked, though.) Thanks, Nathaniel Flath On Sat, Nov 13, 2010 at 7:16 AM, Nicolas Goaziou wrote: > Hello, > >>>>>> Nathaniel Flath writes: > >> Are there any further issues? > > Also, as you changed `org-item-beginning-re' into a function, there > are a few places outside org-list.el that need to be modified > accordingly. > > And exporters (mainly HTML and DocBook) should be aware of > alphabetical bullets. > > Regards, > > -- Nicolas > 0001-Squashed-commit-of-the-following.patch Description: Binary data ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Are there any further issues? Thanks, Nathaniel Flath On Thu, Oct 28, 2010 at 12:17 AM, Nathaniel Flath wrote: > New patch fixing these issues is attached. > > Let me know of any other problems. > > On Tue, Oct 26, 2010 at 1:23 AM, Carsten Dominik > wrote: >> >> On Oct 26, 2010, at 10:21 AM, Nicolas Goaziou wrote: >> >>> Hello, >>> >>>>>>>> Nathaniel Flath writes: >>> >>>> I think I've fixed the issues brought up with this new patch. Please >>>> let me know what you think. >>> >>> I've noticed a couple of glitches. >>> >>> First, you are using >>> >>> (> 28 (length struct)) >>> >>> to know when to replace letters by numbers. But (length struct) >>> doesn't always match list length, so it will lead to errors when >>> outdenting items. >>> >>> For example, try outdenting, with its subtree, the item marked with >>> "<<<" in the list below: >>> >>> a) etsiun >>> b) etsiun >>> c) etsiun >>> d) etisun >>> e) etsiun >>> f) etsiun >>> g) etsiun >>> h) etsiun >>> i) etisun >>> j) etsiun >>> k) etsiun >>> l) etsiun >>> m) etsiun >>> n) etsiun >>> a) Outdent me and my children ! <<< >>> a) tersiu >>> b) etsiru >>> c) estiur >>> d) etsnriu >>> e) etsiun >>> f) etiune >>> g) etuirsnet >>> b) etsiun >>> o) etsiun >>> p) etsiun >>> q) etsiun >>> r) etsiun >>> s) etsiun >>> >>> All the lists will be numbered although they could keep alphabetical >>> bullets. >>> >>> Another (lesser) problem is coming from the regexp chosen for bullets, >>> that is "[0-9A-Za-z]+". I would suggest something alike >>> "\\(\\(?:[0-9]\\)+\\|[A-Za-z]\\)". At the moment, you can set counter >>> to [...@a4] and break you list when applying it. >> >> >> Also, even when the alpha lists are turned off, typing >> >> a) >> >> and pressing M-RET will show that a) is seen as a list bullet. >> >> Thanks for your work, we are getting closer to an acceptable patch. >> >> - Carsten >> >>> >>> Regards, >>> >>> -- Nicolas >> >> - Carsten >> >> >> >> > ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
New patch fixing these issues is attached. Let me know of any other problems. On Tue, Oct 26, 2010 at 1:23 AM, Carsten Dominik wrote: > > On Oct 26, 2010, at 10:21 AM, Nicolas Goaziou wrote: > >> Hello, >> >>>>>>> Nathaniel Flath writes: >> >>> I think I've fixed the issues brought up with this new patch. Please >>> let me know what you think. >> >> I've noticed a couple of glitches. >> >> First, you are using >> >> (> 28 (length struct)) >> >> to know when to replace letters by numbers. But (length struct) >> doesn't always match list length, so it will lead to errors when >> outdenting items. >> >> For example, try outdenting, with its subtree, the item marked with >> "<<<" in the list below: >> >> a) etsiun >> b) etsiun >> c) etsiun >> d) etisun >> e) etsiun >> f) etsiun >> g) etsiun >> h) etsiun >> i) etisun >> j) etsiun >> k) etsiun >> l) etsiun >> m) etsiun >> n) etsiun >> a) Outdent me and my children ! <<< >> a) tersiu >> b) etsiru >> c) estiur >> d) etsnriu >> e) etsiun >> f) etiune >> g) etuirsnet >> b) etsiun >> o) etsiun >> p) etsiun >> q) etsiun >> r) etsiun >> s) etsiun >> >> All the lists will be numbered although they could keep alphabetical >> bullets. >> >> Another (lesser) problem is coming from the regexp chosen for bullets, >> that is "[0-9A-Za-z]+". I would suggest something alike >> "\\(\\(?:[0-9]\\)+\\|[A-Za-z]\\)". At the moment, you can set counter >> to [...@a4] and break you list when applying it. > > > Also, even when the alpha lists are turned off, typing > > a) > > and pressing M-RET will show that a) is seen as a list bullet. > > Thanks for your work, we are getting closer to an acceptable patch. > > - Carsten > >> >> Regards, >> >> -- Nicolas > > - Carsten > > > > ordered-list.patch Description: Binary data ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Sorry about that - patch attached. Thanks, Nathaniel Flath On Fri, Oct 22, 2010 at 1:13 AM, Carsten Dominik wrote: > Hi Nathaniel, > > I get "patch does not apply". Can you please update the patch to the > current git master? > > Thanks > > - Carsten > > > On Oct 22, 2010, at 7:30 AM, Nathaniel Flath wrote: > >> I think I've fixed the issues brought up with this new patch. Please >> let me know what you think. >> >> On Wed, Oct 20, 2010 at 9:44 PM, Nathaniel Flath >> wrote: >>>> >>>>> >>>>> But I can't help thinking this could lead to unexpected results in >>>>> some cases (admittedly less than when alpha bullets could be any size >>>>> long). >>>> >>>> It definitely will. >>>> >>>> Here is an alternative idea. Nathaniel, what do you >>>> think about this: We could keep the numbering as we >>>> have it in the Org file, but introduce something like [...@a] >>>> in the first item that will convert the numbering >>>> into a,b,... upon export to ASCII, HTML, maybe even LaTeX >>>> (even though I think LaTeX demands some consistency here >>>> and prefers to have the global setup decide how lists work). >>>> Hell, we could even use [...@a] for capitals and [...@i] and [...@i] >>>> for roman numbering :) >>>> >>>> - Carsten >>>> >>> >>> Sorry for the late response - got swamped with work for a bit. >>> >>> I'd much prefer the approach I've been going with, mostly since I >>> don't usually export my notes and mostly view them in org-mode. I'll >>> work on the patch tonight - should send a patch either later tonight >>> or tomorow. >>> >>> Thanks, >>> Nathaniel Flath >>> >> > > - Carsten > > > > org-list.patch Description: Binary data ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
I think I've fixed the issues brought up with this new patch. Please let me know what you think. On Wed, Oct 20, 2010 at 9:44 PM, Nathaniel Flath wrote: >> >>> >>> But I can't help thinking this could lead to unexpected results in >>> some cases (admittedly less than when alpha bullets could be any size >>> long). >> >> It definitely will. >> >> Here is an alternative idea. Nathaniel, what do you >> think about this: We could keep the numbering as we >> have it in the Org file, but introduce something like [...@a] >> in the first item that will convert the numbering >> into a,b,... upon export to ASCII, HTML, maybe even LaTeX >> (even though I think LaTeX demands some consistency here >> and prefers to have the global setup decide how lists work). >> Hell, we could even use [...@a] for capitals and [...@i] and [...@i] >> for roman numbering :) >> >> - Carsten >> > > Sorry for the late response - got swamped with work for a bit. > > I'd much prefer the approach I've been going with, mostly since I > don't usually export my notes and mostly view them in org-mode. I'll > work on the patch tonight - should send a patch either later tonight > or tomorow. > > Thanks, > Nathaniel Flath > ordered-list.patch Description: Binary data ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
> >> >> But I can't help thinking this could lead to unexpected results in >> some cases (admittedly less than when alpha bullets could be any size >> long). > > It definitely will. > > Here is an alternative idea. Nathaniel, what do you > think about this: We could keep the numbering as we > have it in the Org file, but introduce something like [...@a] > in the first item that will convert the numbering > into a,b,... upon export to ASCII, HTML, maybe even LaTeX > (even though I think LaTeX demands some consistency here > and prefers to have the global setup decide how lists work). > Hell, we could even use [...@a] for capitals and [...@i] and [...@i] > for roman numbering :) > > - Carsten > Sorry for the late response - got swamped with work for a bit. I'd much prefer the approach I've been going with, mostly since I don't usually export my notes and mostly view them in org-mode. I'll work on the patch tonight - should send a patch either later tonight or tomorow. Thanks, Nathaniel Flath ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
I don't think this is what I had in mind. What you suggest seems to apply for bulleted lists, and sorting the titles of those alphabetically. I'm trying to implement lists of the form: a. Item 1 b. Item 2 c. Item 3 That work the same as lists like: 1. Item 1 2. Item 2 3. Item 3 Correct me if I'm misinterpreting you. Thanks, Nathaniel Flath On Mon, Oct 4, 2010 at 5:07 PM, Sebastian Rose wrote: > > Sorry for not following this thread closely. > > But from what I read, I thought it might be better to have a _command_ > to sort existing lists alphabetically? > > That way, there is nothing that has to be "turned on" globally, that > could intefere with Org mode's syntax. > > > Excuse me, if that's of topic or already discussed. > > > Sebastian > > ___ > 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 > ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Carsten, If you think this is acceptable I'll start working on it. Thanks, Nathaniel Flath On Wed, Sep 29, 2010 at 10:46 AM, Nicolas Goaziou wrote: > Hello, > >>>>>> Carsten Dominik writes: > >> Or, alternatively, put it in with an option to turn it on (default >> off, I think). And maybe we should after all limit it to a single >> character to avoid confusion. Yes, I do realise that I asked for >> several characters - but I am learning... > > What will then happen if the user is cycling bullets in a 100+ items > list and hits alphabetic bullets? Besides undoing that move, there's > nothing much that could be done then. Further cycling would become > impossible. > > One idea would be to count items before cycling, and skipping > alphabetic bullets for lists above 26 items. It has to be carefully > implemented, as it could get very heavy on computations with large > lists. > > Also, inserting new items in an alphabetical list should check if the > 27th item has been reached and change bullets back to numbers if > needed. > > I'm sure there are others subtleties that I can't think of right now. > > Regards, > > -- Nicolas > ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
I'd be fine with either (or both) of these, and can code it up once we decide. I find it unlikely that I'd use an alphabetical list of size more than 26, which is why I only had one character to begin with. Thanks, Nathaniel Flath On Wed, Sep 29, 2010 at 8:49 AM, Carsten Dominik wrote: > > Or, alternatively, put it in with an option to turn it on (default off, I > think). > And maybe we should after all limit it to a single character to avoid > confusion. > Yes, I do realise that I asked for several characters - but I am learning... > > - Carsten > > >> >> - Carsten >> > > ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
> But, there is apparently one major drawback, as I said in a previous > post. If the line starts with a word followed by a dot or a > parenthesis, Org will see a bullet there. This is bad news because the > following line will be indented, or a M-RET will delete the word, > replacing it with a) or a. > > Regards, > > -- Nicolas > Yes, this happens - it's not something that comes up during my normal usage, so I didn't notice. Can you think of a way to determine if this is the case vs. a list is actually wanted? Thanks, Nathaniel Flath ___ 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
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Hey, I gave another shot at this, now that my computer is no longer dead. I believe it fixes the issues described earlier - let me know of any feedback. (Also - I don't know how to get GMail to attach this as anything other than application/octet-stream, so the text is in the message as well. Nathaniel Flath Attachment: diff --git a/lisp/org-list.el b/lisp/org-list.el index d9fc24e..88d5a9b 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -287,14 +287,14 @@ It depends on `org-empty-line-terminates-plain-lists'." "Return the correct regular expression for plain lists. If GENERAL is non-nil, return the general regexp independent of the value of `org-plain-list-ordered-item-terminator'." - (cond - ((or general (eq org-plain-list-ordered-item-terminator t)) -"\\([ \t]*\\([-+]\\|\\([0-9]+[.)]\\)\\)\\|[ \t]+\\*\\)\\([ \t]+\\|$\\)") - ((= org-plain-list-ordered-item-terminator ?.) -"\\([ \t]*\\([-+]\\|\\([0-9]+\\.\\)\\)\\|[ \t]+\\*\\)\\([ \t]+\\|$\\)") +(cond + ((or general (eq org-plain-list-ordered-item-terminator t)) + "\\([ \t]*\\([-+]\\|\\([0-9A-Za-z]+[.)]\\)\\)\\|[ \t]+\\*\\)\\( \\|$\\)") + ((= org-plain-list-ordered-item-terminator ?.) + "\\([ \t]*\\([-+]\\|\\([0-9A-Za-z]+\\.\\)\\)\\|[ \t]+\\*\\)\\( \\|$\\)") ((= org-plain-list-ordered-item-terminator ?\)) -"\\([ \t]*\\([-+]\\|\\([0-9]+)\\)\\)\\|[ \t]+\\*\\)\\([ \t]+\\|$\\)") - (t (error "Invalid value of `org-plain-list-ordered-item-terminator'" +"\\([ \t]*\\([-+]\\|\\([0-9A-Za-z]+)\\)\\)\\|[ \t]+\\*\\)\\( \\|$\\)") +(t (error "Invalid value of `org-plain-list-ordered-item-terminator'" (defconst org-item-beginning-re (concat "^" (org-item-re)) "Regexp matching the beginning of a plain list item.") @@ -530,7 +530,7 @@ List ending is determined by the indentation of text. See (save-excursion (goto-char (match-end 0)) ;; Ignore counter if any - (when (looking-at "\\(?:\...@\\(?:start:\\)?[0-9]+\\][ \t]*\\)?") + (when (looking-at "\\(?:\...@\\(?:start:\\)?[0-9A-Za-z]+\\][ \t]*\\)?") (goto-char (match-end 0))) (looking-at regexp @@ -1135,11 +1135,11 @@ bullet string and bullet counter, if any." (list (point-at-bol) (org-get-indentation) (progn -(looking-at "^[ \t]*\\([-+*0-9.)]+[ \t]+\\)") +(looking-at "^[ \t]*\\([-+*0-9A-Za-z.)]+[ \t]+\\)") (match-string 1)) (progn (goto-char (match-end 0)) -(and (looking-at "\...@\\(?:start:\\)?\\([0-9]+\\)\\]") +(and (looking-at "\...@\\(?:start:\\)?\\([0-9A-Za-z]+\\)\\]") (match-string 1)) (defun org-list-struct (begin end top bottom &optional outdent) @@ -1259,8 +1259,10 @@ This function modifies STRUCT." (let ((counter (nth 3 item)) (bullet (org-list-bullet-string (nth 2 item (cond - ((and (string-match "[0-9]+" bullet) counter) + ((and (string-match "[0-9A-Za-z]+" bullet) counter) (replace-match counter nil nil bullet)) + ((string-match "[A-Za-z]+" bullet) +(replace-match "a" nil nil bullet)) ((string-match "[0-9]+" bullet) (replace-match "1" nil nil bullet)) (t bullet) @@ -1268,7 +1270,7 @@ This function modifies STRUCT." (setcdr item (list (nth 1 item) bullet (nth 3 item) (get-bul (lambda (item bullet) (let* ((counter (nth 3 item))) - (if (and counter (string-match "[0-9]+" bullet)) + (if (and counter (string-match "[0-9A-Za-z]+" bullet)) (replace-match counter nil nil bullet) bullet (fix-bul @@ -1582,13 +1584,50 @@ It determines the number of whitespaces to append by looking at " "))) nil nil bullet 1))) +(defun org-increment-string (str cap) + "Increments str (a->a, b->b, z->aa, aa->ab etc). If cap is non-nil, then + the letters are capitalized." + (let ((res (org-convert-num-to-alpha-str + (1+ (org-convert-alpha-str-to-num str 1 (length str) cap)) cap)) + (z (if cap ?Z ?z)) + (b (if cap ?B ?b)) + (a (if cap ?A ?a))) +(if (and(= (string-to-char str) z) +(= (string-to-char res) b)) +(concat (if cap "A" "a") (substring res 1)) + (concat (make-string (- (length str) (length res)) a) res + +(defun org-conver
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
I was going to fix the issues described in the first reply - not
enough items in particular - and resubmit soon. I got a bit
distracted by finals. I'll see if I can figure out the export
problem, as well.
Thanks,
Nathaniel Flath
On Fri, Aug 27, 2010 at 5:44 AM, Jacob Mitchell
wrote:
>
>
> On Fri, Aug 27, 2010 at 6:53 AM, Bernt Hansen wrote:
>>
>> Carsten Dominik writes:
>>
>> > On Jul 29, 2010, at 10:27 PM, Nathaniel Flath wrote:
>> >
>> >> Hello all,
>> >>
>> >> One thing that had been bugging me was the inability to have an
>> >> ordered list of the form:
>> >>
>> >> a. Item 1
>> >> b. Item 2
>> >> c. Item 3
>> >>
>> >> The following patch enables this, with lists going from a-z and A-Z.
>> >> Let me know if there are any issues with it.
>> >
>> > Hi,
>> >
>> > I am not really sure we need these. They cause problems when lists get
>> > really long - also you patch does not further than "z", after that I
>> > get "{".
>> >
>> > Furthermore the export backends implement their own numbering
>> > rules anyway. So it seems to me that we do not need this addition.
>> >
>> > Any other votes here?
>>
>> I'm not currently missing this feature. I think it definitely would
>> have to handle more entries if this was to be included in org-mode.
>
> I agree, that would be nice.
>
>>
>> Maybe going something like
>>
>> a.
>> b.
>> ...
>> z.
>> aa.
>> ab.
>> ...
>> az.
>> ba.
>> bb.
>> ...
>> zz.
>> ... and if you really need more entries than that (unlikely) you can
>> do
>> aaa.
>> aab.
>> ...
>> and just keep going indefinitely.
>
> As a practical matter we should consider whether it's worth making a
> non-terminating sequence that can be handled by the exporters. LaTeX's
> enumerate package doesn't like going beyond (z):
>
> \documentclass[letterpaper]{article}
> \usepackage{enumerate}
>
> \begin{document}
> \begin{enumerate}[(z)]
> \item
> ...
> \end{document}
>
> The items beyond the 26th are mapped to "()".
>
> Of course there are going to be ways around these issues, but the question
> is whether it's desirable enough to implement and maintain that. Either way
> is fine with me--I'm new on the mailing list and haven't done any
> development for org-mode yet.
>
> -Jake
>>
>> -Bernt
>>
>> ___
>> 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
>
>
> ___
> 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
>
>
___
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
[Orgmode] [PATCH] Alphabetical ordered lists
Hello all, One thing that had been bugging me was the inability to have an ordered list of the form: a. Item 1 b. Item 2 c. Item 3 The following patch enables this, with lists going from a-z and A-Z. Let me know if there are any issues with it. Thanks, Nathaniel Flath alpha-lists.patch Description: Binary data ___ 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
[Orgmode] Re: [PATCH] only display a scheduled item if it is due today or in the past
Yes, this patch is primarily for weekly agendas - it changes when items are displayed to be the same as having a style of 'habit, while also allowing to do it for non-recurring items. org-agenda-repeating-timestamp-show-all doesn't do quite what I want - I want the item to not show on my weekly agenda if it isn't scheduled for today, where that will make it show a maximum of once. I'd be wiling to write a personal skip function - I mainly did it this way because I was emulating org-habit, and then I thought it may be useful to other people. This is what I'll fall back to if you decide not to install this patch. Thanks, Nahtaniel Flath On Sat, May 22, 2010 at 12:50 AM, Matt Lundin wrote: > Nathaniel Flath writes: > > > On May 2, 2010, at 7:37 PM, Nathaniel Flath wrote: > > > > One thing I've wanted from org-mode is the ability to have > > certain items 'hidden' from the agenda until the day they are > > scheduled - this patch implements this for all properties who > > have a STYLE property of 'hidden'. I ended up implementing > > this(the patch is attached), and thought I'd contribute it to > > org-mode. If you have any comments, please let me know. > > > The primary use I have for it is essentially what Nathan said - it > > controls display or recurring items to be the same as habits, with the > > exception of not displaying the habit graph. > > To avoid seeing future instances of recurring tasks, you can set the > variable org-agenda-repeating-timestamp-show-all to nil. > > > I also use it when scheduling items that can't be started before a > > certain date. For example, I recently got a note that my tax return > > was being inverstigated and that I should contact the IRS in 30 days. > > Now, I schedule this item for 30 days from now, but in 23 days it > > starts showing up in my weekly agenda, even though there's nothing that > > can be done about it at that point. I'd much rather have it only > > display when it can actually be worked on. > > I'm still a bit confused about this patch. By definition, scheduled > items do not appear on the agenda until the day on which they are > scheduled. As I understand it, this patch is primarily for weekly > agendas---i.e., to prevent items scheduled on Friday from appearing > under the Friday slot until it is indeed Friday. In that case, why not > use the daily agenda instead of the weekly agenda? > > Would it perhaps be better to write a personal skip function that > handles this instead of hard-coding another test in org-agenda.el? > > Best, > Matt > ___ 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
Re: [Orgmode] [PATCH] only display a scheduled item if it is due today or in the past
Sorry for the late reply - this thread was filtered incorrectly. The primary use I have for it is essentially what Nathan said - it controls display or recurring items to be the same as habits, with the exception of not displaying the habit graph. I also use it when scheduling items that can't be started before a certain date. For example, I recently got a note that my tax return was being inverstigated and that I should contact the IRS in 30 days. Now, I schedule this item for 30 days from now, but in 23 days it starts showing up in my weekly agenda, even though there's nothing that can be done about it at that point. I'd much rather have it only display when it can actually be worked on. Let me know if you have any more questions. Thanks, Nathaniel Flath On Thu, May 13, 2010 at 1:36 AM, Carsten Dominik wrote: > Hi Nathaniel, > > I am not yet sure about the purpose of this functionality. > Items that are scheduled only show up in the agenda on the day when they > are scheduled. What is the added value? Please explain, with an example. > > Thanks. > > - Carsten > > > On May 2, 2010, at 7:37 PM, Nathaniel Flath wrote: > > Hello, >> One thing I've wanted from org-mode is the ability to have certain items >> 'hidden' from the agenda until the day they are scheduled - this patch >> implements this for all properties who have a STYLE property of 'hidden'. >> I ended up implementing this(the patch is attached), and thought I'd >> contribute it to org-mode. If you have any comments, please let me know. >> >> Thanks, >> Nathaniel Flath >> ___ >> >> 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 >> > > - Carsten > > > > ___ 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
[Orgmode] org-entities-user
Hello, I've been setting up org-entities-user with a few custom symbols, and managed to get a few aliases for items already in org-entities, but i'm a bit stuck on adding new items - specifically, the mathbb versions of Z and R (the symbols for the sets of integers and reals). I can't seem to find the UTF-8, latin-1, or HTML encodings of these entities - and I'm not sure how to input the utf-8 or latin-1 even if I do. Does anyone know how to do this? Thanks, Nathaniel Flath ___ 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
[Orgmode] [BUG] Shift-left and Shift-right reset time to 0:00
Whenever I am on a timestamp with a time that isn't zero-filled, shift-left and right zero the time. for example: <2010-05-08 Sat 2:00> becomes: <2010-05-09 Sun 00:00> This does not occur for stamps of the form: <2010-05-08 Sat 02:00> Thanks, Nathaniel Flath ___ 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
[Orgmode] [PATCH] only display a scheduled item if it is due today or in the past
Hello, One thing I've wanted from org-mode is the ability to have certain items 'hidden' from the agenda until the day they are scheduled - this patch implements this for all properties who have a STYLE property of 'hidden'. I ended up implementing this(the patch is attached), and thought I'd contribute it to org-mode. If you have any comments, please let me know. Thanks, Nathaniel Flath diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 2b56cb6..c7a07c4 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4697,6 +4697,9 @@ FRACTION is what fraction of the head-warning time has passed." (and (not todayp) org-habit-show-habits-only-for-today)) (throw :skip nil)) + (if (and (string= "hidden" (org-entry-get (point) "STYLE")) + (< today d2)) + (throw :skip nil)) (if (and (or (eq t org-agenda-skip-scheduled-if-deadline-is-shown) (and org-agenda-skip-scheduled-if-deadline-is-shown ___ 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
[Orgmode] BUG: org-insert-link doesn't use ido completion when org-completion-use-ido is t
I'd really like to be able to use ido to insert links, but even though I have org-completion-use-ido set to t this does not occur. This seems to be because of org-insert-link in org.el, line8061: (let ((org-completion-use-ido nil) However, just removing this causes org-insert-link to not work. ___ 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
[Orgmode] Remove scheduled date when switch TODO states
Hello, I have a todo state, PENDING, that I organize tasks that I cannot perform immediately. Is there a way to configure org-todoconfigure so that when a task is switched to PENDING, if it has a scheduled date that date is removed? Thanks, Nathaniel Flath ___ 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
[Orgmode] Hiding items on agenda until day they are scheduled
Hello, Is there a property that will hide an item from the agenda until the day it is scheduled? I don't want to do this globally, just for specific items. Setting the style to 'habit' does this, but I was wondering if there was a more semantically-correct way. Thanks, Nathaniel Flath ___ 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
[Orgmode] Org-depends: schedule X days after last completion
Hello, using the org-depends package, is there any way to set the next task to be scheduled a certain number of days after the current one is finished? Thanks, Nathaniel Flath ___ 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
[Orgmode] org-babel and source highlighting
Is there a way to get org-babel to highlight the source blocks embedded in your document in the natural language's source? All the source shows as grey for me. Thanks, Nathaniel Flath ___ 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
[Orgmode] org-refile to top-level heading
Is there a way to use org-refile to refile an item as a top-level heading in some file? Looking into this, there only seems to be a way to file as a subheading. Thanks, Nathaniel Flath ___ 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
[Orgmode] [PATCH] Close calendar buffer after scheduling an item
If you schedule an item with org-schedule, the *Calendar* buffer will stay around. This also occurs with org-deadline, and any other functions that use org-read-date. The patch attached just closes this buffer once the date is read. I've filled out the FSF forms already, so copyright shouldn't be a problem. Thanks, Nathaniel Flath diff --git a/lisp/org/org.el b/lisp/org/org.el index 325a524..8206cf2 100644 --- a/lisp/org/org.el +++ b/lisp/org/org.el @@ -12970,125 +12970,127 @@ the user. PROMPT can overwrite the default prompt. DEFAULT-TIME is the time/date that is used for everything that is not specified by the user." (require 'parse-time) - (let* ((org-time-stamp-rounding-minutes - (if (equal with-time '(16)) '(0 0) org-time-stamp-rounding-minutes)) - (org-dcst org-display-custom-times) - (ct (org-current-time)) - (def (or org-overriding-default-time default-time ct)) - (defdecode (decode-time def)) - (dummy (progn - (when (< (nth 2 defdecode) org-extend-today-until) - (setcar (nthcdr 2 defdecode) -1) - (setcar (nthcdr 1 defdecode) 59) - (setq def (apply 'encode-time defdecode) - defdecode (decode-time def) - (calendar-frame-setup nil) - (calendar-move-hook nil) - (calendar-view-diary-initially-flag nil) - (view-diary-entries-initially nil) - (calendar-view-holidays-initially-flag nil) - (view-calendar-holidays-initially nil) - (timestr (format-time-string - (if with-time "%Y-%m-%d %H:%M" "%Y-%m-%d") def)) - (prompt (concat (if prompt (concat prompt " ") "") - (format "Date+time [%s]: " timestr))) - ans (org-ans0 "") org-ans1 org-ans2 final) - -(cond - (from-string (setq ans from-string)) - (org-read-date-popup-calendar - (save-excursion - (save-window-excursion - (calendar) - (calendar-forward-day (- (time-to-days def) - (calendar-absolute-from-gregorian -(calendar-current-date - (org-eval-in-calendar nil t) - (let* ((old-map (current-local-map)) - (map (copy-keymap calendar-mode-map)) - (minibuffer-local-map (copy-keymap minibuffer-local-map))) - (org-defkey map (kbd "RET") 'org-calendar-select) - (org-defkey map (if (featurep 'xemacs) [button1] [mouse-1]) - 'org-calendar-select-mouse) - (org-defkey map (if (featurep 'xemacs) [button2] [mouse-2]) - 'org-calendar-select-mouse) - (org-defkey minibuffer-local-map [(meta shift left)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-backward-month 1 - (org-defkey minibuffer-local-map [(meta shift right)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-forward-month 1 - (org-defkey minibuffer-local-map [(meta shift up)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-backward-year 1 - (org-defkey minibuffer-local-map [(meta shift down)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-forward-year 1 - (org-defkey minibuffer-local-map [?\e (shift left)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-backward-month 1 - (org-defkey minibuffer-local-map [?\e (shift right)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-forward-month 1 - (org-defkey minibuffer-local-map [?\e (shift up)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-backward-year 1 - (org-defkey minibuffer-local-map [?\e (shift down)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-forward-year 1 - (org-defkey minibuffer-local-map [(shift up)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-backward-week 1 - (org-defkey minibuffer-local-map [(shift down)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-forward-week 1 - (org-defkey minibuffer-local-map [(shift left)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-backward-day 1 - (org-defkey minibuffer-local-map [(shift right)] - (lambda () (interactive) - (org-eval-in-calendar '(calendar-forward-day 1 - (org-defkey minibuffer-local-map ">" - (lambda () (interactive) - (org-eval-in-calendar '(scroll-calendar-left 1 - (org-defkey minibuffer-local-map "<" - (lambda () (interactive) - (org-eval-in-calendar '(scroll-calendar-right 1 - (run-hooks 'org-read-date-minibuffer-setup-hook) - (unwind-protect - (progn - (use-local-map map) - (add-hook 'post-command-hook 'org-read-date-display) - (setq org-ans0 (read-string prompt default-input - 'org-read-date-history nil)) - ;; org-ans0: from prompt - ;; org-ans1: from mouse click - ;; org-ans2: from calendar motion - (setq ans (concat org-ans0 " &quo
[Orgmode] org-archive-subtree keep structure
Hello, Is there a way to get org-archive-subtree to keep the tree structure in the archive file? this information is currently just added to the :ARCHIVE_OLPATH in the archive file; is there an option to get it to construct the tree instead? Thanks, Nathaniel Flath ___ 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
[Orgmode] Scheduling an already-scheduled item
Hello, Is there a way to easily postpone an item for several days in the Agenda view? For example, if I have a item scheduled on Sunday and wanted to pus it to Monday, is there a command where I could enter '+1d' and it would offset from the scheduled time instead of the current date? Thanks, Nathaniel Flath ___ 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
[Orgmode] Exporting Agenda to HTML
Hello, I would like to be able to export my agenda as a set of files corresponding to each org-file in org-agenda-files, as an 'agenda' html file that looks like the agenda, and has its entries hyperlinked to the relevant entry in the relevant file - much like the agenda works in emacs, where pressing 'enter' on a line will take you to the specific entry. Is there a way to do this? Thanks, Nathaniel Flath ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
