* Re: Bug: heading visibility cycling and org-narrow-to-subtree
2013-08-30 16:27 ` Carsten Dominik
@ 2013-08-30 18:41 ` Samuel Wales
0 siblings, 0 replies; 3+ messages in thread
From: Samuel Wales @ 2013-08-30 18:41 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Mailinglist emacs-orgmode, Ali Tofigh
Hmm, I have found and reported several bugs of this nature also. For
example, sorting in a narrowed region usually corrupted the buffer by
joining lines. This bug went unnoticed for possibly years becuase it
was tricky to correlate the sorting operation with the buffer
corruption [because diff is often unreadable in such cases].
Here's my take:
I don't know if it is relevant in this case, but I found that the
cause of most of these bugs is Outline mode, not Org or Emacs.
Outline does not include the final newline.
In most of Emacs, you typically mark bol, then move down a few lines,
then perform the operation. This marks lines including their
newlines.
But in Outline, you have to guard against the special case of the
narrowed region not doing this. That is, all code that uses outline
subtree marking has to code defensively and work around what amounts
to a special case.
A lot of code in Emacs subtly assumes a newline at the end of a
narrowed region, and does not consider this special case.
A philosopher would say that it's a matter of whether newlines are
line separators or line terminators, but much of line-operating and
region-operating functionality in Emacs has made the pragmatic
decision that they are line terminators. While I acknowledge the
other point of view, and I am aware of the potential religious war
that might ensue, I agree with that decision and don't think it's best
to try to change all of Emacs to accommodate Outline mode's view in
this case.[1]
In summary, while this decision is up to Org developers, IMO Outline's
peculiar way of marking a subtree will continue to cause subtle bugs
and require defensive coding and workarounds until, somehow, a subtree
in Org is defined to include the final newline, at least everywhere
except eob.
Dunno if that helps or is relevant, but I hope it provides a little
context, even if tangential.
Samuel
[1] The first line does not include the newline before it. The last
line does include its own newline. Thus, lines at buffer boundaries
do not have to be treated specially. If you don't use a final newline
in the file, such bugs become apparent quickly and can be fixed with
require-final-newline.
Furthermore, point and mark are both at bol in all cases when you are
performing such operations.
As a user, I find it disconcerting to do end-of-buffer and have point
not be at bol.
Finally, applications like cron often require final newlines. Did you
know that if you don't do that, and run certain crons, the final line
will be silently skipped? Surprise :).
===
On 8/30/13, Carsten Dominik <carsten.dominik@gmail.com> wrote:
> Hi Ali,
>
> hmmm, this is clearly a bug. But one that is hard to fix. I remember that
> it was problematic to extend the narrowing region to include the newline
> directly before the next heading. I do not exactly remember why this caused
> problems, but it did.
>
> I suggest to just live with it.
>
> Thank you for the report none the less!
>
> - Carsten
>
> On 22.8.2013, at 22:30, Ali Tofigh <alix.tofigh@gmail.com> wrote:
>
>> After narrowing to a subtree, folding the top level heading hides all
>> text except for the last letter in the last paragraph. An example:
>>
>> ----- 8< -----
>> * one
>> ** two
>> hello world
>> * three
>> ----------
>>
>> with cursor on heading "one", do M-x org-narrow-to-subtree (C-x n s),
>> then press tab, and you get:
>>
>> ----- 8< -----
>> * one...d
>> ----------
>>
>> with the "d" of "hello world" being visible.
>>
>> emacs version: 24.3.1
>> Org-mode version: 8.0.7 (8.0.7-6-g13cb28-elpa)
>> OS: Mac OSX
>> emacs was started with the -Q flag
>>
>> /ali
>>
>
>
>
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Denmark: free Karina Hansen NOW.
^ permalink raw reply [flat|nested] 3+ messages in thread