说服 Perltidy 不留空白

发布于 2024-12-12 22:08:05 字数 1126 浏览 0 评论 0原文

我正在使用 Perltidy 将我的一些旧 Perl 文件重新格式化为更接近我当前偏好的样式。我遇到了此代码片段的问题：

Fcntl::S_IRUSR & $mode

Perltidy 坚持删除 & 标记后面的空格，结果是这样：

Fcntl::S_IRUSR &$mode

...在我看来这是一个碍眼的事情。我该怎么做才能说服 Perltidy 留下那个单独的空间？我什至尝试了 -fws 选项但无济于事。

我正在使用 Perltidy 20101217，这显然是最新版本。

编辑：

一些额外的观察结果：

使用 --indent-only (-io) 选项不会删除上述空格。
以下等效代码段不受此问题的影响：
```
$mode & Fcntl::S_IRUSR
```

编辑 2：

我最终颠倒了 & 运算符参数的顺序，因为这似乎可以解决 Perltidy 问题暂时的问题。此外，这种方法不需要添加额外的括号或任何其他可能帮助Perltidy做正确的事情的标记，但肯定会使我感到困惑从长远来看。

更新：

我就这个问题联系了 Perltidy 的作者 Steve Hancock。从他的回应来看：

我查了一下，问题是 &在这方面被误解了 case 作为函数调用 sigil。基本问题是没有看到其他模块的原型，即使是内置的，所以它必须猜猜当涉及到“Fcntl::S_IRUSR”之类的东西时。在其他方面换句话说，它不知道这是函数调用还是常量，并且必须猜测。当你颠倒顺序时，它消除了歧义 &。
谢谢你的留言。我看看是否能找到一个补丁来修复这个。

原文

I am using Perltidy to reformat a few of my old Perl files to a style that is closer to my current preferences. I encountered an issue with this snippet:

Fcntl::S_IRUSR & $mode

Perltidy insists on removing the space after the & token, resulting into this:

Fcntl::S_IRUSR &$mode

...which in my opinion is an eyesore. What can I do to convince Perltidy to leave that single space alone? I even tried the -fws option to no avail.

I am using Perltidy 20101217, which is apparently the latest version.

EDIT:

A few additional observations:

Using the --indent-only (-io) option does not remove the aforementioned space.
The following equivalent snippet is not affected by this issue:
```
$mode & Fcntl::S_IRUSR
```

EDIT 2:

I ended up reversing the order of the & operator arguments, since that seems to work around the Perltidy issue for the time being. In addition this approach does not require adding extra parentheses or any other tokens that might help Perltidy do The Right Thing, but would certainly confuse me in the long run.

UPDATE:

I contacted Steve Hancock, the author of Perltidy, about this issue. From his response:

I checked and the problem is that the & is being mistokenized in this
case as a function call sigil. The basic problem is that perltidy
does not see prototypes for other modules, even built-in, so it has to
guess when it comes to something like "Fcntl::S_IRUSR". In other
words, it doesn't know if this is a function call or a constant, and
has to guess. When you reversed the order it removed the ambiguity on
the &.
Thanks for the note. I'll see if I can come up with a patch to fix
this.

分享到QQ

分享到微博