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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

yyoncho
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))
Reply | Threaded
Open this post in threaded view
|

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).



Reply | Threaded
Open this post in threaded view
|

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

yyoncho
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 <[hidden email]> 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).
Reply | Threaded
Open this post in threaded view
|

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).



Reply | Threaded
Open this post in threaded view
|

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

yyoncho

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 <[hidden email]> 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).
Reply | Threaded
Open this post in threaded view
|

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).



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Alan Mackenzie
> Date: Sun, 1 Dec 2019 15:07:38 +0000
> From: Alan Mackenzie <[hidden email]>
> Cc: [hidden email]
>
> > > 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.)



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Alan Mackenzie
> Date: Sun, 1 Dec 2019 15:58:42 +0000
> From: Alan Mackenzie <[hidden email]>
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Alan Mackenzie
In reply to this post by Eli Zaretskii
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 <[hidden email]>
> > Cc: [hidden email]

> > > > 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).



Reply | Threaded
Open this post in threaded view
|

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: [hidden email], [hidden email]
> From: Alan Mackenzie <[hidden email]>
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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: [hidden email], [hidden email]
> > From: Alan Mackenzie <[hidden email]>

> > 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).



Reply | Threaded
Open this post in threaded view
|

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

Alan Mackenzie
In reply to this post by Eli Zaretskii
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 <[hidden email]>
> > Cc: [hidden email]

> > 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).



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Alan Mackenzie
> Date: Mon, 2 Dec 2019 18:31:56 +0000
> Cc: [hidden email], [hidden email]
> From: Alan Mackenzie <[hidden email]>
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Alan Mackenzie
In reply to this post by Eli Zaretskii
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: [hidden email], [hidden email]
> > From: Alan Mackenzie <[hidden email]>

[ .... ]

> 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).



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Alan Mackenzie
> Date: Wed, 4 Dec 2019 20:41:59 +0000
> Cc: [hidden email]
> From: Alan Mackenzie <[hidden email]>
>
> 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?



Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
> > From: Alan Mackenzie <[hidden email]>

> > 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).



Reply | Threaded
Open this post in threaded view
|

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

Alan Mackenzie
In reply to this post by Dmitry Gutov
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).



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Alan Mackenzie
> Date: Thu, 5 Dec 2019 19:09:51 +0000
> Cc: [hidden email], [hidden email]
> From: Alan Mackenzie <[hidden email]>
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

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: [hidden email], [hidden email]
> > From: Alan Mackenzie <[hidden email]>

> > > 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).



12