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: Tue, 3 Nov 2020 22:31:12 +0300 Message-ID: References: <20201103104340.q34kqfita55w2u7h@E15-2016.optimum.net> <20201103111507.mpfijvlv3kodauxm@E15-2016.optimum.net> <20201103171244.2wpalolm5qrfc5pg@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="4858"; 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 Tue Nov 03 20:31:58 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 1ka229-00016B-6q for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Nov 2020 20:31:57 +0100 Original-Received: from localhost ([::1]:54240 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ka228-0002vH-81 for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Nov 2020 14:31:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ka21c-0002Wb-EG for emacs-devel@gnu.org; Tue, 03 Nov 2020 14:31:24 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:35319) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ka21a-0006si-1l for emacs-devel@gnu.org; Tue, 03 Nov 2020 14:31:23 -0500 Original-Received: from localhost ([::ffff:41.210.145.80]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002A0B3E.000000005FA1B006.00002B9B; Tue, 03 Nov 2020 19:31:18 +0000 Content-Disposition: inline In-Reply-To: <20201103171244.2wpalolm5qrfc5pg@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/03 08:34:00 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:258660 Archived-At: * Boruch Baum [2020-11-03 20:13]: > On 2020-11-03 19:07, Jean Louis wrote: > > It works, but it does not give me safety feeling. > > I don't understand the comment. It never happened that I cannot install package from buffer or file. At first sight it looks good inside. Maybe it is bug in Emacs or maybe some wrong formatting in the package what I doubt. Then I am, maybe wrongly, assuming that package was not tested if it can be installed in that way. And then I am of course careful with such package, I do not know what it brings on me. I hope you get idea. Neither M-x package-install-file works neither M-x package-install-from-buffer > Are you saying that the package could / should do something > differently? Also, if you have an account on github, you give > feedback there or open issues there. Package may have good features for something and is not bad to discuss here. Sorry that I find personally Github appalling. I do report sometimes bugs there and I interact by email or with website by using LibreJS. I hope there is nothing wrong with email. Would Github not have non-free Javascript, maybe I would vouch for it. There are so many free software hosting providers like OS Trisquel, the fully free OS endorsed by FSF, they offer hosting: https://devel.trisquel.info/groups/trisquel > Or you can just email me, but dealing with a organized forge > environment like github / gitlab helps keep things organized. Gitlab is by principle different. Trisquel offers something like Gitlab. > > It broke my console. > > Whoa. I use console emacs, and never encountered such a problem, so > that's serious. Can you please give details? I cannot give much of details. As it was not possible to do anything unde XTerm (not real console). Video is here: https://gnu.support/images/tmp/2020-11-03-21:57:51.ogv Of course it may be due to my settings. And I have used emacsclient. > I've been using this package for months, and it's the product of > accumulated piecemeal work over years - all on console emacs. Please > send me details to reproduce. Now is maybe time that somebody tries it out. People use programs in different manners, different outcomes are the result. > Please try to send details to reproduce. > > > On X it is creating new frame. > > That's the expected behavior - to have a dedicated emacs frame for two > dired panels and their associated temporary buffers (ie. shell buffers > and a quick-view buffer). As I did not need two frames so it is not pleasant. The classic dired frame appears in front of diredc frame. Maybe on your side is different. That is how is on my side. I am orderding diredc and I get classic dired. What if I am in EXWM then maybe I would not even see what happened. > > - test it in EXWM > > Interesting. I've never used EXWM, so I'm interested in how that > went. I just say to you to test it. If this would work better I would test myself. Sometimes I do diredc and happens nothing. It just switches frames. No fancy stuff. Maybe I would need to restart Emacs to see it again, I cannot know. It does not give me good feeling when M-x diredc does not work for second or fifth or ninth time. o - opens new frame but not file that I selected, very unexpected behavior for me Trash management I prefer being handled by expected built-in Emacs behavior. I did not try yours. shells - you may add common shells on OpenBSD/FreeBSD/NetBSD/Minix/Dragonfly BSD systems. {C-h m} did not give me any explanation of diredc-mode-map, for me very unexpected, I was thinking it would be automatic. getfacl - I do not have as command on my system Hyperbola GNU/Linux-libre and I do not know what it is, so I cannot use "get more file info" C-c b a - to add bookmark, isn't it just same number of key strokes as C-x r m ? ' - is good feature to launch shell quickly, I may adopt that. But I get this: export d1="~/Programming/emacs-lisp/others/" d2="" f1="~/Programming/emacs-lisp/others/diredc.el" f2="" t1="(/home/data1/protected/Programming/emacs-lisp/others/diredc.el)" t2="nil" sh-4.4$ sh-4.4$ sh-4.4$ if that is expected, I do not know. It did not choose my shell from /etc/passwd - it went straight into sh C-x o - when switching from window to window is currently confusing me as buffer disappears and I then see instead of opened file again the diredc listing, then if I had shell on left side, I kill it, my right side becomes some other buffer! Too many unexpected things happening. diredc-mode - disabled in all buffers, but colors remain and is not really disabled, it comes back. Then I see line movements in both windows, left and right. I have global-hl-line-mode turned on. I can see in other window the highlighted line but not on same line, imagine how I feel, like on drugs. normal dired does not work after diredc, error: let*: Wrong type argument: consp, "/home/data1/protected/Programming/emacs-lisp/others/" q - does not work any more, Use \[diredc-exit] for diredc-exit, or M-x quit-window for the emacs primitive. Let me restart...