26.0.50; CEDET stickyfunc-mode broken after recent removal of default-FOO variables

26.0.50; CEDET stickyfunc-mode broken after recent removal of default-FOO variables

[Andrew Moore]

CEDET stickyfunc-mode appears to be broken after recent commits:

    e6681b27394a23979c3aef3925f78ef9cd75bd32 (“Nix more uses of default-FOO variables (Bug#24946)”),
    73d47d22197175f08b2dd62e76d7138872e611d2 (“Remove obsolete default-FOO variables”)

Being enamored of stickyfunc-mode, I’m hoping that someone might point me in the direction of a resolution.  What I have so far is only a partial workaround.

Prior to the above commits, CEDET and stickyfunc-mode were enabled globally via the following lines in my .emacs:

    (load (concat cedet-load-path "/semantic/loaddefs.el"))
    (semantic-mode)
    (mapc
      (lambda (mode)
        (funcall mode 1))
      '(global-semantic-idle-summary-mode
       global-semantic-idle-completions-mode
       global-semantic-idle-scheduler-mode
       global-semanticdb-minor-mode))
       global-semantic-stickyfunc-mode))

(This might be more properly done via customization, but the effect should be the same)

After commits removing the obsolete `default-FOO’ variables, including `default-header-line-format', Emacs drops into the debugger on startup as result of the above lines.  One work around is to enable stickyfunc-mode via major mode hooks.  E.g., after commenting out the last line above `global-semantic-stickyfunc-mode’, stickyfunc mode can be enabled in C mode with the following hook:

    (defun c-mode-setup ()
      "Adjust C mode environment."
      (semantic-mode)
      (make-local-variable 'header-line-format)
      (setq header-line-format
               '(:eval
                 (list
                  (propertize " " 'display
                                    '((space :align-to 0)))
                  (semantic-stickyfunc-fetch-stickyline))))
      (semantic-stickyfunc-mode))

    (add-hook 'c-mode-common-hook #'c-mode-setup)

Unfortunately, adding this to emacs-lisp-mode-hook causes Emacs to again drop into the debugger on startup.  In fact, whereas stickyfunc-mode works with C code, it seems not to have worked with Lisp for a while now (i.e., prior to removal of the `default-FOO’ variables).  Obviously it would help to identify the breaking commit, but I’m not even sure what time frame to examine.

In the mean time, perhaps someone could offer some insight into what’s going on?  Why did removal of the obsolete variable `default-header-line-format’ wreck such havoc?  Should I be looking at CEDET code, or might the problem be of a more generic nature that could be affecting other code that I haven’t come across yet?  Once enough information has been gathered, a bug report will be submitted.  Thank you!
-AM

In GNU Emacs 26.0.50.3 (x86_64-apple-darwin15.6.0, NS appkit-1404.47 Version 10.11.6 (Build 15G1108))
of 2016-11-16 built on vesta.slewsys.org
Repository revision: dc4b8a0c329a9d9e56e6be63cb4a0f59a952b07f
Windowing system distributor 'Apple', version 10.3.1404
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
/opt/src/programming/emacs/emacs
mwheel-scroll: End of buffer [4 times]
Compilation exited abnormally with code 2

Configured using:
'configure --prefix=/opt --with-ns CC=/usr/bin/clang
CXX=/usr/bin/clang++'

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

Important settings:
 value of $LC_ALL: en_US.UTF-8
 value of $LANG: en_US.UTF-8
 locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
 shell-dirtrack-mode: t
 tooltip-mode: t
 global-eldoc-mode: t
 electric-indent-mode: t
 mouse-wheel-mode: t
 tool-bar-mode: t
 menu-bar-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 blink-cursor-mode: t
 auto-composition-mode: t
 auto-encryption-mode: t
 auto-compression-mode: t
 line-number-mode: t
 transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils compile shell pcomplete comint ansi-color ring time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win 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
term/tty-colors 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
obarray 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 215600 6717)
(symbols 48 20559 0)
(miscs 40 52 123)
(strings 32 20332 6483)
(string-bytes 1 663313)
(vectors 16 35782)
(vector-slots 8 676057 7085)
(floats 8 186 173)
(intervals 56 582 0)
(buffers 976 13))

Re: 26.0.50; CEDET stickyfunc-mode broken after recent removal of default-FOO variables

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 5952 bytes --]

I could not reproduce this issue.  What is cedet-load-path?

On 2016-11-16 21:32, Andrew Moore wrote:
> CEDET stickyfunc-mode appears to be broken after recent commits:
> 
>     e6681b27394a23979c3aef3925f78ef9cd75bd32 (“Nix more uses of default-FOO variables (Bug#24946)”),
>     73d47d22197175f08b2dd62e76d7138872e611d2 (“Remove obsolete default-FOO variables”)
> 
> Being enamored of stickyfunc-mode, I’m hoping that someone might point me in the direction of a resolution.  What I have so far is only a partial workaround.
> 
> Prior to the above commits, CEDET and stickyfunc-mode were enabled globally via the following lines in my .emacs:
> 
>     (load (concat cedet-load-path "/semantic/loaddefs.el"))
>     (semantic-mode)
>     (mapc
>       (lambda (mode)
>         (funcall mode 1))
>       '(global-semantic-idle-summary-mode
>        global-semantic-idle-completions-mode
>        global-semantic-idle-scheduler-mode
>        global-semanticdb-minor-mode))
>        global-semantic-stickyfunc-mode))
> 
> (This might be more properly done via customization, but the effect should be the same)
> 
> After commits removing the obsolete `default-FOO’ variables, including `default-header-line-format', Emacs drops into the debugger on startup as result of the above lines.  One work around is to enable stickyfunc-mode via major mode hooks.  E.g., after commenting out the last line above `global-semantic-stickyfunc-mode’, stickyfunc mode can be enabled in C mode with the following hook:
> 
>     (defun c-mode-setup ()
>       "Adjust C mode environment."
>       (semantic-mode)
>       (make-local-variable 'header-line-format)
>       (setq header-line-format
>                '(:eval
>                  (list
>                   (propertize " " 'display
>                                     '((space :align-to 0)))
>                   (semantic-stickyfunc-fetch-stickyline))))
>       (semantic-stickyfunc-mode))
> 
>     (add-hook 'c-mode-common-hook #'c-mode-setup)
> 
> Unfortunately, adding this to emacs-lisp-mode-hook causes Emacs to again drop into the debugger on startup.  In fact, whereas stickyfunc-mode works with C code, it seems not to have worked with Lisp for a while now (i.e., prior to removal of the `default-FOO’ variables).  Obviously it would help to identify the breaking commit, but I’m not even sure what time frame to examine.
> 
> In the mean time, perhaps someone could offer some insight into what’s going on?  Why did removal of the obsolete variable `default-header-line-format’ wreck such havoc?  Should I be looking at CEDET code, or might the problem be of a more generic nature that could be affecting other code that I haven’t come across yet?  Once enough information has been gathered, a bug report will be submitted.  Thank you!
> -AM
> 
> In GNU Emacs 26.0.50.3 (x86_64-apple-darwin15.6.0, NS appkit-1404.47 Version 10.11.6 (Build 15G1108))
> of 2016-11-16 built on vesta.slewsys.org
> Repository revision: dc4b8a0c329a9d9e56e6be63cb4a0f59a952b07f
> Windowing system distributor 'Apple', version 10.3.1404
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> /opt/src/programming/emacs/emacs
> mwheel-scroll: End of buffer [4 times]
> Compilation exited abnormally with code 2
> 
> Configured using:
> 'configure --prefix=/opt --with-ns CC=/usr/bin/clang
> CXX=/usr/bin/clang++'
> 
> Configured features:
> JPEG RSVG IMAGEMAGICK DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
> TOOLKIT_SCROLL_BARS NS
> 
> Important settings:
>  value of $LC_ALL: en_US.UTF-8
>  value of $LANG: en_US.UTF-8
>  locale-coding-system: utf-8-unix
> 
> Major mode: Lisp Interaction
> 
> Minor modes in effect:
>  shell-dirtrack-mode: t
>  tooltip-mode: t
>  global-eldoc-mode: t
>  electric-indent-mode: t
>  mouse-wheel-mode: t
>  tool-bar-mode: t
>  menu-bar-mode: t
>  file-name-shadow-mode: t
>  global-font-lock-mode: t
>  font-lock-mode: t
>  blink-cursor-mode: t
>  auto-composition-mode: t
>  auto-encryption-mode: t
>  auto-compression-mode: t
>  line-number-mode: t
>  transient-mark-mode: t
> 
> Load-path shadows:
> None found.
> 
> Features:
> (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
> bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
> dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
> password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
> mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
> mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
> mail-utils compile shell pcomplete comint ansi-color ring time-date
> mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
> lisp-float-type mwheel term/ns-win 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
> term/tty-colors 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
> obarray 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 215600 6717)
> (symbols 48 20559 0)
> (miscs 40 52 123)
> (strings 32 20332 6483)
> (string-bytes 1 663313)
> (vectors 16 35782)
> (vector-slots 8 676057 7085)
> (floats 8 186 173)
> (intervals 56 582 0)
> (buffers 976 13))
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: 26.0.50; CEDET stickyfunc-mode broken after recent removal of default-FOO variables

[Mark Oteiza]

Andrew Moore <slewsys@gmail.com> writes:
> CEDET stickyfunc-mode appears to be broken after recent commits:
>
>     e6681b27394a23979c3aef3925f78ef9cd75bd32 (“Nix more uses of default-FOO variables (Bug#24946)”),
>     73d47d22197175f08b2dd62e76d7138872e611d2 (“Remove obsolete default-FOO variables”)
>
> Being enamored of stickyfunc-mode, I’m hoping that someone might point
> me in the direction of a resolution.  What I have so far is only a
> partial workaround.
>
> Prior to the above commits, CEDET and stickyfunc-mode were enabled
> globally via the following lines in my .emacs:
>
>     (load (concat cedet-load-path "/semantic/loaddefs.el"))
>     (semantic-mode)
>     (mapc
>       (lambda (mode)
>         (funcall mode 1))
>       '(global-semantic-idle-summary-mode
>        global-semantic-idle-completions-mode
>        global-semantic-idle-scheduler-mode
>        global-semanticdb-minor-mode))
>        global-semantic-stickyfunc-mode))

Without the cedet-load-path line, the above works fine here (as the sole
contents of init.el) on e6681b27 (the latest commit listed above).  I
can open C files and sticky mode is operational.  Are you loading CEDET
from somewhere else?

Re: 26.0.50; CEDET stickyfunc-mode broken after recent removal of default-FOO variables

[Andrew Moore]

> Andrew Moore <slewsys@gmail.com> writes:
>> CEDET stickyfunc-mode appears to be broken after recent commits:
>> 
>>    e6681b27394a23979c3aef3925f78ef9cd75bd32 (“Nix more uses of default-FOO variables (Bug#24946)”),
>>    73d47d22197175f08b2dd62e76d7138872e611d2 (“Remove obsolete default-FOO variables”)
>> 
>> Being enamored of stickyfunc-mode, I’m hoping that someone might point
>> me in the direction of a resolution.  What I have so far is only a
>> partial workaround.
>> 
>> Prior to the above commits, CEDET and stickyfunc-mode were enabled
>> globally via the following lines in my .emacs:
>> 
>>    (load (concat cedet-load-path "/semantic/loaddefs.el"))
>>    (semantic-mode)
>>    (mapc
>>      (lambda (mode)
>>        (funcall mode 1))
>>      '(global-semantic-idle-summary-mode
>>       global-semantic-idle-completions-mode
>>       global-semantic-idle-scheduler-mode
>>       global-semanticdb-minor-mode))
>>       global-semantic-stickyfunc-mode))
> 

On Nov 16, 2016, at 10:00 PM, Mark Oteiza <mvoteiza@udel.edu> wrote:
> Without the cedet-load-path line, the above works fine here (as the sole
> contents of init.el) on e6681b27 (the latest commit listed above).  I
> can open C files and sticky mode is operational.  Are you loading CEDET
> from somewhere else?

Indeed, I’m not able to reproduce the problem myself now (other than stickyfunc-mode isn’t working for lisp-mode, which may have been the confounding issue).  So false report. I’ll try to be more careful.  Thank you for checking!
-AM