far2l项目中EditorInfo结构体缺少FileName字段的技术解析

在far2l文件管理器的插件开发过程中，开发者可能会遇到一个常见问题：EditorInfo结构体中没有直接提供FileName字段。这与ViewerInfo结构体形成鲜明对比，后者明确包含了文件名信息。本文将深入分析这一设计差异的原因，并提供正确的解决方案。

结构体差异分析

在far2l的插件开发接口中，确实存在EditorInfo和ViewerInfo两个相似但不同的结构体：

1. ViewerInfo结构体：明确包含const wchar_t *FileName字段，开发者可以直接获取当前查看的文件名。

2. EditorInfo结构体：无论是Python绑定还是C SDK中的farplug-wide.h头文件，都没有直接提供FileName字段。只有在较旧的farplug-mb.h中能找到相关定义，但该头文件已被标记为弃用状态。

技术背景

这种设计差异源于far2l的历史演变和架构设计理念。编辑器组件相比查看器具有更复杂的内部状态管理机制，因为：

1. 编辑器可能处理未保存的新建文件，此时没有确定的文件名
2. 编辑器支持多标签编辑，需要更精确的API来控制
3. 文件名获取可能涉及编码转换等复杂操作

正确获取编辑器文件名的方法

虽然EditorInfo结构体不直接提供文件名，但far2l提供了专门的API来获取这些信息：

# 使用EditorControl命令获取文件名
filename = editor.EditorControl(editor.ECTL_GETFILENAME)

在C语言开发中，同样可以使用ECTL_GETFILENAME控制命令通过EditorControl函数来获取当前编辑的文件名。

最佳实践建议

1. 避免使用弃用接口：不要依赖farplug-mb.h中的旧定义，这些接口可能在未来的版本中被移除。

2. 处理空文件名情况：当编辑器处理未保存的新建文件时，获取文件名可能返回空值，代码中应该做好相应处理。

3. 性能考虑：频繁获取文件名时，考虑缓存结果而不是每次都调用API。

4. 多标签环境：在开发支持多标签的插件时，确保获取的文件名与当前活动标签对应。

通过理解这些设计原理和掌握正确的API使用方法，开发者可以更高效地进行far2l插件开发，避免陷入接口不一致的困惑。