bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Saulius Menkevičius]

When writing code:

namespace X
{
    public class A: B<T>
    {$
($ above denotes cursor position)

Typing [Enter] after the second { would trigger this error:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  signal(wrong-type-argument (stringp nil))
  c-syntactic-re-search-forward(nil nil t t)
  c-forward-<>-arglist-recur(nil)
  c-forward-<>-arglist(nil)
  c-backward-<>-arglist(nil nil)
  c-looking-at-decl-block(13 t)
  c-guess-basic-syntax()
  c-indent-line()
  indent-according-to-mode()
  evil-open-below(1)
  funcall-interactively(evil-open-below 1)
  call-interactively(evil-open-below nil nil)
  command-execute(evil-open-below)

Note, that typing [Enter] after non-generic class inheritance would work ok (no error would get triggered):

namespace X
{
    public class A: B
    {$

I *think* it could be related to this commit (will test):
    commit 02b037b85ce32fdcf454f5b12d72f09bcb217891
    Author: Alan Mackenzie <acm@muc.de>
    Date:   Mon Feb 15 12:45:42 2016 +0000

        Allow arithmetic operators inside C++ template constructs.




In GNU Emacs 25.0.92.3 (x86_64-apple-darwin15.3.0, NS appkit-1404.34 Version 10.11.3 (Build 15D21))
 of 2016-03-17 built on mbp.local
Repository revision: 9ab03f27fad7b1ae68dda7a2effd075658dcf184
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
 'configure --with-gnutls --with-ns'

Configured features:
JPEG DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: de_LT
  locale-coding-system: utf-8

Major mode: mu4e-headers

Minor modes in effect:
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  diff-auto-refine-mode: t
  display-battery-mode: t
  display-time-mode: t
  erc-services-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  helm-mode: t
  evil-leader-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  evil-mode: t
  evil-local-mode: t
  winner-mode: t
  recentf-mode: t
  ido-everywhere: t
  global-hl-line-mode: t
  hl-line-mode: t
  projectile-global-mode: t
  projectile-mode: t
  override-global-mode: t
  shell-dirtrack-mode: t
  image-diredx-async-mode: t
  savehist-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Error during redisplay: (jit-lock-function 370) signaled (wrong-type-argument stringp nil)
Compilation finished
Auto-saving...
[mu4e] csharp-mode [2 times]
[mu4e] Found 11 matching messages
Autoswitch
(New file)
Mark set
Auto-saving...
Buffer *draft* modified; kill anyway? (y or n) y

Load-path shadows:
/Users/bob/.emacs.d/elpa/helm-20160316.2346/helm-multi-match hides /Users/bob/.emacs.d/elpa/helm-core-20160315.2246/helm-multi-match
/Users/bob/.emacs.d/elpa/color-theme-solarized-20160219.924/solarized-theme hides /Users/bob/.emacs.d/elpa/solarized-theme-20160311.1447/solarized-theme
/Users/bob/.emacs.d/elpa/flim-20151212.2350/md4 hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/md4
/Users/bob/.emacs.d/elpa/flim-20151212.2350/hex-util hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/hex-util
/Users/bob/.emacs.d/elpa/org-20160314/ox hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox
/Users/bob/.emacs.d/elpa/org-20160314/ox-texinfo hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-texinfo
/Users/bob/.emacs.d/elpa/org-20160314/ox-publish hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-publish
/Users/bob/.emacs.d/elpa/org-20160314/ox-org hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-org
/Users/bob/.emacs.d/elpa/org-20160314/ox-odt hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-odt
/Users/bob/.emacs.d/elpa/org-20160314/ox-md hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-md
/Users/bob/.emacs.d/elpa/org-20160314/ox-man hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-man
/Users/bob/.emacs.d/elpa/org-20160314/ox-latex hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-latex
/Users/bob/.emacs.d/elpa/org-20160314/ox-icalendar hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-icalendar
/Users/bob/.emacs.d/elpa/org-20160314/ox-html hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-html
/Users/bob/.emacs.d/elpa/org-20160314/ox-beamer hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-beamer
/Users/bob/.emacs.d/elpa/org-20160314/ox-ascii hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ox-ascii
/Users/bob/.emacs.d/elpa/org-20160314/org hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org
/Users/bob/.emacs.d/elpa/org-20160314/org-w3m hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-w3m
/Users/bob/.emacs.d/elpa/org-20160314/org-version hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-version
/Users/bob/.emacs.d/elpa/org-20160314/org-timer hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-timer
/Users/bob/.emacs.d/elpa/org-20160314/org-table hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-table
/Users/bob/.emacs.d/elpa/org-20160314/org-src hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-src
/Users/bob/.emacs.d/elpa/org-20160314/org-rmail hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-rmail
/Users/bob/.emacs.d/elpa/org-20160314/org-protocol hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-protocol
/Users/bob/.emacs.d/elpa/org-20160314/org-plot hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-plot
/Users/bob/.emacs.d/elpa/org-20160314/org-pcomplete hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-pcomplete
/Users/bob/.emacs.d/elpa/org-20160314/org-mouse hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-mouse
/Users/bob/.emacs.d/elpa/org-20160314/org-mobile hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-mobile
/Users/bob/.emacs.d/elpa/org-20160314/org-mhe hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-mhe
/Users/bob/.emacs.d/elpa/org-20160314/org-macs hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-macs
/Users/bob/.emacs.d/elpa/org-20160314/org-macro hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-macro
/Users/bob/.emacs.d/elpa/org-20160314/org-loaddefs hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-loaddefs
/Users/bob/.emacs.d/elpa/org-20160314/org-list hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-list
/Users/bob/.emacs.d/elpa/org-20160314/org-irc hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-irc
/Users/bob/.emacs.d/elpa/org-20160314/org-install hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-install
/Users/bob/.emacs.d/elpa/org-20160314/org-inlinetask hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-inlinetask
/Users/bob/.emacs.d/elpa/org-20160314/org-info hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-info
/Users/bob/.emacs.d/elpa/org-20160314/org-indent hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-indent
/Users/bob/.emacs.d/elpa/org-20160314/org-id hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-id
/Users/bob/.emacs.d/elpa/org-20160314/org-habit hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-habit
/Users/bob/.emacs.d/elpa/org-20160314/org-gnus hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-gnus
/Users/bob/.emacs.d/elpa/org-20160314/org-footnote hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-footnote
/Users/bob/.emacs.d/elpa/org-20160314/org-feed hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-feed
/Users/bob/.emacs.d/elpa/org-20160314/org-faces hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-faces
/Users/bob/.emacs.d/elpa/org-20160314/org-eshell hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-eshell
/Users/bob/.emacs.d/elpa/org-20160314/org-entities hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-entities
/Users/bob/.emacs.d/elpa/org-20160314/org-element hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-element
/Users/bob/.emacs.d/elpa/org-20160314/org-docview hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-docview
/Users/bob/.emacs.d/elpa/org-20160314/org-datetree hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-datetree
/Users/bob/.emacs.d/elpa/org-20160314/org-ctags hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-ctags
/Users/bob/.emacs.d/elpa/org-20160314/org-crypt hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-crypt
/Users/bob/.emacs.d/elpa/org-20160314/org-compat hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-compat
/Users/bob/.emacs.d/elpa/org-20160314/org-colview hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-colview
/Users/bob/.emacs.d/elpa/org-20160314/org-clock hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-clock
/Users/bob/.emacs.d/elpa/org-20160314/org-capture hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-capture
/Users/bob/.emacs.d/elpa/org-20160314/org-bibtex hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-bibtex
/Users/bob/.emacs.d/elpa/org-20160314/org-bbdb hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-bbdb
/Users/bob/.emacs.d/elpa/org-20160314/org-attach hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-attach
/Users/bob/.emacs.d/elpa/org-20160314/org-archive hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-archive
/Users/bob/.emacs.d/elpa/org-20160314/org-agenda hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/org-agenda
/Users/bob/.emacs.d/elpa/org-20160314/ob hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob
/Users/bob/.emacs.d/elpa/org-20160314/ob-tangle hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-tangle
/Users/bob/.emacs.d/elpa/org-20160314/ob-table hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-table
/Users/bob/.emacs.d/elpa/org-20160314/ob-sqlite hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-sqlite
/Users/bob/.emacs.d/elpa/org-20160314/ob-sql hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-sql
/Users/bob/.emacs.d/elpa/org-20160314/ob-shen hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-shen
/Users/bob/.emacs.d/elpa/org-20160314/ob-screen hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-screen
/Users/bob/.emacs.d/elpa/org-20160314/ob-scheme hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-scheme
/Users/bob/.emacs.d/elpa/org-20160314/ob-scala hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-scala
/Users/bob/.emacs.d/elpa/org-20160314/ob-sass hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-sass
/Users/bob/.emacs.d/elpa/org-20160314/ob-ruby hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-ruby
/Users/bob/.emacs.d/elpa/org-20160314/ob-ref hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-ref
/Users/bob/.emacs.d/elpa/org-20160314/ob-R hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-R
/Users/bob/.emacs.d/elpa/org-20160314/ob-python hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-python
/Users/bob/.emacs.d/elpa/org-20160314/ob-plantuml hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-plantuml
/Users/bob/.emacs.d/elpa/org-20160314/ob-picolisp hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-picolisp
/Users/bob/.emacs.d/elpa/org-20160314/ob-perl hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-perl
/Users/bob/.emacs.d/elpa/org-20160314/ob-org hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-org
/Users/bob/.emacs.d/elpa/org-20160314/ob-octave hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-octave
/Users/bob/.emacs.d/elpa/org-20160314/ob-ocaml hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-ocaml
/Users/bob/.emacs.d/elpa/org-20160314/ob-mscgen hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-mscgen
/Users/bob/.emacs.d/elpa/org-20160314/ob-maxima hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-maxima
/Users/bob/.emacs.d/elpa/org-20160314/ob-matlab hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-matlab
/Users/bob/.emacs.d/elpa/org-20160314/ob-makefile hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-makefile
/Users/bob/.emacs.d/elpa/org-20160314/ob-lob hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-lob
/Users/bob/.emacs.d/elpa/org-20160314/ob-lisp hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-lisp
/Users/bob/.emacs.d/elpa/org-20160314/ob-lilypond hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-lilypond
/Users/bob/.emacs.d/elpa/org-20160314/ob-ledger hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-ledger
/Users/bob/.emacs.d/elpa/org-20160314/ob-latex hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-latex
/Users/bob/.emacs.d/elpa/org-20160314/ob-keys hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-keys
/Users/bob/.emacs.d/elpa/org-20160314/ob-js hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-js
/Users/bob/.emacs.d/elpa/org-20160314/ob-java hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-java
/Users/bob/.emacs.d/elpa/org-20160314/ob-io hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-io
/Users/bob/.emacs.d/elpa/org-20160314/ob-haskell hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-haskell
/Users/bob/.emacs.d/elpa/org-20160314/ob-gnuplot hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-gnuplot
/Users/bob/.emacs.d/elpa/org-20160314/ob-fortran hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-fortran
/Users/bob/.emacs.d/elpa/org-20160314/ob-exp hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-exp
/Users/bob/.emacs.d/elpa/org-20160314/ob-eval hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-eval
/Users/bob/.emacs.d/elpa/org-20160314/ob-emacs-lisp hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-emacs-lisp
/Users/bob/.emacs.d/elpa/org-20160314/ob-dot hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-dot
/Users/bob/.emacs.d/elpa/org-20160314/ob-ditaa hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-ditaa
/Users/bob/.emacs.d/elpa/org-20160314/ob-css hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-css
/Users/bob/.emacs.d/elpa/org-20160314/ob-core hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-core
/Users/bob/.emacs.d/elpa/org-20160314/ob-comint hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-comint
/Users/bob/.emacs.d/elpa/org-20160314/ob-clojure hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-clojure
/Users/bob/.emacs.d/elpa/org-20160314/ob-calc hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-calc
/Users/bob/.emacs.d/elpa/org-20160314/ob-C hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-C
/Users/bob/.emacs.d/elpa/org-20160314/ob-awk hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-awk
/Users/bob/.emacs.d/elpa/org-20160314/ob-asymptote hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/org/ob-asymptote
/Users/bob/.emacs.d/elpa/soap-client-3.1.1/soap-inspect hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/soap-inspect
/Users/bob/.emacs.d/elpa/soap-client-3.1.1/soap-client hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/soap-client
/Users/bob/.emacs.d/elpa/flim-20151212.2350/sasl hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/sasl
/Users/bob/.emacs.d/elpa/flim-20151212.2350/sasl-ntlm hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/sasl-ntlm
/Users/bob/.emacs.d/elpa/flim-20151212.2350/sasl-digest hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/sasl-digest
/Users/bob/.emacs.d/elpa/flim-20151212.2350/sasl-cram hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/sasl-cram
/Users/bob/.emacs.d/elpa/flim-20151212.2350/ntlm hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/ntlm
/Users/bob/.emacs.d/elpa/flim-20151212.2350/hmac-md5 hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/hmac-md5
/Users/bob/.emacs.d/elpa/flim-20151212.2350/hmac-def hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/net/hmac-def
/Users/bob/.emacs.d/elpa/seq-20151121.1017/seq hides /Users/bob/bin/Emacs.app/Contents/Resources/lisp/emacs-lisp/seq

Features:
(shadow mail-extr emacsbug wdired debug nxml-uchnm rng-xsd xsd-regexp
rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse
rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln
nxml-rap nxml-util nxml-glyph nxml-enc xmltok omnisharp
omnisharp-settings omnisharp-server-actions omnisharp-utils flycheck
company-oddmuse company-keywords company-etags company-gtags
company-dabbrev-code company-dabbrev company-files company-capf
company-cmake company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb
omnisharp-auto-complete-actions company csharp-mode em-unix em-term
em-script em-prompt em-ls em-hist em-pred em-glob em-dirs em-cmpl
em-basic em-banner em-alias web-mode helm-cmd-t helm-config
helm-easymenu vc-annotate timezone parse-time shr-color network-stream
nsm starttls url-http tls gnutls url-gw url-cache url-auth eww mm-url
gnus gnus-ems nnheader url-queue shr dom helm-command helm-elisp
helm-eval edebug linum magit-blame magit-stash magit-bisect magit-remote
magit-commit magit-sequence magit magit-apply magit-wip magit-log
magit-diff smerge-mode magit-core magit-autorevert autorevert filenotify
magit-process magit-popup magit-mode magit-git crm magit-section
magit-utils git-commit log-edit pcvs-util with-editor async-bytecomp
async dabbrev php-mode flymake add-log cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs sh-script
smie executable vc vc-dispatcher org-rmail org-mhe org-irc org-info
org-gnus org-docview org-bibtex bibtex org-bbdb org-w3m find-cmd vc-git
diff-mode misearch multi-isearch prodigy f battery time hydra lv
helm-git-grep sunrise-commander sort find-dired esh-var esh-io esh-cmd
esh-opt esh-ext esh-proc esh-arg esh-groups eshell esh-module esh-util
esh-mode enriched desktop frameset erc-services erc-list erc-menu
erc-join erc-ring erc-networks erc-pcomplete erc-track erc-match
erc-button erc-fill erc-stamp erc-netsplit erc-goodies erc erc-backend
erc-compat gnus-dired org-mu4e org-element avl-tree mu4e mu4e-speedbar
speedbar sb-image ezimage dframe mu4e-main mu4e-context mu4e-view
mu4e-headers mu4e-compose mu4e-draft mu4e-actions rfc2368 smtpmail
sendmail mu4e-mark mu4e-message html2text mu4e-proc mu4e-utils doc-view
subr-x jka-compr image-mode mu4e-lists mu4e-vars message rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev mail-utils gmm-utils mailheader mu4e-meta ac-cider
cider cider-debug cider-browse-ns cider-inspector cider-mode
cider-resolve cider-interaction arc-mode archive-mode cider-overlays
cider-repl cider-test cider-stacktrace cider-doc org-table
cider-grimoire cider-popup cider-eldoc cider-client cider-common
cider-util clojure-mode align imenu nrepl-client queue ewoc etags xref
project cider-compat spinner find-file virtualenvwrapper gud helm-mode
helm-files rx ffap helm-buffers helm-elscreen helm-tags helm-bookmark
helm-adaptive helm-info bookmark pp helm-locate helm-grep helm-regexp
helm-plugin helm-external helm-net browse-url xml url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util url-parse url-vars mailcap helm-utils helm-help helm-types helm
helm-source eieio-compat helm-multi-match helm-lib ob-sql ob-sh ob-http
ob-http-mode ob-python org org-macro org-footnote org-pcomplete org-list
org-faces org-entities noutline outline org-version ob-emacs-lisp ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint
ob-core ob-eval org-compat org-macs org-loaddefs find-func cal-menu
calendar cal-loaddefs evil-leader evil evil-integration undo-tree diff
evil-maps evil-commands evil-jumps evil-command-window evil-types
evil-search evil-ex evil-macros evil-repeat evil-states evil-core
evil-common windmove rect evil-digraphs evil-vars eshell-ac-pcomplete
shell-toggle term disp-table ehelp exec-path-from-shell winner sql view
go-snippets yasnippet recentf tree-widget wid-edit whitespace dired+
image-file dired-x dired-aux ido hl-line server projectile grep compile
ibuf-ext ibuffer thingatpt spaceline-config spaceline-segments spaceline
powerline powerline-separators color powerline-themes dash auto-complete
edmacro kmacro popup use-package diminish bind-key easy-mmode pytest
python tramp-sh tramp tramp-compat auth-source cl-seq gnus-util mm-util
help-fns mail-prsvr password-cache tramp-loaddefs trampver shell
pcomplete json map seq comint ring ansi-color cl s zenburn-theme
finder-inf color-theme-approximate-autoloads color-theme-autoloads
etags-table-autoloads flycheck-color-mode-line-autoloads
go-mode-autoloads helm-projectile-all-autoloads image-dired+ image-dired
format-spec dired epc-autoloads ctable-autoloads eieio byte-opt bytecomp
byte-compile cl-extra help-mode cconv eieio-core cl-macs gv cl-loaddefs
pcase cl-lib logito-autoloads advice goto-chg-autoloads info
yas-jit-autoloads package easymenu savehist epa-file epa derived epg
epg-config time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded 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
dbusbind kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 1615948 113841)
 (symbols 48 71179 4)
 (miscs 40 2760 920)
 (strings 32 214841 36197)
 (string-bytes 1 6884160)
 (vectors 16 108729)
 (vector-slots 8 2332724 62635)
 (floats 8 1503 1161)
 (intervals 56 54703 4624)
 (buffers 976 77))

bug#23053: followup on 23053

[Saulius Menkevičius]

I performed a `git bisect' on the issue and apparently I was right on
guessing the culprit to be:

    commit 02b037b85ce32fdcf454f5b12d72f09bcb217891
    Author: Alan Mackenzie <acm@muc.de>
    Date:   Mon Feb 15 12:45:42 2016 +0000

        Allow arithmetic operators inside C++ template constructs.

-- 
Saulius Menkevičius (saulius.menkevicius@gmail.com)

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

While the error is encountered in csharp-mode (which is a non-official
Emacs-package) I think it's worth nothing that this didn't use to cause
errors in the past.

I've run this test-case against the "regular" Windows build 24.5.1,
using latest csharp-mode package and it runs fine. Trying latest Emacs
from git master on Ubuntu I can reproduce this error systematically
using the exact same version of csharp-mode.

In my opinion that makes this an Emacs-bug.

Whatever changes was done with cc-mode, it seems they're not fully
compatible with all derived modes out there. It might be worth reaching
out to other known third-party mode-developers basing their work on
cc-mode to see if they too have issues with the recent changes in git
master?

-- 
Jostein Kjønigsen
jostein@kjonigsen.net / jostein@secure.kjonigsen.net

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Ingo Lohmar]

On Fri, Mar 18 2016 22:33 (+0100), Jostein Kjønigsen wrote:

> While the error is encountered in csharp-mode (which is a non-official
> Emacs-package) I think it's worth nothing that this didn't use to cause
> errors in the past.
>
> I've run this test-case against the "regular" Windows build 24.5.1,
> using latest csharp-mode package and it runs fine. Trying latest Emacs
> from git master on Ubuntu I can reproduce this error systematically
> using the exact same version of csharp-mode.
>
> In my opinion that makes this an Emacs-bug.
>
> Whatever changes was done with cc-mode, it seems they're not fully
> compatible with all derived modes out there. It might be worth reaching
> out to other known third-party mode-developers basing their work on
> cc-mode to see if they too have issues with the recent changes in git
> master?

It is quite daring to call out an Emacs bug when you only encounter a
problem in "random" 3rd-party code :)

I have used csharp-mode before --- unless something has dramatically
changed in the last 3 months, it is essentially unmaintained.

Also, and I hope this does not sound too harsh, the csharp-mode code has
its fair share of problems to begin with.  For example, it uses faces
and cc-mode variables in ways that they are not intended for.
Therefore, it is plagued by more or less subtle font-lock and
indentation bugs.  It has severe performance problems.  It has not been
updated to deal w/ recent C# additions.  It is also fairly bloated,
adding "features" only remotely related to editing C# code.

About a year ago, I started to strip down the code to the bare
essentials and tried to make it more robust and play nicely with the
cc-mode machinery.  While this worked.. hmmm.. ok for the most part, I
have hesitated to put any of that code out in the open, as some of the
above problems remain unsolved.  My take-away was that cc-mode is a big
and complex beast as it stands, and I am not too eager to dive into all
its details.  If nobody else is doing the dirty work, chances to
properly support C# in *this* framework are pretty slim, I guess.

My hope is that the open-sourced Roslyn framework that is now used in
Omnisharp (haven't tested it) could also be used to do the whole
font-lock/indentation thing, such that we would not have to try to fit
C# into the cc-mode shape.

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

On Sat, Mar 19, 2016, at 12:08 AM, Ingo Lohmar wrote:
> 
> It is quite daring to call out an Emacs bug when you only encounter a
> problem in "random" 3rd-party code :)
> 
> I have used csharp-mode before --- unless something has dramatically
> changed in the last 3 months, it is essentially unmaintained.
> 
> Also, and I hope this does not sound too harsh, the csharp-mode code has
> its fair share of problems to begin with.  For example, it uses faces
> and cc-mode variables in ways that they are not intended for.
> Therefore, it is plagued by more or less subtle font-lock and
> indentation bugs.  It has severe performance problems.  It has not been
> updated to deal w/ recent C# additions.  It is also fairly bloated,
> adding "features" only remotely related to editing C# code.
> 
> About a year ago, I started to strip down the code to the bare
> essentials and tried to make it more robust and play nicely with the
> cc-mode machinery.  While this worked.. hmmm.. ok for the most part, I
> have hesitated to put any of that code out in the open, as some of the
> above problems remain unsolved.  My take-away was that cc-mode is a big
> and complex beast as it stands, and I am not too eager to dive into all
> its details.  If nobody else is doing the dirty work, chances to
> properly support C# in **this** framework are pretty slim, I guess.
> 
> My hope is that the open-sourced Roslyn framework that is now used in
> Omnisharp (haven't tested it) could also be used to do the whole
> font-lock/indentation thing, such that we would not have to try to fit
> C# into the cc-mode shape.

Just to ensure all cards ar on the table... Hi. I'm the guy who kinda
involuntarily has been maintaining csharp-mode for a couple of years
now :)

(self-defensive-mode t)

Basically Dino Chiesa left csharp-mode unmaintained on Google Code, with
issues unaddressed and breaking bugs unfixed and no work invested after
2011.

In 2014, After Emacs 24 broke it, I forked the repo, moved it to Github
and took over ownership. Since then 42 issues have in some way been
addressed or closed, most of them fixed.

Rather than add features which I can't complete or support, the focus
was on ensuring that the core language-mode code works, and if you want
IDE like features, you just supplement it with Omnisharp.

Basically its in bug-fix mode, which by no means should be taken as
"unmaintained" :)

With all that said, I don't think you are being overly harsh. The code
does have obvious issue here and there and maybe even everywhere, but I
don't think it's as bad as you paint it out to be.

The only performance-problem I am aware of is with the imenu-indexing,
and that's only for extremely big files not adhering to C# conventions
of one class per file. This is also code which can be disabled and
replaced with a (much better) Omnisharp-based alternative.

All in all its works reasonably well. Especially for being maintained by
someone not particularly well versed in Emacs lisp :)

(self-defensive-mode 0)

So if you feel like there are issues which should be addressed, please
feel free to raise them on the Github issue tracker:

https://github.com/josteink/csharp-mode/issues

I can't address or fix things I'm not aware of needing fixing. :)

I'm all for constructive suggestions to make the code a little less
horrible (and you seem to have a few). Please post them!

If you've tried to do any work or improvements with csharp-mode, I would
love to see what changes you propose. It's not really "my" code, I'm
just trying to keep it in working order, and I have no qualms over
throwing big chunks out :)

As for more closely aligning the goals of Omnisharp and csharp-mode, I
don't think that is such a far fetched idea. It has been proposed in the
past, but the Omnisharp-guys has (so far) preferred to have csharp-mode
be its own beast, which they supplement, rather than doing a full merge
(and thus taking on core language-mode responsibilities).

Now with all that said... And back to the bug. *phew*

This particular code which is now breaking has worked reasonably well
since Emacs 22 without any changes as far as I know.

*If* anyone says this bug is best fixed in csharp-mode, I'm not going to
argue a helluva lot over that, but I would appreciate some leads on how
to avoid tripping up cc-mode after recent changes in git master, while
remaining compatible with older Emacs-versions out there.

So to move the issue forward I guess we need to decide: Are we blaming
cc-mode or csharp-mode?

Anyone with strong opinions on the matter?

-- 
Jostein Kjønigsen
jostein@kjonigsen.net / jostein@secure.kjonigsen.net

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

\> So to move the issue forward I guess we need to decide: Are we
blaming
> cc-mode or csharp-mode?
> 
> Anyone with strong opinions on the matter?
> 
> -- 
> Jostein Kjønigsen
> jostein@kjonigsen.net / jostein@secure.kjonigsen.net

And in that regard, I'd like to report that this issue can be reproduced
just as easily
in Java-mode as well.

So it's not just csharp-mode which is affected.

--
Jostein

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Alan Mackenzie]

Hello, Jostein.

On Sat, Mar 19, 2016 at 09:27:19AM +0100, Jostein Kjønigsen wrote:
> > So to move the issue forward I guess we need to decide: Are we
> > blaming cc-mode or csharp-mode?

> > Anyone with strong opinions on the matter?
 
I suspect the interface between CC Mode and csharp-mode.  :-)

My working hypothesis is that the compiled csharp-mode.elc was compiled
on an earlier revision of the emacs-25 branch, hence didn't pick up a
newly introduced c-lang-defvar properly, thus leaving its value at nil.
This nil value is what triggered the error in
c-forward-<>-arglist-recur.

This hypothesis is not consistent with the bug also happening in Java
Mode, hence my questions below....

> > -- 
> > Jostein Kjønigsen
> > jostein@kjonigsen.net / jostein@secure.kjonigsen.net

> And in that regard, I'd like to report that this issue can be reproduced
> just as easily in Java-mode as well.

Can we be absolutely clear here, please.  Have you observed this bug in
Java Mode yourself?  If so, could you possibly give me details of the
version of the emacs-25 branch you saw it in, and any other details I'd
need to reproduce it.  Thanks!

What I tried was taking Saulius's C# file, doing M-x java-mode, then
typing that carriage return.  I could not reproduce the bug in Java
Mode.  I was running a recent emacs-25 branch, latest commit was
5cc691930808ccf7afdbc53ed49ca24badd97013 from Mon Mar 14 21:44:11 2016
+0000.

Also, having recompiled csharp-mode-0.8.12 in that emacs-25 branch, I
don't see the error any more.  I did see the error when I ran
csharp-mode compiled on Emacs-24.5 in the emacs-25 branch.

> So it's not just csharp-mode which is affected.

> --
> Jostein

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

On Mon, Mar 21, 2016, at 01:26 PM, Alan Mackenzie wrote:
> If so, could you possibly give me details of the
> version of the emacs-25 branch you saw it in, and any other details I'd
> need to reproduce it.  Thanks!

I've been tracking Emacs git master. Currently I'm at this point:

> commit 58862751bde2611d9ea99a33ecb5b0c13a7513b9
> Author: Glenn Morris <rgm@gnu.org>
> Date:   Thu Mar 17 00:14:11 2016 -0700

After each "git pull", I've done a "make distclean && make".

> Can we be absolutely clear here, please.  Have you observed this bug in
> Java Mode yourself?

Yes. I've created a new file called test.java with the following
contents:

> package Test;
> 
> public class A extends B<T>$

Pressing enter at this point will trigger a similar error, and the same
will typing { following that enter.

> I suspect the interface between CC Mode and csharp-mode.  :-)
> 
> My working hypothesis is that the compiled csharp-mode.elc was compiled
> on an earlier revision of the emacs-25 branch, hence didn't pick up a
> newly introduced c-lang-defvar properly, thus leaving its value at nil.
> This nil value is what triggered the error in
> c-forward-<>-arglist-recur.

That's a good theory and I decided to completely wiping csharp-mode and
reevaluating it inside Emacs to verify that stale data is not the cause
of the errors.

I'm still getting "wrong argument: stringp, nil" everywhere when
pressing enter interactively inside Emacs csharp-mode buffers.

I therefore tried to look into the build-system to see what it reports.

Byte-compiling csharp-mode triggers a warning which so far haven't been
an
issue for csharp-mode:

> $ make csharp-mode.elc
> ...
> csharp-mode.el:1772:17:Warning: looking-back called with 1 argument, but
>     requires 2-3

Trying to run a "make test" of csharp-mode against git master, most of
the tests breaks:

> Test indentation-rules-should-be-as-specified-in-test-doc backtrace:
>   c-forward-label()
>   c-guess-basic-syntax()
>   c-indent-region(1 1390)
>   indent-region(1 1390)
>   (let* ((buffer (find-file "test-files/indentation-tests.cs")) (orig-
>   (lambda nil (let* ((buffer (find-file "test-files/indentation-tests.
>   ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
>   ert-run-test([cl-struct-ert-test indentation-rules-should-be-as-spec
>   ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
>   ert-run-tests(t #[385 "\306\307\"\203G\211\211G\310U\203\211@\20
>   ert-run-tests-batch(nil)
>   ert-run-tests-batch-and-exit()
>   command-line-1(("-L" "." "-l" "csharp-mode-tests.el" "-f" "ert-run-t
>   command-line()
>   normal-top-level()
> Test indentation-rules-should-be-as-specified-in-test-doc condition:
>     (wrong-type-argument stringp nil)
>    FAILED  15/15  indentation-rules-should-be-as-specified-in-test-doc

I haven't looked into Saulius's C# file to reproduce this issue, so I
can't say if that is why you cannot reproduce or not.

Are the changes between between Emacs-25 and master so significant that
they could the big differences between our observations? I find that
hard to believe.

Anyway, something somewhere is clearly broken, and the faster we can
find out what, the better.

If you need more input, more theories tested, or more help understanding
any part of my setup, let me know. I'll try to provide all the info I
can.

-- 
Jostein Kjønigsen
jostein@kjonigsen.net / jostein@secure.kjonigsen.net

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Saulius Menkevičius]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

> On Mon, Mar 21, 2016, at 01:26 PM, Alan Mackenzie wrote:
>> If so, could you possibly give me details of the
>> version of the emacs-25 branch you saw it in, and any other details I'd
>> need to reproduce it.  Thanks!
>
> I've been tracking Emacs git master. Currently I'm at this point:
>
>> commit 58862751bde2611d9ea99a33ecb5b0c13a7513b9
>> Author: Glenn Morris <rgm@gnu.org>
>> Date:   Thu Mar 17 00:14:11 2016 -0700
>
> After each "git pull", I've done a "make distclean && make".
>
>> Can we be absolutely clear here, please.  Have you observed this bug in
>> Java Mode yourself?
>
> Yes. I've created a new file called test.java with the following
> contents:
>
>> package Test;
>> 
>> public class A extends B<T>$
>
> Pressing enter at this point will trigger a similar error, and the same
> will typing { following that enter.
>
>> I suspect the interface between CC Mode and csharp-mode.  :-)
>> 
>> My working hypothesis is that the compiled csharp-mode.elc was compiled
>> on an earlier revision of the emacs-25 branch, hence didn't pick up a
>> newly introduced c-lang-defvar properly, thus leaving its value at nil.
>> This nil value is what triggered the error in
>> c-forward-<>-arglist-recur.
>
> That's a good theory and I decided to completely wiping csharp-mode and
> reevaluating it inside Emacs to verify that stale data is not the cause
> of the errors.
>
> I'm still getting "wrong argument: stringp, nil" everywhere when
> pressing enter interactively inside Emacs csharp-mode buffers.
>
> I therefore tried to look into the build-system to see what it reports.
>
> Byte-compiling csharp-mode triggers a warning which so far haven't been
> an
> issue for csharp-mode:
>
>> $ make csharp-mode.elc
>> ...
>> csharp-mode.el:1772:17:Warning: looking-back called with 1 argument, but
>>     requires 2-3
>
> Trying to run a "make test" of csharp-mode against git master, most of
> the tests breaks:
>
>> Test indentation-rules-should-be-as-specified-in-test-doc backtrace:
>>   c-forward-label()
>>   c-guess-basic-syntax()
>>   c-indent-region(1 1390)
>>   indent-region(1 1390)
>>   (let* ((buffer (find-file "test-files/indentation-tests.cs")) (orig-
>>   (lambda nil (let* ((buffer (find-file "test-files/indentation-tests.
>>   ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
>>   ert-run-test([cl-struct-ert-test indentation-rules-should-be-as-spec
>>   ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
>>   ert-run-tests(t #[385 "\306\307\"\203G\211\211G\310U\203\211@\20
>>   ert-run-tests-batch(nil)
>>   ert-run-tests-batch-and-exit()
>>   command-line-1(("-L" "." "-l" "csharp-mode-tests.el" "-f" "ert-run-t
>>   command-line()
>>   normal-top-level()
>> Test indentation-rules-should-be-as-specified-in-test-doc condition:
>>     (wrong-type-argument stringp nil)
>>    FAILED  15/15  indentation-rules-should-be-as-specified-in-test-doc
>
> I haven't looked into Saulius's C# file to reproduce this issue, so I
> can't say if that is why you cannot reproduce or not.
>
> Are the changes between between Emacs-25 and master so significant that
> they could the big differences between our observations? I find that
> hard to believe.
>
> Anyway, something somewhere is clearly broken, and the faster we can
> find out what, the better.
>
> If you need more input, more theories tested, or more help understanding
> any part of my setup, let me know. I'll try to provide all the info I
> can.

Actually, removing and installing csharp-mode from package manager with
the latest emacs-25 fixed the issue for me. And I could not replicate
the same problem in Java mode.

-- 
Saulius Menkevičius (saulius.menkevicius@gmail.com)

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

On Mon, Mar 21, 2016, at 10:53 PM, Saulius Menkevičius wrote:
> Actually, removing and installing csharp-mode from package manager with
> the latest emacs-25 fixed the issue for me. And I could not replicate
> the same problem in Java mode.
> 
> -- 
> Saulius Menkevičius (saulius.menkevicius@gmail.com)

I completely nuked my previous Emacs build (and personal setup) and
tried setting everything up from scratch again.

I second your findings: Using the emacs-25 branch everything works fine.

If I base my build on Emacs git master though, I still get all of the
problems described above.

There are currently differences between master and emacs-25 and I guess
these changes needs to be vetted better:

> $ git checkout emacs-25
> $ git diff master -- lisp/progmodes/cc-mode.el
> diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
> index 9ebe6f7..738870b 100644
> --- a/lisp/progmodes/cc-mode.el
> +++ b/lisp/progmodes/cc-mode.el
> @@ -141,18 +141,7 @@
>  ;; derived-mode-ex.el>.
> 
>  (defun c-leave-cc-mode-mode ()
> -  (when c-buffer-is-cc-mode
> -    (save-restriction
> -      (widen)
> -      (c-save-buffer-state ()
> -       (c-clear-char-properties (point-min) (point-max) 'category)
> -       (c-clear-char-properties (point-min) (point-max) 'syntax-table)
> -       (c-clear-char-properties (point-min) (point-max) 'c-is-sws)
> -       (c-clear-char-properties (point-min) (point-max) 'c-in-sws)
> -       (c-clear-char-properties (point-min) (point-max) 'c-type)
> -       (if (c-major-mode-is 'awk-mode)
> -           (c-clear-char-properties (point-min) (point-max) 'c-awk-NL-prop))))
> -    (setq c-buffer-is-cc-mode nil)))
> +  (setq c-buffer-is-cc-mode nil))
> 
>  (defun c-init-language-vars-for (mode)
>    "Initialize the language variables for one of the language modes
> @@ -1493,7 +1482,6 @@ c-mode
>         abbrev-mode t)
>    (use-local-map c-mode-map)
>    (c-init-language-vars-for 'c-mode)
> -  (c-make-noise-macro-regexps)
>    (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
>    (c-common-init 'c-mode)
>    (easy-menu-add c-c-menu)
> @@ -1549,7 +1537,6 @@ c++-mode
>         abbrev-mode t)
>    (use-local-map c++-mode-map)
>    (c-init-language-vars-for 'c++-mode)
> -  (c-make-noise-macro-regexps)
>    (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
>    (c-common-init 'c++-mode)
>    (easy-menu-add c-c++-menu)
> @@ -1603,7 +1590,6 @@ objc-mode
>         abbrev-mode t)
>    (use-local-map objc-mode-map)
>    (c-init-language-vars-for 'objc-mode)
> -  (c-make-noise-macro-regexps)
>    (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
>      (c-common-init 'objc-mode)
>      (easy-menu-add c-objc-menu)

Anything you can look into, Alan?

-- 
Jostein Kjønigsen
jostein@kjonigsen.net / jostein@secure.kjonigsen.net

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Alan Mackenzie]

Hello, Jostein.

On Mon, Mar 21, 2016 at 01:45:56PM +0100, Jostein Kjønigsen wrote:
> On Mon, Mar 21, 2016, at 01:26 PM, Alan Mackenzie wrote:

> I've been tracking Emacs git master.

> > commit 58862751bde2611d9ea99a33ecb5b0c13a7513b9
> > Author: Glenn Morris <rgm@gnu.org>
> > Date:   Thu Mar 17 00:14:11 2016 -0700

> After each "git pull", I've done a "make distclean && make".

> > Can we be absolutely clear here, please.  Have you observed this bug in
> > Java Mode yourself?

> Yes. I've created a new file called test.java with the following
> contents:

> > package Test;

> > public class A extends B<T>$

> Pressing enter at this point will trigger a similar error, and the same
> will typing { following that enter.

Thanks.  That was useful, and enabled me to reproduce the problem.  It's
a separate bug from the one Saulius reported with csharp-mode, and occurs
only in the Emacs master branch.  To be precise, a new variable
introduced in that branch hadn't been given a proper initial value for
Java (or, indeed, C#), so had the default value nil, which led to the
error happening.

This bug has now been fixed and committed to the master branch of the
Emacs git repository.  Would you please get the latest version, and
confirm that the bug has been satisfactorally fixed.  Thanks!

> > I suspect the interface between CC Mode and csharp-mode.  :-)
 
> > My working hypothesis is that the compiled csharp-mode.elc was compiled
> > on an earlier revision of the emacs-25 branch, hence didn't pick up a
> > newly introduced c-lang-defvar properly, thus leaving its value at nil.
> > This nil value is what triggered the error in
> > c-forward-<>-arglist-recur.

> That's a good theory and I decided to completely wiping csharp-mode and
> reevaluating it inside Emacs to verify that stale data is not the cause
> of the errors.

> I'm still getting "wrong argument: stringp, nil" everywhere when
> pressing enter interactively inside Emacs csharp-mode buffers.

I hope that's now fixed.

> I therefore tried to look into the build-system to see what it reports.

> Byte-compiling csharp-mode triggers a warning which so far haven't been
> an issue for csharp-mode:

> > $ make csharp-mode.elc
> > ...
> > csharp-mode.el:1772:17:Warning: looking-back called with 1 argument, but
> >     requires 2-3

Yes.  Somebody in the Emacs team has decided that the second argument,
previously optional, is now mandatory.  I wish people wouldn't do things
like that.  The only thing sensible here is to add a second argument,
nil, to each call to looking-back.

Can I ask you, as maintainer of csharp-mode:
(i) To insert "(eval-when-compile (require 'cc-langs))" near the top of
  csharp-mode.el.
(ii) To add something to the manual telling users to compile
  csharp-mode.el with the Emacs it's going to be run with.

(i) should help ensure csharp-mode gets properly compiled.  (ii) should
also help ensure csharp-mode is properly compiled.  :-)

> Trying to run a "make test" of csharp-mode against git master, most of
> the tests breaks:

> > Test indentation-rules-should-be-as-specified-in-test-doc backtrace:
> >   c-forward-label()
> >   c-guess-basic-syntax()
> >   c-indent-region(1 1390)
> >   indent-region(1 1390)
> >   (let* ((buffer (find-file "test-files/indentation-tests.cs")) (orig-
> >   (lambda nil (let* ((buffer (find-file "test-files/indentation-tests.
> >   ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
> >   ert-run-test([cl-struct-ert-test indentation-rules-should-be-as-spec
> >   ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
> >   ert-run-tests(t #[385 "\306\307\"\203G\211\211G\310U\203\211@\20
> >   ert-run-tests-batch(nil)
> >   ert-run-tests-batch-and-exit()
> >   command-line-1(("-L" "." "-l" "csharp-mode-tests.el" "-f" "ert-run-t
> >   command-line()
> >   normal-top-level()
> > Test indentation-rules-should-be-as-specified-in-test-doc condition:
> >     (wrong-type-argument stringp nil)
> >    FAILED  15/15  indentation-rules-should-be-as-specified-in-test-doc

Please let me know if this still happens.

> I haven't looked into Saulius's C# file to reproduce this issue, so I
> can't say if that is why you cannot reproduce or not.

> Are the changes between between Emacs-25 and master so significant that
> they could the big differences between our observations? I find that
> hard to believe.

Yes, that is indeed the case.  Two variables in master weren't properly
initialised for Java, Pike, ...., and derived modes.  Sorry about that!

> -- 
> Jostein Kjønigsen
> jostein@kjonigsen.net / jostein@secure.kjonigsen.net

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

On Fri, Mar 25, 2016, at 07:54 PM, Alan Mackenzie wrote:
> Thanks.  That was useful, and enabled me to reproduce the problem.  It's
> a separate bug from the one Saulius reported with csharp-mode, and occurs
> only in the Emacs master branch.  To be precise, a new variable
> introduced in that branch hadn't been given a proper initial value for
> Java (or, indeed, C#), so had the default value nil, which led to the
> error happening.
> 
> This bug has now been fixed and committed to the master branch of the
> Emacs git repository.  Would you please get the latest version, and
> confirm that the bug has been satisfactorally fixed.  Thanks!
>

I've tested for both java-mode and csharp-mode.

Once recompiled/reinstalled from melpa/marmalade csharp-mode loads fine
now. Thanks for the fix!

>> I'm still getting "wrong argument: stringp, nil" everywhere when
>> pressing enter interactively inside Emacs csharp-mode buffers.
> 
> I hope that's now fixed.

Indeed it is.

> Yes, that is indeed the case.  Two variables in master weren't
> properly initialised for Java, Pike, ...., and derived modes.  Sorry
> about that!

Shit happens. That's what bug-reports are for :)

>> Trying to run a "make test" of csharp-mode against git master, most of
>> the tests breaks:
> 
> Please let me know if this still happens.

Now 14 tests pass and only 1 test related to fontification breaks. The
fontification-tests have historically been somewhat unreliable, so I
wouldn't worry too much about that.

I'll consider this issue fixed at this point, and look into this single
test later.

>> Byte-compiling csharp-mode triggers a warning which so far haven't been
>> an issue for csharp-mode:
> 
> Yes.  Somebody in the Emacs team has decided that the second argument,
> previously optional, is now mandatory.  I wish people wouldn't do things
> like that.  The only thing sensible here is to add a second argument,
> nil, to each call to looking-back.

I've stalled doing this, due to not knowing if I will be changing the
semantics of the code. Do you know if inserting this nil-parameter is
what implicitly done by the compiler in cases such as these? Is such a
change guaranteed "safe"?

If you can confirm that, I can update the code to get rid of simple
issues like this.

> Can I ask you, as maintainer of csharp-mode:
> (i) To insert "(eval-when-compile (require 'cc-langs))" near the top of
>   csharp-mode.el.
> (ii) To add something to the manual telling users to compile
>   csharp-mode.el with the Emacs it's going to be run with.
> 
> (i) should help ensure csharp-mode gets properly compiled.  (ii) should
> also help ensure csharp-mode is properly compiled.  :-)
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).

Consider (i) done. As for (ii) that's usually not done by the user
itself, but by Emacs whenever there's an update to the package on MELPA
or marmalade.

I can add a note to the related bug on the csharp-mode issue-tracker
that this issue is resolved by reinstalling/recompiling the package
though.

Cheers!

-- 
Jostein Kjønigsen
jostein@kjonigsen.net / jostein@secure.kjonigsen.net

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Alan Mackenzie]

Hello, Jostein.

On Sat, Mar 26, 2016 at 08:26:00AM +0100, Jostein Kjønigsen wrote:

> On Fri, Mar 25, 2016, at 07:54 PM, Alan Mackenzie wrote:
> > Thanks.  That was useful, and enabled me to reproduce the problem.  It's
> > a separate bug from the one Saulius reported with csharp-mode, and occurs
> > only in the Emacs master branch.  To be precise, a new variable
> > introduced in that branch hadn't been given a proper initial value for
> > Java (or, indeed, C#), so had the default value nil, which led to the
> > error happening.

> > This bug has now been fixed and committed to the master branch of the
> > Emacs git repository.  Would you please get the latest version, and
> > confirm that the bug has been satisfactorally fixed.  Thanks!


> I've tested for both java-mode and csharp-mode.

> Once recompiled/reinstalled from melpa/marmalade csharp-mode loads fine
> now. Thanks for the fix!

Thanks, that's great!

[ .... ]

> I'll consider this issue fixed at this point, and look into this single
> test [ related to fontification ] later.

OK.

> >> Byte-compiling csharp-mode triggers a warning which so far haven't been
> >> an issue for csharp-mode:

> > Yes.  Somebody in the Emacs team has decided that the second argument,
> > previously optional, is now mandatory.  I wish people wouldn't do things
> > like that.  The only thing sensible here is to add a second argument,
> > nil, to each call to looking-back.

> I've stalled doing this, due to not knowing if I will be changing the
> semantics of the code. Do you know if inserting this nil-parameter is
> what implicitly done by the compiler in cases such as these? Is such a
> change guaranteed "safe"?

> If you can confirm that, I can update the code to get rid of simple
> issues like this.

Adding the nil argument for the new version of `looking-back' is exactly
equivalent to leaving it out on the earlier version.  Earlier versions
of `looking-back' will continue to work unchanged after adding that
explicit nil.  That argument actually holds a limit position for backward
searching.  If it is convenient to calculate a sensible limit, this might
speed up C# Mode when using `looking-back', since with nil it may be
looking arbitrarily far back.

> > Can I ask you, as maintainer of csharp-mode:
> > (i) To insert "(eval-when-compile (require 'cc-langs))" near the top of
> >   csharp-mode.el.
> > (ii) To add something to the manual telling users to compile
> >   csharp-mode.el with the Emacs it's going to be run with.

> > (i) should help ensure csharp-mode gets properly compiled.  (ii) should
> > also help ensure csharp-mode is properly compiled.  :-)

> Consider (i) done. As for (ii) that's usually not done by the user
> itself, but by Emacs whenever there's an update to the package on MELPA
> or marmalade.

OK.

> I can add a note to the related bug on the csharp-mode issue-tracker
> that this issue is resolved by reinstalling/recompiling the package
> though.

That would be good.

> Cheers!

I think it's time to close this bug, which I will do.  Thanks for all the
help!

> -- 
> Jostein Kjønigsen
> jostein@kjonigsen.net / jostein@secure.kjonigsen.net

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Ingo Lohmar]

On Sat, Mar 19 2016 08:29 (+0100), Jostein Kjønigsen wrote:

> Just to ensure all cards ar on the table... Hi. I'm the guy who kinda
> involuntarily has been maintaining csharp-mode for a couple of years
> now :)
>
> (self-defensive-mode t)
>
> Basically Dino Chiesa left csharp-mode unmaintained on Google Code, with
> issues unaddressed and breaking bugs unfixed and no work invested after
> 2011.
>
> In 2014, After Emacs 24 broke it, I forked the repo, moved it to Github
> and took over ownership. Since then 42 issues have in some way been
> addressed or closed, most of them fixed.
>
> Rather than add features which I can't complete or support, the focus
> was on ensuring that the core language-mode code works, and if you want
> IDE like features, you just supplement it with Omnisharp.
>
> Basically its in bug-fix mode, which by no means should be taken as
> "unmaintained" :)

Hi Jostein,

Sorry, I should have done my homework first.  It seems your work on the
fork started a few months after I started using csharp-mode, and I did
not become aware of it.  My comments above apply to the version that
Dino left at Google Code.

From your description, that all seems to me like the right direction to
take the code.

> If you've tried to do any work or improvements with csharp-mode, I would
> love to see what changes you propose. It's not really "my" code, I'm
> just trying to keep it in working order, and I have no qualms over
> throwing big chunks out :)

My own approach was more radical: I threw out everything that I thought
did not belong to a bare-bones language major mode, and then tried to
clean up the remaining code and get font-locking and indentation right.
Besides a few special-case routines, that leaves me with mostly cc-mode
variable settings.  Incidentally that brings down the main file from
more than 200k (Dino) to 36k (mine), compared to 163k (your latest).

I will try to find some time to look into your code, but just from the
numbers it seems that the differences are substantial.  I should put my
code into a repo anyway (been meaning to do that) and maybe something
good will come from having both.  But since I haven't used your version,
I cannot reasonably file issues now anymore, sorry.

FWIW, I was mostly annoyed by using arbitrary font-lock-faces (I think
the function face was used for non-function symbols and so on),
incomplete keyword settings and non-elisp formatting conventions.

The performance problem came up in buffers with lots of literal strings,
as the routines were very wasteful and used a lot of unnecessary regexp
searching.

> As for more closely aligning the goals of Omnisharp and csharp-mode, I
> don't think that is such a far fetched idea. It has been proposed in the
> past, but the Omnisharp-guys has (so far) preferred to have csharp-mode
> be its own beast, which they supplement, rather than doing a full merge
> (and thus taking on core language-mode responsibilities).

Yeah, this was more of a general idea.  There's an unfair gap in
language-specific capabilities between special IDEs and Emacs for "big"
languages like Java and C#, caused by the fact that those IDEs use
parser and compiler information (or even duplicate their tasks).  As has
been discussed on this list before, part of the gap can be closed, but
it's not clear to me how this would work best for basic things like
syntax highlighting.

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[jostein]

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



Thanks for clearing that up.


With that said: since this change was introduced in cc-mode to fix a c++ issue, at least one bug have been introduced in at least two other cc-mode derived modes: csharp-mode and java-mode.


To me it therefore seems that the proper place to fix this is in cc-mode.


Anyone have any major objections to that line of reasoning? Am I still daring? :)


--

Jostein Kjønigsen

jostein@kjonigsen.net - https://jostein.kjonigsen.net






On Sat, Mar 19, 2016 at 3:05 AM -0700, "Ingo Lohmar" <i.lohmar@gmail.com> wrote:










On Sat, Mar 19 2016 08:29 (+0100), Jostein Kjønigsen wrote:

> Just to ensure all cards ar on the table... Hi. I'm the guy who kinda
> involuntarily has been maintaining csharp-mode for a couple of years
> now :)
>
> (self-defensive-mode t)
>
> Basically Dino Chiesa left csharp-mode unmaintained on Google Code, with
> issues unaddressed and breaking bugs unfixed and no work invested after
> 2011.
>
> In 2014, After Emacs 24 broke it, I forked the repo, moved it to Github
> and took over ownership. Since then 42 issues have in some way been
> addressed or closed, most of them fixed.
>
> Rather than add features which I can't complete or support, the focus
> was on ensuring that the core language-mode code works, and if you want
> IDE like features, you just supplement it with Omnisharp.
>
> Basically its in bug-fix mode, which by no means should be taken as
> "unmaintained" :)

Hi Jostein,

Sorry, I should have done my homework first.  It seems your work on the
fork started a few months after I started using csharp-mode, and I did
not become aware of it.  My comments above apply to the version that
Dino left at Google Code.

From your description, that all seems to me like the right direction to
take the code.

> If you've tried to do any work or improvements with csharp-mode, I would
> love to see what changes you propose. It's not really "my" code, I'm
> just trying to keep it in working order, and I have no qualms over
> throwing big chunks out :)

My own approach was more radical: I threw out everything that I thought
did not belong to a bare-bones language major mode, and then tried to
clean up the remaining code and get font-locking and indentation right.
Besides a few special-case routines, that leaves me with mostly cc-mode
variable settings.  Incidentally that brings down the main file from
more than 200k (Dino) to 36k (mine), compared to 163k (your latest).

I will try to find some time to look into your code, but just from the
numbers it seems that the differences are substantial.  I should put my
code into a repo anyway (been meaning to do that) and maybe something
good will come from having both.  But since I haven't used your version,
I cannot reasonably file issues now anymore, sorry.

FWIW, I was mostly annoyed by using arbitrary font-lock-faces (I think
the function face was used for non-function symbols and so on),
incomplete keyword settings and non-elisp formatting conventions.

The performance problem came up in buffers with lots of literal strings,
as the routines were very wasteful and used a lot of unnecessary regexp
searching.

> As for more closely aligning the goals of Omnisharp and csharp-mode, I
> don't think that is such a far fetched idea. It has been proposed in the
> past, but the Omnisharp-guys has (so far) preferred to have csharp-mode
> be its own beast, which they supplement, rather than doing a full merge
> (and thus taking on core language-mode responsibilities).

Yeah, this was more of a general idea.  There's an unfair gap in
language-specific capabilities between special IDEs and Emacs for "big"
languages like Java and C#, caused by the fact that those IDEs use
parser and compiler information (or even duplicate their tasks).  As has
been discussed on this list before, part of the gap can be closed, but
it's not clear to me how this would work best for basic things like
syntax highlighting.






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

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

Thanks for clearing that up.

With that said: since this change was introduced in cc-mode to fix a c++
issue, at least one bug have been introduced in at least two other
cc-mode derived modes: csharp-mode and java-mode.

To me it therefore seems that the proper place to fix this is in
cc-mode.

Anyone have any major objections to that line of reasoning? Am I still
daring? :)

> --
Jostein Kjønigsen
jostein@kjonigsen.net

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

Alan Mackenzie <acm <at> muc.de> wrote:
> Hello, Saulius.
> 
> Thanks for such an informative bug report.  Could you possibly tell me
> what major mode you're using (presumably some C# Mode) and where I can
> get a copy of it from, please.  That will enable me to reproduce the
> problem.
> 
> Thanks in advance!
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).

This bug was originally reproduced using csharp-mode as available on
MELPA and MARMALADE, but also on Github:

https://github.com/josteink/csharp-mode

This bug can also be reproduced using almost the exact same code in
other cc-mode derived modes like java-mode, which to my knowledge is
shipped as part of cc-mode itself:

    package Test

    public class A: B<T>
    {$

This is: You don't need third-party code to reproduce this error.

Hope this helps.

--
Jostein Kjønigsen

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Alan Mackenzie]

Hello, Saulius.

In article <mailman.7741.1458315553.843.bug-gnu-emacs@gnu.org> you wrote:

> When writing code:

> namespace X
> {
>     public class A: B<T>
>     {$
> ($ above denotes cursor position)

> Typing [Enter] after the second { would trigger this error:

> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   signal(wrong-type-argument (stringp nil))
>   c-syntactic-re-search-forward(nil nil t t)
>   c-forward-<>-arglist-recur(nil)
>   c-forward-<>-arglist(nil)
>   c-backward-<>-arglist(nil nil)
>   c-looking-at-decl-block(13 t)
>   c-guess-basic-syntax()
>   c-indent-line()
>   indent-according-to-mode()
>   evil-open-below(1)
>   funcall-interactively(evil-open-below 1)
>   call-interactively(evil-open-below nil nil)
>   command-execute(evil-open-below)

> Note, that typing [Enter] after non-generic class inheritance would work ok (no error would get triggered):

> namespace X
> {
>     public class A: B
>     {$

> I *think* it could be related to this commit (will test):
>     commit 02b037b85ce32fdcf454f5b12d72f09bcb217891
>     Author: Alan Mackenzie <acm@muc.de>
>     Date:   Mon Feb 15 12:45:42 2016 +0000

>         Allow arithmetic operators inside C++ template constructs.

Thanks for such an informative bug report.  Could you possibly tell me
what major mode you're using (presumably some C# Mode) and where I can
get a copy of it from, please.  That will enable me to reproduce the
problem.


> In GNU Emacs 25.0.92.3 (x86_64-apple-darwin15.3.0, NS appkit-1404.34 Version 10.11.3 (Build 15D21))
>  of 2016-03-17 built on mbp.local
> Repository revision: 9ab03f27fad7b1ae68dda7a2effd075658dcf184
> Windowing system distributor 'Apple', version 10.3.1404
> Configured using:
>  'configure --with-gnutls --with-ns'

> Configured features:
> JPEG DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

> Important settings:
>   value of $LANG: de_LT
>   locale-coding-system: utf-8

> Major mode: mu4e-headers

???

Thanks in advance!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Saulius Menkevičius]

Hi,

Not sure why I did not receive and email directly from debbugs.gnu.org
(maybe there is some delay in mail transfer mechanism on the way).

> Thanks for such an informative bug report.  Could you possibly tell me
> what major mode you're using (presumably some C# Mode) and where I can
> get a copy of it from, please.  That will enable me to reproduce the
> problem.

The mode in question is csharp-mode, from MELPA:

    csharp-mode is a dependency package.

        Status: Installed in ‘csharp-mode-20160217.1211/’ (unsigned).
        Version: 20160217.1211
        Summary: C# mode derived mode
    Homepage: https://github.com/josteink/csharp-mode
    Keywords: c# languages oop mode 
    Other versions: 20160217.1211 (melpa-stable), 0.8.12 (marmelade).

Not sure if you've checked the tracked for this issue, but Jostein
Kjønigsen <jostein <at> secure.kjonigsen.net> wrote:

    I've run this test-case against the "regular" Windows build 24.5.1,
    using latest csharp-mode package and it runs fine. Trying latest Emacs
    from git master on Ubuntu I can reproduce this error systematically
    using the exact same version of csharp-mode.

So this is can be replicated with bare emacs-25 from git + csharp-mode from
MELPA. Also someone wrote that the same thing happens with Java mode too
where the code being edited uses generics (as C# and Java generics syntax is
very similar).

> 
> 
> > In GNU Emacs 25.0.92.3 (x86_64-apple-darwin15.3.0, NS appkit-1404.34 Version 10.11.3 (Build 15D21))
> >  of 2016-03-17 built on mbp.local
> > Repository revision: 9ab03f27fad7b1ae68dda7a2effd075658dcf184
> > Windowing system distributor 'Apple', version 10.3.1404
> > Configured using:
> >  'configure --with-gnutls --with-ns'
> 
> > Configured features:
> > JPEG DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS
> 
> > Important settings:
> >   value of $LANG: de_LT
> >   locale-coding-system: utf-8
> 
> > Major mode: mu4e-headers
> 
> ???

Oh, it was my first time using `report-emacs-bug', -- I invoked
it from my mail client buffer instead of from the csharp-mode that has
issue itself.

Thanks!

-- 
Saulius Menkevičius (saulius.menkevicius@gmail.com)

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Alan Mackenzie]

Hello, Saulius.

On Sat, Mar 19, 2016 at 04:15:53PM +0200, Saulius Menkevičius wrote:

> Hi,

> Not sure why I did not receive and email directly from debbugs.gnu.org
> (maybe there is some delay in mail transfer mechanism on the way).

I answered your mail directly, with a copy to debbugs.gnu.org.  But
things can go wrong with email.

> > Thanks for such an informative bug report.  Could you possibly tell me
> > what major mode you're using (presumably some C# Mode) and where I can
> > get a copy of it from, please.  That will enable me to reproduce the
> > problem.

> The mode in question is csharp-mode, from MELPA:

>     csharp-mode is a dependency package.

>         Status: Installed in ‘csharp-mode-20160217.1211/’ (unsigned).
>         Version: 20160217.1211
>         Summary: C# mode derived mode
>     Homepage: https://github.com/josteink/csharp-mode
>     Keywords: c# languages oop mode 
>     Other versions: 20160217.1211 (melpa-stable), 0.8.12 (marmelade).

OK, I've got it, thanks.  In particular, the 0.8.12 version from MELPA.

Next question: have you actually compiled it with the emacs-25 repository
code?  What makes me think you might not have, is that there are lots of

    (looking-back <string>)

instances in the code, which no longer compile.  (They need to have a nil
inserted after <string>, giving (looking-back <string> nil).)  As soon as
I made these edits, then recompiled csharp-mode.el inside the emacs-25
repo version, the code ran just fine.  Actually, I think I had manually
to load cc-langs.elc to get it to compile properly; I think the following
line is missing from near the top of csharp-mode.el:

    (eval-when-compile (require 'cc-langs))

Explanation for the bug I saw: a new "language variable",
c-<>-notable-chars-re, had been defined in CC Mode, but not compiled into
the csharp-mode part.  That left it's value at nil, rather than the
string it should be.  This nil then caused the error.

But it could be I'm looking at totally the wrong problem.

> Not sure if you've checked the tracked for this issue, but Jostein
> Kjønigsen <jostein <at> secure.kjonigsen.net> wrote:

>     I've run this test-case against the "regular" Windows build 24.5.1,
>     using latest csharp-mode package and it runs fine. Trying latest Emacs
>     from git master on Ubuntu I can reproduce this error systematically
>     using the exact same version of csharp-mode.

Exact same source code, or exact same binary?  The source code will need
recompiling for the emacs-25 repo.  csharp-mode.elc compiled for an earlier
version will definitely produce this error on emacs-25.

> So this is can be replicated with bare emacs-25 from git + csharp-mode from
> MELPA. Also someone wrote that the same thing happens with Java mode too
> where the code being edited uses generics (as C# and Java generics syntax is
> very similar).

The same thing happening on Java would surprise me.  That would imply a
different problem.

So, to sum up: please make sure the compiled version of csharp-mode
you're using has been compiled on the Emacs you're using it on.  Thanks!

> > > In GNU Emacs 25.0.92.3 (x86_64-apple-darwin15.3.0, NS appkit-1404.34 Version 10.11.3 (Build 15D21))
> > >  of 2016-03-17 built on mbp.local
> > > Repository revision: 9ab03f27fad7b1ae68dda7a2effd075658dcf184
> > > Windowing system distributor 'Apple', version 10.3.1404
> > > Configured using:
> > >  'configure --with-gnutls --with-ns'

> > > Configured features:
> > > JPEG DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

> > > Important settings:
> > >   value of $LANG: de_LT
> > >   locale-coding-system: utf-8

> > > Major mode: mu4e-headers

> > ???

> Oh, it was my first time using `report-emacs-bug', -- I invoked
> it from my mail client buffer instead of from the csharp-mode that has
> issue itself.

No, by "???" I just meant "mu4e-headers is something I'm not familiar
with.".

> Thanks!

> -- 
> Saulius Menkevičius (saulius.menkevicius@gmail.com)

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Saulius Menkevičius]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Saulius.
>
> On Sat, Mar 19, 2016 at 04:15:53PM +0200, Saulius Menkevičius wrote:
>
>> Hi,
>
>> Not sure why I did not receive and email directly from debbugs.gnu.org
>> (maybe there is some delay in mail transfer mechanism on the way).
>
> I answered your mail directly, with a copy to debbugs.gnu.org.  But
> things can go wrong with email.
>
>> > Thanks for such an informative bug report.  Could you possibly tell me
>> > what major mode you're using (presumably some C# Mode) and where I can
>> > get a copy of it from, please.  That will enable me to reproduce the
>> > problem.
>
>> The mode in question is csharp-mode, from MELPA:
>
>>     csharp-mode is a dependency package.
>
>>         Status: Installed in ‘csharp-mode-20160217.1211/’ (unsigned).
>>         Version: 20160217.1211
>>         Summary: C# mode derived mode
>>     Homepage: https://github.com/josteink/csharp-mode
>>     Keywords: c# languages oop mode 
>>     Other versions: 20160217.1211 (melpa-stable), 0.8.12 (marmelade).
>
> OK, I've got it, thanks.  In particular, the 0.8.12 version from MELPA.
>
> Next question: have you actually compiled it with the emacs-25 repository
> code?  What makes me think you might not have, is that there are lots of
>
>     (looking-back <string>)
>
> instances in the code, which no longer compile.  (They need to have a nil
> inserted after <string>, giving (looking-back <string> nil).)  As soon as
> I made these edits, then recompiled csharp-mode.el inside the emacs-25
> repo version, the code ran just fine.  Actually, I think I had manually
> to load cc-langs.elc to get it to compile properly; I think the following
> line is missing from near the top of csharp-mode.el:
>
>     (eval-when-compile (require 'cc-langs))
>
> Explanation for the bug I saw: a new "language variable",
> c-<>-notable-chars-re, had been defined in CC Mode, but not compiled into
> the csharp-mode part.  That left it's value at nil, rather than the
> string it should be.  This nil then caused the error.
>
> But it could be I'm looking at totally the wrong problem.

It worked for me, actually. Removing csharp-mode and then reinstalling
via package manager fixed the issue for me.

>
>> Not sure if you've checked the tracked for this issue, but Jostein
>> Kjønigsen <jostein <at> secure.kjonigsen.net> wrote:
>
>>     I've run this test-case against the "regular" Windows build 24.5.1,
>>     using latest csharp-mode package and it runs fine. Trying latest Emacs
>>     from git master on Ubuntu I can reproduce this error systematically
>>     using the exact same version of csharp-mode.
>
> Exact same source code, or exact same binary?  The source code will need
> recompiling for the emacs-25 repo.  csharp-mode.elc compiled for an earlier
> version will definitely produce this error on emacs-25.
>
>> So this is can be replicated with bare emacs-25 from git + csharp-mode from
>> MELPA. Also someone wrote that the same thing happens with Java mode too
>> where the code being edited uses generics (as C# and Java generics syntax is
>> very similar).
>
> The same thing happening on Java would surprise me.  That would imply a
> different problem.

I couldn't replicate the Java issue myself..

>
> So, to sum up: please make sure the compiled version of csharp-mode
> you're using has been compiled on the Emacs you're using it on.  Thanks!
>
>> > > In GNU Emacs 25.0.92.3 (x86_64-apple-darwin15.3.0, NS appkit-1404.34 Version 10.11.3 (Build 15D21))
>> > >  of 2016-03-17 built on mbp.local
>> > > Repository revision: 9ab03f27fad7b1ae68dda7a2effd075658dcf184
>> > > Windowing system distributor 'Apple', version 10.3.1404
>> > > Configured using:
>> > >  'configure --with-gnutls --with-ns'
>
>> > > Configured features:
>> > > JPEG DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS
>
>> > > Important settings:
>> > >   value of $LANG: de_LT
>> > >   locale-coding-system: utf-8
>
>> > > Major mode: mu4e-headers
>
>> > ???
>
>> Oh, it was my first time using `report-emacs-bug', -- I invoked
>> it from my mail client buffer instead of from the csharp-mode that has
>> issue itself.
>
> No, by "???" I just meant "mu4e-headers is something I'm not familiar
> with.".
>
>> Thanks!
>
>> -- 
>> Saulius Menkevičius (saulius.menkevicius@gmail.com)

So the issue is resolved for me, reinstalling csharp-mode fixed it. Not
sure it works for Jostein.

-- 
Saulius Menkevičius (saulius.menkevicius@gmail.com)

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Alan Mackenzie]

Hello, Saulius.

On Mon, Mar 21, 2016 at 11:51:25PM +0200, Saulius Menkevičius wrote:

> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > Explanation for the bug I saw: a new "language variable",
> > c-<>-notable-chars-re, had been defined in CC Mode, but not compiled into
> > the csharp-mode part.  That left it's value at nil, rather than the
> > string it should be.  This nil then caused the error.

> > But it could be I'm looking at totally the wrong problem.

> It worked for me, actually. Removing csharp-mode and then reinstalling
> via package manager fixed the issue for me.

That's great!  As a general principle, csharp-mode should be compiled
together with the CC Mode that it's going to be run with.

> > The same thing happening on Java would surprise me.  That would imply a
> > different problem.

> I couldn't replicate the Java issue myself..

That was a newish CC Mode bug solely in the master branch of the Emacs
repository, now fixed.

[ .... ]

> So the issue is resolved for me, reinstalling csharp-mode fixed it. Not
> sure it works for Jostein.

It does, now.  I'm going to close the bug.  Thanks for the report and all
the help!

> -- 
> Saulius Menkevičius (saulius.menkevicius@gmail.com)

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Alan Mackenzie]

Bug resolved by recompiling csharp-mode.el with the version of CC Mode
in use.

Unrelated bug in master branch with similar symptoms fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).