From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Vivier 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 Message-ID: <87o97dxwsf.fsf@hidden> References: <87pnruq81e.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:36336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guZAH-0003dX-Qc for emacs-orgmode@gnu.org; Fri, 15 Feb 2019 03:48:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1guZAE-0008No-Qp for emacs-orgmode@gnu.org; Fri, 15 Feb 2019 03:48:09 -0500 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:36062) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1guZAE-0008MY-K1 for emacs-orgmode@gnu.org; Fri, 15 Feb 2019 03:48:06 -0500 Received: by mail-wm1-x333.google.com with SMTP id j125so8766716wmj.1 for ; Fri, 15 Feb 2019 00:48:06 -0800 (PST) In-Reply-To: <87pnruq81e.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: emacs-orgmode@gnu.org Hello, I=E2=80=99d forgotten to CC the list in my previous message, so I=E2=80=99v= e included all the context from our two previous emails. Nicolas Goaziou writes: > Leo Vivier writes: > >> You=E2=80=99re right, that=E2=80=99s 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.=20 > > 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=E2=80= =99m >> 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=E2=80=99m encountering, you=E2=80=99re right, but I have two issues with this solutio= n: - =E2=80=98org-narrow-to-subtree=E2=80=99 does not do that by default (alth= ough it=E2=80=99d probably be easy to patch in a conditional behaviour). - The included newline isn=E2=80=99t protected, meaning that the user can d= elete it without warning. MWE: --------------------------------[START]-------------------------------- * Inbox ** Captured task * Tree ---------------------------------[END]--------------------------------- - Narrow to =E2=80=98* Captured task^J=E2=80=99 (i.e. including the new-lin= e at eol). This is the state we=E2=80=99d have with a patched org-narrow-to-subtree. - =E2=80=98(end-of-buffer)=E2=80=99 - =E2=80=98(delete-char 1)=E2=80=99 - =E2=80=98(widen)=E2=80=99 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=E2=80=99s something s/he=E2=80=99d = ever want to do. This goes back to the tentative solution I=E2=80=99ve mentioned in my previous email. >> I=E2=80=99m 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 >> =E2=80=98org-agenda-tree-to-indirect-buffer=E2=80=99. 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=E2=80=99t feel right that the clock-t= able >> 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=E2=80=99ll 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 =E2=80=98org-narrow-to-subtree=E2=80=99 or >> =E2=80=98org-agenda-tree-to-indirect-buffer=E2=80=99 >> 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 =E2=80=98widen=E2=80=99 inside commands like =E2=80= =98org-capture-finalize=E2=80=99=20 >> 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=E2=80=99t respected since the drawer i= s not >>>> visible >>> >>> This is a bug. I fixed it. >> >>Thank you for the fix. Thanks for your help. Best, --=20 Leo Vivier English Studies & General Linguistics Master Student, English Department Universit=C3=A9 Rennes 2