emacs-devel
[Top][All Lists]
Advanced

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

Re: File modes facilities.


From: Kim F. Storm
Subject: Re: File modes facilities.
Date: Tue, 25 Oct 2005 23:34:55 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Richard M. Stallman" <address@hidden> writes:

>     I did consider that, and we could do that as well, but IMO, the whole
>     point of this to allow interactive specs for built-in functions to be
>     written in Lisp, i.e. in a .el file, so people can improve on the code
>     without modifying the base functionality.
>
> The idea is to write it in Lisp, but that doesn't mean putting
> it in a different file, which is undesirable.  

I don't see why it is undesirable--quite the contrary.  In many other
situations, we aim at minimizing the "core functionality in C" and
write the "hard parts" in Lisp.

IMO, it is no less desireable than putting a defcustom for built-in
variables or key bindings for built-in commands into a separate file.

Having to maintain pieces of Lisp code as static C strings sounds
rather tedious and inflexible to me, so IMHO the usefulness of this
will be limited.

>                                                It is cleaner
> to keep the interactive spec in the function definition, not
> separate it.

I don't argue that it should be impossible to specify the interactive
spec as part of the current string, e.g. as "#(list (read-string ...))",
but that functionality is another functionality, so the two approaches
may supplement each other.

However, my approach covers all aspects of your approach, whereas your
appoach only addresses one aspect of my approach, and in a rather
inflexible way.

> If you want to put the code in a separate file, you can put
> it in a function and make the interactive spec call that function.

But this still has the MAJOR drawback that this will only apply to
built-in functions that have already been instrumented to do that
(which in practice means: none).

My trivial changes provide a simple, efficient, flexible,
user-extensible solution which can be applied to all existing
functions and commands.

> I don't know if I want to make functions into commands
> except by editing their definitions in the standard way.

That works only for Lisp code, not for built-in functions (unless you
edit the relevant C files and rebuild emacs -- not the normal approach to
extensibility :-).

But even for Lisp code, why copy all the code just to be able to
change the way a command reads its arguments?

One idea just occurred to me -- my approach could be used as a way to
localize emacs by providing e.g. Danish prompts for the most common
commands.  Not that I would do that personally :-)

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





reply via email to

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