bug#50900: 27.2; Evaluating open-line with a negative argument changes the behavior of self-insert

bug#50900: 27.2; Evaluating open-line with a negative argument changes the behavior of self-insert

[Rodrigo Morales]

In order to reproduce this bug, I deleted my ~/.config/emacs/init.el
file and made sure that no other Emacs configuration file existed in
$HOME.

Steps to reproduce this bug:

1. Evaluate (open-line -1)
2. Insert text in any buffer

You will see that whenever a character is inserted, the point is moved
to the beginning of the line.

bug#50900: 27.2; Evaluating open-line with a negative argument changes the behavior of self-insert

[Lars Ingebrigtsen]

Rodrigo Morales <moralesrodrigo1100@gmail.com> writes:

> In order to reproduce this bug, I deleted my ~/.config/emacs/init.el
> file and made sure that no other Emacs configuration file existed in
> $HOME.

That shouldn't be necessary -- "emacs -Q" will start an Emacs without
any local customisations.

> Steps to reproduce this bug:
>
> 1. Evaluate (open-line -1)
> 2. Insert text in any buffer

I'm unable to reproduce the problem in Emacs 27.2 (or 28).  I said:

emacs -Q
M-: (open-line -1)

And then I just get this backtrace:

Debugger entered--Lisp error: (error "Negative repetition argument -1")
  self-insert-command(-1)
  newline(-1)
  open-line(-1)
  eval((open-line -1) t)
  eval-expression((open-line -1) nil nil 127)
  funcall-interactively(eval-expression (open-line -1) nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

> You will see that whenever a character is inserted, the point is moved
> to the beginning of the line.

I don't see that, either.  What does `C-h f open-line RET' say for you?

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

bug#50900: 27.2; Evaluating open-line with a negative argument changes the behavior of self-insert

[Gregory Heytings]

A recipe:

emacs -Q
M-: (open-line -1)
C-x o
foobar

IOW, do not quit the debugger.  That "bug" was not present in Emacs 24, it 
exists in Emacs 25 and later.  But I'm not sure it qualifies as a "bug".

bug#50900: 27.2; Evaluating open-line with a negative argument changes the behavior of self-insert

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> A recipe:
>
> emacs -Q
> M-: (open-line -1)
> C-x o
> foobar
>
> IOW, do not quit the debugger.  That "bug" was not present in Emacs
> 24, it exists in Emacs 25 and later.  But I'm not sure it qualifies as
> a "bug".

Heh.  It's an oddity for sure.  And fixing it's pretty easy -- I've now
made `newline' check the argument earlier (before it starts binding all
those variables that affect...  stuff).

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

bug#50900: 27.2; Evaluating open-line with a negative argument changes the behavior of self-insert

[Rodrigo Morales]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

Sorry, I wasn't clear in my previous message.

Before you evaluate the expression, you have to be in a buffer with no
read-only-mode. This means that if you tried to reproduce the issue in
the "*GNU Emacs*" buffer, you didn't fully reproduce the bug. For
some reason, the bug doesn't happen when the expression is evaluated
in a buffer with read-only-mode.

Here are more clearer steps:

1. Execute "emacs -Q"
2. Evaluate (open-line -1) in the "*scratch*" buffer.
3. Move your cursor to the "*scratch*" buffer.
4. Insert any text
5. (At this point, whenever you insert a character, the cursor is
   moved to the beginning of the line which makes it seem that you are
   typing from left to right.)

I was able to reproduce this issue in emacs 27.2 (in two systems) and
emacs 26.2 (in one system).

On Wed, 29 Sept 2021 at 14:07, Rodrigo Morales <moralesrodrigo1100@gmail.com>
wrote:

>
> In order to reproduce this bug, I deleted my ~/.config/emacs/init.el
> file and made sure that no other Emacs configuration file existed in
> $HOME.
>
> Steps to reproduce this bug:
>
> 1. Evaluate (open-line -1)
> 2. Insert text in any buffer
>
> You will see that whenever a character is inserted, the point is moved
> to the beginning of the line.
>

[-- Attachment #2: Type: text/html, Size: 1691 bytes --]

bug#50900: 27.2; Evaluating open-line with a negative argument changes the behavior of self-insert

[Rodrigo Morales]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

> 5. (At this point, whenever you insert a character, the cursor is
>    moved to the beginning of the line which makes it seem that you are
>    typing from left to right.)

Typo: "right-to-left" instead of "from left to right"

[-- Attachment #2: Type: text/html, Size: 329 bytes --]

bug#50900: 27.2; Evaluating open-line with a negative argument changes the behavior of self-insert

[Rodrigo Morales]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

This is a response to the message of Lars. Apparently, we get the same
backtrace.

```
Debugger entered--Lisp error: (error "Negative repetition argument -1")
  self-insert-command(-1)
  newline(-1)
  open-line(-1)
  eval((open-line -1) t)
  eval-expression((open-line -1) nil nil 127)
  funcall-interactively(eval-expression (open-line -1) nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)
```

This is what C-h f open-line RET shows

```
open-line is an interactive compiled Lisp function in ‘simple.el’.

It is bound to C-o, <insertline>.

(open-line N)

  Probably introduced at or before Emacs version 19.29.

Insert a newline and leave point before it.
If there is a fill prefix and/or a ‘left-margin’, insert them on
the new line if the line would have been blank.
With arg N, insert N newlines.
```

On Wed, 29 Sept 2021 at 15:38, Rodrigo Morales <moralesrodrigo1100@gmail.com>
wrote:

> > 5. (At this point, whenever you insert a character, the cursor is
> >    moved to the beginning of the line which makes it seem that you are
> >    typing from left to right.)
>
> Typo: "right-to-left" instead of "from left to right"
>

[-- Attachment #2: Type: text/html, Size: 1792 bytes --]