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

Previous Next

Package: emacs;

Reported by: Andrés Ramírez <rrandresf <at> hotmail.com>

Date: Sat, 11 Feb 2023 14:28:02 UTC

Severity: normal

Tags: patch

Found in version 28.2

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61432 in the body.
You can then email your comments to 61432 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sat, 11 Feb 2023 14:28:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andrés Ramírez <rrandresf <at> hotmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 11 Feb 2023 14:28:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrés Ramírez <rrandresf <at> hotmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 11 Feb 2023 14:22:44 +0000
[Message part 1 (text/plain, inline)]
Hi.

The following patch disables face support for not changing the modeline
fonts when using viper.

[patch-viper-init-optionally-disable-face-support.patch (text/x-patch, inline)]
diff -u /tmp/viper-init.el.bak /tmp/viper-init.el
--- /tmp/viper-init.el.bak	2023-02-10 12:25:52.388368619 +0000
+++ /tmp/viper-init.el	2023-02-10 12:30:11.118394615 +0000
@@ -78,11 +78,16 @@
   :type 'boolean
   :group 'viper-highlighting)
 
+(defvar viper-disable-face-support nil
+  "disable the face support for not changing faces in the modeline. And stay as emacs -Q.")
+
 (defun viper-has-face-support-p ()
+  (if (and (boundp 'viper-disable-face-support) viper-disable-face-support)
+      nil
   (cond ((viper-window-display-p))
 	(viper-force-faces)
 	((viper-color-display-p))
-	(t (memq window-system '(pc)))))
+	(t (memq window-system '(pc))))))
 
 
 ;;; Macros

Diff finished.  Fri Feb 10 12:31:17 2023
[Message part 3 (text/plain, inline)]
Best Regards

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sat, 11 Feb 2023 15:40:01 GMT) Full text and rfc822 format available.

Message #8 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrés Ramírez <rrandresf <at> hotmail.com>
Cc: 61432 <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 11 Feb 2023 17:38:47 +0200
> From: Andrés Ramírez <rrandresf <at> hotmail.com>
> Date: Sat, 11 Feb 2023 14:22:44 +0000
> 
> The following patch disables face support for not changing the modeline
> fonts when using viper.
> 
> diff -u /tmp/viper-init.el.bak /tmp/viper-init.el
> --- /tmp/viper-init.el.bak	2023-02-10 12:25:52.388368619 +0000
> +++ /tmp/viper-init.el	2023-02-10 12:30:11.118394615 +0000
> @@ -78,11 +78,16 @@
>    :type 'boolean
>    :group 'viper-highlighting)
>  
> +(defvar viper-disable-face-support nil
> +  "disable the face support for not changing faces in the modeline. And stay as emacs -Q.")
> +
>  (defun viper-has-face-support-p ()
> +  (if (and (boundp 'viper-disable-face-support) viper-disable-face-support)
> +      nil
>    (cond ((viper-window-display-p))
>  	(viper-force-faces)
>  	((viper-color-display-p))
> -	(t (memq window-system '(pc)))))
> +	(t (memq window-system '(pc))))))

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

IOW, I don't think I understand the intent (nor the rationale, btw),
but then I'm not using viper, so I'm probably missing something.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sat, 11 Feb 2023 16:11:02 GMT) Full text and rfc822 format available.

Message #11 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: andrés ramírez <rrandresf <at> hotmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61432 <at> debbugs.gnu.org
Subject: Re: 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 <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sat, 11 Feb 2023 16:32:02 GMT) Full text and rfc822 format available.

Message #14 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrés ramírez <rrandresf <at> hotmail.com>
Cc: 61432 <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 11 Feb 2023 18:30:28 +0200
> From: andrés ramírez <rrandresf <at> hotmail.com>
> Cc: 61432 <at> debbugs.gnu.org
> Date: Sat, 11 Feb 2023 16:10:23 +0000
> 
>     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.

The easiest one is this:

  (require 'viper-init)
  (setq viper-minibuffer-vi-face viper-minibuffer-emacs-face)

Did you try that?
> Hope that clarifies the use of this variable.
> 
> And the most of vipers users are not going to notice that variable.

My problem with this is twofold:

  . I don't like to have code in Emacs which "works around" our own code
  . viper-has-face-support-p is used for more than just the mode line

So I'd prefer a different solution.  And in this case, it sounds like
a possible solution already exists, see above.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sat, 11 Feb 2023 18:33:01 GMT) Full text and rfc822 format available.

Message #17 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: andrés ramírez <rrandresf <at> hotmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61432 <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 11 Feb 2023 18:32:36 +0000
[Message part 1 (text/plain, inline)]
Hi. Eli.

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


[...]


    Eli> The easiest one is this:

    Eli>   (require 'viper-init) (setq viper-minibuffer-vi-face viper-minibuffer-emacs-face)

    Eli> Did you try that?

I have tried it now. It is not giving me the right behaviour.

If You want to try that behaviour run:
emacs -Q -nw and C-x C-f (watch the faces on the prompt)
emacs -Q -nw -l /tmp/test-viper-loading.el

[test-viper-loading.el (text/plain, inline)]
(require 'viper-init)
(setq viper-minibuffer-vi-face viper-minibuffer-emacs-face)
(setq viper-mode t)      
(setq viper-inhibit-startup-message 't)      
(setq viper-expert-level '5)      
(require 'viper)
[Message part 3 (text/plain, inline)]

[...]


    Eli> My problem with this is twofold:

    Eli>   . I don't like to have code in Emacs which "works around" our own code
    Eli> . viper-has-face-support-p is used for more than just the mode line

Mmm. Then perhaps the patch should be changed to integrate better with
the rest.

    Eli> So I'd prefer a different solution.  And in this case, it sounds like a possible solution
    Eli> already exists, see above.

See above.

Best Regards

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sat, 11 Feb 2023 18:49:01 GMT) Full text and rfc822 format available.

Message #20 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrés ramírez <rrandresf <at> hotmail.com>
Cc: 61432 <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 11 Feb 2023 20:48:07 +0200
> From: andrés ramírez <rrandresf <at> hotmail.com>
> Cc: 61432 <at> debbugs.gnu.org
> Date: Sat, 11 Feb 2023 18:32:36 +0000
> 
>     Eli> The easiest one is this:
>     Eli>   (require 'viper-init) (setq viper-minibuffer-vi-face viper-minibuffer-emacs-face)
>     Eli> Did you try that?
> 
> I have tried it now. It is not giving me the right behaviour.
> 
> If You want to try that behaviour run:
> emacs -Q -nw and C-x C-f (watch the faces on the prompt)
> emacs -Q -nw -l /tmp/test-viper-loading.el

What is the "right behavior"?  Which face do you want to avoid seeing?
maybe it's viper-minibuffer-insert?  Then try this instead:

  (require 'viper-init)
  (setq viper-minibuffer-insert-face viper-minibuffer-emacs-face)
  (setq viper-mode t)      
  (setq viper-inhibit-startup-message 't)      
  (setq viper-expert-level '5)      
  (require 'viper)

Anyway, the above is just a hint: how you can arrange for the viper
faces do whatever you like.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sun, 12 Feb 2023 17:56:01 GMT) Full text and rfc822 format available.

Message #23 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: andrés ramírez <rrandresf <at> hotmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61432 <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sun, 12 Feb 2023 17:54:45 +0000
[Message part 1 (text/plain, inline)]
Hi. Eli.
>>>>> "Eli" == Eli Zaretskii <eliz <at> gnu.org> writes:

    Eli> The easiest one is this: (require 'viper-init) (setq viper-minibuffer-vi-face
    Eli> viper-minibuffer-emacs-face) Did you try that?

Yes. without success.

    Eli> What is the "right behavior"?  

The right behaviour is staying as If it were an 'emacs -Q'. minibuffer
faces should stay as by default on vanilla emacs.

    Eli> Which face do you want to avoid seeing?  

I would like minibuffer faces stay as vanilla emacs when activating viper.


[...]


    Eli> Anyway, the above is just a hint: how you can arrange for the viper faces do whatever you
    Eli> like.

Thanks. But I have not being able of having the faces on minibuffer not
changing after activating viper. 

What about a oneline patch?

[patch-viper-cmd-optionally-disable-minibuffer-faces.patch (text/x-patch, inline)]
diff -u /tmp/viper/viper-cmd.el.bak /tmp/viper/viper-cmd.el
--- /tmp/viper/viper-cmd.el.bak	2023-02-12 17:45:05.775987386 +0000
+++ /tmp/viper/viper-cmd.el	2023-02-12 17:06:44.589089504 +0000
@@ -564,7 +564,7 @@
        ))
 
   ;; minibuffer faces
-  (if (viper-has-face-support-p)
+  (if (and (viper-has-face-support-p) (not (and (boundp 'viper-disable-face-support) viper-disable-face-support)))
       (setq viper-minibuffer-current-face
 	    (cond ((eq state 'emacs-state) viper-minibuffer-emacs-face)
 		  ((eq state 'vi-state) viper-minibuffer-vi-face)

Diff finished.  Sun Feb 12 17:45:44 2023
[Message part 3 (text/plain, inline)]
Best Regards

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sun, 12 Feb 2023 18:31:02 GMT) Full text and rfc822 format available.

Message #26 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrés ramírez <rrandresf <at> hotmail.com>
Cc: 61432 <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sun, 12 Feb 2023 20:30:18 +0200
> From: andrés ramírez <rrandresf <at> hotmail.com>
> Cc: 61432 <at> debbugs.gnu.org
> Date: Sun, 12 Feb 2023 17:54:45 +0000
> 
>     Eli> What is the "right behavior"?  
> 
> The right behaviour is staying as If it were an 'emacs -Q'. minibuffer
> faces should stay as by default on vanilla emacs.

Then make all those faces be the same: default.

> What about a oneline patch?

You are suggesting a new user option?  That might be okay, but then
the patch should include a suitable defcustom.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sun, 12 Feb 2023 18:54:02 GMT) Full text and rfc822 format available.

Message #29 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: andrés ramírez <rrandresf <at> hotmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61432 <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sun, 12 Feb 2023 18:53:05 +0000
[Message part 1 (text/plain, inline)]
Hi. Eli.

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


[...]

    Eli> Then make all those faces be the same: default.

There would be more than oneline. And There is no guarantee it should
work. I have tried several variations and have not gotten the default
faces showed when launching 'emacs -Q'


    Eli> You are suggesting a new user option?  That might be okay, but then the patch should
    Eli> include a suitable defcustom.

Yes. I am suggesting a new user option. For not changing minibuffer
faces when using viper.

Attached the new version of the patch.

[patch-viper-cmd-optionally-disable-minibuffer-faces.patch (text/x-patch, inline)]
diff -u /tmp/viper/viper-cmd.el.bak /tmp/viper/viper-cmd.el
--- /tmp/viper/viper-cmd.el.bak	2023-02-12 17:45:05.775987386 +0000
+++ /tmp/viper/viper-cmd.el	2023-02-12 18:48:17.986368416 +0000
@@ -564,7 +564,7 @@
        ))
 
   ;; minibuffer faces
-  (if (viper-has-face-support-p)
+  (if (and (viper-has-face-support-p) (not (and (boundp 'viper-disable-minibuffer-faces) viper-disable-minibuffer-faces)))
       (setq viper-minibuffer-current-face
 	    (cond ((eq state 'emacs-state) viper-minibuffer-emacs-face)
 		  ((eq state 'vi-state) viper-minibuffer-vi-face)
@@ -1923,6 +1923,12 @@
   :group 'viper-misc)
 
 
+(defcustom viper-disable-minibuffer-faces nil
+  "If non-nil, viper does change the minibuffer faces."
+  :type 'boolean
+  :group 'viper-misc)
+
+
 ;; Try to add a suitable suffix to files whose name ends with a `.'
 ;; Useful when the user hits RET on a non-completed file name.
 ;; Used as a minibuffer exit hook in read-file-name

Diff finished.  Sun Feb 12 18:48:25 2023
[Message part 3 (text/plain, inline)]
Best Regards

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Mon, 13 Feb 2023 14:01:01 GMT) Full text and rfc822 format available.

Message #32 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: andrés ramírez <rrandresf <at> hotmail.com>
Cc: 61432 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Mon, 13 Feb 2023 15:00:26 +0100
>>>>> On Sun, 12 Feb 2023 18:53:05 +0000, andrés ramírez <rrandresf <at> hotmail.com> said:
    INKA>    ;; minibuffer faces
    INKA> -  (if (viper-has-face-support-p)
    INKA> +  (if (and (viper-has-face-support-p) (not (and (boundp 'viper-disable-minibuffer-faces) viper-disable-minibuffer-faces)))
    INKA>        (setq viper-minibuffer-current-face
    INKA>  	    (cond ((eq state 'emacs-state) viper-minibuffer-emacs-face)
    INKA>  		  ((eq state 'vi-state) viper-minibuffer-vi-face)
    INKA> @@ -1923,6 +1923,12 @@
    INKA>    :group 'viper-misc)
 
You donʼt need to check if 'viper-disable-minibuffer-faces'  is
bound. Itʼs a defcustom, it will always be bound.

    INKA> +(defcustom viper-disable-minibuffer-faces nil
    INKA> +  "If non-nil, viper does change the minibuffer faces."
    INKA> +  :type 'boolean
    INKA> +  :group 'viper-misc)
    INKA> +
    INKA> +

Setting things to 't' to disable functionality I always find
confusing. How about you invert it:

    (defcustom viper-enable-minibuffer-faces t
      "Whether viper changes the minibuffer faces."
      :type 'boolean
      :group 'viper-misc)

Thanks

Robert
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Mon, 13 Feb 2023 15:04:02 GMT) Full text and rfc822 format available.

Message #35 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: andrés ramírez <rrandresf <at> hotmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 61432 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Mon, 13 Feb 2023 15:02:52 +0000
[Message part 1 (text/plain, inline)]
Hi. Robert.

>>>>> "Robert" == Robert Pluim <rpluim <at> gmail.com> writes:


[...]

 
    Robert> You donʼt need to check if 'viper-disable-minibuffer-faces' is bound. Itʼs a defcustom,
    Robert> it will always be bound.

Thanks for the clarification.

[...]


    Robert> Setting things to 't' to disable functionality I always find confusing. How about you
    Robert> invert it:

    Robert>     (defcustom viper-enable-minibuffer-faces t "Whether viper changes the minibuffer
    Robert> faces."  :type 'boolean :group 'viper-misc)

Done.

[patch-viper-cmd-optionally-disable-minibuffer-faces.patch (text/x-patch, inline)]
diff -u /tmp/viper/viper-cmd.el.bak /tmp/viper/viper-cmd.el
--- /tmp/viper/viper-cmd.el.bak	2023-02-12 17:45:05.775987386 +0000
+++ /tmp/viper/viper-cmd.el	2023-02-12 18:48:17.986368416 +0000
@@ -564,7 +564,7 @@
        ))
 
   ;; minibuffer faces
-  (if (viper-has-face-support-p)
+  (if (and (viper-has-face-support-p) viper-enable-minibuffer-faces)
       (setq viper-minibuffer-current-face
 	    (cond ((eq state 'emacs-state) viper-minibuffer-emacs-face)
 		  ((eq state 'vi-state) viper-minibuffer-vi-face)
@@ -1923,6 +1923,12 @@
   :group 'viper-misc)
 
 
+(defcustom viper-enable-minibuffer-faces t
+  "Whether viper changes the minibuffer faces."
+  :type 'boolean
+  :group 'viper-misc)
+
+
 ;; Try to add a suitable suffix to files whose name ends with a `.'
 ;; Useful when the user hits RET on a non-completed file name.
 ;; Used as a minibuffer exit hook in read-file-name

Diff finished.  Sun Feb 12 18:48:25 2023
[Message part 3 (text/plain, inline)]
Best Regards

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Mon, 13 Feb 2023 17:03:02 GMT) Full text and rfc822 format available.

Message #38 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: andrés ramírez <rrandresf <at> hotmail.com>
Cc: 61432 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Mon, 13 Feb 2023 18:02:01 +0100
>>>>> On Mon, 13 Feb 2023 15:02:52 +0000, andrés ramírez <rrandresf <at> hotmail.com> said:

 
    INKA> +(defcustom viper-enable-minibuffer-faces t
    INKA> +  "Whether viper changes the minibuffer faces."
    INKA> +  :type 'boolean
    INKA> +  :group 'viper-misc)
    INKA> +
    INKA> +

And one thing I forgot: defcustomʼs normally require a :version field,
but I see that *none* of the defcustomʼs in viper have one, so maybe
we could skip that here.

Robert
-- 




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 18 Feb 2023 17:02:02 GMT) Full text and rfc822 format available.

Notification sent to Andrés Ramírez <rrandresf <at> hotmail.com>:
bug acknowledged by developer. (Sat, 18 Feb 2023 17:02:02 GMT) Full text and rfc822 format available.

Message #43 received at 61432-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrés ramírez <rrandresf <at> hotmail.com>
Cc: rpluim <at> gmail.com, 61432-done <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 18 Feb 2023 19:01:05 +0200



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Sat, 18 Feb 2023 17:02:02 GMT) Full text and rfc822 format available.

Message #46 received at 61432-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrés ramírez <rrandresf <at> hotmail.com>
Cc: rpluim <at> gmail.com, 61432-done <at> debbugs.gnu.org
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Sat, 18 Feb 2023 19:01:41 +0200
> From: andrés ramírez <rrandresf <at> hotmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> 	61432 <at> debbugs.gnu.org
> Date: Mon, 13 Feb 2023 15:02:52 +0000
> 
>     Robert> You donʼt need to check if 'viper-disable-minibuffer-faces' is bound. Itʼs a defcustom,
>     Robert> it will always be bound.
> 
> Thanks for the clarification.
> 
> [...]
> 
> 
>     Robert> Setting things to 't' to disable functionality I always find confusing. How about you
>     Robert> invert it:
> 
>     Robert>     (defcustom viper-enable-minibuffer-faces t "Whether viper changes the minibuffer
>     Robert> faces."  :type 'boolean :group 'viper-misc)
> 
> Done.

Thanks, installed on master, with a few necessary adjustments.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Thu, 23 Feb 2023 15:10:02 GMT) Full text and rfc822 format available.

Message #49 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: andrés ramírez <rrandresf <at> hotmail.com>
Cc: 61432 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Thu, 23 Feb 2023 16:09:19 +0100
(restoring Eli and bug address)

>>>>> On Thu, 23 Feb 2023 14:47:42 +0000, andrés ramírez <rrandresf <at> hotmail.com> said:

    INKA> An I realized and additional line is needed (the last one in the patch)

    INKA> Let me know how should I proceed for amending the patch with the needed line.

Hi, I pushed your followup patch to master in your name (we never
rewrite history)

This was only a one liner, so it was easy, for bigger followup changes
itʼs best to have the second patch be on top of the first one (or
re-send two separate patches)

Robert
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61432; Package emacs. (Thu, 23 Feb 2023 15:26:02 GMT) Full text and rfc822 format available.

Message #52 received at 61432 <at> debbugs.gnu.org (full text, mbox):

From: andrés ramírez <rrandresf <at> hotmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 61432 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61432: 28.2; [PATCH] viper-init: disable face support
Date: Thu, 23 Feb 2023 15:24:56 +0000
Hi Robert. Hi Eli.
>>>>> "Robert" == Robert Pluim <rpluim <at> gmail.com> writes:


[...]

    Robert> Hi, I pushed your followup patch to master in your name (we never rewrite history)

Thanks Robert for the ammending. 

    Robert> This was only a one liner, so it was easy, for bigger followup changes itʼs best to have
    Robert> the second patch be on top of the first one (or re-send two separate patches)

Thanks for the information.

Thanks Eli for applying  the patch.
,---- [  ]
| http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b3502b922821fd100fb86b8cda6a0a62fba7d394
`----

Best Regards




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 24 Mar 2023 11:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 34 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.