Hello, Nicolas Goaziou <m...@nicolasgoaziou.fr> 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’s 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’ve 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, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2