Re: Pattern matching lines starting with double comment characters

[goncholden]

------- Original Message -------
On Monday, February 27th, 2023 at 1:34 AM, Greg Wooledge <greg@wooledge.org> 
wrote:


> On Sun, Feb 26, 2023 at 08:57:18PM +0900, Koichi Murase wrote:
> 
> > 2023年2月26日(日) 17:02 Tapani Tarvainen bash@tapanitarvainen.fi:
> > 
> > > > The only portable way is to specify each just the same as you do for //:
> > > > 
> > > > pn_ere = "^[[:space:]]*(##|;;|!!|@c|//)[[:space:]]+"
> > > 
> > > Yes. Assuming the intent is to allow exactly two of the comment
> > > characters. Which the OP apparently wanted, but at least offhand
> > > I can't think of any language that requires blank space after
> > > the comment marker and it is actually rather common to use
> > > more of them at times.
> > 
> > To me, the OP's question is clear enough about the double comment
> > characters, and it does not feel so strange. Rather, generalizing it
> > to an arbitrary number of comment characters seems strange. I naively
> > wonder what would be the use case for detecting an arbitrary number of
> > comment characters.
> 
> 
> The thing is, this is at least the third thread started pertaining
> to whatever this project is. Here are the first two, that I know of:
> 
> https://lists.gnu.org/archive/html/help-bash/2023-02/msg00000.html
> 
> https://lists.gnu.org/archive/html/help-bash/2023-02/msg00002.html
> 
> In the first message of the first thread, there is a regex that
> looks for [#;!]+ among other things. So, the original precedent was
> to look for an arbitrary number of leading comment markers.

Yes, that was a wrong pattern, now fixed.
 
> At the same time, however, we were given examples that showed exactly
> two ## characters. I believed, at the time, that the author had
> cargo-culted the regex from some random source, and was trying to
> wedge it into his own project, where it was simply not needed.

The double ## would be used for storage of ancillary documentation that
a user could extract from the source code file.
 
> But then the requirements kept changing, and changing, and changing.
> The only thing that was clear was that all the examples we had been
> given fell completely short of describing the expected inputs.
> 
> After a few iterations, I simply gave up. We're clearly never going to
> be given the actual requirements, all at once, so that we can craft a
> working solution. Anything we do will be invalidated by the next change.

The input would be, for elisp files

;; FAML [ASMB] KEYS

where KEYS are keywords separated by commas