Should undefined behavior be encouraged in Emacs?

Should undefined behavior be encouraged in Emacs?

[Paul Eggert]

Bug#9642 has raised a question about Emacs design philosophy.

Some Emacs built-ins treat an out-of-range argument as the nearest
value in range.  For example, (goto-char -5) acts like (goto-char 1),
and (make-overlay -5 1) acts like (make-overlay 1 1), because -5
is out of the range of valid buffer positions.  Other built-ins
signal an exception: for example, (aref "abc" -5) signals an
error, and (forward-char -5) signals an error at buffer start.
And still others wrap around: for example, (- most-negative-fixnum)
yields most-negative-fixnum.

A recent comment in Bug#9642 advocates another approach: undefined
behavior.  For example, it proposes that move-overlay should have
undefined behavior when given arguments like -5 that are out of
range.  In other words, (move-overlay OVERLAY -5 1) might signal
an error, or substitute an in-range value, or wrap around, or
return a data structure that subtly violates some other guarantee
made by Emacs; or it might do one of these things sometimes and
another at other times.  In short, undefined behavior means that
move-overlay might do *anything* when given out-of-range
arguments.

The argument given for undefined behavior is that it simplifies
maintenance of Emacs internals.

My impression is that Emacs built-ins are generally supposed to
have defined behavior, so that Emacs is easier to use reliably.
But another developer apparently disagrees, so thought I'd ask on
emacs-devel for further comments.

Here's the a pointer to the abovementioned comment:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9642#23

Re: Should undefined behavior be encouraged in Emacs?

[Stefan Monnier]

> The argument given for undefined behavior is that it simplifies
> maintenance of Emacs internals.

I like to keep some corner of the behavior undefined, when I think
that user code that depends on such details is undesirable (e.g. return
values of primitives which are only called for side-effects).


        Stefan

Re: Should undefined behavior be encouraged in Emacs?

[Andreas Röhler]

Am 03.10.2011 05:11, schrieb Stefan Monnier:
>> The argument given for undefined behavior is that it simplifies
>> maintenance of Emacs internals.
>
> I like to keep some corner of the behavior undefined, when I think
> that user code that depends on such details is undesirable (e.g. return
> values of primitives which are only called for side-effects).
>
>
>          Stefan
>
>

Hi,

my bet: undefined behavior sources bugs, makes maintenance difficult.

Design at the user level certainly deserves a separate approach. It's up 
to implement convenient error-handling than rather than undefined behavior.

Cheers,

Andreas

Re: Should undefined behavior be encouraged in Emacs?

[Stephen J. Turnbull]

Andreas Röhler writes:
 > Am 03.10.2011 05:11, schrieb Stefan Monnier:
 > >> The argument given for undefined behavior is that it simplifies
 > >> maintenance of Emacs internals.
 > >
 > > I like to keep some corner of the behavior undefined, when I think
 > > that user code that depends on such details is undesirable (e.g. return
 > > values of primitives which are only called for side-effects).

 > my bet: undefined behavior sources bugs, makes maintenance difficult.
 > 
 > Design at the user level certainly deserves a separate approach. It's up 
 > to implement convenient error-handling than rather than undefined behavior.

I don't know about convenient error-*handling*, but if Stefan wants to
prevent people from using the value of primitives called only for
side-effects, he can always provide "convenient error generation" by
having such primitives return Qunbound (or whatever it's called in
Emacs sources: the special uninterned symbol placed in the value slot
of an uninitialized symbol).

;-) ** 100

Re: Should undefined behavior be encouraged in Emacs?

[Andreas Schwab]

I don't think Emacs should have undefined behaviour.  It may have
unspecified behaviour (ie. it may change any time), but the result
should always be consistent with the documented rules.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Should undefined behavior be encouraged in Emacs?

[Andreas Röhler]

Am 03.10.2011 09:29, schrieb Stephen J. Turnbull:
> Andreas Röhler writes:
>   >  Am 03.10.2011 05:11, schrieb Stefan Monnier:
>   >  >>  The argument given for undefined behavior is that it simplifies
>   >  >>  maintenance of Emacs internals.
>   >  >
>   >  >  I like to keep some corner of the behavior undefined, when I think
>   >  >  that user code that depends on such details is undesirable (e.g. return
>   >  >  values of primitives which are only called for side-effects).
>
>   >  my bet: undefined behavior sources bugs, makes maintenance difficult.
>   >
>   >  Design at the user level certainly deserves a separate approach. It's up
>   >  to implement convenient error-handling than rather than undefined behavior.
>
> I don't know about convenient error-*handling*, but if Stefan wants to
> prevent people from using the value of primitives called only for
> side-effects, he can always provide "convenient error generation" by
> having such primitives return Qunbound (or whatever it's called in
> Emacs sources: the special uninterned symbol placed in the value slot
> of an uninitialized symbol).
>
> ;-) ** 100
>
>

OK, but when on that side-way, I'm afraid of forms specialising the 
special case, remove  specialising the special case by special condition 
again and so on.

see all the active-region stuff for a basic example at a basic level.

Andreas

Re: Should undefined behavior be encouraged in Emacs?

[Alan Mackenzie]

Hi, Stefan.

On Sun, Oct 02, 2011 at 11:11:58PM -0400, Stefan Monnier wrote:
> > The argument given for undefined behavior is that it simplifies
> > maintenance of Emacs internals.

> I like to keep some corner of the behavior undefined, when I think
> that user code that depends on such details is undesirable (e.g. return
> values of primitives which are only called for side-effects).

There are few functions called solely for side effects.  For example,
`goto-char' is frequently found thusly:

(and
 ...
 ...
 (goto-char anchor-point)
 ...
 ...)

.  Strictly speaking this behaviour is undefined because the return
value (which everybody knows to be anchor-point) is undefined.  Strictly
speaking, one has to write it like this:

(and
 ...
 ...
 (progn (goto-char anchor-point) t)
 ...
 ...)

, which is a pain in the alist.  Surely the return value of things like
`goto-char' should be defined?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Should undefined behavior be encouraged in Emacs?

[Eli Zaretskii]

> Date: Mon, 3 Oct 2011 09:20:46 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Emacs Development <emacs-devel@gnu.org>
> 
> Hi, Stefan.
> 
> On Sun, Oct 02, 2011 at 11:11:58PM -0400, Stefan Monnier wrote:
> > > The argument given for undefined behavior is that it simplifies
> > > maintenance of Emacs internals.
> 
> > I like to keep some corner of the behavior undefined, when I think
> > that user code that depends on such details is undesirable (e.g. return
> > values of primitives which are only called for side-effects).
> 
> There are few functions called solely for side effects.  For example,
> `goto-char' is frequently found thusly:
>  ...
> Surely the return value of things like `goto-char' should be
> defined?

Since this discussion is about to veer sideways, I'd like to make it
clear that I didn't mean something like goto-char's return value at
all.  What I meant is the behavior of Lisp primitives and subroutines
when they are called with invalid arguments, such as buffer positions
that are non-positive.

The original example was that an overlay was moved to start at
position zero and end on position 1, and Paul wanted such an overlay
to be considered empty, because he _expected_ position zero to be
always treated as position 1.

Re: Should undefined behavior be encouraged in Emacs?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Mon, 03 Oct 2011 10:29:10 +0200
> Cc: Emacs Development <emacs-devel@gnu.org>
> 
> I don't think Emacs should have undefined behaviour.  It may have
> unspecified behaviour (ie. it may change any time), but the result
> should always be consistent with the documented rules.

That might be a good goal, but I think it is practically unreachable.

Re: Should undefined behavior be encouraged in Emacs?

[Richard Stallman]

    My impression is that Emacs built-ins are generally supposed to
    have defined behavior, so that Emacs is easier to use reliably.

What is the meaning of "defined" or "undefined", here?
Is it a matter of whether the documentation says what happens in that case?

In simple cases such as (goto-char -5), users tend to see what the
behavior is, and are likely to write code that depends on it, even if
it isn't documented.  Thus, leaving it undocumented doesn't mean that
we can change it and nobody will notice.

Meanwhile, even if something is documented, we CAN change it.
It just means somewhat more annoyance will occur.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Should undefined behavior be encouraged in Emacs?

[Stefan Monnier]

> I don't know about convenient error-*handling*, but if Stefan wants to
> prevent people from using the value of primitives called only for

This is Elisp we're talking about: no types, no "preventing people".
There's only positive/negative encouragement.

> side-effects, he can always provide "convenient error generation" by
> having such primitives return Qunbound (or whatever it's called in

If the Qunbound value escapes to Elisp I'm sure we'll get bug reports.


        Stefan

Re: Should undefined behavior be encouraged in Emacs?

[Dave Abrahams]

on Sun Oct 02 2011, Paul Eggert <eggert-AT-cs.ucla.edu> wrote:

> A recent comment in Bug#9642 advocates another approach: undefined
> behavior.  For example, it proposes that move-overlay should have
> undefined behavior when given arguments like -5 that are out of
> range.  In other words, (move-overlay OVERLAY -5 1) might signal
> an error, or substitute an in-range value, or wrap around, or
> return a data structure that subtly violates some other guarantee
> made by Emacs; or it might do one of these things sometimes and
> another at other times.  In short, undefined behavior means that
> move-overlay might do *anything* when given out-of-range
> arguments.
>
> The argument given for undefined behavior is that it simplifies
> maintenance of Emacs internals.

Such an interesting question!  

Unefined behavior gets a bad rap, but it has at least one important use:
it distinguishes things that are definitely programming bugs from
everything else.  It is perfectly legitimate (and even encouraged style
in some languages) to rely on the defined behavior that certain
out-of-range arguments will cause errors to be signaled, e.g. for loop
termination:

   (condition-case nil
     (let ((n 0))
        (while t 
         (frobnicate (get-item n))
         (setq n (+ n 1))))
     (error "index out of range"))

The problem with this is that when you see a signal come out of get-item
you can't tell whether it indicates a bug or not.  So I actually favor
something stronger than ordinary defined behavior for out-of-range
arguments.

For elisp programs, I don't think completely *undefined* behavior
(reformat your hard disk, launch a missile) is such a hot idea, since it
should in principle be easy to limit the range of responses to things
that are less damaging.  Maybe unspecified behavior, as suggested
elsewhere in this thread, is closer to the mark.

As the author of get-item above, I'd probably want to express the
unspecified behavior by forcing the debugger to come up, with *no
possibility* of it being suppressed by surrounding constructs such as
condition-case (is that possible in elisp?).  But I wouldn't want anyone
trying to rely on that behavior except maybe as a debugging aid.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Should undefined behavior be encouraged in Emacs?

[Dave Abrahams]

on Mon Oct 03 2011, Richard Stallman <rms-AT-gnu.org> wrote:

>     My impression is that Emacs built-ins are generally supposed to
>     have defined behavior, so that Emacs is easier to use reliably.
>
> What is the meaning of "defined" or "undefined", here?
> Is it a matter of whether the documentation says what happens in that case?
>
> In simple cases such as (goto-char -5), users tend to see what the
> behavior is, and are likely to write code that depends on it, even if
> it isn't documented.  Thus, leaving it undocumented doesn't mean that
> we can change it and nobody will notice.

If you make it a hard, inescapable error, that won't happen.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Should undefined behavior be encouraged in Emacs?

[Eli Zaretskii]

> Date: Mon, 03 Oct 2011 09:13:08 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>     My impression is that Emacs built-ins are generally supposed to
>     have defined behavior, so that Emacs is easier to use reliably.
> 
> What is the meaning of "defined" or "undefined", here?
> Is it a matter of whether the documentation says what happens in that case?

Undefined behavior is something that is left to the implementation,
and the programmer who invokes it cannot expect anything in
particular.  Examples (from C) are use of an automatic variable before
initializing it, indexing an array outside of its bounds, etc.  These
could work, or they could produce strange results, or they could
crash.

I consider referencing buffer position of zero similar to indexing an
array out of its bounds.

> In simple cases such as (goto-char -5), users tend to see what the
> behavior is, and are likely to write code that depends on it, even if
> it isn't documented.  Thus, leaving it undocumented doesn't mean that
> we can change it and nobody will notice.
> 
> Meanwhile, even if something is documented, we CAN change it.
> It just means somewhat more annoyance will occur.

Documentation is not the issue here.  The issue is whether we should
let people expect certain undefined behaviors and demand that any such
behavior invariably produces results they expect.  To continue one of
the above examples, the expectation that an uninitialized automatic
variable in a C program always has the value of zero, or that
accessing an array out of bounds actually access its first or last
element, whichever is closest to the invalid reference.

When a large enough body of Lisp programs has been written that relies
on such behavior, any significant changes in the underlying
implementation are either very hard or very bug-prone (or both),
because no living individual can possibly study enough Lisp programs
to glean all these expectations and design the modified implementation
so as not to break them.

Re: Should undefined behavior be encouraged in Emacs?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I consider referencing buffer position of zero similar to indexing an
> array out of its bounds.

Unlike C, Emacs Lisp is supposed to check each and every lisp data.  The
interpreter may reject an out-of-bounds or wrong-type value by raising
an error, or silently accept it by coercing it into bounds, but it
should never crash because of it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Should undefined behavior be encouraged in Emacs?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rms@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Mon, 03 Oct 2011 18:27:16 +0200
> 
> The interpreter may reject an out-of-bounds or wrong-type value by
> raising an error, or silently accept it by coercing it into bounds,
> but it should never crash because of it.

I agree.

Re: Should undefined behavior be encouraged in Emacs?

[Paul Eggert]

On 10/03/11 06:13, Richard Stallman wrote:

> What is the meaning of "defined" or "undefined", here?
> Is it a matter of whether the documentation says what happens in that case?

Partly that, but the question is more about what's reasonable when
behavior is not documented.

For example, there's no documentation for what (make-hash-table :size 0)
does.  If we are very strict and say that the behavior is completely
undefined, then (make-hash-table :size 0) might:

 (a) signal an error
 (b) act like (make-hash-table :size 1)
 (c) return nil
 (d) cause Emacs to exit with status 127
 (e) modify a randomly-chosen string somewhere in your program
 (f) create a hash table that later doesn't work
 (g) corrupt the contents of the file ~/.emacs
 (h) dump core

(a), (b), and (c) are common choices for Emacs built-ins, and I
expect we agree these behaviors are OK.  Conversely, we agree that
(h) is not OK.

The question is whether actions like (d) through (g) are OK for
built-ins that are given out-of-range values, and for similar
areas where behavior is not documented.  If the answer is "yes",
it will be easier to maintain Emacs's internals; if "no",
Emacs will be easier to use reliably.

Re: Should undefined behavior be encouraged in Emacs?

[Richard Stallman]

    > In simple cases such as (goto-char -5), users tend to see what the
    > behavior is, and are likely to write code that depends on it, even if
    > it isn't documented.  Thus, leaving it undocumented doesn't mean that
    > we can change it and nobody will notice.

    If you make it a hard, inescapable error, that won't happen.

That is true; this would pressure everyone to carefully make sure not
to supply out-of-range arguments.  But is that goal really more
desirable than the convenience of rounding out-of-range arguments?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Should undefined behavior be encouraged in Emacs?

[Richard Stallman]

    Undefined behavior is something that is left to the implementation,
    and the programmer who invokes it cannot expect anything in
    particular.

This definition is used in standards development, and presumes that
we're talking about a spec that might have various implementations.
However, Emacs is one specific program, not a spec.  Thus, concepts
from standards development, about the relationship between the spec
and its various implementations, may not transfer naturally.  I don't
see what "undefined behavior" would mean in the case of Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Should undefined behavior be encouraged in Emacs?

[Dave Abrahams]

on Mon Oct 03 2011, Richard Stallman <rms-AT-gnu.org> wrote:

>     > In simple cases such as (goto-char -5), users tend to see what the
>     > behavior is, and are likely to write code that depends on it, even if
>     > it isn't documented.  Thus, leaving it undocumented doesn't mean that
>     > we can change it and nobody will notice.
>
>     If you make it a hard, inescapable error, that won't happen.
>
> That is true; this would pressure everyone to carefully make sure not
> to supply out-of-range arguments.  But is that goal really more
> desirable than the convenience of rounding out-of-range arguments?

I would say it depends on the argument and its meaning.  I remember when
I was working on a MIDI sequencer whose routines would assert that all
times used were nonnegative.  For my code, that was a major PITA.  I
would say the same probably applies to character positions.

Other arguments can't be so easily rounded (an int passed where a string
is expected), and probably some that can just shouldn't be
(e.g. indexing a vector).

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Should undefined behavior be encouraged in Emacs?

[Stephen J. Turnbull]

Andreas Röhler writes:

 > OK, but when on that side-way, I'm afraid of forms specialising the 
 > special case, remove  specialising the special case by special condition 
 > again and so on.

That's the Emacs way, for better or worse.  You'll note that even with
100 smilies Stefan found it necessary to take the suggestion seriously
enough to veto it.

 > see all the active-region stuff for a basic example at a basic level.

UI is *never* basic.  This is especially true of Emacsen, where the
user has full access to the internals of UI.  This means that APIs
used to construct UI take decades to rationalize if you respect
backward compatibility at all.

"Active regions" is also a hard-to-interpret example for historical
reasons.  AIUI, Richard philosophically disagrees with the whole idea
of active regions, but they were a feature greatly desired by a large
fraction of users.  So they were introduced piecemeal, as options, and
were not allowed to disturb existing APIs.

Re: Should undefined behavior be encouraged in Emacs?

[Richard Stallman]

      AIUI, Richard philosophically disagrees with the whole idea
    of active regions, but they were a feature greatly desired by a large
    fraction of users.

That's not the case.  Philosophically, I have no objection to them.

They turn out to be a pain in practice.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Should undefined behavior be encouraged in Emacs?

[Stephen J. Turnbull]

Richard Stallman writes:

 >       AIUI, Richard philosophically disagrees with the whole idea
 >     of active regions, but they were a feature greatly desired by a large
 >     fraction of users.
 > 
 > That's not the case.  Philosophically, I have no objection to them.

I apologize for misstating your position.

 > They turn out to be a pain in practice.

I don't doubt that's true for you.  Nevertheless, it isn't true for
me, as a user or as a programmer, using the "zmacs-regions"
implementation in XEmacs.

I certainly did (and often still do) find active regions + pending
delete (the behavior where the whole active region is deleted on any
insertion or deletion keystroke) annoying in GUI-oriented applications
such as Mozilla and OpenOffice.  I never had any problem with XEmacs'
implementation though (it's more context-sensitive, I think, and for a
couple of months at first I did set pending-delete mode to kill rather
than delete the active region which saved me annoyance a few times).
And in my relatively limited use of Emacs, I don't think I have any
problem with Emacs-style transient mark mode and friends that isn't
attributable to the minor variations from XEmacs.

Nor have I ever found active regions to be a barrier to learning new
idioms for using Emacs.

This is unfortunate, then, because I agree with Andreas: the Emacsen
programming interfaces for working with active regions are complex and
annoying, and unnecessarily so from a design standpoint.

Re: Should undefined behavior be encouraged in Emacs?

[Andreas Röhler]

[  ... ]
> This is unfortunate, then, because I agree with Andreas: the Emacsen
> programming interfaces for working with active regions are complex and
> annoying, and unnecessarily so from a design standpoint.
>

think it would pay a lot to clean up that. AFAIU the same things are 
reimplemented in several loops without that the core questions which 
usually arises profit from it:

is it time to take a certain action or not?

for me transient-mark-mode in connection with a mark set is enough.

Cheers,

Andreas

Re: Should undefined behavior be encouraged in Emacs?

[Lars Magne Ingebrigtsen]

Andreas Röhler <andreas.roehler@online.de> writes:

> for me transient-mark-mode in connection with a mark set is enough.

Oh, are we having this discussion again?

I, like (I'm assuming) all other oldey-timey Emacs users :-), disabled
`transient-mark-mode' the first chance I got.  And the reason for that
is that `C-x C-x' activates the region, which makes it impossible to use
that command to jump around in buffers.  Which I do constantly.

If that rather odd overloading of the `C-x C-x' command went away, I
might start using `transient-mark-mode'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Should undefined behavior be encouraged in Emacs?

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 06 Oct 2011 22:12:53 +0200
> 
> I, like (I'm assuming) all other oldey-timey Emacs users :-), disabled
> `transient-mark-mode' the first chance I got.  And the reason for that
> is that `C-x C-x' activates the region, which makes it impossible to use
> that command to jump around in buffers.  Which I do constantly.
> 
> If that rather odd overloading of the `C-x C-x' command went away, I
> might start using `transient-mark-mode'.

It didn't.

Re: Should undefined behavior be encouraged in Emacs?

[Andreas Röhler]

Am 06.10.2011 22:12, schrieb Lars Magne Ingebrigtsen:
> Andreas Röhler<andreas.roehler@online.de>  writes:
>
>> for me transient-mark-mode in connection with a mark set is enough.
>
> Oh, are we having this discussion again?
>
> I, like (I'm assuming) all other oldey-timey Emacs users :-), disabled
> `transient-mark-mode' the first chance I got.  And the reason for that
> is that `C-x C-x' activates the region, which makes it impossible to use
> that command to jump around in buffers.

don't understand. After C-x C-x just do a C-space to deactivate and jump 
previous marks as common.

Cheers,

Which I do constantly.
>
> If that rather odd overloading of the `C-x C-x' command went away, I
> might start using `transient-mark-mode'.
>

Re: Should undefined behavior be encouraged in Emacs?

[Stephen J. Turnbull]

Lars Magne Ingebrigtsen writes:

 > I, like (I'm assuming) all other oldey-timey Emacs users :-),

You're wrong, as all sensible folk expect from the word "assuming". :-)

I've been using Emacs since ESC-ESC-ESC produced scathing remarks
about inability to hack buffers and hacking buffers meant writing TECO
code.  Does that count as "oldey-timey"?

 > disabled `transient-mark-mode' the first chance I got.

Indeed, just after I switched to XEmacs, `zmacs-regions' was enabled
by default, and I immediately overrode the default.  That was a
mistake, as I discovered about a month later when the maintainers
requested that we try it for a week and report experiences and
preferences.  I found that I liked it, for several reasons, and the
change in default was upheld because most commentators agreed.  That
was in like 1996 when everybody was an oldey-timey Emacs user 'cause
that was oldey-times.

 > And the reason for that is that `C-x C-x' activates the region,
 > which makes it impossible to use that command to jump around in
 > buffers.

Of course it doesn't make it impossible.  You just don't like it,
either because of the risk of deleting something you don't want to
reproduce, or because you find the highlighting annoying, or maybe for
some other reason I don't recall after a decade and a half of correct
usage.<wink/>

 > Which I do constantly.

So did I, although quite recently I've found myself using C-u C-SPC a
lot more.  Specifically, C-x 2 C-u C-SPC, but several other variants
as well.  This turns out to be much more powerful for me, although the
extra power is not useful every day so far.  I'm still working out
idioms.

 > If that rather odd overloading of the `C-x C-x' command went away,

What's odd about it?  One of the use cases for C-x C-x is to make the
region visible, either subtly by the motion of point, or more or less
garishly with highlighting.  Even in my "traditional" usage pattern I
often used that for confirmation that the region is the one I want to
operate on, almost as often as I used it for the motion itself.  With
active regions on, I get that confirmation even when I didn't request
it specifically, and occasionally that forestalls mistakes.

I'm not at all denying your usage pattern, just your claim that it's
universal among long-time users.  It's not, and there are good reasons
for the alternatives, just as there are good reasons why you like your
own patterns.

 > I might start using `transient-mark-mode'.

C'mon, Lars, I'm sure you could do that for yourself.  Why don't you
try it and see?  After all, you'd be the odd one out, people who
already use t-m-m evidently *want* the activating behavior.

Re: Should undefined behavior be encouraged in Emacs?

[John Wiegley]

>>>>> Stephen J Turnbull <stephen@xemacs.org> writes:

>> disabled `transient-mark-mode' the first chance I got.

> [...] I found that I liked it, for several reasons, and the change in
> default was upheld because most commentators agreed.

I also quiet like transient-mark-mode, despite the fact that at first I
disabled it most vociferously (in the confines of my then office).

>> And the reason for that is that `C-x C-x' activates the region, which makes
>> it impossible to use that command to jump around in buffers.

> Of course it doesn't make it impossible.  You just don't like it, either
> because of the risk of deleting something you don't want to reproduce, or
> because you find the highlighting annoying, or maybe for some other reason I
> don't recall after a decade and a half of correct usage.<wink/>

I would like this behavior to have a customization variable.
highlight-region-on-exchange-point-and-mark.

>> I might start using `transient-mark-mode'.

> C'mon, Lars, I'm sure you could do that for yourself.  Why don't you try it
> and see?  After all, you'd be the odd one out, people who already use t-m-m
> evidently *want* the activating behavior.

Well, I don't use C-x C-x, I use C-u C-SPC, but maybe I'd like to bounce back,
and in that case having the region re-highlighted seems... odd.

John

Re: Should undefined behavior be encouraged in Emacs?

[Alan Mackenzie]

On Thu, Oct 06, 2011 at 10:12:53PM +0200, Lars Magne Ingebrigtsen wrote:
> Andreas Röhler <andreas.roehler@online.de> writes:

> > for me transient-mark-mode in connection with a mark set is enough.

> Oh, are we having this discussion again?

> I, like (I'm assuming) all other oldey-timey Emacs users :-), disabled
> `transient-mark-mode' the first chance I got.  And the reason for that
> is that `C-x C-x' activates the region, which makes it impossible to use
> that command to jump around in buffers.  Which I do constantly.

Yep, me too.  I disabled it in my .emacs in Emacs-22, disabling the
monstrosity before it happended.  Trouble is, I still have to do testing
in emacs -Q.  :-(

I detest the way it splurges blue ink over carefully crafted font
locking.  I hate the introduction of modal behaviour into Emacs as
default; it makes Emacs a bit like vi.  Oh, and the dishonest naming -
there is nothing left of `transient-mark-mode' because the mark is not
transient any longer, given that `mark-active-even-when-inactive' (???)
is set by default.

> If that rather odd overloading of the `C-x C-x' command went away, I
> might start using `transient-mark-mode'.

Thank [insert your god's name here] options can be set in Emacs.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Should undefined behavior be encouraged in Emacs?

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

On Oct 06, 2011, at 10:12 PM, Lars Magne Ingebrigtsen wrote:

>Andreas Röhler <andreas.roehler@online.de> writes:
>
>> for me transient-mark-mode in connection with a mark set is enough.
>
>Oh, are we having this discussion again?
>
>I, like (I'm assuming) all other oldey-timey Emacs users :-), disabled
>`transient-mark-mode' the first chance I got.  And the reason for that
>is that `C-x C-x' activates the region, which makes it impossible to use
>that command to jump around in buffers.  Which I do constantly.
>
>If that rather odd overloading of the `C-x C-x' command went away, I
>might start using `transient-mark-mode'.

I'm positive I qualify for "oldey timey" status, and not just because of the
color of what's left of my hair.  I've used X/Emacs daily since probably the
mid-80's.  Back when I was doing a lot of elisp programming, I thought that
XEmacs's API for active regions was just about perfect in its simplicity and
ease of use, and the UI just felt natural.  Translating my usage patterns to
Emacs was one of the biggest impediments to switching back to Emacs, which I
finally managed to do 3+ years ago.

Since I don't do much elisp hacking these days, I can't comment on the APIs
anymore, but I do occasionally report bugs in python-mode.el, which is where I
think Andreas is coming from.  As for the UI, it all feels quite natural these
days in Emacs and I'm fairly certain I'm using the defaults.

One quick note about C-x C-x and C-space.  For several decades now I've used
Ken Manheimer's most awesome namedmarks code[1].  With no C-u, these work just
like their default cousins (I think, it's been a long time), but with an
argument, they allow you to name locations in the buffer.  E.g.

C-u C-space
-> Set named mark:
here RET
(move somewhere far away)
C-u C-x C-x
-> Goto mark named (default here)
RET

jumps you back to the mark named 'here'.  Of course, you can have any number
of named marks, and both prompts support completion.  It's a testament to its
elegant simplicity that I don't think this code has been touched in 20 years
and still works beautifully.  It's a great addition to the core UI, IMO.
Notably, going to a named mark does *not* activate the region, which I think
makes perfect sense given that I'm often jumping around over several screen
fulls.  I don't think I could function without namedmarks.

-Barry

[1] My local copy is (C) 1991 FSF, which looks pretty close to
http://wiki.zope.org/klm/namedmarks.el

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Should undefined behavior be encouraged in Emacs?

[Stephen J. Turnbull]

John Wiegley writes:

 > Well, I don't use C-x C-x, I use C-u C-SPC, but maybe I'd like to
 > bounce back, and in that case having the region re-highlighted
 > seems... odd.

Well, I've found that the "bounce back" case usually involves using
information that I know is at mark to do editing at point or vice
versa.  Thus C-x 2 C-u SPC, which allows me to refer to related
information nearby without more bouncing (at least for a couple of
changes.

Again, I'm not denying the validity of your statement.  Just that I've
found a pattern I like even better, that "just happens" to leave the
behavior of C-x C-x as it currently is.

Re: Should undefined behavior be encouraged in Emacs?

[ken manheimer]

[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]

On Fri, Oct 7, 2011 at 11:26 AM, Barry Warsaw <barry@python.org> wrote:

> On Oct 06, 2011, at 10:12 PM, Lars Magne Ingebrigtsen wrote:
>
> >Andreas Röhler <andreas.roehler@online.de> writes:
> >
> >> for me transient-mark-mode in connection with a mark set is enough.
> >
> >Oh, are we having this discussion again?
> >
> >I, like (I'm assuming) all other oldey-timey Emacs users :-), disabled
> >`transient-mark-mode' the first chance I got.  And the reason for that
> >is that `C-x C-x' activates the region, which makes it impossible to use
> >that command to jump around in buffers.  Which I do constantly.
> >
> >If that rather odd overloading of the `C-x C-x' command went away, I
> >might start using `transient-mark-mode'.
>

i'm jumping in the discussion to say a bit more about namedmarks.el, which
barry mentioned, but while i'm here.  i'm an old timer that leaves transient
mark mode active, and likes it - but i think it's tolerable because i
customized the 'region' face to be only slightly different than the
background, so it's barely noticeable.  (i set the region background to
darkslategray, which blends in almost but not quite completely with the
black background which i have as the default for my emacs frames.)

barry:



[...]


> One quick note about C-x C-x and C-space.  For several decades now I've
> used Ken Manheimer's most awesome namedmarks code[1].  With no C-u, these
> work just like their default cousins (I think, it's been a long time), but
> with an argument, they allow you to name locations in the buffer.  E.g.
>
> C-u C-space
> -> Set named mark:
> here RET
> (move somewhere far away)
> C-u C-x C-x
> -> Goto mark named (default here)
> RET
>
> jumps you back to the mark named 'here'.  Of course, you can have any
> number of named marks, and both prompts support completion.  It's a
> testament to its elegant simplicity that I don't think this code has been
> touched in 20 years and still works beautifully.  It's a great addition to
> the core UI, IMO.  Notably, going to a named mark does *not* activate the
> region, which I think makes perfect sense given that I'm often jumping
> around over several screen fulls.  I don't think I could function without
> namedmarks.
>

me, too! :-)  i've just now put a more legible - but essentially unchanged -
copy of namedmarks.el on my current
site<http://myriadicity.net/software-and-systems/craft/crafty-hacks/emacs-sundries/namedmarks.el/view>,
and would love to see it incorporated in emacs.  the view in that location
is more usable than the old location which barry mentions (and i put a
redirect there - a bit of overdue tidying...)

ken

-Barry
>
> [1] My local copy is (C) 1991 FSF, which looks pretty close to
> http://wiki.zope.org/klm/namedmarks.el
>

[-- Attachment #2: Type: text/html, Size: 4412 bytes --]

Re: Should undefined behavior be encouraged in Emacs?

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Oct 07, 2011, at 02:06 PM, ken manheimer wrote:

>i'm jumping in the discussion to say a bit more about namedmarks.el, which
>barry mentioned, but while i'm here.  i'm an old timer that leaves transient
>mark mode active, and likes it - but i think it's tolerable because i
>customized the 'region' face to be only slightly different than the
>background, so it's barely noticeable.  (i set the region background to
>darkslategray, which blends in almost but not quite completely with the
>black background which i have as the default for my emacs frames.)

Excellent point.  I've done essentially the same thing, and it's beautiful.
My color scheme is anything but default - probably close to what Ken uses.  I
guess that's what happens when two old-timers work together at three different
jobs. :)

-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: Should undefined behavior be encouraged in Emacs?

[Drew Adams]

> I've used Ken Manheimer's most awesome namedmarks code...
> they allow you to name locations in the buffer.  E.g.
> C-u C-space -> Set named mark: here RET
>
> (move somewhere far away)
> C-u C-x C-x -> Goto mark named (default here) RET
> 
> jumps you back to the mark named 'here'.  Of course, you can have
> any number of named marks, and both prompts support completion.

Good stuff.


FWIW -

1. In Icicles you automatically have completion for (ordinary) markers - no need
to stop and name any of them.

Command `icicle-goto-marker' (`C-- C-SPC', same key as setting the mark) lets
you complete against any part of the line the marker is in.

You can also cycle among markers (any subset: those that match your current
minibuffer input), in any sort order you like (default order: buffer position).
You can change the sort order on the fly while completing.

Likewise, for global markers: `icicle-goto-global-marker' (`C-- C-x C-SPC', same
key as setting a global mark).


2. In Bookmark+ you can set autonamed bookmarks without providing any name, then
jump to them or cycle among them.  You can optionally have them be highlighted
(in the fringe or with a face) - visible markers.

The same key sets and deletes an autonamed bookmark (toggle).  With a prefix
arg, (upon confirmation) it deletes all of them in the current buffer.

The automatic names are (by default) the buffer position + the buffer name,
e.g., the autonamed bookmark in buffer foo.el at position 58356 is `000058356
foo.el'.  The names are automatically updated to reflect buffer edits.

http://www.emacswiki.org/emacs/BookmarkPlus#AutonamedBookmarks

Re: Should undefined behavior be encouraged in Emacs?

[Óscar Fuentes]

ken manheimer <ken.manheimer@gmail.com> writes:

> me, too! :-)  i've just now put a more legible - but essentially unchanged -
> copy of namedmarks.el on my current
> site<http://myriadicity.net/software-and-systems/craft/crafty-hacks/emacs-sundries/namedmarks.el/view>,
> and would love to see it incorporated in emacs.  the view in that location
> is more usable than the old location which barry mentions (and i put a
> redirect there - a bit of overdue tidying...)
>
>> [1] My local copy is (C) 1991 FSF, which looks pretty close to
>> http://wiki.zope.org/klm/namedmarks.el

Following those links, login is required.

Re: Should undefined behavior be encouraged in Emacs?

[ken manheimer]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On Fri, Oct 7, 2011 at 2:46 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> ken manheimer <ken.manheimer@gmail.com> writes:
>
> > me, too! :-)  i've just now put a more legible - but essentially
> unchanged -
> > copy of namedmarks.el on my current
> > site<
> http://myriadicity.net/software-and-systems/craft/crafty-hacks/emacs-sundries/namedmarks.el/view
> >,
> > and would love to see it incorporated in emacs.  the view in that
> location
> > is more usable than the old location which barry mentions (and i put a
> > redirect there - a bit of overdue tidying...)
> >
> >> [1] My local copy is (C) 1991 FSF, which looks pretty close to
> >> http://wiki.zope.org/klm/namedmarks.el
>
> Following those links, login is required.
>

whoops - fixed - have a look now.
(this<http://myriadicity.net/software-and-systems/craft/crafty-hacks/emacs-sundries/namedmarks.el/view>is
the new, more direct, location.)

(neglected to promote it, and accompanying stuff, to "published" when i
situated them.)

ken

[-- Attachment #2: Type: text/html, Size: 1697 bytes --]

Re: Should undefined behavior be encouraged in Emacs?

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> like (I'm assuming) all other oldey-timey Emacs users :-), disabled
> `transient-mark-mode'

Hmm, no.  I like transient-mark-mode.

-miles

-- 
Monday, n. In Christian countries, the day after the baseball game.

RE: Should undefined behavior be encouraged in Emacs?

[Drew Adams]

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> > like (I'm assuming) all other oldey-timey Emacs users :-), disabled
> > `transient-mark-mode'
> 
> Hmm, no.  I like transient-mark-mode.

incf - in fact, `delete-selection-mode'.

But I did note the smiley.  I think (hope) Lars was being ironic.