Emacs

I was working with NPM package.json files a lot lately and I often found myself saving them in an unparseable state. json-ts-mode highlights syntax errors in yellow but it wasn't enough.

I didn't want to use flymake-eslint becuase it requires having the jsonlint binary in the PATH and I just wanted a simple Lisp solution.

The code tries to parse the current buffer on save using Emacs' built-in json-parse-string and moves the cursor to the location of the parsing error if it fails.

The below code naively assumes that the saved buffer is always the current buffer, which may very well not be the case (e.g. (save-some-buffers)).

It also probably won't save JSON5 files which have // comments inside because json-parse-string won't handle that.

(defun rtz/json-parse-pre ()
    (interactive)
    (if (eq major-mode 'json-ts-mode)
        (condition-case err
            (progn 
  	    (json-parse-string
  	     (buffer-substring-no-properties
  	      (point-min)
  	      (point-max)))
              nil)
          (json-parse-error
           (goto-char (nth 3 err)) (error err)))))

  (setq write-file-functions '(rtz/json-parse-pre))

A new backend for Gnus which I have been developing for a while was merged today into Emacs - you can now fetch and read Atom feeds right from Gnus.

The backend is extremely customizable, allowing you to swap any parsing function with a custom implementation (I use this feature to display youtube video descriptions from youtube channel Atom feeds, which are otherwise not picked up by the backend since they don't appear in a standard location, and also to be able to supply a youtube channel name instead of its web address to add it; see https://git.sr.ht/~dsemy/emacs-config/tree/master/item/init.d/init-programs.el#L90 if you're curious).

This is a result of this backend being actually made of two backends - an "abstract" backend (nnfeed) which handles feed data storage, talking to Gnus, and defining server variables which will hold parsing functions, and another (nnatom) which actually provides these parsing functions. This also means it is very simple to define new "feed-like" backends, since you don't need to implement data storage or the Gnus backend interface, only some parsing functions (their requirements are also designed to be fairly generic, so it would be easy to handle various types of feeds. nnfeed itself makes very little assumptions about the feed type).

It should be available with Emacs 30 (or right now from Git).

For sure, I’m heading straight to Emacs hell for this.

Apparently, there are a lot of Emacs purists in the world who, over the years, have learned to type such complex key sequences as C-x r t M-. C-c C-p fluently. I'm not one of them. And when I tried to figure out how to customize it for myself, the web forums were full of comments saying it wasn't a good idea.

In vim terminal I use C-[ for ESC to escape from insert mode a lot, but didn't know C-[ works in GUI version of Emacs until recently. Since Meta can be replaced with ESC, we can enter C-M-s, for example, with C-[ C-s.

As a long time Vimmer, I have recently started using Emacs out of sheer curiosity. I chose Doom Emacs as it has evil-mode enabled by default, and do not want to dive down the rabbit hole of configuring the editor from scratch (at least, not yet!).

After installing and enabling libvterm in Emacs, I am having a frustrating experience. I configured ZSH shell to use vi-mode keybindings which interferes with evil-mode whenever I press Esc or C-[.

After having searched a little, I came across a workaround to disable evil-mode when in vterm. But it is still not a smooth experience. For instance, when switching between buffers (C-w C-w).

I would like to know how others in the community tackled this problem. Is there a better solution to this problem? Or have you made peace with the aforementioned workaround? Or have you stopped using vterm entirely?

This release brings a host of user-facing refinements to an already stable base, as well as some impressive new features. There is a lot to cover, so take your time reading these notes.

Special thanks to Jean-Philippe Gagné Guay for the numerous refinements to parts of the code base. Some of these are not directly visible to users, but are critical regardless. In the interest of brevity, I will not be covering the most technical parts here. I mention Jean-Philippe’s contributions at the outset for this reason. Though the Git commit log is there for interested parties to study things further.

cross-posted from: https://lemm.ee/post/27699104

From the NEWS file: Emacs 29.3 is an emergency bugfix release intended to fix several security vulnerabilities described below.

• Arbitrary Lisp code is no longer evaluated as part of turning on Org mode. This is for security reasons, to avoid evaluating malicious Lisp code.

• New buffer-local variable 'untrusted-content'. When this is non-nil, Lisp programs should treat buffer contents with extra caution.

• Gnus now treats inline MIME contents as untrusted. To get back previous insecure behavior, 'untrusted-content' should be reset to nil in the buffer.

• LaTeX preview is now by default disabled for email attachments. To get back previous insecure behavior, set the variable 'org--latex-preview-when-risky' to a non-nil value.

• Org mode now considers contents of remote files to be untrusted. Remote files are recognized by calling 'file-remote-p'.

this update

• uses dropdown menu widgets everywhere, and
• fully implements comment folding widgets.

the readme is also updated to explain these features.

holler if you run into any bugs.

I'm still torn on nvim vs Emacs. I have my Emacs config readt and I'm working on finishing my nvim config, but I'm still switching back and forth and can't decide. I thought Emacs' other features would be enough to make me stay but frankly I find myself preferring non-emacs alternatives like cmus over emms and I don't use RSS feeds enough to justify elfeed. I also prefer kitty in zsh over term, vterm and eshell. As an editor, however currently Emacs is superior, but we'll see if that changes when my neovim config is complete. Currently, the only advantage of nvim over Emacs when it comes to being my IDE, is faster load times. I think Neovim has faster load time, and Emacs has org-mode as features that stand out, where Emacs startup, even with the daemon/server, is slower, and orgmode support for neovim is inferior. The thing is, I haven't been able to really get into org-mode and I haven't even finished configuring neovim. For the time being, I'll stick to my approach of switching back and forth, but we'll see where things go in the future.

In terms of any other text editing features, I can't say either reigns supreme, as they're both really good. They have the features one would expect and theming is just amazing!

But I think my choice of editor will come down to org-mode or markdown. Markdown is simpler for me, as I'm more familiar with it and I use it all the time for my uni work, as I'm required to. Org-mode is more powerful and featured, but is also more difficult to learn because of how different it is. My other problem is that I just couldn't get into it. So currently, I'm on markdown, because that way, my mind doesn't have to switch back and forth, which is confusing.

If markdown support in Emacs was as good as Orgmode support (meaning things like making titles larger in-document, essentially giving me a live preview in the document itself as I'm writing it, was available in Emacs), the coice would be obvious. Currently, I use Ghostwriter for Markdown and it feels good, but it feels useless, as in, it's another program for just this one thing (markdown), that's a usecase under another usecase umbrella (text editing). Alternatively, if Emacs supported live markdown preview within itself to the level of ghostwriter (and no, the browser preview doesn't count, it's not good enough to have to have a broswer window opened alongside Emacs) so if I can get Ghostwriter-level of polish for Markdown and specifically Markdown live preview in Emacs, or Orgmode-level of support, where the live preview happens in the document itself as I'm writing it, I would likely switch to Emacs. But currently, I'm quite torn.

Is the above possible? And if so, can you point me in the right direction of how to achieve it? Thanks.

Edit: a massive thank you rhabarba for helping me get markdown set up on Emacs! After doing that, and adding a few other quality-of-life features, I'd say my Emacs configuration feels quite complete.

Hey gang!

So I've used gopass for awhile now, and Emacs for longer.

I was wondering if any of you here interact with gopass via Emacs with auth-source or something similar.

The main reason I ask is because I'm wanting to finally use Emacs for other things, such as an IRC client and making more use of Magit, and even writing with 750words.

A lot of my passwords are stored with gopass, and the structure isn't always the same for stores. For instance:

| Forums
|-- Gentoo
|-- Some other forum
|
| Email Host
|--  [email protected]
|---- password
|---- recovery codes
|
| Employer Name
|-- Some program we use at work
|---- [email protected]
|
| Some app
|-- My User Name

Maybe this structure for a password store is a no-no, though it's not a big deal to move things around.

Any tips? I've seen auth-source-gopass, but that doesn't provide any interaction with selection of passwords or creation of passwords, I think.

I've look at that mentioned library some and writing an auth-source backend doesn't seem too involved, but maybe I don't necessarily have to with auth-source.

EDIT:

A potential configuration that others might use:

(require 'consult)
(require 'auth-source-pass)

(use-package pass
  :requires password-store
  :preface
  (defvar consult:pass-source
    `(:name "Passwords"
      :narrow ?<                     ;; maybe you want something else for narrow?
      :face pass-mode-directory-face ;; maybe you want to use a different face?
      :category pass
      :enabled
      ,(lambda ()
         (auth-source-pass-file-name-p auth-source-pass-filename))
      :items ,#'password-store-list)
    "Consult source for passwords with (go)pass.")

  (defun consult:pass (arg pass)
    "Stolen from Doom Emacs.
https://github.com/doomemacs/doomemacs/blob/master/modules/tools/pass/autoload/consult.el"
    (interactive
     (list current-prefix-arg
           (progn
             (require 'consult)
             (consult--read consult:pass-source
                            :prompt "(Go)Pass: "
                            :sort nil
                            :require-match t
                            :category 'pass))))
    (funcall (if arg
                 #'password-store-url
               #'password-store-copy)
             pass))
  :custom
  (password-store-executable (executable-find "gopass"))
  (auth-source-pass-filename
   (or (getenv "PASSWORD_STORE_DIR")
       (expand-file-name "~/.local/share/gopass/stores/root")))
  :config
  (auth-source-pass-enable))

added lots of stuff in this update, some of which may be a little green still.

• commands to navigate comment trees
  • up to top-level comment
  • prev/next same-level comment
• various commands to selectively fold (hide) comment branches
  • un/fold current comment
  • un/fold current comment + its children
  • un/fold current comment's entire branch
  • un/fold entire buffer
• added more sorting/listing drop-down widgets to make it easier to see what sorting is in effect (and to change sorting by mouse)
• fix tab navigation to (hopefully) all links everywhere
• make default sorting/listing in views better match the web UI
• fix sorting options in user view
• various other fixes

one thing to note is that this release switches the S/s bindings, for consistency.

I merged a new source for EMMS yesterday (a backend providing commands like 'emms-add-file' and 'emms-play-file') which reads a beets (https://beets.io) library database using Emacs' built-in SQLite support (beets is a command line program which manages your music library and automatically performs operations like tagging and converting music files; it keeps an SQLite database of tracks).

Since beets library databases already contain metadata about the tracks, this source skips running the default track info initialization function (other track init functions do run though).

On my PC (which is fairly powerful), loading ~1500 tracks (my personal library) into the EMMS cache (including their metadata) takes few minutes, during which Emacs is very annoying to use; this process takes under a second using the beets source.

Another nice feature is the ability to interactively filter chosen tracks (by passing a prefix argument to any beets source command). The filtering is done in two steps:

1. Choose metadata types to filter by (actually columns in the beets database).

2. For each metadata type (column) chosen, choose between unique values which appear in that column and which don't correspond only to tracks which have already been filtered by a previous choice.

Both steps use 'completing-read-multiple' (and only allow valid choices).

The source should require no configuration (only tested on Linux though) provided you haven't changed the location of the beets library database, and the source commands are autoloaded.

The source should be available in EMMS 19 (the next version, which should be released soon).

• implement overview (mixed comments + posts) for user views
• implement unified inbox (mixed replies, mentions, private messages)
• add communities moderated to user view
• add sort/listing widgets to browse communities for nice sorting feedback
• add search current user command
• add search current community command

I thought it might be nice to add drop-down sort/listing widgets to the top of all feed-based views, roughly similar to the web client, but it seems that the emacs widget library doesn't allow placing multiple menu widgets on the same line. :/

EDIT: turns out it's possible, so i'll add them to the main views.

Some Emacs Lisp to help me populate random information into my Campaign Status document. This delves into the org-element-map function and some querying of information to pick the right elements.

additions:

• pagination for inbox views (replies, mentions, pms)
• create communities (basic, no images yet)
• delete communities (completing)
• fix view-user-at-point
• display community's restricted/nsfw status
• fix next/prev on user search results

I recently updated lem.el to 0.12.

The release makes encrypted tokens optional for easier use. If you update and find you can't load lem.el, delete ~/.emacs.d/lem.plstore and log in again. If you want your auth tokens to be encrypted, set lem-encrypt-auth-tokens to non-nil. You'll also need to set plstore-encrypt-to to a GPG key of yours.

Hi everyone! I'm looking for help and learning opportunity :) I am improving my emacs configuration following some tutorials, and right now I'm missing something important to understand how keybindings in emacs work. I've read Mickey Petersen blog post about this subject (https://www.masteringemacs.org/article/mastering-key-bindings-emacs), but I can't apply it to my situation.

What I want to achieve

I use general, use-package and evil. I want to use evil keybindings in undo-tree-visualizer-mode to jump between nodes and branches using "j", "k", "h", "l" keys in normal state.

My evil and general config

(use-package evil
  :init      ;; tweak evil's configuration before loading it
  (setq evil-want-integration t) ;; This is optional since it's already set to t by default.
  (setq evil-want-keybinding nil)
  (setq evil-vsplit-window-right t)
  (setq evil-split-window-below t)
  (setq evil-want-C-u-scroll t)
  (setq evil-want-C-i-jump nil)
  (setq evil-respect-visual-line-mode t)
  (setq evil-undo-system 'undo-tree)
  (evil-mode))

(use-package general
  :diminish
  :config
  (general-evil-setup)

What I have tried

1. Defining keybindings with evil

(with-eval-after-load 'evil-maps
(evil-define-key 'normal undo-tree-visualizer-mode-map (kbd "k") 'undo-tree-visulize-undo)
(evil-define-key 'normal undo-tree-visualizer-mode-map (kbd "j") 'undo-tree-visulize-redo)
(evil-define-key 'normal undo-tree-visualizer-mode-map (kbd "h") 'undo-tree-visulize-switch-branch-left)
(evil-define-key 'normal undo-tree-visualizer-mode-map (kbd "l")

2. use-package :bind

(use-package undo-tree
  :bind(:map undo-tree-visualizer-mode-map
             ("k" . undo-tree-visualize-undo)
             ("j" . undo-tree-visualize-redo)
             ("h" . undo-tree-visualize-switch-branch-left)
             ("l" . undo-tree-visualize-switch-branch-right))
  :init
  (global-undo-tree-mode 1))

3. hook-mode

(use-package undo-tree     
  :init     (global-undo-tree-mode 1)     
  :config     
  (add-hook 'udno-tree-visualizer-hook
              (lambda()
              (add-to-list 'evil-previous-visual-line 'undo-tree-visualize-redo))))

I don't get any errors with these solutions, but still it doesn't remap keys as I wish to.

What I am missing here? What is the best approach to rebind these keys to undo-tree-visualizer-mode-map?

Will greatly appreciate help in understanding what I am doing wrong :)