From: Leo Vivier <leo.vivier@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org
Subject: 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/)]
Date: Fri, 15 Feb 2019 09:48:00 +0100 [thread overview]
Message-ID: <87o97dxwsf.fsf@hidden> (raw)
In-Reply-To: <87pnruq81e.fsf@nicolasgoaziou.fr>
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
next parent reply other threads:[~2019-02-15 8:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87pnruq81e.fsf@nicolasgoaziou.fr>
2019-02-15 8:48 ` Leo Vivier [this message]
2019-02-11 18:44 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
2019-02-14 14:53 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o97dxwsf.fsf@hidden \
--to=leo.vivier@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).