emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Leo Vivier <leo.vivier+org@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 14:37:52 +0100	[thread overview]
Message-ID: <87d0nnnbkf.fsf@hidden> (raw)
In-Reply-To: <87sgwkoue5.fsf@nicolasgoaziou.fr>

Hello again,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> It doesn't work the way `LaTeX-narrow-to-environment' works. In
> particular, AUCTeX's function /does not modify the buffer/. This is
> a big no-no, really.

I see your point, and I understand why it would be strange for narrowing
commands to modify the buffer.  I’d built this patch under three
assumptions:

1. We should only change the interactive behaviour of
  `org-narrow-to-subtree' so as to not disturb other commands/functions.
2. When called interactively, as long as our wrapper for `widen' cancels
   out what's been added by `org-narrow-to-subtree', changing the buffer
   is acceptable.
3. If the buffer were to be closed between `org-narrow-to-subtree' and
   our wrapper for `widen', the only thing you'd have is a spurious
   newline.  This wouldn't be a big deal because some commands in org
   already do that in a narrowed context [1].

That said, I completely understand your reticence and you've made me
understand that my solution was more 'hackish' than I intended it to be.

> I suggest to not use narrowing, then. Maybe try editing remotely
> a subtree, similar to what is done for footnotes. I have the feeling
> this would have its own set of issues, too.

I thought about other options before heading into this.  One of them was
to yank the subtrees to a temporary buffer to edit them and hook onto
the saving commands to update the corresponding buffer accordingly.  In
retrospect, that seems a lot more 'hackish'.  Maybe we could salvage
some of the patch for `org-capture' since it's different from narrowing,
but I've got a better idea.

> It is not about my workflow. I don't use 1-line subtrees. But anything
> related to narrowing or widening should not alter the buffer, per
> design. I may sound stubborn, but I don't think this is a way to handle
> the problem.

I'd like to suggest a middle ground which I think would be more
acceptable.  You've asked me in a previous exchange to make a list of
the commands which didn't work as expected when the buffer was narrowed
to a 1-line subtree [2].  Would it be possible to patch those commands
so that they conditionally refresh the narrowing of the buffer if the
information they add would be spawned *outside* of the restriction?

The rationale behind it is that, in Emacs, commands trying to act on
regions outside the current restriction throw an error.  Therefore, in
the context of 1-line subtrees, we could justify that conditional
behaviour by saying that it prevents your command from working outside
of the current restriction.

I was pleased to see that property-adding functions didn't behave badly
with 1-line subtrees.  Maybe we could investigate those commands and
patch their behaviour onto the problematic ones?

If that sounds good to you, I could work on it and submit another patch.

Thank you.

HTH.


Footnotes:
[1] As a quick aside, here's an example for 3. where X represents `point':
--------------------------------[START]--------------------------------
\|   * Tree
\|   |X1|2|
---------------------------------[END]---------------------------------
When narrowed (or at the end of a buffer), if you press <TAB>:
- `point' moves to '2'.
- Table is realigned.
- Newline is added at the end of the table.

[2] We've already addressed `org-clock-out-when-done', but I've found
another one.  Although adding scheduling/deadline information works
within a 1-line subtree (the information isn't visible, but it's there
in the widened buffer), you cannot remove them from within that
environment.


Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2

  reply	other threads:[~2019-02-19 13:38 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
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 [this message]
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=87d0nnnbkf.fsf@hidden \
    --to=leo.vivier+org@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).