bug#46609: Fix shell password prompt in minibuffer (bug 43302)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#46609: Fix shell password prompt in minibuffer (bug 43302)

Eli Zaretskii
> Date: Thu, 18 Feb 2021 01:13:58 +0000
> From:  Ryan Prior via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[hidden email]>
>
> I am not a Unicode expert and don't know if there might be undesirable
> side-effects from using :space: instead of :blank:. However, in my
> manual testing these change give me the exact behavior I'm after.

I'm a bit worried by the [[:space:]]* part: it would match any number
of newlines and ^L characters, right?  Is that what we want here?

Perhaps it would be safer to just add a literal newline, and only
once?  Especially for the emacs-27 branch?



Reply | Threaded
Open this post in threaded view
|

bug#46609: Fix shell password prompt in minibuffer (bug 43302)

Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> writes:

>> I think so -- matching "Password: \n\n" makes as much sense as matching
>> "Password: \n", I think?
>
> It actually happens in Real Life?

I wouldn't have thought so, but then again, I wouldn't have thought that
anybody had even a single newline in the prompt, so my intuitions here
don't count for much.  

> What bothers me is that we could takes something unrelated as a
> password prompt.

If I understand the comint code correctly, it'll match this stuff if
it's the final thing that has been output.  So there should be little
danger in faulty matching here.  But I'm not overly confident in my
understanding of that code.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no