Davis Herring | 1 Sep 01:07 2004

Re: The `risky-local-variable' blacklist

> The problem with the change you've proposed is that we'd have to go
> through and find check nearly all the variables in Emacs, and mark
> most of them as ok to change.  That is a lot of work.

I believe that few variables are really useful to set locally; that's why
I gave the list from the Emacs lisp/ directory.  There is no need, for
instance, to give a per-file value to `abbrev-all-caps', nor
`blink-cursor', `c-default-style', `c-tab-always-indent',
`christian-holidays', `comint-highlight-input' (to what file would this
even apply?), `comment-auto-fill-only-comments',
`compilation-ask-about-save', `confirm-kill-emacs', `crisp-mode',
`delete-exited-processes', `ediff-make-buffers-readonly-at-startup',
`eol-mnemonic-mac', `executable-chmod', nor many others (I obviously was
looking alphabetically).

In summary, in my Emacs (21.3.1) "emacs -q --no-site-file" yields only 498
non-risky user variables (as tested by `user-variable-p', `boundp', and
`risky-local-variable-p'), 48 of which are "-mode$" variables that
(according to the manual) should almost never be set by a file.  It is not
unreasonable to mark the most useful of these (and of those in the
regular-file major-mode lisp files, of which there are relatively few)  
`safe'; `files.el' already marks nearly 50 `risky'.  If any truly useful
ones were missed, they would be quickly noticed and easily accounted for.

I did say (sincerely) that I was willing to undertake the tedium
associated with this, including (perhaps) an easy way to report (to me,
say) a variable as obviously safe when a prompt is perceived as unneeded.  
While the probability of Emacs exploits this way is fairly small, the
resulting damage (to, among other things, people's opinions of Emacs)
would be notable, and none of us want to see that happen.
(Continue reading)

Kenichi Handa | 1 Sep 01:10 2004

Re: emacs clipboard handling for X broken?

In article <20040831.164842.180119251.wl <at> gnu.org>, Werner LEMBERG <wl <at> gnu.org> writes:
> [Emacs CVS 2004-08-22]

> I tried to paste text from Mozilla 1.6 (build 2004011400) into Emacs,
> and I get e.g. for Chinese instead of `不想睡' the following:

>   \x{4E0D}\x{60F3}\x{7761}

I can't reproduce it, but anyway, as Emacs itself never
generate such a string, it was what Mozilla sent to Emacs.

By default, Emacs issues two requests of types COMPOUND_TEXT
and UTF8_STRING and chooses the longer one.

Please try to set x-select-request-type to a symbol

Ken'ichi HANDA
handa <at> m17n.org
Davis Herring | 1 Sep 01:18 2004

Re: The `risky-local-variable' blacklist

> You do not understand.  I was speaking very specifically about the
> timeclock-mode-string.  My comments only apply to variables used as
> mode-line-string.

Ah -- the actual mode-line, not the "line in a file that sets the mode".  

> I don't think you understand the reason why timeclock-mode-string was not
> dangerous before: timeclock-mode-string can have a value of the form
> (:eval <foo>) which means "evaluate <foo> to get the string to display".
> So there's clearly something dangerous here.  Such evalution-in-mode-string
> is new in Emacs-21, so most foo-mode-line-string variable have suddenly been
> made dangerous.  Instead of going through all those vars and marking them
> risky, Emacs-21 decided that "if the var is not marked `risky', then ignore
> any of those new :eval special forms".  I.e. it's safe either way. but in
> order to be able to use the new feature, you need to mark the var as
> "risky".

The documentation I have for `mode-line-format' has a slight bug, then. It
says that "For a symbol, its value is used (but it is ignored if t or
nil).";  it does not say that the symbol's value is processed recursively
(as it does for the other things that are re-interpreted).  The Elisp 
manual does describe the double-evaluation; should the docstring be 

> I didn't discuss your general point about risky variables (because I mostly
> agree with it).

Well, I'm glad something I said made sense.  Sorry that the rest was 
(Continue reading)

John Wiegley | 1 Sep 01:19 2004

Re: small Eshell docfix

Richard Stallman <rms <at> gnu.org> writes:

> It seems \ is a better default, makes the GNU system more coherent
> overall.  I think people will get used to the change.

I have always thought one of Emacs' best selling points was that it
provides a consistent environment across nearly all operating systems.
That, at least, was a huge draw for me: I can start up Emacs on
Windows, without modification, and lose none of its functionality.

The change you are proposing takes the emphasis away from Emacs, and
puts it on GNU/Linux.  Since we are talking about Emacs, why all the
hoopla about GNU/Linux?

I chose the defaults I did so that Eshell would behave similarly on
all platforms.  I ask that you please not change such an excellent
design philosophy now.

Suraj Acharya | 1 Sep 04:06 2004

Re: correct indentation for flet and labels macros

Andreas Schwab wrote:

> Suraj Acharya <sacharya <at> bea.com> writes:
>>The latter is the behavior is would get from let, but since the arguments
>>are special for flet and labels it would be nice the former. How does
>>defun get its special indentation for example ?
> Just by virtue of being named starting with "def".  See
> lisp-indent-function, which calls lisp-indent-defform in this case.  But
> the function responsible for indenting flet is lisp-indent-specform,
> because flet has a lisp-indent-function property with an integer value.
> Andreas.

So here's my hack to get the indentation I want. It turned out to be a little more
involved than setting a special indentation function for flet because the way the default
lisp-indent-function is set up, flet does not have any control over the indentation of its
descendants beyond its immediate children. So I had to add a property called
lisp-indent-children-function which is in the same spirit as lisp-indent-function, ie you can
set it to 'defun, or a number or a function, but it's only invoked if the lisp-indent-function
for the function name being indented is nil.

So for

(flet ((really-long-function-name (args)
          (length args))
(Continue reading)

Miles Bader | 1 Sep 04:38 2004

Re: emacs clipboard handling for X broken?

Werner LEMBERG <wl <at> gnu.org> writes:
> I tried to paste text from Mozilla 1.6 (build 2004011400) into Emacs,
> and I get e.g. for Chinese instead of `不想睡' the following:
>   \x{4E0D}\x{60F3}\x{7761}
> Is this a known problem?  I'm lost and ask for help.

FWIW, I can cut and paste japanese just fine in both directions between
Emacs (started with `-q', so the defaults seem OK) and mozilla-firefox
0.9.3 (I think this roughly corresponds to mozilla 1.7.2).

selection-coding-system's value is `compound-text-with-extensions'.

LANG is set to `ja_JP.UTF-8'.

I've noticed in the past that the setting of LANG is crucial to making
Mozilla do CJK cut-n-paste correctly, and that in general Mozilla is
pretty fucked up in this area -- if LANG is _not_ set `properly', then
it will screw up cut-n-paste.

Here's Mozilla bug report that may be related:



Occam's razor split hairs so well, I bought the whole argument!
Jerry James | 1 Sep 04:42 2004

Re: make-field suggestion

Stefan <monnier <at> iro.umontreal.ca> wrote:
> The only place where I've use fields is for minibuffer-like entry things
> with completion (where I reuse the minibuffer completion code, suitably
> fixed not to assume it's in a minibuffer).  In such cases, it's often
> important that if the user reduces the size of the field to 0 it can still
> grow it back later on by inserting text into it, i.e. I've had to use an
> overlay and it had to be created as:
>    (make-overlay from to nil nil t)
> so I suggest to at least make it possible to pass the front/rear stickiness
> as an argument.

Okay, that makes sense.  It looks like I can rip off much of the
make-overlay docstring in that case.  Hmmmm.... so is it true that
overlays are neither front- nor rear-sticky by default?  But the text
property API creates regions that are front-sticky but not rear-sticky
by default, doesn't it?  I want to make sure I get this right, because
the whole point of make-field is to hide the different Emacs and XEmacs

Here's my latest attempt, which I think is wrong because the created
field has no stickiness at all.  I think.

(defun make-field (from to value &optional buffer front-advance rear-advance)
  "Make a field with value VALUE over the range [FROM, TO) in BUFFER.
If omitted, BUFFER defaults to the current buffer.
FROM and TO may be integers or markers.
The fifth argument, FRONT-ADVANCE, if non-nil, makes the front delimiter
advance when text is inserted there.
(Continue reading)

Stefan | 1 Sep 04:48 2004

Re: make-field suggestion

> make-overlay docstring in that case.  Hmmmm.... so is it true that
> overlays are neither front- nor rear-sticky by default?  But the text

No, AFAIK they're front-sticky ("not front-advance") and
rear-non-sticky ("not rear-advance").

Karl Eichwalder | 1 Sep 06:44 2004

dired-x and image viewer

Tools like xloadimage or ghostview are hard coded in dired-x.el; by
default, both these tools are not available on some systems.

For image formats like tif, jpeg, etc. I vote to switch to display (part
of ImageMagick and already used for png) and for PostScript gv might be
more appropriate than ghostview.

At least, consider to add them as an alternative.


                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)
Richard Stallman | 1 Sep 06:57 2004

Re: make-field suggestion

    I would like to suggest the make-field interface for Emacs.  The Emacs
    version would look something like this, if defaulting to text properties
    is okay:

    (defun make-field (from to value &optional buffer)
      "Make a field with value VALUE over the range [FROM, TO) in BUFFER.
    BUFFER defaults to the current buffer."
      (with-current-buffer (or buffer (current-buffer))
	(put-text-property from to 'field value)))

We can certainly install something like this, once it is clear what is
best.  It depends, I suppose, on how someone would plan to use it.