Re: [PATCH 1/2] Fix narrowing for 1-line subtrees

[Leo Vivier <leo.vivier@gmail.com>]

Hello,

Nicolas Goaziou <mail@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