bug#38802: new data

bug#38802: new data

[Samuel Wales]

this bug is infrequent, but of course the possible loss of data and
opportunity cost is there.

new data consistent with my suspicion that type-break + password-type
prompt can cause the bug and also can fix it:

here is a case of type-break probably causing and then fixing the bug
around the time of a password-type prompt:

n is undefined
ding nil
n is undefined
ding nil
a is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
<f6> is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
C-g is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil
ESC is undefined
ding nil [2 times]
[20:37] Take a break from typing now? (y or n) y
Press any key to resume from typing break.
[20:38] You really ought to rest 14 minutes more.  Continue break? (y or n) n

it seems possible type-break activated at prompt, although i don't
remember what it could have done as i don't have it issue warnings.
it then fixed the bug by prompting me.  i likely said y, then n n.

it seems possible that it would also fix if you did nothing until
type-break prompted.  thanks all.


p.s.  incidentally, although i did not open a new bug yet, there is a
bug in type-break in which it prompts via minibuffer if it /started/
when you were using minibuffer, otherwise dialog box.  it should be
the time of asking, not starting.



-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#38802: new data

[Lars Ingebrigtsen]

Samuel Wales <samologist@gmail.com> writes:

> [20:37] Take a break from typing now? (y or n) y
> Press any key to resume from typing break.
> [20:38] You really ought to rest 14 minutes more.  Continue break? (y or n) n
>
> it seems possible type-break activated at prompt, although i don't
> remember what it could have done as i don't have it issue warnings.
> it then fixed the bug by prompting me.  i likely said y, then n n.
>
> it seems possible that it would also fix if you did nothing until
> type-break prompted.  thanks all.

Sorry; I don't understand what you mean here.  Can you rephrase?

bug#38802: new data

[Samuel Wales]

i am limited in computer use so i hope this helps.

sequence:

  - i ran a command in shell mode
  - that command issued a password prompt
  - that prompt was recognized by comint-password-prompt-regexp
    - it appeared in minibuffer

i surmise that type-break did something around that time due to its
keystroke or time count, causing bug.  to continue:

  - i flailed around not wanting to lose data or state
  - keypresses not recognized
  - this is the usual bug state
  - message buffer shows all this for you

then, fortune intervened.  type-break prompted for whatever reason.  i
interacted with the type-break prompt.

note that i was ABLE to interact with it.  it had magical bug-evading
powers.  nothing else in emacs that i know of does.

e.g. it was not in a state where self-insert-command was undefined
when i interacted with it.

i indicated to type-break to not continue the break.  it complied.

then emacs operated normally.  that is the best i can do to try to rephrase.

idk if type-break tried to issue a first prompt.  but my guess is that
the temporally nearby combination of password entry state and an
action that type-break took [e.g. issuing a prompt or perhaps trying
to do so] caused the bug.

[never mind the stuff about type-break warnings.  i was trying to
speculate why there would be no indication of what type-break did in
the messags buffer but that speculation doesn't really make sense so
you can ignore it.]


On 8/14/22, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> [20:37] Take a break from typing now? (y or n) y
>> Press any key to resume from typing break.
>> [20:38] You really ought to rest 14 minutes more.  Continue break? (y or
>> n) n
>>
>> it seems possible type-break activated at prompt, although i don't
>> remember what it could have done as i don't have it issue warnings.
>> it then fixed the bug by prompting me.  i likely said y, then n n.
>>
>> it seems possible that it would also fix if you did nothing until
>> type-break prompted.  thanks all.
>
> Sorry; I don't understand what you mean here.  Can you rephrase?
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#38802: new data

[Lars Ingebrigtsen]

Samuel Wales <samologist@gmail.com> writes:

> sequence:
>
>   - i ran a command in shell mode
>   - that command issued a password prompt
>   - that prompt was recognized by comint-password-prompt-regexp
>     - it appeared in minibuffer
>
> i surmise that type-break did something around that time due to its
> keystroke or time count, causing bug.  to continue:
>
>   - i flailed around not wanting to lose data or state
>   - keypresses not recognized
>   - this is the usual bug state
>   - message buffer shows all this for you

Ah, thanks -- so you were entering a password, and the type-break.el
stuff triggered, and that made Emacs hang?  `C-g' or anything didn't
work?

bug#38802: new data

[Samuel Wales]

hi lars,

yes, that seems to be the case here.

type-break fixing itself like this is very rare.  usually nothing
works at the time.  always the impudent message.

^g fails along with ALL keys that i am aware of.  technically i would
not call it a hang of emacs.  however, emacs is completely
inaccessible.  [except perhaps for its sigusr1/sigusr2 stuff?  i have
no evidence of that and brain cannot put together code that i know
will be useful.  and possibly except for some very long timeout that
could hypothetically get type-break to fix itself after your
deadline.]


On 8/17/22, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> sequence:
>>
>>   - i ran a command in shell mode
>>   - that command issued a password prompt
>>   - that prompt was recognized by comint-password-prompt-regexp
>>     - it appeared in minibuffer
>>
>> i surmise that type-break did something around that time due to its
>> keystroke or time count, causing bug.  to continue:
>>
>>   - i flailed around not wanting to lose data or state
>>   - keypresses not recognized
>>   - this is the usual bug state
>>   - message buffer shows all this for you
>
> Ah, thanks -- so you were entering a password, and the type-break.el
> stuff triggered, and that made Emacs hang?  `C-g' or anything didn't
> work?
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com