如题，假如有一份几乎全职写elisp的工作，你是否会考虑去做？
薪资和你目前差不多平薪。工作是写elisp，将emacs的显示经过一套协议，转换到web。也就是让emacs支持web，或者说能在web使用emacs。类似web是一个emacsclient。（暂不考虑它的受众或市场）
另外，你需要考虑这份工作对你职业生涯以及工作履历的影响。
如果确要做这件事，那么它的困难点估计会在哪里，或者有哪些（显示）效果其实根本实现不了？(emacs或依然还会用到各种花哨或牛逼的插件)。
这怎么看来是钓鱼贴，正常公司会做这种没有商业价值的事情？
2 个赞
还真不是钓鱼贴。可能老板是个非常有技术情怀的人，抑或认为Emacs确实能提高逼格，We just need it。
而且，offer都发了 
这真是整个蓝星上活久见的事情。
3天后，做出决定。
其实他们把Vim(neovim) 的远程编辑和显示web化了。web不特指浏览器，可能是js桌面框架。
自古以来，Vim 和 Emacs就是一对吧，那么，Vim在的地方，Emacs是不是大概也就要量子纠缠一下
这怎么看起来是钓鱼贴
难不成是用 vimscript 写的？
我看做这个写 javascript 肯定远多过 emacs lisp 的，所以不会考虑
我突然想起来，大佬你不是有个大贴，“从今天开始，Emacs里面可以…”
有些想法可能类似吧。老板想做一套自认全新理念的云桌面分布式操作系统(界面,应用,通信)，里面包含各种能紧密互动及必备的组件工具，编辑器，编译器，Copilot，云服务，自开发应用等等等等
还真是vimscript写的。
javascript别人写。elisp应该是基于网络socket去通信。
而我在想，要把emacs当前所有界面元素，通知到web，web还要正确显示，这会是容易做到的吗？
1 个赞
emacsclient 与 emacsd 之间是用本地socket通信吧？emacsclient负责正确渲染。
传输的内容格式是emacs内部的协议吗？
不是，emacsclient 没有显示的功能，只负责传个文件的路径给 emacs，让 emacs 去自己打开
在运行 emacsclient 的终端打开 emacs 是通过 emacs 本身接管当前终端对应的 /dev/tty.XXX 实现的，也一样不需要经过 emacslient 就能显示
本站刚建立的时候有个贴子解释过 emacsclient 的实现
我的意思是， 你老板不理智， elisp + Web Emacs不难， 但是要让用户付费太难了。
而且我的感觉是你们不知道怎么做， 期望通过社区指点来做商业化， 是不是有点不理智？
没有恶意， 只是纯从商业角度在讨论。
运行 pgtk 版本的时候加上 GDK_BACKEND=broadway 这个环境变量不就能够实现吗？
我也理解你的角度和表达。
这个功能就算做出来，可以肯定几乎不会有人用。
可以这样理解这种不理智的行为，这更像是一个拼图，可选编辑器，有vscode的一片，有vim的一角，也有emacs的一席之地。老板可能希望这个拼图是好看点的。
你所感觉的靠社区指点商业化，其实只是我从个人角度，寻求一点意见，以及技术层面的可行性。
1 个赞
受教。以前没研究过这些编辑器与tty之间的关联依赖。tty本身也是古老和复杂的东西。
以前一直在sway上编pgtk的分支。broadway 这个 backend倒没使用过，改天看看这个东西。
这个 云桌面分布式操作系统 可否理解为 分布式低代码云开发平台？ 这个确实很多不差钱的老板愿意付费.
如果不能不用某个web低代码云开发工具,受够了 拖拽开发 ,当我切换到代码编辑器模式时, 发现有几个编辑器可选, 其中有emacs选项, 我肯定会去用的.
如果采购这个平台的人喜欢emacs, 有可能就是因为支持emacs的特性所以选择这个平台.也算是有商业价值了
可以认为里面包含一套开发平台，低代码高代码应该是都支持。
开发这套东西的老板不差钱。可能愿意购买的老板也不差钱 
Emacs受众极小，但可能确实会给知道它的人带来一丝惊喜。
大公司搞这个还行，小公司搞这个如果不能长期盈利早晚要黄，然后失业
Why not? 有兴趣就搞， 更何况还有钱。
说实话，不看好 vim和neovim那边是有专门的ui event和专门的通信协议，vim是jsonrpc，neovim是msgpackrpc 而且emacs用户群体真的不算多。。。。 至少我接触的写代码的甚至没多少听过emacs的，倒是认识几个emacs的忠实用户