how to get around deprecated function

how to get around deprecated function

[B. T. Raven]

This was posted by mistake to the gnus group:

>
>Hello:
>
>I am constantly losing short pieces of text left in *scratch* and I wrote this
>interactive function:
>
>(defun save-scratchtemp ();; M-x scr
>  (interactive)
>  (switch-to-buffer "*scratch*")
>  (mark-whole-buffer)
> (setq start (point) end (mark))
> (append-to-file start end "c:/mydocu~1/scratchtemp.txt")
>)
>
>It "works" but according to the docs mark-whole-buffer shouldn't be used this
>way.Is there an understandable (to me) right way of doing this or doing
>something else that can be invoked as easily?
>
>Thanks,
>
>Ed
>

Re: how to get around deprecated function

[Emanuel Berg]

B. T. Raven <btraven@nihil.net> writes:

> I am constantly losing short pieces of text left in
> *scratch* and I wrote this interactive function
> [...]
>
> It "works" but according to the docs
> mark-whole-buffer shouldn't be used this way.
> Is there an understandable (to me) right way of
> doing this or doing something else that can be
> invoked as easily?

In the help for `append-to-file', it says

    (append-to-file START END FILENAME) ... If START
    is nil, that means to use the entire
    buffer contents.

Also, instead of using `switch-to-buffer', use
`with-current-buffer'. And, instead of using `setq',
use `let'. Or - as the data doesn't reappear - you
might as well put the function invocations in the
append-to-file invocation itself.

Use the Emacs byte-compiler to get suggestions such as
these. You already found out they are in the help, but
the byte-compiler can be a way of not having to check
the help for every function used...

Meta hint: Don't quote things that haven't appeared in
the thread with the angle brackets. Either just yank
it or make it look like this if it appeals to you:

    Meta hint: don't quote things that haven't
    appeared in the thread with the angle brackets.
    Either just yank it or make it look like this if
    it appeals to you.

Dig deep!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: how to get around deprecated function

[B. T. Raven]

Die Tue Apr 28 2015 18:29:45 GMT-0500 (Central Daylight Time) Emanuel
Berg <embe8573@student.uu.se> scripsit:

> B. T. Raven <btraven@nihil.net> writes:
> 
>> I am constantly losing short pieces of text left in
>> *scratch* and I wrote this interactive function
>> [...]
>>
>> It "works" but according to the docs
>> mark-whole-buffer shouldn't be used this way.
>> Is there an understandable (to me) right way of
>> doing this or doing something else that can be
>> invoked as easily?
> 
> In the help for `append-to-file', it says
> 
>     (append-to-file START END FILENAME) ... If START
>     is nil, that means to use the entire
>     buffer contents.
> 
> Also, instead of using `switch-to-buffer', use
> `with-current-buffer'. And, instead of using `setq',
> use `let'. Or - as the data doesn't reappear - you
> might as well put the function invocations in the
> append-to-file invocation itself.
> 
> Use the Emacs byte-compiler to get suggestions such as
> these. You already found out they are in the help, but
> the byte-compiler can be a way of not having to check
> the help for every function used...
> 
> Meta hint: Don't quote things that haven't appeared in
> the thread with the angle brackets. Either just yank
> it or make it look like this if it appeals to you:
> 
>     Meta hint: don't quote things that haven't
>     appeared in the thread with the angle brackets.
>     Either just yank it or make it look like this if
>     it appeals to you.
> 
> Dig deep!
> 

Thanks, Emanuel and Rusi. GT signs are there because I copypasted out of
gnus.help where I posted by mistake. I should have stripped them.

I now have:

Not exactly what you do but for the same reason I have:

(defun save-scratchtemp ();; M-x sch
 (interactive)
(save-excursion
 (with-current-buffer "*scratch*"
      (mark-whole-buffer)
   ;;(setq start (point) end (mark))
     (append-to-file nil nil "c:/mydocu~1/scratchtemp.txt")))
)

which also "works." Also I may not need save-excursion even if my
current buffer is not *scratch*. I used nil nil for start, end maybe
unnecessarily if append-to-file renumbers the argument list.

I think that the add-hook won't work for me:

(add-hook 'lisp-interaction-mode-hook
	  (function (lambda () (setq buffer-offer-save t))))

because *scratch* would have to be associated with a file name which
would replace the *scratch* buffer. My kludge is pretty hokey but at
least I understand it and the multiple copies of the same -short
stretches of text won't be a cumulative problem if I just delete the
scratchtemp.txt file now and then.

Ed

Re: how to get around deprecated function

[Emanuel Berg]

"B. T. Raven" <btraven@nihilo.net> writes:

> Thanks, Emanuel and Rusi. GT signs are there because
> I copypasted out of gnus.help where I posted by
> mistake. I should have stripped them.

Well, quoting is an acquired craft. If you have the
attitude of learing, let me also advice you to not
quote the entire message replied-to but rather just
what you wish to provide as context for your latest
additions to the thread.

> (defun save-scratchtemp ();; M-x sch
>  (interactive)
>   (save-excursion
>  (with-current-buffer "*scratch*"
>       (mark-whole-buffer)
>    ;;(setq start (point) end (mark))
>      (append-to-file nil nil "c:/mydocu~1/scratchtemp.txt")))
> )

You don't have to use `save-excursion' because you
don't need `mark-whole-buffer'. You use save-excursion
when you move point, which indeed mark-whole-buffer
does, but since that isn't required, you don't need
save-excursion.

In general, try not to move the point from Elisp.
But there are many times when it is needed, and then,
yes, use save-excursion.

> which also "works." Also I may not need
> save-excursion even if my current buffer is not
> *scratch*.

You don't need save-excursion but it doesn't have
anything to do with the current buffer.
`with-current-buffer' is perhaps (?) misleading -
think of it as `do-with-buffer'. This is all you need:

    (with-current-buffer "test.txt"
      (append-to-file nil nil "test-log.txt") )

If you are to put it in a hook, you should check there
is such a buffer as well.

> I used nil nil for start, end maybe unnecessarily if
> append-to-file renumbers the argument list.

No, that is the right thing to do. In the help for
`append-to-file', it says

    If START is nil, that means to use the entire
    buffer contents.
    If START is a string, then output that string to
    the file instead of any buffer contents; END
    is ignored.

So though it isn't spelled out when "START is nil",
I think it is safe to assume "END is ignored" there as
well as when "START is a string". Besides, what else
could it (not) do? Feel free to verify this by
checking out the code. Perhaps it should be added to
the docs (one more "END is ignored") to rule out
confusion? (If that *isn't* the case that should
definitely be spelled out.)

> (add-hook 'lisp-interaction-mode-hook (function
> (lambda () (setq buffer-offer-save t))))

With `add-hook', you don't need `function'
before lambda. Just put the lambda there (unquoted).

    (add-hook 'lisp-interaction-mode-hook (lambda () ...)

But, what are you trying to do? I think you are better
of to tell Emacs to automatically save it on exit.

By the way, and people probably have different views
on this, but I think all that add-hook stuff is
confusing. It is better to find out what the hook is.
Offen it is empty or consists of a single or but a few
items. Examine what is there and decide if you want
it. Then set up the hook explicitly, e.g.

    (setq perl-mode-hook 'enable-line-mode) ; Perl

But there is nothing wrong with add-hook and I use it
sometimes dynamically. But in init files, I don't see
why not setting up the hooks explicitly offers
a higher degree of clarity and control.

-- 
underground experts united
http://user.it.uu.se/~embe8573

hook syntax (was: Re: how to get around deprecated function)

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> By the way, and people probably have different views
> on this, but I think all that add-hook stuff is
> confusing. It is better to find out what the hook
> is. Offen it is empty or consists of a single or but
> a few items. Examine what is there and decide if you
> want it. Then set up the hook explicitly, e.g.
>
>     (setq perl-mode-hook 'enable-line-mode) ; Perl
>
> But there is nothing wrong with add-hook and I use
> it sometimes dynamically. But in init files, I don't
> see why not setting up the hooks explicitly offers
> a higher degree of clarity and control.

As I expected, in the docs it says you should use
add-hook:

(info "(emacs)Hooks")

    You can set a hook variable with ‘setq’ like any
    other Lisp variable, but the recommended way to
    add a function to a hook ... is to use ‘add-hook’
    
(info "(elisp)Hooks")

    The recommended way to add a hook function to a hook
    is by calling ‘add-hook’

However, I have many (10-20) hooks set like this:

    (setq perl-mode-hook 'enable-line-mode)

This gets

    perl-mode-hook ; => enable-line-mode

If I do

    (setq perl-mode-hook nil)
    (add-hook 'perl-mode-hook 'enable-line-mode)

I get

    perl-mode-hook ; => (enable-line-mode)

The "incorrect" syntax always worked, until I just now
found that for `message-mode-hook' I must do

    (setq message-mode-hook '(disable-super-global-keys))

So maybe I should retract my piece of advice. Or at
least, if the setq method is to be used, make it
a list (even for singular functions) at the first
sight of trouble. Because that might be just it...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: hook syntax (was: Re: how to get around deprecated function)

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> The "incorrect" syntax always worked, until I just
> now found that for `message-mode-hook' I must do
>
>     (setq message-mode-hook '(disable-super-global-keys))
>
> So maybe I should retract my piece of advice. Or at
> least, if the setq method is to be used, make it
> a list (even for singular functions) at the first
> sight of trouble. Because that might be just it...

To make this easier to reproduce, try this:

    (setq message-mode-hook '(emacs-version)) ; no error
    (setq message-mode-hook 'emacs-version)   ; error
    (gnus-post-news 'post "")                 ; when you do this

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: hook syntax

[Stefan Monnier]

> However, I have many (10-20) hooks set like this:
>     (setq perl-mode-hook 'enable-line-mode)

Please just don't.


        Stefan

--batch on many files without reloading config (was: Re: hook syntax)

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> However, I have many (10-20) hooks set like this:
>> (setq perl-mode-hook 'enable-line-mode)
>
> Please just don't.

OK. But is it still OK with setq and a list?

By the way, perhaps this is something the compiler
should warn about?

I took this opportunity to try to do something cool,
namely to use the Emacs --batch gear to operate on
a set of files, but *without* having to reload the
configuration each time (for each file), which is the
case if one does a shell (bash, zsh) loop with the -u
option, and it just kills speed if you have just
a couple of files.

This turned out a bit more complicated than at first
sight. I was trying to save time :)

    ;; This file: http://user.it.uu.se/~embe8573/conf/emacs-init/batch.el

    ;; emacs --batch -u USER **/*.el -f fix-hooks-in-batch-args

    (require 'cl-macs)

    (defun fix-hooks ()
      (while (re-search-forward
              "(setq \\(.*\\)-hook\\([[:blank:]]*\\)'\\([^(].*\\))"
              nil ; no BOUND
              t)  ; NOERROR
        (replace-match "(setq \\1-hook\\2'(\\3))") )
      (when (buffer-modified-p) (save-buffer)) )

    (defun fix-hooks-in-batch-args ()
      (cl-dolist (file-rel (cdr command-line-args))  ; drop initial 'emacs'
        (let ((file (concat command-line-default-directory file-rel)))
          (when (file-exists-p file)                 ; drop options and 'fix-hooks'
            (find-file file)                         ; - better way to filter files?
            (fix-hooks) ))))

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: --batch on many files without reloading config

[Stefan Monnier]

> OK. But is it still OK with setq and a list?

No, don't use `setq' on a hook, unless you really have a *very* good
reason and know exactly what it implies.


        Stefan

hooks, again (was: Re: --batch on many files without reloading config)

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> OK. But is it still OK with setq and a list?
>
> No, don't use `setq' on a hook, unless you really have
> a *very* good reason and know exactly what
> it implies.

Yeah? But it seems to work as expected. In the help it
says it is recommended to use `add-hook' but also that
they are variables, and what I can see they behave
a such as well.

The reason which I wouldn't call "very good" but good
and clear enough to be spelled out is that you have
a higher degree of clarity and control because you
know from your config files explicitly what is
at work.

If you experiment to get a desired behavior with
add-hook before long you don't know what is going on
because there is no telling what leftovers from
previous (failed?) attempts may linger to cloud
the picture.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: hooks, again

[Stefan Monnier]

> a higher degree of clarity and control because you
> know from your config files explicitly what is at work.

No, you think you do, but you just miss some other clarity and control,
which is that you have no idea what you've overwritten.
You just bullied yourself onto this poor hook, breaking any other
package that was using it.


        Stefan

Re: hooks, again

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> a higher degree of clarity and control because you
>> know from your config files explicitly what is
>> at work.
>
> No, you think you do, but you just miss some other
> clarity and control, which is that you have no idea
> what you've overwritten.

Nothing says just because you set the hook that way
you cannot before you do that examine what is in the
hook and function by function find out what they are
and if you like them to be there.

Usually there isn't much so it isn't a lot work
either, and besides it is a limited but nonetheless
good way to examine the system.

> You just bullied yourself onto this poor hook,
> breaking any other package that was using it.

Again, what's stopping me adding those functions as
well (with setq), if I like them?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: hooks, again

[Stefan Monnier]

> Nothing says just because you set the hook that way
> you cannot before you do that examine what is in the
> hook and function by function find out what they are
> and if you like them to be there.

> Usually there isn't much so it isn't a lot work
> either, and besides it is a limited but nonetheless
> good way to examine the system.

And what is it again that you gained from using (setq foo '(bla))
over (add-hook 'foo 'bla)?

> Again, what's stopping me adding those functions as
> well (with setq), if I like them?

You can reinvent add-hook, if you want, yes.
More power to you,


        Stefan

Re: hooks, again

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Nothing says just because you set the hook that way
>> you cannot before you do that examine what is in
>> the hook and function by function find out what
>> they are and if you like them to be there.
>>
>> Usually there isn't much so it isn't a lot work
>> either, and besides it is a limited but nonetheless
>> good way to examine the system.
>
> And what is it again that you gained from using
> (setq foo '(bla)) over (add-hook 'foo 'bla)?

With

    (setq foo-hook '(grok greed gold))

I can by inspection learn what the hook is. I don't
need the help or evaluation of the variable name or
anything. I need just bring up the definition itself
and read.

With

    (add-hook 'foo 'grok)
    (add-hook 'foo 'greed)
    (add-hook 'foo 'gold)

I see only what functions are at that point added -
not them already there, or if any. It is also
more bulky.

With `setq' I can add and remove functions by editing
the one form (and evaluating it), without using
`add-hook' or `remove-hook' or anything at all.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: hooks, again

[Stefan Monnier]

> With
>     (setq foo-hook '(grok greed gold))
> I can by inspection learn what the hook is. I don't
> need the help or evaluation of the variable name or
> anything. I need just bring up the definition itself
> and read.

But as seen earlier, you have to look at the value of `foo-hook' before
this setq takes place to be sure it's safe.  So you still need
"the help or evaluation of the variable name or anything".

And next time you upgrade Emacs, you'll have to look again at the value
of `foo-hook' before this setq, to make sure your `setq' is still OK.

And nothing explains why you want to remove previously present elements
from that hook.

And of course the above setq doesn't prevent later modification of the
hook (luckily), so you may still need to look at the var's value if you
want to know what's on the hook.

>     (add-hook 'foo 'grok)
>     (add-hook 'foo 'greed)
>     (add-hook 'foo 'gold)
> I see only what functions are at that point added -

Normally, you shouldn't need to care what other functions are there.

> With `setq' I can add and remove functions by editing
> the one form (and evaluating it), without using
> `add-hook' or `remove-hook' or anything at all.

"Without using add-hook or remove-hook" is not a virtue.

As mentioned before, if you like to use `setq' for your hooks, go
right ahead.  After all, that's how add-hook works under the hood.
I just strongly discourage it and consider it a bug to do that in an
Elisp package, except for very particular circumstances.


        Stefan

Re: hooks, again

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But as seen earlier, you have to look at the value
> of `foo-hook' before this setq takes place to be
> sure it's safe. So you still need "the help or
> evaluation of the variable name or anything".

Yes, but only once.

> And next time you upgrade Emacs, you'll have to look
> again at the value of `foo-hook' before this setq,
> to make sure your `setq' is still OK.

This never presented a problem and I think it won't
since in my case all this relates to programming mode
hooks and not the more complicated ones that
supposedly would glue together a software package, for
example Gnus. But it is a valid point.

> And nothing explains why you want to remove
> previously present elements from that hook.

And this is nothing I have done either. Usually those
programming mode hooks are empty.

> And of course the above setq doesn't prevent later
> modification of the hook (luckily), so you may still
> need to look at the var's value if you want to know
> what's on the hook.

Indeed, here is some unorthodox use (?) of `add-hook'
and `remove-hook' where I don't want to use `setq',
because that would require first extracting the
original value and then resetting it.

    (defun enable-jump ()
      (add-hook 'w3m-display-hook 'goto-first-hit) )

    (defun goto-first-hit (&optional url)
      (if (search-forward "Top Definition" (point-max) t) ; Urban Dictionary
          (progn
            (forward-line 2)
            (beginning-of-line)
            (recenter-top-bottom 0) )
        (search-forward " 1." (point-max) t)) ; YouTube
      (remove-hook 'w3m-display-hook 'goto-first-hit) )

    (defun web-search ()
      (interactive)
      (let ((search (get-search-string "Google")))
        (unless (empty-string-p search)
          (w3m-new-tab (format "Google: %s" search))
          (w3m-search "google" search) ))
      (enable-jump) ) ; all code [1]

> Normally, you shouldn't need to care what other
> functions are there.

Che Guevara said revolutionaries aren't normal people.
I don't think programmers are either.

> As mentioned before, if you like to use `setq' for
> your hooks, go right ahead. After all, that's how
> add-hook works under the hood. I just strongly
> discourage it and consider it a bug to do that in an
> Elisp package, except for very
> particular circumstances.

The anomaly mentioned was only indirectly the
consequence of `setq'. The hook worked for a single
function when that function was included in a list,
but not if the hook was set to only that function
(quoted). In addition, it was only reported in some
cases (which is why I supplied the code). Just setting
the mode did not result in an error for "non-list"
use. But it all other hooks that I had, for a single,
quoted function (i.e. no list) it worked.

... wait, you mean YOU consider it a bug? Yes, I would
consider it a bug as well in packages because that
could ruin the user's configurations. The idea with
packages are they should float in the air and not ruin
what is below. Agreed.

[1] http://user.it.uu.se/~embe8573/conf/emacs-init/w3m/w3m-unisearch.el

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: hooks, again

[Stefan Monnier]

>> But as seen earlier, you have to look at the value
>> of `foo-hook' before this setq takes place to be
>> sure it's safe. So you still need "the help or
>> evaluation of the variable name or anything".
> Yes, but only once.

By the same argument, you'd also only need to do it once when using
`add-hook'.

> Che Guevara said revolutionaries aren't normal people.

So, IIUC, you're heading a revolution to kill all uses of add-hook, tho
only those performed by the end user in her ~/.emacs and only on those
few "safe" hooks like major-mode hooks where it makes no difference?

Wow, that's bold!


        Stefan

Re: hooks, again

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So, IIUC, you're heading a revolution to kill all
> uses of add-hook, tho only those performed by the
> end user in her ~/.emacs and only on those few
> "safe" hooks like major-mode hooks where it makes
> no difference?

The difference is that it is easier to see what the
hook is, it is more convenient and faster to remove
and add stuff, the code is less bulky, and when
experimenting to get a desired behavior you neither
have to remove failed attempts or worry that (if left
behind) they will interfere with what you try to do.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: hooks, again

[Stefan Monnier]

> The difference is that it is easier to see what the
> hook is, it is more convenient and faster to remove
> and add stuff, the code is less bulky, and when
> experimenting to get a desired behavior you neither
> have to remove failed attempts or worry that (if left
> behind) they will interfere with what you try to do.

FWIW, I think you feel this need because you do things like

   (setq foo-hook '(a b c))

whereas I do

   (defun sm-foo-hook ()
     (a)
     (b)
     (c))
   (add-hook 'foo-hook 'sm-foo-hook)

So I get the same property as you do (i.e. re-evaluating the code will
properly change the behavior).


        Stefan

Re: hooks, again

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, I think you feel this need because you do
> things like
>
>    (setq foo-hook '(a b c))
>
> whereas I do
>
>    (defun sm-foo-hook () (a) (b) (c))
>    (add-hook 'foo-hook 'sm-foo-hook)
>
> So I get the same property as you do (i.e.
> re-evaluating the code will properly change the
> behavior).

OK, I'm convinced! The package and update arguments
make sense, and with this it gives the visibility and
degree of control for complicated hooks that I speak
of (where "complicated" = one or two or three
functions in a particular order that have argument
data).

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: how to get around deprecated function

[B. T. Raven]

<87y4l9p04r.fsf@debian.uxu>Emanuel BergFri, 01 May 2015 03:17:08 +0200
>
>"B. T. Raven" <btraven@nihilo.net> writes:

[See bottom post]

>
>> Thanks, Emanuel and Rusi. GT signs are there because
>> I copypasted out of gnus.help where I posted by
>> mistake. I should have stripped them.
>
>Well, quoting is an acquired craft. If you have the
>attitude of learing, let me also advice you to not
>quote the entire message replied-to but rather just
>what you wish to provide as context for your latest
>additions to the thread.
>
>> (defun save-scratchtemp ();; M-x sch
>>  (interactive)
>>   (save-excursion
>>  (with-current-buffer "*scratch*"
>>       (mark-whole-buffer)
>>    ;;(setq start (point) end (mark))
>>      (append-to-file nil nil "c:/mydocu~1/scratchtemp.txt")))
>> )
>
>You don't have to use `save-excursion' because you
>don't need `mark-whole-buffer'. You use save-excursion
>when you move point, which indeed mark-whole-buffer
>does, but since that isn't required, you don't need
>save-excursion.
>
>In general, try not to move the point from Elisp.
>But there are many times when it is needed, and then,
>yes, use save-excursion.
>
>> which also "works." Also I may not need
>> save-excursion even if my current buffer is not
>> *scratch*.
>
>You don't need save-excursion but it doesn't have
>anything to do with the current buffer.
>`with-current-buffer' is perhaps (?) misleading -
>think of it as `do-with-buffer'. This is all you need:
>
>    (with-current-buffer "test.txt"
>      (append-to-file nil nil "test-log.txt") )
>
>If you are to put it in a hook, you should check there
>is such a buffer as well.
>
>> I used nil nil for start, end maybe unnecessarily if
>> append-to-file renumbers the argument list.
>
>No, that is the right thing to do. In the help for
>`append-to-file', it says
>
>    If START is nil, that means to use the entire
>    buffer contents.
>    If START is a string, then output that string to
>    the file instead of any buffer contents; END
>    is ignored.
>
>So though it isn't spelled out when "START is nil",
>I think it is safe to assume "END is ignored" there as
>well as when "START is a string". Besides, what else
>could it (not) do? Feel free to verify this by
>checking out the code. Perhaps it should be added to
>the docs (one more "END is ignored") to rule out
>confusion? (If that *isn't* the case that should
>definitely be spelled out.)
>
>> (add-hook 'lisp-interaction-mode-hook (function
>> (lambda () (setq buffer-offer-save t))))
>
>With `add-hook', you don't need `function'
>before lambda. Just put the lambda there (unquoted).
>
>    (add-hook 'lisp-interaction-mode-hook (lambda () ...)
>
>But, what are you trying to do? I think you are better
>of to tell Emacs to automatically save it on exit.
>
>By the way, and people probably have different views
>on this, but I think all that add-hook stuff is
>confusing. It is better to find out what the hook is.
>Offen it is empty or consists of a single or but a few
>items. Examine what is there and decide if you want
>it. Then set up the hook explicitly, e.g.
>
>    (setq perl-mode-hook 'enable-line-mode) ; Perl
>
>But there is nothing wrong with add-hook and I use it
>sometimes dynamically. But in init files, I don't see
>why not setting up the hooks explicitly offers
>a higher degree of clarity and control.
>

Thanks again Emanuel. Some of that is over my head but at least now I have:

(defun save-scratchtemp () ;; M-x sch
(interactive)
(with-current-buffer "*scratch*"
   (append-to-file nil nil "c:/mydocu~1/scratchtemp.txt")))


The following related function might also benefit from some "subtractional
betterment" in case you care to comment. This just appends the line where cursor
(or maybe more accurately 'point') happens to be to the *scratch* buffer. I know
I can make beg, end local to function by using let instead of setq but I always
re-initialize beg and end:


(defun append-line-to-starscratch ();; M-x asl
(interactive)
(move-beginning-of-line nil)
(set-mark-command nil) (setq beg (point))
(move-end-of-line nil) (setq end (point))
(kill-ring-save beg end)
(with-current-buffer "*scratch*"
     (end-of-buffer) (insert "\n")
     (yank)))

Re: how to get around deprecated function

[John Mastro]

Hi B. T.,

> The following related function might also benefit from some
> "subtractional betterment" in case you care to comment. This just
> appends the line where cursor (or maybe more accurately 'point')
> happens to be to the *scratch* buffer. I know I can make beg, end
> local to function by using let instead of setq but I always
> re-initialize beg and end:
>
>
> (defun append-line-to-starscratch ();; M-x asl
> (interactive)
> (move-beginning-of-line nil)
> (set-mark-command nil) (setq beg (point))
> (move-end-of-line nil) (setq end (point))
> (kill-ring-save beg end)
> (with-current-buffer "*scratch*"
>      (end-of-buffer) (insert "\n")
>      (yank)))
>

Here's a simplified version, which also adds the feature that it will
use the active region, if any, or the current line otherwise.

    (defun append-to-starscratch (beg end)
      (interactive
       (if (use-region-p)
           (list (region-beginning) (region-end))
         (list (line-beginning-position) (line-end-position))))
      (let ((str (buffer-substring beg end)))
        (with-current-buffer (get-buffer-create "*scratch*")
          (goto-char (point-max))
          (insert "\n" str))))

-- 
john

Re: how to get around deprecated function

[Emanuel Berg]

B. T. Raven <btraven@nihil.net> writes:

> The following related function might also benefit
> from some "subtractional betterment" in case you
> care to comment. This just appends the line where
> cursor (or maybe more accurately 'point') happens to
> be to the *scratch* buffer. I know I can make beg,
> end local to function by using let instead of setq
> but I always re-initialize beg and end:
>
> (defun append-line-to-starscratch ();; M-x asl
> (interactive)
> (move-beginning-of-line nil)
> (set-mark-command nil) (setq beg (point))
> (move-end-of-line nil) (setq end (point))
> (kill-ring-save beg end)
> (with-current-buffer "*scratch*"
>      (end-of-buffer) (insert "\n")
>      (yank)))

There are many ways to do that.

The only thing I would change (as in correcting an
error) in the above code is to use `save-excursion'
because you move point but the operation has nothing
to do with moving it - you only do it to get
the endpoints.

I would do it like this:

    (defun append-line-to-buffer (buffer) ; make the function generic (or more so)
      (when (get-buffer buffer)  ; check if input makes sense (always do that)
        (save-excursion          ; use this when point is moved (almost always do that)
          (beginning-of-line)    ; `move-beginning-of-line' is Lisp, this faster (?) C
          (let ((start (point))) ; get start
            (end-of-line)        ; and end
            (let ((line-str (buffer-substring-no-properties start (point)))) ; get string
              (with-current-buffer buffer
                (end-of-buffer)
                (insert line-str "\n")) )))))

    (defun append-line-to-scratch () ; then do (specific) help function
      (interactive)
      (append-line-to-buffer "*scratch*") )

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: how to get around deprecated function

[Emanuel Berg]

John Mastro <john.b.mastro@gmail.com> writes:

> Here's a simplified version, which also adds the
> feature that it will use the active region, if any,
> or the current line otherwise.
>
>     (defun append-to-starscratch (beg end)
>       (interactive
>        (if (use-region-p)
>            (list (region-beginning) (region-end))
>          (list (line-beginning-position) (line-end-position))))
>       (let ((str (buffer-substring beg end)))
>         (with-current-buffer (get-buffer-create "*scratch*")
>           (goto-char (point-max))
>           (insert "\n" str))))

Yes, the `line-beginning-position' and
`line-end-position' are good. They are better than
moving point, even when enclosed by `save-excursion'.

I also like the interactive DWIM region/line combo.

Indeed, they say (goto-char (point-max)) should be
used and not (end-of-buffer).

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: how to get around deprecated function

[Rusi]

On Wednesday, April 29, 2015 at 4:29:14 AM UTC+5:30, B. T. Raven wrote:
> This was posted by mistake to the gnus group:
> 
> >
> >Hello:
> >
> >I am constantly losing short pieces of text left in *scratch* and I wrote this
> >interactive function:
> >
> >(defun save-scratchtemp ();; M-x scr
> >  (interactive)
> >  (switch-to-buffer "*scratch*")
> >  (mark-whole-buffer)
> > (setq start (point) end (mark))
> > (append-to-file start end "c:/mydocu~1/scratchtemp.txt")
> >)
> >
> >It "works" but according to the docs mark-whole-buffer shouldn't be used this
> >way.Is there an understandable (to me) right way of doing this or doing
> >something else that can be invoked as easily?
> >
> >Thanks,
> >
> >Ed
> >

Not exactly what you do but for the same reason I have:

(add-hook 'lisp-interaction-mode-hook  
	  (function (lambda () (setq buffer-offer-save t))))

Re: how to get around deprecated function

[Xavier Maillard]

Hi,

B. T. Raven <btraven@nihil.net> writes:

> This was posted by mistake to the gnus group:
>
>>
>>Hello:
>>
>>I am constantly losing short pieces of text left in *scratch* and I wrote this
>>interactive function:

Here I solved that problem with a very small package:
persistent-scratch.

Regards
-- Xavier.