Re: line-move-visual

[Tim X]

Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:

> On 6/13/2010 2:41 AM, Tim X wrote:
>

> I am dying to figure out what application Mark Crispin is
> putting Emacs to that makes it so hard for him to accommodate the
> line-move-visual change.  >
>

It seems, from a post I've just seen from Mark, that it isn't an
application at all. What he has are some recipes/processes that staff
follow using emacs. He has previously stated that asking them to set
line=move-visual to nil was not acceptable as his users would be
confused and that he has no access to the emacs software they are
running. Therefore, it would be reasonable to assume that if they cannot
add a simple line to set a variable and he does not have access to the
machines, that the users are not installing any specialised packages or
code and there is no elisp involved at all. His issue appears to be with
how to update his processes/recipes in a clear manner so that they will
still work regardless. This is a legitimate issue.

I now think he has overstated the impact. Setting line movement to its
old default is easily done via the options menu and doesn't require the
user editing .emacs or even using M-x customize. It wouldn't be too
difficult to add this to his recipes. (I do wonder how he deals with
users who select other options, such as CUA mode, that are also likely
to impact on his recipes). 

His point about setting visual line mode as the default being a poor
decision is valid. Likewise, his concern that this is a sign of possible
problems for his setup if more changes that affect basic commands occur
in future versions is legitimate, though possibly over stated when based
on a single contentious change (noting also that its not like a new major
version of emacs comes out every other week. 4 major versions released
in over 15 years!). However, discussion of such change is certainly
beneficial, even if it only makes developers aware of the need to be
conservative when proposing changes to interfaces or especially
defaults.

Unfortunately, over stating of the issue, derogatory assertions about
the developers, baseless assumptions about their ages, motivation and
expertise have tended to obscure the valid points he has raised. Instead
of coming across well, much of it has come across as nothing more than a
dummy spit. 

Tim

-- 
tcross (at) rapttech dot com dot au