* bug#15668: 24.3.50; No font lock on active region
@ 2013-10-21 5:56 Darren Hoo
2013-10-21 16:30 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Darren Hoo @ 2013-10-21 5:56 UTC (permalink / raw)
To: 15668
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]
Open any elisp file and mark a function, and the active region is
not font-lockfied.
This only occurs in GUI mode, it's ok with text-mode.
In GNU Emacs 24.3.50.14 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
of 2013-10-21 on Darren-rMBP.local
Bzr revision: 114730 jan.h.d@swipnet.se-20131020164742-8yrjvlomlsy27w9u
Windowing system distributor `Apple', version 10.3.1265
Configured using:
`configure --with-ns'
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x r e o <backspace> p o r t <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process cocoa ns
multi-tty emacs)
[-- Attachment #2: Type: text/html, Size: 2802 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15668: 24.3.50; No font lock on active region
2013-10-21 5:56 bug#15668: 24.3.50; No font lock on active region Darren Hoo
@ 2013-10-21 16:30 ` Eli Zaretskii
2013-10-21 18:47 ` Jan Djärv
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2013-10-21 16:30 UTC (permalink / raw)
To: Darren Hoo; +Cc: 15668
> Date: Mon, 21 Oct 2013 13:56:24 +0800
> From: Darren Hoo <darren.hoo@gmail.com>
>
> Open any elisp file and mark a function, and the active region is
> not font-lockfied.
>
> This only occurs in GUI mode, it's ok with text-mode.
Can't reproduce this with today's trunk. Unless the recipe is not as
simple as it sounds, this could be NS specific.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15668: 24.3.50; No font lock on active region
2013-10-21 16:30 ` Eli Zaretskii
@ 2013-10-21 18:47 ` Jan Djärv
2013-10-21 19:06 ` Eli Zaretskii
2013-10-21 21:36 ` Darren Hoo
0 siblings, 2 replies; 9+ messages in thread
From: Jan Djärv @ 2013-10-21 18:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 15668, Darren Hoo
Hello.
21 okt 2013 kl. 18:30 skrev Eli Zaretskii <eliz@gnu.org>:
>> Date: Mon, 21 Oct 2013 13:56:24 +0800
>> From: Darren Hoo <darren.hoo@gmail.com>
>>
>> Open any elisp file and mark a function, and the active region is
>> not font-lockfied.
>>
>> This only occurs in GUI mode, it's ok with text-mode.
>
> Can't reproduce this with today's trunk. Unless the recipe is not as
> simple as it sounds, this could be NS specific.
Both Gtk+ and NS does this. The reason is that we use the system defined selection colors, and the background may be ill-matched to Emacs foreground colors.
For example, many Gnome settings use an almost black color for selection background, so Emacs black for text color is almost unreadable. These settings use white(ish) for text color which is much better. But by setting foreground selection color, you loose font-lock. OSX uses a light blue for background, which is very near to blue used by font-lock-constant-face and also near font-lock-function-name-face.
It would be nice if one could define a face with a foreground color to be used when foreground and background otherwise are to similar.
Jan D.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15668: 24.3.50; No font lock on active region
2013-10-21 18:47 ` Jan Djärv
@ 2013-10-21 19:06 ` Eli Zaretskii
2013-10-21 19:20 ` Eli Zaretskii
2013-10-22 16:14 ` Jan Djärv
2013-10-21 21:36 ` Darren Hoo
1 sibling, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2013-10-21 19:06 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15668, darren.hoo
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Mon, 21 Oct 2013 20:47:25 +0200
> Cc: Darren Hoo <darren.hoo@gmail.com>,
> 15668@debbugs.gnu.org
>
> It would be nice if one could define a face with a foreground color to be used when foreground and background otherwise are to similar.
Sounds like a simple enough extension to defface.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15668: 24.3.50; No font lock on active region
2013-10-21 19:06 ` Eli Zaretskii
@ 2013-10-21 19:20 ` Eli Zaretskii
2013-10-22 16:14 ` Jan Djärv
1 sibling, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2013-10-21 19:20 UTC (permalink / raw)
To: jan.h.d; +Cc: 15668, darren.hoo
> Date: Mon, 21 Oct 2013 22:06:53 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 15668@debbugs.gnu.org, darren.hoo@gmail.com
>
> > From: Jan Djärv <jan.h.d@swipnet.se>
> > Date: Mon, 21 Oct 2013 20:47:25 +0200
> > Cc: Darren Hoo <darren.hoo@gmail.com>,
> > 15668@debbugs.gnu.org
> >
> > It would be nice if one could define a face with a foreground color to be used when foreground and background otherwise are to similar.
>
> Sounds like a simple enough extension to defface.
Or maybe every face should do that by default.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15668: 24.3.50; No font lock on active region
2013-10-21 19:06 ` Eli Zaretskii
2013-10-21 19:20 ` Eli Zaretskii
@ 2013-10-22 16:14 ` Jan Djärv
2013-10-22 16:28 ` Eli Zaretskii
1 sibling, 1 reply; 9+ messages in thread
From: Jan Djärv @ 2013-10-22 16:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 15668, darren.hoo
Hello.
21 okt 2013 kl. 21:06 skrev Eli Zaretskii <eliz@gnu.org>:
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Mon, 21 Oct 2013 20:47:25 +0200
>> Cc: Darren Hoo <darren.hoo@gmail.com>,
>> 15668@debbugs.gnu.org
>>
>> It would be nice if one could define a face with a foreground color to be used when foreground and background otherwise are to similar.
>
> Sounds like a simple enough extension to defface.
Well, yes, but I envisioned that querying the face for the foreground would automatically give the "fallback" foreground when the background is close to the foreground that would otherwise be used. I think the calculation of close and maybe handling face inheritance is a bit tricky.
Jan D.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15668: 24.3.50; No font lock on active region
2013-10-22 16:14 ` Jan Djärv
@ 2013-10-22 16:28 ` Eli Zaretskii
2013-11-01 15:54 ` Jan Djärv
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2013-10-22 16:28 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15668, darren.hoo
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Tue, 22 Oct 2013 18:14:03 +0200
> Cc: darren.hoo@gmail.com,
> 15668@debbugs.gnu.org
>
> Hello.
>
> 21 okt 2013 kl. 21:06 skrev Eli Zaretskii <eliz@gnu.org>:
>
> >> From: Jan Djärv <jan.h.d@swipnet.se>
> >> Date: Mon, 21 Oct 2013 20:47:25 +0200
> >> Cc: Darren Hoo <darren.hoo@gmail.com>,
> >> 15668@debbugs.gnu.org
> >>
> >> It would be nice if one could define a face with a foreground color to be used when foreground and background otherwise are to similar.
> >
> > Sounds like a simple enough extension to defface.
>
> Well, yes, but I envisioned that querying the face for the foreground would automatically give the "fallback" foreground when the background is close to the foreground that would otherwise be used.
That's what I had in mind, yes.
> I think the calculation of close and maybe handling face inheritance is a bit tricky.
Some distance in the RGB space might fit the former. I'm quite sure
color comparison is something for which algorithms are readily
available.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15668: 24.3.50; No font lock on active region
2013-10-22 16:28 ` Eli Zaretskii
@ 2013-11-01 15:54 ` Jan Djärv
0 siblings, 0 replies; 9+ messages in thread
From: Jan Djärv @ 2013-11-01 15:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 15668-done, darren.hoo@gmail.com Hoo
Hello.
22 okt 2013 kl. 18:28 skrev Eli Zaretskii <eliz@gnu.org>:
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Tue, 22 Oct 2013 18:14:03 +0200
>> Cc: darren.hoo@gmail.com,
>> 15668@debbugs.gnu.org
>>
>> Hello.
>>
>> 21 okt 2013 kl. 21:06 skrev Eli Zaretskii <eliz@gnu.org>:
>>
>>>> From: Jan Djärv <jan.h.d@swipnet.se>
>>>> Date: Mon, 21 Oct 2013 20:47:25 +0200
>>>> Cc: Darren Hoo <darren.hoo@gmail.com>,
>>>> 15668@debbugs.gnu.org
>>>>
>>>> It would be nice if one could define a face with a foreground color to be used when foreground and background otherwise are to similar.
>>>
>>> Sounds like a simple enough extension to defface.
>>
>> Well, yes, but I envisioned that querying the face for the foreground would automatically give the "fallback" foreground when the background is close to the foreground that would otherwise be used.
>
> That's what I had in mind, yes.
>
>> I think the calculation of close and maybe handling face inheritance is a bit tricky.
>
> Some distance in the RGB space might fit the former. I'm quite sure
> color comparison is something for which algorithms are readily
> available.
Actually there is a color_distance function in xfaces.c already.
I implemented :distant-foreground to be used as a fallback, checked in to trunk.
Marking this bug as done.
Jan D.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15668: 24.3.50; No font lock on active region
2013-10-21 18:47 ` Jan Djärv
2013-10-21 19:06 ` Eli Zaretskii
@ 2013-10-21 21:36 ` Darren Hoo
1 sibling, 0 replies; 9+ messages in thread
From: Darren Hoo @ 2013-10-21 21:36 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15668
[-- Attachment #1.1: Type: text/plain, Size: 1908 bytes --]
Hi,
On Tue, Oct 22, 2013 at 2:47 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
> Both Gtk+ and NS does this. The reason is that we use the system defined
> selection colors, and the background may be ill-matched to Emacs foreground
> colors.
> For example, many Gnome settings use an almost black color for selection
> background, so Emacs black for text color is almost unreadable. These
> settings use white(ish) for text color which is much better. But by
> setting foreground selection color, you loose font-lock. OSX uses a light
> blue for background, which is very near to blue used by
> font-lock-constant-face and also near font-lock-function-name-face.
>
> It would be nice if one could define a face with a foreground color to be
> used when foreground and background otherwise are to similar.
>
I've noticed the changes you made in revno: 114473, I can customize-faces
of region for
my own preference. But I would argue that it might be better to leave
foreground of
region face to be unspecified by default and only use
ns_selection_bg_color for background.
Let Emacs theme designers take care of the use ns_selection_fg_color if
they want to
their theme to work flawlessly on OSX.
I suppose that many users do want fancy font-lock on active regions as many
IDE does
although even on text-mode this behaviour between different Emacs releases
is non-consistent.
I think the reason Gtk uses both gtk_selection_fg_color and
gtk_selection_bg_color is that
there are many themes for user to choose and different GNU/Linux
distributors choose different
themes thus the fock-lock on regions thing has to lose . But on OSX the
color of highlight text is
seldom changed (or at least for me).
By default I find that both font-lock-constant-face and
font-lock-function-name-face are quite
readable on the default light blue selectedBackgroundColor.
[-- Attachment #1.2: Type: text/html, Size: 2512 bytes --]
[-- Attachment #2: faces.png --]
[-- Type: image/png, Size: 27378 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-11-01 15:54 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-21 5:56 bug#15668: 24.3.50; No font lock on active region Darren Hoo
2013-10-21 16:30 ` Eli Zaretskii
2013-10-21 18:47 ` Jan Djärv
2013-10-21 19:06 ` Eli Zaretskii
2013-10-21 19:20 ` Eli Zaretskii
2013-10-22 16:14 ` Jan Djärv
2013-10-22 16:28 ` Eli Zaretskii
2013-11-01 15:54 ` Jan Djärv
2013-10-21 21:36 ` Darren Hoo
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).
![[-- Attachment #2: faces.png --] [-- Type: image/png, Size: 27378 bytes --]](../../CAJ+QY_E+yAQW+ix6J--1M3A0P7C+ssPuy0YeZ_Dhaye2fE_Xjg@mail.gmail.com/2-faces.png){kind=link}