Trailing tags idea

[Lutymane]

I think it'd be nice to have trailing option for tags, so comments could be more syntactically correct.

e.g.

instead of
// ! don't do it
it will be
// don't do it!

// ? question
to
// question?

and in config:

tag: "!",
trailing: true,

[edwinhuish]

Looks good.

But is it necessary?

• it will cause additional reg matching loop.
• it can only use in the line mode of line comment
• it will be strange to write together with other tags, like:

// # some title
// the question? Multiple sentences may have matching errors.
// * bold comment
// TODO: this is the block comment in line mode
//       no.2 line
//       no.3 line

[Lutymane]

it will cause additional reg matching loop.

Could you point me to the following code please? I thought the matching is a simple combination of trimming and slicing.

it can only use in the line mode of line comment

Indeed with this feature it's convenient to match only a single line ending

// don't use it!
// @note ...explanation
// continue explanation

so essentially first line is colored one way and the rest is the other

it will be strange to write together with other tags

I didn't quite understand the example, what I meant is to check if comment's content ends with a tag rather than starting. It shouldn't trigger if it appears inside of the string. Basically the logic is if there's no starting tag, check for ending.

Also the option may be more generalized "allowTrailing": true, so it will still match both the beginning and the ending

[edwinhuish]

Could you point me to the following code please? I thought the matching is a simple combination of trimming and slicing.

This code is for single line mode of line comment, if you want to use trailing mode, should add another RegExp match loop before this

better-comments-next/src/handler/langs/common.ts

Lines 141 to 167 in 6b18ac3

	if (lineTags.length) {
	const lineExp = new RegExp(`((^|\\s)(${mark}))([ \\t])(${lineTags.join('|')})([^\\n]*)`, 'gi');
	let line: RegExpExecArray | null | undefined;
	while ((line = lineExp.exec(content))) {
	const lineBegin = contentBegin + line.index;
	const startIdx = lineBegin + line[1].length + line[4].length;
	const endIdx = lineBegin + line[0].length;
	if (lineProcessed.find(range => range[0] <= startIdx && endIdx <= range[1])) {
	// skip if already processed
	continue;
	}
	// store processed range
	lineProcessed.push([startIdx, endIdx]);
	const startPos = editor.document.positionAt(startIdx);
	const endPos = editor.document.positionAt(endIdx);
	const range = new vscode.Range(startPos, endPos);
	const tagName = line[5].toLowerCase();
	const opt = decorationOptions.get(tagName) || [];
	opt.push({ range });
	decorationOptions.set(tagName, opt);
	}
	}

it will be strange to write together with other tags

means something like below, some tags in the begining, others at the end.

// # some title
// don't use it!
// * bold comment
// ~ custom tag decoration

You could use in this way.

// # some title
// ! don't use it! (Here is the reason why, this sentence will also be highlighted)
// * bold comment
// ~ custom tag decoration

Also the option may be more generalized "allowTrailing": true, so it will still match both the beginning and the ending

It will cause the reg more complicate or conflict with the vscode decoration. For example as blow:

// ! don't use it! (Here is the reason why, this sentence will also be highlighted)

The first ! will mark all line as highlight, but the second ! will mark ! don't use it! as highlight, it will cause conflict

At the end, I think it's not worth to do this, bacause:

• Just make the sentence more humane. However, you can consider the tag name as part of the annotation
• Will cause performance loss
• Will cause more conflict/bug at vscode decoration

[Lutymane]

It will cause the reg more complicate or conflict with the vscode decoration

Ah, what I meant is that config can be simpler so it will match both

// ! don't 
and
// don't !

In case of prefix presence it'd take the charge no matter the ending, so there can't be any conflicts. Basically if it looks like simple comment (without prefix) check for ending.

And trailing can't be somewhere in the middle, only at the end as I noted in the initial example.

Another example:

// don't use !
// @note explanation...

That's why I consider it easy to implement. Haven't looked at the code yet though. I'll do it later.

[edwinhuish]

For any new feature required, it is necessary to consider its necessity, the benefits it brings,
and most importantly, the potential problems it may cause.

You just said how will you use it. But I'm thinking about how will the people use.

If there more people needs it, I will think about it.