headers
Karl Berry | 1 Feb 2010 03:04

bug#5502: compile.el uses non-mode-line faces in the mode line

In Emacs 23.1[.92], compile.el uses non-mode-line faces to propertize
text used in the mode line.  My goal is to have inverse video in the
mode line, and regular text only (no underlines, fake bold, etc.) in the
buffer contents.

To reproduce:
emacs -nw --no-site --no-init -l inv.el  # where invtest.el is appended
M-x compile RET
[backspace to wipe out the "make -k", then] false RET

Observe that the compilation status in the mode line is in "regular"
video, unlike the rest of the mode line.

Thanks,
Karl

Here is invtest.el:

(setq compilation-mode-hook 'k-inverse-video-hook)
(defun k-inverse-video-hook ()
  (set-face-attribute 'compilation-info    nil :inverse-video nil)
  (set-face-attribute 'compilation-warning nil :inverse-video nil)
  (set-face-attribute 'compilation-error   nil :inverse-video nil)
)

P.S. I don't suppose this is news to you, but it is apparently coming
from the following three pieces of compile.el.  If the mode line stuff
used face names like mode-line-compilation-{warning,info,error}, which
could default to the same values they get now, then (I surmise) they
could be controlled independently.  Everything else I've run across so
(Continue reading)

Permalink | Reply | 11 comments |
headers
Eli Zaretskii | 1 Feb 2010 05:15
Picon

bug#5475: Archives with filenames with square brackets

> From: Juri Linkov <juri <at> jurta.org>
> Cc: cyd <at> stupidchicken.com,  5475 <at> debbugs.gnu.org
> Date: Sun, 31 Jan 2010 23:59:40 +0200
> 
> When I try to set `archive-zip-extract' to ("7z" "x" "-so") it puts some
> unnecessary information (header lines, progress indication, etc.)  to
> the output buffer, because it outputs this to stderr.  With the following
> change, stderr goes to /dev/null, but there is no chance to see possible errors
> (this patch is for demonstration only, not to be installed):
> 
> === modified file 'lisp/arc-mode.el'
> --- lisp/arc-mode.el	2010-01-28 20:06:36 +0000
> +++ lisp/arc-mode.el	2010-01-31 21:48:51 +0000
>  <at>  <at>  -1080,7 +1080,7  <at>  <at>  (defun archive-extract-by-stdout (archiv
>    (apply 'call-process
>  	 (car command)
>  	 nil
> -	 t
> +	 '(t nil)
>  	 nil
>  	 (append (cdr command) (list archive name))))
>  
> To process 7z in the correct branch, the following patch is needed,
> where any values other than pkunzip/pkzip are processed by
> archive-extract-by-stdout instead of archive-*-extract,
> where "unzip" needs to quote its filenames.
> 
> So I propose to install the following patch, and add more
> changes for 7z processing after feature freeze.
(Continue reading)

Permalink | Reply | 21 comments |
headers
David Reitter | 1 Feb 2010 05:44
Picon
Gravatar

bug#5503: Font choice in Emacs 23 does not match weight/traits

The fonts chosen for non-latin (here: Asian) characters are not very similar to the face font.

For example, if "Lucida Grande" is selected as the frame's default font, the following:

DOUBLETはあなたと->世 界をつなげる翻訳会社です。

is displayed using a much to lightweight (skinny) font for all the non-Latin glyphs.  The Hiragana portion
at the beginning is set in PMingLiU, while the Kanji (Han script) is displayed in LiSung.

These fonts appear very thin compared to the Latin text.
This is despite there being the "Osaka" font present on my system, which is a medium-weight, very suitable font.

-apple-PMingLiU-medium-normal-normal-*-13-*-*-*-p-0-iso10646-1 (#x303)
-apple-Apple_LiSung-medium-normal-normal-*-13-*-*-*-p-0-iso10646-1 (#x7CD)

This is under NS, whereas I am not positive that this is actually due to NS.

This worked great on Emacs 22 - Osaka is chosen there [well, I have tried with Aquamacs].
I have received concrete complaints from users who say that they're not using Emacs 23 because of that.  
The user also said that matching the font according to further traits (serif/sans) would be desirable/expected.

I advised the user of setting Osaka directly (which works), and of fontsets (which appear inappropriate
for such simple use-cases in 2010).

For what it's worth, I have been trying to fix this myself.
So far I know that Osaka has 95% "han" script coverage and is returned among the list of (many) fonts in the
font driver's "list" function.

It seems that exact weight and more specific traits are not being made available to Emacs by the NS font
driver (e.g., nsfont.m:532, call to ns_descriptor_to_entity, last argument is NULL).  Font weight
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juri Linkov | 1 Feb 2010 11:34
Favicon
Gravatar

bug#5475: Archives with filenames with square brackets

> Thanks.  I'm not sure we need to support 7z, I just tried it to see if
> other unzip programs expand wildcards by default like "unzip" does.

Do you mean we don't need to support 7z in 23.2 or at all?
Are there some problems with 7z that makes undesirable to support it
(maybe, it is not free software, or has an unsuitable license?)

Even though it's quite rarely used format, sometimes when I try to visit
a 7z archive in Emacs, I see only binary data.  At least, nowadays the
need to visit a 7z archive arises more often than for obsolete formats
like arc/lzh/zoo still supported by arc-mode.el.

--

-- 
Juri Linkov
http://www.jurta.org/emacs/
Permalink | Reply | 20 comments |
headers
Lennart Borgman | 1 Feb 2010 12:48
Picon
Gravatar

bug#5475: Archives with filenames with square brackets

On Mon, Feb 1, 2010 at 11:34 AM, Juri Linkov <juri <at> jurta.org> wrote:
>
> Even though it's quite rarely used format, sometimes when I try to visit
> a 7z archive in Emacs, I see only binary data.  At least, nowadays the
> need to visit a 7z archive arises more often than for obsolete formats
> like arc/lzh/zoo still supported by arc-mode.el.

7zip also supports most other compression formats, including password
protection.

When I first started using 7zip it was the only free software that did
this. I am not sure whether there is something else now.
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Feb 2010 16:16
Picon

bug#5495: 23.1.90; symbol completion fails

> I am having trouble with symbol completion. The lisp manual says
> about `try-completion'

>   The value of COLLECTION must be a list of strings or symbols,
>   an alist, an obarray, ...

That's incorrect, a list of symbols is not supported (although it
somewhat works).

> So the following works well

>   (try-completion  "foo" '("bar" baz)) ; fine
>   (try-completion  "foo" '((bar) baz)) ; fine

> Yet the following example fails

>   (try-completion  "foo" '(bar baz))   ; fails

> because it tries to interpret (bar baz) as a call of function bar
> using arg baz.

Not, it interprets the whole (bar baz) as a function (without checking
whether the first symbol is indeed a lambda).

> Shouldn't the last example work, too? Or am I missing something?

It can be made to work, but then it will mysteriously break again when
the first symbol in the list happens to be a lambda.

> I thought I had used symbol completion before. But now I cannot get
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan Monnier | 1 Feb 2010 16:54
Picon

bug#5502: compile.el uses non-mode-line faces in the mode line

> Here is invtest.el:

> (setq compilation-mode-hook 'k-inverse-video-hook)
> (defun k-inverse-video-hook ()
>   (set-face-attribute 'compilation-info    nil :inverse-video nil)
>   (set-face-attribute 'compilation-warning nil :inverse-video nil)
>   (set-face-attribute 'compilation-error   nil :inverse-video nil)
> )

Why do you set inverse-video to nil?  If you set it to `unspecified'
instead, it should work right.

        Stefan
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Feb 2010 16:43
Picon

bug#5475: Archives with filenames with square brackets

> Do you mean we don't need to support 7z in 23.2 or at all?
> Are there some problems with 7z that makes undesirable to support it
> (maybe, it is not free software, or has an unsuitable license?)

AFAIK 7zip is Free Software, but adding 7z support would be a new
feature, so we would probably be better off insalling it into the
`pending' branch.

        Stefan
Permalink | Reply | 5 comments |
headers
Stefan Monnier | 1 Feb 2010 16:40
Picon

bug#5483: 23.1.91; EDE : proj-automake : files in subdirectories have no `ede-current-project'

> Well, my lisp ability is rather limited, but I'll launch a message on the
> mailing list, with the information I've gathered.

> Question is, where should any development go into? CEDET cvs or Emacs' bzr?

It's probably better for it to go into the Emacs bzr, because it's a lot
easier for Eric to merge from our repository than the other way around
(for legal reasons on his side).
Eric, what do you think?

        Stefan
Permalink | Reply | 1 comment |
headers
Roland Winkler | 1 Feb 2010 17:06
Picon
Picon
Favicon

bug#5495: 23.1.90; symbol completion fails

On Mon Feb 1 2010 Stefan Monnier wrote:
> > I am having trouble with symbol completion. The lisp manual says
> > about `try-completion'
> 
> >   The value of COLLECTION must be a list of strings or symbols,
> >   an alist, an obarray, ...
> 
> That's incorrect, a list of symbols is not supported (although it
> somewhat works).

Thanks for the clarification. So my bug report refers really to this
node of the elisp manual. In particular, it says

  Symbols are converted to strings using `symbol-name'.

> It can be made to work, but then it will mysteriously break again when
> the first symbol in the list happens to be a lambda.

One could specify that lambda expressions take precedence, i.e., if
and only if (functionp collection) returns non-nil, collection will
be interpreted as a function. Otherwise a list will be interpreted
as a list of symbols (or a list of strings, etc.).

I would find that useful. But I'll be happy to give this feature
request low importance.

> Use an alist with symbols as keys, or use an obarray. Otherwise
> pass your list of symbols through (mapcar 'symbol-name ...) to
> turn it into a list of strings.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane