Re: Copying a list for insertion

[Jean Louis <bugs@gnu.support>]

* Emanuel Berg <incal@dataswamp.org> [2022-10-22 14:08]:
> Jean Louis wrote:
> 
> >> Any reason why you use "progn" in the "stringp" condition?
> >
> > (defun rcd-kill-new (kill)
> >   (cond ((stringp kill) (progn 
> > 			  (kill-new kill)
> > 			  (rcd-message "Killed: %s" kill)))
> > 	 (t (rcd-message "😧 WARNING: Nothing to kill."))))
> >
> > I use it to enclose two functions in one body of functions
> > as `cond' does not allow me to use 2 functions for one
> > condition without enclosing.
> 
> (if (not (stringp str)) ... )

`cond' gives me better overview and I often expand conditions in
future. Long term, `cond' is more flexible then `if'.

> You can also do
> 
>   (let ((str (format "%s" data))) ...)
> 
> But as you know there is already `kill-new' ... `advice-add',
> maybe that happens all the time tho so you don't want that?
> I guess you'll find out. There is `advice-remove'.

Aha, well, I can't use `message' as it does not give me specific
control over my messages. By changing all occurences of `message' to
my specific messaging function, I can then decide what to do with
those messages, for example, I can see them in separate buffer. They
also go in main message buffer, but I like having my separate
buffer. Then I can also choose different buffers for different
purposes, having the actual on the fly log for messages that is
specific to some package or program.

My messaging buffer looks like this:

2022-10-22-14:07:02 RCD DB: updated table `usersdefaults', column `usersdefaults_numberoflatestentries', ID: 1
2022-10-22-14:07:04 Fetching list of people
2022-10-22-14:07:04 Total of 1000 people
2022-10-22-14:08:14 RCD DB: updated table `people', column `people_hyobjects1', ID: 363293

I could as well direct my messages to file for later examination. But
if they are all mixed in one main *Messages* buffer, that is not
enough useful.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/