【问题标题】:Why does emacs' comint-send-string behave differently in different derived modes?为什么 emacs 的 comint-send-string 在不同的派生模式下表现不同?
【发布时间】:2013-07-30 04:04:47
【问题描述】:

我最近一直在玩弄 comint-mode,我注意到一些奇怪的行为。它的文档记录很差,所以我想知道是否有人对此有任何见解。

在某些模式下,comint-send-string 会导致将发送的任何内容插入到 comint 缓冲区中然后发送到关联的进程,而在其他模式下,输入直接发送到进程而不被放入缓冲区。例如,用新的 (24.3) python.el 执行run-python,然后执行(comint-send-string "*Python*" "x=3\n"),将字符串x=3 插入缓冲区然后执行。但是,如果您先执行M-x shell,然后再执行(comint-send-string "*shell*" "x=3\n"),则不会在缓冲区中插入任何文本,而是将输入直接发送到shell进程执行。

有谁知道为什么存在这种行为差异或我可以如何改变它?

【问题讨论】:

  • 您正在使用 comint-send-string 的调用约定,但在谈论 comint-send-input - 请澄清您的问题。
  • 哎呀,对不起,你是对的。我说的是comint-send-string,将进行编辑。 comint-send-input 的使用完全清楚。

标签: emacs elisp


【解决方案1】:

我在 linux 上观察到相同的行为(emacs-version == "24.3.50.7",GUI 和 emacs -Q -nw):两者都没有

(comint-send-string "*Python*" "x=3\n")

也没有

(comint-send-string "*shell*" "x=3\n")

comint 缓冲区中插入任何内容(即出现下一个提示 就在上一个提示之后 - 它们之间甚至没有换行符)。

【讨论】:

  • 有趣;在 GUI 中运行 emacs 似乎是一个问题。我在 Cocoa emacs (Emacs.app) 中观察到上述行为,即使我所有的配置都关闭了,但从终端运行时却没有。
  • 这可能是苹果的人工制品,我在 linux 上看到了相同的行为,并且没有 GUI。
  • 嗯,经过进一步调查,GUI 似乎不是问题;在终端上再次尝试会给出我上面描述的行为。它工作了一次,但之后就没有了。你是对的,它可能是在 OSX 上编译的一些人工制品。我会问其他 OSX 用户,我知道他们看到了什么。奇怪。
  • (comint-send-string . . .之后使用(comint-send-input)怎么样?如果 \n 旨在等同于 comint-send-input,则将不再需要 \n
【解决方案2】:

我终于明白了。出于某种原因,OSX 上的系统 python 会导致这种行为,从 homebrew 安装 python 修复了它。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-11-15
    • 2021-08-03
    • 1970-01-01
    • 1970-01-01
    • 2016-06-28
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多