From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36573: 26.1; bufferpos-to-filepos assumes coding-system-eol-type gives integer Date: Wed, 10 Jul 2019 17:52:58 +0300 Message-ID: <83bly23prp.fsf@gnu.org> References: <877e8q2mc7.fsf@halibut> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="107395"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36573@debbugs.gnu.org To: Rupert Swarbrick Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 10 16:54:43 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hlDzX-000RoA-Ef for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jul 2019 16:54:43 +0200 Original-Received: from localhost ([::1]:34378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlDzW-0008Kx-2o for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jul 2019 10:54:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58080) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlDyv-00084a-Ez for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 10:54:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlDyt-0002BW-Gy for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 10:54:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55806) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hlDys-0002Ao-FO for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 10:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hlDys-00043m-DA for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 10:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2019 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36573 X-GNU-PR-Package: emacs Original-Received: via spool by 36573-submit@debbugs.gnu.org id=B36573.156277040515550 (code B ref 36573); Wed, 10 Jul 2019 14:54:02 +0000 Original-Received: (at 36573) by debbugs.gnu.org; 10 Jul 2019 14:53:25 +0000 Original-Received: from localhost ([127.0.0.1]:36393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlDyH-00042j-B7 for submit@debbugs.gnu.org; Wed, 10 Jul 2019 10:53:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlDyD-00042U-Hz for 36573@debbugs.gnu.org; Wed, 10 Jul 2019 10:53:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlDy8-0001HT-6n; Wed, 10 Jul 2019 10:53:16 -0400 Original-Received: from [176.228.60.248] (port=3509 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hlDy3-0006zU-E1; Wed, 10 Jul 2019 10:53:12 -0400 In-reply-to: <877e8q2mc7.fsf@halibut> (message from Rupert Swarbrick on Wed, 10 Jul 2019 11:52:24 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162644 Archived-At: > From: Rupert Swarbrick > Date: Wed, 10 Jul 2019 11:52:24 +0100 > > The bufferpos-to-filepos function assumes that the return value fo > coding-system-eol-type is an integer, testing it with > > (let* ((eol (coding-system-eol-type coding-system)) > (lineno (if (= eol 1) (1- (line-number-at-pos position)) > 0)) > ...) > ...) > > However, coding-system-eol-type may return a list if the given > coding system doesn't specify eol conversion explicitly. That shouldn't happen for a buffer that visits a file, in general. > This crops up for me when trying to browse info files: > > Debugger entered--Lisp error: (wrong-type-argument > number-or-marker-p [undecided-unix undecided-dos undecided-mac]) > =([undecided-unix undecided-dos undecided-mac] 1) > (if (= eol 1) (1- (line-number-at-pos position)) 0) > (let* /* SNIP contents of bufferpos-to-filepos */) > bufferpos-to-filepos(1202 exact) > Info-read-subfile(1200) > Info-find-node-2("/usr/share/info/gawk" "Top" nil nil) > Info-find-node("gawk" "Top" nil nil) > Info-goto-node("(gawk)" nil) > Info-menu("Gawk" nil) > funcall-interactively(Info-menu "Gawk" nil) > call-interactively(Info-menu nil nil) > command-execute(Info-menu) Please show the entire recipe for reproducing this, starting from "emacs -Q". Info files should generally have the -unix EOL type; that's what I see here. So I wonder how did we get into this situation. > (I've snipped out the contents of bufferpos-to-filepos from the > backtrace). It seems that the coding system for the info file is > 'undecided at this point. On my system, "C-u C-h i /path/to/gawk.info RET" yields a buffer whose buffer-file-coding-system is undecided-unix, as I'd expect. This happens both on GNU/Linux and on MS-Windows. So I wonder how you get something different. One can get undecided with empty buffers, or buffers that don't have a single newline, but this is not that case. > I'm not sure where the bug lies. If bufferpos-to-filepos (and > filepos-to-bufferpos) are supposed to work with an undecided > coding system, they need fixing. This function cannot possibly work with an encoding that has no definite EOL type, because obviously the conversion of buffer positions to file offsets depends on that. > Manually replacing "(= eol ...)" with "(eql eol ...)" locally in > both functions means that I can read the info file again (yippee!) > but I'm not sure whether that's a full solution. It could be, but we should first understand how did that happen, because there might be deeper problems hiding here. > Alternatively, I guess the documentation for these functions needs > to say that they should only be called when the coding system > specifies eol conversion. That should be done regardless, I think. But since this function was written specifically for Info files, it must work there (and did, AFAIK, since the day it was written till now).