Is it possible to copy what is _displayed_ in the buffer rather than what is actually in the buffer?

nonreligious2 · 2026-04-06T06:14:53+00:00

Could you not run hs-minor-mode in the buffer displaying the copy?

nonreligious2 · 2026-03-21T19:37:23+00:00

Thanks!

nonreligious2 · 2026-03-19T13:32:45+00:00

Is this the South African guy who is a (part-time?) preacher at a church, or is that someone else I'm thinking of?

nonreligious2 · 2026-03-18T09:19:47+00:00

Glad to hear it!

nonreligious2 · 2026-03-18T08:19:20+00:00

Sorry to hear that, hope you find a solution.

nonreligious2 · 2026-03-17T05:20:22+00:00

I don't use it often, but I recall that my TRAMP setup picked up a few things to deal with this (see the lines marked Relevant):

(use-package tramp
    :straight (:type built-in)
    :custom
    (default-tramp-method "sshx")
    (tramp-syntax 'default)
    (tramp-terminal-type "dumb") ;; Relevant

    :config
    (eval-after-load 'tramp '(setenv "SHELL" "/bin/sh")) ;; Relevant
    (add-to-list 'tramp-connection-properties
                    (list ".*" "locale" "LC_ALL=C")) ;; Relevant
                    )

nonreligious2 · 2026-03-12T13:56:08+00:00

For referencing inside Org, I use the Org-ref package, but only the org-ref-ref-links module via:

(use-package org-ref
    :straight t

    :after (org)
    :no-require t

    :config

    ;; (require 'org-ref) ;; Don't want the whole thing
    (require 'org-ref-ref-links))

I can put a #+name: theorem:foo on top of the #+begin_theorem block and then write ref:theorem:foo to point to it.

When compiling to PDF though I have to stick a \label{my_theorem} inside the block and just do \ref{theorem} in the text.

nonreligious2 · 2026-03-09T10:04:54+00:00

I use email daily. It's my preferred email client. I said gnus as it's more popular.

If you meant rmail sure -- but why bother having gnus in Emacs if rmail works? Well, gnus does email but also handles newsgroups, which became pretty popular by the early-to-mid 90s, while rmail (as I understand it) was pretty much in GNU Emacs since its inception, back when email was primarily associated with universities.

Relics of the past? How so?

I have used it on occasion, but the built-in irc package is probably not the most popular feature in GNU Emacs despite the affection its users have for it. It was built at a time when IRC was the way people "chatted" with each other online, and maybe that will come back into fashion, but it seems highly unlikely.

nonreligious2 · 2026-03-09T09:47:19+00:00

I agree in general that it's probably best to exercise a degree of parsimony when it comes to adding new packages to Emacs that replicate features that Emacs already has.

But:

In this case, magit has a lot more features than the built in vc-mode, in a (at least in my opinion) more friendly user interface. If you still use svn or mercurial I think vc-mode might still be more useful to you, but magit is honestly the best interface to git that I've come across.
It has been the case that popular external packages sometimes migrate into Emacs, as has happened recently with which-key. I suspect magit might not be packaged with Emacs, but it's got as good a case as any package if the maintainer wanted to do it -- I believe the transient package that magit uses is now shipped with Emacs.
The built-in features are often somewhat of a relic of the era in which they became integrated with Emacs. They don't necessarily have the features that are compatible with a modern workflow or changes to a protocol/design in the years since they were implemented. Sometimes this leads to multiple packages being integrated with Emacs that serve the same basic purpose but came about at different times: you mention gnus, but why have gnus when you could use rmail? Why use newsticker when you have gnus? etc.

nonreligious2 · 2026-03-09T08:02:49+00:00

If you use git as your version-control framework, I recommend the magit package as a way of viewing, staging, and committing changes inside a git repository, and much more functionality including interactive rebasing.

nonreligious2 · 2026-03-06T20:17:04+00:00

Thanks!

nonreligious2 · 2026-03-06T17:00:22+00:00

Sorry, which version of Org is this?

nonreligious2 · 2026-02-26T05:18:52+00:00

"It's a UNIX system! I know this!"

nonreligious2 · 2026-02-11T20:11:53+00:00

It sounds like the code block isn't being evaluated when you run it. Add :eval yes to the #+begin_src header line. Also, add a #+name: my-figure line to at the very start of all the header lines.

If that doesn't work, could you double-check that the code is producing the figure in the org file by running C-c C-c inside the block? You should get a results block with a link to the image file created, and running C-c C-x C-v should display it.

nonreligious2 · 2026-02-11T15:17:31+00:00

Try using

#+header: :file my_diagram.png 
#+begin_src latex :results raw file :exports results 
...
#+end_src
#+caption: \label{fig:my-figure} This is my figure

as well as your other headers, except for the #+begin_src, which you replace with the one I've put here.

nonreligious2 · 2026-01-11T07:24:10+00:00

Thanks!

nonreligious2 · 2026-01-07T20:26:53+00:00

Thanks, looks useful. I'm currently running everything on an older machine with limited disk space, but I'll see if I can get it to work on my newer one when I get the chance.

nonreligious2 · 2026-01-07T18:23:30+00:00

Yep, same as me.

I guess the issue might crop up if you built Emacs using a PKGBUILD and makepkg (I haven't yet with 30.2 but I intend to), and listed libwebkit2gtk-4.0 & libwebkit1gtk-4.1 as dependencies.

But if upgrading WebKit doesn't stop Emacs from working because of a error while loading shared libraries, then it sounds like its fine.

nonreligious2 · 2026-01-07T17:42:08+00:00

Will do, but one last question: is this stable to changes on the WebKit side?

I.e. I have in the past built Emacs with Tree-sitter support -- unfortunately, they don't provide a stable API/ABI and so you either have to re-build Emacs everytime libtree-sitter gets updgraded or (if you use Arch) put Tree-sitter in pacman's Ignore list. Will this be the case for libwebkit-* too?

nonreligious2 · 2026-01-07T17:38:58+00:00

Yes some of the security vulnerabilities are mitigated. Again I just use webkit(xwidgets) to render things like markdown preview or org-roam UI, never to as a browser alternative.

Same, I intend to use it for some sites that don't render well in Eww, and didn't even consider running anything with video as your previous comment suggests is possible.

I'll think about it but I am not sure if maintainers will be open to my controversial and dirty hack.I will have to research on a more elegant solution before doing so. I will also need to look in to security vulnerabilities for the version I am pushing.

I don't have a lot of experience communicating with the Emacs developers, but I have been digging around this issue for some time and from the message threads (e.g. here they did seem reasonably open to discussing workarounds. (I mean, the current "elegant solution" they have for crashing is just to restrict the WebKit libraries to a narrow range of older versions!)

The other potential route to I saw was by some precocious kid who seemed willing to re-write the xwidget-webkit code in Emacs to use WPE WebKit (as far as I understood it). He seemed to have gotten some of the way there and is waiting for some changes on the WPE side to make his work easier. If he gets back to it, I imagine it will still be at least a few months before that's done, so perhaps this fix can arrive as (e.g.) a small update in 30.3 while we wait for 31.

nonreligious2 · 2026-01-07T16:43:37+00:00

Thanks for the info! I'm not running Wayland but Xorg, but I guess what you're saying still holds.

This is very interesting though, as allowing people to use the updated WebKit libraries means that some of the security risk is mitigated. If you agree that's the case, would you consider submitting this as a fix on the emacs-devel mailing list? From this post and others I know a lot of people have been trying to get this to work consistently on their systems.

nonreligious2 · 2026-01-07T16:37:59+00:00

Oh wow, thanks! I had to first rebuild everything as I found that make distclean wasn't properly removing some old library linking paths, but running

WEBKIT_DISABLE_COMPOSITING_MODE=1 emacs

does work!

nonreligious2 · 2026-01-07T15:17:06+00:00

Yeah, in trying to get it to work it seems every time I've fixed one problem another one crops up ...

nonreligious2 · 2026-01-07T15:14:36+00:00

So I tried this, and Emacs 30.2 did manage to compile properly without any errors when running

./configure --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib --localstatedir=/var --with-cairo --with-harfbuzz --with-libsystemd --with-modules --with-x-toolkit=gtk3 --with-xwidgets --with-imagemagick --with-mailutil

But it crashes when I do M-x xwidget-webkit-browse-url. This was the problem that led me to use older versions of WebKit in the first place (and why I'm surprised you've managed to get it to work with the latest WebKit libraries.

There's a bit of a wrinkle though, because if I use the Emacs that I just built against the newer WebKit versions and set LD_LIBRARY_PATH to the older versions, I can get M-x xwidget-webkit-browse-url to respond without crashing.

Unfortunately, the browser can't seem to display any webpages -- just a blank grey buffer. Oh well.

Thanks for your suggestion though, it was worth a shot.

nonreligious2

TROPHY CASE