* bug#6070: 23.1.96; delete-by-moving-to-trash
@ 2010-05-01 1:41 Leo
2010-05-01 2:19 ` Chong Yidong
0 siblings, 1 reply; 6+ messages in thread
From: Leo @ 2010-05-01 1:41 UTC (permalink / raw
To: 6070
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
While experimenting some of the new features, I quite like to use
delete-by-moving-to-trash to double protect deleting files by accident.
However, with (setq delete-by-moving-to-trash t), a lot of (internal)
temporary files are also moved to the trash bin. See the attached file
for an output of `ls' in the .Trash directory after roughly two hours of
emacs.
To reproduce, just (setq delete-by-moving-to-trash t) and carry on with
normal Emacs editing. After a while you should notice the trash bin
heavily populated.
The trash bin is a buffer area to rescue a lost file. Flood it with many
internal temp files makes it very difficult to do so. Before emptying
the trash bin (or remove files permanently) I (I guess many will do the
same) often have a quick look at the files. This is now almost
impossible if delete-by-moving-to-trash has been used.
Could someone take a look at this issue? Thank you.
Leo
[-- Attachment #2: trash-bin-ls.log --]
[-- Type: text/plain, Size: 2007 bytes --]
leo@Victoria ~/.Trash$ ls
!Users!leo!GNUS!.newsrc.eld.~106~ diff16258KRU diff26258KKg emacsca2LL8 jka-com6258xvm
#%2Ascratch%2A#88815TN# diff16258LEz diff26258WaT emacsgM68Dw jka-com8881_hQ
#%2Ascratch%2A#8969WYO# diff16258XUm diff26258WhH emacsmgCrUd jka-com8881yXK
#*message*-20100308-115723# diff16258jrN diff26258XNy emacsqCMK1i jka-com89692BS
#.newsrc-dribble# diff16258v7A diff26258Xba emacsvlXg3W jka-com8969ctF
#init# diff16258w8H diff26258jyB epg-output896926d jka-com8969dZw
#init# 12-48-39-517 diff16258wnr diff26258kes epg-output8969DFk jka-com8969p3L
#init# 12-50-18-590 diff16258wuf diff26258w1T epg-output8969PcL jka-com8969qj2
#init# 12-59-40-774 diff16258xoy emacs0K0etW epg-output8969cmR server
#init# 13-01-51-136 diff262588FH emacs16PAo6 epg-output8969pwX server 11-57-09-965
diff162589_Z diff2625894l emacs9lYpE7 epg-signature8969QPq
diff16258JQN diff262589GO emacsTRvUUZ jka-com6258-5s
diff16258JXB diff262589NC emacsVJlI9u jka-com6258jkZ
diff16258KDs diff262589xx emacsWVYHIH jka-com6258klg
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6070: 23.1.96; delete-by-moving-to-trash
2010-05-01 1:41 bug#6070: 23.1.96; delete-by-moving-to-trash Leo
@ 2010-05-01 2:19 ` Chong Yidong
2010-05-01 4:00 ` Leo
0 siblings, 1 reply; 6+ messages in thread
From: Chong Yidong @ 2010-05-01 2:19 UTC (permalink / raw
To: Leo; +Cc: 6070
Leo <sdl.web@gmail.com> writes:
> While experimenting some of the new features, I quite like to use
> delete-by-moving-to-trash to double protect deleting files by accident.
>
> However, with (setq delete-by-moving-to-trash t), a lot of (internal)
> temporary files are also moved to the trash bin. See the attached file
> for an output of `ls' in the .Trash directory after roughly two hours of
> emacs.
Good point. I have commited a change that inhibits trashing for
jka-compr, server, diff, and epg. Probably more such changes are
required.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6070: 23.1.96; delete-by-moving-to-trash
2010-05-01 2:19 ` Chong Yidong
@ 2010-05-01 4:00 ` Leo
2010-05-01 4:44 ` Leo
0 siblings, 1 reply; 6+ messages in thread
From: Leo @ 2010-05-01 4:00 UTC (permalink / raw
To: Chong Yidong; +Cc: 6070
On 2010-05-01 03:19 +0100, Chong Yidong wrote:
>> However, with (setq delete-by-moving-to-trash t), a lot of (internal)
>> temporary files are also moved to the trash bin. See the attached file
>> for an output of `ls' in the .Trash directory after roughly two hours of
>> emacs.
>
> Good point. I have commited a change that inhibits trashing for
> jka-compr, server, diff, and epg. Probably more such changes are
> required.
Thank you for the quick fix. I will be using it and let you if there are
other cases need fixing.
Leo
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6070: 23.1.96; delete-by-moving-to-trash
2010-05-01 4:00 ` Leo
@ 2010-05-01 4:44 ` Leo
2010-05-01 12:43 ` Leo
0 siblings, 1 reply; 6+ messages in thread
From: Leo @ 2010-05-01 4:44 UTC (permalink / raw
To: Chong Yidong; +Cc: 6070
On 2010-05-01 05:00 +0100, Leo wrote:
>> Good point. I have commited a change that inhibits trashing for
>> jka-compr, server, diff, and epg. Probably more such changes are
>> required.
>
> Thank you for the quick fix. I will be using it and let you if there are
> other cases need fixing.
delete-auto-save-file-if-necessary still creates a lot temp files in the
trash bin. Any idea where names like emacs6ljgy9 or emacsXWkc8c come
from? They look like temp file. Is it from with-temp-file?
Cheers,
Leo
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6070: 23.1.96; delete-by-moving-to-trash
2010-05-01 4:44 ` Leo
@ 2010-05-01 12:43 ` Leo
2010-05-01 14:17 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Leo @ 2010-05-01 12:43 UTC (permalink / raw
To: bug-gnu-emacs
On 2010-05-01 05:44 +0100, Leo wrote:
>> Thank you for the quick fix. I will be using it and let you if there are
>> other cases need fixing.
>
> delete-auto-save-file-if-necessary still creates a lot temp files in the
> trash bin. Any idea where names like emacs6ljgy9 or emacsXWkc8c come
> from? They look like temp file. Is it from with-temp-file?
These are from the following files in Gnus:
----------------
leo@Victoria ...share/emacs/23.1.96/lisp/gnus$ zgrep
-n "delete-file" mm*.el.gz
mm-decode.el.gz:874: (ignore-errors (delete-file file))
mm-decode.el.gz:899:
(delete-file ,file)
mm-decode.el.gz:1031: (ignore-errors (delete-file (car object)))
mm-decode.el.gz:1434: (delete-file file)))))
mm-view.el.gz:366: (delete-file file))
mml-smime.el.gz:140: (delete-file tmp))
mml-smime.el.gz:143: (delete-file tmp))
mml2015.el.gz:858: (delete-file signature-file)
mml2015.el.gz:863: (delete-file signature-file)
----------------
In my view the current implementation of this feature is far from
optimal. It is almost sure that every occurrence of delete-file should
not move things to trash bin. And it seems only a handful of commands
need to move things to trash bin when deleting. Do you have a better way
of fixing this bug? Thank you.
I have been thinking whether it will be better to introduce a new
function delete-file-soft that respects delete-by-moving-to-trash while
leaving delete-file alone.
Leo
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6070: 23.1.96; delete-by-moving-to-trash
2010-05-01 12:43 ` Leo
@ 2010-05-01 14:17 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2010-05-01 14:17 UTC (permalink / raw
To: Leo; +Cc: bug-gnu-emacs
> From: Leo <sdl.web@gmail.com>
> Date: Sat, 01 May 2010 13:43:28 +0100
> Cc:
>
> In my view the current implementation of this feature is far from
> optimal. It is almost sure that every occurrence of delete-file should
> not move things to trash bin. And it seems only a handful of commands
> need to move things to trash bin when deleting. Do you have a better way
> of fixing this bug?
Perhaps the few functions that create temporary files should record
the file in some list, and delete-file could then consult that list to
decide whether to delete or move to trash bin.
Alternatively, perhaps only a few interactive commands should actually
move to trash, while all the other uses of delete-file should actually
delete.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-05-01 14:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-01 1:41 bug#6070: 23.1.96; delete-by-moving-to-trash Leo
2010-05-01 2:19 ` Chong Yidong
2010-05-01 4:00 ` Leo
2010-05-01 4:44 ` Leo
2010-05-01 12:43 ` Leo
2010-05-01 14:17 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.