From: Leo Vivier <leo.vivier@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH 1/2] Fix narrowing for 1-line subtrees
Date: Tue, 19 Feb 2019 11:24:24 +0100 [thread overview]
Message-ID: <871s44cbzb.fsf@hidden> (raw)
In-Reply-To: <87mumsqepg.fsf@nicolasgoaziou.fr>
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
next prev parent reply other threads:[~2019-02-19 10:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 0:25 [PATCH 1/2] Fix narrowing for 1-line subtrees Leo Vivier
2019-02-18 0:25 ` [PATCH 2/2] Prevent deletion of newline added by narrowing Leo Vivier
2019-02-18 1:02 ` [PATCH] Fix other commands for exiting narrowing Leo Vivier
2019-02-18 1:21 ` [PATCH] Fix other commands for exiting narrowing (2) Leo Vivier
2019-02-18 17:18 ` [PATCH] Fix problems Leo Vivier
2019-02-19 10:01 ` [PATCH 1/2] Fix narrowing for 1-line subtrees Nicolas Goaziou
2019-02-19 10:24 ` Leo Vivier [this message]
2019-02-19 10:35 ` [PATCH] Fix narrowing for 1-line subtrees (squashed) Leo Vivier
2019-02-19 12:05 ` [PATCH 1/2] Fix narrowing for 1-line subtrees Nicolas Goaziou
2019-02-19 13:37 ` Leo Vivier
2019-02-19 15:28 ` Leo Vivier
2019-02-19 15:40 ` Leo Vivier
2019-02-20 13:25 ` Nicolas Goaziou
2019-02-20 13:36 ` Leo Vivier
2019-02-21 15:38 ` [PATCH] Fix narrowed " Leo Vivier
2019-02-21 15:41 ` Leo Vivier
2019-02-21 15:43 ` [PATCH] Fix spaces with `org-remove-timestamp-with-keyword' Leo Vivier
2019-02-22 20:23 ` [PATCH] Fix narrowed 1-line subtrees Leo Vivier
2019-02-22 20:54 ` Leo Vivier
2019-02-22 21:53 ` Samuel Wales
2019-02-22 22:04 ` Leo Vivier
2019-02-22 23:58 ` Samuel Wales
2019-02-23 10:43 ` Leo Vivier
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871s44cbzb.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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).