bug#27965: 25.2; \cj does not match some Japanese characters

bug#27965: 25.2; \cj does not match some Japanese characters

[ynyaaa]

(string-match "\\cj"
              (mapconcat (lambda (l) (string (apply #'make-char
                                                    'japanese-jisx0213.2004-1
                                                    l)))
                         '((46 33) (47 126) (79 84) (79 126)
                           (116 39) (126 122) (126 123) (126 124))
                         ""))
=> nil

These characters belong to 'japanese-jisx0213.2004-1,
but does not belong to 'japanese-jisx0213-1.



In GNU Emacs 25.2.1 (i686-w64-mingw32)
 of 2017-04-25 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.0.6002
Configured using:
 'configure --host=i686-w64-mingw32 --without-dbus
 --without-compress-install 'CFLAGS=-static -O2 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:

Load-path shadows:
None found.

Features:
(network-stream nsm starttls tls gnutls mailalias smtpmail auth-source
cl-seq eieio byte-opt bytecomp byte-compile cl-extra cconv eieio-core
cl-macs gv pp shadow sort mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr
mail-utils mule-diag help-mode easymenu cl-loaddefs pcase cl-lib
time-date mule-util japan-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 209319 82842)
 (symbols 32 70470 3)
 (miscs 32 77 243)
 (strings 16 69689 11266)
 (string-bytes 1 1394714)
 (vectors 8 15896)
 (vector-slots 4 621371 13004)
 (floats 8 195 443)
 (intervals 28 51716 2075)
 (buffers 520 23))

bug#27965: 25.2; \cj does not match some Japanese characters

[Eli Zaretskii]

> From: ynyaaa@gmail.com
> Date: Sat, 05 Aug 2017 17:40:55 +0900
> 
> 
> (string-match "\\cj"
>               (mapconcat (lambda (l) (string (apply #'make-char
>                                                     'japanese-jisx0213.2004-1
>                                                     l)))
>                          '((46 33) (47 126) (79 84) (79 126)
>                            (116 39) (126 122) (126 123) (126 124))
>                          ""))
> => nil

It returns nil in Emacs 25.2, but 0 in the current master.  Does that
mean the problem is fixed in the current sources?

> These characters belong to 'japanese-jisx0213.2004-1,
> but does not belong to 'japanese-jisx0213-1.

I don't understand how it's related to the issue at hand.  If you
could tell a bit more about this, including reference to the portions
of Emacs sources (probably characters.el) and how they should be
examined for correctness, we could try and make sure there are no more
errors there.  I don't speak Japanese and don't know enough about the
various japanese charsets to see what, if anything, is in error.

Thanks.

bug#27965: 25.2; \cj does not match some Japanese characters

[Andreas Schwab]

On Aug 05 2017, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: ynyaaa@gmail.com
>> Date: Sat, 05 Aug 2017 17:40:55 +0900
>> 
>> 
>> (string-match "\\cj"
>>               (mapconcat (lambda (l) (string (apply #'make-char
>>                                                     'japanese-jisx0213.2004-1
>>                                                     l)))
>>                          '((46 33) (47 126) (79 84) (79 126)
>>                            (116 39) (126 122) (126 123) (126 124))
>>                          ""))
>> => nil
>
> It returns nil in Emacs 25.2, but 0 in the current master.  Does that
> mean the problem is fixed in the current sources?

Most likely by commit 096d134765.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#27965: 25.2; \cj does not match some Japanese characters

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: ynyaaa@gmail.com,  27965@debbugs.gnu.org
> Date: Sat, 05 Aug 2017 12:14:11 +0200
> 
> On Aug 05 2017, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: ynyaaa@gmail.com
> >> Date: Sat, 05 Aug 2017 17:40:55 +0900
> >> 
> >> 
> >> (string-match "\\cj"
> >>               (mapconcat (lambda (l) (string (apply #'make-char
> >>                                                     'japanese-jisx0213.2004-1
> >>                                                     l)))
> >>                          '((46 33) (47 126) (79 84) (79 126)
> >>                            (116 39) (126 122) (126 123) (126 124))
> >>                          ""))
> >> => nil
> >
> > It returns nil in Emacs 25.2, but 0 in the current master.  Does that
> > mean the problem is fixed in the current sources?
> 
> Most likely by commit 096d134765.

Probably.