possible bug: TAB after elipsis

possible bug: TAB after elipsis

[Anthony Lander]

If the cursor is after the elipsis on a folded entry like this:

	**** Some entry...|

pressing TAB doesn't expand the entry, or in fact, do anything useful  
at all. Is it possible to get it to expand the entry, or am I missing  
something?

Thanks,

   -Anthony

Re: possible bug: TAB after elipsis

[Livin Stephen Sharma]

Yep, I see this too!

setup
org-version: 6.34trans (from 2010_02_25)
emacs: 23.1.50.1

Livin Stephen Sharma



On Mar 24, 2010, at 23:34:40 , Anthony Lander wrote:

> If the cursor is after the elipsis on a folded entry like this:
> 
> 	**** Some entry...|
> 
> pressing TAB doesn't expand the entry, or in fact, do anything useful at all. Is it possible to get it to expand the entry, or am I missing something?
> 
> Thanks,
> 
>  -Anthony
> 
> 
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: possible bug: TAB after elipsis

[Carsten Dominik]

On Mar 24, 2010, at 7:04 PM, Anthony Lander wrote:

> If the cursor is after the elipsis on a folded entry like this:
>
> 	**** Some entry...|
>
> pressing TAB doesn't expand the entry, or in fact, do anything  
> useful at all. Is it possible to get it to expand the entry, or am I  
> missing something?

Cursor after the dots means the cursor is no longer in the headline,
in fact it is no longer in the entry at all.

- Carsten

Re: possible bug: TAB after elipsis

[Ben Finney]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On Mar 24, 2010, at 7:04 PM, Anthony Lander wrote:
>
> > If the cursor is after the elipsis on a folded entry like this:
> >
> > 	**** Some entry...|
> >
> > pressing TAB doesn't expand the entry, or in fact, do anything
> > useful at all. Is it possible to get it to expand the entry, or am I
> > missing something?
>
> Cursor after the dots means the cursor is no longer in the headline,
> in fact it is no longer in the entry at all.

But neither is it in the following entry, surely?

I agree with the original reporter that this goes against expectations.
Pressing TAB *anywhere* on the same line of a collapsed item should
expand it as normal, no? Can this be fixed?

-- 
 \       “Working out the social politics of who you can trust and why |
  `\      is, quite literally, what a very large part of our brain has |
_o__)                                   evolved to do.” —Douglas Adams |
Ben Finney

Re: possible bug: TAB after elipsis

[peter.frings]

On 26 Mar 2010, at 07:32, Carsten Dominik wrote:

> On Mar 24, 2010, at 7:04 PM, Anthony Lander wrote:
> 
>> If the cursor is after the elipsis on a folded entry like this:
>> 
>> 	**** Some entry...|
>> 
>> pressing TAB doesn't expand the entry, or in fact, do anything useful at all. Is it possible to get it to expand the entry, or am I missing something?
> 
> Cursor after the dots means the cursor is no longer in the headline,
> in fact it is no longer in the entry at all.

Well, that may be technically correct, but from a UI point of view it isn't. We're still one the same (head)_line_, no?

Not that I find this an important issue to fix, mind you :-)

Cheers,
Peter.

Re: possible bug: TAB after elipsis

[John Hendy]

[-- Attachment #1.1: Type: text/plain, Size: 2000 bytes --]

In my limited experience, I have already encountered this and been
surprised. I can see it both ways:

- On one hand: technically, the lead up of asterisks and the actual text
define the headline itself, as Carsten has pointed out.

- On the other hand, from a user standpoint I think it would be convenient.
I am not well versed in my keyboard-shortcut-fu, but I'm practicing and use
M-a/e a bit. One of the reasons this behavior is a bit annoying is that M-a
leads one to the spot /after/ an ellipsis. From there I want to press tab
and see the headline... but no dice. I admit that I can begin to use the
shortcuts specifically for navigating headlines. Learning a little at a time
and so currently I don't.

Anyway, my vote goes to expand it, even if technically the cursor is after
the 'body' since the 'body' is represented by the ellipsis. I think once it
is folded it serves only as a representation of the headline, not anything
useful having to do with actual folded text anymore.


John

On Fri, Mar 26, 2010 at 3:38 AM, <peter.frings@agfa.com> wrote:

>
> On 26 Mar 2010, at 07:32, Carsten Dominik wrote:
>
> > On Mar 24, 2010, at 7:04 PM, Anthony Lander wrote:
> >
> >> If the cursor is after the elipsis on a folded entry like this:
> >>
> >>      **** Some entry...|
> >>
> >> pressing TAB doesn't expand the entry, or in fact, do anything useful at
> all. Is it possible to get it to expand the entry, or am I missing
> something?
> >
> > Cursor after the dots means the cursor is no longer in the headline,
> > in fact it is no longer in the entry at all.
>
> Well, that may be technically correct, but from a UI point of view it
> isn't. We're still one the same (head)_line_, no?
>
> Not that I find this an important issue to fix, mind you :-)
>
> Cheers,
> Peter.
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

[-- Attachment #1.2: Type: text/html, Size: 2648 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: possible bug: TAB after elipsis

[Anthony Lander]

Hi Carsten,

On 10-Mar-26, at 2:32 AM, Carsten Dominik wrote:

>
> On Mar 24, 2010, at 7:04 PM, Anthony Lander wrote:
>
>> If the cursor is after the elipsis on a folded entry like this:
>>
>> 	**** Some entry...|
>>
>> pressing TAB doesn't expand the entry, or in fact, do anything  
>> useful at all. Is it possible to get it to expand the entry, or am  
>> I missing something?
>
> Cursor after the dots means the cursor is no longer in the headline,
> in fact it is no longer in the entry at all.

I was thinking about this a bit more. Is it possible to meet in the  
middle and restrict the cursor so that it can't go past the last  
character in the headline, like this:

	*** Some entry|...

I suggest this because if you do type after the elipsis, the text goes  
right on the end of the folded entry, which I believe is undesirable  
as well; It means that part of the entry is invisible, and part is  
visible. Limiting the cursor would solve both problems. Is this even  
feasible?

Regards,

   -Anthony

Re: possible bug: TAB after elipsis

[Memnon Anon]

Anthony Lander <anthonylander@yahoo.com> writes:
> I was thinking about this a bit more. Is it possible to meet in the
> middle and restrict the cursor so that it can't go past the last
> character in the headline, like this:
>
> 	*** Some entry|...
>
> I suggest this because if you do type after the elipsis, the text goes
> right on the end of the folded entry, which I believe is undesirable  as
> well; It means that part of the entry is invisible, and part is
> visible. Limiting the cursor would solve both problems. Is this even
> feasible?

I have not been following closely this thread, but I believe customizing 
"org-special-ctrl-a/e" might bring you a long way towards the behaviour 
you want. I suggest you give it a try.

,----[ (info "(org)Headlines") ]
| Documentation:
| Non-nil means `C-a' and `C-e' behave specially in headlines and items.
| 
| When t, `C-a' will bring back the cursor to the beginning of the
| headline text, i.e. after the stars and after a possible TODO keyword.
| In an item, this will be the position after the bullet.
| When the cursor is already at that position, another `C-a' will bring
| it to the beginning of the line.
| 
| `C-e' will jump to the end of the headline, ignoring the presence of tags
| in the headline.  A second `C-e' will then jump to the true end of the
| line, after any tags.  This also means that, when this variable is
| non-nil, `C-e' also will never jump beyond the end of the heading of a
| folded section, i.e. not after the ellipses.
`----

hth 
memnon

Re: Re: possible bug: TAB after elipsis

[John Hendy]

[-- Attachment #1.1: Type: text/plain, Size: 2360 bytes --]

This awesome. If this equivalent existed for M-a/e and M-f/b, I would be
very happy with the result. Seem reasonable -- when on a folded headline, I
just can't think of a reason someone would want to interact with the
headline after the ellipsis. It even, as someone else mentioned, can ge one
into trouble -- press the wrong key or delete after it and you're removing
text you can't even see... but are able to interact with!

Thanks for this, memmon.


On Sat, Mar 27, 2010 at 1:02 PM, Memnon Anon <
gegendosenfleisch@googlemail.com> wrote:

> Anthony Lander <anthonylander@yahoo.com> writes:
> > I was thinking about this a bit more. Is it possible to meet in the
> > middle and restrict the cursor so that it can't go past the last
> > character in the headline, like this:
> >
> >       *** Some entry|...
> >
> > I suggest this because if you do type after the elipsis, the text goes
> > right on the end of the folded entry, which I believe is undesirable  as
> > well; It means that part of the entry is invisible, and part is
> > visible. Limiting the cursor would solve both problems. Is this even
> > feasible?
>
> I have not been following closely this thread, but I believe customizing
> "org-special-ctrl-a/e" might bring you a long way towards the behaviour
> you want. I suggest you give it a try.
>
> ,----[ (info "(org)Headlines") ]
> | Documentation:
> | Non-nil means `C-a' and `C-e' behave specially in headlines and items.
> |
> | When t, `C-a' will bring back the cursor to the beginning of the
> | headline text, i.e. after the stars and after a possible TODO keyword.
> | In an item, this will be the position after the bullet.
> | When the cursor is already at that position, another `C-a' will bring
> | it to the beginning of the line.
> |
> | `C-e' will jump to the end of the headline, ignoring the presence of tags
> | in the headline.  A second `C-e' will then jump to the true end of the
> | line, after any tags.  This also means that, when this variable is
> | non-nil, `C-e' also will never jump beyond the end of the heading of a
> | folded section, i.e. not after the ellipses.
> `----
>
> hth
> memnon
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

[-- Attachment #1.2: Type: text/html, Size: 3057 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: possible bug: TAB after elipsis

[Memnon Anon]

John Hendy <jw.hendy@gmail.com> writes:

> This awesome. If this equivalent existed for M-a/e and M-f/b, I would
> be very happy with the result. Seem reasonable -- when on a folded
> headline, I just can't think of a reason someone would want to
> interact with the headline after the ellipsis. It even, as someone
> else mentioned, can ge one into trouble -- press the wrong key or
> delete after it and you're removing text you can't even see... but are
> able to interact with!

Well, after all, its just "Plain Text" you are editing.
Whenever there is an Elipsis, there is a convenient "hack" in the
display hiding what you don't want to see, but it is never the less a
hack. So I got into the habbit that, whenever I edit a line that 
contains "...", I unfold it first; whenever it is folded, I only 
a ) view it or 
b) navigate with the org commands like the speed keys
   (http://orgmode.org/manual/Speed-keys.html) or 
c) use the org structure editing command 
(http://orgmode.org/manual/Structure-editing.html).

For extensive editing with emacs board tools, there is always 
"M-x show-all". 

So, I agree, whenever there are ellipsis, editing "it ... can
get one into trouble". So I just don't ;).

hth
Memnon

Re: Re: possible bug: TAB after elipsis

[John Hendy]

[-- Attachment #1.1: Type: text/plain, Size: 1918 bytes --]

Very cool and good point about unfolding. I've basically been doing the same
things.

Thanks for the speed keys link, especially. I've just got to sit down and
read the whole manual some weekend... there's so much and since I am usually
searching under 'problem-based' motivation, there's so many helpful things I
might never find that way!

On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon <
gegendosenfleisch@googlemail.com> wrote:

> John Hendy <jw.hendy@gmail.com> writes:
>
> > This awesome. If this equivalent existed for M-a/e and M-f/b, I would
> > be very happy with the result. Seem reasonable -- when on a folded
> > headline, I just can't think of a reason someone would want to
> > interact with the headline after the ellipsis. It even, as someone
> > else mentioned, can ge one into trouble -- press the wrong key or
> > delete after it and you're removing text you can't even see... but are
> > able to interact with!
>
> Well, after all, its just "Plain Text" you are editing.
> Whenever there is an Elipsis, there is a convenient "hack" in the
> display hiding what you don't want to see, but it is never the less a
> hack. So I got into the habbit that, whenever I edit a line that
> contains "...", I unfold it first; whenever it is folded, I only
> a ) view it or
> b) navigate with the org commands like the speed keys
>   (http://orgmode.org/manual/Speed-keys.html) or
> c) use the org structure editing command
> (http://orgmode.org/manual/Structure-editing.html).
>
> For extensive editing with emacs board tools, there is always
> "M-x show-all".
>
> So, I agree, whenever there are ellipsis, editing "it ... can
> get one into trouble". So I just don't ;).
>
> hth
> Memnon
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

[-- Attachment #1.2: Type: text/html, Size: 2826 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: possible bug: TAB after elipsis

[Bernt Hansen]

John Hendy <jw.hendy@gmail.com> writes:

> Very cool and good point about unfolding. I've basically been doing the same things.
>
> Thanks for the speed keys link, especially. I've just got to sit down and read the whole manual some weekend... there's so much and since I am usually searching under 'problem-based' motivation, there's
> so many helpful things I might never find that way!
>
> On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon <gegendosenfleisch@googlemail.com> wrote:
>
>     John Hendy <jw.hendy@gmail.com> writes:
>    
>     > This awesome. If this equivalent existed for M-a/e and M-f/b, I would
>     > be very happy with the result. Seem reasonable -- when on a folded
>     > headline, I just can't think of a reason someone would want to
>     > interact with the headline after the ellipsis. It even, as someone
>     > else mentioned, can ge one into trouble -- press the wrong key or
>     > delete after it and you're removing text you can't even see... but are
>     > able to interact with!
>    
>     Well, after all, its just "Plain Text" you are editing.
>     Whenever there is an Elipsis, there is a convenient "hack" in the
>     display hiding what you don't want to see, but it is never the less a
>     hack. So I got into the habbit that, whenever I edit a line that
>     contains "...", I unfold it first; whenever it is folded, I only
>     a ) view it or
>     b) navigate with the org commands like the speed keys
>       (http://orgmode.org/manual/Speed-keys.html) or
>     c) use the org structure editing command
>     (http://orgmode.org/manual/Structure-editing.html).
>    
>     For extensive editing with emacs board tools, there is always
>     "M-x show-all".
>    
>     So, I agree, whenever there are ellipsis, editing "it ... can
>     get one into trouble". So I just don't ;).
>    
>     hth
>     Memnon
>
>     _______________________________________________
>     Emacs-orgmode mailing list
>     Please use `Reply All' to send replies to the list.
>     Emacs-orgmode@gnu.org
>     http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: possible bug: TAB after elipsis

[Bernt Hansen]

John Hendy <jw.hendy@gmail.com> writes:

> Very cool and good point about unfolding. I've basically been doing the same things.
>
> Thanks for the speed keys link, especially. I've just got to sit down and read the whole manual some weekend... there's so much and since I am usually searching under 'problem-based' motivation, there's
> so many helpful things I might never find that way!
>
> On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon <gegendosenfleisch@googlemail.com> wrote:
>
>     John Hendy <jw.hendy@gmail.com> writes:
>    
>     > This awesome. If this equivalent existed for M-a/e and M-f/b, I would
>     > be very happy with the result. Seem reasonable -- when on a folded
>     > headline, I just can't think of a reason someone would want to
>     > interact with the headline after the ellipsis. It even, as someone
>     > else mentioned, can ge one into trouble -- press the wrong key or
>     > delete after it and you're removing text you can't even see... but are
>     > able to interact with!
>    
>     Well, after all, its just "Plain Text" you are editing.
>     Whenever there is an Elipsis, there is a convenient "hack" in the
>     display hiding what you don't want to see, but it is never the less a
>     hack. So I got into the habbit that, whenever I edit a line that
>     contains "...", I unfold it first; whenever it is folded, I only
>     a ) view it or
>     b) navigate with the org commands like the speed keys
>       (http://orgmode.org/manual/Speed-keys.html) or
>     c) use the org structure editing command
>     (http://orgmode.org/manual/Structure-editing.html).
>    
>     For extensive editing with emacs board tools, there is always
>     "M-x show-all".
>    
>     So, I agree, whenever there are ellipsis, editing "it ... can
>     get one into trouble". So I just don't ;).
>    
>     hth
>     Memnon

Sorry about the premature post - send key malfunction :)

One other thing I've done for dealing with folded text is use my binding
for F9-v which toggles visibility mode on and off.  This unfolds
_everything_ and makes it possible to see what you are changing (usually
because I accidentally edited something in a folded region and want to
see exactly what I'm undoing to fix it)

(global-set-key (kbd "<f9> v") 'visible-mode)

HTH,
Bernt

Re: Re: possible bug: TAB after elipsis

[Alan E. Davis]

Not sure whether I'm talking about the same phenomenon, but I have
started almost routinely adding a tag at the end of every headline
inserted by my remember templates.  Without the tag, it'seems it's
hard to move past the end of the line cleanly to edit the contents.
With a tag, using the custom \C-a/e behavior alluded to above, its a
cinch.

I am annoyed by this.  It seems wrong, and I assumed there is a
workaround somewhere, if I looked hard enough.  Again, maybe this is
another problem.

Alan

Re: Re: possible bug: TAB after elipsis

[Carsten Dominik]

Hi Alan,

On Mar 28, 2010, at 1:45 PM, Alan E. Davis wrote:

> Not sure whether I'm talking about the same phenomenon, but I have
> started almost routinely adding a tag at the end of every headline
> inserted by my remember templates.  Without the tag, it'seems it's
> hard to move past the end of the line cleanly to edit the contents.
> With a tag, using the custom \C-a/e behavior alluded to above, its a
> cinch.

I don't think I can reproduce this.

Can you please make your explanation more detailed, with an example,  
with your setting for org-special-control-a/e, and with a step by step  
guide on how to hit any problems?


Thanks

- Carsten

>
> I am annoyed by this.  It seems wrong, and I assumed there is a
> workaround somewhere, if I looked hard enough.  Again, maybe this is
> another problem.
>
> Alan
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: possible bug: TAB after elipsis

[Alan E. Davis]

Hello, Carsten:

I have to admit you are right, at least to the extent I cannot now
reproduce this behavior. I also have to admit that I haven't been
aware of that behavior for a while.

I will attempt to reproduce it for a day or two, and see if I can send
you a "working" example.

With apologies,

Alan

On Sun, Mar 28, 2010 at 9:58 PM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
> Hi Alan,
>
> On Mar 28, 2010, at 1:45 PM, Alan E. Davis wrote:
>
>> Not sure whether I'm talking about the same phenomenon, but I have
>> started almost routinely adding a tag at the end of every headline
>> inserted by my remember templates.  Without the tag, it'seems it's
>> hard to move past the end of the line cleanly to edit the contents.
>> With a tag, using the custom \C-a/e behavior alluded to above, its a
>> cinch.
>
> I don't think I can reproduce this.
>
> Can you please make your explanation more detailed, with an example, with
> your setting for org-special-control-a/e, and with a step by step guide on
> how to hit any problems?
>
>
> Thanks
>
> - Carsten
>
>>
>> I am annoyed by this.  It seems wrong, and I assumed there is a
>> workaround somewhere, if I looked hard enough.  Again, maybe this is
>> another problem.
>>
>> Alan
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> - Carsten
>
>
>
>