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.
