Re: [O] Has anybody noticed ellipses instead of the top line of the window?
On 9/6/13, Bastien 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.
Re: [O] Has anybody noticed ellipses instead of the top line of the window?
Hi Samuel, Samuel Wales writes: > On 4/5/13, Bastien 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: [O] Has anybody noticed ellipses instead of the top line of the window?
On 4/5/13, Bastien 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: [O] Has anybody noticed ellipses instead of the top line of the window?
Samuel Wales 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: [O] Has anybody noticed ellipses instead of the top line of the window?
On 4/5/13, Bastien 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: [O] Has anybody noticed ellipses instead of the top line of the window?
Hi Brian, sorry for the late reply. Brian van den Broek 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: [O] Has anybody noticed ellipses instead of the top line of the window?
On 6 December 2012 19:43, Brian van den Broek wrote: > > On 6 Dec 2012 13:46, "Samuel Wales" wrote: >> >> Has anybody encountered ellipses instead of the first line of the window? >> >> On 8/21/12, Samuel Wales 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: [O] Has anybody noticed ellipses instead of the top line of the window?
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/ a a a a a a a a a a > a a a a a a > :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 -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: [O] Has anybody noticed ellipses instead of the top line of the window?
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/ a a a a a a a a a a a a a a a a :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: [O] Has anybody noticed ellipses instead of the top line of the window?
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: [O] Has anybody noticed ellipses instead of the top line of the window?
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 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: [O] Has anybody noticed ellipses instead of the top line of the window?
Hi William, William 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: [O] Has anybody noticed ellipses instead of the top line of the window?
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: MRE.org Description: Binary data -- William
Re: [O] Has anybody noticed ellipses instead of the top line of the window?
Hi William, thanks for digging this further. William 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: [O] Has anybody noticed ellipses instead of the top line of the window?
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: [O] Has anybody noticed ellipses instead of the top line of the window?
Hi Samuel, Samuel Wales 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: [O] Has anybody noticed ellipses instead of the top line of the window?
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: [O] Has anybody noticed ellipses instead of the top line of the window?
The following occurs when isearch ends: On 12/6/12, Samuel Wales 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: [O] Has anybody noticed ellipses instead of the top line of the window?
On 12/6/12, Brian van den Broek 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: [O] Has anybody noticed ellipses instead of the top line of the window?
On 6 Dec 2012 13:46, "Samuel Wales" wrote: > > Has anybody encountered ellipses instead of the first line of the window? > > On 8/21/12, Samuel Wales 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
[O] Has anybody noticed ellipses instead of the top line of the window?
Has anybody encountered ellipses instead of the first line of the window? On 8/21/12, Samuel Wales 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.
