unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [ELPA] Update package: psgml: handle (compile-internal) obsoletion
@ 2017-05-18  8:45 Lucien Pullen
  2017-05-18 13:04 ` Stefan Monnier
  0 siblings, 1 reply; 2+ messages in thread
From: Lucien Pullen @ 2017-05-18  8:45 UTC (permalink / raw)
  To: emacs-devel

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

It looks like (compile-internal) has been deleted, finally.  This 
patch
(see attached) adds a check to use the new (compilation-start) 
while
still being compatible with really old versions.

Is it really necessary to keep the legacy call in there?... how 
far back
should we support old versions?  My computer ships with v22, but 
my OS
is from 2013, and the new procedure was already marked as the one 
to use
by that point.

Unrelated... ...

  I'm not very familiar with Emacs' dynamic loader.  Does it 
  optimize
  out the branch instruction on load since it's a comparison of a
  constant? or does compiled code get interpreted literally?  It's 
  only
  a quick branch and calling the external procedure takes much 
  longer,
  but I used the version check instead of (fboundp) since it's 
  probably
  faster than the obarray lookup if the check is performed every 
  time
  you call the procedure.  Old assembly habits die hard.

Anyways, on to the patch file.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-psgml.el-sgml-validate-use-compilation-start-for-rec.patch --]
[-- Type: text/x-patch, Size: 1115 bytes --]

From 810f33f50b7c47250e41fb23387a96d862162452 Mon Sep 17 00:00:00 2001
From: Lucien Pullen <drurowin@gmail.com>
Date: Thu, 18 May 2017 01:54:05 -0600
Subject: [PATCH] * psgml.el (sgml-validate): use (compilation-start) for
 recent emacs

The procedure (compile-internal) has been deprecated since Emacs v22 and
is removed in at least v24.4.
---
 psgml.el | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/psgml.el b/psgml.el
index 9ab7eef..eb98071 100644
--- a/psgml.el
+++ b/psgml.el
@@ -1133,9 +1133,11 @@ and move to the line in the SGML document that caused it."
 			       nil nil 'sgml-validate-command-history)))
   (if sgml-offer-save
       (save-some-buffers nil nil))
-  (compile-internal command "No more errors" "SGML validation"
-		    nil
-		    sgml-validate-error-regexps))
+  (if (< emacs-major-version 22)
+      (compile-internal command "No more errors" "SGML validation"
+                        nil
+                        sgml-validate-error-regexps)
+    (compilation-start command nil nil sgml-validate-error-regexps)))
 
 \f
 ;;;; Autoloads and hooks
-- 
2.3.4


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [ELPA] Update package: psgml: handle (compile-internal) obsoletion
  2017-05-18  8:45 [ELPA] Update package: psgml: handle (compile-internal) obsoletion Lucien Pullen
@ 2017-05-18 13:04 ` Stefan Monnier
  0 siblings, 0 replies; 2+ messages in thread
From: Stefan Monnier @ 2017-05-18 13:04 UTC (permalink / raw)
  To: emacs-devel

> It looks like (compile-internal) has been deleted, finally.  This patch
> (see attached) adds a check to use the new (compilation-start) while
> still being compatible with really old versions.

Thanks, installed into elpa.git (but without the check: this version of
Psgml doesn't work in such old Emacs versions anyway).

> My computer ships with v22,

Well, personally, I don't consider that Emacs is distributed
with MacOSX.  They include some crippled tty-only version of it,
probably for sysdmin purposes.

>  I'm not very familiar with Emacs' dynamic loader.  Does it optimize
>  out the branch instruction on load since it's a comparison of a
>  constant?

Actually, it's not a constant: it's a variable which will probably
never be modified.

>  or does compiled code get interpreted literally?

It's pretty much interpreted literally.

>  It's only a quick branch and calling the external procedure takes
>  much longer, but I used the version check instead of (fboundp) since
>  it's probably faster than the obarray lookup if the check is
>  performed every time you call the procedure.

fboundp doesn't do an obarray lookup.  It already has the symbol so it's
only an field access within the symbol object.  It might very well be
faster than your < test (but I won't go and test it because I'm pretty
sure it's 100% lost in the noise, anyway).


        Stefan




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-05-18 13:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-18  8:45 [ELPA] Update package: psgml: handle (compile-internal) obsoletion Lucien Pullen
2017-05-18 13:04 ` Stefan Monnier

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