-----Original Message-----
From: Cao, Minggui <minggui.cao@...>
Sent: Monday, July 25, 2022 8:12 PM
To: Dong, Eddie <eddie.dong@...>; acrn-dev@...
Subject: RE: [acrn-dev] [PATCH 1/2 v2] hv: shell: improve console to buffer
history cmds

-----Original Message-----
From: Dong, Eddie <eddie.dong@...>
Sent: Tuesday, July 26, 2022 10:21 AM
To: Cao, Minggui <minggui.cao@...>;
acrn-dev@...
Subject: RE: [acrn-dev] [PATCH 1/2 v2] hv: shell: improve console to
buffer history cmds

[Cao, Minggui] it is a ring buffer, if the buffer is not full
filled and full, the index shall be Handled differently. For
example, if total buffer size 8, now just buffered 4, the index
shall Be just in 3-0;

Understood. But we don't need to check it.

For key_UP, it can do like:
If ( --p_shell->selected_index < 0 )
p_shell->selected_index += p_shell->total_buffered_cmds;

[Cao, Minggui] there is a rule for history cmds: it is not a loop,
if press up or down key always, it will go up/down to the first or
last command as the end one, so the user will know the history is to end.
1. if the ring buffer not full, up key will go until 0 index, then
it will not change any more.
2. if the ring buffer is full, up key will also go to an end index
too and will not change any more then.

Why we need this kind of difference? I am not convinced/

[Cao, Minggui] OK, let me explain in detailed, Let me give two examples:

1. if ring buffer full is 8, now buffered index: 0, 1, 2, 3, total_buffered_cmds is 4;
if up key on and on, it will go as:
3-->2-->1-->0, and then if up key again, it keeps as 0, and not change
again.
2. if ring buffer is full, and buffered index order is: 4, 5, 6, 7, 0, 1, 2 ,3, and start
from 3, for up keys, it will go as:
3->2->1->0->7->6->5->4, and then keeps as 4, not change again for
more up keys.

How about this way:
Next_index = cur_index - 1;
If (next_index < 0)
Next_index += 8;
If (buffered_line [next] is not empty)
Cur_index = next_index.


This way, both situation can be handled.

When I check bash, found it is not a loop, I think the reason is user-friendly:
user can know when it is the end of the history buffered cmds.

As the two cases, I have not found how to unify the code; if adopt the above
code, it is a loop, it is fine, but not user-friendly, the user could search more
time.

I updated this patch to V3, and sent it out, combine "input_line"
and "buffered_cmds" as "buffered_line", and simplify some logic as
your

comments.

Could you have a review?