emacs-devel
[Top][All Lists]
Advanced

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

Re: font-lock-maximum-decoration should be 2 by default?


From: Vitalie Spinu
Subject: Re: font-lock-maximum-decoration should be 2 by default?
Date: Sat, 18 Aug 2012 12:03:21 +0200
User-agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux)

  >> "Stephen J. Turnbull" <address@hidden>
  >> on Sat, 18 Aug 2012 14:10:58 +0900 wrote:

  > Vitalie Spinu writes:
  >> In font-lock language: If you design a feature which is intended for
  >> 30% of salad lovers. Then by the virtue of emacs defaults and peoples'
  >> psychology, 90% of the people will end up using it. That is, 60% of
  >> normal users (which don't like salads) will end up eating it.

  > True, but it's not clear that Emacs should care about "normal" users
  > in the sense of "people's psychology".  Emacs users are different, at
  > least that's the conventional wisdom.  They like (1) customizability,
  > (2) a consistent user interface across applications.  It's not obvious
  > that the generally prevalent "accept the default" psychology is that
  > relevant to Emacs users.

It's easy to get sick of too much customization. It's another well know
paradox of human pshychology -- we want more choose but too much choice
is bad for you
(http://news.bbc.co.uk/today/hi/today/newsid_8155000/8155505.stm).

There are so many small inconveniences/bugs which I know I can solve
probably in 15-30 minutes by studding the code/docs/customization, but I
continue to leave with those in emacs, sometimes for months and
years. Familiar?

  >> 3) Developers which would like to capture 30% of salad lovers will try
  >> to find workarounds. That is, add redundant, mode-specific font-lock
  >> customization, or mess with font-lock-maximum-decoration.

  > This is true, but I'm not sure if it's a problem.

It's a problem in light of yours (2). Everyone wants a consistent
interface.

  >> 4) If not self-obvious, the proposed modification would allow a default
  >> level of fontification. Thing which is not possible right now.

  > It's not obvious that the concept of "level of fontification" is
  > entirely consistent.  At least for me, if certain features aren't
  > fontified,

I agree, levels are not flexible enough (or at least at higher
levels). People tend to agree on the basic fontification like strings,
comments and keywords. But with more fontification levels become a
trouble. For example I can choose to fortify the function call as in
"foo(x, y)" or I can choose to fortify parenthesis. Different people
might choose different things. Also, I might want to fortify {} braces
as they are difficult to distinguish from (), but leave all other paren
syntax untouched.  These things are difficult or impossible to fit into
levels.

Vitalie.



reply via email to

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