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

[Manuel A. Fernandez Montecelo]

Control: block -1 by 801821


2015-10-02 08:44 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.

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.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>