Has anybody noticed ellipses instead of the top line of the window?

Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

Has anybody encountered ellipses instead of the first line of the window?

On 8/21/12, Samuel Wales <samologist@gmail.com> wrote:
> === beginning of window
> ...
> ******* Above all
> Above all, it is a collapse of the uneasy and corrupt
> identification of science -- that principled, unbiased, at
> times necessarily subversive, transparent, open-minded, and
> often selfless search for natural reality -- with rank
> authority.  The sloppy emulsion of water in oil.
> === end of window
>
> Note the "..." on the first line.  (Above that is merely ordinary body
> text in a sibling.)

Thanks.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is no hope without action.

Re: Has anybody noticed ellipses instead of the top line of the window?

[Brian van den Broek]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On 6 Dec 2012 13:46, "Samuel Wales" <samologist@gmail.com> wrote:
>
> Has anybody encountered ellipses instead of the first line of the window?
>
> On 8/21/12, Samuel Wales <samologist@gmail.com> wrote:
> > === beginning of window
> > ...
> > ******* Above all
> > Above all, it is a collapse of the uneasy and corrupt

I have. Haven't noticed a pattern; I always get mildly concerned and often
am motivated to reassure myself there's be no data loss. Never has been.

Best,

Brian vdB

[-- Attachment #2: Type: text/html, Size: 703 bytes --]

Re: Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

On 12/6/12, Brian van den Broek <brian.van.den.broek@gmail.com> wrote:
> I have. Haven't noticed a pattern; I always get mildly concerned and often
> am motivated to reassure myself there's be no data loss. Never has been.

In my case, it's a significant part of the total lines in the window.

I wonder if anybody has any clues about why that ellipsis gets put there?

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is no hope without action.

Re: Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

The following occurs when isearch ends:

On 12/6/12, Samuel Wales <samologist@gmail.com> wrote:
>> === beginning of window
>> ...
>> ******* Above all
>> Above all, it is a collapse of the uneasy and corrupt
>> identification of science -- that principled, unbiased, at
>> times necessarily subversive, transparent, open-minded, and
>> often selfless search for natural reality -- with rank
>> authority.  The sloppy emulsion of water in oil.
>> === end of window
>>
>> Note the "..." on the first line.  (Above that is merely ordinary body
>> text in a sibling.)

Please note how that ellipsis carries no useful information.

I have tried to fix this and other visibility problems (namely,
canonical visibility is impossible to achieve using standard Org
variables) for years, and I still have not found out how to do it.

As best I can tell, there is a post command hook when isearch exits,
and that calls Org's visibility code.

Org's visibility code then inserts the ... at the top line of the
window for unknown reasons.

I don't need fancy recentering of the headline, if that helps.

Anybody know why?  I'd like that ellipsis not to be there.

Thanks.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is no hope without action.

Re: Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

My current kludge is to defadvice org-mode:

(defadvice org-mode
    (after fix-visibility first (&optional state) activate compile)
  ;;undo what org does
  (org-set-local 'outline-isearch-open-invisible-function
                 (lambda (&rest ignore)
                   (alpha-org-show-canonical-liberal))))

Where alpha-org-show-canonical-liberal is a kludge to try to set
canonical visibility.

Slow and buggy, but at least I got rid of the ellipsis on the first line.

I think.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is no hope without action.

Re: Has anybody noticed ellipses instead of the top line of the window?

[Bastien]

Hi Samuel,

Samuel Wales <samologist@gmail.com> writes:

> Please note how that ellipsis carries no useful information.
>
> I have tried to fix this and other visibility problems (namely,
> canonical visibility is impossible to achieve using standard Org
> variables) for years, and I still have not found out how to do it.
>
> As best I can tell, there is a post command hook when isearch exits,
> and that calls Org's visibility code.
>
> Org's visibility code then inserts the ... at the top line of the
> window for unknown reasons.
>
> I don't need fancy recentering of the headline, if that helps.
>
> Anybody know why?  I'd like that ellipsis not to be there.

I want to come back on this.

I cannot reproduce this *at all* and I never noticed it.

Can you help me reproduce it?

Also, what is the value of these variables?

  `org-show-hierarchy-above'
  `org-show-following-heading'
  `org-show-entry-below'
  `org-show-siblings'

Thanks,

-- 
 Bastien

Re: Has anybody noticed ellipses instead of the top line of the window?

[William]

On Wed, 30 Jan 2013 18:36:16 +0100, Bastien spake thus:
> > Org's visibility code then inserts the ... at the top line of the
> > window for unknown reasons.

> Can you help me reproduce it?

I also have visibility problems when performing undo-es.

I can reproduce such an ellipsis by :

- Cutting part of the buffer containing an ellipsis
- Undoing the cut

On the attached example, all being visible, fold the first second level
headline, kill its line (C-k with cursor at the beginning of line), and undo
the kill. The buffer then looks like

[ellipsis]
** next headlines

Instead of the initial view (seeing the main headline, etc.)

(That doesn't happen if, all folded, you unfold the main headline, then cut the
still-folded second-level headline and undo, apparently.)

> Also, what is the value of these variables?

>   `org-show-hierarchy-above'
t
>   `org-show-following-heading'
t
>   `org-show-entry-below'
((default))
>   `org-show-siblings'
t

--
William

Re: Has anybody noticed ellipses instead of the top line of the window?

[Bastien]

Hi William,

thanks for digging this further.

William <william.lechelle@ens-lyon.org> writes:

> On Wed, 30 Jan 2013 18:36:16 +0100, Bastien spake thus:
>> > Org's visibility code then inserts the ... at the top line of the
>> > window for unknown reasons.
>
>> Can you help me reproduce it?
>
> I also have visibility problems when performing undo-es.
>
> I can reproduce such an ellipsis by :
>
> - Cutting part of the buffer containing an ellipsis
> - Undoing the cut
>
> On the attached example, all being visible, fold the first second level
> headline, kill its line (C-k with cursor at the beginning of line), and undo
> the kill. The buffer then looks like

I think you forgot to attach the example, and I was not able to
reproduce the problem by following the directions...

Thanks,

-- 
 Bastien

Re: Has anybody noticed ellipses instead of the top line of the window?

[William]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Thu, 07 Feb 2013 11:11:21 +0100, Bastien spake thus:
> > I can reproduce such an ellipsis by :
> >
> > - Cutting part of the buffer containing an ellipsis
> > - Undoing the cut
> >
> > On the attached example, all being visible, fold the first second level
> > headline, kill its line (C-k with cursor at the beginning of line), and undo
> > the kill. The buffer then looks like

> I think you forgot to attach the example, and I was not able to
> reproduce the problem by following the directions...

My bad… here:


[-- Attachment #2: MRE.org --]
[-- Type: application/octet-stream, Size: 91 bytes --]

pre-text

* MRE
** Be folded
   You shouldn't see this.
** Kill the above headline
** Undo

[-- Attachment #3: Type: text/plain, Size: 11 bytes --]


--
William

Re: Has anybody noticed ellipses instead of the top line of the window?

[Bastien]

Hi William,

William <william.lechelle@ens-lyon.org> writes:

> My bad… here:

Thanks...  But I still cannot reproduce the problem.
Let's get back to this when we have a sure recipe.
Also let us know if you think it depends on your
version of Emacs (23 right?)  Best,

-- 
 Bastien

Re: Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

Hi Bastien,

The reproduction is consistent for me for the top line ellipses in
24.2.2 using johnw's git repo's mac port branch.  Let me know if you
need more data.

===

It is usually also consistent for all the other falsely hidden lines
and false ellipses.
Org *all over the place* for me has non-canonical visibility behavior.
 I encounter it all the time.  :(

Just so it is clear, my term, "canonical visibility" means that you
never get any visibility state that is not possible to create using
TAB and arrow keys starting from a completely folded buffer.  This is
what I always want (except for when I do a sparse tree explicitly).

Thus, no matter how you get there (undo, redo, isearch, agenda
following, Magit following, link, etc.) you should get such a state.

And you should never get any bogus ellipses, hidden lines (such as
when only the next header shows), etc.  I typically get both of those
frequently.

On 1/30/13, Bastien <bzg@altern.org> wrote:
>   `org-show-hierarchy-above'
t
>   `org-show-following-heading'
((default)) which is default
>   `org-show-entry-below'
((default)) which is default
>   `org-show-siblings'
t

Thanks.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is no hope without action.

Re: Has anybody noticed ellipses instead of the top line of the window?

[Bastien]

Hi Samuel and William,

I still cannot reproduce the problem consistently and it seems 
hard to reproduce.  Let's try to reproduce it with emacs -Q first,
then consider customization later on.

Also, I don't think we can prevent the users from ending up with
wrong ellipses in *all* circumstances.  `org-catch-invisible-edits'
was a step in this direction, preventing users to accidentally
delete hidden regions, but it's impossible to catch all mistakes.

Let's try to catch the most obvious/disturbing ones first.

Thanks,

-- 
 Bastien

Re: Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

The ellipses still occur.

Here is an ECM.

===
# -*- coding: utf-8 -*-
#+CATEGORY: executive

the long line and logbook are necessary.  try with fewer
lines and columns.

* a
*** a /a/ aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa
aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa
:LOGBOOK:
- Not scheduled, was "2012-08-01 Wed 02:00 .+1d" on [2012-12-01 Sat 02:29]
:END:
*** REF cycling this always puts the ellipsis in                   :norefile:
:PROPERTIES:
:CATEGORY: remember
:END:
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
***** a
===

Thanks.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is no hope without action.

Re: Has anybody noticed ellipses instead of the top line of the window?

[Arun Persaud]

On 02/28/2013 09:59 AM, Samuel Wales wrote:
> The ellipses still occur.
> 
> Here is an ECM.
> 
> ===
> # -*- coding: utf-8 -*-
> #+CATEGORY: executive
> 
> the long line and logbook are necessary.  try with fewer
> lines and columns.
> 
> * a
> *** a /a/ aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa
> aaaaa aaaaa aaaaa aaaaa aaaaa aaaaa
> :LOGBOOK:
> - Not scheduled, was "2012-08-01 Wed 02:00 .+1d" on [2012-12-01 Sat 02:29]
> :END:
> *** REF cycling this always puts the ellipsis in                   :norefile:
>[...]

can't reproduce this on my computer. If I move the cursor onto "cycling"
and do <shift>-TAB everything seems normal.

First shift-tab collapses everything to * a..., second time I get all
the headlines (e.g. just the lines that start with a *), third time I
also see the second line of the "a"-entry and the folded LOGBOOG and
PROPERTY drawers. If I remove LOGBOOK and/or make the lines shorter
things stay the same.

I'm using release_7.9.3f-1257-g5bdb84.

Arun

Re: Has anybody noticed ellipses instead of the top line of the window?

[Brian van den Broek]

On 6 December 2012 19:43, Brian van den Broek
<brian.van.den.broek@gmail.com> wrote:
>
> On 6 Dec 2012 13:46, "Samuel Wales" <samologist@gmail.com> wrote:
>>
>> Has anybody encountered ellipses instead of the first line of the window?
>>
>> On 8/21/12, Samuel Wales <samologist@gmail.com> wrote:
>> > === beginning of window
>> > ...
>> > ******* Above all
>> > Above all, it is a collapse of the uneasy and corrupt
>
> I have. Haven't noticed a pattern; I always get mildly concerned and often
> am motivated to reassure myself there's be no data loss. Never has been.
>


Hi all,

I've found one repeatable way to generate these unwanted ellipses.

I have an org file with two top-level headings. The second is small
and containing only a few lines of text. The first is huge and has a
crypt tag and thus is encrypted with org-crypt. (For obvious reasons,
I am unwilling to post the file.)

Steps:

1) Visit the file
2) Call org-decrypt-entry on the crypt heading
3) Follow a link at the top of the crypt tree to a heading deep within
that tree. Ensure that it is not the case that the entire tree is
expanded (decription occurs below)
4) Edit somewhere in the heading
5) Save the file (C-x C-s). This causes the heading to be encrypted again.
6) M-x undo to restore the file to its unencrypted state.
7) Observe that the top of the buffer has the ellipses and all data
before the heading being edited can no longer be seen.

The file looks roughly like:

# -*- buffer-auto-save-file-name: nil; -*-

Two lines of description not in any heading

* vault                         :crypt:

** Quick links

** stuff

** other stuff

** still more stuff

** more stuff still


Each of the various stuff headings (there are plenty more) may have
several layers of descendant headings. In the Quick links heading
there are org links to the most used headings. At step (3) in the
recipe above, I expand the Quick links heading and follow one of the
links there which points to a heading buried within the tree. I hit
TAB to expand that heading. (It has siblings both before and after.)
There is a `...' at the end of the heading when it is expanded. The
ellipses observed at (7) seem to appear either before the heading that
follows the top level tree that I edited (so, right before `more stuff
still' if I edited a tree several layers in `still more stuff' *or*
immediately before all of the body text of the headline that I edited
and taking the place of the subtree headline to which the link that I
followed points. (I've not discerned a pattern, but it seems to depend
upon the expansion state around the edit or the location of the cursor
when I save; I am not sure, though.) Either way, M-x
beginning-of-buffer never takes me past the `...'.

Following the same steps but first ensuring that the entire tree is
fully expanded does not result in the `...'.

I hope both that my description is tolerably clear and that it is some
help in the ellipses bug hunt.

Best,

Brian vdB

Re: Has anybody noticed ellipses instead of the top line of the window?

[Bastien]

Hi Brian,

sorry for the late reply.

Brian van den Broek <brian.van.den.broek@gmail.com> writes:

> I hope both that my description is tolerably clear and that it is some
> help in the ellipses bug hunt.

I must say I have been lazy and quite gave up on this "wrong ellipses"
issue.  Since your description involves en/decryption, I assume it does
affect too many users and too many possible use-cases.

Let's revisit this issue after the next major release, if someone has*
the energy to put a stab at it.

Thanks,

-- 
 Bastien

Re: Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

On 4/5/13, Bastien <bzg@altern.org> wrote:
> I must say I have been lazy and quite gave up on this "wrong ellipses"
> issue.  Since your description involves en/decryption, I assume it does
> affect too many users and too many possible use-cases.

For clarity, wrong ellipses (and other non-canonical visibility
issues) occur for me without encryption being involved.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY
can get it.  There is NO hope without action.  This means YOU.

Re: Has anybody noticed ellipses instead of the top line of the window?

[Bastien]

Samuel Wales <samologist@gmail.com> writes:

> For clarity, wrong ellipses (and other non-canonical visibility
> issues) occur for me without encryption being involved.

I know it can occur, I use Org too :)

It's hard to find reproducible recipes; when we have some (like the
one Brian provided), it's hard to debug; and for I cannot afford to
put this as a priority as the annoyance/hard-to-debug ratio is too
low IMO.

Let's revive this after 8.0 if needed,

-- 
 Bastien

Re: Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

On 4/5/13, Bastien <bzg@altern.org> wrote:
> It's hard to find reproducible recipes; when we have some (like the
> one Brian provided), it's hard to debug; and for I cannot afford to
> put this as a priority as the annoyance/hard-to-debug ratio is too
> low IMO.
>
> Let's revive this after 8.0 if needed,

Reviving.  I provided a recipe in this thread.

Here is a fix that sometimes works, but usually not:

(defadvice org-optimize-window-after-visibility-change
    (around fix-recenter activate compile)
  "fix recenter to be recenter 2 so ellipses do not sometimes
show up on line 1.  recenter 1 is an emacs bug."
  (when (get-buffer-window (current-buffer))
    (cond
      ((eq state 'content)  nil)
      ((eq state 'all)      nil)
      ((eq state 'folded)   nil)
      ((eq state 'children) (or (org-subtree-end-visible-p) (recenter 2)))
      ((eq state 'subtree)  (or (org-subtree-end-visible-p) (recenter 2))))))

-- 
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.

Re: Has anybody noticed ellipses instead of the top line of the window?

[Bastien]

Hi Samuel,

Samuel Wales <samologist@gmail.com> writes:

> On 4/5/13, Bastien <bzg@altern.org> wrote:
>> It's hard to find reproducible recipes; when we have some (like the
>> one Brian provided), it's hard to debug; and for I cannot afford to
>> put this as a priority as the annoyance/hard-to-debug ratio is too
>> low IMO.
>>
>> Let's revive this after 8.0 if needed,
>
> Reviving.  I provided a recipe in this thread.

Sorry, I'm short of time to explore this again and I rarely have
problems with wrong ellipsis myself.  Let's see if you can have
a stable fix, otherwise I guess we'll have to live with it!

Best,

-- 
 Bastien

Re: Has anybody noticed ellipses instead of the top line of the window?

[Samuel Wales]

On 9/6/13, Bastien <bzg@gnu.org> wrote:
> problems with wrong ellipsis myself.  Let's see if you can have
> a stable fix, otherwise I guess we'll have to live with it!

not sure what you mean by let's see if you can have a stable fix.

n.b. still getting ellipsis at top of buffer with both refile goto and
link goto.  it is not intermittent, but depends on the target header.

possibly related to number of lines and having to do with an attempt
to show as much of the text as possible or something.  just a guess.

-- 
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.