unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Troy Hinckley <t.macman@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org>
Subject: Re: compile.el legacy compatibility
Date: Sat, 06 Apr 2019 18:50:32 -0400	[thread overview]
Message-ID: <jwv7ec63g6w.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CAO_0tjntjTEdzur0LrxEoVApr6rasZuFef6utDAhzuzywLqniQ@mail.gmail.com> (Troy Hinckley's message of "Sat, 6 Apr 2019 07:14:00 -0600")

> I checked out the latest commit, and it looks like there is some more code
> we need to remove to complete this.

AFAICT what you're suggesting removes another backward compatibility
feature, made obsolete around the same time but otherwise independent.
Furthermore, this one is better documented in the code (e.g. with
a make-obsolete-variable), so I think we can remove it when we decide to
drop the other "obsolete since 24.1" features.


        Stefan


> On Wed, Apr 3, 2019 at 9:21 AM Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>> >> > However since we changed to the new style at least 15 years ago, it
>> >> > seems it would be best to drop the old compatibility (which is your
>> >> > first preference as well). Who has the power to make that call?
>> >> That would be Eli,
>> > I have no opinion on this, provided that the incompatible change is
>> > clearly documented in NEWS and in relevant places in compile.el (if
>> > there are such places).
>>
>> Thanks, done.
>>
>>
>>         Stefan
>>
>>
> From fad195eba10ced934d9bae3a81780ff45349fcd1 Mon Sep 17 00:00:00 2001
> From: CeleritasCelery <t.macman@gmail.com>
> Date: Sat, 23 Mar 2019 06:04:57 -0700
> Subject: [PATCH] Remove obselete compile.el code
>
> ---
>  lisp/progmodes/compile.el  | 67 +++++++++++++++++-----------------------------
>  lisp/progmodes/prolog.el   | 15 +----------
>  lisp/textmodes/tex-mode.el |  4 +--
>  3 files changed, 26 insertions(+), 60 deletions(-)
>
> diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
> index 1a0d9bdbb7..cbe36a30f7 100644
> --- a/lisp/progmodes/compile.el
> +++ b/lisp/progmodes/compile.el
> @@ -820,11 +820,6 @@ Faces `compilation-error-face', `compilation-warning-face',
>  (defvar compilation-leave-directory-face 'font-lock-builtin-face
>    "Face name to use for leaving directory messages.")
>  
> -;; Used for compatibility with the old compile.el.
> -(defvar compilation-parse-errors-function nil)
> -(make-obsolete-variable 'compilation-parse-errors-function
> -			'compilation-error-regexp-alist "24.1")
> -
>  (defcustom compilation-auto-jump-to-first-error nil
>    "If non-nil, automatically jump to the first error during compilation."
>    :type 'boolean
> @@ -1081,7 +1076,7 @@ POS and RES.")
>                 (setq file (if (functionp file) (funcall file)
>                              (match-string-no-properties file))))
>  	  (let ((dir
> -	    (unless (file-name-absolute-p file)
> +	         (unless (file-name-absolute-p file)
>                     (let ((pos (compilation--previous-directory
>                                 (match-beginning 0))))
>                       (when pos
> @@ -1310,34 +1305,29 @@ FMTS is a list of format specs for transforming the file name.
>              (and proc (memq (process-status proc) '(run open))))
>        (setq end (line-beginning-position))))
>    (compilation--remove-properties start end)
> -  (if compilation-parse-errors-function
> -      ;; An old package!  Try the compatibility code.
> -      (progn
> -        (goto-char start)
> -        (compilation--compat-parse-errors end))
> -
> -    ;; compilation-directory-matcher is the only part that really needs to be
> -    ;; parsed sequentially.  So we could split it out, handle directories
> -    ;; like syntax-propertize, and the rest as font-lock-keywords.  But since
> -    ;; we want to have it work even when font-lock is off, we'd then need to
> -    ;; use our own compilation-parsed text-property to keep track of the parts
> -    ;; that have already been parsed.
> -    (goto-char start)
> -    (while (re-search-forward (car compilation-directory-matcher)
> -                              end t)
> -      (compilation--flush-directory-cache (match-beginning 0) (match-end 0))
> -      (when compilation-debug
> -        (font-lock-append-text-property
> -         (match-beginning 0) (match-end 0)
> -         'compilation-debug
> -         (vector 'directory compilation-directory-matcher)))
> -      (dolist (elt (cdr compilation-directory-matcher))
> -        (add-text-properties (match-beginning (car elt))
> -                             (match-end (car elt))
> -                             (compilation-directory-properties
> -                              (car elt) (cdr elt)))))
> -
> -    (compilation-parse-errors start end)))
> +
> +  ;; compilation-directory-matcher is the only part that really needs to be
> +  ;; parsed sequentially.  So we could split it out, handle directories
> +  ;; like syntax-propertize, and the rest as font-lock-keywords.  But since
> +  ;; we want to have it work even when font-lock is off, we'd then need to
> +  ;; use our own compilation-parsed text-property to keep track of the parts
> +  ;; that have already been parsed.
> +  (goto-char start)
> +  (while (re-search-forward (car compilation-directory-matcher)
> +                            end t)
> +    (compilation--flush-directory-cache (match-beginning 0) (match-end 0))
> +    (when compilation-debug
> +      (font-lock-append-text-property
> +       (match-beginning 0) (match-end 0)
> +       'compilation-debug
> +       (vector 'directory compilation-directory-matcher)))
> +    (dolist (elt (cdr compilation-directory-matcher))
> +      (add-text-properties (match-beginning (car elt))
> +                           (match-end (car elt))
> +                           (compilation-directory-properties
> +                            (car elt) (cdr elt)))))
> +
> +  (compilation-parse-errors start end))
>  
>  (defun compilation--note-type (type)
>    "Note that a new message with severity TYPE was seen.
> @@ -2878,15 +2868,6 @@ TRUE-DIRNAME is the `file-truename' of DIRNAME, if given."
>    (setq compilation-gcpro nil)
>    ;; FIXME: the old code reset the directory-stack, so maybe we should
>    ;; put a `directory change' marker of some sort, but where?  -stef
> -  ;;
> -  ;; FIXME: The old code moved compilation-current-error (which was
> -  ;; virtually represented by a mix of compilation-parsing-end and
> -  ;; compilation-error-list) to point-min, but that was only meaningful for
> -  ;; the internal uses of compilation-forget-errors: all calls from external
> -  ;; packages seem to be followed by a move of compilation-parsing-end to
> -  ;; something equivalent to point-max.  So we heuristically move
> -  ;; compilation-current-error to point-max (since the external package
> -  ;; won't know that it should do it).  --Stef
>    (setq compilation-current-error nil)
>    (let* ((proc (get-buffer-process (current-buffer)))
>  	 (mark (if proc (process-mark proc)))
> diff --git a/lisp/progmodes/prolog.el b/lisp/progmodes/prolog.el
> index 296a7ac3c9..cd5a1a4ecc 100644
> --- a/lisp/progmodes/prolog.el
> +++ b/lisp/progmodes/prolog.el
> @@ -1711,13 +1711,10 @@ This function must be called from the source code buffer."
>        (remove-function (process-filter process)
>                         #'prolog-consult-compile-filter))))
>  
> -(defvar compilation-error-list)
> -
>  (defun prolog-parse-sicstus-compilation-errors (limit)
>    "Parse the prolog compilation buffer for errors.
>  Argument LIMIT is a buffer position limiting searching.
>  For use with the `compilation-parse-errors-function' variable."
> -  (setq compilation-error-list nil)
>    (message "Parsing SICStus error messages...")
>    (let (filepath dir file errorline)
>      (while
> @@ -1736,17 +1733,7 @@ For use with the `compilation-parse-errors-function' variable."
>        (if (string-match "\\(.*/\\)\\([^/]*\\)$" filepath)
>            (progn
>              (setq dir (match-string 1 filepath))
> -            (setq file (match-string 2 filepath))))
> -
> -      (setq compilation-error-list
> -            (cons
> -             (cons (save-excursion
> -                     (beginning-of-line)
> -                     (point-marker))
> -                   (list (list file dir) errorline))
> -             compilation-error-list)
> -            ))
> -    ))
> +            (setq file (match-string 2 filepath)))))))
>  
>  (defun prolog-consult-compile-filter (process output)
>    "Filter function for Prolog compilation PROCESS.
> diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
> index 9c91d27b94..2fdbba84cf 100644
> --- a/lisp/textmodes/tex-mode.el
> +++ b/lisp/textmodes/tex-mode.el
> @@ -2489,9 +2489,7 @@ Only applies the FSPEC to the args part of FORMAT."
>        (tex-send-command tex-shell-cd-command dir)))
>    (with-current-buffer (process-buffer (tex-send-command cmd))
>      (setq compilation-last-buffer (current-buffer))
> -    (compilation-forget-errors)
> -    ;; Don't parse previous compilations.
> -    (set-marker compilation-parsing-end (1- (point-max))))
> +    (compilation-forget-errors))
>    (tex-display-shell)
>    (setq tex-last-buffer-texed (current-buffer)))
>  \f



      reply	other threads:[~2019-04-06 22:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-23 13:55 compile.el legacy compatibility Troy Hinckley
2019-03-24 17:51 ` Stefan Monnier
2019-03-25 19:23   ` Troy Hinckley
2019-03-26 14:05     ` Stefan Monnier
2019-03-30 10:11       ` Eli Zaretskii
2019-04-03 15:20         ` Stefan Monnier
2019-04-06 13:14           ` Troy Hinckley
2019-04-06 22:50             ` Stefan Monnier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv7ec63g6w.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=t.macman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).