unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: 17165@debbugs.gnu.org
Subject: bug#17165: 24.4.50; icomplete-exhibit: (wrong-type-argument number-or-marker-p nil)
Date: Tue, 1 Apr 2014 18:59:18 -0700 (PDT)	[thread overview]
Message-ID: <f347bf93-2816-4318-a6b8-da5b6c80c2bd@default> (raw)


I have some code that does this:

(when (and (featurep 'icomplete)
           (natnump icicle-icomplete-mode-max-candidates))
      (if (< nb-cands icicle-icomplete-mode-max-candidates)
          (if (not icicle-last-icomplete-mode-value)
              (icomplete-mode -1)
            (icomplete-mode 1)
            (icomplete-exhibit)) ; <==========
          (icomplete-tidy)
          (icomplete-mode -1)))

Once in a while I have seen this wrong-type-argument error.  I suspect,
but I do not know, that it comes from this code in `icomplete-exhibit':

(if (and (or icomplete-show-matches-on-no-input
             (> (icomplete--field-end) (icomplete--field-beg)))
    ...

I see that `icomplete--field-end' and `icomplete--field-beg' are defined
simply in terms of `completion-in-region--data'.  And AFAICT, that
variable can be nil, in which case each of `icomplete--field-(end|beg)'
is nil also.

I see too that in minibuffer.el `completion-in-region--data' is
initialized to nil, and the code there takes care to test for a non-nil
value before trying to access its components using `nth':

(and completion-in-region--data
     (and (eq (marker-buffer (nth 0 completion-in-region--data))
              (current-buffer))
          (>= (point) (nth 0 completion-in-region--data))
          (<= (point)
              (save-excursion
                (goto-char (nth 1 completion-in-region--data))
                (line-end-position)))
         (funcall completion-in-region-mode--predicate)))

A naive guess is that the code in icomplete.el should do likewise:
ensure that `completion-in-region--data' is non-nil before applying
`nth' to it and then using the result in a numeric comparison.

HTH.



In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-03-27 on ODIEONE
Bzr revision: 116884 lekktu@gmail.com-20140327173422-cr942b3hn7xjurks
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''





             reply	other threads:[~2014-04-02  1:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-02  1:59 Drew Adams [this message]
2016-04-29 19:52 ` bug#17165: 24.4.50; icomplete-exhibit: (wrong-type-argument number-or-marker-p nil) Lars Ingebrigtsen
2016-04-29 21:52   ` Drew Adams
2016-12-07 19:58     ` Glenn Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f347bf93-2816-4318-a6b8-da5b6c80c2bd@default \
    --to=drew.adams@oracle.com \
    --cc=17165@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).