headers
John J Foerch | 1 Sep 2007 01:44
Picon
Favicon
Gravatar

Re: Outline mode

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> I don't think that's a good idea in general: it forces every entry to span
> at least two display lines: one for the heading and another for the
> ellipsis.  In some contexts it might be accpetable, but definitely
> not always.
>
>
> Maybe you could make it an option.
>
>
>         Stefan

Actually, with my patch, the ellipsis appears on the same line as the
heading.

--John
Permalink | Reply | 14 comments |
headers
Glenn Morris | 1 Sep 2007 01:47
Picon

Re: mention risky local variables "!" choice

jidanni <at> jidanni.org wrote:

> OK, then please document the **** changes stuff below:
>
>    Some variables, such as `load-path', are considered particularly
> "risky": there is seldom any reason to specify them as local
> variables, and changing them can be dangerous. ****> Emacs will not
> prompt with "!" in this case, and even if you enter it, <**** Emacs
> will not record any values as safe for these variables.

When Emacs does not prompt with !, you can't enter it. This is so
self-explanatory as to not be worth documenting.

If there are both risky and unsafe variables, it does prompt with !,
but that only applies to the unsafe variables. This non-trivial case
is what the current manual refers to, quite clearly I think.

> And don't forget the other important points of my original important
> post.

I must have missed them.
Permalink | Reply | 1 comment |
headers
YAMAMOTO Mitsuharu | 1 Sep 2007 01:50
Picon

Re: CVS HEAD fails to build on OSX 10.4 (macterm.c broken?)

>>>>> On Fri, 31 Aug 2007 14:21:11 -0400, Richard Stallman <rms <at> gnu.org> said:

>> The simplest fix is to convert those macros to defuns, since
>> efficiency is not important here.

>> They could also be defsubsts, but getting the value of them would
>> entail such a `require' as caused trouble already.

>     Sorry, I don't think that working around the bootstrap issue in this
>     way is not a good thing to do now.

> I do not follow you.  Do you see any reason why my patch to url.el
> should not be installed?

The original problem that Emacs doesn't bootstrap with Carbon was
introduced by multi-tty because it changed lisp/loadup.el to preload
lisp/term/mac-win.el.  So I thought the first thing to do is to
clarify this preloading is really necessary or the right thing rather
than making a workaround at the url package side.  Anyway, it seems
that Stefan has already installed another change using defstruct.

Someone who is really familiar with multi-tty should explain why
preloading lisp/term/*-win.el was necessary for multi-tty.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp
Permalink | Reply | 11 comments |
headers
Drew Adams | 1 Sep 2007 01:57
Picon
Favicon

RE: [sdl.web <at> gmail.com: 23.0.0; (thing-at-point 'url) returns invalid urls]

>    That's OK too. I thought people were asking for the ability to
>    get only "valid" URLs in the sense of having live
>    targets. Isn't that what the initial request was for?
>
> iiuc the initial request was to disambiguate the two cases whereby
> (thing-at-point 'url) when point is on one of:
>   something
>   http://something
> (both cases return "http://something").

Admittedly, the text of the initial bug report (OP) is not too clear:

>> Put the point in any word but not in a url and eval (thing-at-point
>> 'url) it will returns a url like "http://something", where 'something'
>> is the word under point.

That and other posts seem to suggest that the requested (optional, perhaps)
behavior is to return nil unless the URL under point contains a scheme (e.g.
http://, ftp://). For example, "something" at point and www.google.com at
point would each return nil.

However, other posts seem to suggest that the perceived problem is that
http://something is not a "valid" URL because the target is not (currently
or perhaps usually) live (accessible):

>> Because a url created by concat "http://" and the word under point is
>> unlikely to be accessible by a browser.

Admittedly, it says "is unlikely to be accessible", not "is not accessible".
But the subject line of the thread is "... returns invalid urls". Since the
(Continue reading)

Permalink | Reply | 3 comments |
headers
d.henman | 1 Sep 2007 02:19
Picon

Re: Failure in building Emacs 23.0.50 on Cygwin


I confirm that I too, encounter the same problem reported by Angelo on cygwin

> term.o: In function `dissociate_if_controlling_tty':
> /tmp/emacs/src/term.c:3146: undefined reference to `_croak'

I believe, the problem is that "croak" is not being properly defined in the
"sysdep.c" file.  It is only manifested when trying to compile term.c which refers to croak.

How should one define "croak" in sysdep.c for "i686-pc-cygwin" to test this?
   Ref: config.log:Target: i686-pc-cygwin

Regards,
  darel henman
Permalink | Reply | 7 comments |
headers
Dan Nicolaescu | 1 Sep 2007 02:35
Picon

Re: Failure in building Emacs 23.0.50 on Cygwin

"d.henman" <dhenman <at> gmail.com> writes:

  > I confirm that I too, encounter the same problem reported by Angelo on cygwin
  > 
  > > term.o: In function `dissociate_if_controlling_tty':
  > > /tmp/emacs/src/term.c:3146: undefined reference to `_croak'
  > 
  > 
  > I believe, the problem is that "croak" is not being properly defined in the
  > "sysdep.c" file.  It is only manifested when trying to compile term.c which refers to croak.
  > 
  > How should one define "croak" in sysdep.c for "i686-pc-cygwin" to test this?
  >    Ref: config.log:Target: i686-pc-cygwin

IMO the question should be asked the other way: how do you avoid
references to "croak". 

Adjust preprocessor code in dissociate_if_controlling_tty so that
croak is not used. Whether that is enough to make cygwin work, I don't
know.
Permalink | Reply | 6 comments |
headers
Leo | 1 Sep 2007 03:57
Face
Picon
Gravatar

Re: [sdl.web <at> gmail.com: 23.0.0; (thing-at-point 'url) returns invalid urls]

On 2007-08-31 21:34 +0100, Drew Adams wrote:
> That's OK too. I thought people were asking for the ability to get only
> "valid" URLs in the sense of having live targets. Isn't that what the
> initial request was for?

Stefan gets my idea right. It is definitely not about aliveness.

--

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

         Gnus is one component of the Emacs operating system.
Permalink | Reply | 10 comments |
headers
Stefan Monnier | 1 Sep 2007 04:02
Picon

Re: Outline mode

>> I don't think that's a good idea in general: it forces every entry to span
>> at least two display lines: one for the heading and another for the
>> ellipsis.  In some contexts it might be accpetable, but definitely
>> not always.
>> Maybe you could make it an option.

> Actually, with my patch, the ellipsis appears on the same line as the
> heading.

Duh, I overlooked this "detail", sorry.
But then in what way does it help?  You may now move the cursor to just
after the ellipsis but actually be placed right after the newline (rather
than at the end of the text).  And if you remove the newline, you get into
the undesired situation where there is no ellipsis any more to warn about
the presence of invisible text.

Of course I'm biased: it would break reveal-mode which I wrote and use
extensively with outline-minor-mode ;-)

        Stefan
Permalink | Reply | 13 comments |
headers
Stefan Monnier | 1 Sep 2007 04:06
Picon

Re: CVS HEAD fails to build on OSX 10.4 (macterm.c broken?)

> Someone who is really familiar with multi-tty should explain why
> preloading lisp/term/*-win.el was necessary for multi-tty.

I don't know the reason for it but it does strike me that the probability
that mac-win.el will be used in a Carbon build is very high (similarly for
w32-win.el and x-win.el in their respective builds I guess).

But of course, by this reasoning encoded-kb.el should be preloaded as well,
but Richard rejected it.

        Stefan
Permalink | Reply | 10 comments |
headers
Glenn Morris | 1 Sep 2007 04:49
Picon

Re: Split man directory

Richard Stallman wrote:

> I would like to split the `man' directory, putting the auxiliary
> manuals into a different directory, and keeping only the Emacs manual
> in `man'.  Can someone please do this?

Would you prefer a subdirectory of man (man/aux), or a new directory
at the same level (man-aux)?
Permalink | Reply | 58 comments |

Gmane