[O] Agenda bug: q x keys are swapped?
It seems that org-agenda-quit (q) and org-agenda-exit (x) are swapped. 'q' wants to close my the buffers loaded for the agenda. Strange. I'm running 7.9.2 on emacs 24.2.1 on OS X Thanks, Huy
[O] Agenda bug: 'now' is on the wrong day
It's 1:17am over here. And when I pop up the agenda and then hit 'l', it says: 1:17.. now - - - - - - - - - - - - - - - - - - - - - - - - - but it's on the wrong day: yesterday. I'm running 7.9.2 on emacs 24.2.1 on OS X Thanks, Huy
[O] Agenda bug: time conflict between headline and scheduled date
task Reply-To: Hi, there's a bug when I have a task like this: * Test [2012-12-26 Wed 22:24] SCHEDULED: 2012-12-25 Wed Note that the inactive date has a time in the headline, but the schedule date doesn't. When I run the agenda, I get this: Tuesday25 December 2012 GTD:22:24.. Scheduled: Test [2012-12-26 Wed 22:24] The time should not be extracted from the non-scheduled timestamp, right? I'm running 7.9.2 on emacs 24.2.1 on OS X Thanks, Huy
Re: [O] Bug: inline images for filenames with spaces
On Thu, Jun 30, 2011 at 05:41:55PM +0200, Bastien wrote: Hi Huy, Huy list-orgm...@reml.org writes: inline image display doesn't seem to work for image links with spaces in them. The attached patch fixes this. Please confirm and also take the time to check that there is no side-effects -- especially wrt the exporter. Sorry, it took me long to get back. I confirm that the current repo fixed it, bt I can't confirm exporting. I don't know how to do any exporting yet. Thanks for the fix! Huy
Re: [O] Bug: inline images for filenames with spaces
I'm not exporting. I'm just doing C-c C-x C-v to display the inline images within emacs. On Wed, Jun 29, 2011 at 01:34:36PM +0200, Manuel Giraud wrote: Huy list-orgm...@reml.org writes: Example: [[file:img/test.png]] will display inline [[file:img/test copy.png]] won't Just tested on the same emacs version and few minutes old org-mode and both works for me. How do you export? Do you have some special settings? -- Manuel Giraud
[O] Bug: inline images for filenames with spaces
Hi, inline image display doesn't seem to work for image links with spaces in them. However, clicking on the image links does work: a window shows the image. Example: [[file:img/test.png]] will display inline [[file:img/test copy.png]] won't I'm using the latest org-mode sources in git as of a few minutes ago on: GNU Emacs 23.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of 2011-03-10 on black.porkrind.org Thanks, Huy
Re: [O] Semantics of 'C-c -' and massively-indented lists
On Sat, May 28, 2011 at 02:29:07PM +0200, Nicolas Goaziou wrote: Hello, Huy list-orgm...@reml.org writes: The effects of converting from headline to list with 'C-c -' and back to 'C-c *' don't behave as I'd expect. The indentation levels seem all wrong, no matter how you look at it. I have pushed a patch that should go in the right direction. See below. What I would like is a LEVEL=1 list, properly indented along with the rest of the body text. If org-adapt-indentation is t, then I would expect to see: * Headline - Converted Line where the '-' is aligned with the 'H' of the above headline, at the same column where any body text would start if I hit TAB in a line after Headline (if there were no list). And if org-adapt-indentation is nil, then I would expect to see: * Headline - Converted Line Fixed. In fact, if I take the list and I try to convert it back to a headline with 'C-c *', it doesn't even matter how many spaces there are in front of the '-': it's always converted to a LEVEL=5 headline because the parent is LEVEL=4: This is the intended behavior. Things look especially weird when org-indent-mode is turned on, since you have a mixture of visual indentation and hard space indentation. I would expect a 'C-c -' to insert no hard spaces at all and leave everything in column 0 and let the visual-line-mode adjust the display. Fixed. It's the same as the first case, as org-indent-mode sets org-adapt-indentation to nil. Now, what happens when we convert the previous example back by using 'C-c *'? We get a LEVEL-4 headline. * Headline LEVEL=3 - Converted Line LEVEL=4 becomes * Headline LEVEL=3 *** Converted Line LEVEL=4 The operations are not symmetric because somehow the LEVEL was incremented. Operations are not symmetric because lists and headlines are not equivalent objects. In most cases, 'C-c *' acts sanely. It acts weird when there is no Headline above a list item and you try to convert to a Headline. Again, in 'odd' mode. - Converted Line LEVEL=1 (alone without parent) becomes ** Converted Line LEVEL=1.5 (alone without parent) Yes, that's a decimal. It's trying to hide in the cracks. Fixed. Please report back if something is still wrong. Thank you. Perfect behavior! Exactly what I was expecting. The only problem is a typo 'skip-blank' instead of 'skip-blanks' Thanks a lot for the quick turnaround! Regards, -- Nicolas Goaziou
Re: [O] Semantics of 'C-c -' and massively-indented lists
On Sat, May 28, 2011 at 07:09:06AM -0700, Huy wrote: On Sat, May 28, 2011 at 02:29:07PM +0200, Nicolas Goaziou wrote: Fixed. Please report back if something is still wrong. Thank you. Perfect behavior! Exactly what I was expecting. The only problem is a typo 'skip-blank' instead of 'skip-blanks' Thanks a lot for the quick turnaround! Actually, I found a few more problems Multiple Lines ~~ I had forgotten to test when invoking 'C-c -' on multiple lines. If I have (with oddeven and org-adapt-indentation on) the following: ** Headline 2 ** Converting 2 *** Converting 3 * Converting 1 ** Converting 2 *** Converting 3 and I try to do 'C-c -' on the 5 bottom lines, I get: ** Headline 2 - Converting 1 - Converting 2 - Converting 1 - Converting 1 - Converting 2 I would hope to get the following instead: ** Headline 2 - Converting 1 - Converting 2 - Converting 1 - Converting 2 - Converting 3 Whenever possible, the converted lines should preserve their relative levels with their parent. In the above example, we have 2 subtrees that should be preserved separately. Of course, we can't keep all 5 items with levels relative to each other, otherwise we'd get the nonsensical effect: - orphan - parent But in other cases, entire subtrees can be preserved. Strange region behavior and 'C-c *' ~~~ When highlighting a region and then applying 'C-c -', all the lines that have at least one character highlighted (anywhere on the line) will be converted. That's good and as expected. But the same doesn't happen with 'C-c *'. There, it actually matters where the region starts/ends in the line. For example, if you have ** Headline 2 - Converting 1 If you triple-mouse-click Converting 1 or if you just single-click the cursor on Converting 1, then 'C-c *' will convert the line fine. However, if you only select any of the letters on that line, e.g. the letter 'v', and then 'C-c *', then you get this: ** Headline 2 *** Con verting 1 I have other problems that involve vimpulse and its visual mode, but I won't bother you with that :) Thanks, Huy
[O] Semantics of 'C-c -' and massively-indented lists
should become part of the body of the above headline, no matter what. And when we go back to 'C-c *', what makes sense is for the line to become a sub-heading of Headline, as is the current behavior. 'C-c *' fringe case ~~~ In most cases, 'C-c *' acts sanely. It acts weird when there is no Headline above a list item and you try to convert to a Headline. Again, in 'odd' mode. - Converted Line LEVEL=1 (alone without parent) becomes ** Converted Line LEVEL=1.5 (alone without parent) Yes, that's a decimal. It's trying to hide in the cracks. Summary ~~~ 'C-c *' mostly works right. 'C-c -' has strange behavior in all display styles, especially 'oddeven' and org-indent-mode modes and even in 'odd' mode. The resulting indentation is not useful. Thanks for responding, Huy
