headers
Richard M. Stallman | 1 Aug 2005 02:46
Picon
Picon

Re: emacs & MAXPATHLEN

    (you can create virtually infinite long file names on Linux, for example).

You can't create them on Linux by itself.  To execute a system call,
you need GNU libc too.  So I think you mean "on GNU/Linux", not "on
Linux".
Permalink | Reply | 18 comments |
headers
Richard M. Stallman | 1 Aug 2005 02:46
Picon
Picon

Re: sit-for arg old-nodisp not documented

    `sit-for' has an argument old-nodisp that is not described in the doc 
    string.

We often don't document an argument that we don't encourage people to
use.
Permalink | Reply | 0 comments |
headers
Richard M. Stallman | 1 Aug 2005 02:45
Picon
Picon

Re: Copyright notices

    It occurs to me that if there isn't a release until 2006 (or
    later!) then all the files will need to be changed again.  Now
    that the legal advice suggests a straightforward solution perhaps
    this process could (ultimately) be scripted.

It could be so.

    perhaps all files could display the _same_ copyright notice (apart from
    comment delimiters) for the period from the start of Emacs (1985?) to the
    present?

No, because most files were added to Emacs later than 1985, and some of them
have years when they were released by their authors bevore they were added
to Emacs.

A script to add a certain year to all files in a certain directory,
or to the files that are specified for it, would do the job.
Doing this is not quite trivial, but not terribly hard.

Would you like to write it?

    Not only is the year wrong but it seems to suggest that everything before 2004
    is not copyrighted.

No, it doesn't mean that.  Don't worry.
Permalink | Reply | 0 comments |
headers
Richard M. Stallman | 1 Aug 2005 02:46
Picon
Picon

Re: Minibuffer height problem

max-mini-window-height is documented in the Emacs Manual,
in the minibuffer section.

But I think I see a bug here: for y-or-n-p, I think it should
show the last part of the message rather than the first,
so that the "? (y or n)" appears.  In other words, it should
scroll up so the bottom appears on the screen.

Could someone please implement that, and ack this message?
Permalink | Reply | 3 comments |
headers
Richard M. Stallman | 1 Aug 2005 02:45
Picon
Picon

Re: [drew.adams <at> oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

       For cases which are more complex, you'd use custom-initialize-default
       and then write (if foo-mode (foo-mode 1)) at the end of the file.

    If we are willing to change define-minor-mode, then I do not believe
    that there is any need for the more complex method, unless there is
    some reason why the define-minor-mode can not be delayed until all
    functions called by the minor mode have been defined.

Sometimes it is inconvenient to order things that way.  So let's
document this as an optional method.
Permalink | Reply | 0 comments |
headers
Richard M. Stallman | 1 Aug 2005 02:46
Picon
Picon

Re: emacs & MAXPATHLEN

1. I'd rather put this in sysdep.c and avoid the hassle of
two new files.

2. It could be called get_current_dir_name,
and defined only when the system does not define it.
That would simplify things.

3. I'd rather not include this:

+#ifdef MAXPATHLEN
+      buf = (char *) malloc (MAXPATHLEN + 1);
+      if (!buf)
+        return NULL;
+      if (getcwd (buf, MAXPATHLEN + 1) == NULL)
+        return NULL;
+#else
Permalink | Reply | 1 comment |
headers
Richard M. Stallman | 1 Aug 2005 02:45
Picon
Picon

Re: unnecessary fringe-indicators defcustom creates trouble

    `indicate-empty-lines' is already a defcustomed variable (actually set
    in startup.el).  `indicate-buffer-boundaries' is not, but it should be
    and the patches below make it customizable through startup.el.

That sounds like a good idea.  Your change in cus-start.el is a good one
(assuming the details are right--I will take your word for that).

								    Once
    this is done, there is no longer any need for the annoying
    fringe-indicators variable.

The reason for this is to make it simple to request the usual options.
This is the right thing for the menu bar.

But I agree it shouldn't get in the way of setting the other variables
directly, if you want to do that.  So I propose this change.
(I will also change the doc strings of default-indicate-empty-lines
and default-indicate-buffer-boundaries.)

*** fringe.el	10 Jul 2005 13:00:16 -0400	1.20
--- fringe.el	30 Jul 2005 20:30:12 -0400	
***************
*** 269,298 ****
    "Set fringe indicators according to VALUE.
  This is usually invoked when setting `fringe-indicators' via customize."
    (setq fringe-indicators value)
!   (setq default-indicate-empty-lines nil)
!   (setq default-indicate-buffer-boundaries
! 	(cond
! 	 ((memq value '(left right t))
(Continue reading)

Permalink | Reply | 3 comments |
headers
Richard M. Stallman | 1 Aug 2005 02:45
Picon
Picon

Re: [drew.adams <at> oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]

       That seems like the right thing to me.  If the user set the variable,
       he probably wanted to control the mode.

    In the text you quoted, I was talking about defcustoms with a :set
    function that are _not_ minor modes.

I don't think this changes anything, but let's call it "behavior"
rather than "mode".

       So what?  One can't please everybody.

    I thought that we decided that use of Custom was optional, that people
    should be able to customize everything in their .emacs and completely
    ignore Custom, if that is what they wanted to do.

That is just a goal, not an unbreakable rule.  It seems irrelevant
to this issue anyway.  We're not talking about running Custom here.
We're talking about what happens when you load a defcustom and
the variable has already been set.

      If you try to customize things manually
    in your .emacs you subject yourself to Custom overriding you at random
    moments, without notice, when some file is loaded (for instance by Custom).

It's not Custom that's doing this, it is loading the defcustom.
Let's not complicate the issue unnecessarily.

    Prior cases that were known to give problems have been solved already
    in various ways, but people just keep writing new very intrusive :set
    functions.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Lennart Borgman | 1 Aug 2005 03:25
Picon
Picon
Favicon

Re: Minibuffer height problem

Richard M. Stallman wrote:

>max-mini-window-height is documented in the Emacs Manual,
>in the minibuffer section.
>  
>
Yes, in the "user part", but I was reading the Elisp Manual and in 20.1 
Introduction to Minibuffers it says

    " The minibuffer's window is normally a single line; it grows
    automatically if necessary if the contents require more space. "

Which I think is not the whole truth and actually might stop the user 
from searching for more information.

>But I think I see a bug here: for y-or-n-p, I think it should
>show the last part of the message rather than the first,
>so that the "? (y or n)" appears.  In other words, it should
>scroll up so the bottom appears on the screen.
>
>Could someone please implement that, and ack this message?
>  
>
I can not do it now, but I observed that yes-or-no-p does not have this 
problem. Also if you enter some invalid answer to y-or-n-p it will write 
"Please ..." in the wrong place in the minibuffer.
Permalink | Reply | 2 comments |
headers
Stephen J. Turnbull | 1 Aug 2005 03:39
Picon
Favicon

Re: defvar'ing constants

Sorry this is old; getting back into emacs-devel after a long hiatus.

>>>>> "Jay" == Jay Belanger <belanger <at> truman.edu> writes:

    Jay> That would be nice.  A while back, there was a discussion
    Jay> along the lines of doing something similar for functions,
    Jay> (defun foo) to keep the compiler happy.  I recall the idea
    Jay> (not mine) meeting approval.  Perhaps it's still planned for
    Jay> a future release?

XEmacs has a whole suite of macros for checking whether things are
boundp or fboundp, and for locally declaring them to be f?boundp to
the compiler without using def* macros.  We have found them very
useful in suppressing spurious compiler warnings.  If there is
interest in using this code, they are not yet assigned to the FSF, but
at the present time they are 100% written by Ben Wing <ben <at> xemacs.org>
as far as I know.  You might ask Ben to assign the code and avoid
redundant work on this.

The only advantage I see over the (defvar foo) approach is that you
avoid spurious tags, but this can be convenient.

These macros do not require any changes to the byte-compiler (in
XEmacs, anyway), and can even be placed in a separate library and
require'd only in the files where they are used.  (I don't recommend
this, just demonstrating that they don't interfere with the normal byte
compiler.)

Cheers,
(Continue reading)

Permalink | Reply | 1 comment |

Gmane