gnats-prs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnats/251: gnats:state-change-from-to fails with ACK message


From: andrewg
Subject: gnats/251: gnats:state-change-from-to fails with ACK message
Date: 29 Aug 2001 08:31:18 -0000

>Number:         251
>Category:       gnats
>Synopsis:       gnats:state-change-from-to fails with ACK message
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 29 01:34:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Andrew Gray
>Release:        gnats-3.113.1 with gnats/250 patch
>Organization:
>Environment:
Red Hat Linux release 7.1, kernel 2.4.2-2, i586,
Emacs 20.7.1
>Description:
When running edit-pr on Emacs (after applying the patch
attached to gnats/250), changing the State field fails
with an ACK message in the command buffer.
>How-To-Repeat:
Start Emacs.
M-x edit-pr
200<Return>
Change to <category>/200 buffer
C-c C-s
>Fix:
The immediate cause of the error message seems to be that
the default value for the "States" field as found in the
gnats::fields variable is a compiled function, i.e.
 (type-of (elt (assoc "State" gnats::fields) 2))
evaluates to
 compiled-function
but the gnats::functionp function used by
gnats::field-default does not recognise it as a function
and returns nil. Using the built in functionp function
instead appears to fix the problem in my environment. The
attached patch file for send-pr-el.in makes this change.
I don't understand enough about Emacs Lisp to know why
gnats::functionp was coded originally and what the affect
of using the built-in functionp instead will be.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="patchfile.out"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="patchfile.out"

SW5kZXg6IHNlbmQtcHItZWwuaW4KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9nbmF0cy9nbmF0
cy9zZW5kLXByL3NlbmQtcHItZWwuaW4sdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMS4xLjEuMi4x
LjQuMQpkaWZmIC11IC1wIC1yMS4xLjEuMS4yLjEuNC4xIHNlbmQtcHItZWwuaW4KLS0tIHNlbmQt
cHItZWwuaW4JMTk5OS8xMC8yNyAwNToyOToyNgkxLjEuMS4xLjIuMS40LjEKKysrIHNlbmQtcHIt
ZWwuaW4JMjAwMS8wOC8yOSAwODoyMDo0MgpAQCAtNDc5LDcgKzQ3OSw3IEBAIGlmIGl0IGlzIG5v
dCBuaWwuIgogICAgIChjb25kICgoc3RyaW5ncCB0aGluZykgdGhpbmcpCiAJICAoKG51bGwgdGhp
bmcpICIiKQogCSAgKChudW1iZXJwIHRoaW5nKSAoY2FyIChlbHQgKGduYXRzOjpmaWVsZC12YWx1
ZXMgZmllbGQpIHRoaW5nKSkpCi0JICAoKGduYXRzOjpmdW5jdGlvbnAgdGhpbmcpCisJICAoKGZ1
bmN0aW9ucCB0aGluZykKIAkgICAoZnVuY2FsbCB0aGluZyAoZ25hdHM6OmZpZWxkLWNvbnRlbnRz
IGZpZWxkKSkpCiAJICAoKGVxIHRoaW5nIHQpIChnbmF0czo6ZmllbGQtY29udGVudHMgZmllbGQp
KQogCSAgKHQgKGVycm9yICJBQ0siKSkpKSkK


reply via email to

[Prev in Thread] Current Thread [Next in Thread]