MORE.STUFF calculator.el moved

The url for calculator.el in MORE.STUFF is a 404, it seems to have
moved to,

2005-09-01  Kevin Ryde  <user42 <at> zip.com.au>

        * MORE.STUFF: Update url for calculator.el.

--- MORE.STUFF.~1.51.~	2005-08-28 10:15:20.000000000 +1000
+++ MORE.STUFF	2005-09-01 09:58:35.208784280 +1000
 <at>  <at>  -43,7 +43,7  <at>  <at> 

  * BS: <URL:http://www.geekware.de/software/emacs/index.html>

- * Calculator: <URL:http://www.cs.cornell.edu/eli/misc/calculator.el>
+ * Calculator: <URL:http://www.barzilay.org/misc/calculator.el>

  * CC mode: <URL:http://cc-mode.sourceforge.net/>

_______________________________________________
Emacs-devel mailing list
Emacs-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Info node (emacs)Faces

The info page for Faces says:

`menu'
     This face determines the colors and font of Emacs's menus.
     Setting the font of LessTif/Motif menus is currently not
     supported; attempts to set the font are ignored in this case.

I believe this paragraph also applies to GTK.  In fact, maybe
under all X toolkits (the only other one is Athena).

--

-- 
Karl 2005-08-31 19:43

Re: make `occur' use word at point as default

> We could conceivably make a second M-n insert another possible input
> that one might want.  In effect, this would mean putting another
> element at the "front" of the history list.  That could be a new
> convention that could be generalized to other things.

This is already implemented by a small 9-line patch I proposed in
http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg01755.html
It allows M-n in the minibuffer to insert input from the list of
default values.  Each consecutive M-n inserts a new default value
from the list.

For `grep' and `occur' there are at least five useful default values:

1. word at point - (current-word t)
2. tag at point - (funcall (or find-tag-default-function
                           (get major-mode 'find-tag-default-function)
                           'find-tag-default))
3. active region - (and transient-mark-mode mark-active
                        (buffer-substring-no-properties
                         (region-beginning) (region-end)))
4. last isearch regexp - (car regexp-search-ring)
5. last kill from the kill ring - (current-kill 0)

With this patch, it is possible to make a list of all these default
values accessible in the minibuffer via M-n.

--

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: jit-lock doesn't honor font-lock-lines-before

 >     Because this means that every time I insert one character, redisplay
 >     would refontify `font-lock-lines-before' in addition to the current
 >     line.
 >
 > Would that be bad?

It would slow down editing long lines.  jit-lock is supposed to make
editing faster.

 >
 >       Whether and when these lines are refontified
 >     would be _also_ decided by the redisplay engine.  And the latter doesn't
 >     know about `font-lock-lines-before'.  For example, editing the first
 >     line in a window would not "include the line before in refontification".
 >
 > This is a good point.  However, it can probably be fixed by a change in
 > the fontification function--when it is called, it should extend the starting
 > point for refontification upward by the specified number of lines.
 > (This might be the only fix needed.)
 >
 >

In `font-lock-default-fontify-region', immediately before the comment

           ;; check to see if we should expand the beg/end area for
           ;; proper multiline matches

insert either

           (setq beg (line-beginning-position (1- font-lock-lines-before)))

Re: jit-lock doesn't honor font-lock-lines-before

 >>Suppose not: Wouldn't that mean `font-lock-lines-before' is useless?
 >
 >
 > Not at all.

Then you mean that `font-lock-lines-before' is useless with jit-lock?

 > ... font-lock-lines-before has not been introduced to force
 > refontification of the previous lines but because the N previous lines are
 > needed as context in order to properly refontify the current line.
 > Now the code does in fact refontify the previous lines, but it is
 > a side-effect rather than one of the original goals.
 >
 >

When the "N previous lines" have not been fontified yet because they are
before `window-start' you do have to fontify them anyway.  Otherwise any
- syntactical, for example - context infomation needed to fontify the
current line correctly might be invalid.

 >>It's not very difficult to contrive test cases for this.  By default
 >>`font-lock-multiline' is nil. `font-lock-fontify-anchored-keywords'
 >>won't alter it - the appropriate lines have been commented out.  Write
 >>an arbitrary multiline pattern.  Now font-lock won't give it the
 >>`font-lock-multiline' text property and jit-lock not necessarily reset
 >>its `fontified' text property after a change.  `font-lock-after-change',
 >>on the other hand, may refontify it provided `font-lock-lines-before' is
 >>large enough.
 >
 >

Re: literal newlines in <at> result{} strings

Juri Linkov <juri <at> jurta.org> writes:

> I meant that these functions return only a literal newline, not `\n'.
> It might be confusing for readers of the reference manual when they
> will try out an example and see that its real output is different from
> the documented output in regard to newlines.  They might start to
> search for an (AFAIK, nonexistent) option that toggles a literal newline
> or `\n' in return values, or even to fill a bug report.

to document a literal newline, we can 

  (a) include a literal newline between double quotes
  (b) include a representation of such, between double quotes
  (c) use a literal newline after  <at> print{}, for output

(c) is not applicable for the three functions under discussion, so i
explain my rationale for choosing (b) or (a) in this case (similar
thinking might be useful generally, but i haven't thought about it
generally).

some observations: the strings in question share some characteristics:
are result values, short, end with a newline (and only one).  `\n' as a
representation for literal newline is used not just for documentation
but also in emacs lisp strings (see node "Character Type").  this is a
programmer's manual for which the audience tends to be less easily
confused by seeing such a representation (although programmers can
become confused over anything, with enough concentration, it is often
true .

here are some cases where i think (a) would be more indicated than (b):

Re: make `occur' use word at point as default

> 1. word at point - (current-word t)
> 2. tag at point - (funcall (or find-tag-default-function
>                            (get major-mode 'find-tag-default-function)
>                            'find-tag-default))

These are pretty much the same.  More specifically the tag should include
the current-word as a substring, so I'd drop the number 1 and just keep
number 2.

> 3. active region - (and transient-mark-mode mark-active
>                         (buffer-substring-no-properties
>                          (region-beginning) (region-end)))

You could have done M-w before the current operation.  Much simpler/quicker
than doing M-n M-n M-n searching for it.

> 4. last isearch regexp - (car regexp-search-ring)

This one makes sense.  Maybe we could simply use the same ring for occur as
for regexp-search so that it is available as M-p.

> 5. last kill from the kill ring - (current-kill 0)

C-y brings it more quickl;y and reliably than M-n M-n M-n M-n.

I.e. there are really only 2 different useful values and we could make one
of the two available via M-p.

        Stefan

Re: jit-lock doesn't honor font-lock-lines-before

>>> Suppose not: Wouldn't that mean `font-lock-lines-before' is useless?
>> Not at all.
> Then you mean that `font-lock-lines-before' is useless with jit-lock?

....fumbling about...

Hmm.... now I see what you mean.  I simply assumed that the code for
font-lock-lines-before had been added at the same place as the code for
font-lock-multiline, so it would work just as well for jit-lock as for
lazy-lock or anything else.
As it currently stands, it indeed is broken.  Sorry for being so stubborn.

I suggest the patch below, which also sets the default value to 0: except
for some special modes which rely on font-lock-lines-before (and which
should thus set it explicitly to an appropriate value), setting it to
something more than 0 will just waste CPU.

> I don't know about font-lock-fontification-face-function.
> `font-lock-multiline' is not a hack, at least not a priori.  It simply
> has not been developed yet.  `font-lock-lines-before' is a brute hack.
> However, until `font-lock-multiline' is implemented correctly, it might
> be better than nothing.

I designed and implemented font-lock-multiline.  It's a hack.  It can't be
fixed.  If you want reliable and efficient multiline keywords, you have to
specify them differently (read: change/extend the format of
font-lock-keywords).  Although you are right that you could get it to work
more or less right for the special case of anchored keywords.

        Stefan

Re: jit-lock doesn't honor font-lock-lines-before

> In `font-lock-default-fontify-region', immediately before the comment

>            ;; check to see if we should expand the beg/end area for
>            ;; proper multiline matches

> insert either

>            (setq beg (line-beginning-position (1- font-lock-lines-before)))

Oh, I see we violently agree.  I've committed the change.

> or - but this would have to be mentioned in the doc-string of
> `font-lock-lines-before' -

>            (when font-lock-multiline
>              (setq beg (line-beginning-position (1- font-lock-lines-before))))

I'd rather not force people to use font-lock-multiline at the same time as
font-lock-lines-before since they interact in non-trivial ways.
I'd actually rather recommend to avoid using the two together.

> remove the corresponding line from `font-lock-after-change-function' and
> wait what happens?  I'm still sceptical, though ... fontifications would
> always overlap by `font-lock-lines-before' lines.

The default setting of font-lock-lines-before makes it a nop (as it
should).  Major modes which rely on it should set it to the
appropriate value.

        Stefan

[PATCH] intro.texi

_______________________________________________
Emacs-devel mailing list
Emacs-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel