headers
Dan Jacobson | 1 Feb 2006 01:23
Favicon
Gravatar

shell-command-on-region fooled by long lines

shell-command-on-region on this:
  perl -le 'for(1..6){print $_ x 111}'
mistakenly thinks it is showing all the output in the minibuffer, so
it doesn't create new a new buffer for the output, when in fact it
gets fooled by the wrapped lines. Adjust the 6 and 111 for your screen
if you don't see the effect. I was using Emacs.geometry: 81x35+-6+.
emacs-version"21.4.1"
Permalink | Reply | 6 comments |
headers
Ehud Karni | 1 Feb 2006 16:46
Picon

Re: Weird emacs behavior

 [ resent, there was a mistake in the mailing list name ]

On Mon, 30 Jan 2006 22:38:16 -0800, Leo Chang wrote:
>
> There is an unexplained behavior that we've seen on a few machines we have
> with emacs.  These are Redhat Enterprise Linux boxes that we usually ssh to.
> Xforwarding works fine.  All X apps including emacs work fine.  Then, after
> a long time (weeks or months), emacs stops appearing in its own window when
> you ssh into the box.  Instead, after a long wait, it croaks with something
> like "Connection Lost to Xserver. localhost 10:0."
>
> At this point, you can open ALL X applications except for emacs.  Xeyes,
> xclock, xterm, firefox all work!  But not emacs.  "emacs -nw" does work, and
> emacs in its own Xwindow works if you're directly on the machine.  However,
> emacs will not open without the -nw option thru ssh.  (Even though it did
> while the machine was running for quite some time.)  Restarting the machine
> fixes the problem.

Can you do "netstat -a" (look for listening ports in the 6000-6100 range)
when the problem occurs ?
Also, do "echo $DISPLAY".

Try to run "naked" emacs - emacs -q , what happens ?

Ehud.

--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
(Continue reading)

Permalink | Reply | 5 comments |
headers
Leo Chang | 1 Feb 2006 20:57

RE: Weird emacs behavior

Weirdly enough, this behavior went away when I tried it this morning (after
a couple of days).  Emacs is working again.  I can't explain it at all.

-----Original Message-----
From: Ehud Karni [mailto:ehud <at> unix.mvs.co.il] 
Sent: Wednesday, February 01, 2006 7:46 AM
To: lchang <at> clickshift.com
Cc: help-gnu-emacs <at> gnu.org; bug-gnu-emacs <at> gnu.org
Subject: Re: Weird emacs behavior

 [ resent, there was a mistake in the mailing list name ]

On Mon, 30 Jan 2006 22:38:16 -0800, Leo Chang wrote:
>
> There is an unexplained behavior that we've seen on a few machines we have
> with emacs.  These are Redhat Enterprise Linux boxes that we usually ssh
to.
> Xforwarding works fine.  All X apps including emacs work fine.  Then,
after
> a long time (weeks or months), emacs stops appearing in its own window
when
> you ssh into the box.  Instead, after a long wait, it croaks with
something
> like "Connection Lost to Xserver. localhost 10:0."
>
> At this point, you can open ALL X applications except for emacs.  Xeyes,
> xclock, xterm, firefox all work!  But not emacs.  "emacs -nw" does work,
and
> emacs in its own Xwindow works if you're directly on the machine.
However,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leo Chang | 1 Feb 2006 20:57

RE: Weird emacs behavior

Weirdly enough, this behavior went away when I tried it this morning (after
a couple of days).  Emacs is working again.  I can't explain it at all.

-----Original Message-----
From: Ehud Karni [mailto:ehud <at> unix.mvs.co.il] 
Sent: Wednesday, February 01, 2006 7:46 AM
To: lchang <at> clickshift.com
Cc: help-gnu-emacs <at> gnu.org; bug-gnu-emacs <at> gnu.org
Subject: Re: Weird emacs behavior

 [ resent, there was a mistake in the mailing list name ]

On Mon, 30 Jan 2006 22:38:16 -0800, Leo Chang wrote:
>
> There is an unexplained behavior that we've seen on a few machines we have
> with emacs.  These are Redhat Enterprise Linux boxes that we usually ssh
to.
> Xforwarding works fine.  All X apps including emacs work fine.  Then,
after
> a long time (weeks or months), emacs stops appearing in its own window
when
> you ssh into the box.  Instead, after a long wait, it croaks with
something
> like "Connection Lost to Xserver. localhost 10:0."
>
> At this point, you can open ALL X applications except for emacs.  Xeyes,
> xclock, xterm, firefox all work!  But not emacs.  "emacs -nw" does work,
and
> emacs in its own Xwindow works if you're directly on the machine.
However,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 1 Feb 2006 18:07
Picon
Favicon

Re: shell-command-on-region fooled by long lines

Dan Jacobson wrote:
 > shell-command-on-region on this:
 >   perl -le 'for(1..6){print $_ x 111}'
 > mistakenly thinks it is showing all the output in the minibuffer, so
 > it doesn't create new a new buffer for the output, when in fact it
 > gets fooled by the wrapped lines. Adjust the 6 and 111 for your screen
 > if you don't see the effect. I was using Emacs.geometry: 81x35+-6+.
 > emacs-version"21.4.1"

shell-command always captures the command's output in the *Shell Command
Output* buffer.  Whether the output is displayed in the echo area or in
a pop-up buffer is determined by the resize-mini-windows and
max-mini-window-height variables.  You are right, though, that the
length of the output lines is not considered, only the number of output
lines.

Here's an experimental version of display-message-or-buffer that counts
display lines by comparing each line length to the frame width.  It
tries to do so efficiently for both empty messages and large messages,
like the original:

(defun display-message-or-buffer (message
				  &optional buffer-name not-this-window frame)
   "Display MESSAGE in the echo area if possible, otherwise in a pop-up 
buffer.
MESSAGE may be either a string or a buffer.

A buffer is displayed using `display-buffer' if MESSAGE is too long for
the maximum height of the echo area, as defined by `max-mini-window-height'
if `resize-mini-windows' is non-nil.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sam Owre | 1 Feb 2006 22:54
Favicon

count-screen-lines

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.3.1 (x86_64-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-02-04 on crowe.devel.redhat.com
configured using `configure  --build=x86_64-redhat-linux --host=x86_64-redhat-linux
--target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --with-pop --with-sound'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Torsten Bronger | 2 Feb 2006 15:27
X-Face
Picon
Picon
Picon
Picon
Favicon
Gravatar

strange behaviour of "//" in open file names

When I open a file with C-x C-f I have to enter its name in the minibuffer.  If
its name contains double slashs "//", everything before them is printed in grey
(my global standard colour is orange).  Additionally, a C-a doesn't go to the
first character in the file path but to the most recent double slash (if the
cursor was behind it).

In GNU Emacs 22.0.50.7 (i686-pc-linux-gnu)
 of 2006-02-02 on wilson
X server distributor `The Cygwin/X Project', version 11.0.60802000
configured using `configure '--prefix=/usr/local/' '--infodir=/usr/local/share/info/'
'--mandir=/usr/local/share/man/' '--with-x-toolkit=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  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
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Python

Minor modes in effect:
  global-auto-revert-mode: t
  desktop-save-mode: t
  auto-compression-mode: t
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kevin Rodgers | 2 Feb 2006 17:49
Picon
Favicon

Re: shell-command-on-region fooled by long lines

Kevin Rodgers wrote:
 > Here's an experimental version of display-message-or-buffer that counts
 > display lines by comparing each line length to the frame width.  It
 > tries to do so efficiently for both empty messages and large messages,
 > like the original:

Thanks to the clue posted by Sam Owre in a subsequent thread, this is
all that's needed:

2006-02-02  Kevin Rodgers  <ihs_4664 <at> yahoo.com>

	* simple.el (display-message-or-buffer): Count screen lines
	instead of buffer lines when determining whether the message
	will fit in the echo area/minibuffer window.

*** simple.el~  Thu Feb  2 09:31:34 2006
--- simple.el   Thu Feb  2 09:35:18 2006
***************
*** 1922,1928 ****
            (let ((lines
                   (if (= (buffer-size) 0)
                       0
!                   (count-lines (point-min) (point-max)))))
              (cond ((= lines 0))
                    ((and (or (<= lines 1)
                              (<= lines
--- 1922,1928 ----
            (let ((lines
                   (if (= (buffer-size) 0)
                       0
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kevin Rodgers | 2 Feb 2006 20:54
Picon
Favicon

Re: shell-command-on-region fooled by long lines

Kevin Rodgers wrote:
 > Thanks to the clue posted by Sam Owre in a subsequent thread, this is
 > all that's needed:

Oops.  A final newline is ignored when displaying the message in the
echo area, so the call to count-screen-lines should specify nil for
the COUNT-FINAL-NEWLINE argument:

2006-02-02  Kevin Rodgers  <ihs_4664 <at> yahoo.com>

     * simple.el (display-message-or-buffer): Count screen lines
     instead of buffer lines when determining whether the message
     will fit in the echo area/minibuffer window.

*** simple.el~  Thu Feb  2 09:31:34 2006
--- simple.el   Thu Feb  2 09:35:18 2006
***************
*** 1922,1928 ****
            (let ((lines
                   (if (= (buffer-size) 0)
                       0
!                   (count-lines (point-min) (point-max)))))
              (cond ((= lines 0))
                    ((and (or (<= lines 1)
                              (<= lines
--- 1922,1928 ----
            (let ((lines
                   (if (= (buffer-size) 0)
                       0
!                   (count-screen-lines nil nil nil (minibuffer-window)))))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Rodgers | 2 Feb 2006 21:09
Picon
Favicon

Re: strange behaviour of "//" in open file names

Torsten Bronger wrote:
 > When I open a file with C-x C-f I have to enter its name in the
 > minibuffer.  If its name contains double slashs "//", everything
 > before them is printed in grey (my global standard colour is orange).

That is not a bug.  File names cannot contain consecutive directory
separators.  See the Minibuffer File node of the Emacs manual and the
doc string for file-name-shadow-mode.

(BTW, you're using Emacs 22, so M-x report-emacs-bug would have sent
your report to the correct mailing list.)

 > Additionally, a C-a doesn't go to the first character in the file path
 > but to the most recent double slash (if the cursor was behind it).

That may be a bug...

--

-- 
Kevin Rodgers
Permalink | Reply | 0 comments |

Gmane