[gshenaut]

Yes, that's in the right direction, but I don't want to "complete" a project name, I want to find the id of a specific project from its name. The completion method is inherently ambiguous. I wrote a shell script kludge based on the xml file but would rather use something more standard.

How can these lines

set MyProjectArray to complete ProjectString as project maximum matches 1
set MyProjectID to id of first item of MyProjectArray

be modified to use an exact string match instead of a completion to find a project's ID?

Originally Posted by gshenaut

Yes, that's in the right direction, but I don't want to "complete" a project name, I want to find the id of a specific project from its name. The completion method is inherently ambiguous.

On the complete method ...

The complete method has to be "inherently ambiguous" simply because the data is inherently ambiguous. Nothing prevents 2 projects (or 10 projects for that matter) from having identical names, so there can, alas, be no simple mapping of a name string onto a unique id.

You just have to remove the maximum matches parameter, see how many matches you have got in your data, and handle the harvest iteratively in the way that makes sense for your application.

tell application "OmniFocus"
	tell front document
		set lstMatches to complete strPattern as project
		set lngMatches to length of lstMatches
		if (lngMatches) > 1 then
			-- deal with the multiple matches ...
			repeat with recMatch in lstMatches
				set {_, lngScore, strID, strName} to recMatch as list
				
				-- handle each match here ...
				
			end repeat
		else if lngMatches > 0 then
			-- good ! you have a unique match !
		else
			-- sorry ! no matches at all !
		end if
	end tell
end tell

[gshenaut]

That's interesting. I suppose I simply should not open an OmniFocus window at all when there is more than one project for a given name, or maybe even pop up an error message, since under my naming convention, that would be a user error. Another possibility might be to open *all* projects with that name in separate windows or all in one window (if that's even possible).

But that takes me back to "inherent ambiguity": Is there some way to not include projects with names like "Foobar" for input "Foo" using "complete"? As I understand it, invoking «*complete "Foo"*» will return all projects whose name contains "Foo" as a substring, including "Foobar", but it would *not* be erroneous to have two different projects named like that.

Originally Posted by gshenaut

Is there some way to not include projects with names like "Foobar" for input "Foo" using "complete"?

You just need to iterate through the list of matches, and pull out the exact ones.

e.g. something like:

tell application "OmniFocus"
	set oDoc to front document
	set strName to "xyz" as string
	set lstProjects to my ExactMatchProjects(oDoc, strName)
end tell

on ExactMatchProjects(oDoc, strName)
	using terms from application "OmniFocus"
		tell oDoc
			set lstExact to {}
			set lstMatches to complete strName as project
			if (count of lstMatches) > 0 then
				repeat with recMatch in lstMatches
					set {_, _, strID, strMatch} to recMatch as list
					if strMatch is strName then
						set end of lstExact to project id strID
					else
						-- sorted by score, so there will be no more
						-- exact matches
						exit repeat
					end if
				end repeat
			end if
		end tell
	end using terms from
	lstExact
end ExactMatchProjects

[Ken Case]

Originally Posted by gshenaut

But that takes me back to "inherent ambiguity": Is there some way to not include projects with names like "Foobar" for input "Foo" using "complete"? As I understand it, invoking «*complete "Foo"*» will return all projects whose name contains "Foo" as a substring, including "Foobar", but it would *not* be erroneous to have two different projects named like that.

You should be able to just use the first match: if there's an exact match, it should always be listed first. (If not, please let us know as that's a bug!)

Originally Posted by Ken Case

You should be able to just use the first match: if there's an exact match, it should always be listed first. (If not, please let us know as that's a bug!)

Complete does work as advertised - multiple matches are sorted by their match score, with the best matches first.

(Of course, the best match is not necessarily an exact match, and even when the first match is an exact one, one can not exclude the possibility that the 2nd and 3rd up to Nth matches may also be exact ... Nothing constrains top level project names to be unique)

It is not too difficult to iterate through the match list, gathering any exact matches from the start of it.

(Though it might be helpful to add an ExactMatchesOnly option to Complete ...)

--

[gshenaut]

I really appreciate all the help.

Here's another glitch that I don't know how to handle. In OmniFocus, I have my projects in folders. For example, there's a folder "Writing". So suppose I have a writing project called "Foobar". Well, the "complete" command appears to return "Writing : Foobar" as the name of the project, in a structure of this form:

{name:"Writing : Foobar", xml:"Writing : <span class=\"match\">Foobar</span>", id:"jexW10LHv6C", score:195}

Therefore, I never get any exact matches for project names. What's odd about this is that in the XML version of the database, there is a "<name>Foobar</name>" tag in the project record, with just a "<folder idref=XXX /> back to the enclosing folder. So in a sense, it "should" be easier for "complete" to just work on the project name in isolation.

On the other hand, this may be related to the "inherent ambiguity" issue: now for there to be two projects that "complete" returns the same name for, they will also have to be in identical folder hierarchies, which I suppose is theoretically possible, but probably shouldn't be permitted.

Anyway, is there a modifier or some other way to make "complete ... as project" not prepend projects' folder hierarchies, or to do something like

s/..*: //

on the values that it does return?

Greg

Originally Posted by gshenaut

is there a modifier or some other way to make "complete ... as project" not prepend projects' folder hierarchies,

No. Probably better to assemble the whole path, in the " : " delimited format, and apply complete to that. Less risk of multiple matches, for a start.