> emacs org-mode: There is no live, inline LaTeX preview.
There is, but we haven't managed to merge it into Org mode yet because we (the feature authors) and the Org maintainer have been busy with other things.
Thanks! I followed the instructions to install it, they were super straight forward. This is exactly what I was looking for! Some notes:
- FYI there’s a typo in the docs of the sample use-package declaration, should be one dash instead of two in "org-latex-preview--mode”.
- Live preview works for me but only if I first do M-x org-latex-preview, it doesn’t do it automatically. Probably an issue of missing config on my end, but I haven't been able to figure it out yet.
- Unrelated issue is that org-cdlatex isn’t recognizing \begin{array} as math, e.g. it is inserting text mode latex there instead of math mode. No idea here, I don’t think I touched cdlatex from the built-in Doom Emacs version.
Unfortunately I’m out of time to spend configuring emacs… I’ll have to continue using Obsidian for now, but this is really cool! Hopefully I’ll have some time to come back to configuring emacs soon
> Live preview works for me but only if I first do M-x org-latex-preview, it doesn’t do it automatically.
Not an error on your end. Live previews for _new_ fragments are only supported when entering \[..\] and \(..\) delimiters, and not $..$ and $$..$$. With the latter you'll have to preview it manually once, and live previews will update from then on.
Is there _any_ other example? For years now, this is the only one I've ever seen brought up to support this point.
On the other side, there are many MacOS-specific features supported by Emacs, with the recently added dictation support being one of them. If a MacOS feature is missing, it's much more likely to be due to a lack of manpower than a desire to maintain feature parity with Linux.
For the entire 10 years I was a Mac user, a Japanese professor named Mitsuharu maintained a fork of Emacs with MacOS-specific features. I never came across any explanation for why the Emacs project didn't accept his changes (i.e., why he needed to maintain his own fork) other than some maintainers' wanting to discourage the use of non-Free OSes.
The good news is that this fork was very competently maintained, so I had a good experience in Emacs on OS X.
The 2 or 3 times I tried "vanilla" Emacs (the one published on fsf.org) it had bugs that weren't present in Mitsuharu Emacs. One of those times vanilla Emacs did not work at all: it displayed a window, but the window was very small (i.e., incapable of displaying more than a few characters) and the usual ways of enlarging a windows on OS X had no effect. My (typing blindly) evalling (set-frame-parameter frame 'fullscreen 'maximized) also had no effect.
The homebrew package named "emacs" got you vanilla Emacs. To get Mitsuharu Emacs, you needed to install the homebrew package named "emacs-mac" instead.
Maybe vanilla Emacs got better on OS X during the past 4.5 years. I haven't had access to a Mac during that time.
I have my own story over here[0], and I’m pretty sure that there’s going to be a lot of instances similar to what I’ve experienced — blocked from merging or just fizzling out due to the lack of push on features that work on non-free OSes. There’s a reason why there are so many forks and patches for Emacs on macOS that are maintained for years that are not getting upstreamed.
This is the only one that has bitten me personally, but I probably only noticed it because it was working and then taken away. I just assume there are more instances where something was never implemented in the first place for a political reason.
Edit: I also remember hearing that for a long time an ffi was forbidden because someone could use it to call proprietary software. Don't have a source on that one though.
> tried all the fancy context management stuff multiple times, but I mostly just have a chat buffer open and copy paste stuff manually.
As of last week you can insert a link to a plain-text file in a chat buffer to include its contents in the prompt. It must be on a line by itself. In Markdown it looks
[like this](/path/to/file)
with Org links in Org chat buffers.
This feature is disabled by default to minimize confusion. To enable it you can flip the header line button that says "ignoring media" to "sending media". This works for sending images and other media too, if the model supports it.
Do Cursor and co have better tools than the ones we write ourselves for lower-level interfaces like gptel? Or do they work better because they add post-processing layers that verify the state of the repo after the tool call?
Cursor is proprietary, but is known to index code for doing queries etc.
Cline is closer in spirit to GPTel, but since CLINE is an actual business, it does seem to do well off the bat. That said, I haven't found it to be "hugely better" compared to whatever you can hack in GPTel.
Quite frankly being able to hack the tools on the go in Elisp, makes GPTel far far better (for some of us anyway).
> Learn Windows' keyboard UI and you can drive the whole OS and all its apps with the speed of a genius Vim user
Do you have a reference for this? I've often needed to control Windows using only a keyboard and failed to do so. I'm aware of most shortcuts in this list[1] but these are for a few very specific things. (As an aside, I also remember controlling the mouse with the numpad using the Mouse Keys accessibility setting but this is worse than both keyboard shortcuts and the mouse.)
Look for underlined single letters in menus. With apps that use the "classic" style menus instead of ribbons or plain Electron crap, the single letters are the key.
I'm curious to know if this is what lproven meant in their comment above. Alt + a-z to access menu items is available in every OS and all "native" apps, but you can't "drive the OS and all apps" this way.
For example, I would like to set options that are a few menus/button clicks deep in the Windows control panel (either the "classic" or new variant) using keyboard shortcuts/navigation. Or navigate the Windows registry editor. I'm not aware of a way to do this.
No, it's not in all native apps. KDE reinvents its own set of keystrokes, for instance, and half the KDE apps have no menu bars any more... And there's no global way to force them either.
Yes, the control panel and RegEdit are totally keyboard controllable.
You can literally just unplug the mouse from a Windows desktop and it remains totally 100% operable.
Some apps may not, because the developers didn't do their jobs right, but the OS is.
> I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.
Everyone including the maintainers would like this to happen. The arguments against it are technical hurdles. Emacs is a large ball of global state and the lisp evaluator hooks into everything, including the display engine, so it's not clear to anyone how to disentangle things to the point where the interpreter lock can be released.
> It's the one powerful feature that has yet to be replicated in Emacs.
Emacs cannot do this. There are many Emacs libraries or packages that need this feature (Org babel is a big one, transclusion is another), and have to work around its absence in hacky ways.
Not sure why you got downvoted - you are correct.[1]
I don't know if there is any fundamental limitation in Emacs/Elisp that prevents it, or that no one has succeeded in doing it. I suspect it's the latter. I also suspect the problem is trying to shoehorn this to work with Org Mode (which is what I want as well), but there may be a significant impedance mismatch between the Org code base and this feature.
Frankly, trying to manipulate the Org tree using Elisp is a nightmare compared to how simple it is in Leo (using Python). I've been trying to do with Org mode what is fairly basic in Leo: Traverse the tree, make changes, copy the tree to another file, with some headlines demoted/promoted due to rules, etc. Although I finally got something working, it took a lot of research as well as multiple packages. Whereas in Leo, people without a programming background manage to write the Python code to do this very easily.
[1] karthink has written a number of heavily used Emacs packages. He likely knows what he's talking about.
You didn't mention a mobile app or cloud sync as one of your priorities, so any offline, desktop RSS feeder should provide most of these features.
I use Elfeed in Emacs, which satisfies all your requirements -- except bypassing paywalls -- and is the best RSS reader I've ever used. For context, I've used at least ten RSS readers since 2005 before finding Elfeed in 2018.
There is, but we haven't managed to merge it into Org mode yet because we (the feature authors) and the Org maintainer have been busy with other things.
Here are some screencasts:
- https://share.karthinks.com/olp-auto-mode-env-1.mp4
- https://share.karthinks.com/olp-auto-mode-inline-1.mp4
Here's a longer explainer (this is part 2/2): https://www.youtube.com/watch?v=u44X_th6_oY
Here are instructions if you want to try the fork of Org mode that provides this feature: https://abode.karthinks.com/org-latex-preview/
reply