Hi,
I think that *unsupplied-argument-marker* (and *numeric-argument-marker*) should not be uninterned symbols or conses. The basic reason is that
(define-command-table foo-menu-table :menu (("Foo" (com-foo #.*unsupplied-argument-marker*))))
or any other use of the literal value of the markers will not survive a compile-file/load-fasl cycle: a "similar" but not EQ value will be constructed. This causes PARTIAL-COMMAND-P to fail, and confusion to reign. Patch attached (making the markers uninterned symbols -- one could imagine cleverer, interned struct representations, but that's probably overkill).
Also attached is a proposed adjustment to the READ-FRAME-COMMAND :AROUND handling of menu-items and partial commands. At the moment, the method only attempts to fill in partial command arguments if the input stream is an interactor-pane; and command-line-read-arguments is hardcoded. The second piece of the attached patch removes both of these restrictions, which is what is needed for my application, but I'm unsure of the general ramifications.
(I need the removal of the interactor-pane requirement because esa:minibuffer-pane is not a clim:interactor-pane. I'm not sure why not, nor what the protocol requirements on interactor-panes are.)
Comments? I think that these changes are fairly safe, but there might be better fixes that are less conservative.
Best,
Christophe
Christophe Rhodes csr21@cantab.net writes:
Comments? I think that these changes are fairly safe, but there might be better fixes that are less conservative.
Absent comments, I have committed these changes.
Best,
Christophe
PS: I know that this is a little bit of a reversal for me, but I begin to see the advantages of bug trackers even if they are not blessed with perfect interfaces. Does the McCLIM project have one, and if not would there be objections simply to turning on Trac on common-lisp.net?
On Sat, Feb 28, 2009 at 11:51 AM, Christophe Rhodes csr21@cantab.net wrote:
PS: I know that this is a little bit of a reversal for me, but I begin to see the advantages of bug trackers even if they are not blessed with perfect interfaces. Does the McCLIM project have one, and if not would there be objections simply to turning on Trac on common-lisp.net?
Trac was set up for mcclim some time ago, although it hasn't seen a lot of use.
Christophe Rhodes wrote:
Christophe Rhodes csr21@cantab.net writes:
Comments? I think that these changes are fairly safe, but there might be better fixes that are less conservative.
Absent comments, I have committed these changes.
Best,
Christophe
PS: I know that this is a little bit of a reversal for me, but I begin to see the advantages of bug trackers even if they are not blessed with perfect interfaces. Does the McCLIM project have one, and if not would there be objections simply to turning on Trac on common-lisp.net?
See http://intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-Systems
:) Tim
Timothy Moore moore@bricoworks.com writes:
Christophe Rhodes wrote:
PS: I know that this is a little bit of a reversal for me, but I begin to see the advantages of bug trackers even if they are not blessed with perfect interfaces. Does the McCLIM project have one, and if not would there be objections simply to turning on Trac on common-lisp.net?
See http://intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-Systems
Heh. I think the value of a bug tracking system increases as the inverse of the number of people who have the knowledge and the time to deal with bug reports. Why? Because if there's someone, or more than one, who looks at a bug report and either fixes it or ignores it, the problem has essentially gone away: either the bug is gone or it probably wasn't that important in the larger scheme of things.
What we have in McCLIM now is \epsilon active developers. This makes a bug tracker infinitely more useful, because it can then act (if people get on board, anyway; that's usually the difficult bit) as a repository of knowledge, even if that knowledge is "this doesn't work" -- and when the blue moon in the month of Sundays comes around and someone has some time to spend on fixing something (because, say, they're using McCLIM in some random project of theirs), less time needs to be spent wondering what it was in the first place that wasn't working any more.
Of course, my perception is coloured by the fact that, at least this month, it's me who's finding bugs, hacking around them, wondering whether what I'm fixing is actually a bug rather than someone's intentional behaviour, and generally getting all angsty that people might think that I'm taking responsibility...
:)
Bah. Looks like you're having way to much fun.
Best,
Christophe
-
Andy Hefner -
Christophe Rhodes -
Timothy Moore