bug#3943: 23.0.96; CPerl-mode is too electric

bug#3943: 23.0.96; CPerl-mode is too electric

[Rommerskirchen, Heinrich (NSN - DE/Munich)]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing
list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

In CPerl-Mode the '<' inside a while statement completes not only to
'<>' which is fine, but adds another set of brackets, so that you end up
with
--- example start
while (<>) {
} ( ) {
}
--- example end
instead of the reasonble
--- example start
while (<>) {

}
--- example end
what was the result in former versions.

To duplicate this I started emacs with '-Q' and loaded a file containing
-- start of file
(autoload 'cperl-mode  "cperl-mode" t t)
(setq cperl-hairy t)            ; Alle Features on
(setq cperl-indent-level 4)
(setq cperl-auto-newline t)     ; Einrueckung und Leerzeile bei ';' usw.
(setq auto-mode-alist
      (append '(("\\.\\([pP][Llm]\\|al\\)$" . cperl-mode))
auto-mode-alist ))
-- end of file
the CPerl configuration I have used for a few years

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
d:/bin/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.0.96.1 (i386-mingw-nt5.1.2600)
 of 2009-07-09 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: DEU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: CPerl

Minor modes in effect:
  tooltip-mode: t
  tool-bar-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
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
M-x l o a d - f i l <return> t m p / t e <tab> . e 
<tab> <return> C-x C-f t e s t . p l <return> w h i 
l e SPC SPC < <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading d:/tmp/test.el (source)...done
(New file)
Precede char by C-q to avoid expansion [2 times]
<>	Reads line from union of files in @ARGV (= command line) and
STDIN. [2 times]

bug#3943: 23.0.96; CPerl-mode is too electric

[Chong Yidong]

Hi Ilya,

Could you take a look at the following bug report?  Thanks.

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3943

bug#3943: 23.0.96; CPerl-mode is too electric

[Ilya Zakharevich]

On Sat, Aug 15, 2009 at 01:14:47AM -0400, Chong Yidong wrote:
> Hi Ilya,
> 
> Could you take a look at the following bug report?  Thanks.
> 
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3943

The home of CPerl is ilyaz.org/software/emacs

Please report results with my version.  (The shipped-with-Emacs
version is hopelessly buggy...)

Thanks,
Ilya

bug#3943: 23.0.96; CPerl-mode is too electric

[Chong Yidong]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> The home of CPerl is ilyaz.org/software/emacs
>
> Please report results with my version.  (The shipped-with-Emacs
> version is hopelessly buggy...)

Then we should update the version in the Emacs repository.  Is 6.2 the
stable version?

bug#3943: 23.0.96; CPerl-mode is too electric

[Ilya Zakharevich]

On Sun, Aug 16, 2009 at 09:23:58AM -0400, Chong Yidong wrote:
> Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
> 
> > The home of CPerl is ilyaz.org/software/emacs
> >
> > Please report results with my version.  (The shipped-with-Emacs
> > version is hopelessly buggy...)
> 
> Then we should update the version in the Emacs repository.  Is 6.2 the
> stable version?

Yes.  But it is not conforming to the style policy (and never would).

Hope this helps,
Ilya

bug#3943: 23.0.96; CPerl-mode is too electric

[Chong Yidong]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

>> Could you take a look at the following bug report?  Thanks.
>> 
>> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3943
>
> The home of CPerl is ilyaz.org/software/emacs
>
> Please report results with my version.  (The shipped-with-Emacs
> version is hopelessly buggy...)

The problem exists in upstream CPerl as well.  The bug arises from line
3763 (cperl-electric-paren):

  (if (eq last-command-char ?<)
      (progn
        (and abbrev-mode ; later it is too late, may be after `for'
             (expand-abbrev))
        (cperl-after-expr-p nil "{;(,:="))
    1))

Because one abbrev expansion already takes place when typing "while ",
this code leads to another, extra expansion.  Removing the
(and abbrev-mode...) expression fixes the problem.

bug#3943: 23.0.96; CPerl-mode is too electric

[Ilya Zakharevich]

On Sun, Aug 16, 2009 at 07:24:23PM -0400, Chong Yidong wrote:
> The problem exists in upstream CPerl as well.  The bug arises from line
> 3763 (cperl-electric-paren):
> 
>   (if (eq last-command-char ?<)
>       (progn
>         (and abbrev-mode ; later it is too late, may be after `for'
>              (expand-abbrev))
>         (cperl-after-expr-p nil "{;(,:="))
>     1))
> 
> Because one abbrev expansion already takes place when typing "while ",
> this code leads to another, extra expansion.  Removing the
> (and abbrev-mode...) expression fixes the problem.

A lot of thanks for investigating this problem!

  >>TODO

Thanks again,
Ilya

bug#3943: 23.0.96; CPerl-mode is too electric

[Ilya Zakharevich]

On Sun, Aug 16, 2009 at 07:24:23PM -0400, Chong Yidong wrote:
> The problem exists in upstream CPerl as well.  The bug arises from line
> 3763 (cperl-electric-paren):
> 
>   (if (eq last-command-char ?<)
>       (progn
>         (and abbrev-mode ; later it is too late, may be after `for'
>              (expand-abbrev))
>         (cperl-after-expr-p nil "{;(,:="))
>     1))
> 
> Because one abbrev expansion already takes place when typing "while ",
> this code leads to another, extra expansion.  Removing the
> (and abbrev-mode...) expression fixes the problem.

The bug report does not contain the way to reproduce the problem.
From your description, I presume that it is typing

  while<

which leads to a double expansion.

Then it is an incompatible change in Emacs after v21 (which I can test
with).  I would much prefer code without explicit version-checking
(especially since there are a few independent branches); for this I
need a way to determine whether I'm inside `expand-abbrev'.

Is there a way to detect this?

Thanks,
Ilya

bug#3943: 23.0.96; CPerl-mode is too electric

[Chong Yidong]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> The bug report does not contain the way to reproduce the problem.
> From your description, I presume that it is typing
>
>   while<
>
> which leads to a double expansion.

It's from typing "while <".  You must type a space after the "while".

bug#3943: 23.0.96; CPerl-mode is too electric

[Ilya Zakharevich]

On Tue, Aug 18, 2009 at 12:59:27PM -0400, Chong Yidong wrote:
> Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
> 
> > The bug report does not contain the way to reproduce the problem.
> > From your description, I presume that it is typing
> >
> >   while<
> >
> > which leads to a double expansion.

> It's from typing "while <".  You must type a space after the "while".

If one is inside parens in

   while () {
   }

and types
  <
, would this lead to the abnormal behaviour?


If yes, then would typing M-x expand-abbrev (instead of "<") lead to
the same abnormal behaviour?  (Then it is, IMO, a bug in expansion
logic...)

Yours,
Ilya