Re: Bug: Bug: org-clock commands spawn drawer outside of narrowing [9.2.1 (9.2.1-2-gc6d37c-elpaplus @ /home/zaeph/.emacs.d/elpa/org-plus-contrib-20190204/)]

[Leo Vivier <leo.vivier@gmail.com>]

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 <mail@nicolasgoaziou.fr> writes:

> Leo Vivier <leo.vivier@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