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
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
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
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
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
iss
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
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, i
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
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 s
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.
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
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
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 c
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 w
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
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 i
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-
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-
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 a
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
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 su
21 matches
Mail list logo
