GNU bug report logs - #6830
widget-complete bad completions in :type 'file

Previous Next

Package: emacs;

Reported by: Lennart Borgman <lennart.borgman <at> gmail.com>

Date: Mon, 9 Aug 2010 11:46:01 UTC

Severity: normal

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6830 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#6830: widget-complete bad completions in :type 'file
Date: Tue, 06 Mar 2012 23:12:02 +0200
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: cyd <at> gnu.org,  6830 <at> debbugs.gnu.org
> Date: Tue, 06 Mar 2012 15:45:02 -0500
> 
> >> Ideally, the cursor position should not be considered as "in the
> >> boundary", so the boundary overlay should not be considered for
> >> determining `field'.
> >> For that, I'd guess that you'd want the boundary's marker to use the
> >> insertion type t.  But AFAIK, the code already sets its type to t.
> >> So I'm not sure what's going on, here.
> 
> > I don't think I follow.  Can you elaborate on the role of the boundary
> > marker in this issue?
> 
> I'm not sure what's the role of the boundary marker.  But from what you
> say, the problem is that the boundary overlay's field property
> interferes.  But the cursor should not be considered as being "in the
> boundary field".  And indeed, the boundary's start marker is of
> insertion-type t, which means that Fget_pos_property should ignore this
> overlay when we're right in front of it.

Ah, that's a simple misunderstanding, then.  The boundary marker is
not related to this issue at all.  See below.

> The values that Chong sees for before_field, after_field, and field
> are correct.  If in your case, `field' has a value different from
> `completion' (e.g. it has value `boundary' or nil), then this is the
> problem whose origin we need to find.

The value of `field' on MS-Windows is neither `boundary' nor nil.  It
is the value of the widget itself.  Here's just its beginning, as an
illustration:

  (gdb) pp field
  (file :format " %v" :value "chown" :parent (custom-variable :documentation-shown t :custom-state modified :tag "Dired Chown Program" :value dired-chown-program :custom-form edit :custom-magic (custom-magic :args (nil) :parent #1 :indent 0 :children ((choice-item :help-echo "Change the state of this item." ...

As I explained earlier, this value comes from this snippet in
widget-specify-field:

    (let ((overlay (make-overlay from to nil nil rear-sticky)))
      (widget-put widget :field-overlay overlay)
      ;;(overlay-put overlay 'detachable nil)
      (overlay-put overlay 'field widget) <<<<<<<<<<<<<<<<<<<<<<<<<<<<
      (overlay-put overlay 'local-map keymap)
      (overlay-put overlay 'face face)
      (overlay-put overlay 'follow-link follow-link)
      (overlay-put overlay 'help-echo help-echo)))

When this is called as part of Customize, the Lisp backtrace looks
like this:

  "widget-specify-field" (0x82eac8)
  "widget-setup" (0x82ed24)
  "custom-buffer-create-internal" (0x82ef94)
  "custom-buffer-create" (0x82f1e4)
  "customize-variable" (0x82f4c4)
  "call-interactively" (0x82f704)
  "execute-extended-command" (0x82f954)
  "call-interactively" (0x82fb84)

IIUC, this code is part of setting up editable fields of a widget.




This bug report was last modified 13 years and 75 days ago.

Previous Next


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