gmane.emacs.devel

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Phil Jackson — 2008-08-30T10:43:15

I think you misunderstand, this (now way off topic) conversation came about when Lennart talked about having some sort of global trash can interface. I was trying to state that you can't make assumptions about that sort of interface in GNU/Linux that you can with Windows and OSX. Cheers, Phil

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Alan Mackenzie — 2008-08-30T10:18:35

Hi, Phil, On Sat, Aug 30, 2008 at 10:49:16AM +0100, Phil Jackson wrote: That's kind of missing the point. It also verges on rubbing salt into the wound. You need, somehow, to become aware of this "choice" before doing irrevocable damage. I don't think Lennart would now be unhappy if something in Dired had made him aware of what he was about to do.

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Eli Zaretskii — 2008-08-30T10:11:50

There certainly are, quite a few of them, actually.

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Phil Jackson — 2008-08-30T09:49:16

No with GNU/Linux you have choice. My system works exactly the way I want it and not the way any corp. wants it to.

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Johannes Weiner — 2008-08-30T09:36:06

Probably to very few Emacs users. First of all, you don't do that by accident. You mark the files first and delete in batch afterwards. Secondly, dired's interface resembles the output of an old unix command, so I expect all operations on the listed files to be done in the same flavor. And the documentation right now even tells me that it behaves like `rm'! Changing that would be like teaching `rm' about a trash can. So if you do see a representation of files that seems alien to you, read in the documentation of a program `rm' that doesn't tell you anything and *then go ahead and throw into it your precious files with the expectation that the interface would behave like all other stuff you know while everything else of the program seems different and while knowing in advance that you will later need these files again*... Come on! Hannes

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Alan Mackenzie — 2008-08-30T09:40:03

Hi, Stephen! On Sat, Aug 30, 2008 at 12:11:34PM +0900, Stephen J. Turnbull wrote: Dangerous - aiming for (car nail), you might cdr it, and at the next swipe hit toe nail instead of tail nail, carnage indeed. At least, it has become so. Not meaning to be unkind to Lennart, but we've ALL lost critical files by doing stupid things. At least I have, and it cost me several days of hard (but interesting) grind to recover the bulk of that file. Aren't there effective file undelete programs for MS-Windows? There certainly were for MS-DOS's FAT file system.

Re: print hash table to disk and reread in hash table

Ted Zlatanov — 2008-08-30T09:17:54

On Sat, 30 Aug 2008 07:18:07 +0200 tomas< at >tuxteam.de wrote: t> On Fri, Aug 29, 2008 at 01:10:11PM -0500, Ted Zlatanov wrote: EZ> You mean, like bindat.el? t> I don't know the context -- but I have been musing on and off about a t> persistent hash (backed by something like GDBM), similar to what Perl t> offers. I was trying to serialize a hashtable to a file, and there's no good way other than converting it to a list or making a file of (puthash) statements. bindat.el seems OK but doesn't seem to have a hashtable spec in the format. Persistent storage is useful and could easily be implemented with a small sqlite database file. It could be an option when creating a hashtable. It doesn't solve serialization, though. The file is not human-readable, which is the advantage of formats like the Gnus newsrc file. So it's not what I'm looking for, but still an useful addition to Emacs IMO :) Ted

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Johannes Weiner — 2008-08-30T09:11:37

Sorry, translation error. Remove the -on ending by either deleting it or moving it into the trash-can. Why do you expect it from the UI in the first place? Even on Windows there are probably more interfaces to delete a file that don't have a notion of a trash can than interfaces that have. But whatever the fix is, please don't have me extend my ~/emacs/garbage-collect.el to sanitize the dired behaviour again. What I mean to say is: if your expectation of the the interface differs from what has been there for a long time, do not punish long-standing users with new annoying warnings, silent/noisy behaviour change, creation of stuff like ~/Trash or another flag which they have to set instead of the people requesting different behaviour. Agreed. Hannes

Re: Gnus number of unread articles change when switching from 22.2to 23

Sven Joachim — 2008-08-30T07:18:29

Yes, see etc/GNUS-NEWS. Read the sections about marks in the mentioned file. You may want to set nntp-marks-is-evil to t if you keep switching between the to versions. Another idea would be to use No Gnus in Emacs 22. Sven

Re[2]: CEDET, DL & parsing thoughts (was Release plans)

Eric M. Ludlam — 2008-08-30T09:04:05

I can imagine how it *might* be done, though to be honest, it may be that having "eval" actions in the real bison generated parser might be all it takes to slow it down. I would not claim this as an area of expertise. It would work like this: 1) lex/grammar file -> flex & bison -> c-files 2) compile flex-bison output + generic interface -> dl 3) load dl, bind generated parser commands to fcns 4) bind those fcns to generic CEDET/Semantic calls 5) Semantic infrastructure calls into the dll for parsing goodness. My goal was to build a tool that would make it easy for anyone to write a parser that would feed into an infrastructure that provides the complex specialy functionality. This is true now for what is in CEDET. There are already 6 grammars that work pretty well that enthusiasts of a particular language have written. (Erlang, python, csharp, javascript, 2 php parsers, and ruby.) It is my understanding that only nxml, and that new javascript mode do this, making the undertaking a statistically l

Re: Gnus number of unread articles change when switching from 22.2to 23

Tassilo Horn — 2008-08-30T07:10:45

Hi! Hm, the Gnus manual states that downgrading from Oort Gnus (5.10.x) to older versions isn't a good idea. So I dare to say that switching between major versions may lead to troubles in general. Bye, Tassilo

Re: Gnus number of unread articles change when switching from 22.2to 23

Frank Schmitt — 2008-08-29T16:54:53

I've got no idea what might cause this, but I see the same problem.

Re: print hash table to disk and reread in hash table

2008-08-30T05:18:07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Aug 29, 2008 at 01:10:11PM -0500, Ted Zlatanov wrote: I don't know the context -- but I have been musing on and off about a persistent hash (backed by something like GDBM), similar to what Perl offers. Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIuNgPBcgs9XrR2kYRAoxsAJ99r4ARwpnX1GQgaoX08E2iy86M8wCfUV4t C81sI7b0SZFrOD6GkBw3Nb4= =0/DR -----END PGP SIGNATURE-----

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

2008-08-30T05:10:49

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Aug 30, 2008 at 03:16:14AM +0100, David De La Harpe Golden wrote: [...] Sure. The Windows method of dealing with network-hosted files is so superior (just deleting *without* moving to trash!). Let's do that, because that's what users expect (no!) Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIuNZYBcgs9XrR2kYRAo6iAJ9JXoWuguAuK88EukUsOHeP5zmFegCfdPPX Q+1sRy2MXiCOhTk66U9LHto= =DfVq -----END PGP SIGNATURE-----

Re: Improving X selection?

David De La Harpe Golden — 2008-08-30T04:08:29

Well, they are somewhat like the kill-ring.... There's no existing standard api* for generally accesing them though AFAIK, and it's not immediately clear to me how you would mesh them if you wanted to. I'm not sure you would want to - I already use the emacs kill-ring (with yank-pop-change-selection set!) AND klipper - you end up over time with a lot of the same snippets on both the klipper menu and the kill ring, but that doesn't matter much at all? If you did want to, it might be more a case of one supplanting the other than meshing i.e. emacs providing general system clipboard history functionality, like watch-all-system-clipboard-changes-and-autoadd-them-to-kill-ring or emacs having a use-system-clipboard-history-as-kill-ring option such that the system pseudo-kill-ring supplants the emacs kill ring Especially the latter is probably not very workable, given emacs' needs (text properties...). The former could work, at least for textual clipboard contents, but is it worth the bother? * FWIW, one c

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Stephen J. Turnbull — 2008-08-30T03:14:42

> * Gilaras Drakeson: > > Lennart Borgman writes: > > > > > I just deleted a file because I misunderstood dired. I needed that file > > > (of course). > > > > > > And then I found that dired did not make any backup and did not use > > > windows Recycle bin. > > > > Can we have another dired keybinding for move-file-to-trash? > > (e.g., `b', with companion `% b'. This can be called dired-do-bury). > > And while we're requesting features, what about browse-trash and > empty-trash? How about an artificial Dired file "Trash" which refers to the Trash if non-empty? Then deleting it empties the trash with confirmation, and `find'ing it opens a Dired browser on it.

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

Stephen J. Turnbull — 2008-08-30T03:11:34

> It's a linguistic confusion between communities, in part. God, you're smart, Tom. At least in the "finding the head of the nail so you can whack it with a hammer" sense. ;-) Now, since these are communities we're talking about, not simply a minor twirk, there are a bunch of other things that are associated with something like this difference in definition of "delete". I conclude that this thread is a waste of time; Lennart should go customize his .emacs, and then everybody should get to work on (1) implementing cascading custom themes and (2) providing a UI that (a) allows Windows folks to have Windowsy behavior, Mac folks to have "for the rest of us" behavior, and *nix folks to have "for the sentient" behavior, (b) an (optional) subcommunity thematic for eg Vista cripples vs XP wonks and (c) a "new-in-version-X.Y" theme advertised on the splish-screed. And all easily accessible and well-advertised.

Re: CEDET, DL & parsing thoughts (was Re: Release plans)

Lennart Borgman (gmail — 2008-08-30T02:24:19

So (if I understand currectly from the little I know about this), a bit sadly, if there were sutiable flex and bison dlls these could be used instead (if Davids specials were backported too) and would be quite a bit faster. This does not relate to the general question of loading dll:s. This is a special case that I suppose Richard would approve. (I have no idea, but I guess there are no flex and bison dlls availabe, or are there?) However for new languages all this requires also writing language specific bison grammars. Is this perhaps be a big job that just a few person have insight in how to do? nxml-mode does that, but on its own of course. Great. Then we can hope for that it is easy to get started using CEDET.

Re: Why < at >#! is not Emacs using the Recycle bin on w32?

David De La Harpe Golden — 2008-08-30T02:16:14

Bear in mind the fact it says 0.7 doesn't mean it is not widely used. in this case the major desktop environments implement it. I think fd.o specs remain described as "draft" to avoid claiming to be some sort of standards body... http://www.freedesktop.org/wiki/Specifications - I dunno what rule they have for moving a spec from "draft specifications that are new" to "draft specifications that have pretty good de facto adoption". Given the sheer number of alternative free desktops, it probably takes a while... And in this case, no doubt some desktops are developed by folk with an even lower opinion of trashcans than me. :-) IMO the optional-per-volume-trash-dir aspects are particularly iffy, it's a bit of extra implementation complexity in a security sensitive area for what is IMO quite a low-value feature these days. Could have just left it at the "home trash" and put up with the occasional and ever-less-relevant inefficiency. Plus there may be ass-out-of-u-and-me bits left out - it might "go without s

Re: what is TERM?

Daniel Colascione — 2008-08-30T02:16:20

I actually used Slirp the PPP/SLIP-on-terminal emulator) for some, ah, creative routing having to do with my university's firewall. You might as well suggest using slirp in the changelog entry removing TERM support.

Re: Meanness

Daniel Colascione — 2008-08-30T02:10:09

I know several people who began using Free Software systems because they first used Emacs on Windows, moved to Cygwin, and eventually to entirely free operating systems.