[Aptitude-devel] Bug#613794: Bug#613794: aptitude: cursor position in textfields. Usability improvement.

[Axel Beckert]

Hi,

Manuel A. Fernandez Montecelo wrote:
> > 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.
> 
> 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.

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.

> 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.

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

> With mini-buffer, at least some text inputs (search, limits, grouping)
> behave in the same way when typing -- previous input is also cleared.

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

> 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?

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.

> 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

Thanks for digging that up.

> What do you think about that report?

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... ;-)

> 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.

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.

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

I nevertheless disagree at this point.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE