region-active-p

region-active-p

[Andreas Röhler]

What about to introduce `region-active-p' and/or
`region-exists-p' for

(and mark-active transient-mark-mode)

thus enhancing portability with XEmacs, which I try
here with such a construct:

(or (and (featurep 'xemacs)
	 (region-active-p))
    (and 
     mark-active transient-mark-mode))

I'm well aware that behaviour of mark is different in
both Emacsen and thus proceeding of `(and mark-active
transient-mark-mode)' will the not be the same as in
`region-exists-p'. However, in most if not all cases
the result for the user should be comparable and
expected.


Thanks all

Andreas Röhler

Re: region-active-p

[Juri Linkov]

> What about to introduce `region-active-p' and/or
> `region-exists-p' for
>
> (and mark-active transient-mark-mode)

I think this is a good idea.  Instead of putting everywhere
a complex condition:

    (and transient-mark-mode mark-active
	 (not (eq (region-beginning) (region-end))))

`region-active-p' is much shorter.

> thus enhancing portability with XEmacs, which I try
> here with such a construct:
>
> (or (and (featurep 'xemacs)
> 	 (region-active-p))
>     (and
>      mark-active transient-mark-mode))
>
> I'm well aware that behaviour of mark is different in
> both Emacsen and thus proceeding of `(and mark-active
> transient-mark-mode)' will the not be the same as in
> `region-exists-p'. However, in most if not all cases
> the result for the user should be comparable and
> expected.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: region-active-p

[Richard Stallman]

    > What about to introduce `region-active-p' and/or
    > `region-exists-p' for

    > (and mark-active transient-mark-mode)

    I think this is a good idea.  Instead of putting everywhere
    a complex condition:

I agree.  But we need to decide whether (not (eq (region-beginning)
(region-end))) should be part of it.  The name `region-active-p'
implies that it doesn't matter whether the region is empty.

Re: region-active-p

[Stefan Monnier]

>> What about to introduce `region-active-p' and/or
>> `region-exists-p' for

>> (and mark-active transient-mark-mode)

>     I think this is a good idea.  Instead of putting everywhere
>     a complex condition:

> I agree.  But we need to decide whether (not (eq (region-beginning)
> (region-end))) should be part of it.

I think it should be part of it.  All the commands I can think of that use
this kind of feature make the command work on the selected region instead of
just "at point".  So an empty region isn't very meaningful for them.

> The name `region-active-p'
> implies that it doesn't matter whether the region is empty.

Not necessarily.  I don't consider an empty region as being really "active".


        Stefan

Re: region-active-p

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The name `region-active-p'
>> implies that it doesn't matter whether the region is empty.
>
> Not necessarily.  I don't consider an empty region as being really "active".

And in many cases an empty-but-"active" region can be pretty confusing
if you don't realize what's going on... (e.g., undo with an
empty-but-"active" region used to be _extremely_ confusing, though that
seems to have been fixed).

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: region-active-p

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> What about to introduce `region-active-p' and/or
 > >> `region-exists-p' for
 > 
 > >> (and mark-active transient-mark-mode)
 > 
 > >     I think this is a good idea.  Instead of putting everywhere
 > >     a complex condition:
 > 
 > > I agree.  But we need to decide whether (not (eq (region-beginning)
 > > (region-end))) should be part of it.
 > 
 > I think it should be part of it.  All the commands I can think of that use
 > this kind of feature make the command work on the selected region instead of
 > just "at point".  So an empty region isn't very meaningful for them.

Please implement this interpretation.  It is the interpretation used
by XEmacs since time immemorial (to me, anyway):

------------------------------------------------------------------------
`region-active-p' is a compiled Lisp function
  -- loaded from "/playpen/src/XEmacs/git-staging/lisp/simple.elc"
(region-active-p)

Documentation:
Return non-nil if the region is active in the current buffer.
If `zmacs-regions' is true, this is equivalent to `region-exists-p'.
Otherwise, this function always returns false.
------------------------------------------------------------------------

I believe `zmacs-regions' is the variable that `transient-mark-mode'
emulates.

Re: region-active-p

[Andreas Röhler]

Am Sonntag, 21. Oktober 2007 16:48 schrieb Miles Bader:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >> The name `region-active-p'
> >> implies that it doesn't matter whether the region is empty.
> >
> > Not necessarily.  I don't consider an empty region as being really
> > "active".
>
> And in many cases an empty-but-"active" region can be pretty confusing
> if you don't realize what's going on... (e.g., undo with an
> empty-but-"active" region used to be _extremely_ confusing, though that
> seems to have been fixed).
>
> -Miles

Introducing something like 

 (not (eq (region-beginning) (region-end)))

would mean a new feature for both Emacsen

AFAIS XEmacs simple.el knows two funktions

region-active-p  and region-exists-p 

where

(defsubst region-exists-p ()
  "..."
  (not (null (mark))))

relates to the state of `mark-active' in GNU, whereas

`region-active-p' delivers something near
`transient-mark-mode'

(defun region-active-p ()
  "..."
  (and zmacs-regions zmacs-region-extent
       (eq (current-buffer) (zmacs-region-buffer))))

`region-exists-p' returns t if called at a buffer with
length 1 where the mark is set. Checked with:

(defun report-region-exists-p (&optional ispec) 
   (interactive "p")
  (if ispec (message "%s" (not (null (mark)))) 
    (not (null (mark)))))

So far 

(defsubst region-exists-p ()
  "..."
  (not (null (mark))))

could be taken as is, beneath 

(defun region-active-p ()
  "..."
  (and mark-active transient-mark-mode))

Andreas Röhler	

Re: region-active-p

[Reiner Steib]

On Sun, Oct 21 2007, Stephen J. Turnbull wrote:

> Stefan Monnier writes:
>  > > I agree.  But we need to decide whether (not (eq (region-beginning)
>  > > (region-end))) should be part of it.
>  > 
>  > I think it should be part of it.  [...]
>
> Please implement this interpretation.  It is the interpretation used
> by XEmacs since time immemorial (to me, anyway):
>
> ------------------------------------------------------------------------
> `region-active-p' is a compiled Lisp function
>   -- loaded from "/playpen/src/XEmacs/git-staging/lisp/simple.elc"
> (region-active-p)
>
> Documentation:
> Return non-nil if the region is active in the current buffer.
> If `zmacs-regions' is true, this is equivalent to `region-exists-p'.
> Otherwise, this function always returns false.
> ------------------------------------------------------------------------
>
> I believe `zmacs-regions' is the variable that `transient-mark-mode'
> emulates.

FWIW, Gnus has the following compatibility functions (gnus-ems.el):

(defun gnus-region-active-p ()
  "Say whether the region is active."
  (and (boundp 'transient-mark-mode)
       transient-mark-mode
       (boundp 'mark-active)
       mark-active))

(defun gnus-mark-active-p ()
  "Non-nil means the mark and region are currently active in this buffer."
  mark-active) ; aliased to region-exists-p in XEmacs.

When running Gnus in XEmacs, these are aliased:

gnus-xmas.el:433:  (defalias 'gnus-region-active-p 'region-active-p)
gnus-xmas.el:434:  (defalias 'gnus-mark-active-p 'region-exists-p)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: region-active-p

[Andreas Röhler]

Am Sonntag, 21. Oktober 2007 16:48 schrieb Miles Bader:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >> The name `region-active-p'
> >> implies that it doesn't matter whether the region is empty.
> >
> > Not necessarily.  I don't consider an empty region as being really
> > "active".
>
> And in many cases an empty-but-"active" region can be pretty confusing
> if you don't realize what's going on... (e.g., undo with an
> empty-but-"active" region used to be _extremely_ confusing, though that
> seems to have been fixed).
>
> -Miles

That's it. I correct my posting from yesterday so far.

It makes no sence to have two forms--`exist' and
`active'-- else.

So I get two new forms:

(defsubst region-exists-p ()
 "..."
 (not (null (mark))))

(defun region-active-p ()
 "..."
 (and mark-active transient-mark-mode
  (not (eq (region-beginning) (region-end)))))

Installing both makes code in both directions
compatible at that point.

Andreas Röhler

Re: region-active-p

[Richard Stallman]

    (defun region-active-p ()
      "..."
      (and zmacs-regions zmacs-region-extent
	   (eq (current-buffer) (zmacs-region-buffer))))

When commands in XEmacs call this, do they also test
for a nonempty region?  Or do they operate on the region
when it is empty?

I don't see any need for region-exists-p
unless we want it specifically to run code in Emacs
which was written for XEmacs.

Re: region-active-p

[Andreas Röhler]

Am Dienstag, 23. Oktober 2007 09:12 schrieb Richard Stallman:
>     (defun region-active-p ()
>       "..."
>       (and zmacs-regions zmacs-region-extent
> 	   (eq (current-buffer) (zmacs-region-buffer))))
>
> When commands in XEmacs call this, do they also test
> for a nonempty region?  Or do they operate on the region
> when it is empty?

No. AFAIU `zmacs-region-extent' checks for a physical extend, it may be nil or 
have a value, for example I got

,----
| `zmacs-region-extent' is a variable declared in Lisp.
|   -- loaded from "/home/speck/progarbeit/xemacs/veraendert/simple.el"
| 
| Value: #<extent [147998, 148021] 0x8e8aa24 in buffer simple.el>
| 
| Documentation:
| The extent of the zmacs region; don't use this. 
`----


`zmacs-regions' seems equivalent to
`transient-mark-mode':

,----
| `zmacs-regions' is a built-in boolean variable.
|   -- loaded 
from "/usr/src/packages/BUILD/xemacs-21.5.27.20060705/src/editfns.c"
| 
| Value: t
| 
| Documentation:
| *Whether LISPM-style active regions should be used.
| This means that commands which operate on the region (the area between the
| point and the mark) will only work while the region is in the ``active''
| state, which is indicated by highlighting.
`----

>
> I don't see any need for region-exists-p
> unless we want it specifically to run code in Emacs
> which was written for XEmacs.

AFAIS `region-exists-p' in XEmacs delivers precisely
the value `mark-active' in GNU has.

To provide respective symbols in both Emacsen would
save time for programmers.

Maybe it could be written in GNU somehow as

(defun region-exists-p ()
  mark-active)

and in XEmacs

(setq mark-active (region-exists-p))


Andreas Röhler

Re: region-active-p

[Richard Stallman]

    > When commands in XEmacs call this, do they also test
    > for a nonempty region?  Or do they operate on the region
    > when it is empty?

    No.

What does "no" mean in this context?  (Please don't ask which part of
"no" I don't understand.)

	AFAIU `zmacs-region-extent' checks for a physical extend, it may be nil or 
    have a value, for example I got

What does "checks for a physical extend" mean?

Re: region-active-p

[Andreas Röhler]

Am Dienstag, 23. Oktober 2007 19:53 schrieb Richard Stallman:
>     > When commands in XEmacs call this, do they also test
>     > for a nonempty region?  Or do they operate on the region
>     > when it is empty?
>
>     No.
>
> What does "no" mean in this context?  (Please don't ask which part of
> "no" I don't understand.)
>

Was intended as the answer of your last question and followed be some 
explanation. Sorry if it was not clear enough.

> 	AFAIU `zmacs-region-extent' checks for a physical extend, it may be nil or
>     have a value, for example I got
>
> What does "checks for a physical extend" mean?

As "physical" I understand something that exists and
has a body, an extend. An empty buffer I understand as of no extend, but 
existing.

Thus the mark may exist whereas the region has no
extention. Thats possible with mark-active and
region-exist-p.

Therefor 

(not (eq (region-beginning) (region-end)))

as proposed by Juri for Emacs looks necessary to be
sure.

Andreas Röhler

Re: region-active-p

[Stephen J. Turnbull]

Richard Stallman writes:

 > When commands in XEmacs call [region-active-p], do they also test
 > for a nonempty region?  Or do they operate on the region
 > when it is empty?

Core commands defined in Lisp don't test (at least not within 3 lines,
checked with grep -3), but they're generally wrappers for functions
defined in C that do test (eg, the casefilling commands).

 > I don't see any need for region-exists-p
 > unless we want it specifically to run code in Emacs
 > which was written for XEmacs.

The use-case in XEmacs is that some code wishes to operate on the
region regardless of whether it is active.  All examples in XEmacs
core code are used to determine whether a menu item or dialog button
is active; I presume that the corresponding functions query the user
if the region exists but is inactive, and simply executes if the
region is active.  I don't know if there are any important uses.

Re: region-active-p

[Richard Stallman]

I cannot understand what Andreas Roehler is trying to say.
Can someone else answer my question?
       
     > When commands in XEmacs call this, do they also test
     > for a nonempty region?  Or do they operate on the region
     > when it is empty?

Re: region-active-p

[Richard Stallman]

     > When commands in XEmacs call [region-active-p], do they also test
     > for a nonempty region?  Or do they operate on the region
     > when it is empty?

    Core commands defined in Lisp don't test (at least not within 3 lines,
    checked with grep -3), but they're generally wrappers for functions
    defined in C that do test (eg, the casefilling commands).

I don't entirely understand the answer.  Maybe I did not state the
question clearly.  When you say they "don't test", what precisely
don't they test?

Are you sayimg that they call `region-active-p' but do not test
whether the region is nonempty?

Re: region-active-p

[Stephen J. Turnbull]

Richard Stallman writes:
 >      > When commands in XEmacs call [region-active-p], do they also test
 >      > for a nonempty region?  Or do they operate on the region
 >      > when it is empty?
 > 
 >     Core commands defined in Lisp don't test (at least not within 3 lines,
 >     checked with grep -3), but they're generally wrappers for functions
 >     defined in C that do test (eg, the casefilling commands).
 > 
 > I don't entirely understand the answer.  Maybe I did not state the
 > question clearly.  When you say they "don't test", what precisely
 > don't they test?

They don't test "for a nonempty region".

 > Are you sayimg that they call `region-active-p' but do not test
 > whether the region is nonempty?

Yes.

Specifically, the function that calls `region-active-p' does not.
However, in the cases I looked at, that function simply dispatches to
a more primitive function that acts on the region.  The more primitive
function checks for non-empty in those cases.  The typical idiom is

(defun fill-paragraph-or-region (arg)
  "Fill the current region, if it's active; otherwise, fill the paragraph.
See `fill-paragraph' and `fill-region' for more information."
  (interactive "*P")
  (if (region-active-p)
      (call-interactively 'fill-region)
    (call-interactively 'fill-paragraph)))

`fill-region' *does* check that the region is nonempty before doing
any work.

Re: region-active-p

[Andreas Röhler]

Am Freitag, 26. Oktober 2007 07:38 schrieben Sie:
> Richard Stallman writes:
>  >      > When commands in XEmacs call [region-active-p], do they also test
>  >      > for a nonempty region?  Or do they operate on the region
>  >      > when it is empty?
>  >
>  >     Core commands defined in Lisp don't test (at least not within 3
>  > lines, checked with grep -3), but they're generally wrappers for
>  > functions defined in C that do test (eg, the casefilling commands).
>  >
>  > I don't entirely understand the answer.  Maybe I did not state the
>  > question clearly.  When you say they "don't test", what precisely
>  > don't they test?
>
> They don't test "for a nonempty region".
>
>  > Are you sayimg that they call `region-active-p' but do not test
>  > whether the region is nonempty?
>
> Yes.
>
> Specifically, the function that calls `region-active-p' does not.


So my understanding ceased to exist... :)

 `region-active-p' reads and depends with `and' from variable

`zmacs-region-extent'.

(and  ... zmacs-region-extent

If there is no extension, just the mark set,
`zmacs-region-extent' is nil and `region-active-p'
returns nil therefor.

I would qualify this behaviour as including a check.

BTW quite other thing with `region-exist-p'.

Maybe I miss the point?

Cheers

Andreas Röhler

> However, in the cases I looked at, that function simply dispatches to
> a more primitive function that acts on the region.  The more primitive
> function checks for non-empty in those cases.  The typical idiom is
>
> (defun fill-paragraph-or-region (arg)
>   "Fill the current region, if it's active; otherwise, fill the paragraph.
> See `fill-paragraph' and `fill-region' for more information."
>   (interactive "*P")
>   (if (region-active-p)
>       (call-interactively 'fill-region)
>     (call-interactively 'fill-paragraph)))
>
> `fill-region' *does* check that the region is nonempty before doing
> any work.

Re: region-active-p

[Stephen J. Turnbull]

Andreas Röhler writes:

 > If there is no extension, just the mark set,
 > `zmacs-region-extent' is nil and `region-active-p'
 > returns nil therefor.

Right.  However, if zmacs-region-extent is non-nil, it is possible
that (region-beginning) equals (region-end), in which case there is
(usually) no point in operating on the region.  It is that check that
Richard is asking about AFAICS.

Re: region-active-p

[Andreas Röhler]

Am Freitag, 26. Oktober 2007 11:21 schrieb Stephen J. Turnbull:
> Andreas Röhler writes:
>  > If there is no extension, just the mark set,
>  > `zmacs-region-extent' is nil and `region-active-p'
>  > returns nil therefor.
>
> Right.  However, if zmacs-region-extent is non-nil, it is possible
> that (region-beginning) equals (region-end), 

If this is possible--my little check rather
contradicts--than I consider it as not congruent with
its name "extent" or a bug.

At stake are AFAIU tree different and hierarchical
conditions:

1 region exists but has no extent
2 region has extent but is not visible
3 region is visible

For appropriate names I held something like

1 region-exist-p
2 region-extent-p
3 region-visible-p

In GNU Emacs these conditions are expressed by

1 mark-active
2 (and mark-active (not (eq (region-beginning) (region-end))))
3 (and transient-mark-mode mark-active
     (not (eq (region-beginning) (region-end))))

XEmacs has AFAIS

1 region-exist-p

3 region-active-p

Andreas Röhler

> in which case there is 
> (usually) no point in operating on the region.  It is that check that
> Richard is asking about AFAICS.
>
>

Re: region-active-p

[Stephen J. Turnbull]

Andreas Röhler writes:

 > > Right.  However, if zmacs-region-extent is non-nil, it is possible
 > > that (region-beginning) equals (region-end), 
 > 
 > If this is possible--my little check rather
 > contradicts

Try "C-SPC C-x C-x M-: (list (region-beginning) (region-end)
zemacs-region-extent) RET" and you will see it is quite possible.

 > --than I consider it as not congruent with its name "extent" or a
 > bug.

Please read the documentation on extents.  Extents are *objects* with
properties.  For example, zero-length extents are the usual way to
insert images in a window that are not attached to any particular
buffer text.  I see no particular reason why an extent of zero length
should be impossible; it's the obviously limiting case.

 > At stake are AFAIU tree different and hierarchical conditions:
 > 
 > 1 region exists but has no extent
 > 2 region has extent but is not visible
 > 3 region is visible

You're using "extent" as a property of the region.  However, in XEmacs
extents are Lisp_Objects, and the test for zmacs-region-extent is a
test for whether such an object is attached to the region.  In XEmacs
2 and 3 are almost the same, because the highlighting is carried by
the extent.  The region is visible if and only if the extent exists,
with the sole exception of zero-length regions.  (It would be possible
to make them visible by adding an image to them.)

 > For appropriate names I held something like
 > 
 > 1 region-exist-p
 > 2 region-extent-p

This is not compatible with XEmacs usage of the word "extent".  You
can use it as you like, of course, but if you choose to use it in this
way you will find it very difficult to communicate with XEmacs
developers.

 > 3 region-visible-p
 > 
 > In GNU Emacs these conditions are expressed by
 > 
 > 1 mark-active
 > 2 (and mark-active (not (eq (region-beginning) (region-end))))
 > 3 (and transient-mark-mode mark-active
 >      (not (eq (region-beginning) (region-end))))
 > 
 > XEmacs has AFAIS
 > 
 > 1 region-exist-p
 > 
 > 3 region-active-p

No.  1 and XEmacs's `region-exists-p' may be equivalent (but maybe
not: if zmacs-regions is non-nil, then region exists if and only if it
is active), but `region-active-p' is surely not equivalent to 3,
because an active region can have zero length in the buffer.  I'm not
sure whether this is more useful than the definition you suggest, but
that is the way XEmacs works.

Also, for a region to be active, the buffer containing it must be
current.  I'm not sure why this test is necessary in XEmacs, or
whether it would be useful in Emacs.

Re: region-active-p

[Richard Stallman]

     > If there is no extension, just the mark set,
     > `zmacs-region-extent' is nil and `region-active-p'
     > returns nil therefor.

    Right.  However, if zmacs-region-extent is non-nil, it is possible
    that (region-beginning) equals (region-end), in which case there is
    (usually) no point in operating on the region.  It is that check that
    Richard is asking about AFAICS.

That really puzzles me.  It seems to say that in the following XEmacs code

    (defun fill-paragraph-or-region (arg)
      "Fill the current region, if it's active; otherwise, fill the paragraph.
    See `fill-paragraph' and `fill-region' for more information."
      (interactive "*P")
      (if (region-active-p)
	  (call-interactively 'fill-region)
	(call-interactively 'fill-paragraph)))

with an active but empty region, region-active-p sometimes returns t
and sometimes returns nil.  (This is because zmacs-region-extent might
be nil, or might be t and empty.)

Do I understand correctly?

Re: region-active-p

[Stephen J. Turnbull]

Richard Stallman writes:

 >      > If there is no extension, just the mark set,
 >      > `zmacs-region-extent' is nil and `region-active-p'
 >      > returns nil therefor.
 > 
 >     Right.  However, if zmacs-region-extent is non-nil, it is possible
 >     that (region-beginning) equals (region-end), in which case there is
 >     (usually) no point in operating on the region.  It is that check that
 >     Richard is asking about AFAICS.
 >
 > That really puzzles me.

`region-active-p' does not check that the region has non-zero length.

My point is that whether it makes sense to operate on a region of
length zero depends on the operation, so `region-active-p' doesn't try
to decide.

Note that Andreas and I are talking at cross-purposes to some extent,
because his usage of "extent", although impeccable as English, differs
from XEmacs terminology where it denotes a specific type of
Lisp_Object, approximately an Emacs overlay.  This confused me, and
I'm probably not responding to him in a way that's useful to him or
you.

 > It seems to say that in the following XEmacs code
 > 
 >     (defun fill-paragraph-or-region (arg)
 >       "Fill the current region, if it's active; otherwise, fill the paragraph.
 >     See `fill-paragraph' and `fill-region' for more information."
 >       (interactive "*P")
 >       (if (region-active-p)
 > 	  (call-interactively 'fill-region)
 > 	(call-interactively 'fill-paragraph)))
 > 
 > with an active but empty region, region-active-p sometimes returns t
 > and sometimes returns nil.  (This is because zmacs-region-extent might
 > be nil, or might be t and empty.)
 > 
 > Do I understand correctly?

No, if the region is active but empty (by which I mean having zero
length), `region-active-p' will return non-nil and `fill-region' will
be called.

An active region exists if and only if `zmacs-region-extent' contains
an extent object.  Code that activates the region does so by setting
`zmacs-region-extent' to an extent whose endpoints are point and mark,
and whose face property is 'zmacs-region.  Deactivation is done by
setting `zmacs-region-extent' to nil.

Re: region-active-p

[Miles Bader]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
> `region-active-p' does not check that the region has non-zero length.
>
> My point is that whether it makes sense to operate on a region of
> length zero depends on the operation, so `region-active-p' doesn't try
> to decide.

So, which operations _don't_ check?  Well, I assume there are some which
don't check, but probably should, so maybe it's more reasonable to ask,
which operations _shouldn't_ check?

-Miles

-- 
Would you like fries with that?

Re: region-active-p

[Andreas Röhler]

Am Samstag, 27. Oktober 2007 08:17 schrieb Miles Bader:
> "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
> > `region-active-p' does not check that the region has non-zero length.
> >
> > My point is that whether it makes sense to operate on a region of
> > length zero depends on the operation, so `region-active-p' doesn't try
> > to decide.
>
> So, which operations _don't_ check?  Well, I assume there are some which
> don't check, but probably should, so maybe it's more reasonable to ask,
> which operations _shouldn't_ check?
>
> -Miles

After all, checking in Juri's proposal would ease
writing GNU code and enhance compatibility. May he get
a green light?

Andreas Röhler

Re: region-active-p

[Richard Stallman]

Thanks.  Now I understand what XEmacs does here.

I propose to add an optional argument NONEMPTY to region-active-p
which means "return nil if the region is empty".  How about it?

Re: region-active-p

[Stefan Monnier]

> Thanks.  Now I understand what XEmacs does here.
> I propose to add an optional argument NONEMPTY to region-active-p
> which means "return nil if the region is empty".  How about it?

I expect the opposite makes more sense:

   (defun region-active-p (&optional allow-empty)
     "Return non-nil if the region is active.
   Optional argument ALLOW-EMPTY non-nil means that an empty region
   may also be considered as active."
     ...)

This is because in most cases we've seen we want to treat empty regions as
inactive.


        Stefan

Re: region-active-p

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I propose to add an optional argument NONEMPTY to region-active-p
>> which means "return nil if the region is empty".  How about it?
>
> I expect the opposite makes more sense:
...
> This is because in most cases we've seen we want to treat empty regions as
> inactive.

I agree, but is this sufficiently compatible with xemacs?

[I don't think they actually have strictly the same behavior -- if the use
of empty regions is vanishingly rare, then who cares...]

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: region-active-p

[Stefan Monnier]

> I agree, but is this sufficiently compatible with xemacs?

Close enough: the differences should only affect the users, but not the
package authors.


        Stefan

Re: region-active-p

[Stephen J. Turnbull]

Miles Bader writes:

 > So, which operations _don't_ check?  Well, I assume there are some which
 > don't check, but probably should, so maybe it's more reasonable to ask,
 > which operations _shouldn't_ check?

As I wrote before, these APIs seem to be mainly used for interactive
DWIM-type functions where you can either specify a region or let
XEmacs guess a region for you.  I can't think of an operation that
*shouldn't* check offhand, but if there is one, it would be a bad idea
for these APIs to check because they wouldn't work with such an API if
they did.  Since they're only used interactively AFAIK, postponing the
check to the function that actually does the work is no big loss.

Re: region-active-p

[Stephen J. Turnbull]

Richard Stallman writes:

 > Thanks.  Now I understand what XEmacs does here.
 > 
 > I propose to add an optional argument NONEMPTY to region-active-p
 > which means "return nil if the region is empty".  How about it?

No, thank you.  That makes the name inaccurate in XEmacs usage, is not
backwardly compatible (unlike GNU, we support older versions of XEmacs
which will not support that argument), is IMO less readable than using
an explicit check where the optimization is appropriate and needed,
and as far as I know is redundant in current XEmacsen because functions
where the check is appropriate already do it (typically very quickly
because they do it in C).

A new API defaulting to the semantics of `region-exists-p' would be
preferable.  (Not `region-active-p', since the former makes sense to
the user regardless of whether zmacs-regions/transient-mark-mode is
active.)

Re: region-active-p

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> I can't think of an operation that *shouldn't* check offhand, but if
> there is one, it would be a bad idea for these APIs to check because
> they wouldn't work with such an API if they did.  Since they're only
> used interactively AFAIK, postponing the check to the function that
> actually does the work is no big loss.

It's not a "big loss" but it is silly bloat.  Putting the check in the
common function will also likely reduce bugs because it will avoid the
case where the function writer forgets to do the extra check (and as
undo has shown, _not_ checking can be quite confusing).

If we're going for 100% rigid API compatibility, even in the most
obscure corner cases, then of course it shouldn't check.  But I'm not
sure we are.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: region-active-p

[Johan Bockgård]

Miles Bader <miles@gnu.org> writes:

> So, which operations _don't_ check?  Well, I assume there are some which
> don't check, but probably should, so maybe it's more reasonable to ask,
> which operations _shouldn't_ check?

Keyboard macros might get in trouble if Emacs tries to be clever about
empty regions.

-- 
Johan Bockgård

Re: region-active-p

[Stefan Monnier]

> where the check is appropriate already do it (typically very quickly
> because they do it in C).

Speed is 100% irrelevant here: we're talking about a handful of non-looping
operations executed for interactive calls.


        Stefan

Re: region-active-p

[Stefan Monnier]

>> So, which operations _don't_ check?  Well, I assume there are some which
>> don't check, but probably should, so maybe it's more reasonable to ask,
>> which operations _shouldn't_ check?

> Keyboard macros might get in trouble if Emacs tries to be clever about
> empty regions.

I doubt it'll make any real difference.


        Stefan

Re: region-active-p

[Stefan Monnier]

> Keyboard macros might get in trouble if Emacs tries to be clever about
> empty regions.

That is irrelevant: we're talking about *where* to put the empty-region
check, not about whether to tput it in or not.


        Stefan

Re: region-active-p

[Richard Stallman]

I just double-checked.  What we want for Emacs is closer to your
`region-active-p'.  We want it to test for Transient Mark mode with
the mark active.

     > I propose to add an optional argument NONEMPTY to region-active-p
     > which means "return nil if the region is empty".  How about it?

    No, thank you.  That makes the name inaccurate in XEmacs usage, is not
    backwardly compatible

I don't know how to understand "backwardly compatible".  I designed
this to make it an upward compatible change for you.  Does "backwardly
compatible" mean something else?

Re: region-active-p

[Richard Stallman]

    I expect the opposite makes more sense:

       (defun region-active-p (&optional allow-empty)
	 "Return non-nil if the region is active.
       Optional argument ALLOW-EMPTY non-nil means that an empty region
       may also be considered as active."
	 ...)

    This is because in most cases we've seen we want to treat empty regions as
    inactive.

I agree this would be better.  I made my proposal the way I did
because it is an upward compatible change for XEmacs.  But if that is
not a factor in the decision, let's define the argument as you suggest.

Re: region-active-p

[Stefan Monnier]

>     I expect the opposite makes more sense:
>        (defun region-active-p (&optional allow-empty)
> 	 "Return non-nil if the region is active.
>        Optional argument ALLOW-EMPTY non-nil means that an empty region
>        may also be considered as active."
> 	 ...)

>     This is because in most cases we've seen we want to treat empty regions as
>     inactive.

> I agree this would be better.  I made my proposal the way I did
> because it is an upward compatible change for XEmacs.  But if that is
> not a factor in the decision, let's define the argument as you suggest.

As I said elsewhere, I do not think compatibility is an issue because the
potential difference will only cause different behavior for the user, but
will not cause bugs.


        Stefan

Re: region-active-p

[Andreas Röhler]

Am Sonntag, 28. Oktober 2007 08:29 schrieb Stephen J. Turnbull:
> Richard Stallman writes:
>  > Thanks.  Now I understand what XEmacs does here.
>  >
>  > I propose to add an optional argument NONEMPTY to region-active-p
>  > which means "return nil if the region is empty".  How about it?
>
> No, thank you.  That makes the name inaccurate in XEmacs usage, is not
> backwardly compatible (unlike GNU, we support older versions of XEmacs
> which will not support that argument), is IMO less readable than using
> an explicit check where the optimization is appropriate and needed,
> and as far as I know is redundant in current XEmacsen because functions
> where the check is appropriate already do it (typically very quickly
> because they do it in C).
>
> A new API defaulting to the semantics of `region-exists-p' would be
> preferable.  (Not `region-active-p', 


For compatibility we should have both. 

(defun region-exists-p ()
  mark-active)

and

 (defun region-active-p (&optional allow-empty)
...

Andreas Röhler

> since the former makes sense to 
> the user regardless of whether zmacs-regions/transient-mark-mode is
> active.)

Re: region-active-p

[Stephen J. Turnbull]

Richard Stallman writes:

 > I just double-checked.  What we want for Emacs is closer to your
 > `region-active-p'.  We want it to test for Transient Mark mode with
 > the mark active.
 > 
 >      > I propose to add an optional argument NONEMPTY to region-active-p
 >      > which means "return nil if the region is empty".  How about it?
 > 
 >     No, thank you.  That makes the name inaccurate in XEmacs usage, is not
 >     backwardly compatible
 > 
 > I don't know how to understand "backwardly compatible".  I designed
 > this to make it an upward compatible change for you.  Does "backwardly
 > compatible" mean something else?

Upwardly compatible, yes, but code that uses that argument cannot be
used in current XEmacsen.  The OP, Andreas Roehler, is specifically
going to want to use it, because those are his preferred semantics.
From the point of view of XEmacs, the additional argument is a clear
nuisance because most of the early uses are presumably going to be by
third parties wishing to eliminate a source of incompatibility, and
they're going to be disappointed.

If you plan to use this API generally in Emacs, then I guess XEmacs
compatibility is a secondary consideration.  If so I would prefer that
you use a different name and the semantics for the argument that
Stefan proposed (or no argument if you also add `region-exists-p' with
XEmacs's semantics).  Then we can add it to XEmacs with less testing
than changing an API, you better semantics (and can ignore the XEmacs
APIs that have semantics that don't look useful to Emacs), and Andreas
gets the semantics that are intuitive to him.

Possible names are `region-usable-p' and `region-nonempty-p'.

Re: region-active-p

[Richard Stallman]

    If you plan to use this API generally in Emacs, then I guess XEmacs
    compatibility is a secondary consideration.  If so I would prefer that
    you use a different name and the semantics for the argument that
    Stefan proposed

I'm not wedded to any particular name.

    Possible names are `region-usable-p' and `region-nonempty-p'.

Neither one fits quite right.  Whether the region is active is more
central to the meaning than whether it is nonempty.

Perhaps `region-overrides-p' is a good name.  The decision is whether
the region should override the normal meaning of the command.

I invite other suggestions.

Re: region-active-p

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     If you plan to use this API generally in Emacs, then I guess XEmacs
>     compatibility is a secondary consideration.  If so I would prefer that
>     you use a different name and the semantics for the argument that
>     Stefan proposed
>
> I'm not wedded to any particular name.
>
>     Possible names are `region-usable-p' and `region-nonempty-p'.
>
> Neither one fits quite right.  Whether the region is active is more
> central to the meaning than whether it is nonempty.
>
> Perhaps `region-overrides-p' is a good name.  The decision is whether
> the region should override the normal meaning of the command.
>
> I invite other suggestions.

region-effective-p

I am quite unconvinced that it is a good idea to differentiate the
non-empty case, however.  It is just begging for a wagonload of
commands that behave inconsistently, depending on what the programmer
happened to pick for checking the region.

I think that for Emacs, we should stay with the equivalent of (and
transient-mark-mode mark-active).  If that introduces some slight user
level incompatibility with XEmacs, this is hardly tragic:
zmacs-regions is different from Emacs' region handling, anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: region-active-p

[Drew Adams]

> I'm not wedded to any particular name. Possible names are
> `region-usable-p' and `region-nonempty-p'.
> Neither one fits quite right.  Whether the region is active is more
> central to the meaning than whether it is nonempty.
> Perhaps `region-overrides-p' is a good name.  The decision is whether
> the region should override the normal meaning of the command.
> I invite other suggestions.

transient-region-p?

BTW, what's the reason for creating this, again? I thought this was about
harmonizing with XEmacs somehow. Now that doesn't seem possible. What's
wrong with just (and mark-active transient-mark-mode)? that's short and
leaves no doubt about the meaning.

Re: region-active-p

[Stefan Monnier]

>> I'm not wedded to any particular name. Possible names are
>> `region-usable-p' and `region-nonempty-p'.
>> Neither one fits quite right.  Whether the region is active is more
>> central to the meaning than whether it is nonempty.
>> Perhaps `region-overrides-p' is a good name.  The decision is whether
>> the region should override the normal meaning of the command.
>> I invite other suggestions.

> transient-region-p?

> BTW, what's the reason for creating this, again? I thought this was about
> harmonizing with XEmacs somehow. Now that doesn't seem possible. What's
> wrong with just (and mark-active transient-mark-mode)? that's short and
> leaves no doubt about the meaning.

I thought the whole point was to add region-emptyness checking in there
as well (and potentially more, to account for things like a region that
has just been selected with the mouse).


        Stefan

RE: region-active-p

[Drew Adams]

> >> I'm not wedded to any particular name. Possible names are
> >> `region-usable-p' and `region-nonempty-p'.
> >> Neither one fits quite right.  Whether the region is active is more
> >> central to the meaning than whether it is nonempty.
> >> Perhaps `region-overrides-p' is a good name.  The decision is whether
> >> the region should override the normal meaning of the command.
> >> I invite other suggestions.
>
> > transient-region-p?
>
> > BTW, what's the reason for creating this, again? I thought this
> > was about harmonizing with XEmacs somehow. Now that doesn't seem
possible.
> > What's wrong with just (and mark-active transient-mark-mode)? that's
short
> > and leaves no doubt about the meaning.
>
> I thought the whole point was to add region-emptyness checking in there
> as well (and potentially more, to account for things like a region that
> has just been selected with the mouse).

Oh, right; I forgot.

A short name probably won't capture all 3 things this is a conjunction of:
(1) tmm mode, (2) mark-active, (3) point diff from mark. The last can
probably be dropped from the name, so perhaps `transient-region-p'?

Whatever the name is, the doc string should make 1,2,3 clear.

Also, I don't follow your remark in parens - could you elaborate?

Re: region-active-p

[Stefan Monnier]

>> I thought the whole point was to add region-emptyness checking in there
>> as well (and potentially more, to account for things like a region that
>> has just been selected with the mouse).

> Oh, right; I forgot.

> A short name probably won't capture all 3 things this is a conjunction of:
> (1) tmm mode, (2) mark-active, (3) point diff from mark. The last can
> probably be dropped from the name, so perhaps `transient-region-p'?

> Whatever the name is, the doc string should make 1,2,3 clear.

> Also, I don't follow your remark in parens - could you elaborate?

Hmm.... [grepping frantically] ... oh I have it, it's in skeleton.el:

                          (or (eq last-command 'mouse-drag-region)
			      (and transient-mark-mode mark-active))

-- Stefan

RE: region-active-p

[Drew Adams]

> >> I thought the whole point was to add region-emptyness checking in there
> >> as well (and potentially more, to account for things like a region that
> >> has just been selected with the mouse).
>
> > Oh, right; I forgot.
> > A short name probably won't capture all 3 things this is a
> > conjunction of: (1) tmm mode, (2) mark-active, (3) point diff
> > from mark. The last can probably be dropped from the name, so
> > perhaps `transient-region-p'?
>
> > Whatever the name is, the doc string should make 1,2,3 clear.
> > Also, I don't follow your remark in parens - could you elaborate?
>
> Hmm.... [grepping frantically] ... oh I have it, it's in skeleton.el:
>
>                           (or (eq last-command 'mouse-drag-region)
> 			      (and transient-mark-mode mark-active))

Thanks for frantically searching, but I still don't understand. Do you think
that should be added to the function we're discussing now
(`transient-region-p' or whatever we call it)? If so, why?

Re: region-active-p

[Stefan Monnier]

>> Hmm.... [grepping frantically] ... oh I have it, it's in skeleton.el:
>> 
>> (or (eq last-command 'mouse-drag-region)
>> (and transient-mark-mode mark-active))

> Thanks for frantically searching, but I still don't understand. Do you think
> that should be added to the function we're discussing now
> (`transient-region-p' or whatever we call it)? If so, why?

Don't know.


        Stefan

Re: region-active-p

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> A short name probably won't capture all 3 things this is a conjunction of:
> (1) tmm mode, (2) mark-active, (3) point diff from mark. The last can
> probably be dropped from the name, so perhaps `transient-region-p'?

I dunno, I think most of these "alternative" names are not very good.

Part of the problem is that "transient-mark-mode" is not a particularly
clear name itself; it's one of those names that, if you sit down and
think about it, you can kind of see where it came from, but it's
... awkward.  Oh well, tmm is too embedded to change, but we should aim
to use more intuitive names for new interfaces.

"region-active-p" is by contrast, a really good name:  I think it very
naturally captures the "sense" of what it does, even to someone not
entirely clear with the details of Emacs mark/region handling.

Personally I think we should just use region-active-p, with non-empty
test by default -- the incompatibility with xemacs is minor, and I think
it's far more important that the code in Emacs be clear.  I'm sure
package authors can cope in those (very few) cases where it actually
makes any difference.

> Whatever the name is, the doc string should make 1,2,3 clear.

Very true.

-Miles

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: region-active-p

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> Personally I think we should just use region-active-p, with non-empty
> test by default -- the incompatibility with xemacs is minor, and I
> think it's far more important that the code in Emacs be clear.  I'm
> sure package authors can cope in those (very few) cases where it
> actually makes any difference.

But the standard test _is_ (and transient-make-mode mark-active) and has
been so for eternities.  And it will stay that way for external packages
for a long time to come.  So we will get inconsistent behavior.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: region-active-p

[Richard Stallman]

    I think that for Emacs, we should stay with the equivalent of (and
    transient-mark-mode mark-active).

I've already decided that question and I will not reopen it.

Re: region-active-p

[Richard Stallman]

    BTW, what's the reason for creating this, again?

Simplicity and avoidance of errors.

						     I thought this was about
    harmonizing with XEmacs somehow.

No, that's just a secondary issue affecting how to do it.

Re: region-active-p

[Richard Stallman]

    transient-region-p?

That name seems ok to me.  But I think that `region-overrides-p'
hits it more accurately.

Re: region-active-p

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
>> Personally I think we should just use region-active-p, with non-empty
>> test by default -- the incompatibility with xemacs is minor, and I
>> think it's far more important that the code in Emacs be clear.  I'm
>> sure package authors can cope in those (very few) cases where it
>> actually makes any difference.
>
> But the standard test _is_ (and transient-make-mode mark-active) and has
> been so for eternities.  And it will stay that way for external packages
> for a long time to come.  So we will get inconsistent behavior.

Who cares?  In most cases, the new behavior is _better_.

In other words, it seems likely that the number of times a user is
_helped_ because the new behavior is more intuitive, will exceed the
number of times a user is confused because the behavior is not 100% the
same as it was previously.

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: region-active-p

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> That name seems ok to me.  But I think that `region-overrides-p'
> hits it more accurately.

Overrides what?

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: region-active-p

[Richard Stallman]

    > That name seems ok to me.  But I think that `region-overrides-p'
    > hits it more accurately.

    Overrides what?

Overrides the command's usual behavior.

Re: region-active-p

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     > That name seems ok to me.  But I think that `region-overrides-p'
>     > hits it more accurately.
>
>     Overrides what?
>
> Overrides the command's usual behavior.

Perhaps that's how it's usually used, but to name the predicate based on
that seems sort of weird.

If I see code like:

   (if (region-active-p)
       ...do-this...
       ...do-that...)

It seems fairly clear to me what's going on (I'm assuming that people
can intuitively grasp the idea of an active region -- given the
commonness of this concept, and the suggestivenss of the term, I think
they can).

But this:

   (if (region-overrides-p)
       ...do-this...
       ...do-that...)

(1) Obscures the fact that the _reason_ for overriding the is that the
    region is active.  It sounds "arbitrary".

    In fact, upon first seeing it, it sounds like maybe there might be a
    "region-override" flag somewhere which controls the behavior, or
    that the rules were too complex to find a good intuitive name, and
    one must examine `region-override-p' to see what the actual rules
    are (I don't think this is true -- I think the _concept_ is pretty
    concise).  This makes the code harder to understand.

(2) It requires the concept of "usual" behavior to be understood,
    whereas a name phrased in terms.  Perhaps in many cases that's OK,
    but it seems like an unnecessary bit of extra information one is
    required to know.

    One can imagine a command where the "usual" case the active-region
    case, but which also has a useful non-active behavior.  For a
    command like this, the name "overrides" is awkward.

Anyway, what I'm trying to say is that a name like `region-override-p'
makes code harder to understand.

-Miles

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

Re: region-active-p

[Stefan Monnier]

> Anyway, what I'm trying to say is that a name like `region-override-p'
> makes code harder to understand.

For what it's worth, I agree 100%,


        Stefan

Re: region-active-p

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Anyway, what I'm trying to say is that a name like `region-override-p'
>> makes code harder to understand.
>
> For what it's worth, I agree 100%,

FWIW, me too.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

RE: region-active-p

[Drew Adams]

> >> Anyway, what I'm trying to say is that a name like `region-override-p'
> >> makes code harder to understand.
> >
> > For what it's worth, I agree 100%,
> 
> FWIW, me too.

FWIW, another.

Re: region-active-p

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> >> Anyway, what I'm trying to say is that a name like `region-override-p'
>> >> makes code harder to understand.
>> >
>> > For what it's worth, I agree 100%,
>> 
>> FWIW, me too.
>
> FWIW, another.

What about region-given-p or region-specified-p or region-selected-p?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: region-active-p

[Richard Stallman]

    > Overrides the command's usual behavior.

    Perhaps that's how it's usually used, but to name the predicate based on
    that seems sort of weird.

It is not weird to name a function based on the job you do with it.

The other good names cause practical problems which have already been
explained.

Re: region-active-p

[Richard Stallman]

    What about region-given-p or region-specified-p or region-selected-p?

Those talk more specifically about the preexisting situation
rather than about the action to be taken.  And they are partly
inaccurate about what they say about the situation.  For that
reason I don't like them.

Re: region-active-p

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     > Overrides the command's usual behavior.
>
>     Perhaps that's how it's usually used, but to name the predicate based on
>     that seems sort of weird.
>
> It is not weird to name a function based on the job you do with it.

It's not very helpful for elisp hackers, however -- to understand what's
going on, they must go and read the source code to the function in
question -- whereas a better name _does_ help them.

If you see:

   (if (i-should-jump-p) (jump))

That really tells you nothing about the reasons for jumping (you need to
read i-should-jump-p to find out), whereas:

   (if (im-really-depressed-p) (jump))

tells you why in a glance; to find out all the gory details you need to
read more, but until you do that, you still have a good general idea.

The former style can be desirable if the details of should-jump-p in
fact are very complicated (not summarizable by a single phrase) or might
change often though user-customization or whatever.  Still, one has to
weigh flexibility against clarity in deciding which style to use.

> The other good names cause practical problems which have already been
> explained.

Well then why not pick _another_ good name which is still helpful to the
code reader?  David Kastrup suggested `region-selected-p', which seems
intuitive and helpful in the same way that region-active-p is.

-Miles

-- 
The automobile has not merely taken over the street, it has dissolved the
living tissue of the city.  Its appetite for space is absolutely insatiable;
moving and parked, it devours urban land, leaving the buildings as mere islands
of habitable space in a sea of dangerous and ugly traffic.
[James Marston Fitch, New York Times, 1 May 1960]

Re: region-active-p

[Richard Stallman]

    Well then why not pick _another_ good name which is still helpful to the
    code reader?  David Kastrup suggested `region-selected-p', which seems
    intuitive and helpful in the same way that region-active-p is.

I won't argue against `region-selected-p', even though it seems
less on the mark than `region-active-p'.

Re: region-active-p

[Stefan Monnier]

>     Well then why not pick _another_ good name which is still helpful to the
>     code reader?  David Kastrup suggested `region-selected-p', which seems
>     intuitive and helpful in the same way that region-active-p is.

> I won't argue against `region-selected-p', even though it seems
> less on the mark than `region-active-p'.

Both sounds good to me,


        Stefan

Re: region-active-p

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Well then why not pick _another_ good name which is still helpful to the
>     code reader?  David Kastrup suggested `region-selected-p', which seems
>     intuitive and helpful in the same way that region-active-p is.
>
> I won't argue against `region-selected-p', even though it seems
> less on the mark than `region-active-p'.

Actually I prefer `region-active-p' too, as long as the slight
inconsistency with the xemacs definition is OK (I think it is,
personally).

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: region-active-p

[Richard Stallman]

    Actually I prefer `region-active-p' too, as long as the slight
    inconsistency with the xemacs definition is OK (I think it is,
    personally).

The function should have an argument which says
whether an empty region should count as "selected".
They asked us to use a name that is new.

Re: region-active-p

[Stephen J. Turnbull]

Miles Bader writes:

 > Personally I think we should just use region-active-p, with non-empty
 > test by default

We and 3rd party library developers will get bug reports when people
write libraries that depend on Emacs semantics.  Please don't use this
identifier with default semantics that differ from XEmacs's; there is
no need to do so.

Re: region-active-p

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> The function should have an argument which says
> whether an empty region should count as "selected".
> They asked us to use a name that is new.

Ok, then let's use `region-selected-p'...

-Miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: region-active-p

[Richard Stallman]

I came up with a better solution to the question of what region-active-p
should do when the region is empty: make it a user option.
I think that will make people happy, because I expect most users will
have the same preference for all the commands.

I will install it when I have a good connection.

Re: region-active-p

[Andreas Röhler]

Am Dienstag, 11. Dezember 2007 00:08 schrieb Richard Stallman:
> I came up with a better solution to the question of what region-active-p
> should do when the region is empty: make it a user option.
> I think that will make people happy, because I expect most users will
> have the same preference for all the commands.
>
> I will install it when I have a good connection.
>
>

That certainly wouldn't be wrong on the logical level,
however can't help in original case, reduces
compatibilty rather than enhances them.

My idea was to make the writing of compatible code a
little bit easier, to get rid of one of these (featurep
'xemacs) forms occasionally.

If you could ask Juri to install his answer we will all
live in a better world. :)

Andreas Röhler

Re: region-active-p

[Andreas Röhler]

Am Dienstag, 11. Dezember 2007 00:08 schrieb Richard Stallman:
> I came up with a better solution to the question of what region-active-p
> should do when the region is empty: make it a user option.
> I think that will make people happy, because I expect most users will
> have the same preference for all the commands.
>
> I will install it when I have a good connection.
>
>

To be more precisely: For the special case "region
exist but empty" XEmacs has already the function
`region-exists-p'. `region-active-p' fails in
that case and I see no reason to make things more
complicated at this point.

It's quite easy to follow in both cases, remaining
differences caused by routines below will not be
remarkable by users as was stated correctly.

Andreas Röhler

Re: region-active-p

[Juri Linkov]

>> I came up with a better solution to the question of what region-active-p
>> should do when the region is empty: make it a user option.
>> I think that will make people happy, because I expect most users will
>> have the same preference for all the commands.
>>
>> I will install it when I have a good connection.
>
> That certainly wouldn't be wrong on the logical level,
> however can't help in original case, reduces
> compatibilty rather than enhances them.
>
> My idea was to make the writing of compatible code a
> little bit easier, to get rid of one of these (featurep
> 'xemacs) forms occasionally.
>
> If you could ask Juri to install his answer we will all
> live in a better world. :)

I proposed:

(defun region-active-p ()
    (and transient-mark-mode mark-active
	 (not (eq (region-beginning) (region-end)))))

And as I understand, Richard wants:

(defun region-active-p ()
    (and transient-mark-mode mark-active
	 (if some-new-user-option
             (not (eq (region-beginning) (region-end))))))

This seems like a good solution.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: region-active-p

[Juri Linkov]

>> I came up with a better solution to the question of what region-active-p
>> should do when the region is empty: make it a user option.
>> I think that will make people happy, because I expect most users will
>> have the same preference for all the commands.
>>
>> I will install it when I have a good connection.
>
> To be more precisely: For the special case "region
> exist but empty" XEmacs has already the function
> `region-exists-p'. `region-active-p' fails in
> that case and I see no reason to make things more
> complicated at this point.
>
> It's quite easy to follow in both cases, remaining
> differences caused by routines below will not be
> remarkable by users as was stated correctly.

`region-exists-p' in XEmacs would be equivalent in Emacs to:

(defun region-exists-p ()
    (not (null mark-active)))

I don't see how this is comparable to `region-active-p'
with "region exist but empty" in Emacs.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: region-active-p

[Andreas Röhler]

Am Dienstag, 11. Dezember 2007 10:59 schrieb Juri Linkov:
> >> I came up with a better solution to the question of what region-active-p
> >> should do when the region is empty: make it a user option.
> >> I think that will make people happy, because I expect most users will
> >> have the same preference for all the commands.
> >>
> >> I will install it when I have a good connection.
> >
> > To be more precisely: For the special case "region
> > exist but empty" XEmacs has already the function
> > `region-exists-p'. `region-active-p' fails in
> > that case and I see no reason to make things more
> > complicated at this point.
> >
> > It's quite easy to follow in both cases, remaining
> > differences caused by routines below will not be
> > remarkable by users as was stated correctly.
>
> `region-exists-p' in XEmacs would be equivalent in Emacs to:
>
> (defun region-exists-p ()
>     (not (null mark-active)))
>
Yes, and that's the second useful thing here, thanks.

> I don't see how this is comparable to `region-active-p'
> with "region exist but empty" in Emacs.

Because if a "region exist but empty" returns `t', the
mark must be set, nothing more is required. That's
precisely the question, `mark-active' and
`region-exists-p' are answering.


Andreas Röhler

Re: region-active-p

[Andreas Röhler]

Am Dienstag, 11. Dezember 2007 10:57 schrieb Juri Linkov:
> >> I came up with a better solution to the question of what region-active-p
> >> should do when the region is empty: make it a user option.
> >> I think that will make people happy, because I expect most users will
> >> have the same preference for all the commands.
> >>
> >> I will install it when I have a good connection.
> >
> > That certainly wouldn't be wrong on the logical level,
> > however can't help in original case, reduces
> > compatibilty rather than enhances them.
> >
> > My idea was to make the writing of compatible code a
> > little bit easier, to get rid of one of these (featurep
> > 'xemacs) forms occasionally.
> >
> > If you could ask Juri to install his answer we will all
> > live in a better world. :)
>
> I proposed:
>
> (defun region-active-p ()
>     (and transient-mark-mode mark-active
> 	 (not (eq (region-beginning) (region-end)))))
>
> And as I understand, Richard wants:
>
> (defun region-active-p ()
>     (and transient-mark-mode mark-active
> 	 (if some-new-user-option
>              (not (eq (region-beginning) (region-end))))))
>
> This seems like a good solution.


That new design of `region-active-p' would permit
behaving as `region-exists-p',

the result therefor will not be comparable with XEmacs,
even if it will differ only on a mince level. GNU user
then is able to allow something, which in not allowed
in XE, where to be `active' region _must_ have an
extend.

But why introduce new diffs? If there is a need I will
change my mind.

Until then I see two practical cases: 

- a region with an extend is needed
- if mark is set it's sufficient

Both questions are served already. For case two
`mark-active' or `region-exists-p' are enough, case one
is perfect answered with `region-active-p' in it's
comparable variant.

BTW if something deserves a `new-user-option' here, IMO
it's `transient-mark-mode', because to permit highlighting or not
has not really a meaning about the existence of the
region.

Then I come to this

(defun region-active-p ()
  (if user-requires-transient-mark-mode
      (and transient-mark-mode mark-active
	   (not (eq (region-beginning) (region-end))))
    (not (eq (region-beginning) (region-end)))))


Andreas Röhler

Re: region-active-p

[Stefan Monnier]

> But why introduce new diffs? If there is a need I will
> change my mind.

Diferences of behavior are perfectly fine.  The differences we do not
want are differences which break elisp code (i.e. packages).  I see no
indication that this kind of difference will ever break elisp code.


        Stefan

Re: region-active-p

[Andreas Röhler]

Am Dienstag, 11. Dezember 2007 15:55 schrieb Stefan Monnier:
> > But why introduce new diffs? If there is a need I will
> > change my mind.
>
> Diferences of behavior are perfectly fine.  The differences we do not
> want are differences which break elisp code (i.e. packages).  I see no
> indication that this kind of difference will ever break elisp code.
>
>
>         Stefan
>

A bug then may occur at XEmacs-side if someone codes
the need for an exclusive `mark-active'/region-exists-p
with `region-active-p useroption'. XEmacs will not know
about that option, only reads `region-active-p' and
decision may be wrong.

XEmacs will always check for an extend if
`region-active-p' is written and maybe return `nil' in
cases, where it's not TRT.

Andreas Röhler

Re: region-active-p

[Stefan Monnier]

>> > But why introduce new diffs? If there is a need I will
>> > change my mind.
>> 
>> Diferences of behavior are perfectly fine.  The differences we do not
>> want are differences which break elisp code (i.e. packages).  I see no
>> indication that this kind of difference will ever break elisp code.

> A bug then may occur at XEmacs-side if someone codes
> the need for an exclusive `mark-active'/region-exists-p
> with `region-active-p useroption'. XEmacs will not know
> about that option, only reads `region-active-p' and
> decision may be wrong.

> XEmacs will always check for an extend if
> `region-active-p' is written and maybe return `nil' in
> cases, where it's not TRT.

You talk about the user-level behavior.  Reread what I wrote.


        Stefan