4ffy

joined 2 years ago
[–] 4ffy@lemmy.ml 3 points 1 day ago (1 children)

Personally, I flip :defer around by setting use-package-always-defer and :demanding packages that I want loaded at startup.

[–] 4ffy@lemmy.ml 15 points 1 month ago* (last edited 1 month ago)

Cool small features in Emacs 30 that I really like:

  • If you have ever tried to create a custom modeline, you may have discovered that right-aligning elements was a massive pain. Emacs 30 adds a new modeline element mode-line-format-right-align which makes all subsequent elements in mode-line-format right-aligned.
  • When Emacs prompts you about recovering an auto-save file, you can now press = to show a diff between the buffer and auto-save. No more guessing whether you had done anything important.
  • E in dired opens a file with the default program for that file type (via xdg-open or OS equivalent).
30
Emacs 30.1 released (lists.gnu.org)
submitted 1 month ago* (last edited 1 month ago) by 4ffy@lemmy.ml to c/emacs@lemmy.ml
 

Featuring a significantly faster (~8x) JSON parser, native compilation enabled by default, and the official release of the Android port.

Abridged Announcement:

Version 30.1 of Emacs, the extensible text editor, should now be available from your nearest GNU mirror:

https://ftpmirror.gnu.org/emacs/emacs-30.1.tar.xz

https://ftpmirror.gnu.org/emacs/emacs-30.1.tar.gz

For a summary of changes in Emacs 30, see the etc/NEWS file in the tarball; you can view it from Emacs by typing 'C-h n', or by clicking Help->Emacs News from the menu bar.

You can also browse NEWS online using this URL:

https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-30

Windows binaries can be found at https://ftp.gnu.org/gnu/emacs/windows/emacs-30

[–] 4ffy@lemmy.ml 5 points 1 month ago* (last edited 1 month ago) (1 children)

Emacs 30 is a more low-key release compared to heavy hitting features like native compilation in 28 and Tree-sitter in 29. Probably the headline change is replacing the libjansson based JSON parser with a homegrown one that is several times (~8x) faster, which will significantly benefit features like LSP. This will also mark the official release of the Android port, as well as the usual scattershot of improvements across the board. The NEWS file has the full changelog.

 

The first release candidate for Emacs 30.1, the extensible text editor, is now available at:

https://alpha.gnu.org/gnu/emacs/pretest/emacs-30.1-rc1.tar.xz

Please give it as much testing as you can. If no problems are reported, this will become Emacs 30.1 this Sunday.

[–] 4ffy@lemmy.ml 2 points 2 months ago

I found that sound was completely broken in MAME, in the extremely loud kind of way. Not a fun experience. I'd like to look into it more so that I can file a bug report, but I don't yet know where the blame lies.

Every other program that I use seems to work fine so far.

18
submitted 8 months ago* (last edited 8 months ago) by 4ffy@lemmy.ml to c/emacs@lemmy.ml
 

I am excited and relieved to finally announce the release of Magit version 4.0, consisting of 1077 commits, since the last release three years ago. The release notes can be found here.

[–] 4ffy@lemmy.ml 28 points 10 months ago* (last edited 10 months ago)

The reason that Doom is so portable goes beyond Linux and is an artefact of its development. id developed Doom on NeXTSTEP (i.e. Unix) machines and obviously targeted DOS. This is pretty unique among DOS games at the time and required id to write as much code as possible in a platform agnostic way. This means that the main engine does not care about where it is running and the usual DOS hacks are contained to DOS-specific files. In order to port Doom to a new platform, ideally one only needs to rewrite the system-specific implementation files for video, sound, filesystem access, etc., and this mostly holds true today. (These files are prefixed with i_ in the Doom source).

The Linux port is just one of many versions developed at the time. I don't believe that it was commercially released; it was more of a portability test. The reason that the Linux version was chosen for the source release over the DOS version was because it didn't rely on the proprietary DMX sound library that the DOS port used.

 

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.

[–] 4ffy@lemmy.ml 6 points 1 year ago* (last edited 1 year ago)

I don't think that's a good idea. Pretty much all interaction with Emacs is mediated through keybinds. There is no distinction between shortcuts and fundamental behavior. Even ordinary typing is done by having each character on your keyboard bound to self-insert-command. Perhaps there is some way to nuke the global keymap, but then you're left with literally nothing. Besides, this would not prevent various modes from adding their own keys anyway.

You should consider whether Emacs keybinds are actually in the way enough to be bothersome. You can also keymap-global-unset (or keymap-unset) individual bindings that you find problematic. I'd also consider delving into the Spacemacs code to see how they implement their "vi only mode."

[–] 4ffy@lemmy.ml 5 points 2 years ago

Emacs's regular clipboard is the "kill ring" which also allows you to retrieve any previously cut/copied text. It also has "registers" where you can store and retrieve snippets of text, which can be considered clipboards when used for this purpose. Registers can be referenced by any character you can type on your keyboard, including control characters like ^D.

This totals... a lot of clipboards.

[–] 4ffy@lemmy.ml 16 points 2 years ago (7 children)

My heart sank upon reading the word "electron" and rose again on the very next paragraph. I'm looking forward to seeing it in action.

[–] 4ffy@lemmy.ml 5 points 2 years ago* (last edited 2 years ago) (1 children)

I think that this is above all else the reason that I use Arch. Arch Linux makes creating packages trivial, basically just wrapping build instructions into a shell script template. Arch handles the rest. The build systems for deb or rpm packages don't come close, and good luck rolling your own flatpak.

This allows me to use pacman for everything outside of my home directory. Pacman is practically the central feature of my computer, and it's wonderful. I'm sure those Nix people can relate, though I guess my method is a bit less robust.

[–] 4ffy@lemmy.ml 5 points 2 years ago

Xremap, despite the name, supports both X and Wayland, and can be used to move modifier keys around. Configuration is done with YAML but is otherwise pretty easy. I personally use it for full Emacs keybind emulation.

[–] 4ffy@lemmy.ml 177 points 2 years ago* (last edited 2 years ago) (29 children)

This might be the first time I've ever seen something productive happen in the Phoronix forums. I love that place. Go to any topic with more than about a dozen posts and it's almost guaranteed to be a flame war. Genuinely one of the funniest places on the Internet.

Check out this one. It took like three posts!

[–] 4ffy@lemmy.ml 6 points 2 years ago

I have done almost the opposite: moving as much configuration as I can into use-package statements, even for built-in features like dired. You can (use-package feature-name) or even (use-package emacs) in order to customize the basics. use-package just provides much better organization than any schema that I have ever been able to come up with on my own.

view more: next ›