From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: Friendlier dired experience [CODE INCLUDED] Date: Wed, 4 Nov 2020 20:15:05 +0300 Message-ID: References: <20201103111507.mpfijvlv3kodauxm@E15-2016.optimum.net> <20201103171244.2wpalolm5qrfc5pg@E15-2016.optimum.net> <20201103211312.grkaloqedpj7anbn@E15-2016.optimum.net> <20201104085425.te4qwhnrjclchq7b@E15-2016.optimum.net> <20201104131730.bbgye4zbfsqpr6gu@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10886"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/+ (1036f0e) (2020-10-18) Cc: Emacs-Devel List To: Boruch Baum Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 05 15:02:00 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kafpw-0002hZ-76 for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 15:02:00 +0100 Original-Received: from localhost ([::1]:50180 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kafpt-0000RT-Lz for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Nov 2020 09:01:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34426) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kafno-0007R8-Ai for emacs-devel@gnu.org; Thu, 05 Nov 2020 08:59:48 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:58553) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kafnm-0001Vw-0d for emacs-devel@gnu.org; Thu, 05 Nov 2020 08:59:47 -0500 Original-Received: from localhost ([::ffff:197.157.0.43]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002A0D01.000000005FA4052F.0000356B; Thu, 05 Nov 2020 13:59:10 +0000 Content-Disposition: inline In-Reply-To: <20201104131730.bbgye4zbfsqpr6gu@E15-2016.optimum.net> Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/05 08:59:12 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: 6 X-Spam_score: 0.6 X-Spam_bar: / X-Spam_report: (0.6 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258718 Archived-At: * Boruch Baum [2020-11-04 16:18]: > On 2020-11-04 13:39, Jean Louis wrote: > > https://gnu.support/images/2020/11/2020-11-04/2020-11-04-13:01:29.ogv > > Hi. I'm really enjoying your video, and will need to watch it a few more > times before I can get through it without laughing. Please watch with laughing, you are welcom. > The key sequences this time indicate that you are doing your best to > avoid actually using diredc and are working hard to create > complications for yourself. For example, you launch diredc, but then > instead of using it you make a direct use of M-x dired. No, that may be mistake, it was not at all my intention. It was only to verify if I am on clean Emacs with my configurations and all packages loaded would it block again on the console. That was main purpose. I maybe get stuck with completion functions and you maybe see dired... but not my intention. I did not want to move files, rename or do anything more than TAB and ' for shell. > Then you perform C-x 3 to make it look to you like you might be in > diredc (you aren't). When I have got one window, I had to split it before trying out if TAB will work in that one, split window, right? > And it continues. I've watched the video a few times but have never > gotten to the end yet, because I'm laughing too hard. That is good... > The usage instructions for diredc are pretty short, so try reading > them. I read them all line by line, but not that I wish to invoke it. In general I can make review of your package and play little with it. Not that I wish to play with my files. I hope you get the point. Same with other dired improving packages. > That's what they're for, and if they're unclear I'll be happy to edit > them for clarity and simplicity. If you did read them once, it's obvious > that either they weren't clearly written or you weren't paying > attention. Come on, no. By my review you could see that I went through all commentary in the package. I did not want to use anything. Instead you put attention on how I don't put attention, you could make diredc-mod-map actually working. > The video shows that you eventually figured out that after performing > M-x package-install-from-buffer, you need to take the extra step of > loading the library (you didn't want to follow my simpler instructions > to just evaluate the buffer, but that's cool; emacs is all about > choices). Of course I know what you wrote, of course I know how to evaluate buffers, etc. But you improved the package since I told you last time that it does not install? Right? So you changed the space and then I have been testing new improvement to show it is installing. Isn't that nice? > The intention is for the users to perform M-x diredc (it should be bound > to S-) to launch it, *and* to use the same command to toggle into > and out of the diredc frame. That is clear, I know that. When package-initialize finishes, if you have some autoload functions, M-x diredc will start the functions and load whatever. > A design goal of the package is to avoid accumulating more than two > dired buffers, and to keep an orderly dired configuration. I understand this principle. It really pushes into Midnight Commander direction. Not that I need that. I do not count or put attention how many buffers I have. Often hundreds and hundreds of buffers. Usuall I am handling in a week sometimes 5000+ file processing functions through Emacs, like video processing by using `dired-do-async-shell-command', preparing thousands of images for multiple websites within Website Revision System, optimizing images for the website page speedups, describing images and videos straight within Emacs to later automatically include such into website pages. Video processing is tedious so I distribute processing to other computers in network that in turn process them without my attention or my computer getting too hot. Like for Dired I am very much familiar with it. But how many buffers are there, I don't put attention on it. I remember I was doing that somewhere 1999 when I was surprised that buffers are opening and I confused myself, I was thinking is it good or bad and started always killing them or making sure of it. Today I only do {C-x s} and that is all. > There should never be a need to call dired itself directly; When you > want to use dired, perform S- to enter diredc. Main point was not keybindings. But that it does not block in console. For key bindings make the {C-h m} work first. Jean