Updating Autocomplete Definitions: Best Practices?

CmsWares

I’m compiling a new autocomplete XML file for PHP. The current one that’s still bundled in was compiled in 2010, which puts it two major versions behind (PHP 5.3.1 to be exact). I notice that there have been some additions. Still, on a quick diff of what I’ve parsed from the current manual and the old definitions, there are ~1000 removed and ~1500 added functions. So that’s a lot of missed suggestions there.

I still need add in control structures and magic methods (that are not included, switch, return, __construct() et al), and scrape up all the functions that are not listed under function.* but in the likes of mysqli::query, mysqli_query as “object-oriented style” and “procedural style”, so-called. Which brings me to my question. I’m reading the auto-completion docs and there’s this:

The basic character set used to recognize keywords is made of letters a-z, A-Z, digits 0-9, and the underscore _. Punctuation might work for auto-completion; however, if you want to use the parameter hints, you should not use punctuation in the keyword name.

An example from the PHP manual on mysqli_query:

// Object-oriented style
public mysqli::query( string $query, int $result_mode = MYSQLI_STORE_RESULT) : mysqli_result|bool

// Procedural style
mysqli_query( mysqli $mysql, string $query, int $result_mode = MYSQLI_STORE_RESULT) : mysqli_result|bool

Obviously :: are punctuation. This would mean that e.g. mysqli::query as a keyword would disable parameter hints. Tested and indeed so it does. Also to note, the “procedural” variant typically has a different signature (with an object passed as the first argument).

Then, what’s the preferred way of handling these situations? Ignore the :: variant? Or include it and let the hints not be shown? In any case, the :: versions are rarely (I think?) used for static calls with the literal class name, and it’s really only the class name (and constructor signature?) that’s conceivably helpful to include in autocomplete.

Also, there are any number of built-in classes with their methods that don’t have an “alternative access” variant. Example:

public PDOStatement::bindParam( string|int $param, mixed &$var, int $type = PDO::PARAM_STR, int $maxLength = 0, mixed $driverOptions = null) : bool

I’d be inclined to add PDOStatement as a separate keyword. This leaves the question of what to do with bindParam(). In this case there’s no collision, so it could go in, an orphan with its parameter hints. However e.g. PDO::prepare and mysqli::prepare have different signatures, and doubtless there are plenty more like that. And damned if I’ll be manually curating collisions for this. Also, adding in each method from each built-in class would conceivably create a lot of suggestion noise.

In any case, it seems that all the built-in class names (SPL) deserve to be included in the definitions on their own. Anybody feel like typing new RecursiveCallbackFilterIterator() a couple of times over huh?

Then, any feedback welcome on best practices here. While I’m at it and the scripts are still warm, I might as well scrape up current CSS and JS/ES6 definitions and update them. Seem a bit dated as well. To be continued. Thanks for all the great work with NP++.

PeterJones

@cmswares said in Updating Autocomplete Definitions: Best Practices?:

Also to note, the “procedural” variant typically has a different signature (with an object passed as the first argument).

That’s not a problem. You can have multiple entries for a given function:

It might be that you’d be better served by an LSP feature, maybe like the one in development mentioned here – I am not an LSP expert, but I think that function-argument hints are one of the things they are supposed to handle.

But yes, in general, as implemented today, I don’t know that you’ll be able to get around the :: being punctuation.

mpheath

@cmswares said in Updating Autocomplete Definitions: Best Practices?:

Obviously :: are punctuation. This would mean that e.g. mysqli::query as a keyword would disable parameter hints. Tested and indeed so it does. Also to note, the “procedural” variant typically has a different signature (with an object passed as the first argument).

If you did not set the Environment tag, then : is not matched. Set additionalWordChar=":" attribute to include the : as a autocomplete character. I also set ignoreCase="no" as PHP is case sensitive IIRC. Remove ignoreCase="no" if you like as it was not set previously.

Try this example as php.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<NotepadPlus>
	<AutoComplete>
		<Environment ignoreCase="no" additionalWordChar=":"/>
		<KeyWord name="mysqli::query" func="yes">
			<Overload retVal="mysqli_result|bool">
				<Param name="string $query"/>
				<Param name="int $result_mode = MYSQLI_STORE_RESULT"/>
			</Overload>
		</KeyWord>
		<KeyWord name="mysqli_query" func="yes">
			<Overload retVal="mysqli_result|bool">
				<Param name="mysqli $mysql"/>
				<Param name="string $query"/>
				<Param name="int $result_mode = MYSQLI_STORE_RESULT"/>
			</Overload>
		</KeyWord>
	</AutoComplete>
</NotepadPlus>

Both object oriented and procedural may cause confusion. The current php.xml seems to be procedural. I rarely use PHP so do not have a worthy opinion.

WinterSilence

Vote to adding Custom/user adapters for autocompletion