re-loading an elisp file

re-loading an elisp file

[ken]

Is there a way, when reloading an elisp file, to have it examine (and
reload new) values of variables?  It's weird that this isn't done with
"eval-current-buffer" or "load ..." and others.

Re: re-loading an elisp file

[Pascal J. Bourguignon]

ken <gebser@mousecar.com> writes:

> Is there a way, when reloading an elisp file, to have it examine (and
> reload new) values of variables?  

There's a reason it's done: if you've painfully customized a module, you
wouldn't want all your settings to be reset to default just because you
reload its sources.

So defvar is defined to set the value of the variable only if the
variable is not already defined.


In Common Lisp, there's also a defparameter macro that always sets the
value of the variable.  But of course, you wouldn't do that for
customization variables, or for variables storing important state (eg. a
database).


So you may put:

(defmacro defconstant (symbol initvalue &optional docstring)
  `(defconst ,symbol ,initvalue ,docstring))

(defmacro defparameter (symbol &optional initvalue docstring)
  `(progn
     (defvar ,symbol nil ,docstring)
     (setq   ,symbol ,initvalue)))

in your ~/.emacs and use defparameter instead of defvar in some cases.
But in general you don't want to.


What you may do, is to provide a reset command to reinitialize the state
of your module.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

RE: re-loading an elisp file

[Drew Adams]

> Is there a way, when reloading an elisp file, to have it examine (and
> reload new) values of variables?  It's weird that this isn't done with
> "eval-current-buffer" or "load ..." and others.

Sounds like you are discovering that `defvar' does not assign a variable a value
if it already has one.  This is a feature.

`setq' and `setq-default' do, however.

But in general an Elisp library should not act this way, by design.  A personal
init file is another story - there you might want to use `setq' and
`setq-default' in some cases.

Re: re-loading an elisp file

[ken]

On 03/05/2011 10:27 AM Pascal J. Bourguignon wrote:
> ken <gebser@mousecar.com> writes:
> 
>> Is there a way, when reloading an elisp file, to have it examine (and
>> reload new) values of variables?  
> 
> There's a reason it's done: if you've painfully customized a module, you
> wouldn't want all your settings to be reset to default just because you
> reload its sources.

That's what I *am* doing-- *quite* and unnecessarily painfully
customizing a module-- and I *do* want variables to be re-initialized.


> 
> So defvar is defined to set the value of the variable only if the
> variable is not already defined.

Then the name of the function should be called
"load-everything-except-variables".  The "load" and
"eval-current-buffer" functions should do what their names say.


> 
> 
> In Common Lisp, there's also a defparameter macro that always sets the
> value of the variable.  But of course, you wouldn't do that for
> customization variables, or for variables storing important state (eg. a
> database).

Are you saying I need to switch from elisp to common lisp or make a call
to common lisp just to change the value of a variable?


> 
> 
> So you may put:
> 
> (defmacro defconstant (symbol initvalue &optional docstring)
>   `(defconst ,symbol ,initvalue ,docstring))
> 
> (defmacro defparameter (symbol &optional initvalue docstring)
>   `(progn
>      (defvar ,symbol nil ,docstring)
>      (setq   ,symbol ,initvalue)))
> 
> in your ~/.emacs and use defparameter instead of defvar in some cases.
> But in general you don't want to.

So I need to put all this code in my ~/.emacs (and then of course
re-initialize ~/.emacs) whenever I need to re-initialize one variable?
But then wouldn't I need to take this code back out and re-initialize
~/.emacs again when I don't want to change the value of a variable?

I think it would be simpler and easier just to reboot all of emacs.  But
quitting-and-restarting emacs seems like a radical procedure just to
re-initialize one variable.


> 
> 
> What you may do, is to provide a reset command to reinitialize the state
> of your module.

I was hoping I wouldn't have to write that code myself...  I was
thinking that elisp should have a way to re-initialize a variable in a
module.  That was really the point of my original post.

Re: re-loading an elisp file

[ken]

On 03/05/2011 10:54 AM Drew Adams wrote:
>> Is there a way, when reloading an elisp file, to have it examine (and
>> reload new) values of variables?  It's weird that this isn't done with
>> "eval-current-buffer" or "load ..." and others.
> 
> Sounds like you are discovering that `defvar' does not assign a variable a value
> if it already has one.  

Actually, I thought my computer had some corrupt memory... but then I
googled and after a time read about it on a forum on the web.


> This is a feature.

Hmm.  I've heard that said before.


> 
> `setq' and `setq-default' do, however.
> 
> But in general an Elisp library should not act this way, by design.  A personal
> init file is another story - there you might want to use `setq' and
> `setq-default' in some cases.

The forum said that the simplest way to re-initialize a variable in
elisp was to reboot emacs.  I thought, "that's knuckle-headed... can't
be true."  But I guess it is.  Your work-around though-- changing all
the defvar's to setq's-- is preferable.

Thanks.

Re: re-loading an elisp file

[Johan Bockgård]

ken <gebser@mousecar.com> writes:

> I was hoping I wouldn't have to write that code myself...  I was
> thinking that elisp should have a way to re-initialize a variable in a
> module.  That was really the point of my original post.

You can use `C-M-x' on the defvar form.

RE: re-loading an elisp file

[Drew Adams]

> > Sounds like you are discovering that `defvar' does not 
> > assign a variable a value if it already has one.  
> 
> Actually, I thought my computer had some corrupt memory... but then I
> googled and after a time read about it on a forum on the web.

Suit yourself, but I recommend starting with Emacs's own doc: `C-h r'.
Emacs Wiki is also a good resource: www.emacswiki.org.

> > This is a feature.
> 
> Hmm.  I've heard that said before.

Learn about it and you will convince yourself.
It is a very _useful_ feature.

But no one forces you to use it.  And certainly no one suggests that you use it
to do something it is not intended for.

> > `setq' and `setq-default' do, however.
> > But in general an Elisp library should not act this way, by 
> > design.  A personal init file is another story - there you might
> > want to use `setq' and `setq-default' in some cases.
> 
> The forum said that the simplest way to re-initialize a variable in
> elisp was to reboot emacs.

Sounds like a forum to avoid, or at least to read only judiciously.

> I thought, "that's knuckle-headed... can't be true."  But I guess it is.

No, of course it isn't true.

> Your work-around though-- changing all the defvar's to setq's--
> is preferable.

I did _not_ suggest that, and what I suggested is not a "workaround".  If you
read the cited forum only as carefully as you read what I wrote, then perhaps it
is not the forum's advice that was misguided...

Emacs Lisp gives you ways to assign values unconditionally - e.g. setq.

And it gives you ways to assign a value if there is not already a value - IOW,
to initialize a variable (_only_ initialize) - e.g., defvar, defcustom.

It's up to you to choose the right Emacs Lisp facilities to accomplish what you
want.

defvar and defcustom are used very often, precisely because of the feature of
being no-ops if the variable has already been set.  But if you want to set a
variable unconditionally each time you load a file, then do not try to use
defvar to do that.

In general, Emacs libraries are designed to be loadable without changing
existing user settings.  Typically a user has to invoke some command to make a
loaded library actually change some existing value.  And decades of user
experiences have shown this to be a good pattern.

User init files, on the other hand, often unconditionally set variables (e.g.
using setq or setq-default).  And those user settings are then respected by
libraries that are loaded - precisely because those libraries use defvar or
defcustom, not setq, for their initialization.

And even in user init files, practice over the years has tended to reduce the
habit of using setq in favor of taking advantage of Customize (defcustom).
There are several reasons for that, including type-checking and initialization
with side effects (i.e., initializing a variable can also call for other,
related initialization operations).

And with cleaner libraries to load nowadays (in general), the need for
re-assigning things in user init files has been reduced.  If a library does not
stomp on your initialized settings simply by loading it, then you need not
counter that by re-setting such things after loading the library.  In general,
your init file can now count on making its own settings without worrying about
the libraries it loads altering those settings.

Changing variable values simply by loading a file can be particularly
problematic when the sexp defining the value is not a constant.  IOW, (setq foo
42) is one thing, but (setq foo (+ foo 42)) and (setq foo (oracle-at-delphi))
are something else again.

Consider this as friendly advice.  If it helps, fine.  If not, ignore.

RE: re-loading an elisp file

[Drew Adams]

But it seems that we've been down this road before...
http://lists.gnu.org/archive/html/help-gnu-emacs/2009-06/msg00394.html

Re: re-loading an elisp file

[Tim X]

ken <gebser@mousecar.com> writes:

> On 03/05/2011 10:27 AM Pascal J. Bourguignon wrote:
>> ken <gebser@mousecar.com> writes:
>> 
>>> Is there a way, when reloading an elisp file, to have it examine (and
>>> reload new) values of variables?  
>> 
>> There's a reason it's done: if you've painfully customized a module, you
>> wouldn't want all your settings to be reset to default just because you
>> reload its sources.
>
> That's what I *am* doing-- *quite* and unnecessarily painfully
> customizing a module-- and I *do* want variables to be re-initialized.
>
>
>> 
>> So defvar is defined to set the value of the variable only if the
>> variable is not already defined.
>
> Then the name of the function should be called
> "load-everything-except-variables".  The "load" and
> "eval-current-buffer" functions should do what their names say.
>
>
>> 
>> 
>> In Common Lisp, there's also a defparameter macro that always sets the
>> value of the variable.  But of course, you wouldn't do that for
>> customization variables, or for variables storing important state (eg. a
>> database).
>
> Are you saying I need to switch from elisp to common lisp or make a call
> to common lisp just to change the value of a variable?
>
>
>> 
>> 
>> So you may put:
>> 
>> (defmacro defconstant (symbol initvalue &optional docstring)
>>   `(defconst ,symbol ,initvalue ,docstring))
>> 
>> (defmacro defparameter (symbol &optional initvalue docstring)
>>   `(progn
>>      (defvar ,symbol nil ,docstring)
>>      (setq   ,symbol ,initvalue)))
>> 
>> in your ~/.emacs and use defparameter instead of defvar in some cases.
>> But in general you don't want to.
>
> So I need to put all this code in my ~/.emacs (and then of course
> re-initialize ~/.emacs) whenever I need to re-initialize one variable?
> But then wouldn't I need to take this code back out and re-initialize
> ~/.emacs again when I don't want to change the value of a variable?
>
> I think it would be simpler and easier just to reboot all of emacs.  But
> quitting-and-restarting emacs seems like a radical procedure just to
> re-initialize one variable.
>
>
>> 
>> 
>> What you may do, is to provide a reset command to reinitialize the state
>> of your module.
>
> I was hoping I wouldn't have to write that code myself...  I was
> thinking that elisp should have a way to re-initialize a variable in a
> module.  That was really the point of my original post.
>
>

No you don't need to add all the code Pascal included and probably best
not to unless you understand it. 

The problem is that while you may know which variables you want re-set,
emacs doesn't know which ones have been deliberately set to a value by
you because that is the default you want and which ones should be reset
to their default values. 

The way I usually deal with this is to either reset the variable in the
scratch buffer i.e. 

(setq var nil)

then when I re-evaluate the buffer, var will be set if it is in a defvar
statement. If you have a few of these variables, then I would just put
them in a simple funciton (which I also define in the scratch buffer)
i.e.

(defun my-reset ()
       (interactive)
       (setq var1 nil)
       (setq var2 nile)
       ... 
       )

and then just type M-x my-reset whenever I want to reset that set of
variables. 

However, it is possible that you may be approaching hings from the wrong
direction. I rarely need to re-evaluate a whole buffer, unless I'm
developing something from scratch. If your just modifying some existing
code, you normally only need to evaluate individual functions. For
customization, the custom interface provides a good high-level way to
try out various settings without having to re-evaluate a buffer etc. 

Maybe provide some more explination about what your trying to do and we
can provide better answers.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: re-loading an elisp file

[Tim X]

ken <gebser@mousecar.com> writes:

> On 03/05/2011 10:54 AM Drew Adams wrote:
>>> Is there a way, when reloading an elisp file, to have it examine (and
>>> reload new) values of variables?  It's weird that this isn't done with
>>> "eval-current-buffer" or "load ..." and others.
>> 
>> Sounds like you are discovering that `defvar' does not assign a variable a value
>> if it already has one.  
>
> Actually, I thought my computer had some corrupt memory... but then I
> googled and after a time read about it on a forum on the web.
>
>
>> This is a feature.
>
> Hmm.  I've heard that said before.
>
>
>> 
>> `setq' and `setq-default' do, however.
>> 
>> But in general an Elisp library should not act this way, by design.  A personal
>> init file is another story - there you might want to use `setq' and
>> `setq-default' in some cases.
>
> The forum said that the simplest way to re-initialize a variable in
> elisp was to reboot emacs.  I thought, "that's knuckle-headed... can't
> be true."  But I guess it is.  Your work-around though-- changing all
> the defvar's to setq's-- is preferable.
>

I would be very cautious regarding any forum that provided advice like
that. I suspect they would also recommend rebooting the computer
whenever there is a problem a la "The IT Crowd"

I help maintain a couple of elisp packages, write a fair amount of
elips for personal use and only reboot emacs if I've upgraded/built a
new version or my computer needs to be rebooted (well, I might also do a
reboot if I've fixed a lot of bugs and want to make sure they work in a
fresh session prior to committing them to vc just as a final test). 

One of the huge advantages of lisp like languages is that you can modify
the running system without having to kill everything and restart. 

Tim
-- 
tcross (at) rapttech dot com dot au

Re: re-loading an elisp file

[ken]

On 03/05/2011 12:41 PM Johan Bockgård wrote:
> ken <gebser@mousecar.com> writes:
> 
>> I was hoping I wouldn't have to write that code myself...  I was
>> thinking that elisp should have a way to re-initialize a variable in a
>> module.  That was really the point of my original post.
> 
> You can use `C-M-x' on the defvar form.

Thanks, I'll try that... but later.  I already changed the defvar's to
setq's.  (On to the next thing!)

Re: re-loading an elisp file

[PJ Weisberg]

On Sat, Mar 5, 2011 at 2:17 PM, Tim X <timx@nospam.dev.null> wrote:

> The way I usually deal with this is to either reset the variable in the
> scratch buffer i.e.
>
> (setq var nil)
>
> then when I re-evaluate the buffer, var will be set if it is in a defvar
> statement.

Not true.  If the variable is set at all, even to nil, defvar respects
it and doesn't overwrite it with the default.  Otherwise putting
something like (setq flyspell-persistent-highlight nil) in your .emacs
file would have no effect.

The way to actually do that is:

(makunbound 'var)

-PJ

Re: re-loading an elisp file

[ken]

On 03/05/2011 01:11 PM Drew Adams wrote:
> But it seems that we've been down this road before...
> http://lists.gnu.org/archive/html/help-gnu-emacs/2009-06/msg00394.html
> 

The counterintuitive is harder to remember over the years.

Re: re-loading an elisp file

[Tim X]

PJ Weisberg <pj@irregularexpressions.net> writes:

> On Sat, Mar 5, 2011 at 2:17 PM, Tim X <timx@nospam.dev.null> wrote:
>
>> The way I usually deal with this is to either reset the variable in the
>> scratch buffer i.e.
>>
>> (setq var nil)
>>
>> then when I re-evaluate the buffer, var will be set if it is in a defvar
>> statement.
>
> Not true.  If the variable is set at all, even to nil, defvar respects
> it and doesn't overwrite it with the default.  Otherwise putting
> something like (setq flyspell-persistent-highlight nil) in your .emacs
> file would have no effect.
>
> The way to actually do that is:
>
> (makunbound 'var)
>

Your right - coincidentally, I was debugging a function that does some
work after doing a (if (null ....) and was not thinking clearly/more
generally. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: re-loading an elisp file

[PJ Weisberg]

On Sat, Mar 5, 2011 at 3:36 PM, ken <gebser@mousecar.com> wrote:
>
> On 03/05/2011 01:11 PM Drew Adams wrote:
>> But it seems that we've been down this road before...
>> http://lists.gnu.org/archive/html/help-gnu-emacs/2009-06/msg00394.html
>>
>
> The counterintuitive is harder to remember over the years.

Think of defvar as defining a variable.  If the variable is already
defined, there's nothing for defvar to do.  Setting the variable's
default value likewise only affects it's current value if there *is*
no current value.  (That's why defvar *does* set the global "default"
if that's unset, even if there's a buffer-local variable with the same
name.)

-PJ

Re: re-loading an elisp file

[rusi]

On Mar 6, 4:21 am, PJ Weisberg <p...@irregularexpressions.net> wrote:
> On Sat, Mar 5, 2011 at 2:17 PM, Tim X <t...@nospam.dev.null> wrote:
> > The way I usually deal with this is to either reset the variable in the
> > scratch buffer i.e.
>
> > (setq var nil)
>
> > then when I re-evaluate the buffer, var will be set if it is in a defvar
> > statement.
>
> Not true.  If the variable is set at all, even to nil, defvar respects
> it and doesn't overwrite it with the default.  Otherwise putting
> something like (setq flyspell-persistent-highlight nil) in your .emacs
> file would have no effect.
>
> The way to actually do that is:
>
> (makunbound 'var)
>
> -PJ

This points out the real problem -- elisp is not a functional
language.
In (pure) functional languages the pattern (for loading) is to 'clean
the slate' and then load. IOW everything -- variable, function, type
-- that was defined in this module is first 'makunbounded' and then
the module is loaded.

It would certainly be worthwhile to have such a feature in emacs.  I
guess its not easy to do unless one has available the pair-list of the
form: ((var defined-in-file)...).
Another problem that would probably muddy the waters are macros...

Re: re-loading an elisp file

[Le Wang]

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

On Sun, Mar 6, 2011 at 1:32 PM, rusi <rustompmody@gmail.com> wrote:

> On Mar 6, 4:21 am, PJ Weisberg <p...@irregularexpressions.net> wrote:
> > On Sat, Mar 5, 2011 at 2:17 PM, Tim X <t...@nospam.dev.null> wrote:
> > > The way I usually deal with this is to either reset the variable in the
> > > scratch buffer i.e.
> >
> > > (setq var nil)
> >
> > > then when I re-evaluate the buffer, var will be set if it is in a
> defvar
> > > statement.
> >
> > Not true.  If the variable is set at all, even to nil, defvar respects
> > it and doesn't overwrite it with the default.  Otherwise putting
> > something like (setq flyspell-persistent-highlight nil) in your .emacs
> > file would have no effect.
> >
> > The way to actually do that is:
> >
> > (makunbound 'var)
> >
> > -PJ
>
> This points out the real problem -- elisp is not a functional
> language.
> In (pure) functional languages the pattern (for loading) is to 'clean
> the slate' and then load. IOW everything -- variable, function, type
> -- that was defined in this module is first 'makunbounded' and then
> the module is loaded.
>
> It would certainly be worthwhile to have such a feature in emacs.  I
> guess its not easy to do unless one has available the pair-list of the
> form: ((var defined-in-file)...).
> Another problem that would probably muddy the waters are macros...
>

You can roll your own eval-buffer that reloads defvars and defcustoms like
so:

(defmacro replacement-def (sym val &rest args)
  `(setq ,sym ,val))


(defun force-eval-buffer (&optional buf)
  (interactive)
  (eval-buffer buf)                         ; define variables properly at
least once
  (let ((func-alist (mapcar (lambda (func)
                              (cons func (symbol-function func)))
                            '(defvar defcustom))))
    (unwind-protect
        (progn
          (mapc (lambda (func-cons)
                  (fset (car func-cons) (symbol-function 'replacement-def)))
                func-alist)
          (eval-buffer buf))
      (mapcar (lambda (func-cons)
                (fset (car func-cons) (cdr func-cons)))
              func-alist))))


I'm not sure if this introduces any problems.

-- 
Le

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

Re: re-loading an elisp file

[Kevin Rodgers]

On 3/6/11 1:36 AM, Le Wang wrote:
> On Sun, Mar 6, 2011 at 1:32 PM, rusi <rustompmody@gmail.com
> <mailto:rustompmody@gmail.com>> wrote:
...
>     This points out the real problem -- elisp is not a functional
>     language.
>     In (pure) functional languages the pattern (for loading) is to 'clean
>     the slate' and then load. IOW everything -- variable, function, type
>     -- that was defined in this module is first 'makunbounded' and then
>     the module is loaded.
>
>     It would certainly be worthwhile to have such a feature in emacs.  I
>     guess its not easy to do unless one has available the pair-list of the
>     form: ((var defined-in-file)...).
>     Another problem that would probably muddy the waters are macros...

Does M-x unload-feature meet the goals?

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: re-loading an elisp file

[rusi]

On Mar 8, 6:18 am, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> On 3/6/11 1:36 AM, Le Wang wrote:
>
> > On Sun, Mar 6, 2011 at 1:32 PM, rusi <rustompm...@gmail.com
> > <mailto:rustompm...@gmail.com>> wrote:
> ...
> >     This points out the real problem -- elisp is not a functional
> >     language.
> >     In (pure) functional languages the pattern (for loading) is to 'clean
> >     the slate' and then load. IOW everything -- variable, function, type
> >     -- that was defined in this module is first 'makunbounded' and then
> >     the module is loaded.
>
> >     It would certainly be worthwhile to have such a feature in emacs.  I
> >     guess its not easy to do unless one has available the pair-list of the
> >     form: ((var defined-in-file)...).
> >     Another problem that would probably muddy the waters are macros...
>
> Does M-x unload-feature meet the goals?

Thanks -- looks interesting.
But a first glance at it shows that it uses unload-function-defs-list
and that is nil.
Guess it must get populated at the appropriate time.  When?

Re: re-loading an elisp file

[rusi]

On Mar 8, 6:57 am, rusi <rustompm...@gmail.com> wrote:
> On Mar 8, 6:18 am, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
>
>
>
> > On 3/6/11 1:36 AM, Le Wang wrote:
>
> > > On Sun, Mar 6, 2011 at 1:32 PM, rusi <rustompm...@gmail.com
> > > <mailto:rustompm...@gmail.com>> wrote:
> > ...
> > >     This points out the real problem -- elisp is not a functional
> > >     language.
> > >     In (pure) functional languages the pattern (for loading) is to 'clean
> > >     the slate' and then load. IOW everything -- variable, function, type
> > >     -- that was defined in this module is first 'makunbounded' and then
> > >     the module is loaded.
>
> > >     It would certainly be worthwhile to have such a feature in emacs.  I
> > >     guess its not easy to do unless one has available the pair-list of the
> > >     form: ((var defined-in-file)...).
> > >     Another problem that would probably muddy the waters are macros...
>
> > Does M-x unload-feature meet the goals?
>
> Thanks -- looks interesting.
> But a first glance at it shows that it uses unload-function-defs-list
> and that is nil.
> Guess it must get populated at the appropriate time.  When?

Ok looked at loadhist.el and find that the list I was earlier asking
for is load-history.

So now if I have thrown some random elisp into a file (no require,
provides) how do I unload it?
I can assoc the file's alist in load-history.  After that??

Re: re-loading an elisp file

[David Combs]

...
...
>
>However, it is possible that you may be approaching hings from the wrong
>direction. I rarely need to re-evaluate a whole buffer, unless I'm
>developing something from scratch. If your just modifying some existing
                                       ^^^^
>code, you normally only need to evaluate individual functions. For
>customization, the custom interface provides a good high-level way to
>try out various settings without having to re-evaluate a buffer etc. 
>
>Maybe provide some more explination about what your trying to do and we
                                                ^^^^
>can provide better answers.
>
>Tim

This writing of "your" for "you're" -- EVERYONE seems to be doing it,
at least for the last year or so.   Maybe it's the new standard patois
for newsgroups (and other things too?).

Anyway -- yeah, it's kinda neat (assuming it's on purpose), maybe,
but it could really screw those who do it.

Because, once someone gets used to using "your" for "you're" (for "you are"),
in news post after news post, then SOME DAY it'll really bite him or her,
because when writing something really important, like a job application,
grant request, a "nice meeting you; can we get together sometime, maybe" letter,
etc ..., a knee-jerk memorized-by-fingers "your"  might leave the wrong impression, 
right, and you letter gets rejected, with maybe life-changing results. 

(Nor does it help that with "your", the spell-checker won't catch it.)

Please, guys, let's not start a flame-war over this.  Thanks.

I hope this helps (someone, some day).

David

Re: re-loading an elisp file

[David Combs]

In article <mailman.4.1299348453.24947.help-gnu-emacs@gnu.org>,
Drew Adams <drew.adams@oracle.com> wrote:
...
...
>
>And even in user init files, practice over the years has tended to reduce the
>habit of using setq in favor of taking advantage of Customize (defcustom).
>There are several reasons for that, including type-checking and initialization
>with side effects (i.e., initializing a variable can also call for other,
>related initialization operations).
>
...
...

Customize -- hmmm -- interesting (though I've never used it, always preferred
edit-options kind of thing).

But please say more about your suggested use of customize in this
situation.  Thanks!


Also, some more about its type checking, and its initialization
with side-effects.

Maybe also some examples of how you use it in your code-writing.

Thanks!

David

Re: re-loading an elisp file

[David Combs]

In article <mailman.22.1299377327.22865.help-gnu-emacs@gnu.org>,
PJ Weisberg  <pj@irregularexpressions.net> wrote:
>On Sat, Mar 5, 2011 at 3:36 PM, ken <gebser@mousecar.com> wrote:
>>
>> On 03/05/2011 01:11 PM Drew Adams wrote:
>>> But it seems that we've been down this road before...
>>> http://lists.gnu.org/archive/html/help-gnu-emacs/2009-06/msg00394.html
>>>
>>
>> The counterintuitive is harder to remember over the years.
>
>Think of defvar as defining a variable.  If the variable is already
>defined, there's nothing for defvar to do.  Setting the variable's
...

Suppose the default value is 5, and then you reset (via setq) it
to 0, or null, or the like.

Then you read in a .el-file containing a defvar on it --
what happens then?

David

RE: re-loading an elisp file

[Drew Adams]

> >Think of defvar as defining a variable.  If the variable is already
> >defined, there's nothing for defvar to do.  Setting the variable's
> ...
> 
> Suppose the default value is 5, and then you reset (via setq) it
> to 0, or null, or the like.
> 
> Then you read in a .el-file containing a defvar on it --
> what happens then?

Nothing.

C-h f defvar RET

...INITVALUE is evaluated, and used to set SYMBOL,
only if SYMBOL's value is void.

After your `setq' the symbol's value is not void, so `defvar' does nothing.

RE: re-loading an elisp file

[Drew Adams]

> > And even in user init files, practice over the years has 
> > tended to reduce the habit of using setq in favor of
> > taking advantage of Customize (defcustom). There are
> > several reasons for that, including type-checking 
> > and initialization with side effects (i.e., initializing a
> > variable can also call for other, related initialization
> > operations).
> 
> Customize -- hmmm -- interesting (though I've never used it, 
> always preferred edit-options kind of thing).
> 
> But please say more about your suggested use of customize in this
> situation.  Thanks!

Dunno what "this situation" is.  And I don't have a suggested use of customize.

I use `defcustom' to define variables that I expect general users to want to
modify.  That makes the variables into user options, which means their values
can be changed using `M-x set-variable' or `M-x customize-option'.

> Also, some more about its type checking, and its initialization
> with side-effects.

See the `defcustom' doc wrt :type, :init, and :set.
(elisp) Variable Definitions
(elisp) Customization Types

> Maybe also some examples of how you use it in your code-writing.

Check the Lisp sources that come with Emacs.  Grep `:type' or `:set' or
`:initialize'.

Re: re-loading an elisp file

[Tim X]

dkcombs@panix.com (David Combs) writes:

> ...
> ...
>>
>>However, it is possible that you may be approaching hings from the wrong
>>direction. I rarely need to re-evaluate a whole buffer, unless I'm
>>developing something from scratch. If your just modifying some existing
>                                        ^^^^
>>code, you normally only need to evaluate individual functions. For
>>customization, the custom interface provides a good high-level way to
>>try out various settings without having to re-evaluate a buffer etc. 
>>
>>Maybe provide some more explination about what your trying to do and we
>                                                 ^^^^
>>can provide better answers.
>>
>>Tim
>
> This writing of "your" for "you're" -- EVERYONE seems to be doing it,
> at least for the last year or so.   Maybe it's the new standard patois
> for newsgroups (and other things too?).
>
> Anyway -- yeah, it's kinda neat (assuming it's on purpose), maybe,
> but it could really screw those who do it.
>
> Because, once someone gets used to using "your" for "you're" (for "you are"),
> in news post after news post, then SOME DAY it'll really bite him or her,
> because when writing something really important, like a job application,
> grant request, a "nice meeting you; can we get together sometime, maybe" letter,
> etc ..., a knee-jerk memorized-by-fingers "your"  might leave the wrong impression, 
> right, and you letter gets rejected, with maybe life-changing results. 
>
> (Nor does it help that with "your", the spell-checker won't catch it.)
>
> Please, guys, let's not start a flame-war over this.  Thanks.
>
> I hope this helps (someone, some day).
>

Get over it. I type my responses quickly (average 194 words p/m) and
rarely proof read them. I will frequently type your instead of your're
and thats not going to change. I will also sometimes type their instead
of there and vice-versa. I prefer to read and respond to more messages
than waste time editing/correcting when dealing with an informal forum
like usernet and when the errors rarely affect the point being
discussed. 

You must have a terrible time with SMS!

Tim

-- 
tcross (at) rapttech dot com dot au

Re: re-loading an elisp file

[David Kastrup]

Tim X <timx@nospam.dev.null> writes:

> Get over it. I type my responses quickly (average 194 words p/m) and
> rarely proof read them. I will frequently type your instead of your're
> and thats not going to change. I will also sometimes type their instead
> of there and vice-versa. I prefer to read and respond to more messages
> than waste time editing/correcting when dealing with an informal forum
> like usernet and when the errors rarely affect the point being
> discussed. 
>
> You must have a terrible time with SMS!

I should be surprised if your SMS are read by thousands of people,
archived for eternity, and indexed and searchable by search engines.

In a write-once, read-once medium the balance between collective sender
and receiver efforts is different from a write-once, read-multiply one.

-- 
David Kastrup

Re: re-loading an elisp file

[Jambunathan K]

> I prefer to read and respond to more messages than waste time
> editing/correcting when dealing with an informal forum like usernet
> and when the errors rarely affect the point being discussed.

Right from this thread, you would have noted that errors affect (some)
readers. 

Puts these fact together and decide what makes most sense to you.

1. Every reader is a potential respondent.
2. You have no prior knowledge of what would prevent a reader from
   responding.
3. You have raised a question with some hope that someone out there
   would respond.

ps: Some people pride themselves of their high typing speeds while few
others pride themselves of their impeccable English.

Jambunathan K.
-- 

Re: re-loading an elisp file

[Tim X]

David Kastrup <dak@gnu.org> writes:

> Tim X <timx@nospam.dev.null> writes:
>
>> Get over it. I type my responses quickly (average 194 words p/m) and
>> rarely proof read them. I will frequently type your instead of your're
>> and thats not going to change. I will also sometimes type their instead
>> of there and vice-versa. I prefer to read and respond to more messages
>> than waste time editing/correcting when dealing with an informal forum
>> like usernet and when the errors rarely affect the point being
>> discussed. 
>>
>> You must have a terrible time with SMS!
>
> I should be surprised if your SMS are read by thousands of people,
> archived for eternity, and indexed and searchable by search engines.
>

One word - Twitter!

> In a write-once, read-once medium the balance between collective sender
> and receiver efforts is different from a write-once, read-multiply one.

-- 
tcross (at) rapttech dot com dot au

Re: re-loading an elisp file

[Tim X]

Jambunathan K <kjambunathan@gmail.com> writes:

>> I prefer to read and respond to more messages than waste time
>> editing/correcting when dealing with an informal forum like usernet
>> and when the errors rarely affect the point being discussed.
>
> Right from this thread, you would have noted that errors affect (some)
> readers. 
>
> Puts these fact together and decide what makes most sense to you.
>
> 1. Every reader is a potential respondent.
> 2. You have no prior knowledge of what would prevent a reader from
>    responding.
> 3. You have raised a question with some hope that someone out there
>    would respond.
>

No, I responded to a question raised by someone else. 

Nobody has raised any questions relating to confusion due to my use of
your instead of you're, which would suggest your points are at best
based on a possible 'theoretical' issue that could exist if the grammar
was sufficiently confusing, but is not the situation in this case.
David's original criticism has valid points in that he is probably
correct i.e. getting intot the habit of your instead of you're does have
some risks. However, my position is that I don't consider usernet
important enough to worry about this sort of minor error in grammar. I
respond quickly and don't proof read - my posts will typically be full
of such errors and frequent transposition of keys or other typos. I
don't care if these errors are archived for posterity and if asked,
would clarify any confusion caused (which has rarely ever happened and
never happened because of grammar mistakes). If others can't deal with
it or feel they cannot rely on content with such errors, they can ignore
them.

When posting a question, which I rarely find the need to do these days,
I will typically spend more effort proof reading - not so much for
grammar and typos, but more to ensure my question is as clear as
possible.

As to David's original warning regarding bad habits - well, that horse
has already bolted. I frequently use your instead of you're and am quie
aware of this bad habit. As a consequence, it is one of the things I do
look for when proof reading more important text (though, due to the
extra care taken when writing such text, this error rarely occurs). What
I cannot do is easily unlearn this habit when typing quickly -
especially when usernet responses are typically a 'flow of
consciousness' more like verbally answering a quetion than a more structured and
thought out written answer.  

I suspect the reality is that your v you're just bugs David and he just
had to vent a little. My position is this is usernet and you just have
to shake your head and move on and get over it as its unlikely to change.

> ps: Some people pride themselves of their high typing speeds while few
> others pride themselves of their impeccable English.
>

and thats fine - each to their own. My posts are what they are. If
others find them irritating because of minor grammar errors, they are
free to ignore them. If others wish to spend more time proof reading and
correcting before they post, that is also fine. What is pointless is to
even bother worrying about the habits of others and applying your own
standards on them..

Tim


-- 
tcross (at) rapttech dot com dot au

Re: re-loading an elisp file

[Jambunathan K]

> I frequently use your instead of you're and am quie aware of this bad
> habit.

I have read somewhere that one could set up an abbrev expansion for
frequently mis-spelt/mis-typed words so that they expand to the rightly
spelt word.

Jambunathan K.

-- 

Re: re-loading an elisp file

[Tim X]

Jambunathan K <kjambunathan@gmail.com> writes:

>> I frequently use your instead of you're and am quie aware of this bad
>> habit.
>
> I have read somewhere that one could set up an abbrev expansion for
> frequently mis-spelt/mis-typed words so that they expand to the rightly
> spelt word.
>

As David pointed out, the danger with your and you're is that they are
both legitimate words. An abbrev is of no use as there is not enough
information available for abbrev to know when to allow your and when to
replace it with you're, so abbrev is of no use.



-- 
tcross (at) rapttech dot com dot au