bug#22112: 24.5; lockup in shell-script-mode with missing newline at eof

bug#22112: 24.5; lockup in shell-script-mode with missing newline at eof

[Tony Finch]

In an empty shell-script buffer, I type
	i
        f
        left

This causes emacs to lock up, consuming CPU in a tight loop without
responding to the user interface.

The problem occurs when there is an "if" statement on the last line of
the buffer, and the buffer does not end in a newline. The "if" does not
have to be right at the end of the buffer - there can be a conditional
command. Movement or editing attempts around this line usually cause a
lockup.

Standard rubric follows...

In GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
of 2015-04-10 on builder10-9.porkrind.org
Windowing system distributor `Apple', version 10.3.1404
Configured using:
`configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp''

Important settings:
  locale-coding-system: utf-8-unix

Major mode: Shell-script

Minor modes in effect:
  sh-electric-here-document-mode: t
  show-paren-mode: t
  global-whitespace-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Wrote /Users/fanf/.emacs
Mark set
Mark activated [2 times]
t.sh has auto save data; consider M-x recover-this-file
Setting up indent for shell type sh
Indentation variables are now local.
Indentation setup for shell type sh
Quit
Buffer *unsent mail to bug-gnu-emacs@gnu.org* modified; kill anyway? (y or n) y
Making completion list...

Load-path shadows:
None found.

Features:
(sh-script smie executable mule-util vc-git jka-compr find-func
help-mode pp shadow sort gnus-util mail-extr emacsbug message
format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils fanf-theme
go-mode-autoloads lua-mode derived advice help-fns edmacro kmacro
cl-macs compile rx comint ansi-color ring cl gv cl-loaddefs cl-lib paren
whitespace cus-start cus-load time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
cocoa ns multi-tty emacs)

Memory information:
((conses 16 111756 13871)
(symbols 48 20921 0)
(miscs 40 138 265)
(strings 32 20354 3268)
(string-bytes 1 560447)
(vectors 16 13116)
(vector-slots 8 422660 7712)
(floats 8 65 365)
(intervals 56 877 210)
(buffers 960 20))

bug#22112: 24.5; lockup in shell-script-mode with missing newline at eof

[Glenn Morris]

Tony Finch wrote:

> In an empty shell-script buffer, I type
> 	i
>         f
>         left
>
> This causes emacs to lock up, consuming CPU in a tight loop without
> responding to the user interface.

I'm unable to reproduce this with:

  emacs-24.5 -Q foo.sh

bug#22112: 24.5; lockup in shell-script-mode with missing newline at eof

[Alan J Third]

Tony Finch <dot@dotat.at> writes:

> In GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
> of 2015-04-10 on builder10-9.porkrind.org

I believe I'm running the exact same build:

"GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
 of 2015-04-10 on builder10-9.porkrind.org"

but I can't reproduce this either. If you run emacs using

/Applications/Emacs.app/Contents/MacOS/Emacs -Q

Does it still happen?

--
Alan Third

bug#22112: 24.5; lockup in shell-script-mode with missing newline at eof

[Alan Third]

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

I've managed to replicate this on a Windows PC: GNU Emacs 24.5.1
(i686-pc-mingw32) of 2015-04-11 on LEG570

Run emacs -Q

Evaluate:

    (show-paren-mode +1)

Open a new shell script buffer:

    C-x b test <RET> M-x shell-script-mode

and type:

    if<left arrow>

If I don't turn on show-paren-mode there is no hang and Emacs carries on
happily.
-- 
Alan Third

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

bug#22112: 24.5; lockup in shell-script-mode with missing newline at eof

[Tony Finch]

Alan Third <alan@idiocy.org> wrote:

> If I don't turn on show-paren-mode there is no hang and Emacs carries on
> happily.

Excellent, thanks for pursuing this. Yes, I had show-paren-mode on.

Sorry I wasn't able to find the time to pin it down myself.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
South Utsire, Forties, Cromarty: Cyclonic, mainly southeasterly, 6 to gale 8,
decreasing 4 or 5 at times. Rough or very rough, occasionally moderate later.
Rain or sleet. Good, occasionally poor.

bug#22112: 24.5; lockup in shell-script-mode with missing newline at eof

[Alan J Third]

Alan Third <alan@idiocy.org> writes:

> I've managed to replicate this on a Windows PC: GNU Emacs 24.5.1
> (i686-pc-mingw32) of 2015-04-11 on LEG570
>
> Run emacs -Q
>
> Evaluate:
>
> (show-paren-mode +1)
>
> Open a new shell script buffer:
>
> C-x b test <RET> M-x shell-script-mode
>
> and type:
>
> if<left arrow>
>
> If I don't turn on show-paren-mode there is no hang and Emacs carries
> on happily.

I can't reproduce this against Emacs 25.1.50.1 so I'm marking it as
fixed. If you later upgrade and it's still broken for you, please
reopen the bug.

-- 
Alan Third

bug#22112: Processed: bug#22112

[Glenn Morris]

GNU bug tracker automated control server wrote:

> Processing commands for control@debbugs.gnu.org:
>
>> close 22112 25.1.50.1

It's not worth changing now, but the right version number to use would
be "25.1", since that is the first release in which this will be fixed.

"25.1.50" is a fairly meaningless development version that applies to a
huge range of git revisions. The final ".1" is a build number that is
irrelevant.