From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Glenn Linderman Newsgroups: gmane.emacs.bugs Subject: bug#32581: 24.4; make recover-file a prompt instead of a warning Date: Sat, 13 Jul 2019 19:10:56 -0700 Message-ID: <7128dbb2-de2c-45e2-2cd6-fd55bc8bb6ab@g.nevcal.com> References: <4cb978b3-9453-29c5-4757-4ef804bf5c54@g.nevcal.com> <87sgrazmc0.fsf@mouse.gnus.org> <81bd4ae4-60de-7a64-24e6-d6e43c89c13f@g.nevcal.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CBA5FA460B773F792F74F66A" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="219372"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: 32581@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 14 04:12:09 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hmTzk-000uxA-OZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Jul 2019 04:12:08 +0200 Original-Received: from localhost ([::1]:58700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmTzj-0006vG-4O for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2019 22:12:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35525) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmTzf-0006ts-QT for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 22:12:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmTze-0000ts-8f for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 22:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34849) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hmTze-0000td-3h for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 22:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hmTzd-00035p-Rx for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 22:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Glenn Linderman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Jul 2019 02:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32581 X-GNU-PR-Package: emacs Original-Received: via spool by 32581-submit@debbugs.gnu.org id=B32581.156307027211832 (code B ref 32581); Sun, 14 Jul 2019 02:12:01 +0000 Original-Received: (at 32581) by debbugs.gnu.org; 14 Jul 2019 02:11:12 +0000 Original-Received: from localhost ([127.0.0.1]:43670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmTyp-00034m-TB for submit@debbugs.gnu.org; Sat, 13 Jul 2019 22:11:12 -0400 Original-Received: from cadetblue.birch.relay.mailchannels.net ([23.83.209.28]:64000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmTyn-00034d-3Z for 32581@debbugs.gnu.org; Sat, 13 Jul 2019 22:11:09 -0400 X-Sender-Id: interserver|x-authuser|email@ywawy.com Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C059B1A189A; Sun, 14 Jul 2019 02:11:07 +0000 (UTC) Original-Received: from webhosting2025.is.cc (100-96-30-63.trex.outbound.svc.cluster.local [100.96.30.63]) (Authenticated sender: interserver) by relay.mailchannels.net (Postfix) with ESMTPA id 3676E1A15AD; Sun, 14 Jul 2019 02:11:06 +0000 (UTC) X-Sender-Id: interserver|x-authuser|email@ywawy.com Original-Received: from webhosting2025.is.cc ([TEMPUNAVAIL]. [64.20.52.82]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.3); Sun, 14 Jul 2019 02:11:07 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: interserver|x-authuser|email@ywawy.com X-MailChannels-Auth-Id: interserver X-Ruddy-Abortive: 425cc9081ae70837_1563070267450_2262778579 X-MC-Loop-Signature: 1563070267450:2602636603 X-MC-Ingress-Time: 1563070267450 Original-Received: from 24-205-219-131.dhcp.crcy.nv.charter.com ([24.205.219.131]:52328 helo=[192.168.43.252]) by webhosting2025.is.cc with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hmTyb-003NbH-9a; Sat, 13 Jul 2019 22:10:59 -0400 In-Reply-To: Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AuthUser: email@ywawy.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162959 Archived-At: This is a multi-part message in MIME format. --------------CBA5FA460B773F792F74F66A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/13/2019 6:35 AM, Lars Ingebrigtsen wrote: > Glenn Linderman writes: > >> I think you understood correctly. I'm not sure what version of which >> Python-mode I have, but could probably figure it out somehow (I love emacs, >> because it has extensions, but I'm not real good at writing or understanding >> elisp: I use other people's extensions, mostly, and a bit of cut-n-paste >> programming for a few more customizations). >> >> Probably the following message, that I get every time I open the file. >> >> "Warning: no abbrev-file found, customize `abbrev-file-name' in order to make >> mode-specific abbrevs work." > Right. Some modes are chatty at startup and hides warnings you're > interested in. > > It's perfectly valid to not want to load an autosaved file, and making > Emacs prompt would be an inconvenience, in my opinion. I agree that a prompt (a forced interaction) would not be appropriate. > Perhaps Emacs should treat auto-saved files a bit more like what it does > with files that have changed? I.e., if you try to edit a file with an > auto-save file, it should prompt you something like "foo has auto save > data; really edit the buffer?" or something? This is a very interesting idea. It is only when you go to edit that you would lose the auto-save file, so that would be a "last-chance" to retrieve your data, and you would be interacting with the file at that point anyway, so a forced interaction would be less intrusive than at load time. > Would that make sense? > That would certainly be safer than the current behavior, but would add the forced interaction. My thought was more along the lines of some sort of message priority, where informational messages like the abbrev-file-name warning could not override a more important message... Of course, everyone thinks there message is most important, so that might be difficult to enforce or rank. Another idea is that multiple messages could be displayed concurrently in an expanding echo area, and that none would vanish until the first user interaction. That way, when the user turns their attention to the emacs window again, all the messages from startup activities would be visible until the first keystroke or significant mouse operation (more than just a click) for the window occurs. This wouldn't require a forced interaction, and wouldn't require ranking message priorities, but would allow the user an opportunity to see all the startup messages. And it could generalize to non-startup situations: any occasion when macros or scripts are running and produce multiple messages without user interaction might want to grow the echo area to display them until there is another required user interaction. Thanks for considering the possibility of enhancing something in this area, as it was a significant amount of work that was lost, and it could potentially happen again, and not just to me (I'm a little sensitized to the possibility now, others may not yet be). --------------CBA5FA460B773F792F74F66A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 7/13/2019 6:35 AM, Lars Ingebrigtsen wrote:
Glenn Linderman <v+python@g.nevcal.com> writes:


I think you understood correctly.  I'm not sure what version of which
Python-mode I have, but could probably figure it out somehow (I love emacs,
because it has extensions, but I'm not real good at writing or understanding
elisp: I use other people's extensions, mostly, and a bit of cut-n-paste
programming for a few more customizations).

Probably the following message, that I get every time I open the file.

"Warning: no abbrev-file found, customize `abbrev-file-name' in order to make
mode-specific abbrevs work."

Right.  Some modes are chatty at startup and hides warnings you're
interested in.

It's perfectly valid to not want to load an autosaved file, and making
Emacs prompt would be an inconvenience, in my opinion.

I agree that a prompt (a forced interaction) would not be appropriate.
Perhaps Emacs should treat auto-saved files a bit more like what it does
with files that have changed?  I.e., if you try to edit a file with an
auto-save file, it should prompt you something like "foo has auto save
data; really edit the buffer?" or something?

This is a very interesting idea. It is only when you go to edit that you would lose the auto-save file, so that would be a "last-chance" to retrieve your data, and you would be interacting with the file at that point anyway, so a forced interaction would be less intrusive than at load time.

Would that make sense?
That would certainly be safer than the current behavior, but would add the forced interaction.

My thought was more along the lines of some sort of message priority, where informational messages like the abbrev-file-name warning could not override a more important message... Of course, everyone thinks there message is most important, so that might be difficult to enforce or rank.

Another idea is that multiple messages could be displayed concurrently in an expanding echo area, and that none would vanish until the first user interaction. That way, when the user turns their attention to the emacs window again, all the messages from startup activities would be visible until the first keystroke or significant mouse operation (more than just a click) for the window occurs. This wouldn't require a forced interaction, and wouldn't require ranking message priorities, but would allow the user an opportunity to see all the startup messages. And it could generalize to non-startup situations: any occasion when macros or scripts are running and produce multiple messages without user interaction might want to grow the echo area to display them until there is another required user interaction.

Thanks for considering the possibility of enhancing something in this area, as it was a significant amount of work that was lost, and it could potentially happen again, and not just to me (I'm a little sensitized to the possibility now, others may not yet be).

--------------CBA5FA460B773F792F74F66A--