Function: PC-lisp-complete-symbol

PC-lisp-complete-symbol is an interactive and byte-compiled function defined in complete.el.gz.

Signature

(PC-lisp-complete-symbol)

Documentation

Perform completion on Lisp symbol preceding point.

That symbol is compared against the symbols that exist and any additional characters determined by what is there are inserted. If the symbol starts just after an open-parenthesis, only symbols with function definitions are considered. Otherwise, all symbols with function definitions, values or properties are considered.

Key Bindings

Source Code

;; Defined in /usr/src/emacs/lisp/obsolete/complete.el.gz
(defun PC-lisp-complete-symbol ()
  "Perform completion on Lisp symbol preceding point.
That symbol is compared against the symbols that exist
and any additional characters determined by what is there
are inserted.
If the symbol starts just after an open-parenthesis,
only symbols with function definitions are considered.
Otherwise, all symbols with function definitions, values
or properties are considered."
  (interactive)
  (let* ((end
          (save-excursion
            (with-syntax-table lisp-mode-syntax-table
              (skip-syntax-forward "_w")
              (point))))
	 (beg (save-excursion
                (with-syntax-table lisp-mode-syntax-table
                  (backward-sexp 1)
                  (while (= (char-syntax (following-char)) ?\')
                    (forward-char 1))
                  (point))))
	 (minibuffer-completion-table obarray)
	 (minibuffer-completion-predicate
	  (if (eq (char-after (1- beg)) ?\()
	      'fboundp
	    (function (lambda (sym)
			(or (boundp sym) (fboundp sym)
			    (symbol-plist sym))))))
	 (PC-not-minibuffer t))
    ;; https://lists.gnu.org/r/emacs-devel/2007-03/msg01211.html
    ;;
    ;; This deals with cases like running PC-l-c-s on "M-: (n-f".
    ;; The first call to PC-l-c-s expands this to "(ne-f", and moves
    ;; point to the hyphen [1]. If one calls PC-l-c-s immediately after,
    ;; then without the last-command check, one is offered all
    ;; completions of "(ne", which is presumably not what one wants.
    ;;
    ;; This is arguably (at least, it seems to be the existing intended
    ;; behavior) what one _does_ want if point has been explicitly
    ;; positioned on the hyphen. Note that if PC-do-completion (qv) binds
    ;; completion-base-size to nil, then completion does not replace the
    ;; correct amount of text in such cases.
    ;;
    ;; Neither of these problems occur when using PC for filenames in the
    ;; minibuffer, because in that case PC-do-completion is called without
    ;; an explicit value for END, and so uses (point-max). This is fine for
    ;; a filename, because the end of the filename must be at the end of
    ;; the minibuffer. The same is not true for lisp symbols.
    ;;
    ;; [1] An alternate fix would be to not move point to the hyphen
    ;; in such cases, but that would make the behavior different from
    ;; that for filenames. It seems PC moves point to the site of the
    ;; first difference between the possible completions.
    ;;
    ;; Alternatively alternatively, maybe end should be computed in
    ;; the same way as beg. That would change the behavior though.
    (if (equal last-command 'PC-lisp-complete-symbol)
        (PC-do-completion nil beg PC-lisp-complete-end t)
      (if PC-lisp-complete-end
          (move-marker PC-lisp-complete-end end)
        (setq PC-lisp-complete-end (copy-marker end t)))
      (PC-do-completion nil beg end t))))