[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: privacy function for deleting cookies, history, etc. [SNIPPET INCLUDED]
On 04/02/2019 13:28 -0500, Boruch Baum wrote:
>> And how is rm -f better than emacs's delete-file?
> The edge case of a file somehow getting minor-level protection.
What do you mean by minor-level protection?
>> > (cmd (progn
>> > (while (and (setq cmd (pop cmds))
>> > (not (file-executable-p (car cmd)))))
>> > cmd))
>> Seems dangerous to use "cmd" inside its own initialization. Better user
>> let-form with a new var for use in loop.
> That's not a constructive comment to which I can respond. "Seems" is a
> weasel-word, "dangerous" is a vague scare-mongering word that you don't
> substantiate, and your second sentence I can't make sense of - it would
> be better to actually code an alternative snippet.
These words are usually fine in tech discussion :-)
Here, it's dangerous because the value-form for cmd is executed before
cmd is added to environment, so in fact it's some free variable named
cmd is assigned to, and who knows which effects it may trigger.
I meant something like:
(cmd (let (tmp)
(while (and (setq tmp (pop cmds))
>> > (cmd-string (if cmd
>> > (format "%s %s" (car cmd) (cdr cmd))
>> > "emacs' delete-file"))
>> Hm? I don't get this "emacs' .." value.
> There's nothing to get, it's an output string; it give the variable
> cmd-string the value "emacs' delete-file".
Yes, but what does this value mean? It looks obscure. Yes, a person
may look closer into code, but it could be more obvious, I think.
>> > (directory-files w3m-profile-directory 'full
>> > "^w3m\\(cache\\|cookie\\|el\\|src\\|tmp\\)" 'nosort))))
>> What does el/src have to do with private files?
> If you look through the code, you'll see how those files are used.
It's clear what the code does with them, but it's unclear why they
should be considered as something to be deleted/cleared - this is what
the comment was about.
>> > (switch-to-buffer stdout-buf)
>> This functions states in the docstring: "WARNING: This is NOT the way to
>> work on another buffer temporarily within a Lisp program! Use
>> ‘set-buffer’ instead. That avoids messing with the window-buffer
> I did read that before I decided that the function was the correct tool
> for this job, because in this use-case, we want the buffer to be visibly
> presented to the user while the buffer is being acted upon. The
> scrubbing process that the snippet performs could take many seconds, so
> this will show the user the progress as it unfolds. The warning in the
> docstring is for uses meant not to be visible to the user during its
>> > (insert "Beginning emacs-w3m history scrub "
>> > (format-time-string "%Y-%m-%d %H:%M")
>> > "\n\nDeleting files ...\n")
>> Actually, maybe just write a shorter log to *Messages*?
> This speaks to my prior comment, and is an opportunity to elaborate on
> it. What I want is to confront the user with the details of the progress of
> the operation, and then allow the user to then delete that record, ie.
> kill-buffer, or possibly save it. My opinion is that the messages are
> too much detail for the message log.
*Messages* is more standard interface for things which Emacs does, and
the log could be much shorter. If all packages start writing their own
log files, we would be overwhelmed by them. Debug buffers are another
thing, they usually do really need their own buffer. But here we have a
progress indication - have a look at what desktop-read does, for
example. Just an opinion.