Hello, Samuel Wales <samolog...@gmail.com> writes:
> i have not been able to follow this conversation, but is it possible > that /all/ of this complexity is due to outline-mode's dubious choice > of not considering the final newline in an entry to be part of an > entry? I don't know much about outline-mode, but I doubt it would be the case. In my email sent on Thu, 21 Feb 2019 16:41:43 +0100, I've investigated the problem, and one of my conclusions was the following: --------------------------------[START]-------------------------------- Going back to our example, if narrowing to a 1-line subtree included that last newline, we could delete it inside our narrowed buffer. If that newline was also the beginning of a new subtree, the subtree would not be functional anymore, since we'd end up with something like this: `*Subtree 1* Subtree 2'. ---------------------------------[END]--------------------------------- So, if we kept the newline, we'd put the user at risk of breaking the following subtree. An option could be to protect that newline by modifying our deletion commands, but after having done that in a previous implementation, it'd bring its fair share of complexity. >From my point of view, I do not see it as 'complex', but rather as a different way from doing what we'd been doing so far. Most of the functions are only *slightly* modified to preserve the ambiguous newline. HTH. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2