Feature request: formatting templates

[mark-hahn]

I want a log line like

console.log("[App] 16, opt:", opt); // file is App.js, 16 is line number, etc.

I tried

  "turboConsoleLog.logMessagePrefix": "[",
  "turboConsoleLog.logMessageSuffix": "]",

but it wrapped the whole line.

[module] log info is a defacto standard for logging. It is all I use.

What would be nice is some kind of formatting like

[%file_pfx] %line_num, %vars

I could use the prefix of [ so console.log("[xxx]"); would separate these from non-turbo comments.

[mark-hahn]

Very minor comment: I said I could use the prefix of [ to separate these from non-turbo comments but there is a better way. See Issue 305.

[mark-hahn]

I'm considering developing this template feature in a pull request. I have written a number of vscode extensions so I know what I'm doing.

Ideas about the implementation would be appreciated. I will post my ideas here as they develop so people can comment, assuming anyone cares.

I am new to pull requests. I noticed two things...

• There are 9 open pull requests dating as far back as five years ago. Does this mean they were rejected or maybe abandoned by the author?

• I looked at the closed pull requests and they ended with Closed with unmerged commits. So I must ask again, were they rejected or maybe abandoned by the author?

[mark-hahn]

I've already run into my first big question. Every one of these config options could be deprecated when a template is provided ...

logMessagePrefix
logMessageSuffix
includeFilename
includeLineNum
insertEnclosingClass
insertEnclosingFunction
delimiterInsideMessage

The template config option would be a single simple string like [%file-pfx](%line-num) %func-class:

So how could we transition? Many would just want to use the old options for simplicity but many would like the flexibility of the template. Would we ...

• Disable old options if template is provided? (This might be confusing). We could provide a one-time command to translate the old options to the template.
• Make any change to old option automatically update the template? (Would be tricky since template format may be quite different).
• Make template changes update the old options? (Probably impossible).

I can start developing without an answer for this by just ignoring the old options but it doesn't hurt to start thinking about it.

[Chakroun-Anas]

Hi @mark-hahn,

Thanks for the thoughtful follow-up — and great to see your enthusiasm to contribute!

Regarding your first point: many of the older pull requests that were closed with unmerged commits were simply irrelevant or incomplete.
The currently open PRs were intentionally kept for reference because some of the ideas behind them still make sense — the repository has just evolved significantly since those contributions were made.

On the template system: I really like your thinking, but backward compatibility remains essential. The best approach would be to let both systems coexist:

• Existing settings (logMessagePrefix, logMessageSuffix, etc.) stay valid for all current users.
• A new template option could take priority if defined, acting as a master override.
• The detection engine (responsible for comment, uncomment, and delete) must support both configurations to ensure full reliability.

That way, we keep Turbo stable while giving advanced users more flexibility.
You’re absolutely welcome to proceed — feel free to open a pull request when ready, and we’ll refine and review it carefully together.

[mark-hahn]

template option could take priority if defined

I agree but I suggest one tweak.

It would be very useful if there was a sample template helping the user to understand templates and give them a starting point. The tweak is to use an additional boolean option to explicitly specify whether to use the new template. It would default to off. Then the default template could contain a value that gives a message that could have been generated by the old options. It would look like ...

🚀 ~ _file_:_line-num_ ~ _class_ ~ _func_ ~ _var_:

I also think this would be clearer than explaining the meaning of an empty template, although this would be a minor advantage.

[mark-hahn]

This is an early proposal of how templates work. They are complex but they can be used in a simple way. Also users of templates are advanced users.

I would also argue that all VScode users are advanced. These templates are child's play compared to regexes.

Template field names.

• path: The relative path from the workspace root to the file name. An example is src/components. It doesn't include an ending slash (/) because the slash can be placed as a constant used like _path_/_file_.

• file: The entire file name like index.js.

• file-base: The file name base like index.

• file-ext: The file name extension like js.

• line-num: The line number of the log line.

• class: The name of the class enclosing the log line.

• func: The name of the function the log line is in.

• var: The name of the variable shown after the message.

Template Field format.

The general format of a field is _xxx,options,'beg','end'_ wherexxx is the field name like line-num. All other parts are optional for advanced users.

• options give extra display control much like option letters at the end of a regex.

  • number: Minimum field width: If text is shorter than this then it will be padded. If the text is larger then the field will expand as needed (unless truncate option t is set).

  • t: Truncate: If field width is specified and text is larger than that width then the right side will be truncated to fit.

  • l, m, and r. Left, middle, and right alignment. If field width is specified and the text is smaller than that width then this specifies where text is aligned.

  • ^, c, and v. Uppercase, capitalize, and lowercase. Change case of text.

  • z. Pad with zeros. Use zeros instead of spaces for padding. Meant to make a column of numbers more readable.

• beg is a string that is shown before the field but only if the text isn't blank.

• end is a string that is shown after the text but only if the text isn't blank.

Examples

🚀 ~ _file__line-num,':'_ ~ _var_:  
    =>  "🚀 ~ index.js:121 ~ firstStr:"

[_file-base_ 🚀] (_line-num_) _var_:
    =>  "[index 🚀] (121) hashStr:"

[mark-hahn]

Minor change: changed field format from _xxx,options,'beg','end'_ to <xxx,options>. 'beg','end' was unneeded and stupid. Changing _ to <> makes template much more readable.

🚀 ~ _file__line-num,':'_ ~ _var_: is now 🚀 ~ <file>:<line-num> ~ <var>:.

[mark-hahn]

I've got a serious problem. Many places in the code assume the existing fixed format. An example of a killer problem is that it assumes there is a known fixed delimiter. My templates have no concept of a delimiter. Text is just text. There are other similar problems.

At this time the only solution I can think of is inserting zero-width chars inside the message to demarcate the fields. There are five different zero-width chars so I could combine multiple chars to encode positions. I do this in other extensions. But, I assume that solution would be considered a kludge and not be approved.

This is disappointing to me, not so much that I can't be a good citizen and help, but because I wanted to selfishly use it. The current fixed format is not acceptable for my logs which always have to start with [module] as many other logs do. I considered offering an optional opinionated fixed format but that is also a kludge and may not be popular.

I'll come back here if I can think of a solution but I doubt one exists.