On Thu, May 9, 2024 at 3:54 AM Shigio YAMAGUCHI <
shigio@gnu.org> wrote:
> What about converting the wrapper to consistently use bytearrays
> instead of strings?
I agree. I think that bytearray does not break compatibility
with python2. Is it right?
...or alternatively, consistently use strings assuming all I/O was latin1 encoded. This is the case
in other places in the wrapper and is unlikely to put us in any worse
situation than we already have. I believe this way it would be possible
to unify Python2 and Python3 code paths, too.
> The original problem that made me look into
> this was that ‘load_ctags_path()’ currently returns a bytearray
> (non-Win32) and the variable ‘UNIVERSAL_CTAGS’ is later compared
> with a string ('' != b''). Under Python 2 this didn't matter.
Do you mean that there is a bug in pygments_parser.py?
If so, could you please explain the specific steps to reproduce it?
Compile global on a platform that is non-win32 (e.g. 'linux') and choose Python3 as Python executable, a reasonable choice since Pygments itself, which is imported, depends on Python3. Choose a pygments-parser configuration and run gtags. Notice that GTAGS will contain no entries.
- In handle_requests(), the variable path is set to the result from load_ctags_path(), which is a bytearray on the platform above.
- The following condition compares the bytearray path with the (empty) string, which is always false.
- Therefore the global variable UNIVERSAL_CTAGS will always be overwritten and end up as a bytearray, containing the configuration value of gtagscom.
- UNIVERSAL_CTAGS (bytearray) is compared with an empty string, which is always false.
- The else-branch of the conditional is always executed, skipping CtagsParser().
Best regards,
Marcus