Hello, I’d forgotten to CC the list in my previous message, so I’ve included all the context from our two previous emails.
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Leo Vivier <leo.viv...@gmail.com> writes: > >> You’re right, that’s the behaviour we would expect from M-RET. However, >> with C-RET, the new heading should respect the content of the tree at >> point. > > I disagree. C-RET is expected to move point, so it should obviously > operate on the accessible part of the buffer. > > The only other option, AFAICT, would be to automatically widen the > buffer, which would be most surprising. > >> Even though this is an expected behaviour with narrowed buffers, maybe >> we could find a way to work around this limitation. The reason I’m >> suggesting this is because I often find myself dealing with 1-line tree >> which are meaningful parts of my documents. > > Then you ought to include the final newline character in the narrowed > part of the buffer. It mitigate some issues you are encountering. Including the final newline mitigates most of the problems I’m encountering, you’re right, but I have two issues with this solution: - ‘org-narrow-to-subtree’ does not do that by default (although it’d probably be easy to patch in a conditional behaviour). - The included newline isn’t protected, meaning that the user can delete it without warning. MWE: --------------------------------[START]-------------------------------- * Inbox ** Captured task * Tree ---------------------------------[END]--------------------------------- - Narrow to ‘* Captured task^J’ (i.e. including the new-line at eol). This is the state we’d have with a patched org-narrow-to-subtree. - ‘(end-of-buffer)’ - ‘(delete-char 1)’ - ‘(widen)’ Result: --------------------------------[START]-------------------------------- * Inbox ** Captured task*Tree ---------------------------------[END]--------------------------------- Since the line is visible in the buffer, it follows that the user is able to delete it, but I wonder if that’s something s/he’d ever want to do. This goes back to the tentative solution I’ve mentioned in my previous email. >> I’m aware that this problem only affects people who do not have >> empty-lines between their trees. However, 90% of the time, those 1-line >> trees are the result of simple org-capture templates on which no work >> has been done. When the time comes, I access them from the agenda with >> ‘org-agenda-tree-to-indirect-buffer’. I have no way to know that the >> buffer is narrowed char-wise rather than line-wise. So, when >> clocking-in on that tree, it doesn’t feel right that the clock-table >> should be spawned outside of the view-port. >> > > I'm not sure about "this problem" you're talking about. You are > encountering different "problems". Some are certainly genuine bugs, but > not all of them, per above. In any case, please report them precisely so > we can see if there is something to fix, piece-wise. I’ll make sure to specify those behaviours, then. >> Since the problem only happens with 1-line trees, a tentative solution >> could be the following: >> - When evaluating ‘org-narrow-to-subtree’ or >> ‘org-agenda-tree-to-indirect-buffer’ >> 1. Check whether the tree being considered is a 1-line tree. >> 2. If t: Add a newline at the end of the heading. >> (This bypasses the narrowing limitation.) >> 3. Store the result of the check in a local variable. >> - When evaluating ‘widen’ inside commands like ‘org-capture-finalize’ >> 1. Check whether the local variable mentioned above is set and true. >> 2. If t: Remove newline at the end of the narrowed buffer if it still >> exists. >> >> If this solution seems sound, I could work on it and submit a patch. >> >>>> - `org-clock-out-when-done` isn’t respected since the drawer is not >>>> visible >>> >>> This is a bug. I fixed it. >> >>Thank you for the fix. Thanks for your help. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
