alphapapa / prism.el Goto Github PK

View Code? Open in Web Editor NEW

274.0 8.0 4.0 6.32 MB

Disperse Lisp forms (and other languages) into a spectrum of colors by depth

License: GNU General Public License v3.0

Emacs Lisp 100.00%

emacs syntax-highlighting

prism.el's People

Contributors

Stargazers

Watchers

Forkers

emacsmirror majdi1401 overdr0ne pedrormjunior

prism.el's Issues

Use more builtins for examples

A lot of the example color configurations use solarized-with-color-variables, but that isn't a builtin and it isn't obvious where it comes from. It took me a while to figure out that a list of strings is required.

It might be a good idea to include some default configurations.

Emacs loops/segfaults with certain buffer contents in certain major modes

Hi all,

edit: Original title was "Prism mode causes emacs to freeze/lock up when typing double-quote characters on ARM macbooks"

Title says it all. I am not sure how to debug this further, because emacs hangs entirely and the only way to recover is to force-quit the application. I suppose one could use gdb or another debugger but I am not an expert in that sort of debugging and wouldn't know where to start.

Steps to reproduce:

start emacs with blank config on M2 Macbook pro
Install Prism from MELPA (version "20230416.626" is what package.el pulled down for me)

(use-package prism
    :commands prism-mode
    :init
    (add-hook 'prog-mode-hook #'prism-mode))

Open a .lisp file and attempt to type the following: (#P"") which is a Common Lisp pathname literal. I have also seen this when editing HTML and attempting to type <html lang="en">

Running `prism-mode` before `prism-set-faces` wipes existing colors

Not all of the existing colors, but some of them. It messages Please set ‘prism’ colors with ‘prism-set-faces’.

Infinite loop in prism-match

I've been using prism on a previous version very successfully, mainly to highlight clojure code.
I recently upgraded emacs to 29.1 and prism to the latest version, but now I get the following error quite frequently:

Error during redisplay: (jit-lock-function 190939) signaled (error "prism: Infinite loop detected in ‘prism-match’ (buffer:# point:191160). Please report this bug")

( same color

Hi,

I absolutely love your package! It makes Lisp so much more readable!
Is there a possibiliy to have the surrounding paren in the same color?

eg.

(defun new-function (new-parameter) (+ new-parameter 1))

the first ( is a different color to defun.

This confuses me.

Can I set prism to have the same color?

Thank you for your attention!
Best wishes!

Marc

Feature request - an option to make closing delimiters more dim?

Parinfer (without prism or other rainbow modes) colorizes closing brackets at the end of line more dim than opening brackets.

If there is such an option in prism, then i could not find how to achieve this, and asking to help with it. If there is no such option, then I would be glad if such an option would be added!

Feature: paren-face compatibility

Hello,

Thank you for prism.

Is it possible to make it compatible with paren-face? I'm guessing that means prism not including the parentheses for fontification so that those from paren-face aren't overridden, but I don't know how much work that involves.

I'm using paren-face to hide parentheses in javascript code, which makes it more pleasant to work with :)

Thanks again
Berkan

prefix-string-p error in prism-set-colors

Hello,

by adding the following --remove clause in the following line:

prism.el/prism.el

Line 735 in f7b8da4

(--remove (string-prefix-p "unspecified-"))

it causes to crash with an wrong number of arguments exception. I replaced the previous line with

(--remove (string-prefix-p "unspecified-" (format "%S" it)))

and it seems to work but I don't really know if that is what you wanted to do.

PS: the use of format is because there are symbols and raw color code as strings.

prism-save-colors called after prism-randomize-colors reverts to the default pulled from prism-set-colors

I'm a novice with emacs and lisp, so pardon me in advance for my ignorance. As mentioned in the readme, I called prism-randomize-colors and then prism-save-colors, but instead of saving the current color scheme, it resets the color scheme to the result of calling prism-set-colors.

I'm trying to figure out why this is happening, and it appears that in prism-set-colors,

...
(set-vars prism-faces (faces colors)
          prism-faces-strings (faces colors "strings" strings-fn)
          prism-faces-comments (faces colors "comments" comments-fn)
          prism-faces-parens (faces colors "parens" parens-fn)))
(when (and save (not local))
;; Save arguments for later saving as customized variables,
;; including the unmodified (but shuffled) colors.
(setf prism-colors colors
    prism-desaturations desaturations
    prism-lightens lightens
    prism-num-faces num
    prism-comments-fn comments-fn
    prism-strings-fn strings-fn
    prism-parens-fn parens-fn)
(prism-save-colors)))))

that when the save parameter isn't true, prism-set-colors doesn't set prism-color, prism-desaturations, etc., but, prism-save-colors assumes those variables are set:

(cl-letf (((symbol-function 'custom-save-all)
             (symbol-function 'ignore)))
    ;; Avoid saving the file for each variable, which is very slow.
    ;; Save it once at the end.
    (dolist (var (list 'prism-desaturations 'prism-lightens 'prism-num-faces
                       'prism-comments-fn 'prism-strings-fn))
      (customize-save-variable var (symbol-value var))))
  (customize-save-variable 'prism-colors prism-colors))

lag with common lisp

Occasionally I delete one parentheses too many, and suddenly the whole document is part of a function. When this happens, emacs becomes unresponsive for several seconds, due to the fact (I guess) that the colors need to be re-calculated for the whole document.

(prism-expand-list) is very broken

For example:

(prism-expand-list 4 '(1 2 3)) ;; => (1 1 2 2 3 3 3)

The problem is in how repeat-n is determined. Here's my proposed solution, but I'm not sure if it's exactly what you want, because it repeats the last element potentially many times, while the documentation says it will be repeated only one time.

(defun prism-expand-list (new-length list)
  "Return LIST expanded to NEW-LENGTH.
Each element of LIST is repeated an equal number of times, except
that the last element may be repeated an extra time when
necessary."
  (let* ((length (length list))
         (_longer-p (or (> new-length length)
                        (user-error "NEW-LENGTH must be longer than LIST")))
         (repeat-n (/ new-length length))
         (final-element-repeat-n (mod new-length length))
	 (final-elements (and (< 0 final-element-repeat-n)
			      (-repeat final-element-repeat-n (-last-item list))))
         (new-list (->> list
                        (--map (-repeat repeat-n it))
                        (-flatten))))
    (if final-elements
        (apply #'-snoc new-list final-elements)
      new-list)))

Error: "Invalid search bound (wrong side of point)"

Hey, I've been having a great time with the package. Thanks for your great work!
I've been noticing some jit-lock errors and I narrowed it down to prism.

My setup is GNU Emacs 29.0.60, with Doom emacs, and prism v0.3.2

It's only with one emacs lisp file, and it's some weird combination of length of the file (like 600 lines) and a comment line. Bisecting the file itself hasn't gotten much info, but it seems like it only occurs when there's at least a full window of content and something to do with this starting section of the file:

;;; -*- lexical-binding: t; -*-

;; Some functionality uses this to identify you, e.g. GPG configuration, email
;; clients, file templates and snippets.
(setq user-full-name    "Ketan Kanishka"
      user-mail-address "[email protected]")

;;; Utility functions
;; Due to name visibility issues, this section needs to be at the top.

;; 12-hour time -> 24-hour time
(defun pm (hour) (mod (+ hour 12) 24))
(defun am (hour) hour)

(defun my/load-doom-theme (&optional theme)
  "Load the currently set `doom-theme'. If THEME is provided, set it to `doom-theme' first."
  (setq doom-theme (or theme doom-theme))
  (load-theme doom-theme t nil))

(defun silently (fn)
  "Run FN without showing any messages in echo area."
  (let ((inhibit-message t))
    (funcall fn)))

and especially this line - "Some functionality uses this to identify you, e.g. GPG configuration, email" seems to be causing issues.

Since this error was thrown by jit-lock-mode, I wasn't able to debug it very effectively.
However, I've narrowed it down to this section:

                                 (when (re-search-forward (rx (or (syntax string-quote)
                                                                  (syntax comment-start)))
                                                          (or (ignore-errors
                                                                (scan-lists (point) 1 1))
                                                              limit)
                                                          t)

Specifically, it seems like re-search-forward, even when its noerror argument is true, raises an error when the current point is less than the bound argument.
After modifying the section to:

                                 when (condition-case err
                                           (let ((regex (rx (or (syntax string-quote)
                                                                (syntax comment-start))))
                                                 (my-limit (or (ignore-errors
                                                                 (scan-lists (point) 1 1))
                                                               limit)))
                                             (message
                                              "calling (re-search-forward :regex %S :limit %S 'noerror) [current-point: %S, limit: %S]"
                                              regex my-limit (point) limit)
                                             (re-search-forward regex my-limit t))
                                         (error
                                          (message "caught error! %S" err)
                                          nil))

I get these logs:

...
calling (re-search-forward :regex "\\s\"\\|\\s<" :limit 1551 ’noerror) [current-point: 1492, limit: 1552]
calling (re-search-forward :regex "\\s\"\\|\\s<" :limit 1551 ’noerror) [current-point: 1550, limit: 1552]
calling (re-search-forward :regex "\\s\"\\|\\s<" :limit 1552 ’noerror) [current-point: 1553, limit: 1552]
caught error! (error "Invalid search bound (wrong side of point)")

So I think wrapping this (and maybe also the other) re-search-forward calls with ignore-errors will be at least a good band-aid fix. I'm not sure about the true cause of this though.

Best
Ketan

Error during redisplay: (jit-lock-function 3001) signaled (error "prism: Infinite loop detected in ‘prism-match’

Observed with revision 169b49a (v0.3.2) on Emacs 29.3

Prism suddenly gets deactivated when scrolling the buffer down a bit, when the attached file is opened in the buffer. The full error message is:

Error during redisplay: (jit-lock-function 3001) signaled (error "prism: Infinite loop detected in ‘prism-match’ (buffer:#<buffer xfiltertree-html.lisp> point:3267).  Please report this bug")

A gzipped copy of the file triggering this issue is available here:

xfiltertree-html.lisp.gz

prism-whitespace-mode: "End of buffer" when used with swiper, org-export, etc.

Prism seems to have a weird interaction with Swiper at least in prism-whitespace-mode: when Swiper is invoked with Prism enabled, sometimes Emacs will just beep and show "End of buffer" in the minibuffer. Trying again will usually work. With Prism disabled, Swiper always works.

On Emacs 27.0.90, I can repeat it like this:

Start emacs -Q and evaluate:

(package-initialize)
(require 'prism)
(require 'swiper)

Open a file in python-mode.
(2b. Try M-x swiper, note that it works.)
Invoke M-x prism-whitespace-mode.
Try M-x swiper, note that it dies with "End of buffer".
(4b. Try M-x swiper again, note that it works most of the time.)

I'm not sure if this is a bug in Prism, Swiper or Emacs. The End of buffer error doesn't seem to trigger debug-on-error. Any ideas on debugging this?

Possible to use for XML

How easy would it be to provide a prism mode for XML.

It does not need to fully understand XML - but sufficient to identify elements and attributes

I am finding prism much more useful than normal font-lock as it emphasises the structure not different types.

Is there a way to escape the prism face in certain cases

I'd like my docstrings always to be a certain color.

They are usually given font-lock-doc-face but when prism is running, they become prism-level-1-strings.

Is there a way to escape the prism coloring for a specific face?

Background color not always defined on terminal

Like you already experienced (and fixed) with ement.el, the same thing could happen in prism.el.

There are a few instances of (face-attribute 'default :background) which may be "unspecified-bg", which is a color that cannot be blended.

This results in error messages at startup when running emacs -nw in some terminals:

prism-blend: Wrong type argument: number-or-marker-p, nil

Samples of Modus themes with prism.el

Hello again! This is in response to this reddit thread.

I have been experimenting with various styles and settled on what I feel is a good starting point. Screenshots below. I only have Elisp code here, so this has influenced my decision. Here is the configuration I used:

(use-package prism
  :straight (:host github :repo "alphapapa/prism.el" :branch "master")
  :config
  (setq prism-comments nil) ; non-nil distorts colours

  (prism-set-colors
    :desaturations '(0) ; may lower the contrast ratio
    :lightens '(0) ; same
    :colors (list ; NOTE: I plan to add a "with-color-variables"
             (modus-themes-color 'fg-main)
             (modus-themes-color 'blue-faint)
             (modus-themes-color 'magenta)
             (modus-themes-color 'magenta-alt-other)
             (modus-themes-color 'cyan-alt-other)
             (modus-themes-color 'fg-special-cold)
             (modus-themes-color 'blue-alt)
             (modus-themes-color 'magenta-faint)
             (modus-themes-color 'cyan)
             (modus-themes-color 'fg-main)
             (modus-themes-color 'green-faint)
             (modus-themes-color 'red-alt-faint)
             (modus-themes-color 'blue-alt-faint)
             (modus-themes-color 'fg-special-warm)
             (modus-themes-color 'cyan-alt)
             (modus-themes-color 'blue))))

Screenshots

The sequence is the default theme followed by its prism-styled variant. Note that I do have some options for the themes turned on as I think they work well in this case (just some bold and italics).

Click to enlarge.

Modus Operandi

Modus Vivendi

Your thoughts?

What do you think? If something is amiss, how would you like to review it?

My plan is to first come up with some elegant way for users to get colours from the themes and then I would like to add a section in the manual for users who would like to set up prism.el with the themes.

Update screenshots

Collecting some possibilities for new screenshots:

Posted at #18 (comment):

whitespace-mode space-mark characters sometimes get highlighted incorrectly

When using whitespace-mode, with space-mark added to whitespace-style, sometimes the characters marking a space get highlighted in the same color as the proceeding character instead of using the foreground color set by the whitespace-space face.

Doom Emacs config

Doom Emacs uses rainbow-delimiters-mode by default. For ages, I was using it together with prism without realizing. I'm fairly experienced with initfile stuff but missed it anyway, which shows how easy it may be to miss. A hint in the README may be appropriate, or even a message printed when prism-mode turns on.

Now my use-package declaration has an extensive remove-hook! which you may also find useful to put in README. Up to you.

(use-package prism
  :hook (prog-mode . prism-mode)
  :config
  (add-hook 'doom-load-theme-hook #'prism-set-colors)
  (remove-hook! (racket-mode
                 scheme-mode
                 sh-mode
                 clojure-mode
                 purescript-mode
                 rjsx-mode
                 typescript-mode
                 typescript-tsx-mode
                 TeX-update-style
                 zig
                 java-mode
                 c-mode-common
                 csharp-mode
                 lisp-mode)
    #'rainbow-delimiters-mode))

Since these hooks may change, a futureproof alternative is (fset 'rainbow-delimiters-mode #'ignore). Unfortunately simply disabling it with (package! rainbow-delimiters :ignore t) is not supported; it's considered part of Doom's core.

EDIT: I guess an even better alternative would be if prism-mode toggles rainbow-delimiters-mode. Any way the user can make it do that?

Unfortunately this is not so easy as the following advice will not run sufficiently late for Doom (if prism-mode is on prog-mode-hook)... but at that point it's more a Doom bug.

(advice-add #'prism-mode :after
              (defun my-turn-off-rainbow-delimiters (&rest _args)
                (rainbow-delimiters-mode 0)))

Color scheme vanishes

After certain events (not sure exactly what causes it - usually it is after some buffer is opened; i'll post more if i'll see any more patterns) color scheme in prism-mode vanishes and it starts to color everything in gray

Using prism-set-colors (for example, in a way of recompiling part of .emacs file) does not change anything.
However, prism-randomize-colors still work and produce new random color scheme. The only way i found to return original (specified in .emacs) color scheme that i found is to restart emacs.

Can I set :background instead of :foreground?

I have significant syntax highlighting on the foreground, the background on the other hand is largely empty, so I'd really prefer prism color that instead if possible. Is there support for that?

"End of buffer" message when running consult-line

I don't have the full steps to reproduce, because on emacs -Q it doesn't seem to happen, but for me when I have (setq prism-comments nil) and run the command consult-line in an elisp file, I get an "End of buffer" message and the prompt dies before it can start. It works after I re-run consult-line once or twice.

I've tried to use toggle-debug-on-quit and type C-g right after it happens, but Emacs doesn't seem to think there's anything to debug.

PS: consult-line is similar to swiper or the old helm-swoop.

If you want more info let me know.

Support clojure form comments

In Clojure we can comment out an entire form with #_:

however prism-mode's syntax parsing doesn't support this:

In both cases the font family is coming from font-lock-comment-face, but with prism-mode the form comment is colorized too.