Hi,

maybe we can improve the cursor position in textfields (search box, limit
display box): currently it is always at the _beginning_ of textfields, even
when there is text in them already.

Here is how aptitude behaves now:
 1. Open the Search box (For example with the '/' key)
 2. Insert some text and press OK
 3. Open the Search box again, the cursor is shown at the _beginning_ of the
    previously inserted text.
 4. To replace the text the user can:
    a. Insert a new text directly, _replacing_ the current one altogether
    b. Use the right arrow key to put the cursor at the end of the text and
       use Backspace to delete it (Del/Canc does not seem to work).

I observed myself doing 4b. most of the time (I should really say "always"),
and moving the cursor is kind of annoying.

However, if it was decided that the cursor has to be shown at the _end_ of the
text box then 4a. would not be look right either, the user would expect to
_append_ new characters to the text when inserting something new.

Bottomline, I propose to put the cursor at the _end_ of the text in textfields
and only allow to delete the text with backspace, in order to follow what IMHO
are the "expectations" of most of the users.

If the current behavior depends on ncurses and not directly on aptitude, then
sorry for the noise.

With Kind Regards,
   Antonio Ospite
http://ao2.it

Hi Antonio,

2011-02-17 10:15 Antonio Ospite:

I was never very happy about this behaviour, but now that it's been like
that for more than a decade, I am not sure if it's a good idea to change
it, breaking the assumptions of users.

Thus marking as +moreinfo to give it some consideration about what to
do.


Also, if you haven't discovered that yet, note that you can use keys
"End" and shortcut "Control-e" (as in emacs, bash, etc) to go to the end
of the line, or "Home" and "Control-a" to move to the beginning.

"Control-u" removes the line from the beginning to the position of the
cursor, and "Control-k" from the current position until the end of the
line.  Possibly other shortcuts work as well.


Cheers.

Hi Manuel, thanks for getting back on this issue.

Ctrl-k is a good work-around for my use case and the current behavior,
thanks.

I still think that the natural position of the cursor should be at the
end of the already inserted text, and I would like to hear the opinion
of others about it, but I will survive even without all that :)

Ciao ciao,
   Antonio

Hi,

Antonio Ospite wrote:
false (which is the default). If set to true, the cursor is always at
the end of the shown text.

I never was annoyed by that because I always use
aptitude::UI::Minibuf-Prompts=true, but I would be annoyed if the
mini-buffer would behave like the search box does.

I think, we should make both cases behave the same way. And from my
point of view, the "right" way is that the cursor should be at the end
of the text, too.

		Regards, Axel

Hi both,

2015-10-01 23:19 Axel Beckert:

Thanks for the input.  I also think that it's the best thing to do in
general, I am just afraid of breaking user expectations after many years
being this way.

The other slightly weird issue is that it clears the input as soon as
one starts typing, rightly pointed out in the original submission, maybe
some people rely on that behaviour by now.

With mini-buffer, at least some text inputs (search, limits, grouping)
behave in the same way when typing -- previous input is also cleared.
Which doesn't make sense to me, why to have anything at all if you are
clearing when starting to type?  Specially if you go to the trouble to
move the cursor to the end?


And here's a nice trick: with minibuf=true, pressing 'right arrow' (or
end, ctrl-e, etc) and typing, doesn't clear the text, even if the cursor
is in the same position :-)

Conversely, with minubuf=false, the cursor starts in the beginning and
clears when typing, but if you press 'left arrow' or home or ctrl-a, it
doesn't, stays in the same position but when typing now inserts instead
of clearing.


BTW, this was changed to be in the beginning of the line (not for
minibuf=true, it seems) back in 2001, version 0.2.9-1, after a user
requested it:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120890

What do you think about that report?


I guess that it's better to change the behaviour, put the cursor in the
end in both cases, and not delete.  If people are unhappy I am sure that
we will receive hate mail^W^W new bug reports.

But still, that Daniel Burrows thinks that "it's clearly much better
than the current behavior" is intriguing.


Cheers.

Hi,

Manuel A. Fernandez Montecelo wrote:

Well, it's the expectation that they have to press End/Ctrl-E before
extending the pattern. That will still work, the Ctrl-E will be just
redundant.

Yes, I consider that a feature, despite I dislike it. It seems quite
common, at least mutt uses that feature, too.

Yep, I'm just experienced with the mini-buffer input and it behaves
there as described.

The idea behind that is probably the following:

Typing "/somesearchpattern<Enter>" should just work.

So if you type any printable character, the previous string is
discarded. But if start to edit it, i.e. press Backspace, cursor keys
or End, you can edit it.

Thanks for digging that up.

Hrm, there it's mostly about not seeing the whole contents and not
about where to start to edit. And I'd rather would like to see the end
than the beginning, because usually these kind of strings get
developed recursively by adding stuff at the end. So if I only see the
beginning, it's unclear at which iteration I am.

But then again, I do agree that for the specific case of grouping,
this is probably different. I though consider it a special case as
that's a thing you edit very seldom compared to e.g. searching or
limiting.

I'd say we should stay consistent with what people are used to from
other tools. And the current behaviour is unknown to me anywhere else.

Since aptitude refers to mutt for its design patterns in some places,
we could use mutt as pattern again:

* Start at the end
* Delete current contents upon typing the first printable character

Then again, vim and less start with a cleared search field and you
have to press cursor-up to get the previous search item.

So I'd be ok with both of these behaviour patterns. I'd refer in the
changelog to the application from which the pattern has been taken as
an argument for consistency. (And then someone will refer to the other
tool in a bug report, sure... ;-)

While I clearly agree and starting at the end, I'm unsure about the
automatic delete on typing. I assume I probably would prefer the text
to not be deleted automatically as I'm a mutt user, but not a vim
user, but I probably can only tell if I was able to compare it.

I nevertheless disagree at this point.

		Regards, Axel

2015-10-02 08:44 Axel Beckert:

I basically agree on the above.  I am not sure if the text should clear
when typing visible letters or not, it is true that mutt behaves in the
same way, but at least I also think that the cursor should start at the
end of the line.


Anyway, after one or two hours investigating, it doesn't seem achievable
without bypassing prompt_string in ui.{h,cc}, which uses
cwidget::dialogs::string().  It creates the "dialog window" as a whole,
and there doesn't seem to be any way to retrieve the editline even
directly or indirectly (e.g. looking to their children) -- it doesn't
expose any interface for that.

I don't think that it's a good idea to create the dialogs "by hand" in
aptitude, so I think that it's better to add the mechanisms in cwidget
first.


Cheers.