headers
Miles Bader | 1 Apr 2004 01:02
Picon
Gravatar

Re: Emphasize the character to be typed next in *Completions*

On Tue, Mar 30, 2004 at 08:32:03PM -0500, Stefan Monnier wrote:
> > I agree, as regards font lock faces.  However, when a face is used
> > only in a specific mode, then this motivation for customizing it would
> > be rare.
> 
> I don't see any reason why similar issues wouldn't come up.  You might want
> to use different faces for "dired on /etc" than "dired on /home/foo".

Yeah, but it's proably an awful lot less likely (not that I have any proof,
but ...).

> Other examples: header-line face, default face, ... I'd love to have
> different settings for those in different buffers (or at least in different
> modes).

Of course this is definitely true.

I posted an idea for per-buffer faces a while ago (a buffer-local variable
containing an alist of face name remappings; face lookup filters requests
through this alist), which Richard seemed to think was all right; I think
I'll take a shot at a simple implementation.

-Miles
--

-- 
80% of success is just showing up.  --Woody Allen
Permalink | Reply | 0 comments |
headers
Miles Bader | 1 Apr 2004 01:08
Picon
Gravatar

Re: diff-apply-hunk broken

On Tue, Mar 30, 2004 at 06:28:22PM -0500, Stefan Monnier wrote:
> >> The manpage definitely mentions -L as does `diff --help'.
> 
> > What version are you referring to?  In GNU diffutils 2.8.1-6 (Debian
> > unstable), diff -L is neither mentioned in the manpage, the info manual,
> > nor diff --help.
>
>    ~-0% diff --version
>    diff (GNU diffutils) 2.8.1

FWIW, fencepost has diff 2.7, which supports -L, and --help mentions it.

[This is a great option, BTW -- I used to do the same thing with an
awk-script that parsed the diff-output, and munged the names, but man what a
pain, -L is soooo much better.]

-Miles
--

-- 
We have met the enemy, and he is us.  -- Pogo
Permalink | Reply | 10 comments |
headers
Nick Roberts | 1 Apr 2004 01:50

gdb-ui at startup

 > > The splitting for *gud* is another independent issue.  I'd rather 
 > > focus on
 > > the issue at hand which is the fact that the file holding the `main'
 > > function is displayed.
 > 
 > I agree that this is the main issue.  Maybe there should be a way to
 > customize this, i.e. old behaviour versus new?

By default, it should now start up in the way you want. Hopefully, I've not
broken anything else in the process.

Nick
Permalink | Reply | 0 comments |
headers
Vinicius Jose Latorre | 1 Apr 2004 02:00
Picon
Favicon

Command-line argument in Info

What is the right command-line argument `-no-init-file' or 
`--no-init-file'?  `-no-site-file' or `--no-site-file'?

All info files use `--no-init-file' and `--no-site-file', but in file 
info/elisp-46 is used `-no-init-file' and `-no-site-file', and in file 
info/ccmode-4 is used `-no-site-file'.

Vinicius
Permalink | Reply | 3 comments |
headers
Miles Bader | 1 Apr 2004 03:53
Picon
Picon

Re: Suggestion: Mapping of M-g should be goto-line

Juanma Barranquero <lektu <at> mi.madritel.es> writes:
> > I intensely dislike this sort of `ah modes can just rebind the key' way of
> > avoiding a level of indirection, because often I use different global
> > bindings that normal
> 
> I'm on your camp here regarding having explicit levels of indirection.
> 
> Still, I don't find your example compelling at all, because the given
> examples are not equivalent. I can imagine a (more or less) all-purpose
> `fill-paragraph', but it's less easy to imagine an all-purpose
> `done-editing-now-do-it'

You may very well be right in this case; I was mostly just trying to say
that in the case where there _is_ a generic function that occasionally
is overridden by modes &c, rebinding of the default key-sequence is not
a good override mechanism.

-Miles
--

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]
Permalink | Reply | 0 comments |
headers
Karl Berry | 1 Apr 2004 04:01

Re: [PATCH] ignoring Info extensions

    question: is trailing whitespace allowed in Info node names

No.  It "should" not occur.

    officially by Texinfo documentation and by `makeinfo'? 

By coincidence, there was a recent bug report pointing that TeX barfed
on node names with trailing whitespace, while makeinfo accepted them.  I
will change makeinfo to make this an error, or at least a warning, and
remove such trailing whitespace so it doesn't get into the output.

I can't find anything in the documentation that says explicitly one way
or the other.  I'll change that.

Thanks,
k
Permalink | Reply | 20 comments |
headers
Luc Teirlinck | 1 Apr 2004 05:30
Picon

Re: Suggestion for autorevert.el

Richard Stallman wrote (concerning the issue of making auto-revert
suitable for tailing):

   It would be consistent with the rest of Emacs to keep point at the
   end if it was previously at the end.  Please do it that way, rather
   than introducing an option.

Did you mean that `revert-buffer' should be changed to keep point at
the end if it was there or just auto-revert?  If consistency is the
issue, it probably would be the former.  Eric raised two issues.  The
first, inconsistency with the documentation is easy to fix, just
change the documentation.  That would leave the question of what to do
with an empty buffer, where point is both at beginning and end.

Sincerely,

Luc.
Permalink | Reply | 7 comments |
headers
Richard Stallman | 1 Apr 2004 06:42
Picon
Picon

Re: Compilation to native

    There is the possibility of further improvement, especially for this
    example, by moving Lisp object referencing and setting out of loops.
    This will surely be tricky, though, if only because the functions
    called by the byte code operations could change these objects.

Maybe optimize the bytecode instead.
Permalink | Reply | 1 comment |
headers
Richard Stallman | 1 Apr 2004 06:42
Picon
Picon

Re: enhancements to compile.el (Emacs 20 code)

It sounds like this is pretty much the same feature
that has now been integrated into Emacs.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Apr 2004 06:42
Picon
Picon

Re: Compilation to native

    There are several declaration forms in the CL package
    (info "(cl)Declarations") which are intended for optimising
    compilers, but currently unused.  They could be used for the
    native code compiler.

CL is an optional extension package which is present in
Emacs for the sake of those who want to load it.
It is not part of Emacs Lisp.  It would be erroneous
for the Emacs Lisp compiler to expect people to use CL constructs.

We can consider proposals to add some sort of optimization declaration
construct to the Emacs Lisp language.  Compatibility with Common Lisp
is not a primary design goal for this, but all else being equal
it is better to be compatible than not.
Permalink | Reply | 0 comments |

Gmane