bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[yyoncho]

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

As per post-self-insert-hook documentation.

> Hook run at the end of `self-insert-command'.
> This is run after inserting the character.

This does not hold by default in cc-mode due to the following mapped by
default functions:

> (define-key c-mode-base-map "#"         'c-electric-pound)
> (define-key c-mode-base-map "{"         'c-electric-brace)
> (define-key c-mode-base-map "}"         'c-electric-brace)
> (define-key c-mode-base-map "/"         'c-electric-slash)
> (define-key c-mode-base-map "*"         'c-electric-star)
> (define-key c-mode-base-map ";"         'c-electric-semi&comma)
> (define-key c-mode-base-map ","         'c-electric-semi&comma)
> (define-key c-mode-base-map ":"         'c-electric-colon)
> (define-key c-mode-base-map "("         'c-electric-paren)
> (define-key c-mode-base-map ")"         'c-electric-paren)

All of these functions (or at least majority) contain the following lines:

> (let (post-self-insert-hook) ; Disable random functionality.
>      (self-insert-command (prefix-numeric-value arg)))

Possible fixes:

1. Do not bind the functions by default.
2. Rewrite them so they do not inhibit post-self-insert-hook functions.

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
 of 2019-11-23 built on kyoncho-H87-D3H
Repository revision: 8934762bb37273e6606097de92dcc2556456acd2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Linux Mint 19.1

Configured using:
 'configure --with-modules --with-json'

Configured features:
XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY GNUTLS
LIBXML2 FREETYPE HARFBUZZ XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM
MODULES THREADS JSON PDUMPER GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MONETARY: bg_BG.UTF-8
  value of $LC_NUMERIC: bg_BG.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  helm-spacemacs-help-mode: t
  global-magit-file-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  helm-descbinds-mode: t
  helm-mode: t
  helm-flx-mode: t
  dap-tooltip-mode: t
  dap-ui-mode: t
  gdb-many-windows: t
  dap-mode: t
  gradle-mode: t
  global-git-gutter+-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  pupo-mode: t
  purpose-mode: t
  evil-escape-mode: t
  projectile-mode: t
  recentf-mode: t
  company-mode: t
  auto-compile-mode: t
  elisp-slime-nav-mode: t
  eval-sexp-fu-flash-mode: t
  goto-address-prog-mode: t
  bug-reference-prog-mode: t
  auto-highlight-symbol-mode: t
  flycheck-pos-tip-mode: t
  global-flycheck-mode: t
  highlight-numbers-mode: t
  highlight-parentheses-mode: t
  rainbow-delimiters-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  evil-cleverparens-mode: t
  show-smartparens-global-mode: t
  show-smartparens-mode: t
  smartparens-mode: t
  persistent-scratch-autosave-mode: t
  winner-mode: t
  global-spacemacs-whitespace-cleanup-mode: t
  spacemacs-whitespace-cleanup-mode: t
  winum-mode: t
  global-vi-tilde-fringe-mode: t
  save-place-mode: t
  savehist-mode: t
  persp-mode: t
  global-hl-todo-mode: t
  hl-todo-mode: t
  global-fasd-mode: t
  eyebrowse-mode: t
  evil-mc-mode: t
  global-anzu-mode: t
  anzu-mode: t
  editorconfig-mode: t
  doom-modeline-mode: t
  clean-aindent-mode: t
  hybrid-mode: t
  which-key-mode: t
  override-global-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  shell-dirtrack-mode: t
  evil-mode: t
  evil-local-mode: t
  spacemacs-leader-override-mode: t
  global-spacemacs-leader-override-mode: t
  global-hl-line-mode: t
  xterm-mouse-mode: t
  global-auto-revert-mode: t
  ido-vertical-mode: t
  global-page-break-lines-mode: t
  page-break-lines-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-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
  hs-minor-mode: t

Load-path shadows:
/home/kyoncho/.emacs.d/elpa/27.0/develop/ht-20190924.704/ht hides
/home/kyoncho/.emacs.d/core/libs/ht
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-exp
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-exp
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-footnote
hides /usr/local/share/emacs/27.0.50/lisp/org/org-footnote
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-scheme
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-scheme
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-entities
hides /usr/local/share/emacs/27.0.50/lisp/org/org-entities
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-clojure
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-clojure
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-odt
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-odt
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-ledger
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ledger
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-man
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-man
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-duration
hides /usr/local/share/emacs/27.0.50/lisp/org/org-duration
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-core
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-core
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-css
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-css
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-org
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-org
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-sass
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sass
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-maxima
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-maxima
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-matlab
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-matlab
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-ebnf
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ebnf
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-ocaml
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ocaml
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-ascii
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-ascii
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-lilypond
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lilypond
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-md
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-md
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-timer
hides /usr/local/share/emacs/27.0.50/lisp/org/org-timer
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-calc
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-calc
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-macro
hides /usr/local/share/emacs/27.0.50/lisp/org/org-macro
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-attach
hides /usr/local/share/emacs/27.0.50/lisp/org/org-attach
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-plantuml
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-plantuml
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-element
hides /usr/local/share/emacs/27.0.50/lisp/org/org-element
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-eww
hides /usr/local/share/emacs/27.0.50/lisp/org/org-eww
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-crypt
hides /usr/local/share/emacs/27.0.50/lisp/org/org-crypt
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-forth
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-forth
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-clock
hides /usr/local/share/emacs/27.0.50/lisp/org/org-clock
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-colview
hides /usr/local/share/emacs/27.0.50/lisp/org/org-colview
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-w3m
hides /usr/local/share/emacs/27.0.50/lisp/org/org-w3m
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-src
hides /usr/local/share/emacs/27.0.50/lisp/org/org-src
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-vala
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-vala
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-stan
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-stan
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-gnus
hides /usr/local/share/emacs/27.0.50/lisp/org/org-gnus
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-fortran
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-fortran
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-lob
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lob
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-processing
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-processing
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-mobile
hides /usr/local/share/emacs/27.0.50/lisp/org/org-mobile
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-groovy
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-groovy
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-habit
hides /usr/local/share/emacs/27.0.50/lisp/org/org-habit
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-shen
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-shen
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-lua
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lua
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-ruby
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ruby
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-info
hides /usr/local/share/emacs/27.0.50/lisp/org/org-info
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-mouse
hides /usr/local/share/emacs/27.0.50/lisp/org/org-mouse
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-archive
hides /usr/local/share/emacs/27.0.50/lisp/org/org-archive
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-rmail
hides /usr/local/share/emacs/27.0.50/lisp/org/org-rmail
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-comint
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-comint
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-io
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-io
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-hledger
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-hledger
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-id
hides /usr/local/share/emacs/27.0.50/lisp/org/org-id
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-octave
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-octave
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-ref
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ref
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-table
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-table
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-beamer
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-beamer
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-picolisp
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-picolisp
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-agenda
hides /usr/local/share/emacs/27.0.50/lisp/org/org-agenda
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-python
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-python
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-makefile
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-makefile
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-texinfo
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-texinfo
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-gnuplot
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-gnuplot
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-lint
hides /usr/local/share/emacs/27.0.50/lisp/org/org-lint
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-publish
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-publish
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-version
hides /usr/local/share/emacs/27.0.50/lisp/org/org-version
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-perl
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-perl
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-eshell
hides /usr/local/share/emacs/27.0.50/lisp/org/org-eshell
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-tangle
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-tangle
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-ctags
hides /usr/local/share/emacs/27.0.50/lisp/org/org-ctags
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-eval
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-eval
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-latex
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-latex
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-keys
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-keys
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-java
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-java
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-macs
hides /usr/local/share/emacs/27.0.50/lisp/org/org-macs
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-awk
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-awk
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-abc
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-abc
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-asymptote
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-asymptote
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-org
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-org
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-js
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-js
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-plot
hides /usr/local/share/emacs/27.0.50/lisp/org/org-plot
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-indent
hides /usr/local/share/emacs/27.0.50/lisp/org/org-indent
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-table
hides /usr/local/share/emacs/27.0.50/lisp/org/org-table
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-sql
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sql
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-screen
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-screen
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-dot
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-dot
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-coq
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-coq
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-pcomplete
hides /usr/local/share/emacs/27.0.50/lisp/org/org-pcomplete
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-mscgen
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-mscgen
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-irc
hides /usr/local/share/emacs/27.0.50/lisp/org/org-irc
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-latex
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-latex
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox hides
/usr/local/share/emacs/27.0.50/lisp/org/ox
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-capture
hides /usr/local/share/emacs/27.0.50/lisp/org/org-capture
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org
hides /usr/local/share/emacs/27.0.50/lisp/org/org
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-feed
hides /usr/local/share/emacs/27.0.50/lisp/org/org-feed
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-shell
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-shell
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-protocol
hides /usr/local/share/emacs/27.0.50/lisp/org/org-protocol
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-R
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-R
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-ditaa
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ditaa
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-icalendar
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-icalendar
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-sed
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sed
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-lisp
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lisp
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-datetree
hides /usr/local/share/emacs/27.0.50/lisp/org/org-datetree
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-install
hides /usr/local/share/emacs/27.0.50/lisp/org/org-install
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-loaddefs
hides /usr/local/share/emacs/27.0.50/lisp/org/org-loaddefs
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-sqlite
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sqlite
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-bibtex
hides /usr/local/share/emacs/27.0.50/lisp/org/org-bibtex
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-J
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-J
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-inlinetask
hides /usr/local/share/emacs/27.0.50/lisp/org/org-inlinetask
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-mhe
hides /usr/local/share/emacs/27.0.50/lisp/org/org-mhe
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-emacs-lisp
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-emacs-lisp
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-faces
hides /usr/local/share/emacs/27.0.50/lisp/org/org-faces
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-docview
hides /usr/local/share/emacs/27.0.50/lisp/org/org-docview
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ox-html
hides /usr/local/share/emacs/27.0.50/lisp/org/ox-html
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob hides
/usr/local/share/emacs/27.0.50/lisp/org/ob
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-list
hides /usr/local/share/emacs/27.0.50/lisp/org/org-list
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-haskell
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-haskell
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-bbdb
hides /usr/local/share/emacs/27.0.50/lisp/org/org-bbdb
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/ob-C
hides /usr/local/share/emacs/27.0.50/lisp/org/ob-C
/home/kyoncho/.emacs.d/elpa/27.0/develop/org-plus-contrib-20191111/org-compat
hides /usr/local/share/emacs/27.0.50/lisp/org/org-compat

Features:
(shadow sort mail-extr emacsbug sendmail helm-c-yasnippet
evil-indent-plus hippie-exp org-eldoc evil-org org-table ob-groovy ob-js
ob-python ob-java ob-C ob-scala ensime-expand-region expand-region-core
expand-region-custom ensime ensime-mode ensime-sbt sbt-mode
sbt-mode-rgrep sbt-mode-comint sbt-mode-buffer sbt-mode-project
sbt-mode-vars ensime-http ensime-ui ensime-semantic-highlight ensime-doc
ensime-search ensime-helm ensime-undo ensime-startup ensime-refactor
ensime-popup ensime-eldoc ensime-notes ensime-company ensime-editor
ensime-ivy ensime-model ivy delsel colir ivy-overlay popup ensime-debug
ensime-stacktrace ensime-inf ensime-overlay ensime-completion-util
ensime-config ensime-util ensime-client ensime-vars smartparens-scala
scala-mode scala-mode-prettify-symbols scala-mode-imenu scala-mode-map
scala-mode-fontlock scala-mode-indent scala-mode-paragraph
scala-mode-syntax scala-mode-lib arc-mode archive-mode ensime-macros
ob-shell ob-clojure org-bullets org-download toc-org image-file org-eww
org-rmail org-mhe org-irc org-info org-gnus nnir gnus-sum shr svg dom
gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source
utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader
org-docview doc-view image-mode exif org-bibtex bibtex org-bbdb org-w3m
smartparens-org orgit org-element avl-tree org ob ob-tangle ob-ref
ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint ob-keys
org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp
ob-core ob-eval org-compat org-macs org-loaddefs cal-menu calendar
cal-loaddefs helm-projectile eieio-opt mwim pulse cursor-sensor
company-go go-mode find-file helm-ag dired-aux drupal-mode
drupal/emacs-drush drupal/flycheck drupal/phpcs drupal/ispell
drupal/etags drupal/eldoc sql php-mode speedbar sb-image ezimage dframe
cc-langs php-face php php-project diff-hl-dired diff-hl vc-dir dired-x
gravatar url-cache misearch multi-isearch semantic/find helm-semantic
helm-imenu semantic/util-modes semantic/util semantic semantic/tag
semantic/lex semantic/fw mode-local cedet jka-compr ffap helm-swoop
vc-mtn vc-hg mule-util magit-extras fill-column-indicator
helm-spacemacs-help helm-command helm-elisp helm-eval edebug backtrace
magit-gitflow evil-magit git-rebase forge-list forge-commands forge-semi
forge-bitbucket buck forge-gogs gogs forge-gitea gtea forge-gitlab glab
forge-github ghub-graphql treepy gsexp ghub gnutls forge-notify
forge-revnote forge-pullreq forge-issue forge-topic forge-post
forge-repo forge forge-core forge-db closql emacsql-sqlite emacsql
emacsql-compiler magit-bookmark magit-submodule magit-obsolete
magit-popup magit-blame magit-stash magit-reflog magit-bisect magit-push
magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func magit-diff
diminish smerge-mode magit-core magit-autorevert magit-margin
magit-transient magit-process magit-mode transient flx helm-x-files
helm-for-files helm-bookmark helm-adaptive helm-info bookmark pp
helm-external helm-net evil-surround whitespace tabify helm-fasd
helm-descbinds helm-mode helm-files helm-buffers helm-occur helm-tags
helm-locate helm-grep helm-regexp helm-utils helm-help helm-types
helm-flx helm helm-source helm-multi-match helm-lib vc-git diff-mode
vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher dap-java
dap-mouse dap-ui gdb-mi gud bui bui-list bui-info bui-entry bui-core
bui-history bui-button bui-utils tree-mode dap-mode dap-overlays lsp-ui
lsp-ui-doc lsp-ui-imenu lsp-ui-peek lsp-ui-sideline view company-lsp
flycheck-rust lsp-ui-flycheck lsp-clients lsp-pwsh lsp-terraform
lsp-yaml lsp-vhdl lsp-haxe lsp-erlang lsp-fsharp lsp-metals lsp-elm
lsp-dart lsp-clojure lsp-go lsp-xml lsp-css lsp-intelephense lsp-vetur
lsp-html lsp-solargraph lsp-rust lsp-pyls lsp-java request lsp lsp-mode
ewoc smartparens-markdown markdown-mode color spinner network-stream
inline em-glob esh-util dash-functional bindat flymake-proc flymake
gradle-mode maven-test-mode company-c-headers cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
editorconfig-core editorconfig-core-handle editorconfig-fnmatch
git-gutter-fringe+ fringe-helper git-gutter+ git-commit with-editor
async-bytecomp async server magit-git magit-section magit-utils crm
log-edit message rfc822 mml mml-sec epa gnus-util rmail rmail-loaddefs
text-property-search mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log face-remap spacemacs-purpose-popwin window-purpose-x
imenu-list dired dired-loaddefs window-purpose window-purpose-fixes
window-purpose-prefix-overload window-purpose-switch
window-purpose-layout window-purpose-core window-purpose-configuration
window-purpose-utils evil-escape projectile grep ibuf-ext ibuffer
ibuffer-loaddefs tramp-sh docker-tramp tramp-cache tramp tramp-loaddefs
trampver tramp-integration files-x tramp-compat parse-time iso8601
time-date ls-lisp recentf tree-widget evil-better-visual-line
company-files company-keywords company-etags company-gtags
company-dabbrev-code company-dabbrev company-semantic company-template
company-capf php-extras company overseer pkg-info url-http url url-proxy
url-privacy url-expand url-methods url-history mailcap url-auth
url-cookie url-domsuf url-util url-gw nsm rmc puny epl compile
auto-compile packed elisp-slime-nav etags fileloop generator xref
project flycheck-package package-lint let-alist imenu finder
cider-eval-sexp-fu eval-sexp-fu goto-addr bug-reference
auto-highlight-symbol evil-lisp-state flycheck-pos-tip pos-tip flycheck
find-func highlight-numbers parent-mode highlight-parentheses hideshow
rainbow-delimiters yasnippet-snippets clojure-snippets yasnippet
evil-cleverparens evil-cleverparens-text-objects evil-cleverparens-util
smartparens-config smartparens-text smartparens paredit
persistent-scratch winner xterm-color spacemacs-whitespace-cleanup
ws-butler winum vi-tilde-fringe symbol-overlay string-inflection
saveplace savehist popwin persp-mode noflet cl-indent hl-todo fasd
eyebrowse evil-unimpaired evil-textobj-line evil-mc
evil-mc-command-execute evil-mc-command-record evil-mc-cursor-make
evil-mc-region evil-mc-cursor-state evil-mc-undo evil-mc-vars
evil-mc-known-commands evil-mc-common evil-anzu anzu editorconfig
noutline outline doom-modeline doom-modeline-segments doom-modeline-env
doom-modeline-core shrink-path f s dash all-the-icons
all-the-icons-faces data-material data-weathericons data-octicons
data-fileicons data-faicons data-alltheicons memoize clean-aindent-mode
clang-format xml helm-easymenu gh-common marshal drupal/pcomplete
hybrid-mode evil-evilified-state which-key use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core hydra lv cus-edit
cus-start cus-load evil evil-keybindings evil-integration undo-tree diff
evil-maps evil-commands reveal flyspell ispell evil-jumps
evil-command-window evil-types evil-search evil-ex shell pcomplete
comint ansi-color evil-macros evil-repeat evil-states evil-core
evil-common windmove thingatpt rect evil-digraphs evil-vars ring
bind-map quelpa mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr lisp-mnt help-fns radix-tree
hl-line xt-mouse autorevert filenotify cl-extra disp-table wid-edit
spacemacs-dark-theme spacemacs-common format-spec info finder-inf
ido-vertical-mode ido core-spacemacs core-use-package-ext
core-transient-state core-micro-state core-toggle core-keybindings
core-fonts-support core-themes-support core-display-init core-jump
core-release-management core-custom-settings core-configuration-layer
eieio-compat core-progress-bar core-spacemacs-buffer core-funcs ht cl
help-mode warnings package browse-url url-handlers url-parse auth-source
cl-seq password-cache json map url-vars seq eieio byte-opt bytecomp
byte-compile cconv eieio-core eieio-loaddefs epg epg-config
core-command-line pcase core-debug edmacro kmacro derived cl-macs gv
profiler easymenu cl-loaddefs cl-lib core-hooks page-break-lines
easy-mmode core-env load-env-vars rx core-dotspacemacs advice
core-emacs-backports subr-x core-dumper tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer 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 composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray 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 threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 1748405 1637619)
 (symbols 48 124025 14)
 (strings 32 353167 161247)
 (string-bytes 1 11869694)
 (vectors 16 146728)
 (vector-slots 8 3379598 989814)
 (floats 8 1585 12951)
 (intervals 56 79951 27733)
 (buffers 1000 123))

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

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Yyoncho.

On Wed, Nov 27, 2019 at 22:00:26 +0200, yyoncho wrote:
> As per post-self-insert-hook documentation.

> > Hook run at the end of `self-insert-command'.
> > This is run after inserting the character.

Yes.  This is a problematic hook, since it is capable of disrupting the
correct functionality of any Lisp program which uses
self-insert-command.  This transpired in CC Mode, so to make
c-electric-brace and friends work, the action of the hook was nullified.

> This does not hold by default in cc-mode due to the following mapped by
> default functions:

> > (define-key c-mode-base-map "#"         'c-electric-pound)
> > (define-key c-mode-base-map "{"         'c-electric-brace)
> > (define-key c-mode-base-map "}"         'c-electric-brace)
> > (define-key c-mode-base-map "/"         'c-electric-slash)
> > (define-key c-mode-base-map "*"         'c-electric-star)
> > (define-key c-mode-base-map ";"         'c-electric-semi&comma)
> > (define-key c-mode-base-map ","         'c-electric-semi&comma)
> > (define-key c-mode-base-map ":"         'c-electric-colon)
> > (define-key c-mode-base-map "("         'c-electric-paren)
> > (define-key c-mode-base-map ")"         'c-electric-paren)

> All of these functions (or at least majority) contain the following lines:

> > (let (post-self-insert-hook) ; Disable random functionality.
> >      (self-insert-command (prefix-numeric-value arg)))

Yes.  This was one way to get self-insert-function to perform its
correct functionality, namely inserting exactly one copy of a typed key
(or alternatively N copies when there's a prefix key).

> Possible fixes:

First question, what's the problem?  What do you want to do that the
above mechanism hinders?

> 1. Do not bind the functions by default.

They are essential to the correct functioning of CC Mode.

> 2. Rewrite them so they do not inhibit post-self-insert-hook functions.

This is difficult.  If there were an easy way to do this, I would have
done it.  Note that, from the point of view of a major mode,
post-self-insert-hook is totally random functionality - it is a bit like
a trojan horse.  The major mode has no way to control what it does, thus
is unable to guarantee the major mode will work.

There are other possible "fixes", for example modifying these functions
so that they don't use self-insert-command at all, but somehow I don't
think that's what you want.

Another fix would be to specify restrictions on what one is allowed to
do in this hook.  I would prefer this, but other people would object
strongly.

I would advise against using post-self-insert-hook, if you possibly can.
after-change-functions may be a good alternative.  Maybe you can't.  So,
again, what is it you're trying to do?

> In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
>  of 2019-11-23 built on kyoncho-H87-D3H
> Repository revision: 8934762bb37273e6606097de92dcc2556456acd2
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
> System Description: Linux Mint 19.1

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[yyoncho]

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

Hi Alan,

> There are other possible "fixes", for example modifying these functions
> so that they don't use self-insert-command at all, but somehow I don't
> think that's what you want.

I don't think that the code that is implemented against the contract listed
in
the hook documentation should be rewritten. If electric stuff is so that
important and there is no way to disable it by default then at least a
function
to unbind the electric functionality the documentation of
post-self-insert-hook
should state: "Don't rely on this hook in cc derived modes because of
{implementation details}. If you still want to use post-self-insert-hook
disable
use {implementation details} to turn electric off."

Thanks,
Ivan


On Sat, Nov 30, 2019 at 4:36 PM Alan Mackenzie <acm@muc.de> wrote:

> Hello, Yyoncho.
>
> On Wed, Nov 27, 2019 at 22:00:26 +0200, yyoncho wrote:
> > As per post-self-insert-hook documentation.
>
> > > Hook run at the end of `self-insert-command'.
> > > This is run after inserting the character.
>
> Yes.  This is a problematic hook, since it is capable of disrupting the
> correct functionality of any Lisp program which uses
> self-insert-command.  This transpired in CC Mode, so to make
> c-electric-brace and friends work, the action of the hook was nullified.
>
> > This does not hold by default in cc-mode due to the following mapped by
> > default functions:
>
> > > (define-key c-mode-base-map "#"         'c-electric-pound)
> > > (define-key c-mode-base-map "{"         'c-electric-brace)
> > > (define-key c-mode-base-map "}"         'c-electric-brace)
> > > (define-key c-mode-base-map "/"         'c-electric-slash)
> > > (define-key c-mode-base-map "*"         'c-electric-star)
> > > (define-key c-mode-base-map ";"         'c-electric-semi&comma)
> > > (define-key c-mode-base-map ","         'c-electric-semi&comma)
> > > (define-key c-mode-base-map ":"         'c-electric-colon)
> > > (define-key c-mode-base-map "("         'c-electric-paren)
> > > (define-key c-mode-base-map ")"         'c-electric-paren)
>
> > All of these functions (or at least majority) contain the following
> lines:
>
> > > (let (post-self-insert-hook) ; Disable random functionality.
> > >      (self-insert-command (prefix-numeric-value arg)))
>
> Yes.  This was one way to get self-insert-function to perform its
> correct functionality, namely inserting exactly one copy of a typed key
> (or alternatively N copies when there's a prefix key).
>
> > Possible fixes:
>
> First question, what's the problem?  What do you want to do that the
> above mechanism hinders?
>
> > 1. Do not bind the functions by default.
>
> They are essential to the correct functioning of CC Mode.
>
> > 2. Rewrite them so they do not inhibit post-self-insert-hook functions.
>
> This is difficult.  If there were an easy way to do this, I would have
> done it.  Note that, from the point of view of a major mode,
> post-self-insert-hook is totally random functionality - it is a bit like
> a trojan horse.  The major mode has no way to control what it does, thus
> is unable to guarantee the major mode will work.
>
> There are other possible "fixes", for example modifying these functions
> so that they don't use self-insert-command at all, but somehow I don't
> think that's what you want.
>
> Another fix would be to specify restrictions on what one is allowed to
> do in this hook.  I would prefer this, but other people would object
> strongly.
>
> I would advise against using post-self-insert-hook, if you possibly can.
> after-change-functions may be a good alternative.  Maybe you can't.  So,
> again, what is it you're trying to do?
>
> > In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
> >  of 2019-11-23 built on kyoncho-H87-D3H
> > Repository revision: 8934762bb37273e6606097de92dcc2556456acd2
> > Repository branch: master
> > Windowing system distributor 'The X.Org Foundation', version
> 11.0.12001000
> > System Description: Linux Mint 19.1
>
> [ .... ]
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

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

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Ivan.

On Sun, Dec 01, 2019 at 12:02:56 +0200, yyoncho wrote:
> Hi Alan,

> > There are other possible "fixes", for example modifying these functions
> > so that they don't use self-insert-command at all, but somehow I don't
> > think that's what you want.

> I don't think that the code that is implemented against the contract listed
> in the hook documentation should be rewritten. If electric stuff is so
> that important and there is no way to disable it by default then at
> least a function to unbind the electric functionality the
> documentation of post-self-insert-hook should state: "Don't rely on
> this hook in cc derived modes because of {implementation details}. If
> you still want to use post-self-insert-hook disable use
> {implementation details} to turn electric off."

The problem you have stumbled over is more of a political problem than a
technical one.

post-self-insert-hook was introduced relatively recently as a quick and
dirty method of doing certain things.  Its implications weren't thought
through beforehand.  In particular, it breaks major modes which use
self-insert-command as part of their processing, including CC Mode.

If functions put onto post-self-insert-hook didn't violate the
definition of self-insert-command (inserting exactly one copy of the key
typed), there wouldn't be a problem.  An example of such a function is
blink-paren-post-self-insert-function (see lisp/simple.el L7801).

However, there are several functions put onto this hook that make
extensive buffer changes.  An example is
electric-pair-post-self-insert-function (in lisp/elec-pair.el).  These
mess up self-insert-command, and violate the principle that major modes
should be in charge of what text goes where in a window.

People like using post-self-insert-hook without worrying about the
problems it causes.  Binding post-self-insert-hook to nil in CC Mode,
while not good, was a pragmatic workaround from around a year ago.  This
allowed electric-pair-mode to function in CC Mode.  As I said, this
problem is primarily a political problem.  Forgive me not wanting to
draw too much attention to it at the moment.

Again, how does this binding of post-self-insert-hook to nil in CC Mode
affect you?  What is it you're trying to do that this binding makes
difficult?

> Thanks,
> Ivan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[yyoncho]

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

Hi Alan

> Again, how does this binding of post-self-insert-hook to nil in CC Mode
> affect you?  What is it you're trying to do that this binding makes
> difficult?

ATM this change breaks at least 2 packages - lsp-mode and smartparents. I
am the maintainer of lsp-mode and it uses the hook for 2 things:

1. There are keys that are triggering displaying function signature.
2. There are keys that are triggering onTypeFormatting which happens
asynchronously.

I am not aware of how exactly smartparens uses post-insert-hook.

Thanks,
Ivan

On Sun, Dec 1, 2019 at 5:07 PM Alan Mackenzie <acm@muc.de> wrote:

> Hello, Ivan.
>
> On Sun, Dec 01, 2019 at 12:02:56 +0200, yyoncho wrote:
> > Hi Alan,
>
> > > There are other possible "fixes", for example modifying these functions
> > > so that they don't use self-insert-command at all, but somehow I don't
> > > think that's what you want.
>
> > I don't think that the code that is implemented against the contract
> listed
> > in the hook documentation should be rewritten. If electric stuff is so
> > that important and there is no way to disable it by default then at
> > least a function to unbind the electric functionality the
> > documentation of post-self-insert-hook should state: "Don't rely on
> > this hook in cc derived modes because of {implementation details}. If
> > you still want to use post-self-insert-hook disable use
> > {implementation details} to turn electric off."
>
> The problem you have stumbled over is more of a political problem than a
> technical one.
>
> post-self-insert-hook was introduced relatively recently as a quick and
> dirty method of doing certain things.  Its implications weren't thought
> through beforehand.  In particular, it breaks major modes which use
> self-insert-command as part of their processing, including CC Mode.
>
> If functions put onto post-self-insert-hook didn't violate the
> definition of self-insert-command (inserting exactly one copy of the key
> typed), there wouldn't be a problem.  An example of such a function is
> blink-paren-post-self-insert-function (see lisp/simple.el L7801).
>
> However, there are several functions put onto this hook that make
> extensive buffer changes.  An example is
> electric-pair-post-self-insert-function (in lisp/elec-pair.el).  These
> mess up self-insert-command, and violate the principle that major modes
> should be in charge of what text goes where in a window.
>
> People like using post-self-insert-hook without worrying about the
> problems it causes.  Binding post-self-insert-hook to nil in CC Mode,
> while not good, was a pragmatic workaround from around a year ago.  This
> allowed electric-pair-mode to function in CC Mode.  As I said, this
> problem is primarily a political problem.  Forgive me not wanting to
> draw too much attention to it at the moment.
>
> Again, how does this binding of post-self-insert-hook to nil in CC Mode
> affect you?  What is it you're trying to do that this binding makes
> difficult?
>
> > Thanks,
> > Ivan
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

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

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Ivan.

On Sun, Dec 01, 2019 at 17:27:33 +0200, yyoncho wrote:
> Hi Alan

> I am not aware of how exactly smartparens uses post-insert-hook.

In the simplest case, when you type, e.g. "{", it inserts "{}".  In other
cases, when you type "}" onto the existing Rbrace in "{}" it erases one
of the Rbraces.

The problem with this for CC Mode (in c-electric-brace, for example) is
that all these extra and removed characters play havoc with CC Mode's
insertion of auto-newlines and its execution of "clean ups" (e.g.
compacting "}\n    else {"  to  "} else {").

> > Again, how does this binding of post-self-insert-hook to nil in CC
> > Mode affect you?  What is it you're trying to do that this binding
> > makes difficult?

> ATM this change breaks at least 2 packages - lsp-mode and smartparents. I
> am the maintainer of lsp-mode and it uses the hook for 2 things:

> 1. There are keys that are triggering displaying function signature.
> 2. There are keys that are triggering onTypeFormatting which happens
> asynchronously.

Ok, thanks for telling me!

Why are you using post-self-insert-hook for these?  This hook can run in
the middle of a major mode's command, but surely you want them to run
_after_ that command, no?  Why not use post-command-hook here instead?

> Thanks,
> Ivan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Sun, 1 Dec 2019 15:07:38 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: 38406@debbugs.gnu.org
> 
> > > There are other possible "fixes", for example modifying these functions
> > > so that they don't use self-insert-command at all, but somehow I don't
> > > think that's what you want.
> 
> > I don't think that the code that is implemented against the contract listed
> > in the hook documentation should be rewritten. If electric stuff is so
> > that important and there is no way to disable it by default then at
> > least a function to unbind the electric functionality the
> > documentation of post-self-insert-hook should state: "Don't rely on
> > this hook in cc derived modes because of {implementation details}. If
> > you still want to use post-self-insert-hook disable use
> > {implementation details} to turn electric off."
> 
> The problem you have stumbled over is more of a political problem than a
> technical one.

Can we please make it technical again?  Why can't the CC Mode function
which temporarily disables post-self-insert-hook call the hook
functions after it does its thing?  (I think I already asked this in
the past, but I cannot find that question of any discussion of it.)

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Sun, 1 Dec 2019 15:58:42 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: 38406@debbugs.gnu.org
> 
> Why not use post-command-hook here instead?

I don't know what's Ivan's reason, but I know mine: post-command-hook
runs much more frequently (since self-insert-command's are a small
subset of commands in general), and therefore its use is much more
likely to make Emacs less responsive.  E.g., cursor motion commands
will not call post-self-insert-hook.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Sun, Dec 01, 2019 at 19:59:54 +0200, Eli Zaretskii wrote:
> > Date: Sun, 1 Dec 2019 15:07:38 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: 38406@debbugs.gnu.org

> > > > There are other possible "fixes", for example modifying these
> > > > functions so that they don't use self-insert-command at all, but
> > > > somehow I don't think that's what you want.

> > > I don't think that the code that is implemented against the
> > > contract listed in the hook documentation should be rewritten. If
> > > electric stuff is so that important and there is no way to disable
> > > it by default then at least a function to unbind the electric
> > > functionality the documentation of post-self-insert-hook should
> > > state: "Don't rely on this hook in cc derived modes because of
> > > {implementation details}. If you still want to use
> > > post-self-insert-hook disable use {implementation details} to turn
> > > electric off."

> > The problem you have stumbled over is more of a political problem
> > than a technical one.

> Can we please make it technical again?  Why can't the CC Mode function
> which temporarily disables post-self-insert-hook call the hook
> functions after it does its thing?  (I think I already asked this in
> the past, but I cannot find that question or any discussion of it.)

See bug #33794 (but a lot of the discussion is unedifying).

post-self-insert-hook's functions, unusually amongs hooks, interfere with
its triggering event.  This contrasts with, say, after-change-functions,
where the functions don't insert into or delete from the buffer, or
pre-redisplay-functions, where the functions don't try to prevent a
particular window getting displayed.  But post-s-i-h customarily makes
its own buffer changes such that self-insert-command no longer performs
its prime function, which is to insert exactly one copy (or N copies) of
the typed key into the buffer.  This makes it problematic for Lisp code
which calls self-insert-command.

It would be nice if functions on post-self-insert-hook could be split
into "disruptive" ones and "safe" ones, so that a function such as
c-electric-brace could elect to run just the "safe" ones.  I think Ivan's
functions would likely be classed as "safe".  How about this idea for
Emacs 28?

Anyhow back to your question: c-electric-brace carefully calls
electric-pair-post-self-insert-function testing various states afterwards
(such as the buffer reducing in size) so as to be able to complete
c-electric-brace's own processing.  Just calling post-self-insert-hook
instead could easily upset this balance.  Unfortunately this hook can
contain arbitrary code, and frequently does.

So to call this hook at the end of c-electric-brace would mean having to
filter the hook first (at the very least, to remove
electric-pair-post-self-insert-function), which just seems very hackish
and unsatisfactory.

As a statistic, there are approximately 111 occurrences of
(self-insert-command ...) in the Emacs Lisp sources.  Any of them might
be vulnerable to disruption by post-self-insert-hook.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Sun, 1 Dec 2019 19:27:09 +0000
> Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> post-self-insert-hook's functions, unusually amongs hooks, interfere with
> its triggering event.  This contrasts with, say, after-change-functions,
> where the functions don't insert into or delete from the buffer, or
> pre-redisplay-functions, where the functions don't try to prevent a
> particular window getting displayed.

You'd be surprised to know what some of those hooks do.  Everything
you say they don't, and then some.  There's nothing we can do to
prevent people from shooting themselves in the foot or hanging
themselves with the rope we provided.  And if you think you are the
only one who needs to harden your code to let people do the craziest
things with these hooks, please don't think so: you are definitely
not alone.

But breaking a hook's contract as a means to teach people not to shoot
themselves in the foot is not right.  If the uses are legitimate, they
should be able to do them; if they aren't, let them cope with the
consequences.

> So to call this hook at the end of c-electric-brace would mean having to
> filter the hook first (at the very least, to remove
> electric-pair-post-self-insert-function), which just seems very hackish
> and unsatisfactory.

It doesn't seem too hackish to me, and as a nice bonus we will have
post-self-insert-hook act as per its contract again.

So could you please do that?  TIA.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Sun, Dec 01, 2019 at 22:47:01 +0200, Eli Zaretskii wrote:
> > Date: Sun, 1 Dec 2019 19:27:09 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > post-self-insert-hook's functions, unusually amongs hooks, interfere
> > with its triggering event.  This contrasts with, say,
> > after-change-functions, where the functions don't insert into or
> > delete from the buffer, or pre-redisplay-functions, where the
> > functions don't try to prevent a particular window getting
> > displayed.

> You'd be surprised to know what some of those hooks do.  Everything
> you say they don't, and then some.

Any chance you could name one (or even two), thus letting me see for
myself?

> There's nothing we can do to prevent people from shooting themselves
> in the foot or hanging themselves with the rope we provided.

In the case of post-self-insert-hook, the damaging functions are part of
Emacs itself, not crazy user-written code.

> And if you think you are the only one who needs to harden your code to
> let people do the craziest things with these hooks, please don't think
> so: you are definitely not alone.

OK.

> But breaking a hook's contract as a means to teach people not to shoot
> themselves in the foot is not right.  If the uses are legitimate, they
> should be able to do them; if they aren't, let them cope with the
> consequences.

> > So to call this hook at the end of c-electric-brace would mean having to
> > filter the hook first (at the very least, to remove
> > electric-pair-post-self-insert-function), which just seems very hackish
> > and unsatisfactory.

> It doesn't seem too hackish to me, and as a nice bonus we will have
> post-self-insert-hook act as per its contract again.

> So could you please do that?  TIA.

OK, I'll do that.  It's not a nice thing to do, but we're kind of
lacking nice things in this situation.  Give me a few days, please - I'm
a touch busy in RL at the moment.

Additionally, how about reversing the encouragement in the Elisp manual
to put buffer changing functions onto post-self-insert-hook?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Sun, Dec 01, 2019 at 20:03:38 +0200, Eli Zaretskii wrote:
> > Date: Sun, 1 Dec 2019 15:58:42 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: 38406@debbugs.gnu.org

> > Why not use post-command-hook here instead?

> I don't know what's Ivan's reason, but I know mine: post-command-hook
> runs much more frequently (since self-insert-command's are a small
> subset of commands in general), and therefore its use is much more
> likely to make Emacs less responsive.  E.g., cursor motion commands
> will not call post-self-insert-hook.

What we could do with here is a post-change-command-functions, something
a bit like after-change-functions in what triggers it, and a bit like
post-command-hook in when it gets triggered.

Of course, one could say that we have too many hooks already .....

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Mon, 2 Dec 2019 18:31:56 +0000
> Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > You'd be surprised to know what some of those hooks do.  Everything
> > you say they don't, and then some.
> 
> Any chance you could name one (or even two), thus letting me see for
> myself?

I'd have to dig for them.  I'll try.

> > It doesn't seem too hackish to me, and as a nice bonus we will have
> > post-self-insert-hook act as per its contract again.
> 
> > So could you please do that?  TIA.
> 
> OK, I'll do that.  It's not a nice thing to do, but we're kind of
> lacking nice things in this situation.  Give me a few days, please - I'm
> a touch busy in RL at the moment.

Thanks, there's no special rush.

> Additionally, how about reversing the encouragement in the Elisp manual
> to put buffer changing functions onto post-self-insert-hook?

If you could suggest the text to explain why this should be
discouraged, I promise to consider it.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli and Ivan.

On Sun, Dec 01, 2019 at 22:47:01 +0200, Eli Zaretskii wrote:
> > Date: Sun, 1 Dec 2019 19:27:09 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> But breaking a hook's contract as a means to teach people not to shoot
> themselves in the foot is not right.  If the uses are legitimate, they
> should be able to do them; if they aren't, let them cope with the
> consequences.

> > So to call this hook at the end of c-electric-brace would mean
> > having to filter the hook first (at the very least, to remove
> > electric-pair-post-self-insert-function), which just seems very
> > hackish and unsatisfactory.

> It doesn't seem too hackish to me, and as a nice bonus we will have
> post-self-insert-hook act as per its contract again.

> So could you please do that?  TIA.

OK, here's a patch which I think does just what's wanted.  Would you
please try it out, Ivan, then let me know that it works, or about any
problems which there still may be?  Thanks.

It's merely necessary to apply the patch below, byte compile cc-cmds.el,
and load it.  (In the highly unlikely event you want any help with the
patch or the compilation, feel free to send me private email.)  The
patch should apply cleanly to the Emacs master branch.



diff -r d20020192bd6 cc-cmds.el
--- a/cc-cmds.el	Sat Nov 30 21:10:11 2019 +0000
+++ b/cc-cmds.el	Wed Dec 04 20:15:11 2019 +0000
@@ -493,6 +493,34 @@
       (c-hungry-delete-forward)
     (c-hungry-delete-backwards)))
 
+(defvar c--unsafe-post-self-insert-hook-functions
+  '(smie-blink-matching-open
+    electric-pair-post-self-insert-function
+    blink-paren-post-self-insert-function
+    electric-indent-post-self-insert-function
+    electric-layout-post-self-insert-function
+    electric-quote-post-self-insert-function)
+    "Known unsafe functions when members of `post-self-insert-hook' in CC Mode")
+
+(defun c--call-post-self-insert-hook-more-safely ()
+  ;; Call post-self-insert-hook, having removed from `post-self-insert-hook'
+  ;; function known not to be safe to CC Mode.  The result is of no
+  ;; significance.  Note that the hook call is NOT absolutely safe.
+  (let ((src post-self-insert-hook)
+	dest)
+    (while src
+      (cond
+       ((memq (car src) c--unsafe-post-self-insert-hook-functions))
+       ((eq (car src) t)
+	(let ((src (default-value 'post-self-insert-hook)))
+	  (while src
+	    (unless (memq (car src) c--unsafe-post-self-insert-hook-functions)
+	      (add-hook dest (car src) t)) ; Preserve the order of the functions.
+	    (setq src (cdr src)))))
+       (t (add-hook dest (car src) t)))	; Preserve the order of the functions.
+      (setq src (cdr src)))
+    (run-hooks dest)))
+
 (defun c-electric-pound (arg)
   "Insert a \"#\".
 If `c-electric-flag' is set, handle it specially according to the variable
@@ -522,7 +550,8 @@
       (insert (c-last-command-char))
       (and (not bolp)
 	   (goto-char (- (point-max) pos)))
-      )))
+      ))
+  (c--call-post-self-insert-hook-more-safely))
 
 (defun c-point-syntax ()
   ;; Return the syntactic context of the construct at point.  (This is NOT
@@ -903,7 +932,8 @@
 	 (save-excursion
 	   (c-save-buffer-state nil
 	     (c-backward-syntactic-ws safepos))
-	   (funcall old-blink-paren)))))
+	   (funcall old-blink-paren)))
+    (c--call-post-self-insert-hook-more-safely)))
 
 (defun c-electric-slash (arg)
   "Insert a slash character.
@@ -955,7 +985,8 @@
     (let (post-self-insert-hook)	; Disable random functionality.
       (self-insert-command (prefix-numeric-value arg)))
     (if indentp
-	(indent-according-to-mode))))
+	(indent-according-to-mode))
+    (c--call-post-self-insert-hook-more-safely)))
 
 (defun c-electric-star (arg)
   "Insert a star character.
@@ -985,7 +1016,8 @@
 	       (bolp))))
       (let (c-echo-syntactic-information-p) ; shut this up
 	(indent-according-to-mode))
-    ))
+    )
+  (c--call-post-self-insert-hook-more-safely))
 
 (defun c-electric-semi&comma (arg)
   "Insert a comma or semicolon.
@@ -1057,8 +1089,8 @@
 		(setq add-newline-p (not (eq answer 'stop)))
 		))
 	    (if add-newline-p
-		(c-newline-and-indent))
-	    )))))
+		(c-newline-and-indent)))))
+    (c--call-post-self-insert-hook-more-safely)))
 
 (defun c-electric-colon (arg)
   "Insert a colon.
@@ -1160,8 +1192,8 @@
 	  ;; does a newline go after the colon?
 	  (if (and (memq 'after (cdr-safe newlines))
 		   (not is-scope-op))
-	      (c-newline-and-indent))
-	  ))))
+	      (c-newline-and-indent))))
+    (c--call-post-self-insert-hook-more-safely)))
 
 (defun c-electric-lt-gt (arg)
   "Insert a \"<\" or \">\" character.
@@ -1251,7 +1283,8 @@
 	;; From now (2016-01-01), the syntax-table text properties on < and >
 	;; are applied in an after-change function, not during redisplay.  Hence
 	;; we no longer need to call (sit-for 0) for blink paren to work.
-	(funcall blink-paren-function)))))
+	(funcall blink-paren-function))))
+  (c--call-post-self-insert-hook-more-safely))
 
 (defun c-electric-paren (arg)
   "Insert a parenthesis.
@@ -1370,7 +1403,8 @@
       ;; Apply `electric-pair-mode' stuff inside a string or comment.
       (when (and (boundp 'electric-pair-mode) electric-pair-mode)
 	(let (post-self-insert-hook)
-	  (electric-pair-post-self-insert-function))))))
+	  (electric-pair-post-self-insert-function))))
+    (c--call-post-self-insert-hook-more-safely)))
 
 (defun c-electric-continued-statement ()
   "Reindent the current line if appropriate.


-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Dmitry Gutov]

On 04.12.2019 22:41, Alan Mackenzie wrote:
> +(defvar c--unsafe-post-self-insert-hook-functions
> +  '(smie-blink-matching-open
> +    electric-pair-post-self-insert-function
> +    blink-paren-post-self-insert-function
> +    electric-indent-post-self-insert-function
> +    electric-layout-post-self-insert-function
> +    electric-quote-post-self-insert-function)
> +    "Known unsafe functions when members of `post-self-insert-hook' in CC Mode")

I don't see how filtering out a bunch of popular consumers of 
post-self-insert-hook can make it "act as per its contract again".

More surprisingly, what did smie-blink-matching-open and 
blink-paren-post-self-insert-function ever do so wrong? Neither of them 
modifies the buffer's contents.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Wed, 4 Dec 2019 20:41:59 +0000
> Cc: 38406@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> OK, here's a patch which I think does just what's wanted.  Would you
> please try it out, Ivan, then let me know that it works, or about any
> problems which there still may be?  Thanks.

Thanks.

> +(defvar c--unsafe-post-self-insert-hook-functions
> +  '(smie-blink-matching-open
> +    electric-pair-post-self-insert-function
> +    blink-paren-post-self-insert-function
> +    electric-indent-post-self-insert-function
> +    electric-layout-post-self-insert-function
> +    electric-quote-post-self-insert-function)
> +    "Known unsafe functions when members of `post-self-insert-hook' in CC Mode")

Can you explain why you exempt these from being called from CC Mode?
AFAIU, by disabling them when CC Mode reacts to insertion, you have
solved the conflict between any such hook and CC Mode, so why not call
any such hook afterwards?

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Thu, Dec 05, 2019 at 16:45:12 +0200, Eli Zaretskii wrote:
> > Date: Wed, 4 Dec 2019 20:41:59 +0000
> > Cc: 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > OK, here's a patch which I think does just what's wanted.  Would you
> > please try it out, Ivan, then let me know that it works, or about any
> > problems which there still may be?  Thanks.

> Thanks.

Actually, I forgot about testing for the existence of
post-self-insert-hook.  So the following will go in, too, with the
obvious definition for ....-1:

(defmacro c--call-post-self-insert-hook-more-safely ()
  ;; Call post-self-insert-hook, if such exists.  See comment for
  ;; `c--call-post-self-insert-hook-more-safely-1'.
  (if (boundp 'post-self-insert-hook)
      '(c--call-post-self-insert-hook-more-safely-1)
    '(progn)))

> > +(defvar c--unsafe-post-self-insert-hook-functions
> > +  '(smie-blink-matching-open
> > +    electric-pair-post-self-insert-function
> > +    blink-paren-post-self-insert-function
> > +    electric-indent-post-self-insert-function
> > +    electric-layout-post-self-insert-function
> > +    electric-quote-post-self-insert-function)
> > +    "Known unsafe functions when members of `post-self-insert-hook' in CC Mode")

> Can you explain why you exempt these from being called from CC Mode?

There is already a call to the matching-paren blink functionality in
cc-cmds.el, which must stay for older Emacsen.  If blink-paren-p-s-i-f
was allowed to run too, the result would probably be a doubling of the
blink time.  This is not desirable.  The same applies to smie-blink-m-o,
which in any case will not be used for CC Mode.

electric-pair-post-self-insert-function must not run in
c-electric-brace/paren except as carefully coded in these functions
explicitly; it would otherwise foul things up, one way or another, as it
did in the scenario for which bug #33794 was raised.

Of the other three electric-* functions, only one has a complete doc
string, so it is work to work out what the other two do.
electric-indent-post-self-insert-function is redundant in CC Mode, and
probably harmful.  At best it will just take up processor cycles.  I
believe electric-layout-p-s-i-f just duplicates the auto-newline
behaviour of the c-electric-* functions, making it redundant.  I don't
know exactly what electric-quote-p-s-i-f does, but it is likely to be
something to do with quotes, and thus likely to clash with CC Mode's
handling of quotes.

> AFAIU, by disabling them when CC Mode reacts to insertion, you have
> solved the conflict between any such hook and CC Mode, so why not call
> any such hook afterwards?

See above.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Dmitry.

On Wed, Dec 04, 2019 at 23:04:27 +0200, Dmitry Gutov wrote:
> On 04.12.2019 22:41, Alan Mackenzie wrote:
> > +(defvar c--unsafe-post-self-insert-hook-functions
> > +  '(smie-blink-matching-open
> > +    electric-pair-post-self-insert-function
> > +    blink-paren-post-self-insert-function
> > +    electric-indent-post-self-insert-function
> > +    electric-layout-post-self-insert-function
> > +    electric-quote-post-self-insert-function)
> > +    "Known unsafe functions when members of `post-self-insert-hook' in CC Mode")

> I don't see how filtering out a bunch of popular consumers of 
> post-self-insert-hook can make it "act as per its contract again".

Think of it more as "filtering in" all functions on
post-self-insert-hook _except_ the ones mentioned, which are harmful in
CC Mode.

> More surprisingly, what did smie-blink-matching-open and 
> blink-paren-post-self-insert-function ever do so wrong? Neither of them 
> modifies the buffer's contents.

No, but if allowed to run, they would probably double the blink time on
the paren match, which would be a Bad Thing.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Thu, 5 Dec 2019 19:09:51 +0000
> Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Can you explain why you exempt these from being called from CC Mode?
> 
> There is already a call to the matching-paren blink functionality in
> cc-cmds.el, which must stay for older Emacsen.  If blink-paren-p-s-i-f
> was allowed to run too, the result would probably be a doubling of the
> blink time.  This is not desirable.  The same applies to smie-blink-m-o,
> which in any case will not be used for CC Mode.
> 
> electric-pair-post-self-insert-function must not run in
> c-electric-brace/paren except as carefully coded in these functions
> explicitly; it would otherwise foul things up, one way or another, as it
> did in the scenario for which bug #33794 was raised.
> 
> Of the other three electric-* functions, only one has a complete doc
> string, so it is work to work out what the other two do.
> electric-indent-post-self-insert-function is redundant in CC Mode, and
> probably harmful.  At best it will just take up processor cycles.  I
> believe electric-layout-p-s-i-f just duplicates the auto-newline
> behaviour of the c-electric-* functions, making it redundant.  I don't
> know exactly what electric-quote-p-s-i-f does, but it is likely to be
> something to do with quotes, and thus likely to clash with CC Mode's
> handling of quotes.

I don't think CC Mode should protect users of those hooks from
themselves.  If the user or Lisp set up these hooks such that they end
up shooting themselves in the foot, we should let them.  We never
provide any "safety nets" for silly hook functions, so we shouldn't do
that here as well.  OTOH, if someone puts a function on those hooks
which does something legitimate, we should meet their expectations and
let those functions run, as the contract says.

So I think you shouldn't filter anything from the hook before you run
it.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Thu, Dec 05, 2019 at 21:25:14 +0200, Eli Zaretskii wrote:
> > Date: Thu, 5 Dec 2019 19:09:51 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Can you explain why you exempt these from being called from CC Mode?

> > There is already a call to the matching-paren blink functionality in
> > cc-cmds.el, which must stay for older Emacsen.  If blink-paren-p-s-i-f
> > was allowed to run too, the result would probably be a doubling of the
> > blink time.  This is not desirable.  The same applies to smie-blink-m-o,
> > which in any case will not be used for CC Mode.

> > electric-pair-post-self-insert-function must not run in
> > c-electric-brace/paren except as carefully coded in these functions
> > explicitly; it would otherwise foul things up, one way or another, as it
> > did in the scenario for which bug #33794 was raised.

> > Of the other three electric-* functions, only one has a complete doc
> > string, so it is work to work out what the other two do.
> > electric-indent-post-self-insert-function is redundant in CC Mode, and
> > probably harmful.  At best it will just take up processor cycles.  I
> > believe electric-layout-p-s-i-f just duplicates the auto-newline
> > behaviour of the c-electric-* functions, making it redundant.  I don't
> > know exactly what electric-quote-p-s-i-f does, but it is likely to be
> > something to do with quotes, and thus likely to clash with CC Mode's
> > handling of quotes.

> I don't think CC Mode should protect users of those hooks from
> themselves.

It doesn't.  Ivan's hook functions will now get called.

> If the user or Lisp set up these hooks such that they end up shooting
> themselves in the foot, we should let them.

It's not a matter of what users might do.  It's about what Emacs
maintainers have already done.  The current changes to CC Mode are to
protect users of CC Mode from these design clashes inside Emacs.

> We never provide any "safety nets" for silly hook functions, so we
> shouldn't do that here as well.  OTOH, if someone puts a function on
> those hooks which does something legitimate, we should meet their
> expectations and let those functions run, as the contract says.

I think that, with my latest patch, that is the case.

> So I think you shouldn't filter anything from the hook before you run
> it.

I thought you were urging me to do precisely that two or three posts ago.

I just tried taking a particular function off of
c--unsafe-post-self-insert-hook-functions and enabling electric-pair
mode.  On typing a brace, electric-pair-mode threw an obscure error.  It
doesn't make sense to call electric-pair-post-self-insert-function twice
for one keypress.  That is a good reason for having that function
filtered out of the hook.  For the other five filtered out functions, I
gave what I think were good reasons in my last post.

The root of the problem is the hook post-self-insert-hook.  It is a
thoroughly bad idea.  The implications of introducing it a few years ago
weren't thought through.  Assuming that removing this hook from Emacs
isn't an option, we are left with ugly ad-hoc workarounds, such as the
patch we're currently discussing.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Dmitry Gutov]

On 05.12.2019 21:14, Alan Mackenzie wrote:

> On Wed, Dec 04, 2019 at 23:04:27 +0200, Dmitry Gutov wrote:
>> On 04.12.2019 22:41, Alan Mackenzie wrote:
>>> +(defvar c--unsafe-post-self-insert-hook-functions
>>> +  '(smie-blink-matching-open
>>> +    electric-pair-post-self-insert-function
>>> +    blink-paren-post-self-insert-function
>>> +    electric-indent-post-self-insert-function
>>> +    electric-layout-post-self-insert-function
>>> +    electric-quote-post-self-insert-function)
>>> +    "Known unsafe functions when members of `post-self-insert-hook' in CC Mode")
> 
>> I don't see how filtering out a bunch of popular consumers of
>> post-self-insert-hook can make it "act as per its contract again".
> 
> Think of it more as "filtering in" all functions on
> post-self-insert-hook _except_ the ones mentioned, which are harmful in
> CC Mode.

blink-paren is harmful for CC Mode? Or is it reimplemented, like other 
features (e.g. electric-*), inside CC Mode?

In the latter case, I think CC Mode should just disable the respective 
minor modes/variables locally and call it a day (the hook won't be used 
them, so no need for filtering).

Of course, ideally users of recent enough Emacs would be able to disable 
these built-in features and switch on the generic ones instead.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Thu, 5 Dec 2019 20:17:13 +0000
> Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > We never provide any "safety nets" for silly hook functions, so we
> > shouldn't do that here as well.  OTOH, if someone puts a function on
> > those hooks which does something legitimate, we should meet their
> > expectations and let those functions run, as the contract says.
> 
> I think that, with my latest patch, that is the case.
> 
> > So I think you shouldn't filter anything from the hook before you run
> > it.
> 
> I thought you were urging me to do precisely that two or three posts ago.
> 
> I just tried taking a particular function off of
> c--unsafe-post-self-insert-hook-functions and enabling electric-pair
> mode.  On typing a brace, electric-pair-mode threw an obscure error.  It
> doesn't make sense to call electric-pair-post-self-insert-function twice
> for one keypress.  That is a good reason for having that function
> filtered out of the hook.

There might be a misunderstanding on my part here.  Could you please
explain how come electric-pair-post-self-insert-function is called
twice if it isn't removed from the hook? where's the second (or the
first) call?

> The root of the problem is the hook post-self-insert-hook.  It is a
> thoroughly bad idea.  The implications of introducing it a few years ago
> weren't thought through.

That might be so, but I think it's too late for removing it now.

> Assuming that removing this hook from Emacs isn't an option, we are
> left with ugly ad-hoc workarounds, such as the patch we're currently
> discussing.

Yes.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Fri, Dec 06, 2019 at 10:06:31 +0200, Eli Zaretskii wrote:
> > Date: Thu, 5 Dec 2019 20:17:13 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > We never provide any "safety nets" for silly hook functions, so we
> > > shouldn't do that here as well.  OTOH, if someone puts a function
> > > on those hooks which does something legitimate, we should meet
> > > their expectations and let those functions run, as the contract
> > > says.

> > I think that, with my latest patch, that is the case.

> > > So I think you shouldn't filter anything from the hook before you
> > > run it.

> > I thought you were urging me to do precisely that two or three posts
> > ago.

> > I just tried taking a particular function off of
> > c--unsafe-post-self-insert-hook-functions and enabling electric-pair
> > mode.  On typing a brace, electric-pair-mode threw an obscure error.
> > It doesn't make sense to call electric-pair-post-self-insert-function
> > twice for one keypress.  That is a good reason for having that
> > function filtered out of the hook.

> There might be a misunderstanding on my part here.  Could you please
> explain how come electric-pair-post-self-insert-function is called
> twice if it isn't removed from the hook? where's the second (or the
> first) call?

The first call is an explicit call from c-electric-brace to
electric-pair-post-self-insert-function.  Depending on the changes to the
buffer this call causes (amongst other things), differing electric
actions are performed by c-electric-brace.  This call is itself a
workaround, there being no purpose designed function for this purpose in
elec-pair.el.

The second call happens when c-electric-brace run-hook's
post-self-insert-hook - _if_ electric-pair-post-self-insert-function
hasn't been filtered out of that hook.

> > The root of the problem is the hook post-self-insert-hook.  It is a
> > thoroughly bad idea.  The implications of introducing it a few years ago
> > weren't thought through.

> That might be so, but I think it's too late for removing it now.

> > Assuming that removing this hook from Emacs isn't an option, we are
> > left with ugly ad-hoc workarounds, such as the patch we're currently
> > discussing.

> Yes.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Fri, 6 Dec 2019 18:28:42 +0000
> Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > There might be a misunderstanding on my part here.  Could you please
> > explain how come electric-pair-post-self-insert-function is called
> > twice if it isn't removed from the hook? where's the second (or the
> > first) call?
> 
> The first call is an explicit call from c-electric-brace to
> electric-pair-post-self-insert-function.  Depending on the changes to the
> buffer this call causes (amongst other things), differing electric
> actions are performed by c-electric-brace.  This call is itself a
> workaround, there being no purpose designed function for this purpose in
> elec-pair.el.
> 
> The second call happens when c-electric-brace run-hook's
> post-self-insert-hook - _if_ electric-pair-post-self-insert-function
> hasn't been filtered out of that hook.

If you already call that particular function explicitly, then calling
it one more time is indeed redundant.

But is this the case with all the other functions that you suggest to
filter from post-self-insert-hook?

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Fri, Dec 06, 2019 at 20:48:26 +0200, Eli Zaretskii wrote:
> > Date: Fri, 6 Dec 2019 18:28:42 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > There might be a misunderstanding on my part here.  Could you please
> > > explain how come electric-pair-post-self-insert-function is called
> > > twice if it isn't removed from the hook? where's the second (or the
> > > first) call?

> > The first call is an explicit call from c-electric-brace to
> > electric-pair-post-self-insert-function.  Depending on the changes to the
> > buffer this call causes (amongst other things), differing electric
> > actions are performed by c-electric-brace.  This call is itself a
> > workaround, there being no purpose designed function for this purpose in
> > elec-pair.el.

> > The second call happens when c-electric-brace run-hook's
> > post-self-insert-hook - _if_ electric-pair-post-self-insert-function
> > hasn't been filtered out of that hook.

> If you already call that particular function explicitly, then calling
> it one more time is indeed redundant.

No, it's not redundant.  It's positively harmful.

> But is this the case with all the other functions that you suggest to
> filter from post-self-insert-hook?

No.  They have individual reasons for being filtered out.  Don't forget
that this is a particularly sensitive hook, allowing hook functions to
interfere in an unsynchronised way with partially complete command
processing.

Let's go through them again:

  smie-blink-matching-open is inapplicable to CC Mode and just takes up
  processor cycles.

  electric-pair-post-self-insert-function we've already discussed.

  blink-paren-post-self-insert-function would do nothing anyhow, since
  blink-paren-function has been bound to nil - this is so that the actual
  blinking doesn't occur until the newly inserted brace is at its final
  position.

  electric-indent-post-self-insert-function is redundant and possibly
  harmful.

  electric-layout-post-self-insert-function is undocumented, thus likely
  to be harmful.  Its name suggests it is redundant.

  electric-quote-post-self-insert-function is undocumented, uncommented
  and obscure.  It is safer not to risk running it.

Given that the mechanism for filtering post-self-insert-hook is there,
why is there the resistance to filtering out redundant and effect-free
functions?

And how come functions without meaningful doc strings are allowed onto
Emacs hooks?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Fri, 6 Dec 2019 22:24:59 +0000
> Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > If you already call that particular function explicitly, then calling
> > it one more time is indeed redundant.
> 
> No, it's not redundant.  It's positively harmful.

Agreed.

>   smie-blink-matching-open is inapplicable to CC Mode and just takes up
>   processor cycles.
> 
>   electric-pair-post-self-insert-function we've already discussed.
> 
>   blink-paren-post-self-insert-function would do nothing anyhow, since
>   blink-paren-function has been bound to nil - this is so that the actual
>   blinking doesn't occur until the newly inserted brace is at its final
>   position.
> 
>   electric-indent-post-self-insert-function is redundant and possibly
>   harmful.
> 
>   electric-layout-post-self-insert-function is undocumented, thus likely
>   to be harmful.  Its name suggests it is redundant.
> 
>   electric-quote-post-self-insert-function is undocumented, uncommented
>   and obscure.  It is safer not to risk running it.
> 
> Given that the mechanism for filtering post-self-insert-hook is there,
> why is there the resistance to filtering out redundant and effect-free
> functions?

Alan, I'm trying to do TRT here, but I cannot do everything by myself,
because that would mean I need to invest an inordinate amount of time
in each decision, and will never be able to catch up.  Please help me
with this particular task by providing more detailed information about
your reasons for filtering out each of the functions you want to
filter out.  You have evidently studied them, so you should know more
about them then shown above, and certainly more than I do.

In general, I'd like to leave any function that is not harmful in the
list unfiltered, even if calling it in this context is silly, or has
no effect, or is otherwise redundant.  Can you please humor me by
looking at the above list through these eyes, and trying to avoid your
apparent dislike for the whole idea while at that?  I really need your
help.

Specifically, I'd like the following questions answered, at the very
least:

 . why is smie-blink-matching-open inapplicable?
 . where and why is blink-paren-function bound to nil?  Your patch
   calls blink-paren-function explicitly -- does that mean calling
   blink-paren-post-self-insert-function will be redundant?
 . why do you think electric-indent-post-self-insert-function could be
   harmful?  If it's merely redundant, could we please call it here?
 . electric-layout-post-self-insert-function inserts newlines, and its
   documentation is in electric-layout-rules; the latter is nil by
   default and only used in js.el and octave.el -- why would it be
   harmful here?
 . electric-quote-post-self-insert-function replaces quote characters
   (see the doc string of electric-quote-mode); do you have specific
   reasons why calling it here could be harmful or risky?

> And how come functions without meaningful doc strings are allowed onto
> Emacs hooks?

Please, let's not try fix all of Emacs while working on this single
issue.  I agree that undocumented functions is not a good thing, but,
as shown above, documentation for what these functions do _is_
available nearby.

Thanks.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

On Sat, Dec 07, 2019 at 10:21:40 +0200, Eli Zaretskii wrote:
> > Date: Fri, 6 Dec 2019 22:24:59 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > If you already call that particular function explicitly, then calling
> > > it one more time is indeed redundant.

> > No, it's not redundant.  It's positively harmful.

> Agreed.

> >   smie-blink-matching-open is inapplicable to CC Mode and just takes up
> >   processor cycles.

> >   electric-pair-post-self-insert-function we've already discussed.

> >   blink-paren-post-self-insert-function would do nothing anyhow, since
> >   blink-paren-function has been bound to nil - this is so that the actual
> >   blinking doesn't occur until the newly inserted brace is at its final
> >   position.

> >   electric-indent-post-self-insert-function is redundant and possibly
> >   harmful.

> >   electric-layout-post-self-insert-function is undocumented, thus likely
> >   to be harmful.  Its name suggests it is redundant.

> >   electric-quote-post-self-insert-function is undocumented, uncommented
> >   and obscure.  It is safer not to risk running it.

> > Given that the mechanism for filtering post-self-insert-hook is there,
> > why is there the resistance to filtering out redundant and effect-free
> > functions?

> Alan, I'm trying to do TRT here, but I cannot do everything by myself,
> because that would mean I need to invest an inordinate amount of time
> in each decision, and will never be able to catch up.  Please help me
> with this particular task by providing more detailed information about
> your reasons for filtering out each of the functions you want to
> filter out.  You have evidently studied them, so you should know more
> about them then shown above, and certainly more than I do.

> In general, I'd like to leave any function that is not harmful in the
> list unfiltered, even if calling it in this context is silly, or has
> no effect, or is otherwise redundant.  Can you please humor me by
> looking at the above list through these eyes, and trying to avoid your
> apparent dislike for the whole idea while at that?  I really need your
> help.

OK, sorry for the misunderstanding.  I was reasoning, subconsciously, on
the basis of justifying each function to remain on the hook.  Again,
subconsciously, I assumed you were doing the same.  If I move over to
justifying each function to be filtered out of the hook, things get a lot
easier.

> Specifically, I'd like the following questions answered, at the very
> least:

>  . why is smie-blink-matching-open inapplicable?

The "simple-minded indentation engine" is not used in CC Mode.  But we
can leave it in the hook since it is harmless.

>  . where and why is blink-paren-function bound to nil?  Your patch
>    calls blink-paren-function explicitly -- does that mean calling
>    blink-paren-post-self-insert-function will be redundant?

blink-paren-function is bound to nil at the start of c-electric-brace and
c-electric-paren.  Otherwise, the paren blinking would happen
instantaneously after inserting the } or ), even though auto-newline may
still need to insert a NL before the } or ); this would be jarring for
the user.  c-electric-brace/paren instead call blink-paren-function
explicitly after any adjustments in the buffer have been made.

But leaving blink-paren-post-self-insert-function on the hook, although
it is redundant, will be harmless.

>  . why do you think electric-indent-post-self-insert-function could be
>    harmful?  If it's merely redundant, could we please call it here?
>  . electric-layout-post-self-insert-function inserts newlines, and its
>    documentation is in electric-layout-rules; the latter is nil by
>    default and only used in js.el and octave.el -- why would it be
>    harmful here?

These two functions never have any business in CC Mode, so I wanted to
exclude them from the hook for safety reasons.  If they somehow became
active, they might corrupt CC Mode's indentation or auto-newline mode.
But there is no immediately pressing reason to filter them out of the
hook.

>  . electric-quote-post-self-insert-function replaces quote characters
>    (see the doc string of electric-quote-mode); do you have specific
>    reasons why calling it here could be harmful or risky?

Thanks for the pointer.  This hook alters ASCII quotes to curly quotes,
but does so only in comments and strings.  It might corrupt code if a
user edits the code whilst it is commented out, or (in C++) "stringed
out" by a long raw string (yes, I have seen this happening).

So, I suppose we could say that any user who enables electric-quote-mode
and comments out code should be aware of what she is doing.  Although it
would not happen often, getting a curly quote into commented out code,
then uncommenting it, would be a difficult error to spot, with seemingly
non-sensensical compiler error messages.

But, thinking about it, there is no function `c-electric-quote', so
filtering out electric-quote-p-s-i-f will never have any effect on
anything.  So there is no point in doing so.

So, that would leave just electric-pair-post-self-insert-function to be
filtered out of the hook.

> > And how come functions without meaningful doc strings are allowed onto
> > Emacs hooks?

> Please, let's not try fix all of Emacs while working on this single
> issue.  I agree that undocumented functions is not a good thing, but,
> as shown above, documentation for what these functions do _is_
> available nearby.

OK.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Eli Zaretskii]

> Date: Sat, 7 Dec 2019 11:40:45 +0000
> Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> So, that would leave just electric-pair-post-self-insert-function to be
> filtered out of the hook.

Thank you, I agree.  So please go ahead and push your changes with
those modifications.

bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Sat, Dec 07, 2019 at 15:27:46 +0200, Eli Zaretskii wrote:
> > Date: Sat, 7 Dec 2019 11:40:45 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > So, that would leave just electric-pair-post-self-insert-function to be
> > filtered out of the hook.

> Thank you, I agree.  So please go ahead and push your changes with
> those modifications.

DONE.  I am closing the bug with this post.

-- 
Alan Mackenzie (Nuremberg, Germany).