Re: [BUG] Shift-up/down move the cursor to end of timestamp
On Wed, 7 Dec 2022 at 12:54, Ihor Radchenko wrote: > > Daniel Clemente writes: > > > Using a file with just one header: > > > > * something > > :CLOCK: > > CLOCK: [2022-12-01 Thu 17:15]--[2022-12-01 Thu 17:30] => 0:15 > > :END: > > > > If I put the cursor on the end timestamp (on the 3 of 17:30) and press > > shift+up or shift-down, the timestamp is correctly adjusted by 5 minutes, > > but the cursor jumps some characters to the right and stays at the right of > > ] > > It should stay on the same character (the 3), so that I can keep adjusting > > the minutes with shift-up/down > > Thanks for reporting! > Fixed on bugfix. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4dddbc143 I, too, was affected by this bug, and, with the release of org-mode 9.6.1, can confirm that it has been fixed. However, the same problem (cursor is positioned after closing bracket) occurs with the related commands org-shiftcontrolup and org-shiftcontroldown. (For completeness: in 9.6.0 they were even slightly more broken in that they shifted the timestamps in different directions.) Johannes
Re: org-babel prepends <> expansions with the prefix of the <>? Can this be turned off?
Having re-read Vladimir's original question, it looks like I may have misunderstood it at first. Now I'm wondering: What's the use case for referencing a code block but commenting out the first line? On Tue, 25 Feb 2020 at 09:00, Johannes Dahl wrote: > > Hi, > > That's a fun coincidence, I ran into this behaviour a couple of days > ago as well. For anyone wondering why one would want to comment out > their noweb tags but still expect them to result in uncommented code > expansion: if one is to edit a source block containing Noweb tags, the > emacs mode for that programming language might interpret those tags in > an unexpected way and give a messy result, e.g. in my case with > LilyPond, mess up the indentation of the rest of the code block. > > Luckily, Noweb tag syntax is configurable using > org-babel-noweb-wrap-start and org-babel-noweb-wrap-end. Thus, the way > I worked around this was to define, for the file containing LilyPond > code blocks, org-babel-noweb-wrap-start as "%<<", % being LilyPond's > comment symbol. But I still wonder if there is a better way. > > Cheers, > Johannes > > On Tue, 25 Feb 2020 at 04:10, Vladimir Nikishkin wrote: > > > > Hello, everyone > > > > I have the following case: > > > > #+name: test1 > > #+begin_src shell > > LINE to comment > > LINE to not comment > > #+end_src > > > > #+begin_src shell > > #<> > > #+end_src > > > > When I expand it, I get: > > #LINE to comment > > #LINE to not comment > > > > That's not entirely what I want. Can this behaviour be switched off somehow? > > > > -- > > Yours sincerely, Vladimir Nikishkin > >
Re: org-babel prepends <> expansions with the prefix of the <>? Can this be turned off?
Hi, That's a fun coincidence, I ran into this behaviour a couple of days ago as well. For anyone wondering why one would want to comment out their noweb tags but still expect them to result in uncommented code expansion: if one is to edit a source block containing Noweb tags, the emacs mode for that programming language might interpret those tags in an unexpected way and give a messy result, e.g. in my case with LilyPond, mess up the indentation of the rest of the code block. Luckily, Noweb tag syntax is configurable using org-babel-noweb-wrap-start and org-babel-noweb-wrap-end. Thus, the way I worked around this was to define, for the file containing LilyPond code blocks, org-babel-noweb-wrap-start as "%<<", % being LilyPond's comment symbol. But I still wonder if there is a better way. Cheers, Johannes On Tue, 25 Feb 2020 at 04:10, Vladimir Nikishkin wrote: > > Hello, everyone > > I have the following case: > > #+name: test1 > #+begin_src shell > LINE to comment > LINE to not comment > #+end_src > > #+begin_src shell > #<> > #+end_src > > When I expand it, I get: > #LINE to comment > #LINE to not comment > > That's not entirely what I want. Can this behaviour be switched off somehow? > > -- > Yours sincerely, Vladimir Nikishkin >
[O] Bug: Inconsistent timestamping with org-mobile-pull [8.3beta-245-g3a1fff]
When I pull changes from mobileorg where I have changed multiple todo items, I expect the state change to be logged (as it does when I change the state manually), but that happens to only on one of them. Steps to reproduce: 1. Create an org file with the following content: * test-workaround ** TODO test1 :PROPERTIES: :ID: abc77285-41e5-4694-949e-0b2bc1db1c80 :END: ** TODO test2 :PROPERTIES: :ID: 351fe9ee-0446-496b-9e35-3beb5706ed05 :END: 2. Create mobileorg.org in the appropriate place with the following content: * F(edit:todo) [[id:abc77285-41e5-4694-949e-0b2bc1db1c80][test1]] ** Old value TODO ** New value DONE ** End of edit * F(edit:todo) [[id:351fe9ee-0446-496b-9e35-3beb5706ed05][test2]] ** Old value TODO ** New value DONE ** End of edit 3. Make sure state change logging is set for at least DONE keyword and run org-mobile-pull. 4. Observe that one of the todo items now has a timestamp, whereas the other does not. I'm using Org mode from git://orgmode.org/org-mode.git (master branch) with Emacs 24.3.1 Regards, Johannes
