headers
Dan Nicolaescu | 1 Aug 2007 06:10
Picon

Re: Setting term-default-fg-color/term-default-bg-color has no effect

Peter Povinec <pp_publiclists <at> yahoo.com> writes:

  > > Can you please describe exactly what are you doing and how? How did
  > > you test your patch? 
  > 
  > The basic idea is the same as it was in Emacs 21.  Take the user preferences
  > in terms of fg/bg colors as stored in term-default-fg-color and
  > term-default-bg-color and apply them consistently every time term-current-face
  > is set.  This is done for the initial value of term-current-face, when the
  > terminal is reset in term-reset-terminal, and when the escape sequences
  > setting the default fg/bg colors are interpreted in term-handle-color-array. 
  > Note that this was partially done already in term-handle-color-array, e.g. in
  > the case of  setting reverse+invisible. 
  > 
  > For the testing, I've tested with my color customizations, including colored
  > terminal prompt in csh.  I verified the reverse video logic by running 'top'
  > and 'emacs -nw' inside an ansi-term, both with my customizations, and plain
  > emacs.  Customizations to term-default-fg-color or term-default-bg-color while
  > one or more term sessions are running take effect as expected, e.g. by running
  > 'reset'.  

I tested your changes by setting term-default-fg-color to blue and
term-default-bg-color to red on an emacs run with -Q and comparing
with running various curses applications in M-x term and "xterm -fg
blue -bg red". The results are not the same.  

The problem is that the screen is updated in a lot of places in
term.el not only term-handle-colors-array. So this could not have
worked correctly in emacs 21 either.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Richard Stallman | 1 Aug 2007 07:38
Picon
Picon

Re: kill-compilation failing when there are several compilation buffers

    Reading the help C-h C-k got me on C-c C-k, I see it's (kill-compilation)
    which takes no parameter to indicate which compilation to kill, if there
    happen to be several.  I had been under the impression that C-c C-k killed
    the current buffer's compilation previously, but the documentation doesn't
    say anything relating to that.

C-c C-k ought to kill the current buffer's compilation if you are in a
compilation buffer.  If that doesn't reliably work, but is a bug.

Does this patch fix it?

Index: compile.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.421.2.5
diff -c -c -r1.421.2.5 compile.el
*** compile.el	25 Jul 2007 04:29:36 -0000	1.421.2.5
--- compile.el	1 Aug 2007 05:32:34 -0000
***************
*** 1604,1615 ****
      (setq compilation-current-error (point))
      (next-error-internal)))

- ;; Return a compilation buffer.
- ;; If the current buffer is a compilation buffer, return it.
- ;; Otherwise, look for a compilation buffer and signal an error
- ;; if there are none.
  (defun compilation-find-buffer (&optional avoid-current)
!   (next-error-find-buffer avoid-current 'compilation-buffer-internal-p))
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ulrich Windl | 1 Aug 2007 08:21
Picon

Re: rmail can't delete message 10000 and later

Richard,

actually the work-around was to quit rmail after having marked 9999 messages for 
deletion, and then restart it to mark the rest of the messages. To answer your 
question, I'll have to wait until there are another 10000 messages.

Regards,
Ulrich

On 31 Jul 2007 at 16:22, Richard Stallman wrote:

> Does this patch fix it?
> 
> *** rmailsum.el	25 Jul 2007 11:49:20 -0400	1.144.2.2
> --- rmailsum.el	31 Jul 2007 14:23:05 -0400	
> ***************
> *** 288,296 ****
>   		    (if (zerop (% rmail-new-summary-line-count 10))
>   			(message "Computing summary lines...%d"
>   				 rmail-new-summary-line-count))
> ! 		    (rmail-make-summary-line-1 msg)))))
>       ;; Fix up the part of the summary that says "deleted" or "unseen".
> !     (aset line 5
>   	  (if (rmail-message-deleted-p msg) ?\D
>   	    (if (= ?0 (char-after (+ 3 (rmail-msgbeg msg))))
>   		?\- ?\ )))
> --- 288,298 ----
>   		    (if (zerop (% rmail-new-summary-line-count 10))
>   			(message "Computing summary lines...%d"
>   				 rmail-new-summary-line-count))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward Welbourne | 1 Aug 2007 09:44
Picon
Favicon

Re: kill-compilation failing when there are several compilation buffers

> C-c C-k ought to kill the current buffer's compilation if you are in a
> compilation buffer.  If that doesn't reliably work, but is a bug.

OK, I'll watch out for if it repeats itself.

> Does this patch fix it?

Given how sporadic the bug is (I've seen it once in at least a
fortnight), I'll leave my system unchanged until I reproduce, then
over-ride compilation-find-buffer (by C-x C-e on the modified defun)
and see if it fixes the problem.  If I simply apply the patch, and
never see the bug again, I won't know whether some peculiarity that
provoked it the first time has never repeated, or whether it's fixed.

Unfortunately, the session in which the bug showed up is now lost -
I've had a sporadic problem with my X server zorching my session when
I go to a virtual console (C-M-F1, etc.) and come back (C-M-F7); it
bit again last night :-(

	Eddy.
Permalink | Reply | 0 comments |
headers
Juri Linkov | 1 Aug 2007 21:43
Favicon
Gravatar

Re: kill-compilation failing when there are several compilation buffers

>> !   (if (and (compilation-buffer-internal-p (current-buffer))
>> ! 	   (not avoid-current))
>> !       (current-buffer)
>> !     (next-error-find-buffer avoid-current 'compilation-buffer-internal-p)))
>   
> Curiously, next-error-find-buffer only checks current-buffer as its
> 3rd choice.  This function either needs to be changed to try the current
> buffer as its first choice, or it needs a clear comment explaining why.
>
> It looks like this was changed by:
>
>    revision 1.655
>    date: 2004-09-01 13:05:59 -0400;  author: jurta;  state: Exp;  lines: +45 -45;
>    * simple.el (next-error-find-buffer): Move the rule
>    "if current buffer is a next-error capable buffer" after the
>    rule "if next-error-last-buffer is set to a live buffer".
>    Simplify to test all rules in one `or'.
>    (next-error): Doc fix.
>
> where it is not explained.  Juri, do you remember what was the motivation
> for this change?

This change was based on the conclusion of the very long discussion started
from http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00476.html

Any change in current rules may break test cases mentioned on that thread.

--

-- 
Juri Linkov
http://www.jurta.org/emacs/
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter Povinec | 2 Aug 2007 02:50
Picon
Favicon

Re: Setting term-default-fg-color/term-default-bg-color has no effect

> I tested your changes by setting term-default-fg-color to blue and
> term-default-bg-color to red on an emacs run with -Q and comparing
> with running various curses applications in M-x term and "xterm -fg
> blue -bg red". The results are not the same.  
Please be specific: what applications and how were the results different?  I'd
just like to know.

> 
> The problem is that the screen is updated in a lot of places in
> term.el not only term-handle-colors-array. So this could not have
> worked correctly in emacs 21 either.
That is quite possible.  The patch I submitted was intended to merely remove
the regression in functionality introduced in Emacs 22.  I believe it does
that and is useful on its own, whether additional color handling fixes are
applied or not. 

> 
> Given that AFAIK nothing else in emacs changes the default foreground
> and background for a buffer, it's kind of hard to find a convincing
> argument that such a feature is needed for term.el. It can probably be
> done with some effort, but is it worth the added complexity? Not
> sure... 
The additional complexity introduced by the patch is negligible.  We can look
at what it would take to fix the other color related issues you have seen, but
if those existed in version 21, I'd say they are separate issues and should be
treated as such.

--Peter
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dan Nicolaescu | 2 Aug 2007 04:28
Picon

Re: Setting term-default-fg-color/term-default-bg-color has no effect

Peter Povinec <pp_publiclists <at> yahoo.com> writes:

  > > I tested your changes by setting term-default-fg-color to blue and
  > > term-default-bg-color to red on an emacs run with -Q and comparing
  > > with running various curses applications in M-x term and "xterm -fg
  > > blue -bg red". The results are not the same.  
  > Please be specific: what applications and how were the results different?  I'd
  > just like to know.

I tried "emacs -nw", all empty lines did not use term-default-bg-color.

  > > The problem is that the screen is updated in a lot of places in
  > > term.el not only term-handle-colors-array. So this could not have
  > > worked correctly in emacs 21 either.
  > That is quite possible.  The patch I submitted was intended to merely remove
  > the regression in functionality introduced in Emacs 22.  I believe it does
  > that and is useful on its own, whether additional color handling fixes are
  > applied or not. 

It's hard to call a regression replacing one type of broken
behavior with another type of just slightly different broken
behavior.

  > > Given that AFAIK nothing else in emacs changes the default foreground
  > > and background for a buffer, it's kind of hard to find a convincing
  > > argument that such a feature is needed for term.el. It can probably be
  > > done with some effort, but is it worth the added complexity? Not
  > > sure... 
  > The additional complexity introduced by the patch is negligible.  We can look
  > at what it would take to fix the other color related issues you have seen, but
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eli Barzilay | 2 Aug 2007 06:58
Favicon
Gravatar

Problem in temp-buffer-resize-mode

Try this (using version 22.1.1 on Fedora):

  (set-fringe-mode 1)
  (temp-buffer-resize-mode 1)

and you'll see that temp buffers are not resized.  The problem is that
the small fringe makes (window-width) bigger than (frame-width), which
makes the test in `resize-temp-buffer-window' fail.

--

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!
Permalink | Reply | 3 comments |
headers
Yuri Shtil | 1 Aug 2007 20:11
Picon
Favicon

gud.el parses args incorrectly

It is impossible to pass quoted arguments to the gud.
For example if I say on the command line:

perl -d foo.pl one "two and three",
the ARGV in perl has two elements:
index 0 -  one
index 1 - two and three

However if I invoke perldb with the same command, I get:

index 0 - one
index 1 - "two
index 2 - and
index 3 three"

The problem, I believe is that gud-common-init in gud.el uses 
split-string which uses white spaces as delimiters and does not splits 
the command line in shell-like way as I would expect.
Permalink | Reply | 1 comment |
headers
Nick Roberts | 2 Aug 2007 08:27
Picon

Re: gud.el parses args incorrectly

 > It is impossible to pass quoted arguments to the gud.
 > For example if I say on the command line:
 > 
 > perl -d foo.pl one "two and three",
 > the ARGV in perl has two elements:
 > index 0 -  one
 > index 1 - two and three
 > 
 > However if I invoke perldb with the same command, I get:
 > 
 > index 0 - one
 > index 1 - "two
 > index 2 - and
 > index 3 three"
 > 
 > The problem, I believe is that gud-common-init in gud.el uses 
 > split-string which uses white spaces as delimiters and does not splits 
 > the command line in shell-like way as I would expect.

In the CVS repository (trunk and the Emacs 22 release branch EMACS_22_BASE)
gud-common-init no longer uses split-string and this should work.

If you can't check check out a CVS version of Emacs, then you'll need to
wait for Emacs 22.2 which was due to be released about now, although it
will probably be much later.

Alternatively you can patch Emacs 22.1 with:

http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-06/msg00261.html
(Continue reading)

Permalink | Reply | 0 comments |

Gmane