Reopen bug 535: Problem with highlit regions on Linux virtual terminal

Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

Hi, Yidong, Hi Emacs!

I submitted the bug report (below) ~9 months ago.  In August, it got
tagged with "won't fix".  I seem to have missed the discussion on this
decision.

This problem makes the default setup barely usable on a Linux virtual
terminal; it surely must be fixed before release.

I have removed the "won't fix" tag and increased its severity to
"serious".

-- 
Alan Mackenzie (Nuremberg, Germany).


----- Forwarded message from Alan Mackenzie <acm@muc.de> -----

Date: Fri, 4 Jul 2008 21:17:01 +0000
From: Alan Mackenzie <acm@muc.de>
To: emacs-pretest-bug@gnu.org
Subject: Problem with highlit regions on Linux virtual terminal

In a GNU/Linux system, log on to a virtual terminal.  (If already in X,
do, e.g., Ctrl-Alt-F1 to get there).

With an up to date CVS version,

    emacs -Q
    C-x C-f .../path/to/emacs/lisp/files.el
    C-s find-alternate-file <CR>

Note the general quality of the display (high :-), including the font
locking.  Now do

    C-M-h

to mark the function.  Note again the quality of the display (low :-().
We have uniform pale grey text on a bright blue background, and the sole
remaining vestige of the font locking is that font-lock-keyword-face
(and one or two others) are in bold white rather than pale grey.

This is unacceptable for our release.  It has been a particular problem
since transient-mark-mode became switched on by default.

-- 
Alan Mackenzie (Nuremberg, Germany).


----- End forwarded message -----

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
>     C-M-h
>
> to mark the function.  Note again the quality of the display (low :-().
> We have uniform pale grey text on a bright blue background, and the sole
> remaining vestige of the font locking is that font-lock-keyword-face
> (and one or two others) are in bold white rather than pale grey.

I beg to differ -- it looks great to me (high-contrast, readable, usable).
[not just on the linux console, either, but in every environment I tried
it in -- X, xterm, gnome-terminal, light-background, black-background]

You seem to be right that it's suppressing most of the font-locking in
the highlighted area.  I don't know exactly why it does so (whether this
is intentional behavior or an artifact of the implementation), but it's
not at all clear to me that this behavior is a bad thing -- region
highlighting is generally temporary, and the text would very likely be
_less_ readable if the font-locking was preserved (because the font-lock
colors are designed to be readable with the standard background, and
would in many cases be quite awful against the highlighted background).

-Miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> You seem to be right that it's suppressing most of the font-locking in
> the highlighted area.  I don't know exactly why it does so (whether this
> is intentional behavior or an artifact of the implementation)

See the definition of the `region' face in faces.el.  On displays with
sufficient colors, the face definition sets just :background, leaving
the remaining face attributes unspecified; those will generally be set
from the font-lock face.

On 8-color displays, both :background and :foreground is set.  This is
quite reasonable, because of the paucity of colors on such displays.

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

HI, Yidong!

On Sun, Apr 05, 2009 at 11:10:06PM -0400, Chong Yidong wrote:
> Miles Bader <miles@gnu.org> writes:

> > You seem to be right that it's suppressing most of the font-locking
> > in the highlighted area.  I don't know exactly why it does so
> > (whether this is intentional behavior or an artifact of the
> > implementation)

> See the definition of the `region' face in faces.el.  On displays with
> sufficient colors, the face definition sets just :background, leaving
> the remaining face attributes unspecified; those will generally be set
> from the font-lock face.

> On 8-color displays, both :background and :foreground is set.  This is
> quite reasonable, because of the paucity of colors on such displays.

I disagree - precisely because of this paucity of colours, it is
unreasonable to override both.  Font locking is important.  The contrast
between a highlit region and a font locked region (the current setup
excludes a combination of both) is too violent.  

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

Hi, Miles!

On Mon, Apr 06, 2009 at 10:12:54AM +0900, Miles Bader wrote:
> Alan Mackenzie <acm@muc.de> writes:
> >     C-M-h

> > to mark the function.  Note again the quality of the display (low :-().
> > We have uniform pale grey text on a bright blue background, and the sole
> > remaining vestige of the font locking is that font-lock-keyword-face
> > (and one or two others) are in bold white rather than pale grey.

> I beg to differ -- it looks great to me (high-contrast, readable, usable).
> [not just on the linux console, either, but in every environment I tried
> it in -- X, xterm, gnome-terminal, light-background, black-background]

Yes, it is high-contrast and so on, in the same way that a foghorn at
200m is highly audible when you're trying to have a quiet conversation.

> You seem to be right that it's suppressing most of the font-locking in
> the highlighted area.

It all but obliterates it.  It obliterates hi-lock mode entirely.  I
think it does this in GUI environments too.

> I don't know exactly why it does so (whether this is intentional
> behavior or an artifact of the implementation), but it's not at all
> clear to me that this behavior is a bad thing -- region highlighting
> is generally temporary,

A blaring foghorn is temporary too.

When I start Emacs 23 -Q, all of my buffers (loaded by desktop) are
foghorned - I find Emacs in this state unusable.

> and the text would very likely be _less_ readable if the font-locking
> was preserved (because the font-lock colors are designed to be
> readable with the standard background, and would in many cases be
> quite awful against the highlighted background).

I agree with the logic here.  Region highlighting is incompatible with
font lock and hi-lock.  Do you think that turning off font lock by
default might be a good solution?

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> Yes, it is high-contrast and so on, in the same way that a foghorn at
> 200m is highly audible when you're trying to have a quiet conversation.

This a silly analogy, and bears no resemblance to the actual appearance,
which is quite nice in my opinion.

>> You seem to be right that it's suppressing most of the font-locking in
>> the highlighted area.
>
> It all but obliterates it.

... and yet, it simply _doesn't matter_, because highlighted regions are
_temporary_.  I use Emacs too, and I find the behavior very reasonable.

Font-Locking is nice, but it's very much secondary information, and
suppressing some of it when selecting a region (when your attention is
focused on the region), is just not a big deal -- indeed, I didn't even
_notice_ that font-locking colors were suppressed by the region on a tty
until you mentioned it!

>It obliterates hi-lock mode entirely.  I
> think it does this in GUI environments too.

Yes, because hi-lock uses the background.  This is probably not
particularly important.

> A blaring foghorn is temporary too.

... which is quite irrelevant, since your "foghorn" analogy is not
accurate; arguing by means of poor analogies is not useful.

> When I start Emacs 23 -Q, all of my buffers (loaded by desktop) are
> foghorned - I find Emacs in this state unusable.

All of your buffers have activated  regions when Emacs starts?

If so, _that_ sounds like a bug (so please try to send a test case);
needless to say, I think, I do not see this behavior.

> I agree with the logic here.  Region highlighting is incompatible with
> font lock and hi-lock.  Do you think that turning off font lock by
> default might be a good solution?

Of course not, since as far as I can see, there isn't actually any
problem.

It seems pretty obvious to me that all of this is much more a matter of
taste than anything else.  You have made your opinion on the matter very
clear, repeatedly.  The Emacs maintainers have made their best judgement
as to what the majority of Emacs users will prefer.  You know how to
turn off the highlighting.

-Miles

-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

On Mon, Apr 06, 2009 at 06:30:28PM +0900, Miles Bader wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> You seem to be right that it's suppressing most of the font-locking
> >> in the highlighted area.

> > It all but obliterates it.

> ... and yet, it simply _doesn't matter_, because highlighted regions
> are _temporary_.  I use Emacs too, and I find the behavior very
> reasonable.

Why does the temporariness make something not important?  Temporary
things are very important.  I'm sensitive to things which flash and bang,
which is one of the main reasons I've loved Emacs so much - up till now,
it has never flashed and banged by default.

> Font-Locking is nice, but it's very much secondary information, and
> suppressing some of it when selecting a region (when your attention is
> focused on the region), is just not a big deal -- indeed, I didn't
> even _notice_ that font-locking colors were suppressed by the region
> on a tty until you mentioned it!

It's a big deal for me.  Probably for lots of other TTY users, too.  And
if font-locking is secondary, surely region highlighting is tertiary?
The normal Emacs default for such personal preferences has always been to
be restrained - surely lots of people like angry fruit salad font lock
faces, but we don't make them the default.

> >It obliterates hi-lock mode entirely.  I think it does this in GUI
> >environments too.

> Yes, because hi-lock uses the background.  This is probably not
> particularly important.

Again, I think it is.  I don't think it's been discussed here at all.

> All of your buffers have activated regions when Emacs starts?

They all have hilit regions when Emacs starts.

> If so, _that_ sounds like a bug (so please try to send a test case);

Ah, OK.  I don't have the background to judge.  ;-)

> needless to say, I think, I do not see this behavior.

No, you do in fact need to say this.  You're saying that when you start
Emacs with a desktop, your buffers don't have highlit regions, yes?  Mine
do.  My .emacs.desktop was first created by Emacs 21 in ~4004 BC, and
currently gets renewed in Emacs 22, and occasionally loaded into Emacs
23.  Maybe that has something to do with it.  I'll have a look sometime.

> > I agree with the logic here.  Region highlighting is incompatible
> > with font lock and hi-lock.  Do you think that turning off font lock
> > by default might be a good solution?

> Of course not, since as far as I can see, there isn't actually any
> problem.

> It seems pretty obvious to me that all of this is much more a matter of
> taste than anything else.

Yes.  Normally, in matters of taste, Emacs's defaults incline towards the
restrained, conservative.  Here we have a glaring exception.

> You have made your opinion on the matter very clear, repeatedly.  The
> Emacs maintainers have made their best judgement as to what the
> majority of Emacs users will prefer.

No, not at all.  On the specific matter of the interaction between region
hilighting and font-locking/hi-locking, I raised a bug report last
summer, as requested by Stefan.  Until yesterday there had been no
discussion of it at all, as far as I am aware.

> You know how to turn off the highlighting.

Yes of course.  But for a "mere" user, it's very difficult to find this
out.

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[David De La Harpe Golden]

Alan Mackenzie wrote:

> 
> It's a big deal for me.  Probably for lots of other TTY users, too.


These days, a lot text terminal emulators support 256 color mode. 
Unfortunately, the linux kernel console in particular doesn't seem to, 
but framebuffer (rather than hardware text mode) consoles on PC SVGA and 
similar hardware certianly *should* be able to in principle, it's 
possible just no-one's bothered writing the support.  Hmm.

>  And
> if font-locking is secondary, surely region highlighting is tertiary?

? Stuff is still legible without font locking, you can't even
see the region without region highlighting...

> No, not at all.  On the specific matter of the interaction between region
> hilighting and font-locking/hi-locking, I raised a bug report last
> summer, as requested by Stefan.  Until yesterday there had been no
> discussion of it at all, as far as I am aware.
>

I thought I posted something about the IMO nicest solution being to 
allow alphablending computation to mix the various foreground and 
background colors coming in from the overlaid faces somewhere around 
face realization time rather than just having higher priority override 
lower priority, but maybe I hallucinated actually saying that publically 
or thought I'd wait till I had a patch to do it.

Such a solution still wouldn't work exactly amazingly on an 8-color 
terminal to solve your "hi-lock background popping" problem, but would 
on 256 color text terminal or bitmap gui emacs - i.e. the region face 
could supply a translucent-looking tint instead of nuking the background 
(and maybe foreground).

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

Hi, David,

On Mon, Apr 06, 2009 at 04:35:59PM +0100, David De La Harpe Golden wrote:
> Alan Mackenzie wrote:

> These days, a lot text terminal emulators support 256 color mode.
> Unfortunately, the linux kernel console in particular doesn't seem to,
> but framebuffer (rather than hardware text mode) consoles on PC SVGA
> and similar hardware certianly *should* be able to in principle, it's
> possible just no-one's bothered writing the support.  Hmm.

> > And if font-locking is secondary, surely region highlighting is
> > tertiary?

> ? Stuff is still legible without font locking, you can't even
> see the region without region highlighting...

I've never had a problem seeing a region, and I've never used region
highlighting.  (OK, I know what you meant.).

> >No, not at all.  On the specific matter of the interaction between
> >region hilighting and font-locking/hi-locking, I raised a bug report
> >last summer, as requested by Stefan.  Until yesterday there had been
> >no discussion of it at all, as far as I am aware.

> I thought I posted something about the IMO nicest solution being to
> allow alphablending computation to mix the various foreground and
> background colors coming in from the overlaid faces somewhere around
> face realization time rather than just having higher priority override
> lower priority, but maybe I hallucinated actually saying that
> publically or thought I'd wait till I had a patch to do it.

No, I must just have forgotten about it, or missed it.  That sounds like
an excellent solution, so that you could make region highlighting do some
de-saturization, and adjust the degree of it to an optimum where the
colour change is slight enough not to be disturbing, yet firm enough to
be clearly seen.

> Such a solution still wouldn't work exactly amazingly on an 8-color 
> terminal to solve your "hi-lock background popping" problem, but would 
> on 256 color text terminal or bitmap gui emacs - i.e. the region face 
> could supply a translucent-looking tint instead of nuking the background 
> (and maybe foreground).

Yes.  

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

Hi, Miles!

On Mon, Apr 06, 2009 at 06:30:28PM +0900, Miles Bader wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > When I start Emacs 23 -Q, all of my buffers (loaded by desktop) are
> > foghorned - I find Emacs in this state unusable.

> All of your buffers have activated  regions when Emacs starts?

> If so, _that_ sounds like a bug (so please try to send a test case);
> needless to say, I think, I do not see this behavior.

In Emacs-22 -Q, enable desktop-save-mode, load some files, create a
region in each file.  DO NOT enable transient-mark-mode (or anything
similar).  Exit Emacs, creating .emacs.desktop.

Have a look at this .emacs.desktop.  It will contain buffer entries like
this:

(desktop-create-buffer 206
  "/home/acm/emacs/emacs.cvs/src/callint.c"
  "callint.c"
  'c-mode
  '(abbrev-mode hi-lock-mode)
  1
  '(8314 t)           ; <==============================================
  nil
  nil
  '((buffer-file-coding-system . undecided-unix)))

The cons in the marked line is of the mark and the variable
`mark-active'.  This variable doesn't have a coherent definition, but it
causes the region to be highlit.  It is "defined" as

    Non-nil means the mark and region are currently active in this
    buffer.

As I have pointed out before, this is Humpty Dumpty language, liable to
cause bugs.  The mark and the region are never "active" and cannot be
active - so to assert is a category error; they don't do anything, they
are never agents.  I don't know what it means for a mark to be "active"
and for a region to be "active" - I don't think it's defined anywhere,
and there is certainly no entry in the Concept Index for "active".  It
seems that the hacker who created `mark-active' had a different
understanding from the hacker who wrote desktop.el, hence this bug.  As
it is, `mark-active' is meaningless unless transient-mark-mode is
enabled.  Hence the arbitrariness of the `t' in (8314 t).

My suggestion for a fix:
(i) The variable `mark-active' should be renamed to what it actually
means, together with an alias.  Other similarly named variables should
also be renamed as needed to make their names meaningful; all uses of
these variables should be checked.
(ii) The concept "active" should be defined in the Emacs manual.
(ii) desktop-mode.el should be enhanced to record the state of
`transient-mark-mode' in .emacs.desktop.
(iii) On loading the desktop, buffers' regions should not be highlit
unless `transient-mark-mode' is recorded with a non-nil state.

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > The cons in the marked line is of the mark and the variable
 > `mark-active'.  This variable doesn't have a coherent definition,
 > but it causes the region to be highlit.  It is "defined" as
 > 
 >     Non-nil means the mark and region are currently active in this
 >     buffer.
 > 
 > As I have pointed out before, this is Humpty Dumpty language,

Not at all.  Active regions and the terminology go back twenty years
or more.  If the mark is non-nil, then the region exists.  The region
may be active, in which case operations on the region will succeed, or
inactive, when such operations will fail.[1]  In transient-mark-mode,
it is possible for the region to be inactive.  Outside of transient-
mark-mode, the region is always active.  (Or something like that,
that's how zmacs-regions works in XEmacs, transient-mark-mode has some
tiny differences that I never understood very well.)

It sounds to me like there's a bug in desktop.el[2], and maybe a lack of
documentation of active regions.  But the term is well-defined.


Footnotes: 
[1]  This is the same terminology used for GUI elements.  But I guess
you would say that the whole concept of "GUI" is a "category error".<wink>

[2]  I guess, as you say, it should record and check for
transient-mark-mode before going ahead and highlighting regions.
Personally, I would prefer desktop to have an option such that mark
status is always reset across sessions.

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

Hi, Stephen!

On Wed, Apr 08, 2009 at 02:35:16PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > The cons in the marked line is of the mark and the variable
>  > `mark-active'.  This variable doesn't have a coherent definition,
>  > but it causes the region to be highlit.  It is "defined" as

>  >     Non-nil means the mark and region are currently active in this
>  >     buffer.

>  > As I have pointed out before, this is Humpty Dumpty language,

> Not at all.  Active regions and the terminology go back twenty years
> or more.

I don't doubt this, but it has no bearing on the matter.

> If the mark is non-nil, then the region exists.  The region may be
> active, ....

What is the activity that this region does?  Does the region delete a
block of characters?  Does the region jump to the start of the next
defun?

Supposing you have a geologist inside a dead volcano, examining it,
measuring it, chipping bits out of it.  You would call this an "active
volcano", would you?

> ...., in which case operations on the region will succeed, or inactive,
> when such operations will fail.[1]

This is a misuse of the word "active", just as confusing as talking about
"protecting" a copyright work rather than "restricting" it.  In any
sentence with a verb of activity, "the region" is always in the object
position, never the subject position.

"Active" is the wrong word.  Possibly "Reactive" would be a suitable one
- a "reactive region" being one which reacts to commands directed at it.

> In transient-mark-mode, it is possible for the region to be inactive.
> Outside of transient- mark-mode, the region is always active.  (Or
> something like that, that's how zmacs-regions works in XEmacs,
> transient-mark-mode has some tiny differences that I never understood
> very well.)

> It sounds to me like there's a bug in desktop.el[2], and maybe a lack of
> documentation of active regions.  But the term is well-defined.

"Active region" is not well defined, which is what caused the bug in
desktop.  In particular, it is ill defined whilst transient-mark-mode is
not enabled.  Because "active" is here a purely conventional label,
disconnected from its normal semantics, hackers get confused as to what
they really mean by it.  Two competing definitions here are "highlit" and
"reacts to region commands"; one hacker understood the former meaning,
the other the latter.

I think that desktop needs to record whether a region is highlit.  Or
something like that.

Do you have definitions of (as contrasted to a discussion around) "active
region" and "active mark" that you could contribute to the Emacs manual?

> Footnotes: 

> [2]  I guess, as you say, it should record and check for
> transient-mark-mode before going ahead and highlighting regions.
> Personally, I would prefer desktop to have an option such that mark
> status is always reset across sessions.

Yes.  Maybe.  Perhaps....  transient-mark-mode is not simple.  

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Eli Zaretskii]

> Date: Wed, 8 Apr 2009 08:13:42 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Miles Bader <miles@gnu.org>, emacs-devel@gnu.org
> 
> > If the mark is non-nil, then the region exists.  The region may be
> > active, ....
> 
> What is the activity that this region does?  Does the region delete a
> block of characters?  Does the region jump to the start of the next
> defun?
> 
> Supposing you have a geologist inside a dead volcano, examining it,
> measuring it, chipping bits out of it.  You would call this an "active
> volcano", would you?

Sorry, Alan, but this goes waaaay beyond the limits of courtesy and
civilized discussion.  Stephen tried to explain the terminology to
you, and you are mocking him? why does he deserve that?

> This is a misuse of the word "active"

Any terminology misuses words to some extent.  "Active region" is a
well established terminology in Emacs, as Stephen points out, and it
will not change just because you happen to have difficulties with
agreeing with it.  You should simply get used to it.

> Do you have definitions of (as contrasted to a discussion around) "active
> region" and "active mark" that you could contribute to the Emacs manual?

That would be good, indeed.  The current Emacs manual begins talking
about these (in the "Mark" node) without defining them first.

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > This is a misuse of the word "active",

Any dictionary will quickly show that this usage of "active" is
well-known.  From dictionary.reference.com:

2. 	being in a state of existence, progress, or motion:
        active hostilities.

5. 	characterized by action, motion, volume, use, participation,
   	etc.: an active market in wheat; an active list of
   	subscribers.

reference.com doesn't mention it, but biology and biochemistry have a
very similar usage, viz. "active receptors", "active sites".

 > "Active" is the wrong word.  Possibly "Reactive" would be a
 > suitable one - a "reactive region" being one which reacts to
 > commands directed at it.

I don't think that's as good a term as "active".  The region is not an
object with methods it uses to "react" to commands.  It is an object
to which things may be done, unless it is inactive.  "Receptive
region" might be more accurate, but unfortunately there is no verb "to
receptivate".  I think documenters would mutiny if they had to write
"to activate the receptivity of the region".

 > Do you have definitions of (as contrasted to a discussion around)
 > "active region" and "active mark" that you could contribute to the
 > Emacs manual?

Not really.  As you say, transient-mark-mode is complex.  And we've
been through this discussion before, IIRC, and the XEmacs terminology
was considered inappropriate for Emacs.

To recap, XEmacs does not have a concept of "active mark" (or if that
term is used, I guess it is identical to "the mark", ie, the mark on
the top of the mark stack).  It does have two concepts of active
region, the more often used of which is `region-exists-p' (for
compatibility with code written for Emacs):

    Return t if the region exists.
    If active regions are in use (i.e. `zmacs-regions' is true), this
    means that the region is active.  Otherwise, this means that the
    user has pushed a mark in this buffer at some point in the past.

the other being `region-active-p':

    (defun region-active-p () (and zmacs-regions (region-exists-p)))

where zmacs-regions is the XEmacs equivalent to transient-mark-mode.

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

Hi, Stephen!

On Wed, Apr 08, 2009 at 06:26:13PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > This is a misuse of the word "active",

> Any dictionary will quickly show that this usage of "active" is
> well-known.  From dictionary.reference.com:

> 2. 	being in a state of existence, progress, or motion:
>         active hostilities.

> 5. 	characterized by action, motion, volume, use, participation,
>    	etc.: an active market in wheat; an active list of
>    	subscribers.

Well, hostilities kill people, and markets shift wheat around, at least
when they're of sufficient granularity.  _Processes_ can clearly be
active merely by "existing".  An active list?  OK, point to you.  ;-)

>  > "Active" is the wrong word.  Possibly "Reactive" would be a suitable
>  > one - a "reactive region" being one which reacts to commands
>  > directed at it.

> I don't think that's as good a term as "active".  The region is not an
> object with methods it uses to "react" to commands.  It is an object
> to which things may be done, unless it is inactive.  "Receptive
> region" might be more accurate, but unfortunately there is no verb "to
> receptivate".  I think documenters would mutiny if they had to write
> "to activate the receptivity of the region".

:-)  There seems to be a hole in the English language here; there doesn't
seem to be an adjective meaning "in a state in which things can be done
to it".  Maybe in Japanese?

>  > Do you have definitions of (as contrasted to a discussion around)
>  > "active region" and "active mark" that you could contribute to the
>  > Emacs manual?

> Not really.  As you say, transient-mark-mode is complex.  And we've
> been through this discussion before, IIRC, and the XEmacs terminology
> was considered inappropriate for Emacs.

Pity.  `zmacs-regions' is much less confusing than `transient-mark-mode';
the mark isn't transient, and neither is the mode.  Well, Germany was in
transient-mark-mode from 1989 to 2001, but that's something different.

> To recap, XEmacs does not have a concept of "active mark" (or if that
> term is used, I guess it is identical to "the mark", ie, the mark on
> the top of the mark stack).  It does have two concepts of active
> region, the more often used of which is `region-exists-p' (for
> compatibility with code written for Emacs):

>     Return t if the region exists.
>     If active regions are in use (i.e. `zmacs-regions' is true), this
>     means that the region is active.  Otherwise, this means that the
>     user has pushed a mark in this buffer at some point in the past.

This seems to be the interpretation intended for `mark-active' by the
hacker who created it.

> the other being `region-active-p':

>     (defun region-active-p () (and zmacs-regions (region-exists-p)))

This seems to be the interpretation of `mark-active' understood in
desktop.el.

> where zmacs-regions is the XEmacs equivalent to transient-mark-mode.

Yes.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Well, [...].

I didn't claim your usage is *wrong*, just that correct usage is not
limited to the ones you admit.

 > > [XEmacs] does have two concepts of active region, the more often
 > > used of which is `region-exists-p'
 > 
 > This seems to be the interpretation intended for `mark-active' by the
 > hacker who created it.
 > 
 > > the other being `region-active-p':
 > 
 > This seems to be the interpretation of `mark-active' understood in
 > desktop.el.

Well, that's the bug, then.  Oh, and I guess the documentation.

Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> This problem makes the default setup barely usable on a Linux virtual
> terminal; it surely must be fixed before release.

Like Miles, I find the color scheme highly usable.