all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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

       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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.