* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance @ 2016-03-18 9:07 Saulius Menkevičius 2016-03-18 21:13 ` bug#23053: followup on 23053 Saulius Menkevičius ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: Saulius Menkevičius @ 2016-03-18 9:07 UTC (permalink / raw) To: 23053 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)) ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: followup on 23053 2016-03-18 9:07 bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance Saulius Menkevičius @ 2016-03-18 21:13 ` Saulius Menkevičius 2016-03-18 21:33 ` bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance Jostein Kjønigsen ` (2 subsequent siblings) 3 siblings, 0 replies; 23+ messages in thread From: Saulius Menkevičius @ 2016-03-18 21:13 UTC (permalink / raw) To: 23053 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) ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-18 9:07 bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance Saulius Menkevičius 2016-03-18 21:13 ` bug#23053: followup on 23053 Saulius Menkevičius @ 2016-03-18 21:33 ` Jostein Kjønigsen 2016-03-18 23:08 ` Ingo Lohmar [not found] ` <mailman.7741.1458315553.843.bug-gnu-emacs@gnu.org> 2016-03-19 14:15 ` Saulius Menkevičius 3 siblings, 1 reply; 23+ messages in thread From: Jostein Kjønigsen @ 2016-03-18 21:33 UTC (permalink / raw) To: 23053 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-18 21:33 ` bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance Jostein Kjønigsen @ 2016-03-18 23:08 ` Ingo Lohmar 2016-03-19 7:29 ` Jostein Kjønigsen 0 siblings, 1 reply; 23+ messages in thread From: Ingo Lohmar @ 2016-03-18 23:08 UTC (permalink / raw) To: jostein, 23053 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-18 23:08 ` Ingo Lohmar @ 2016-03-19 7:29 ` Jostein Kjønigsen 2016-03-19 8:27 ` Jostein Kjønigsen 2016-03-19 10:05 ` Ingo Lohmar 0 siblings, 2 replies; 23+ messages in thread From: Jostein Kjønigsen @ 2016-03-19 7:29 UTC (permalink / raw) To: Ingo Lohmar, jostein, 23053 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-19 7:29 ` Jostein Kjønigsen @ 2016-03-19 8:27 ` Jostein Kjønigsen 2016-03-21 12:26 ` Alan Mackenzie 2016-03-19 10:05 ` Ingo Lohmar 1 sibling, 1 reply; 23+ messages in thread From: Jostein Kjønigsen @ 2016-03-19 8:27 UTC (permalink / raw) To: jostein, Ingo Lohmar, 23053 \> 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-19 8:27 ` Jostein Kjønigsen @ 2016-03-21 12:26 ` Alan Mackenzie 2016-03-21 12:45 ` Jostein Kjønigsen 0 siblings, 1 reply; 23+ messages in thread From: Alan Mackenzie @ 2016-03-21 12:26 UTC (permalink / raw) To: jostein; +Cc: Ingo Lohmar, 23053 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-21 12:26 ` Alan Mackenzie @ 2016-03-21 12:45 ` Jostein Kjønigsen 2016-03-21 21:53 ` Saulius Menkevičius 2016-03-25 18:54 ` Alan Mackenzie 0 siblings, 2 replies; 23+ messages in thread From: Jostein Kjønigsen @ 2016-03-21 12:45 UTC (permalink / raw) To: Alan Mackenzie, jostein; +Cc: Ingo Lohmar, 23053 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-21 12:45 ` Jostein Kjønigsen @ 2016-03-21 21:53 ` Saulius Menkevičius 2016-03-22 10:21 ` Jostein Kjønigsen 2016-03-25 18:54 ` Alan Mackenzie 1 sibling, 1 reply; 23+ messages in thread From: Saulius Menkevičius @ 2016-03-21 21:53 UTC (permalink / raw) To: jostein; +Cc: Alan Mackenzie, Ingo Lohmar, 23053 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) ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-21 21:53 ` Saulius Menkevičius @ 2016-03-22 10:21 ` Jostein Kjønigsen 0 siblings, 0 replies; 23+ messages in thread From: Jostein Kjønigsen @ 2016-03-22 10:21 UTC (permalink / raw) To: Saulius Menkevičius, jostein; +Cc: Alan Mackenzie, Ingo Lohmar, 23053 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-21 12:45 ` Jostein Kjønigsen 2016-03-21 21:53 ` Saulius Menkevičius @ 2016-03-25 18:54 ` Alan Mackenzie 2016-03-26 7:26 ` Jostein Kjønigsen 1 sibling, 1 reply; 23+ messages in thread From: Alan Mackenzie @ 2016-03-25 18:54 UTC (permalink / raw) To: jostein; +Cc: Ingo Lohmar, 23053 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-25 18:54 ` Alan Mackenzie @ 2016-03-26 7:26 ` Jostein Kjønigsen 2016-03-26 10:48 ` Alan Mackenzie 0 siblings, 1 reply; 23+ messages in thread From: Jostein Kjønigsen @ 2016-03-26 7:26 UTC (permalink / raw) To: Alan Mackenzie, jostein; +Cc: Ingo Lohmar, 23053 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-26 7:26 ` Jostein Kjønigsen @ 2016-03-26 10:48 ` Alan Mackenzie 0 siblings, 0 replies; 23+ messages in thread From: Alan Mackenzie @ 2016-03-26 10:48 UTC (permalink / raw) To: jostein; +Cc: Ingo Lohmar, 23053 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-19 7:29 ` Jostein Kjønigsen 2016-03-19 8:27 ` Jostein Kjønigsen @ 2016-03-19 10:05 ` Ingo Lohmar 2016-03-19 15:00 ` jostein 1 sibling, 1 reply; 23+ messages in thread From: Ingo Lohmar @ 2016-03-19 10:05 UTC (permalink / raw) To: Jostein Kjønigsen, jostein, 23053 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-19 10:05 ` Ingo Lohmar @ 2016-03-19 15:00 ` jostein 2016-03-19 17:54 ` Jostein Kjønigsen 0 siblings, 1 reply; 23+ messages in thread From: jostein @ 2016-03-19 15:00 UTC (permalink / raw) To: i.lohmar, jostein, 23053 [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-19 15:00 ` jostein @ 2016-03-19 17:54 ` Jostein Kjønigsen 2016-03-20 20:57 ` Jostein Kjønigsen 0 siblings, 1 reply; 23+ messages in thread From: Jostein Kjønigsen @ 2016-03-19 17:54 UTC (permalink / raw) To: jostein, i.lohmar, 23053 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-19 17:54 ` Jostein Kjønigsen @ 2016-03-20 20:57 ` Jostein Kjønigsen 0 siblings, 0 replies; 23+ messages in thread From: Jostein Kjønigsen @ 2016-03-20 20:57 UTC (permalink / raw) To: jostein, i.lohmar, 23053, acm 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <mailman.7741.1458315553.843.bug-gnu-emacs@gnu.org>]
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance [not found] ` <mailman.7741.1458315553.843.bug-gnu-emacs@gnu.org> @ 2016-03-19 13:14 ` Alan Mackenzie 0 siblings, 0 replies; 23+ messages in thread From: Alan Mackenzie @ 2016-03-19 13:14 UTC (permalink / raw) To: Saulius Menkevičius; +Cc: 23053 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-18 9:07 bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance Saulius Menkevičius ` (2 preceding siblings ...) [not found] ` <mailman.7741.1458315553.843.bug-gnu-emacs@gnu.org> @ 2016-03-19 14:15 ` Saulius Menkevičius 2016-03-20 21:16 ` Alan Mackenzie 3 siblings, 1 reply; 23+ messages in thread From: Saulius Menkevičius @ 2016-03-19 14:15 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 23053 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) ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-19 14:15 ` Saulius Menkevičius @ 2016-03-20 21:16 ` Alan Mackenzie 2016-03-21 21:51 ` Saulius Menkevičius 0 siblings, 1 reply; 23+ messages in thread From: Alan Mackenzie @ 2016-03-20 21:16 UTC (permalink / raw) To: Saulius Menkevičius; +Cc: 23053 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-20 21:16 ` Alan Mackenzie @ 2016-03-21 21:51 ` Saulius Menkevičius 2016-03-26 10:55 ` Alan Mackenzie 2016-03-26 10:59 ` Alan Mackenzie 0 siblings, 2 replies; 23+ messages in thread From: Saulius Menkevičius @ 2016-03-21 21:51 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 23053 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) ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-21 21:51 ` Saulius Menkevičius @ 2016-03-26 10:55 ` Alan Mackenzie 2016-03-26 10:59 ` Alan Mackenzie 1 sibling, 0 replies; 23+ messages in thread From: Alan Mackenzie @ 2016-03-26 10:55 UTC (permalink / raw) To: Saulius Menkevičius; +Cc: 23053 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance 2016-03-21 21:51 ` Saulius Menkevičius 2016-03-26 10:55 ` Alan Mackenzie @ 2016-03-26 10:59 ` Alan Mackenzie 1 sibling, 0 replies; 23+ messages in thread From: Alan Mackenzie @ 2016-03-26 10:59 UTC (permalink / raw) To: 23053-done 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2016-03-26 10:59 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-18 9:07 bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance Saulius Menkevičius 2016-03-18 21:13 ` bug#23053: followup on 23053 Saulius Menkevičius 2016-03-18 21:33 ` bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance Jostein Kjønigsen 2016-03-18 23:08 ` Ingo Lohmar 2016-03-19 7:29 ` Jostein Kjønigsen 2016-03-19 8:27 ` Jostein Kjønigsen 2016-03-21 12:26 ` Alan Mackenzie 2016-03-21 12:45 ` Jostein Kjønigsen 2016-03-21 21:53 ` Saulius Menkevičius 2016-03-22 10:21 ` Jostein Kjønigsen 2016-03-25 18:54 ` Alan Mackenzie 2016-03-26 7:26 ` Jostein Kjønigsen 2016-03-26 10:48 ` Alan Mackenzie 2016-03-19 10:05 ` Ingo Lohmar 2016-03-19 15:00 ` jostein 2016-03-19 17:54 ` Jostein Kjønigsen 2016-03-20 20:57 ` Jostein Kjønigsen [not found] ` <mailman.7741.1458315553.843.bug-gnu-emacs@gnu.org> 2016-03-19 13:14 ` Alan Mackenzie 2016-03-19 14:15 ` Saulius Menkevičius 2016-03-20 21:16 ` Alan Mackenzie 2016-03-21 21:51 ` Saulius Menkevičius 2016-03-26 10:55 ` Alan Mackenzie 2016-03-26 10:59 ` Alan Mackenzie
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.