emacs-devel
[Top][All Lists]
Advanced

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

Re: cua-mode and the tutorial


From: Kim F. Storm
Subject: Re: cua-mode and the tutorial
Date: Mon, 28 Aug 2006 13:21:10 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Richard Stallman <address@hidden> writes:
>
>> You're the only one involved, in this scenario, so you're
>> not treating anyone else badly.
>>
>> But this is a special case, and you're the one who has told me that
>> some sysadmins set up Emacs in a nonstandard way for _other people_.

I didn't mean to say anyone actually does this.

We discussed whether it was worth the trouble to write code which
specifically tries to _remove_ CUA setting that the user may
not have installed himself.

So I tried to give examples where of ways it _can_ be done, that would
be non-trivial to remove (hoping that we could drop that idea and do
more important work).

>>
>>     And what exactly do you intend to change?  Enabling cua-mode,
>>     viper-mode, delete-selection-mode, pc-selection-mode, glasses-mode,
>>     .. any minor mode?
>>
>> Perhaps this should be done for whichever modes we find are often
>> being imposed on other users in this way.

I honestly don't think that there are any such modes which are _often_
imposed on other users through site-start.el etc.  

In most cases, people who want to introduce someone to emacs may
give the newbee a copy of their own .emacs to look at and use
initially.  We neither can nor should try to control what people
share in this way.

> We are interfering in that manner with the freedom of adapting Emacs
> to one's wishes.  What next?  Will we use DRM to ensure that all
> variables we consider worthy are left at standard settings?
>
> Emacs is free software.  Part of the freedom is being able to do
> things that upstream did not think a good idea.  I am strictly opposed
> to booby-trapping Emacs with code that reverts a consciously made
> decision downstream.

I agree with David -- but even if I didn't, I wouldn't spend as much
as one second writing the code necessary to impose such restrictions.

[and I've already spent way too much time discussion this (non-)issue].


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





reply via email to

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