unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
@ 2010-12-04 21:59 Peter Dyballa
  2010-12-05  4:06 ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Dyballa @ 2010-12-04 21:59 UTC (permalink / raw)
  To: 7556

Hello!

I have an EPS file created by Adobe Illustrator 15 with a "DOS EPS  
Binary File Header" according to 5002.EPSF_Spec and a TIFF preview at  
the end, in mac-roman-mac encoding. Size: 643 KB. When I visit that  
file from a dired buffer in PostScript DocView View mode and scroll  
down near the end of the PostScript section where the TIFF preview  
starts, it happens that GNU Emacs becomes inoperable for seven hours  
while consuming all remaining CPU power. The first line of the TIFF  
section, starting with II*, is approximately 314,899 characters  long  
(GNU Emacs is a bad tool, it counts ASCII NUL ^@ as two columns).  
Rendering this in a window of 55 lines and around 120 columns takes  
these 7 h. And more: GNU Emacs creates a #file.eps# backup file,  
larger in size (50 %) than the original file. Is that the expected  
behaviour?

In GNU Emacs 24.0.50.1 (powerpc-apple-darwin9.8.0, X toolkit, Xaw3d  
scroll bars)
  of 2010-11-13 on localhost
Windowing system distributor `The X.Org Foundation', version  
11.0.10902901
configured using `configure  '--without-sound' '--without-dbus' '-- 
without-pop' '--without-gconf' '--with-x-toolkit=athena' '--x- 
libraries=/usr/X11/lib' '--x-includes=/usr/X11/include' '--with- 
imagemagick' '--enable-locallisppath=/Library/Application Support/ 
Emacs/calendar24:/Library/Application Support/Emacs' 'CFLAGS=-g -H - 
pipe -fPIC -fno-common -mcpu=7450 -mtune=7450 -faltivec -fast'  
'CPPFLAGS=-I/usr/local/include -idirafter /sw/include' 'LDFLAGS=-L/usr/ 
local/lib -Wl,-dead_strip_dylibs' 'CC=gcc-4.2' 'CPP=cpp-4.2'  
'PKG_CONFIG_PATH=/sw/lib/pango-ft219/lib/pkgconfig:/sw/lib/xft2/lib/ 
pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/freetype219/lib/ 
pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/sw/lib/ 
pkgconfig:/sw/share/pkgconfig:/usr/lib/pkgconfig:/usr/X11/lib/ 
pkgconfig:/usr/X11/share/pkgconfig''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: de_DE.UTF-8
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: de_DE.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Calendar

Minor modes in effect:
   TeX-PDF-mode: t
   shell-dirtrack-mode: t
   diff-auto-refine-mode: t
   show-paren-mode: t
   display-time-mode: t
   desktop-save-mode: t
   delete-selection-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t



--
Greetings

   Pete

Without vi there is only GNU Emacs






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

* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
  2010-12-04 21:59 bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line Peter Dyballa
@ 2010-12-05  4:06 ` Eli Zaretskii
  2010-12-05 12:04   ` Peter Dyballa
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-05  4:06 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: 7556

> From: Peter Dyballa <Peter_Dyballa@Freenet.DE>
> Date: Sat, 4 Dec 2010 22:59:29 +0100
> Cc: 
> 
> I have an EPS file created by Adobe Illustrator 15 with a "DOS EPS  
> Binary File Header" according to 5002.EPSF_Spec and a TIFF preview at  
> the end, in mac-roman-mac encoding. Size: 643 KB. When I visit that  
> file from a dired buffer in PostScript DocView View mode

Visiting binary files with anything but find-file-literally is not a
good idea.

> Rendering this in a window of 55 lines and around 120 columns takes  
> these 7 h.

Emacs display engine is known to be very slow with very long lines.
Does it help to set truncate-lines non-nil?

> And more: GNU Emacs creates a #file.eps# backup file,  
> larger in size (50 %) than the original file. Is that the expected  
> behaviour?

I'm guessing that this is because raw bytes are decoded into internal
format that makes them take 5 bytes.  The auto-save file is written in
this internal format.





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

* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
  2010-12-05  4:06 ` Eli Zaretskii
@ 2010-12-05 12:04   ` Peter Dyballa
  2010-12-05 14:37     ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Dyballa @ 2010-12-05 12:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7556


Am 05.12.2010 um 05:06 schrieb Eli Zaretskii:

>> I have an EPS file created by Adobe Illustrator 15 with a "DOS EPS
>> Binary File Header" according to 5002.EPSF_Spec and a TIFF preview at
>> the end, in mac-roman-mac encoding. Size: 643 KB. When I visit that
>> file from a dired buffer in PostScript DocView View mode
>
> Visiting binary files with anything but find-file-literally is not a
> good idea.

Yes, find-file-literally works very fine, and fast! Although it  
produces a backup file and does not open the file read-only...

>
>> Rendering this in a window of 55 lines and around 120 columns takes
>> these 7 h.
>
> Emacs display engine is known to be very slow with very long lines.
> Does it help to set truncate-lines non-nil?

I did not wait the whole seven hours, just a few minutes, until the  
CPU became hot enough that the fan started to spin... Not really a  
change or improvement in speed, probably.

>
>> And more: GNU Emacs creates a #file.eps# backup file,
>> larger in size (50 %) than the original file. Is that the expected
>> behaviour?
>
> I'm guessing that this is because raw bytes are decoded into internal
> format that makes them take 5 bytes.  The auto-save file is written in
> this internal format.


The backup file was created while I opened the file read-only, just  
visiting it!

--
Greetings

   Pete

The future will be much better tomorrow.
				– George W. Bush






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

* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
  2010-12-05 12:04   ` Peter Dyballa
@ 2010-12-05 14:37     ` Eli Zaretskii
  2010-12-06  9:44       ` Peter Dyballa
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-05 14:37 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: 7556

> Cc: 7556@debbugs.gnu.org
> From: Peter Dyballa <Peter_Dyballa@Freenet.DE>
> Date: Sun, 5 Dec 2010 13:04:26 +0100
> 
> >> And more: GNU Emacs creates a #file.eps# backup file,
> >> larger in size (50 %) than the original file. Is that the expected
> >> behaviour?
> >
> > I'm guessing that this is because raw bytes are decoded into internal
> > format that makes them take 5 bytes.  The auto-save file is written in
> > this internal format.
> 
> 
> The backup file was created while I opened the file read-only, just  
> visiting it!

That's strange.  I thought auto-save only kicks in if a file was
modified in some way.  Do you see the "modified" indication on the
mode line?  Do you see "Autosaving" in *Messages*?





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

* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
  2010-12-05 14:37     ` Eli Zaretskii
@ 2010-12-06  9:44       ` Peter Dyballa
  2010-12-06 18:53         ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Dyballa @ 2010-12-06  9:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7556


Am 05.12.2010 um 15:37 schrieb Eli Zaretskii:

>> The backup file was created while I opened the file read-only, just
>> visiting it!
>
> That's strange.  I thought auto-save only kicks in if a file was
> modified in some way.  Do you see the "modified" indication on the
> mode line?  Do you see "Autosaving" in *Messages*?


I tried to reproduce the issue this night – but failed! One reason  
might be that I had to use an elder installed version of GNU Emacs  
24.0.50 because the "recent" one was deleted for a new compilation.  
Sorry that I did not think of this before!

--
Greetings

   Pete

If we don't succeed, we run the risk of failure.
				– George W. Bush






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

* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
  2010-12-06  9:44       ` Peter Dyballa
@ 2010-12-06 18:53         ` Eli Zaretskii
  2010-12-06 21:05           ` Peter Dyballa
  2010-12-07  9:43           ` Peter Dyballa
  0 siblings, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-06 18:53 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: 7556

> Cc: 7556@debbugs.gnu.org
> From: Peter Dyballa <Peter_Dyballa@Freenet.DE>
> Date: Mon, 6 Dec 2010 10:44:48 +0100
> 
> 
> Am 05.12.2010 um 15:37 schrieb Eli Zaretskii:
> 
> >> The backup file was created while I opened the file read-only, just
> >> visiting it!
> >
> > That's strange.  I thought auto-save only kicks in if a file was
> > modified in some way.  Do you see the "modified" indication on the
> > mode line?  Do you see "Autosaving" in *Messages*?
> 
> 
> I tried to reproduce the issue this night – but failed! One reason  
> might be that I had to use an elder installed version of GNU Emacs  
> 24.0.50 because the "recent" one was deleted for a new compilation.  
> Sorry that I did not think of this before!

So do we still have a problem to look into, or can this bug be closed?






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

* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
  2010-12-06 18:53         ` Eli Zaretskii
@ 2010-12-06 21:05           ` Peter Dyballa
  2010-12-07  9:43           ` Peter Dyballa
  1 sibling, 0 replies; 9+ messages in thread
From: Peter Dyballa @ 2010-12-06 21:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7556


Am 06.12.2010 um 19:53 schrieb Eli Zaretskii:

> So do we still have a problem to look into, or can this bug be closed?


Let's wait until tomorrow! Today it seems GNU Emacs 24.0.50 can be  
compiled, so I'll have a "test platform". I'll even have two: There is  
also one NS variant, five weeks old. I could launch both in parallel  
and see which one is creating a backup file.

--
Greetings

   Pete

Almost anything is easier to get into than out of.
				– Allen's Law






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

* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
  2010-12-06 18:53         ` Eli Zaretskii
  2010-12-06 21:05           ` Peter Dyballa
@ 2010-12-07  9:43           ` Peter Dyballa
  2010-12-07 18:44             ` Eli Zaretskii
  1 sibling, 1 reply; 9+ messages in thread
From: Peter Dyballa @ 2010-12-07  9:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7556


Am 06.12.2010 um 19:53 schrieb Eli Zaretskii:

> So do we still have a problem to look into, or can this bug be closed?


I think it can be closed!

The elder NS variant is faster than the X client and did not produce a  
backup file. I did not wait until the up-to-date X client finished  
scrolling or creating the backup file but killed it with xkill. *This*  
produced the backup file. The date of this file and that of my action  
is the same, to the minute. Previously I killed GNU Emacs when it  
became inoperable and not knowing the cause of this behaviour. After  
this I visited the directory in dired mode and saw the backup files  
and concluded they might have been created when GNU Emacs started to  
consume all CPU power–now in some irregular working mode–while in fact  
this was perhaps a minute later when I killed it.

In the *Messages* buffers nothing was written.

--
Greetings

   Pete

 From error to error, one discovers the entire truth.
				- Sigmund Freud






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

* bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
  2010-12-07  9:43           ` Peter Dyballa
@ 2010-12-07 18:44             ` Eli Zaretskii
  0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-07 18:44 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: 7556-done

> Cc: 7556@debbugs.gnu.org
> From: Peter Dyballa <Peter_Dyballa@Freenet.DE>
> Date: Tue, 7 Dec 2010 10:43:33 +0100
> 
> The elder NS variant is faster than the X client and did not produce a  
> backup file. I did not wait until the up-to-date X client finished  
> scrolling or creating the backup file but killed it with xkill. *This*  
> produced the backup file. The date of this file and that of my action  
> is the same, to the minute. Previously I killed GNU Emacs when it  
> became inoperable and not knowing the cause of this behaviour. After  
> this I visited the directory in dired mode and saw the backup files  
> and concluded they might have been created when GNU Emacs started to  
> consume all CPU power–now in some irregular working mode–while in fact  
> this was perhaps a minute later when I killed it.

Yes, when Emacs catches a fatal signal, it auto-saves.  This is normal
behavior.

Closing.  Thanks for looking into this.






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

end of thread, other threads:[~2010-12-07 18:44 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-04 21:59 bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line Peter Dyballa
2010-12-05  4:06 ` Eli Zaretskii
2010-12-05 12:04   ` Peter Dyballa
2010-12-05 14:37     ` Eli Zaretskii
2010-12-06  9:44       ` Peter Dyballa
2010-12-06 18:53         ` Eli Zaretskii
2010-12-06 21:05           ` Peter Dyballa
2010-12-07  9:43           ` Peter Dyballa
2010-12-07 18:44             ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).