An improvement could be to change ch_log() signature with:
ch_log({msg} [, {level}, {handle}])
Where {level} can be any of "debug", "info", "warning", "level".
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Don't you care about backward compatibility?
In the first place, isn't it enough to just provide a primitive logging function?
If necessary, users can wrap it and make it more convenient.
I think it's important to adapt yourself to Vim, rather than adapting Vim to you.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
You are right, this should not break retro-compatibility:
ch_log({msg} [,{handle}, {level}])
Having loggers with the mentioned levels is de-facto standard in computer engineering, it is not a singularity that I only need.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I am not sure if such a feature improvement would make sense since ch_log() appears too connected to channels.
Is user is not using channels at all, the log will include to much info about channels, which become just noise.
For example, the following script:
vim9script
ch_logfile('./tmp.log')
ch_log('Hello World!', null_job)
would produce the following log:
==== start log session Wed Feb 11 08:40:43 2026 ====
0.000018769 : ch_log(): Hello World!
0.000054489 : SafeState: Start triggering
0.002033663 : looking for messages on channels
0.002060305 : SafeState: back to waiting, triggering SafeStateAgain
2.887727601 : SafeState: reset: key typed
2.887903457 : SafeState: Start triggering
2.888490694 : looking for messages on channels
2.888506403 : SafeState: back to waiting, triggering SafeStateAgain
3.059346811 : SafeState: reset: key typed
3.059426625 : SafeState: Start triggering
3.059946932 : looking for messages on channels
3.059959632 : SafeState: back to waiting, triggering SafeStateAgain
3.185439610 : SafeState: reset: key typed
3.185556441 : SafeState: Start triggering
3.186298158 : looking for messages on channels
3.186319433 : SafeState: back to waiting, triggering SafeStateAgain
4.344881498 : SafeState: reset: key typed
4.344988801 : SafeState: Start triggering
4.345473103 : looking for messages on channels
4.345488582 : SafeState: back to waiting, triggering SafeStateAgain
4.502106421 : SafeState: reset: key typed
4.503167892 : looking for messages on channels
5.639053147 : setting timeout timer to 2 sec 0 nsec
5.656756402 : SafeState: Start triggering
5.656855782 : setting timeout timer to 2 sec 0 nsec
5.658502367 : looking for messages on channels
5.658583687 : SafeState: back to waiting, triggering SafeStateAgain
9.660743465 : SafeState: reset: key typed
9.742107141 : SafeState: Start triggering
9.742347462 : looking for messages on channels
9.742353523 : SafeState: back to waiting, triggering SafeStateAgain
19.128044410 : SafeState: Start triggering
19.128195178 : looking for messages on channels
19.128200983 : SafeState: back to waiting, triggering SafeStateAgain
Perhaps, it would be better to create an ex-novo general purpose logger log() that user can call with log('Hello world!", 'info'), and leave ch_log() alone.
Or to add a Vim9 logger that uses classes so that users could instantiate multiple loggers, e.g. var my_logger = NewLogger() and use it as my_logger.info = 'Hello World!. But perhaps the Vim9 solution is better suited for an external plugin.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
As another idea, ch_log() could prevent to log channel related info if null_job is passed as second argument. In that way, we would have a nice, clean and retro-compatible standard logger.
What I mean, is that the followig example script:
vim9script
ch_logfile('./tmp.log')
ch_log('Hello World!', null_job. 'info')
shall create the following log:
==== start log session Wed Feb 11 08:40:43 2026 ====
0.000018769 : info - ch_log(): Hello World!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()