Kevin Ryde | 1 Sep 02:02 2005
Picon
Picon

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
Karl Chen | 1 Sep 04:46 2005
Picon

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
Juri Linkov | 1 Sep 07:47 2005

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/
(Continue reading)

martin rudalics | 1 Sep 08:22 2005
Picon
Picon

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)))
(Continue reading)

martin rudalics | 1 Sep 08:24 2005
Picon
Picon

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.
 >
 >
(Continue reading)

Thien-Thi Nguyen | 1 Sep 09:11 2005
Picon

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):
(Continue reading)

Stefan Monnier | 1 Sep 15:08 2005
Picon

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
(Continue reading)

Stefan Monnier | 1 Sep 15:49 2005
Picon

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
(Continue reading)

Stefan Monnier | 1 Sep 16:11 2005
Picon

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
(Continue reading)

Joshua Varner | 1 Sep 16:22 2005
Picon

[PATCH] intro.texi

Since one of the Release goals is proofing the manuals, I'm sending this here,
rather than the bug-lisp-manual. I've attached a patch to intro.texi and the
Changelog, but I'm going to inline the intro.texi part and make some comments,
so that a commiter can decide which parts to apply.

I tried to avoid simply stylistic issues. The only repeated change I made was adding
"notation, " index entries for each of the notation types, so that they will be listed
together in the index in the 'n' section.

Thanks,
Josh

*** intro.texi    10 Aug 2005 14:29:00 -0000    1.30
--- intro.texi    1 Sep 2005 13:32:32 -0000
***************
*** 175,181 ****
  <at> cindex boolean
  <at> cindex false
 
!   In Lisp, the symbol <at> code{nil} has three separate meanings: it
  is a symbol with the name <at> samp{nil}; it is the logical truth value
  <at> var{false}; and it is the empty list---the list of zero elements.
  When used as a variable, <at> code{nil} always has the value <at> code{nil}.
--- 175,181 ----
  <at> cindex boolean
  <at> cindex false
 
!   In Lisp, the symbol <at> dfn{ <at> code{nil}} has three separate meanings: it
  is a symbol with the name <at> samp{nil}; it is the logical truth value
  <at> var{false}; and it is the empty list---the list of zero elements.
  When used as a variable, <at> code{nil} always has the value <at> code{nil}.
==> nil is defined here, but there was no dfn.
***************
*** 197,203 ****
  (not nil)                     ; <at> r{Emphasize the truth value <at> var{false}}
  <at> end example
 
! <at> cindex <at> code{t} and truth
  <at> cindex true
    In contexts where a truth value is expected, any non- <at> code{nil} value
  is considered to be <at> var{true}.  However, <at> code{t} is the preferred way
--- 197,203 ----
  (not nil)                     ; <at> r{Emphasize the truth value <at> var{false}}
  <at> end example
 
! <at> cindex <at> code{t}, uses of
  <at> cindex true
    In contexts where a truth value is expected, any non- <at> code{nil} value
  is considered to be <at> var{true}.  However, <at> code{t} is the preferred way
==> Make this index entry consistent with nil entry
***************
*** 209,222 ****
    In Emacs Lisp, <at> code{nil} and <at> code{t} are special symbols that always
  evaluate to themselves.  This is so that you do not need to quote them
  to use them as constants in a program.  An attempt to change their
! values results in a <at> code{setting-constant} error.  The same is true of
! any symbol whose name starts with a colon ( <at> samp{:}).  <at> xref{Constant
  Variables}.
 
  <at> node Evaluation Notation
  <at> subsection Evaluation Notation
  <at> cindex evaluation notation
  <at> cindex documentation notation
 
    A Lisp expression that you can evaluate is called a <at> dfn{form}.
  Evaluating a form always produces a result, which is a Lisp object.  In
--- 209,223 ----
    In Emacs Lisp, <at> code{nil} and <at> code{t} are special symbols that always
  evaluate to themselves.  This is so that you do not need to quote them
  to use them as constants in a program.  An attempt to change their
! values results in a <at> code{setting-constant} error.  <at> xref{Constant
  Variables}.
 
  <at> node Evaluation Notation
  <at> subsection Evaluation Notation
  <at> cindex evaluation notation
  <at> cindex documentation notation
+ <at> cindex notation, evaluation
+ <at> cindex notation, documentation
 
    A Lisp expression that you can evaluate is called a <at> dfn{form}.
  Evaluating a form always produces a result, which is a Lisp object.  In
==> Remove sentence about variables starting with ':', since that is irrelevant
==> to this node, and it is in the referenced node anyway.
==> Added index entries so that all of the notations will be listed together
==> in the index
***************
*** 252,257 ****
--- 253,259 ----
  <at> node Printing Notation
  <at> subsection Printing Notation
  <at> cindex printing notation
+ <at> cindex notation, printing
 
    Many of the examples in this manual print text when they are
  evaluated.  If you execute example code in a Lisp Interaction buffer
==> Added index entries so that all of the notations will be listed together
==> in the index
***************
*** 262,269 ****
 
    Examples in this manual indicate printed text with <at> samp{ <at> print{}},
  irrespective of where that text goes.  The value returned by
! evaluating the form (here <at> code{bar}) follows on a separate line with
! <at> samp{ <at> result{}}.
 
  <at> example
  <at> group
--- 264,271 ----
 
    Examples in this manual indicate printed text with <at> samp{ <at> print{}},
  irrespective of where that text goes.  The value returned by
! evaluating the form (in the example below: <at> code{bar}) follows on a
! separate line with <at> samp{ <at> result{}}.
 
  <at> example
  <at> group
==> The first time I read this I thought the "form" was (here <at> code{bar}), so I
==> reworded to make it more apparent that 'here' was not a made up function
==> name for the example.
***************
*** 277,282 ****
--- 279,285 ----
  <at> node Error Messages
  <at> subsection Error Messages
  <at> cindex error message notation
+ <at> cindex notation, error message
 
    Some examples signal errors.  This normally displays an error message
  in the echo area.  We show the error message on a line starting with
==> Added index entries so that all of the notations will be listed together
==> in the index
***************
*** 291,296 ****
--- 294,300 ----
  <at> node Buffer Text Notation
  <at> subsection Buffer Text Notation
  <at> cindex buffer text notation
+ <at> cindex notation, buffer text
 
    Some examples describe modifications to the contents of a buffer, by
  showing the ``before'' and ``after'' versions of the text.  These
==> Added index entries so that all of the notations will be listed together
==> in the index
***************
*** 355,365 ****
  arguments default to <at> code{nil}).  Do not write <at> code{&optional} when
  you call the function.
 
!   The keyword <at> code{&rest} (which must be followed by a single argument
! name) indicates that any number of arguments can follow.  The single
! following argument name will have a value, as a variable, which is a
! list of all these remaining arguments.  Do not write <at> code{&rest} when
! you call the function.
 
    Here is a description of an imaginary function <at> code{foo}:
 
--- 359,369 ----
  arguments default to <at> code{nil}).  Do not write <at> code{&optional} when
  you call the function.
 
!   The keyword <at> code{&rest} (which must be followed by a single
! argument name) indicates that any number of arguments can follow.  The
! argument name following <at> code{&rest} will have, as its value, a list
! of all the remaining arguments passed to the function.  Do not write
! <at> code{&rest} when you call the function.
 
    Here is a description of an imaginary function <at> code{foo}:

==> I didn't like the wording of this paragraph, so here is what to me
==> is a better wording
***************
*** 450,457 ****
  <at> cindex variable descriptions
  <at> cindex option descriptions
 
!   A <at> dfn{variable} is a name that can hold a value.  Although any
! variable can be set by the user, certain variables that exist
  specifically so that users can change them are called <at> dfn{user
  options}.  Ordinary variables and user options are described using a
  format like that for functions except that there are no arguments.
--- 454,461 ----
  <at> cindex variable descriptions
  <at> cindex option descriptions
 
!   A <at> dfn{variable} is a name that can hold a value.  Although most
! variables can be set by the user, certain variables that exist
  specifically so that users can change them are called <at> dfn{user
  options}.  Ordinary variables and user options are described using a
  format like that for functions except that there are no arguments.
==> there are read only variables
***************
*** 518,529 ****
 
  <at> defvar emacs-major-version
  The major version number of Emacs, as an integer.  For Emacs version
! 20.3, the value is 20.
  <at> end defvar
 
  <at> defvar emacs-minor-version
  The minor version number of Emacs, as an integer.  For Emacs version
! 20.3, the value is 3.
  <at> end defvar
 
  <at> node Acknowledgements
--- 522,533 ----
 
  <at> defvar emacs-major-version
  The major version number of Emacs, as an integer.  For Emacs version
! 20.3, the value is <at> code{20}.
  <at> end defvar
 
  <at> defvar emacs-minor-version
  The minor version number of Emacs, as an integer.  For Emacs version
! 20.3, the value is <at> code{3}.
  <at> end defvar
 
  <at> node Acknowledgements
==> since these are return values, I thought they should have <at> code{}'s

Attachment (intro.texi): application/x-texinfo, 7996 bytes
_______________________________________________
Emacs-devel mailing list
Emacs-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Gmane