comparison lisp/complete.el @ 96376:c3309dba6542

American English spelling fix.

96375:4abf11e31c26

    ;; 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
    ;; behaviour) 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

    ;; 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 behaviour 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 behaviour 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)))

96376:c3309dba6542

    ;; 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

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