Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t0oI6-00DJ4L-Uz for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Oct 2024 20:37:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t0oI5-00B9FM-AP for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Oct 2024 20:37:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t0oI4-00B9FD-VG for pgsql-hackers@lists.postgresql.org; Tue, 15 Oct 2024 20:37:13 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t0oI2-001Et1-Pt; Tue, 15 Oct 2024 20:37:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=xzPFSiaHT6VDUWm0sHRKRQe4sNrtzTivx33s0Zi6Yws=; b=akBO0 7JyeWDRv/L3V2Lg9YeXUJwgp66Jx0YR3w5Wo1wufsHNOD06ySI7gT5ZMlZWqP3BoSgF50YAVy0v76 8gPrvqvlGgaiGO/OiJC+V6a54/7u3xTyL+W6/KGwZXMorvaD9VFzZ1ChK+ZrRlTRn7uwqNRfs39vf u6F7fSyjcpdDZ46pSSs1TwunxkwWUbNVj7DyVAOILaE1xItakoOFCte46y7HgLeME3F+5T8RdH2Pk ySqjO6DpDL2/V04Jm/XTX/UZGojej0pkvYXwzx6V6gn3n3+e3JlEj1OYtgsK5XwRz9ezynW2W3+Dr m8Rtchq9kQ97/b8H7Cn34m3wjZqiQ==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1t0oHx-004xFC-0q; Tue, 15 Oct 2024 16:37:05 -0400 Date: Tue, 15 Oct 2024 16:37:05 -0400 From: Bruce Momjian To: Peter Eisentraut Cc: Yugo NAGATA , Tatsuo Ishii , tgl@sss.pgh.pa.us, daniel@yesql.se, pgsql-hackers@postgresql.org Subject: Re: Doc: typo in config.sgml Message-ID: References: <2565921.1728531809@sss.pgh.pa.us> <20241010.160041.949661508167788393.ishii@postgresql.org> <20241011114122.c90f8a871462da36f2e2afeb@sraoss.co.jp> <20241011.121650.2077607600187658573.ishii@postgresql.org> <20241011123653.09a67d3ad7b60a59e4558403@sraoss.co.jp> <20241015101036.d8c29e4aada1c3e92ddcef9d@sraoss.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Oct 15, 2024 at 10:34:16PM +0200, Peter Eisentraut wrote: > On 15.10.24 18:54, Bruce Momjian wrote: > > > I agree with encoding non-Latin1 characters and disallowing non-ASCII > > > characters totally. > > > > > > I found your patch includes fixes in *.svg files, so how about checking > > > also them by check-non-ascii? Also, I think it is better to use perl instead > > > of grep because non-GNU grep doesn't support hex escape sequences. I've attached > > > a updated patch for Makefile. The changes in release.sgml above is not applied > > > yet, though. > > Yes, good idea on using Perl and checking svg files --- I have used your > > Makefile rule. > > > > Attached is an updated patch. I realized that the new rules apply to > > all SGML files, not just the release notes, so I have created > > README.non-ASCII and moved the description there. > > I don't understand the point of this. Maybe it's okay to try to detect > certain "hidden" whitespace characters, like in the case that started this > thread. But I don't see the value in prohibiting all non-ASCII characters, > as is being proposed here. Well, we can only use Latin-1, so the idea is that we will be explicit about specifying Latin-1 only as HTML entities, rather than letting non-Latin-1 creep in as UTF8. We can exclude certain UTF8 or SGML files if desired. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"