gnu-emacs-sources
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNU ELPA] Ef-Themes version 1.5.0


From: ELPA update
Subject: [GNU ELPA] Ef-Themes version 1.5.0
Date: Fri, 12 Jan 2024 05:04:11 -0500

Version 1.5.0 of package Ef-Themes has just been released in GNU ELPA.
You can now find it in M-x list-packages RET.

Ef-Themes describes itself as:

  ===========================
  Colorful and legible themes
  ===========================

More at https://elpa.gnu.org/packages/ef-themes.html

## Summary:

  # Ef (εὖ) themes for GNU Emacs

  IMAGES HERE: <https://protesilaos.com/emacs/ef-themes-pictures>.

  The `ef-themes` are a collection of light and dark themes for GNU Emacs
  whose goal is to provide colorful ("pretty") yet legible options for
  users who want something with a bit more flair than the `modus-themes`
  (also designed by me).

## Recent NEWS:

                     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                      CHANGE LOG OF THE EF THEMES
                     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


This document contains the release notes for each tagged commit on the
project's main git repository:
<https://git.sr.ht/~protesilaos/ef-themes>.

The newest release is at the top.  For further details, please consult
the manual: <https://protesilaos.com/emacs/ef-themes>.


Version 1.5.0 on 2024-01-11
═══════════════════════════

The new `ef-arbutus' and `ef-rosa' themes
─────────────────────────────────────────

  The `ef-arbutus' theme combines red and green colours against a mild
  light red-pink background. The announcement article contains
  screenshots: <https://protesilaos.com/codelog/2023-12-29-ef-arbutus/>.

  The `ef-rosa' theme has a deep dark red-brown background with a blend
  of magenta and green foregrounds. Check the blog post for pictures:
  <https://protesilaos.com/codelog/2024-01-06-emacs-ef-rosa/>.

  These two new entries bring the total count of the collection to 30.

  Remember that you can set the user option `ef-themes-to-toggle' to two
  themes in the collection and switch between them with the command
  `ef-themes-toggle'. For example:

  ┌────
  │ (setq ef-themes-to-toggle '(ef-arbutus ef-rosa))
  └────

  Otherwise, use the command `ef-themes-load-random' (call it with a
  `C-u' prefix argument to limit the result to either dark or light
  themes, else call it from Lisp, like `(ef-themes-load-random 'dark)').


Stopped the `transient' buffers from trying semantic key colouration
────────────────────────────────────────────────────────────────────

  In a recent version of `transient.el', there is a new user option that
  applies colour-coding to keys (e.g. we see those while using `magit'):
  `transient-semantic-coloring'. This option is enabled by default,
  changing the previous style that was used as a reference for all my
  designs.

  The idea with such colour coding is to indicate when a key continues
  to display the transient, exits with a given action, and the like. For
  our purposes this interface cannot work:

  • We need some place to teach users what each colour means, as there
    are no indicators of any sort to help them (whereas, say, in diff
    buffers we have the plus and minus signs).

  • Not all hues are suitable for highlighting a single character. In
    light themes, for example, green and yellow colours are TERRIBLE
    choices for the requirements of this interface where the key must be
    clearly visible. But when we introduce multiple colours, each with
    their own meaning, we will not be able to avoid those hues.

  • The style of key bindings is not limited to `transient.el'. We find
    them when we invoke `M-x', do `M-x describe-bindings', while using
    the `which-key' package, and many more. If we are to change how
    `transient.el' shows key bindings, then we have to retain the same
    visual cues for other contexts. Otherwise, everything is
    inconsistent.

  • All themes must use the same colours to preserve the colour coding,
    thus removing an important aspect of their presentation.

  • This whole paradigm does not work for themes that are optimised for
    users with colour deficiency, due to the reduced number of suitable
    hues. With deuteranopia, for example, we can only rely on yellow and
    blue: since yellow is not optimal for single key highlights against
    a light backdrop, blue is the only hue that works in such a context.

  The `ef-themes' will not support this user option. All relevant faces
  use the style of standard key bindings.

  Themes can enforce user option values, but I have decided to change
  the faces instead to better communicate my intent. If a user wants
  semantic colouring, they can change the faces to whatever they like.


The `evil' prompts now show the correct colours
───────────────────────────────────────────────

  While using `evil-mode', the ex prompts no longer use their generic …
  …

reply via email to

[Prev in Thread] Current Thread [Next in Thread]