当前位置：文江博客话题详情

比例字体IDE

发布于 2024-07-04 20:44:44 字数 323 浏览 8 评论 0 原文

我真的很想看到一个比例字体 IDE，即使我必须自己构建它（也许作为 Visual Studio 的扩展）。我基本上的意思是 MS Word 风格的代码编辑，有点像《C++ 编程语言》书。

我想为缩进设置制表位，并排列函数签名和赋值语句行，这些可以用点而不是固定字符位置来指定。我还想要粗体和斜体。各种字体大小甚至样式表都会很酷。

有没有人见过这样的东西或者知道开始构建这样的东西的最佳方法？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

笑忘罢 2024-07-11 20:44:54

让我回忆一下有关在 C# 中使用“var”关键字的争论。人们讨厌它，认为它会让代码变得不太清晰。例如，您无法知道类似以下内容的类型：

var x = GetResults("Main");
foreach(var y in x)
{
   WriteResult(x);
}

他们的论点是，您无法查看 x 是否是数组、列表或任何其他 IEnumerable。或者 y 的类型是什么。在我看来，不清楚并不是因为使用了 var，而是因为选择了不明确的变量名。为什么不直接输入：

var electionResults = GetRegionalElactionResults("Main");
foreach(var result in electionResults)
{
   Write(result); // you can see what you're writing!!
}

“但是你仍然看不到选举结果的类型！” - 真的有关系吗？如果您想更改 GetRegionalElectionResults 的返回类型，您可以这样做。任何 IEnumerable 都可以。

快进到现在。人们希望将注释与类似的代码对齐：

int var2       =  1; //The number of days since startup, including the first
int longerVar  =  2; //The number of free days per week
int anotherVar = 38; //The number of working hours per week

因此，如果没有注释，一切都不清楚。如果不对齐值，则无法将它们与变量分开。但你呢？这个怎么样（请忽略项目符号）

int daysSinceStartup = 1; // 包括第一个
int freeDaysPerWeek = 2;
int 每周工作时间 = 38;

如果您需要对每一行进行注释，那么您就做错了。 “但你仍然需要调整价值观”——是吗？ 38和2有什么关系？

在 C# 中，大多数代码块可以仅使用制表符（或者实际上是四个空格的倍数）轻松对齐：

varregionsWithIncrease =
- 来自 GetRegionalElectionResults() 的结果
- 其中结果.TotalCount > 结果> 上一页总数 &&
  - 结果.PreviousTotalCount > 0 // 只是新区域
- 选择结果.区域；
foreach (regionsWithIncrease 中的 var 区域)
{
- 写入（区域）；
您

永远不应该使用逐行注释，并且很少需要垂直对齐内容。很少，不是从来没有。所以我理解你们中的一些人是否喜欢等宽字体。我更喜欢 Noto Sans 或 Source Sans Pro 字体的可读性。这些字体可从 Google 免费获得，类似于 Calibri，但专为编程而设计，因此具有所有必要的特征：

Big : ; 。，这样你就可以清楚地看到区别
Clearly different 0Oo 和distinct Il|

Let me recall arguments about using the 'var' keyword in C#. People hated it, and thought it would make code less clear. For example, you couldn't know the type in something like:

var x = GetResults("Main");
foreach(var y in x)
{
   WriteResult(x);
}

Their argument was, that you couln't see if x was an array, an List or any other IEnumerable. Or what the type of y was. In my opinion the unclearity did not arise from using var, but from picking unclear variable names. Why not just type:

var electionResults = GetRegionalElactionResults("Main");
foreach(var result in electionResults)
{
   Write(result); // you can see what you're writing!!
}

"But you still cannot see the type of electionResults!" - does it really matter? If you want to change the return type of GetRegionalElectionResults, you can do so. Any IEnumerable will do.

Fast forward to now. People want to align comments en similar code:

int var2       =  1; //The number of days since startup, including the first
int longerVar  =  2; //The number of free days per week
int anotherVar = 38; //The number of working hours per week

So without the comment everything is unclear. And if you don't align the values, you cannot seperate them from the variales. But do you? What about this (ignore the bullets please)

int daysSinceStartup = 1; // including first
int freeDaysPerWeek = 2;
int workingHoursPerWeek = 38;

If you need a comment on EVERY LINE, you're doing something wrong. "But you still need to align the VALUES" - do you? what does 38 have to do with 2?

In C# Most code blocks can easily be aligned using only tabs (or acually, multiples of four spaces):

var regionsWithIncrease =
- from result in GetRegionalElectionResults()
- where result.TotalCount > result > PreviousTotalCount &&
  - result.PreviousTotalCount > 0 // just new regions
- select result.Region;
foreach (var region in regionsWithIncrease)
{
- Write(region);
}

You should never use line-to-line comments and you should rarely need to vertically align things. Rarely, not never. So I understand if some of you guys prefer a monospaced font. I prefer the readibility of font Noto Sans or Source Sans Pro. These fonts are available freely from Google, and resemble Calibri, but are designed for programming and thus have all the neccesary characteristics:

Big : ; . , so you can clearly see the difference
Clearly distinct 0Oo and distinct Il|

回复收藏 0 原文

看海 2024-07-11 20:44:54

比例字体的主要问题是它们破坏了代码的垂直对齐，这在编写代码时是一个相当大的损失。

垂直对齐使得可以轻松执行剪切、复制、粘贴、删除和缩进、取消缩进等块操作，从而操作跨越多行的矩形代码块。

作为示例，请考虑以下代码片段：

a1 = a111;
B2 = aaaa;
c3 = AAAA;
w4 = wwWW;
W4 = WWWW;

在等宽字体中，= 和 ; 所有行向上。

现在，如果将此文本加载到 Word 中并使用比例字体显示，则文本实际上会变成这样：

注意： 添加额外的空白以显示= 和 ; 如何不再对齐：

a1 = a1 1 1;
B2  = aaaa;
c3 = A A A A;
w4 = w w W  W;
W4  = W W W  W;

随着垂直对齐的消失，那些漂亮的代码块实际上消失了。

另外，由于不再保证光标垂直移动（即，从一行到下一行的列号并不总是恒定），因此编写旨在操纵外观相似的行的废弃宏脚本变得更加困难。

The major problem with proportional fonts is they destroy the vertical alignment of the code and this is a fairly major loss when it comes to writing code.

The vertical alignment makes it possible to manipulate rectangular blocks of code that span multiple lines by allowing block operations like cut, copy, paste, delete and indent, unindent etc to be easily performed.

As an example consider this snippet of code:

a1 = a111;
B2 = aaaa;
c3 = AAAA;
w4 = wwWW;
W4 = WWWW;

In a mono-spaced font the = and the ; all line up.

Now if this text is loded into Word and display using a proportional font the text effectively turns into this:

NOTE: Extra white space added to show how the = and ; no longer line up:

a1 = a1 1 1;
B2  = aaaa;
c3 = A A A A;
w4 = w w W  W;
W4  = W W W  W;

With the vertical alignment gone those nice blocks of code effectively disappear.

Also because the cursor is no longer guaranteed to move vertically (i.e. the column number is not always constant from one line to the next) it makes it more difficult to write throw away macro scripts designed to manipulated similar looking lines.

回复收藏 0 原文

洛阳烟雨空心柳 2024-07-11 20:44:53

人们都在抱怨评论不排队。

在我看来，有一个非常简单的解决方案：将单位空间定义为字体中最宽的字符。现在，按比例间隔除空格之外的所有字符。该空格占据尽可能多的空间，以便将下一个字符排列在该行上所有前面的字符都是字体中最宽的字符的位置。

即：

iiii_space_Foo

xxxx_space_Foo

将排列“Foo”，“i”之后的空间比“x”之后的空间宽得多。

所以称之为弹性空间。而不是制表位。

如果你是一个聪明的编辑，请特别对待评论，但这只是肉汁

回复收藏 0 原文

把昨日还给我 2024-07-11 20:44:52

您问题的缩进部分今天正在实际产品中完成，尽管自动化程度可能比您想象的更高，我提到的产品是 XSLT IDE，但相同的格式化原则适用于大多数（但不是全部）传统代码语法。

这确实必须在视频中看到才能了解这一切（抱歉音乐回溯）。还有一个轻型 XML 编辑器衍生产品 XMLQuire，用作技术演示器。

下面的屏幕截图显示了在此 XSLT IDE 中使用相当复杂的格式规则进行格式化的 XML，其中所有缩进均以文字处理程序样式执行，使用左边距，而不是空格或制表符。

在此处输入图像描述

为了强调此格式概念，所有字符均已突出显示，以显示左边距延伸的位置以保持缩进。我使用术语虚拟格式来描述这一点 - 它不像弹性制表位，因为根本没有制表符，只有作为“段落”格式一部分的边距信息（此处使用 RTF 代码）。解析器在与语法着色相同的过程中不断重新格式化。

这里没有使用比例字体，但它本来可以很容易 - 因为缩进是以 TWIPS 为单位设置的。编辑体验非常引人注目，因为当您重构代码（在本例中为 XML）时，可能通过拖放或扩展属性值的长度，缩进会自行重新调整以适应 - 没有制表符 -键或“重新格式化”按钮按下。

所以，缩进是存在的，但字体工作是一个更复杂的问题。我已经对此进行了实验，但发现如果在键入时重新选择字体，代码的水平移动会让人分心 - 可能需要用户启动“格式字体”命令。该产品还内置了用于注释代码的墨水/手写技术，但我尚未在实时版本中利用它。

回复收藏 0 原文

白龙吟 2024-07-11 20:44:51

Soeren：在我看来，这很简洁。但人们真的会像这样排列评论吗？对于行尾注释，我总是使用一个空格，然后使用 // 或 /* 或同等内容，具体取决于我使用的语言。我从来没有尝试将声明或评论或任何东西排列起来，我见过的唯一地方就是在教科书中。

回复收藏 0 原文

最单纯的乌龟 2024-07-11 20:44:51

@Brian Ensink：我没有发现这样的代码格式更容易阅读。

int var1 = 1 //Comment
int longerVar = 2 //Comment
int anotherVar = 4 //Command

就我个人而言，

int var2       = 1 //Comment
int longerVar  = 2 //Comment
int anotherVar = 4 //Comment

我发现第一行比第二行更容易阅读。

@Brian Ensink: I don't find code formatted like that easier to read.

int var1 = 1 //Comment
int longerVar = 2 //Comment
int anotherVar = 4 //Command

versus

int var2       = 1 //Comment
int longerVar  = 2 //Comment
int anotherVar = 4 //Comment

I find the first lines easier to read than the second lines, personally.

回复收藏 0 原文

柠檬色的秋千 2024-07-11 20:44:50

当我上次查看 Eclipse 时（不久前！），它允许您选择任何已安装的字体来工作。不太确定它是否支持使用制表位缩进的概念。

它看起来很酷，但代码肯定更难阅读......

回复收藏 0 原文

黄昏下泛黄的笔记 2024-07-11 20:44:50

我想知道为什么没有人真正回答你的问题，以及为什么接受的答案与你的问题没有任何关系。但无论如何...

比例字体 IDE

在 Eclipse 中，您可以选择系统上的任何字体。

为缩进设置制表位

在 Eclipse 中，您可以配置自动缩进，包括将其设置为“仅制表符”。

排列函数签名和赋值语句行

在 Eclipse 中，自动缩进可以做到这一点。

可以用点而不是固定的字符位置来指定。

抱歉，我认为 Eclipse 无法帮助您。但它是开源的。 ;-)

粗体和斜体

Eclipse 就有这样的功能。

各种字体大小甚至样式表都会很酷

我认为 Eclipse 只为每种文件类型（例如 Java 源文件）使用一种字体和字体大小，但是您可以为不同的文件类型使用不同的“样式表”不同的文件类型。

回复收藏 0 原文

鞋纸虽美，但不合脚ㄋ〞 2024-07-11 20:44:49

@托马斯·欧文斯

我发现这样的代码格式并不容易阅读。

没关系，这只是个人喜好，我们可以不同意。按照您认为最好的方式格式化它，我会尊重它。我经常问自己“我应该如何格式化这个或那个东西？” 我的答案始终是对其进行格式化以提高可读性，我承认这可能是主观的。

关于您的示例，我只是喜欢在右侧有一个很好对齐的列，它是左侧代码的快速“索引”。话虽如此，我可能会避免像这样注释每一行，因为代码本身不需要那么多解释。如果是这样，我倾向于在代码上方写一段话。

但请考虑原始海报中的这个示例。在我看来，更容易发现第二个中的评论。

for (size-type i = 0; i<v.size(); i++) { // rehash:
    size-type ii = has(v[i].key)%b.size9); // hash
    v[i].next = b[ii]; // link
    b[ii] = &v[i];
}

for (size-type i = 0; i<v.size(); i++) {     // rehash:
    size-type ii = has(v[i].key)%b.size9);   // hash
    v[i].next = b[ii];                       // link
    b[ii] = &v[i];
}

@Thomas Owens

I don't find code formatted like that easier to read.

That's fine, it is just a personal preference and we can disagree. Format it the way you think is best and I'll respect it. I frequently ask myself 'how should I format this or that thing?' My answer is always to format it to improve readability, which I admit can be subjective.

Regarding your sample, I just like having that nicely aligned column on the right hand side, its sort of a quick "index" into the code on the left. Having said that, I would probably avoid commenting every line like that anyway because the code itself shouldn't need that much explanation. And if it does I tend to write a paragraph above the code.

But consider this example from the original poster. Its easier to spot the comments in the second one in my opinion.

for (size-type i = 0; i<v.size(); i++) { // rehash:
    size-type ii = has(v[i].key)%b.size9); // hash
    v[i].next = b[ii]; // link
    b[ii] = &v[i];
}

for (size-type i = 0; i<v.size(); i++) {     // rehash:
    size-type ii = has(v[i].key)%b.size9);   // hash
    v[i].next = b[ii];                       // link
    b[ii] = &v[i];
}

回复收藏 0 原文