Re: Universal Ctags: Don't read config files; New 'ctagsoptfile' configuration variable

[Shigio YAMAGUCHI]

> 'ctags-gtags.conf' is just a configuration file for Universal Ctags.
> It lists flags accepted by the program, one per line (see ctags(1)).
>
> See also the new text in 'gtags(1)' in the attached patch.

I understand.

> So I've kept 'ctagsoptfile' and added 'ctagsopt'. See the new attached patch:
> It adds both 'ctagsoptfile' and 'ctagsopt', allowing merging of 'ctagsopt'
> lines (with '\n') and discarding empty ones, and provides documentation for
> these new variables and also 'ctagscom' (which was not documented).

I don't think 'ctagsopt' is necessary. I prefer 'ctagsoptfile' instead
because it is simple and it keeps a clear boundary between Ctags and Global.
The complexity of 'ctagsopt' does not match the usefulness of it.
The reason why I suggested 'ctagsopt' is because I didn't understand
'ctags-gtags.conf' is a ctags's configuration file.

I have two questions:
Q1. Your patch seems to fix the bug. But if the configuration file specified
    by 'ctagsoptfile' contains inconvenient options, will that bug occur again?
Q2. It seems that patched Universal Ctags plug-in parser does not load
    any ctags configuration files automatically. It means an incompatible
    change.  Is it right?

>> What are '--option' and '--option-maybe'? Which command's options?
>
> These are flags to Universal Ctags (see ctags(1)).

I understand.

> As for the attached patch, I went with the pedestrian way of
> doing string and argument manipulations.

No problem.
I wish to discuss user-level specifications first.
You can put off how to implement it and who will implement it.

Regards,
Shigio

On Wed, Apr 19, 2023 at 9:56 PM Olivier Certner <ocert.dev@free.fr> wrote:
>
> Hi,
>
> > Could you write a description about this variable for the
> > CONFIGURATION section of gtags(1)?  Could you explain the format of
> > 'ctags-gtags.conf'?
>
> 'ctags-gtags.conf' is just a configuration file for Universal Ctags. It lists 
> flags accepted by the program, one per line (see ctags(1)).
>
> See also the new text in 'gtags(1)' in the attached patch.
>
> > Should we use a file? How about putting the contents of the file
> > directly into a variable (may be 'ctagsopt')?
>
> Since this Universal Ctags configuration is specific to Global, having it in 
> Global's configuration file certainly makes sense.
>
> But having the file alternative can be seen as simpler: You just have to 
> copy/paste the lines you want to keep from your "normal" Universal Ctags 
> configuration in the specific 'ctags-gtags.conf' (or whatever name you 
> choose) and can then keep experimenting in this file without touching 
> Global's config. I went with the file implementation for this reason and also 
> because it was the simplest to do.
>
> So I've kept 'ctagsoptfile' and added 'ctagsopt'. See the new attached patch: 
> It adds both 'ctagsoptfile' and 'ctagsopt', allowing merging of 'ctagsopt' 
> lines (with '\n') and discarding empty ones, and provides documentation for 
> these new variables and also 'ctagscom' (which was not documented).
>
> > What are '--option' and '--option-maybe'? Which command's options?
>
> These are flags to Universal Ctags (see ctags(1)). The first makes the 
> program read a configuration file and error out if no such file exists. 
> '--option-maybe' can be used to ignore such errors, but I would prefer we 
> don't use it.
>
> As for the attached patch, I went with the pedestrian way of doing string and 
> argument manipulations. Surely could I have used 'strbuf' or created another 
> abstraction, simplifying the code (and making it less efficient; not that it 
> matters in this case), but this was not my initial approach. I have very 
> little time now, so I won't be able to implement and test any large changes. 
> If you want to clean up the code with abstractions, you'll have to do it on 
> your own. But I'm still available for questions and support.
>
> As for tests, I tested all possible combinations, as well as Windows' 
> argument preparation code this time. So the patch should be as safe as it can 
> be. The only lacking verification is to compile and run the plugins on an 
> actual Windows machine.
>
> Thanks and regards.
>
> --
> Olivier Certner



-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint:
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB