[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13686: hi-yellow vs. hi-lock-1
From: |
Jambunathan K |
Subject: |
bug#13686: hi-yellow vs. hi-lock-1 |
Date: |
Thu, 07 Mar 2013 08:53:19 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
David Koppelman <koppel@ece.lsu.edu> writes:
> Jambunathan K <kjambunathan@gmail.com> writes:
>>
>> I gave a code snippet at the end of the mail. If you had looked at it,
>> you will realize that I have done nothing which changes the status quo
>> but I have done eveything to accommodate my requirements. I am the
>> proposer, right?
>
> I'm sorry, I was responding more to past comments than the specific
> message I was replying to.
>
>> Please provide specific feedback on the snippet rather than registering
>> a broad objection. I have made an effort to understand the
>> "I-want-color" camp and I have also openly acknowledged that the
>> "I-want-color" camp have valid and sensible arguments.
>
> So, the goal of hi-lock-face-regexp is to select a set of fonts. I
> guess the custom interface would expose simple options to the user,
> for example, "Fixed Colors", "Theme Colors", and for each option the
> appropriate regexp would be assigned. Is that right?
Correct.
> In that case, why not have a variable hi-lock-use-theme-colors and use
> that to select either the current default list, or one with generic
> names.
Yes, this is fine with me. I am open to anything that would address
even a fraction of my needs.
> That said, I still believe the user should see the color that will be
> applied, and that this be accomplished without undue complexity.
Yes, existing users of hi-lock shouldn't be alarmed with new changes.
Jambunathan K.
bug#13686: hi-yellow vs. hi-lock-1, Jambunathan K, 2013/03/06