I noticed that the developer of kitty terminal uses this style of comments I have rarely if ever seen elsewhere:

outside
#: section {{{
inside
#: }}}

Kate text editor recognize sections for purposes of highlighting, folding etc. It's really nice for me because I sometimes I have a difficult time navigating large text files. And it lets you nest them.

• what is this called?
• are there other ways to do it?
• is it standard among text editors? I believe Kovid the dev for kitty is a vim guy so presumably there is support there also.
• why don't more people use it? are there problems?

Screenshot that shows the code folding.

• Cursor is at the end of line 7 so the whole section line 7-22 is highlighted
• lines 12-16 are folded in a 3rd level comment
• I also included tab indents just to make it easier to see what's going on (Kate treats it the same way regardless of indents)
• Highlighting/Mode > Scripts > Bash

I also like his style of distinguishing between narrative comments (starting with #:) and commented-out code (starting with #). Although in my example, Kate doesn't treat them differently. Is there a term for this? Any conventions, support etc?

#: Comment level 1 {{{
	#: Comment level 2 {{{
		#: configure something
		key value
	#: }}}
	#: Another Comment level 2 {{{
		#: Comment level 3 {{{
			#: Helpful explanatory comment
			file location
		#: }}}
		#: Comment level 3 with hidden text {{{
			you_cant see_this
			hidden_emoji "👁️"
			hidden_emoji2 " 👁️"
			hidden_emoji3 "   👁️"
		#: }}}
		#: let's set some things up
		# setting yes
		# other_setting no
		different_setting maybe
	#: }}}
	# regular comment
#: }}}

# regular comment outside anything

For a real world example, see sample kitty.conf file provided on project website.

I often see Rust mentioned at the same time as MIT-type licenses.

Is it just a cultural thing that people who write Rust dislike ~~Libre~~ copyleft licenses? Or is it baked in to the language somehow?

Edit: It has been pointed out that I meant to say "copyleft", not "libre", so edited the title and body likewise.

I'm a FLOSS/linux enthusiast. Over the years I have learned some scripting, and can get around in git. Occasionally I fork someone else's project to suit it to myself. Shell scripts, webapps, browser extensions etc. The kind of thing you can work in the source of without actual programming knowledge by just looking at text files.

Recently I modified a C program to have more legible/useful (to me) terminal output. I gave it a slightly different name and for compatibility have both versions running on my system. For my use-case it is a huge improvement over the original so I want to have it publicly available where I can install it from any system. And to share in case anyone else would enjoy it.

I don't think my changes would be appreciated by the original maintainer. For one thing, no changes have been made to the code in >10 years. The dev is still active so I guess the program is considered complete. For another, my changes are breaking and specifically disrupt the "linux philosophy" aspect of the program. I think having both version co-exist is the best way.

• I don't want to confuse anyone who is trying to find the repo of the original program.
  • The original is hosted on github whereas I use codeberg; so the "forked from" relationship is not as clear as if I stayed on github
• I ?do? want to update documentation such as README in the repo to describe my changes and relationship to the original
• I ?do? want to update and --help/man in the terminal to reflect the fork's name and possibly clarify how it works
• Should I make some sort of courtesy PR or repo issue offering my changes even though I think it would be (even should be) rejected/ignored? It seems kind of time wasting.
• In the case where the original upstream was being updated, how do I integrate those with my changes? I've had some luck so far with doing my best to guess about the git process, I think using branch, sync, merge. But I couldn't tell you more than that. Any insight on how this is supposed to go? I have spent lots of time wading through git's documentation but still find the main ideas kind of confusing.
• Anything else to consider?

Since I'm just dabbling, I try to stay away from more complicated workflows, or those which require specific system set up, when possible. My experience is that when I come back to it in a few months, a year or two years, I will have forgotten a lot; it might be a different system environment. I need to be able to re-learn everything at a later time. Simple solutions that are widely-compatible, and do not rely on my memory are preferred.

I don't mind doing a bit more work than is strictly required to learn about the FLOSS process. I've done it a few times before and it is useful to me to understand things.