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 writes:
> Leo Vivier 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
