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

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

bug#61432: 28.2; [PATCH] viper-init: disable face support


From: andrés ramírez
Subject: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 11 Feb 2023 16:10:23 +0000

Hi. Eli.

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


[...]


    Eli> Can't you have the same effect if you customize the faces 
viper-minibuffer-emacs-face and
    Eli> viper-minibuffer-vi-face to look the same?

I have tried some modifications. like this one.
--8<---------------cut here---------------start------------->8---
(when (viper-has-face-support-p)
  (set-face-foreground 'viper-minibuffer-emacs "white") 
  (set-face-background 'viper-minibuffer-emacs "black"))
--8<---------------cut here---------------end--------------->8---

But We need to remember than viper is a very old package. Perhaps emacs
21 or before. At that time viper coder's thought modifying always the
faces for reflecting the viper state and also the viper emulation level
(something like level 1 to level 5. It was according to the colors). The
only thing they missed at that time was a variable for leaving
everything as it was before. The same behaviour You get when running
'emacs -Q'.

My issues with viper default behaviour are:
Most of my time is spend on emacs within xterm. But from times to times
I open PDF files with an emacs-lucid-frame at that time when running
'M-x' and showing the prompt faces have changed.

Also when I move to an fb-console and when doing 'M-x' (and again
inspecting the prompt or writting the command) sometimes what I type is
not noticed cos of the faces. So I need to M-x delete-frame and
'TERM=screen emacsclient -c -t' that behaviour is different than the one
You get when not using viper. So I have been thinking why the original
viper coder's have not created a variable to inhibit the faces
modifications.

For solving the issue when being on 'insert-mode' or not being on
'insert-mode' I use a trick used by the evil-mode users changing the
color of the modeline. So the main issue why the original viper coder's
did that have been avoided (having a visual help for knowing in which
state viper is currently in).

And Yes perhaps customization of faces could work. But when You need to do it
on several machines. So the simple solution would be having a variable
to inhibit that behaviour.

Finding the right face to modify would take time also. 

Hope that clarifies the use of this variable.

And the most of vipers users are not going to notice that variable.

Best Regards





reply via email to

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