headers
Dan Nicolaescu | 1 Dec 2009 01:07
Picon

bug#5078: 23.1.50; vc broken

Leo <sdl.web <at> gmail.com> writes:

  > On 2009-11-30 19:59 +0000, Dan Nicolaescu wrote:
  > [...]
  > >   > I think I am seeing an odd bug.
  > >   > 
  > >   > There's a file in one of my projects that Emacs (with -Q) VC can't see
  > >   > its changes. However, I can use magit to see its changes without any
  > >   > problem. I tried to reproduce this problem with a newly created git repo
  > >   > but with no luck.
  > >   > 
  > >   > Could you let me know how I can debug this further? Thanks.
  > >
  > >
  > > With the file that you have problems with in the current buffer, try to debug:
  > >
  > > M-: (vc-git-state (buffer-file-name)) RET
  > 
  > That returns: up-to-date

Please try to debug that function and figure out why it returns 'up-to-date. 

  > while the difference is:
  > 
  >  <at>  <at>  -27,7 +27,7  <at>  <at> 
  > -\DeclareSymbolFont{numbers}{OT1}{cmr}{m}{n}
  > +     dkdk\DeclareSymbolFont{numbers}{OT1}{cmr}{m}{n}
  > 
  > Leo
(Continue reading)

Permalink | Reply | 2 comments |
headers
Juanma Barranquero | 1 Dec 2009 01:32
Picon
Gravatar

bug#5042: 23.1; linum-mode gives incorrect line numbers with narrowed buffers

X-Debbugs-CC: markus.triska <at> gmx.at
quit

On Thu, Nov 26, 2009 at 01:39, Mark Lillibridge <mark.lillibridge <at> hp.com> wrote:

>    Linum-mode does not work correctly with buffers that have been
> narrowed.  As a simple example, type ^h i.  You will note that the first
> line is assigned line number one.  You can verify that this is wrong
> either by using goto-line

Let's hear Markus' opinion, but IMHO that's not necessarily a bug.
Linum's function is to add line numbers, but these do not have to
correspond to buffer lines. For example, nothing stops you from doing

  (defvar my-num 1000)
  (make-variable-buffer-local 'my-num)

  (setq linum-format (lambda (n) (format "%4d" (+ n my-num))))

    Juanma
Permalink | Reply | 21 comments |
headers
Kenichi Handa | 1 Dec 2009 02:33

bug#5081: zwj should not be ignored in indic text

> ZWJ is required to display some characters (like Malayalam chillu or
> pure consonants) in many indic languages (Persian and Arabic also
> needs these characters). These should not be ignored while displaying
> indic text.

Please try to evaluate this:

(let ((script-regexp-alist
       `((devanagari . "[\x900-\x97F\x200C\x200D]+")
	 (bengali . "[\x980-\x9FF\x200C\x200D]+")
	 (gurmukhi . "[\xA00-\xA7F\x200C\x200D]+")
	 (gujarati . "[\xA80-\xAFF\x200C\x200D]+")
	 (oriya . "[\xB00-\xB7F\x200C\x200D]+")
	 (tamil . "[\xB80-\xBFF\x200C\x200D]+")
	 (telugu . "[\xC00-\xC7F\x200C\x200D]+")
	 (kannada . "[\xC80-\xCFF\x200C\x200D]+")
	 (malayalam . "[\xD00-\xD7F\x200C\x200D]+"))))
  (map-char-table
   #'(lambda (key val)
       (let ((slot (assq val script-regexp-alist)))
	 (if slot
	     (set-char-table-range
	      composition-function-table key
	      (list (vector (cdr slot) 0 'font-shape-gstring))))))
   char-script-table))

If it still doesn't work, please tell me the version numbers
of libotf and libm17n-flt, and also tell me which font is selected
for Malayalam.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Leo | 1 Dec 2009 02:18
Picon
Gravatar

bug#5078: 23.1.50; vc broken

On 2009-12-01 00:07 +0000, Dan Nicolaescu wrote:
> Please try to debug that function and figure out why it returns 'up-to-date. 

I set vc-git-state with edebug and then made some changes to the file.
The following are some return values inside vc-git-state. Does it give a
clue?

1. (vc-git--call nil "add" "--refresh" "--" (file-relative-name file))

returns result: 128 (#o200, #x80, ?\200)

2. (vc-git--run-command-string file "diff-index" "-z" "HEAD" "--")

returns empty string ""

If I clone the repo, the problem goes away.

Best,

Leo
Permalink | Reply | 1 comment |
headers
Kenichi Handa | 1 Dec 2009 02:36

bug#5080: indic text is not displayed correctly in emacs shell

In article <3f2beab60911300543l2436ff3ar8e5b5124db9db218 <at> mail.gmail.com>, Praveen A
<pravi.a <at> gmail.com> writes:

> Indic text is not rendered correctly in emacs shell (M-x shell).
> Attached images show indic text displayed as escaped unicode values.
> output of ls (when file names has indic characters) and cat (when
> content of a file has indic characters) is displayed like that.

It seems that the coding system for your shell buffer is
iso-8859-1.  In which locale did you invoke Emacs?  And
please try to change the coding system for the shell buffer
to utf-8 (C-x C-m p utf-8 RET utf-8 RET) and run ls and cat
again.

---
Kenichi Handa
handa <at> m17n.org
Permalink | Reply | 19 comments |
headers
Kenichi Handa | 1 Dec 2009 02:44

bug#5086: 23.1.50; strange font-lock in message-mode

When I invoke Emacs with -q, type C-x m, and start typing
the body text in the message mode, the face
`message-cited-text' (foreground: red) is used for that
text.  It should be the default face.

---
Kenichi Handa
handa <at> m17n.org

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/local/work/emacs/etc/DEBUG.

In GNU Emacs 23.1.50.9 (i686-pc-linux-gnu, GTK+ Version 2.16.1)
 of 2009-11-30 on etlken
Windowing system distributor `The X.Org Foundation', version 11.0.10600000
configured using `configure  'CFLAGS=-g''

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: ja_JP.UTF-8
  value of $XMODIFIERS:  <at> im=SCIM
(Continue reading)

Permalink | Reply | 3 comments |
headers
YAMAMOTO Mitsuharu | 1 Dec 2009 02:42
Picon

bug#5085: 23.1.50; assertion failure in Fx_family_fonts

Steps to reproduce:

  1. Compile Emacs with "make CFLAGS='-g -DENABLE_CHECKING'"
  2. emacs -Q
  3. (x-family-fonts) C-j

Result:

  .../src/xfaces.c:1763: Emacs fatal error: assertion failed: VECTORLIKEP((vec))

The value of `vec' is from font_list_entities, whose return value is
of cons.

1758	    {
1759	      CHECK_STRING (family);
1760	      font_parse_family_registry (family, Qnil, font_spec);
1761	    }
1762	  vec = font_list_entities (frame, font_spec);
1763	  nfonts = ASIZE (vec);
1764	  if (nfonts == 0)
1765	    return Qnil;
1766	  if (nfonts > 1)
1767	    {

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

In GNU Emacs 23.1.50.1 (i386-apple-darwin9.8.0, X toolkit, Xaw3d scroll bars)
 of 2009-12-01 on yamamoto-mitsuharu-no-mac-mini.local
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Nicolaescu | 1 Dec 2009 03:00
Picon

bug#5078: 23.1.50; vc broken

Leo <sdl.web <at> gmail.com> writes:

  > On 2009-12-01 00:07 +0000, Dan Nicolaescu wrote:
  > > Please try to debug that function and figure out why it returns 'up-to-date. 
  > 
  > 
  > I set vc-git-state with edebug and then made some changes to the file.
  > The following are some return values inside vc-git-state. Does it give a
  > clue?
  > 
  > 1. (vc-git--call nil "add" "--refresh" "--" (file-relative-name file))
  > 
  > returns result: 128 (#o200, #x80, ?\200)
  > 
  > 2. (vc-git--run-command-string file "diff-index" "-z" "HEAD" "--")
  > 
  > returns empty string ""

It seems that git thinks there's no change, if you change that line to:

(vc-git--run-command-string file "diff-index" "-p" "-z" "HEAD" "--")

does it return the diff you've shown in a previous message?

  > If I clone the repo, the problem goes away.

Maybe something is corrupted in your tree, maybe comparing the 2 .git
directories could give some clues.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Emacs bug Tracking System | 1 Dec 2009 04:25

bug#5070: marked as done (23.1; rmailmm.el fails to decode pdf attachment properly)

Your message dated Mon, 30 Nov 2009 22:17:35 -0500
with message-id <3hhbsb8jsg.fsf <at> fencepost.gnu.org>
and subject line Re: bug#5070: 23.1; rmailmm.el fails to decode pdf attachment properly
has caused the Emacs bug report #5070,
regarding 23.1; rmailmm.el fails to decode pdf attachment properly
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner <at> emacsbugs.donarmstrong.com
immediately.)

--

-- 
5070: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=5070
Emacs Bug Tracking System
Contact owner <at> emacsbugs.donarmstrong.com with problems
Picon
From: Walter Neumann <walter.neumann <at> gmail.com>
Subject: 23.1; rmailmm.el fails to decode pdf attachment properly
Date: 2009-11-29 05:31:31 GMT
(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Richard Stallman
 | 
1 Dec 2009 05:10






Picon

Picon





bug#4957: 23.1.50; idlwave activated spuriously


    No I don't, because bootstrapping starts a new Emacs instance to
    compile every file in a pure environment. They exit when done, so
    never hang around for 10 seconds of idle time to allow this code to
    run. I thought you said you did a recompile, which is different and
    compiles everything in a single Emacs instance.

I think this occurred during a bootstrap.  But I can't be sure
of that memory after the time that has gone by.







Permalink
| Reply
| 2 comments  
| 



  

  

  

  


  





    



Gmane