unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* recover file after crash
@ 2013-01-24 20:16 drain
  2013-01-24 21:00 ` Drew Adams
  0 siblings, 1 reply; 15+ messages in thread
From: drain @ 2013-01-24 20:16 UTC (permalink / raw)
  To: Help-gnu-emacs

Instead of Emacs telling me that I can recover auto-save data after a
crash, then leaving me to manually enter the command, I'd prefer Emacs to
prompt me with a yes-or-n-p to do so itself.



--
View this message in context: http://emacs.1067599.n5.nabble.com/recover-file-after-crash-tp276397.html
Sent from the Emacs - Help mailing list archive at Nabble.com.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: recover file after crash
  2013-01-24 20:16 recover file after crash drain
@ 2013-01-24 21:00 ` Drew Adams
  2013-01-25 18:23   ` drain
  0 siblings, 1 reply; 15+ messages in thread
From: Drew Adams @ 2013-01-24 21:00 UTC (permalink / raw)
  To: 'drain', Help-gnu-emacs

> Instead of Emacs telling me that I can recover auto-save data after a
> crash, then leaving me to manually enter the command, I'd 
> prefer Emacs to prompt me with a yes-or-n-p to do so itself.

Please use `M-x report-emacs-bug' if you want to submit an enhancement request.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: recover file after crash
  2013-01-24 21:00 ` Drew Adams
@ 2013-01-25 18:23   ` drain
  2013-01-25 18:30     ` Valentin Baciu
  0 siblings, 1 reply; 15+ messages in thread
From: drain @ 2013-01-25 18:23 UTC (permalink / raw)
  To: Help-gnu-emacs

I meant to ask if that were already an option.

Related: how can I get Emacs NOT to prompt me when I want to open large (>10
MB) files?



--
View this message in context: http://emacs.1067599.n5.nabble.com/recover-file-after-crash-tp276397p276478.html
Sent from the Emacs - Help mailing list archive at Nabble.com.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-25 18:23   ` drain
@ 2013-01-25 18:30     ` Valentin Baciu
  2013-01-25 19:12       ` drain
  0 siblings, 1 reply; 15+ messages in thread
From: Valentin Baciu @ 2013-01-25 18:30 UTC (permalink / raw)
  To: drain; +Cc: Emacs help

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

Hi drain,

Maybe this will help, even though I never tried it myself because I like
opening large and hairy files :)

Type the following: C-h v large-<TAB>

Then the description for the variable will show up like this:

large-file-warning-threshold is a variable defined in `files.el'.
Its value is 10000000

Documentation:
Maximum size of file above which a confirmation is requested.
When nil, never request confirmation.

You can customize this variable.

This variable was introduced, or its default value was changed, in
version 22.1 of Emacs.

[back]



On Fri, Jan 25, 2013 at 8:23 PM, drain <aeuster@gmail.com> wrote:

> I meant to ask if that were already an option.
>
> Related: how can I get Emacs NOT to prompt me when I want to open large
> (>10
> MB) files?
>
>
>
> --
> View this message in context:
> http://emacs.1067599.n5.nabble.com/recover-file-after-crash-tp276397p276478.html
> Sent from the Emacs - Help mailing list archive at Nabble.com.
>
>

[-- Attachment #2: Type: text/html, Size: 1735 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-25 18:30     ` Valentin Baciu
@ 2013-01-25 19:12       ` drain
  2013-01-25 19:29         ` Eli Zaretskii
  2013-01-25 19:36         ` Valentin Baciu
  0 siblings, 2 replies; 15+ messages in thread
From: drain @ 2013-01-25 19:12 UTC (permalink / raw)
  To: Help-gnu-emacs

Just customized that variable to nil.

Do you guys experience lag when you open these large files? For me, the
deeper I get into a nested heading, the less lag there is, eventually
lag-free. But when I am at the overview, it starts to get pretty slow
around 10 MB.



--
View this message in context: http://emacs.1067599.n5.nabble.com/recover-file-after-crash-tp276397p276485.html
Sent from the Emacs - Help mailing list archive at Nabble.com.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-25 19:12       ` drain
@ 2013-01-25 19:29         ` Eli Zaretskii
  2013-01-25 20:31           ` drain
  2013-01-25 19:36         ` Valentin Baciu
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2013-01-25 19:29 UTC (permalink / raw)
  To: Help-gnu-emacs

> Date: Fri, 25 Jan 2013 11:12:43 -0800 (PST)
> From: drain <aeuster@gmail.com>
> 
> Do you guys experience lag when you open these large files? For me, the
> deeper I get into a nested heading, the less lag there is, eventually
> lag-free. But when I am at the overview, it starts to get pretty slow
> around 10 MB.

Because what is one line on display may be many lines of text in the
buffer, and redisplay needs to traverse them all.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-25 19:12       ` drain
  2013-01-25 19:29         ` Eli Zaretskii
@ 2013-01-25 19:36         ` Valentin Baciu
  1 sibling, 0 replies; 15+ messages in thread
From: Valentin Baciu @ 2013-01-25 19:36 UTC (permalink / raw)
  To: drain; +Cc: Emacs help

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

Hello again,

In my experience, large files with few line ends (like minified JavaScript
files) tend to lag more. Sometimes I just use vim for these kind of files
or, depending on what I want to do, grep or sed in order to avoid opening
it in Emacs. But that should be a rare case rather than the rule.

I like to think of Emacs as a code editor (mostly) which works great for
development, but not necessarily for debugging.

Byte compiling your major modes may speed up processing, but I don't think
of it as a general performance solution. This "tip" should apply only for
custom installs because the default/built-in ones are already compiled.

In case you can share the file that you have trouble with I will gladly try
it on my system.



On Fri, Jan 25, 2013 at 9:12 PM, drain <aeuster@gmail.com> wrote:

> Just customized that variable to nil.
>
> Do you guys experience lag when you open these large files? For me, the
> deeper I get into a nested heading, the less lag there is, eventually
> lag-free. But when I am at the overview, it starts to get pretty slow
> around 10 MB.
>
>
>
> --
> View this message in context:
> http://emacs.1067599.n5.nabble.com/recover-file-after-crash-tp276397p276485.html
> Sent from the Emacs - Help mailing list archive at Nabble.com.
>
>

[-- Attachment #2: Type: text/html, Size: 1956 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-25 19:29         ` Eli Zaretskii
@ 2013-01-25 20:31           ` drain
  2013-01-25 20:44             ` Eli Zaretskii
  2013-01-25 20:56             ` Ludwig, Mark
  0 siblings, 2 replies; 15+ messages in thread
From: drain @ 2013-01-25 20:31 UTC (permalink / raw)
  To: Help-gnu-emacs

Eli Zaretskii wrote
> Because what is one line on display may be many lines of text in the
> buffer, and redisplay needs to traverse them all.

Makes sense. I'm glad to know there is a clear technical reason for it, and
that it is not symptomatic of a poorly optimized installation.

In any case, I sent Valentin a large file that tends to lag (didn't want to
impose a large attachment on the mailing list).




--
View this message in context: http://emacs.1067599.n5.nabble.com/recover-file-after-crash-tp276397p276496.html
Sent from the Emacs - Help mailing list archive at Nabble.com.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-25 20:31           ` drain
@ 2013-01-25 20:44             ` Eli Zaretskii
  2013-01-25 21:04               ` drain
  2013-01-25 20:56             ` Ludwig, Mark
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2013-01-25 20:44 UTC (permalink / raw)
  To: Help-gnu-emacs

> Date: Fri, 25 Jan 2013 12:31:57 -0800 (PST)
> From: drain <aeuster@gmail.com>
> 
> In any case, I sent Valentin a large file that tends to lag

If it has no or few empty lines, adding empty lines (e.g., before
top-level headings) might dramatically improve performance in very
large buffers.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: recover file after crash
  2013-01-25 20:31           ` drain
  2013-01-25 20:44             ` Eli Zaretskii
@ 2013-01-25 20:56             ` Ludwig, Mark
  2013-01-26 10:39               ` Eli Zaretskii
  1 sibling, 1 reply; 15+ messages in thread
From: Ludwig, Mark @ 2013-01-25 20:56 UTC (permalink / raw)
  To: drain, Help-gnu-emacs@gnu.org

> From:  drain
> Sent: Friday, January 25, 2013 2:32 PM
> To: Help-gnu-emacs@gnu.org
> Subject: Re: recover file after crash
> 
> Eli Zaretskii wrote
> > Because what is one line on display may be many lines of text in the
> > buffer, and redisplay needs to traverse them all.
> 
> Makes sense. I'm glad to know there is a clear technical reason for it, and
> that it is not symptomatic of a poorly optimized installation.
> 
> In any case, I sent Valentin a large file that tends to lag (didn't want to
> impose a large attachment on the mailing list).

I think I thoroughly documented this in Bug # 9589
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9589) for the
developers to consider, which see.  (No attachment is
required to reproduce the behavior.)  It has been merged
with bugs 3219 and 4123, both of which also document how to
show the problem without a specific attachment.

You might also be interested in some of the experimental
results I documented in bug 9589 about which commands
respond consistently (i.e., quickly with long lines) and
which are sensitive to the line length and/or buffer
position.

Good luck,
Mark




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-25 20:44             ` Eli Zaretskii
@ 2013-01-25 21:04               ` drain
  0 siblings, 0 replies; 15+ messages in thread
From: drain @ 2013-01-25 21:04 UTC (permalink / raw)
  To: Help-gnu-emacs

Eli Zaretskii wrote
>> Date: Fri, 25 Jan 2013 12:31:57 -0800 (PST)
>> From: drain &lt;

> aeuster@

> &gt;
>> 
>> In any case, I sent Valentin a large file that tends to lag
> 
> If it has no or few empty lines, adding empty lines (e.g., before
> top-level headings) might dramatically improve performance in very
> large buffers.

I have to add a couple spaces to the very end of the text of the last
nested headline in order for the spaces to separate each of the top level
headlines. Otherwise, when I reopen the file, these spaces are gone.

In any case, after doing so, implementing your suggestion appears to have
improved performance, especially when sifting through top level headlines
that are partially or completely opened, and also especially when running
point rapidly up a sequence of top level headlines.



--
View this message in context: http://emacs.1067599.n5.nabble.com/recover-file-after-crash-tp276397p276502.html
Sent from the Emacs - Help mailing list archive at Nabble.com.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-25 20:56             ` Ludwig, Mark
@ 2013-01-26 10:39               ` Eli Zaretskii
  2013-01-26 21:47                 ` Ludwig, Mark
       [not found]                 ` <mailman.18392.1359236878.855.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 15+ messages in thread
From: Eli Zaretskii @ 2013-01-26 10:39 UTC (permalink / raw)
  To: Help-gnu-emacs

> From: "Ludwig, Mark" <ludwig.mark@siemens.com>
> Date: Fri, 25 Jan 2013 20:56:47 +0000
> 
> I think I thoroughly documented this in Bug # 9589
> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9589) for the
> developers to consider, which see.

Assuming the OP has such long lines, yes.  But that would be unusual
in a file that is being read in any kind of overview mode, because
those normally are for human consumption, so long lines are unlikely
to appear in them.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: recover file after crash
  2013-01-26 10:39               ` Eli Zaretskii
@ 2013-01-26 21:47                 ` Ludwig, Mark
  2013-01-27  6:19                   ` Eli Zaretskii
       [not found]                 ` <mailman.18392.1359236878.855.help-gnu-emacs@gnu.org>
  1 sibling, 1 reply; 15+ messages in thread
From: Ludwig, Mark @ 2013-01-26 21:47 UTC (permalink / raw)
  To: Eli Zaretskii, Help-gnu-emacs@gnu.org

> From: Eli Zaretskii
> Sent: Saturday, January 26, 2013 4:40 AM
> 
> > From: "Ludwig, Mark" <ludwig.mark@siemens.com>
> > Date: Fri, 25 Jan 2013 20:56:47 +0000
> >
> > I think I thoroughly documented this in Bug # 9589
> > (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9589) for the
> > developers to consider, which see.
> 
> Assuming the OP has such long lines, yes.  But that would be unusual
> in a file that is being read in any kind of overview mode, because
> those normally are for human consumption, so long lines are unlikely
> to appear in them.

Agreed, this is not an every-day occurrence.

In my case, it is because log files I receive from customers sometimes
have a huge number of NUL bytes preceding the readable content.  This
leading, extremely-long line gets in the way of reasonable
responsiveness.

I also confess that I have not been keeping up with the current trends
in Emacs development.  Back when I started using EMACS [sic], it was
an excellent binary editor.  Apparently this is not a current
requirement, because it clearly is no longer useful for same.  Side
question: is there a GNU tool designed for editing binary files?

Cheers,
Mark



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
  2013-01-26 21:47                 ` Ludwig, Mark
@ 2013-01-27  6:19                   ` Eli Zaretskii
  0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2013-01-27  6:19 UTC (permalink / raw)
  To: Help-gnu-emacs

> From: "Ludwig, Mark" <ludwig.mark@siemens.com>
> Date: Sat, 26 Jan 2013 21:47:50 +0000
> 
> Side question: is there a GNU tool designed for editing binary
> files?

Hexl mode in Emacs?



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: recover file after crash
       [not found]                 ` <mailman.18392.1359236878.855.help-gnu-emacs@gnu.org>
@ 2013-02-20  1:35                   ` David Combs
  0 siblings, 0 replies; 15+ messages in thread
From: David Combs @ 2013-02-20  1:35 UTC (permalink / raw)
  To: help-gnu-emacs

In article <mailman.18392.1359236878.855.help-gnu-emacs@gnu.org>,
Ludwig, Mark <ludwig.mark@siemens.com> wrote:
>> From: Eli Zaretskii
>> Sent: Saturday, January 26, 2013 4:40 AM
>> 
>> > From: "Ludwig, Mark" <ludwig.mark@siemens.com>
>> > Date: Fri, 25 Jan 2013 20:56:47 +0000
>> >
>> > I think I thoroughly documented this in Bug # 9589
>> > (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9589) for the
>> > developers to consider, which see.
>> 
>> Assuming the OP has such long lines, yes.  But that would be unusual
>> in a file that is being read in any kind of overview mode, because
>> those normally are for human consumption, so long lines are unlikely
>> to appear in them.
>
>Agreed, this is not an every-day occurrence.
>
>In my case, it is because log files I receive from customers sometimes
>have a huge number of NUL bytes preceding the readable content.  This
>leading, extremely-long line gets in the way of reasonable
>responsiveness.
>
>I also confess that I have not been keeping up with the current trends
>in Emacs development.  Back when I started using EMACS [sic], it was
>an excellent binary editor.  Apparently this is not a current
>requirement, because it clearly is no longer useful for same.  Side
>question: is there a GNU tool designed for editing binary files?
>
>Cheers,
>Mark
>

About all those nulls that make lines so long, couldn't you run
the file through sed or some super-short c-program or even perl
first, and delete (ie ignore) all those nulls then?

David



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2013-02-20  1:35 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-24 20:16 recover file after crash drain
2013-01-24 21:00 ` Drew Adams
2013-01-25 18:23   ` drain
2013-01-25 18:30     ` Valentin Baciu
2013-01-25 19:12       ` drain
2013-01-25 19:29         ` Eli Zaretskii
2013-01-25 20:31           ` drain
2013-01-25 20:44             ` Eli Zaretskii
2013-01-25 21:04               ` drain
2013-01-25 20:56             ` Ludwig, Mark
2013-01-26 10:39               ` Eli Zaretskii
2013-01-26 21:47                 ` Ludwig, Mark
2013-01-27  6:19                   ` Eli Zaretskii
     [not found]                 ` <mailman.18392.1359236878.855.help-gnu-emacs@gnu.org>
2013-02-20  1:35                   ` David Combs
2013-01-25 19:36         ` Valentin Baciu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).