From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Vivier Subject: Re: [PATCH 1/2] Fix narrowing for 1-line subtrees Date: Tue, 19 Feb 2019 11:24:24 +0100 Message-ID: <871s44cbzb.fsf@hidden> References: <20190218002547.30325-1-leo.vivier@gmail.com> <87mumsqepg.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]:47737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gw2Zu-0007bS-1Q for emacs-orgmode@gnu.org; Tue, 19 Feb 2019 05:24:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gw2Zs-0002F3-62 for emacs-orgmode@gnu.org; Tue, 19 Feb 2019 05:24:41 -0500 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]:41526) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gw2Zr-00028W-SU for emacs-orgmode@gnu.org; Tue, 19 Feb 2019 05:24:40 -0500 Received: by mail-wr1-x443.google.com with SMTP id n2so9385167wrw.8 for ; Tue, 19 Feb 2019 02:24:30 -0800 (PST) In-Reply-To: <87mumsqepg.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, Nicolas Goaziou writes: > However, I don't think this is going into a good direction. Narrowing > should probably be the same everywhere in Emacs, including Org mode. I understand. The rationale behind this idea was that it would only modify the way narrowing works for subtrees just as AUCTeX's `LaTeX-narrow-to-environment' works for environments. That's why I didn't think it was a problem. > IMO, this is very hackish. You imply that narrowing is only done > interactively, but this is not always the case. In non-interactive > usage, messing with newline characters could be a bad idea. I don't think if I've implied so, and I've written the code so that it wouldn't change non-interactive calls: --------------------------------[START]-------------------------------- <---------------> (defun org-narrow-to-subtree (&optional newline) "Narrow buffer to the current subtree. When called interactively, ensures that there=E2=80=99s a newline at the end of the narrowed tree." ->(interactive "p") (save-excursion (save-match-data (org-with-limited-levels (narrow-to-region (progn (org-back-to-heading t) (point)) (progn (org-end-of-subtree t t) (when (and (org-at-heading-p) (not (eobp))) (backward-char 1) -> (when newline (insert "\n"))) (point))))))) ---------------------------------[END]--------------------------------- I've tried to touch as few commands as possible, and I haven't seen any weird behaviours so far. But I understand your wariness. > In a nutshell, I suggest not going this route. Sorry for not having been > clear about it earlier. You don't need to apologise, I went down this route because it was an interesting project to address my problems with 1-line subtrees. As I've said in the commit message, even if we address the problem of other commands not seeing content added outside of the narrowing, we're still left with the other problem which is that the user is not seeing those changes. I wasn't content with this solution, and that's what prompted me to write this. Could I suggest you try out this patch with its latest commit (sent on Mon, 18 Feb 2019 18:18:47 +0100) and gauge whether it affects your workflow negatively? I know you=E2=80=99ve only said that this patch was heading in a wrong direction rather than saying that all hell would break loose upon applying the patch, but the later commits have tried to iron out the kinks, and that might quell your wariness. At any rate, thank you for time. HTH. Best, --=20 Leo Vivier English Studies & General Linguistics Master Student, English Department Universit=C3=A9 Rennes 2