unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "andrés ramírez" <rrandresf@hotmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 61432@debbugs.gnu.org
Subject: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 11 Feb 2023 16:10:23 +0000	[thread overview]
Message-ID: <SJ1PR12MB63633D7BFE129E338E2FFF82A6DF9@SJ1PR12MB6363.namprd12.prod.outlook.com> (raw)
In-Reply-To: <83357cjjp4.fsf@gnu.org>

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	other threads:[~2023-02-11 16:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-11 14:22 bug#61432: 28.2; [PATCH] viper-init: disable face support Andrés Ramírez
2023-02-11 15:38 ` Eli Zaretskii
2023-02-11 16:10   ` andrés ramírez [this message]
2023-02-11 16:30     ` Eli Zaretskii
2023-02-11 18:32       ` andrés ramírez
2023-02-11 18:48         ` Eli Zaretskii
2023-02-12 17:54           ` andrés ramírez
2023-02-12 18:30             ` Eli Zaretskii
2023-02-12 18:53               ` andrés ramírez
2023-02-13 14:00                 ` Robert Pluim
2023-02-13 15:02                   ` andrés ramírez
2023-02-13 17:02                     ` Robert Pluim
2023-02-18 17:01                     ` Eli Zaretskii
2023-02-18 17:01                     ` Eli Zaretskii
     [not found]                       ` <SJ1PR12MB63635DCA5881078AB2D3ED0BA6AB9@SJ1PR12MB6363.namprd12.prod.outlook.com>
2023-02-23 15:09                         ` Robert Pluim
2023-02-23 15:24                           ` andrés ramírez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ1PR12MB63633D7BFE129E338E2FFF82A6DF9@SJ1PR12MB6363.namprd12.prod.outlook.com \
    --to=rrandresf@hotmail.com \
    --cc=61432@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).