[9fans] invisible prompt in win

[9fans] invisible prompt in win

[Michael Brown]

1. Open a "win" in acme.
2. Scroll down as far as possible.
3. Notice that there is no $prompt visible at left.
4. echo annoying
5. Now scroll back up and it turns out you entered the echo command at
a prompt after all!

Re: [9fans] invisible prompt in win

[Robert Raschke]

On Fri, Oct 3, 2008 at 7:14 AM, Michael Brown <ebebe33@gmail.com> wrote:
> 1. Open a "win" in acme.
> 2. Scroll down as far as possible.
> 3. Notice that there is no $prompt visible at left.
> 4. echo annoying
> 5. Now scroll back up and it turns out you entered the echo command at
> a prompt after all!

Not entirely sure what other behaviour you were expecting? You
scrolled all the way down, leading to no text on your pane (it's all
up above), but your cursor is still where you left it (all the way at
the end of the text in the pane, all the way at the beginning of your
pane display).

Robby

Re: [9fans] invisible prompt in win

[Russ Cox]

This is not a bug.

At any point in time, there is a character position
associated with the upper left corner of the text window.
Text before that position is not shown; text at or after
that position is shown, until it runs off the bottom of
the window.  Let's call that upper left character position p0.

Most of the time, acme/sam/rio work to arrange that p0
follows a newline character, so that the window begins
at the beginning of a line.  Sometimes this is not possible.
One case is when a line is very long--longer than the
entire window--and you want to see the end of it.
Another case is when you tell acme/sam/rio to scroll past
the end of the text.  Then p0 is the end of the text,
right where your cursor is.  When you type new text,
it correctly shows at p0.  The prompt is still there, just
off the window to the top.

You are expecting line-oriented behavior in a "stream of bytes" world.

Russ

Re: [9fans] invisible prompt in win

[erik quanstrom]

> > 1. Open a "win" in acme.
> > 2. Scroll down as far as possible.
> > 3. Notice that there is no $prompt visible at left.
> > 4. echo annoying
> > 5. Now scroll back up and it turns out you entered the echo command at
> > a prompt after all!
>
> Not entirely sure what other behaviour you were expecting? You
> scrolled all the way down, leading to no text on your pane (it's all
> up above), but your cursor is still where you left it (all the way at
> the end of the text in the pane, all the way at the beginning of your
> pane display).

this is a bug.  you can see what you've typed but not the prompt.
normally acme warps back to the tick when you type.  this bug is
in acme since if you create a new window and type the prompt
manually then continue with step 2, you get the same results.

- erik

Re: [9fans] invisible prompt in win

[Robert Raschke]

On Fri, Oct 3, 2008 at 1:19 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > 1. Open a "win" in acme.
>> > 2. Scroll down as far as possible.
>> > 3. Notice that there is no $prompt visible at left.
>> > 4. echo annoying
>> > 5. Now scroll back up and it turns out you entered the echo command at
>> > a prompt after all!
>>
>> Not entirely sure what other behaviour you were expecting? You
>> scrolled all the way down, leading to no text on your pane (it's all
>> up above), but your cursor is still where you left it (all the way at
>> the end of the text in the pane, all the way at the beginning of your
>> pane display).
>
> this is a bug.  you can see what you've typed but not the prompt.
> normally acme warps back to the tick when you type.  this bug is
> in acme since if you create a new window and type the prompt
> manually then continue with step 2, you get the same results.
>

It's because your cursor is actually showing! So, no need to warp anywhere.

New heuristic needed? Personally, I'd say no. Maybe add it to smacme?

Robby

Re: [9fans] invisible prompt in win

[erik quanstrom]

> > this is a bug.  you can see what you've typed but not the prompt.
> > normally acme warps back to the tick when you type.  this bug is
> > in acme since if you create a new window and type the prompt
> > manually then continue with step 2, you get the same results.
> >
>
> It's because your cursor is actually showing! So, no need to warp anywhere.
>
> New heuristic needed? Personally, I'd say no. Maybe add it to smacme?
>

the fact that the tick shows is also a bug.  notice the scroll bar.

- erik

Re: [9fans] invisible prompt in win

[Robert Raschke]

> the fact that the tick shows is also a bug.  notice the scroll bar.

What do you mean? You're showing no characters in the pane, the
insertion point is after the last character.

Or do you want to have the ability to scroll beyond the end of your
text, to have some imaginary scroll advance taking you out into the
blue past the edge of the world?

Or do you want to disallow scrolling to just past the last character?
How many characters would you say need to remain showing?

Robby

Re: [9fans] invisible prompt in win

[erik quanstrom]

> > the fact that the tick shows is also a bug.  notice the scroll bar.
>
> What do you mean? You're showing no characters in the pane, the
> insertion point is after the last character.

yes, but you're not showing the line which includes the prompt.
either the tick and the prompt need displaying or neither do.  this
line is not long enough to wrap.

> Or do you want to have the ability to scroll beyond the end of your
> text, to have some imaginary scroll advance taking you out into the
> blue past the edge of the world?

bingo.

> Or do you want to disallow scrolling to just past the last character?
> How many characters would you say need to remain showing?

how about fixing the bug.  it's perfectly reasonable to have a blank
screen with 0 lines.  (an empty file, for example.)

- erik

Re: [9fans] invisible prompt in win

[Martin Neubauer]

* erik quanstrom (quanstro@quanstro.net) wrote:
> > > the fact that the tick shows is also a bug.  notice the scroll bar.
> >
> > What do you mean? You're showing no characters in the pane, the
> > insertion point is after the last character.
>
> yes, but you're not showing the line which includes the prompt.
> either the tick and the prompt need displaying or neither do.  this
> line is not long enough to wrap.

To me it looks more like a consequence of Plan 9's treatment of files as
sequences of bytes/chars/runes rather then sequences of lines as is common
in Unix. Basically, you can't scroll beyond the end of the file, and if the
insertion point coincides with the eof there's no need to jump on input. A
(possibly) related effect can be seen if you scroll across very long lines
(I saw this when viewing an e-mail with a somewhat large number of
recipients.) You might still consider it a bug, but I'm afraid the fix won't
really be straightforward and you might end up half way towards cursor
addressing.

Rio and sam show the same behaviour, by the way.

Regards,
	Martin

Re: [9fans] invisible prompt in win

[erik quanstrom]

> To me it looks more like a consequence of Plan 9's treatment of files as
> sequences of bytes/chars/runes rather then sequences of lines as is common
> in Unix. Basically, you can't scroll beyond the end of the file, and if the

unix and plan 9 agree: a file is an ordered sequence of bytes. unix
read/write/seek are measured in the same units as plan 9
pread/pwrite/seek: bytes.

but i think you may be talking about vi.  but even here,
the problem only happens on the first line.  i think it's just
a garden variety bug.  no philosophy need apply.

> Rio and sam show the same behaviour, by the way.

indicating exactly where to look.  (libframe.)

- erik

Re: [9fans] invisible prompt in win

[Pietro Gagliardi]

On Oct 5, 2008, at 9:52 AM, erik quanstrom wrote:
> indicating exactly where to look.  (libframe.)

I don't think so, as libframe doesn't provide a scroll function. Maybe
(rio sam acme) use a common scroll function? I'll look into it.

Re: [9fans] invisible prompt in win

[erik quanstrom]

> On Oct 5, 2008, at 9:52 AM, erik quanstrom wrote:
> > indicating exactly where to look.  (libframe.)
>
> I don't think so, as libframe doesn't provide a scroll function. Maybe
> (rio sam acme) use a common scroll function? I'll look into it.

i don't think the callback Frame.scroll would exist unless it's job
were to allow libframe to decide when to scroll.  if the application
made the decision by itself, there would be no need for this callback.

- erik