headers
martin rudalics | 1 Jun 2008 10:26
Picon
Picon

bug#342: kill-line sometimes unexpectedly kills invisible text

 > current line is visible,
 > next line is invisible,
 > I move to end of visible line,
 > then type ctrl-k.
 > I expect it to kill just the visible newline,
 > and sometimes it does that,
 > but sometimes it kills the invisible line too.
 >
 > what's annoying is, it's inconsistent in an unobvious way.
 > the behavior depends on what's in the invisible text.
 >
 > the underlying problem:
 > kill-line in that case uses forward-visible-line
 > to find the end of the kill region.

FWIW, your problem is caused by the

	      (unless (bolp)
		(goto-char opoint))))

checks in `forward-visible-line' which get you back to the position
before the invisible text if that text does not end in a newline as with
the t2 part of your code.  Hence the invisible text won't be killed for
t2.  In the t1 part the invisible region ends in a newline and kill-line
will kill it along with the visible text.

I think the behavior of Emacs is consistent here but maybe not very
intuitive.  On the other hand I'm quite confident that changing that
behavior will break something else :-(
(Continue reading)

Permalink | Reply | 0 comments |
headers
Emacs bug Tracking System | 1 Jun 2008 17:30
Gravatar

Processed: reassigning, stupid mistake by me

Processing commands for control <at> emacsbugs.donarmstrong.com:

> reassign 344 octave
bug#344: plot not cleared after plot() commands following a plotyy()
bug reassigned from package `emacs' to `octave'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)
Permalink | Reply | 0 comments |
headers
Thomas Weber | 1 Jun 2008 14:24
Picon

bug#344: plot not cleared after plot() commands following a plotyy()

thanks
[let's give the tracker a try]

[ Octave 3.0.1, gnuplot 4.2 patchlevel 2 ]

The following code leaves fragments of the plotyy() commands in the
final plot after the plot() command:

===================================================================
x= 1:10;
y = 1./x;
z = 10 *x;
q = 100*x;

plotyy(x,y,x,z)
pause
plotyy(x,y,x,q)
pause
plot(x,y)
===================================================================

	Thomas
Permalink | Reply | 0 comments |
headers
Gabor Toth | 1 Jun 2008 15:57
Picon

bug#345: Bug in F90 mode

Dear GNU emacs developers,

I truly appreciate the work put into the emacs editor. This is the  
editor of choice for editing source code files because of the many  
advanced features that help programmers. I have been using the F90  
module for a long time and I encountered a small but annoying bug. I  
tried to work around it, but I could not.

The bug is present in every version of emacs I know of. It is a bug  
in the F90 module. To reproduced the bug, simply create a file  
with .f90 extension, say

bug.f90

open the file, and type the following lines

program bug

    AnyVariable = 1.0
    TypeVariable = 2.0
        OtherVariable = 3.0

    end program bug

and let Emacs indent it (by hitting TAB at the beginning of each  
line). The result is what you see above, ie the lines following the  
TypeVariable = 2.0 line are indented.

The reason is that if a line starts withTypeXXX the F90 module  
regards it as a type definition, although it is not matched when an
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Bateman | 1 Jun 2008 17:42
Picon

bug#346: plot not cleared after plot() commands following a plotyy()

Thomas Weber wrote:
> thanks
> [let's give the tracker a try]
> 
> [ Octave 3.0.1, gnuplot 4.2 patchlevel 2 ]
> 
> The following code leaves fragments of the plotyy() commands in the
> final plot after the plot() command:
> 
> ===================================================================
> x= 1:10;
> y = 1./x;
> z = 10 *x;
> q = 100*x;
> 
> plotyy(x,y,x,z)
> pause
> plotyy(x,y,x,q)
> pause
> plot(x,y)
> ===================================================================

Not sure how to address this in the bug tracker as it should be marked
as "pending" for 3.1.x and "won't fix" for 3.0.x.. In any case its a
known problem. The thread

http://www.nabble.com/RE%3A--Changeset--plotyy-leaves-traces-of-previous-plots-tt16361090.html

discusses it and I even proposed a patch, that partially addresses the
issue, though potentially causes other problems and so John didn't want
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Mackenzie | 1 Jun 2008 19:21
Picon
Favicon

Re: C mode asks twice about local variables

Hi, Glenn,

On Sat, May 31, 2008 at 06:51:35PM -0400, Glenn Morris wrote:

> This applies in Emacs 22.2 and CVS trunk.

> emacs -Q lib-src/etags.c

>     The local variables list in etags.c
>     contains values that may not be safe (*).

>     Do you want to apply it?  You can type
>     y  -- to apply the local variables list.
>     n  -- to ignore the local variables list.
>     !  -- to apply the local variables list, and permanently mark these
>     values (*) as safe (in the future, they will be set automatically.)

>     indent-tabs-mode: t
>     tab-width: 8
>     fill-column: 79
>   * c-font-lock-extra-types: ("FILE" "bool" "language" "linebuffer" "fdesc" "node" "regexp")
>     c-file-style: "gnu"

> If I answer `y', nothing happens. I have to press `y' a second time.

Yes.  This needs fixing, somehow.

The way this happens is that in a C file's local variables list, there
are two "special" variables, e.g. `c-file-style'.
(Continue reading)

Permalink | Reply | 18 comments |
headers
jidanni | 1 Jun 2008 22:47
Favicon
Gravatar

bug#348: perl mode color vs. /:/

Perl mode needs an "m" here to get the colors right.
Cperl mode has no problem. emacs-version "22.2.1".
$ cat r.pl
m/.*:dndli([^:]+)10:/; my $tmp=$1; #color OK
 /.*:dndli([^:]+)10:/; my $tmp=$1; #color stuck.
//;#to recover color, only to demonstrate that
for(split /:/){print; print "\n";} #color stuck again.
#By the way, add make the "OK" in the comment above become "OK." and
#color gets unstuck!
$ emacs -Q r.pl
Permalink | Reply | 1 comment |
headers
Kevin Ryde | 2 Jun 2008 01:31
Picon
Picon

bug#135: closed by Glenn Morris <rgm <at> gnu.org> (Re: eval-defun binds print-level during eval )

don <at> donarmstrong.com (Emacs bug Tracking System) writes:
>
> This has been fixed.

Has it?  It's still coming out as 4 for me (C-M-x recipe in the bug).

(But I'm a little unsure how clean my build is at the moment.)
Permalink | Reply | 2 comments |
headers
Kevin Ryde | 2 Jun 2008 03:46
Picon
Picon

bug#349: show-paren-mode overlay extending onto new text

In show-paren-mode, when point is after a closing paren so it and the
opener are highlighted, sometimes newly inserted text is covered with
the paren colour too, for a little while.

This doesn't happen all the time, but I've noticed in particular in
program output from M-x compile.  So from "emacs -Q",

    M-x show-paren-mode
    M-x compile
    echo -n '(hello)'; sleep 6; yes
    C-x o    # to *compilation* buffer
    M->      # go to end of buffer

    => the (hello) parens are highlighted

    => but then the output of "yes" is highlighted too

The "sleep 6" gives you a chance to switch to the compilation buffer,
the "echo -n" is so there's no trailing newline in the buffer yet.

An "echo" like this is of course a contrivance, but I've struck the
effect in real program output when switching to the buffer at a random
point or when a close paren is a genuine last bit of its output so far.

I guess for most insertions the timer or whatever gets a chance to reset
or hide the overlay, but for heavy running compile output maybe that
doesn't happen.  I wondered if the make-overlay in show-paren-function
might have the "rear-advance" arg nil, unless there's ever a time it
ought to extend.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Glenn Morris | 2 Jun 2008 04:03
Picon

bug#135: closed by Glenn Morris <rgm <at> gnu.org> (Re: eval-defun binds print-level during eval )


Kevin Ryde wrote (on Mon, 2 Jun 2008 at 09:31 +1000):

> Has it?  It's still coming out as 4 for me (C-M-x recipe in the bug).
> 
> (But I'm a little unsure how clean my build is at the moment.)

My mistake, thanks for pointing it out. I will reopen this bug.
(Some of the discussion seems to be missing from the bug tracker,
probably a teething problem.)
Permalink | Reply | 1 comment |

Gmane