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