bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 17 Nov 2017 18:36:32 +0000
> Cc: 29326@debbugs.gnu.org
> 
> Also by running the gdb in the src/ dir, the backtrace looks a bit different 
> (instead of SIGABRT plus putting out
> core dump in gdb, this time the error is concise and code is SIG_DFL
> instead)

No, it's still SIGABRT:

> xdisp.c:2752: Emacs fatal error: assertion failed: charpos < 0 || (charpos >= 
> BUF_BEG (current_buffer) &&
> charpos <= ZV)
> 
> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, 
> backtrace_limit=2147483647) at emacs.c:364
                                                                                
                        ^^^^^^^

"sig=6" means SIGABRT (you can see that in your system's header files,
probably in /usr/include/bits/signum.h).

> 364       signal (sig, SIG_DFL);

This just shows the source line where Emacs stopped due to the fatal
signal.  It has nothing to do with the signal itself.

> Lisp Backtrace:
> "line-number-display-width" (0xffff37e0)
> "line-move-visual" (0xffff4030)
> "line-move" (0xffff4780)
> "let" (0xffff4b80)
> "condition-case" (0xffff4e70)
> "nim-line-move" (0xffff5030)

Thanks, I installed a change which should fix this.  Please try the
latest release branch.

> Org is displaying the nim-mode buffers in org-mode, but does something like 
> enabling the code block's major
> mode only for that code snippet to do indentation, commenting etc. (the 
> native line number enabling would be
> a part of that I believe).

Org copies the snippet to a separate buffer, turns on nim-mode in that
buffer, then indents the text, and finally copies the text back.  The
problem happened because the window-start position was not updated
during this dance, and still had the value suitable to the Org buffer,
which is outside of the valid positions in the temporary edit buffer.