GNU bug report logs - #28832
[PATCH 0/3] gnu: Add emacs-json-mode.

Previous Next

Full log

Message #29 received at 28832 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Oleg Pykhalov <go.wigust <at> gmail.com>
Cc: 28832 <at> debbugs.gnu.org, Alex Kost <alezost <at> gmail.com>
Subject: Re: [bug#28832] [PATCH 1/3] gnu: Add emacs-json-reformat.
Date: Tue, 12 Dec 2017 10:17:08 +0100

Hi Oleg,

Oleg Pykhalov <go.wigust <at> gmail.com> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:

[...]

>>> Did you have a chance to investigate the test failures?  It’s not
>>> confidence-inspiring ;-), so it would be good to at least have a link to
>>> an upstream bug report.
>
> Yes I looked at those tests.  Here is a little review of them.
>
> json-reformat-test:string-to-string basically just calls
> a reimplemented in Emacs 25 json-encode-string function.
>
> json-reformat-test:json-reformat-region-occur-error emulates error and
> produce a message.  This message is differ from Emacs 24 in symbol '`'.
>
> So, I think those test fails are harmless.  I attach the new patch with
> fixing those failing tests.

Indeed.

> From d589de21acb02d0fba7aee3b48e5f42d7bd8957e Mon Sep 17 00:00:00 2001
> From: Oleg Pykhalov <go.wigust <at> gmail.com>
> Date: Tue, 12 Dec 2017 01:41:08 +0300
> Subject: [PATCH] gnu: Add emacs-json-reformat.
>
> * gnu/packages/patches/emacs-json-reformat-fix-tests.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add this.
> * gnu/packages/emacs.scm (emacs-json-reformat): New variable.

[...]

> diff --git a/gnu/packages/patches/emacs-json-reformat-fix-tests.patch b/gnu/packages/patches/emacs-json-reformat-fix-tests.patch
> new file mode 100644
> index 000000000..23a239582
> --- /dev/null
> +++ b/gnu/packages/patches/emacs-json-reformat-fix-tests.patch
> @@ -0,0 +1,28 @@
> +Copyright © 2017 Oleg Pykhalov <go.wigust <at> gmail.com>
> +
> +This patch fixes tests for Emacs 25.

Please mention <https://github.com/gongo/json-reformat/issues/33> here.

OK with these changes!

> >> Besides, I wonder: shouldn’t ‘emacs-build-system’ define the
> >> ‘EMACSLOADPATH’ env. var. so we don’t have to carry all these -L flags?
> >> Is there any downside?
> 
> As I see from the documentation¹ EMACSLOADPATH is a list of directories
> with *.el files in it.  If we will use it, then it will be almost the
> same carring bunch of directories in package recipes, will it?

If ‘emacs-build-system’ sets ‘EMACSLOADPATH’ automatically, then
individual package definitions won’t need those -L flags.  Dunno if
there are good reasons not to do so.  Maybe Alex has an opinion?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.