从今天开始,Emacs里面可以运行任何你想要的程序 (Only Linux)


#162

我下午也找到这个项目了,看了源代码,不一样,没法用


#163

说实话,不值得在Mac系统下太多功夫. 苹果正在走30年前的老路,会逐步加速被边缘化.

Mac系统对开发者非常的不尊重. 之前因为帮主牛逼,大家也服气, 现在没那个本事了,还牛逼,那就是找死了.

把主力桌面环境切换到Linux 两年多,越用越顺溜....很高兴当年的决定是正确的.


#164

我现在手头两个本, 一台 Arch, 一台 Mac.

换着用, Mac 的快捷键各种魔改, 改成和Arch 一样, 要不两边用,手指头会疯的.

作为使用十几年的Linuxer, 我个人感觉, Mac 在保护系统稳定的架构设计和应用生态还是非常好的, 比较适合开发商业程序和不用涉及底层的程序.

涉及到要定制操作系统方面,就很麻烦了,什么都不能改.

理性看待 Mac, Mac 现在的现状可是所有Linux 发行版都没有达到的高度


#165

Mac OSX确实很好. 但那是当年NextStep打下的底子好.

现在的Mac OSX非常不适合做商业应用,每次系统升级,大概率会导致老程序无法使用, 逼这用户升级,逼着开发商更新应用, 这其实是一个恶性循环, 最终会导致系统被开发者抛弃.

当年我就吃过很多亏,那是相当尴尬的事情.以至于后来根本就不敢进行操作系统升级.

在厨子的带领下,苹果已经成为了一家生产消费类产品公司, 根本就无法成为生产力工具.

这几年奇奇怪怪的做法是越来越多, 砍USB,强推USBC, 华而不实的Touch bar, 砍Mega Safe, 为了减小厚度, 弄得键盘不像键盘..,.. 唉...

可惜了...


#166

对了,前不久为了运行gdb, 折腾了大半天....最后需要在一个非常莫名其妙的地方弄那么一下才让运行gdb


#167

需要数字签名验证。这是系统完整性保护的一部分,因为 gdb 有能力注入恶意代码。


#168

哈哈哈哈, 还好我没有买 TouchBar 的那款,哈哈哈


#169

再给你们打个预防针,Mac的硬件质量也非常糟糕.

我用过4台Mac, 有两台电池鼓包(是很大的那种,大到把机器整个给撑裂了)

还有一台用了不到三个月,键盘,触摸板完全失灵, 去保修的时候还是很大方的, 好像出了主板都换成新的了,可惜没过3个月又都坏了, 应该是设计问题, 还好我一直是用外接键盘. 后来一直撑到多苹果失去信心...下决心换了Linux


#170

哈哈哈,估计是笔记本做的太薄了,电池禁不起糟。

我买的苹果耳机也是三个月坏一次,换了4次就过保了,哈哈哈哈。


#171

Mac现在就是做消费品了…但是它消费品做的体验就是好,消费者不需要折腾。


#172

问一下,这个可以在spacemacs的下用吗?我试了下,就是简单的(require 'eaf),发现不能打开网址,所有的网址会自动加home前缀,即被当成path处理了。打开PDF会卡住,狂按ctrl+g后可以用了,但用那个快捷键退出啊😭


#173

spaceemacs 已经有用户报bug 了, spacemacs 本身就有bug,

请先 emacs -Q 来启动 emacs 加载 eaf, 排除 spaceemacs 的bug

退出直接杀掉 buffer 就可以了.


#174

app/browser 文件夹下放个空 init.py 文件就可以了

touch __init__.py

试试


#176

写了一个新的补丁来解决这个问题: https://github.com/manateelazycat/emacs-application-framework/commit/2cf99b2b3750944ec21ae1dd704cf57bf66c2c83


#177

方便的话请在项目里面加个 requirements.txt,这样 python 的包有添加的话,pip install 下就可以了


#178

然后我发现 pdf 用了 poppler 这个东西,又得装一堆库,有方便些的办法吗?


#179

肯定要用库啊……总不能手写整个pdf显示实现吧


#180

我的意思是有没有办法方便的引入需要的库,而不是用到 debug 发现报错了一个一个安装


#181

默认的按键是不是可以更 emacs 化一些,如: C-v or v Scroll down page M-v or V Scroll up page C-n or n Scroll down C-p or p Scroll up


#182

我感觉还是mupdf的库更好些。poppler的那个python-poppler-qt5好长时间没更新了,github上的issue也没人管。而PyMuPDF就好不少。不过eaf好像需要的是Python Qt5 库的三方联系,这个mupdf好像没有。

今天pyqt5和sip更新,重新编译之后发现python-poppler-qt5就安装不上了。。。

PS:仔细想想,eaf要做的是一个既易于开发又易于使用的package,但是它需要的东西必须同时与Python和Qt关联。

同时eaf也要依赖xlib和dbus,这样的话,eaf就会被限制在linux,可能还得是特定的Linux,比如archlinux。

我是用的archlinux,可是为了保证系统的稳定,我自己用的Python是用pyenv隔离出来的,在这种环境下,sip和PyQt5都得手动编译源码安装,要不然就没有webkit,这样每次更新就得编译一遍,编译PyQt5还是挺费时间的。

当然也可以lock出一个virtualenv给eaf单独用,但这样你自己用Python的时候就得切换,可能这就要写些elisp的hook之类的东西来做自动切换。

这不就把一个本来要简单易用的eaf变得麻烦了吗?

当然,我在这些方面都很业余,上面说的错误估计不少。大家可以讨论讨论。