headers
Kenichi Handa | 1 Dec 2004 01:38

Re: Clipboard and coding systems

In article <87bre6k65d.fsf <at> marant.org>, Jérôme Marant <jmarant <at> nerim.net> writes:

> Kenichi Handa <handa <at> m17n.org> writes:
>>  So, my question is: Should Emacs still support pasting form
>>  an application that uses only a cut buffer?  If not, we can
>>  make x-cut-buffer-or-selection-value not check a cut buffer,
>>  then, we can store encoded string in a cut buffer by
>>  x-set-cut-buffer?
>> 
>>  Another way is to solve this problem (the comment before
>>  x-cut-buffer-or-selection-value) not in
>>  x-cut-buffer-or-selection-value.
>> 
>>  ;;; If this function is called twice and finds the same text,
>>  ;;; it returns nil the second time.  This is so that a single
>>  ;;; selection won't be added to the kill ring over and over.

> Hi,

> Has anything been decided about fixing this problem? Thanks.

Sorry for not responding long time.  As I found a simple
solution, I've just installed a fix.  Please try the latest
CVS code.

---
Ken'ichi HANDA
handa <at> m17n.org
Permalink | Reply | 1 comment |
headers
Alfred M. Szmidt | 1 Dec 2004 02:13
Picon

pcl-cvs and insertion ChangeLogs

Hi,

I whiped up this hack, it isn't tested that well at all; so if anyone
thinks of commiting it before the release, don't.  Just sharing it,
and tossing it out for discussion.

Some projects like to insert the full ChangeLog entry into the CVS
log.  And this adds a option that enables such an option, or atleast
_should_.

Happy hacking (and some serious sleeping for my part)

diff -up /usr/hacks/share/emacs/21.3.50/lisp/log-edit.el /tmp/buffer-content-767267u
--- /usr/hacks/share/emacs/21.3.50/lisp/log-edit.el	2004-09-15 00:01:58.000000000 +0200
+++ /tmp/buffer-content-767267u	2004-12-01 02:06:46.000000000 +0100
 <at>  <at>  -162,6 +162,11  <at>  <at>  should contain only the text for the cha
 file, because the log is per-file.  This is the behaviour you get
 when this variable is set to nil.")

+(defvar log-edit-changelog-full-entries nil
+  "*If non-nil, include a full ChangeLog entry in the log.
+This may be set in the ``local variables'' section of a ChangeLog, to
+indicate the policy for that ChangeLog.")
+
 ;;;; Internal global or buffer-local vars

 (defconst log-edit-files-buf "*log-edit-files*")
 <at>  <at>  -488,18 +493,21  <at>  <at>  To select default log text, we:

 (defun log-edit-narrow-changelog ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Dec 2004 03:56
Picon
Picon

Re: Man-fontify-manpage does not handle man, version 1.5o1, ANSI escape sequences

I too had rewritten his patch, but in a much simpler way.
Your version is fine.

However, I think that `highlight' is a more appropriate choice
for Man-reverse-face.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Dec 2004 03:56
Picon
Picon

Re: cc-mode adds newlines

    > Note that GCC accepts this too, as an extension.

    No more.

They were not supposed to do this!
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Dec 2004 03:56
Picon
Picon

Re: cc-mode adds newlines

    I believe it is, indirectly: The default settings should be suitable
    for the most common editing situations. It's reasonable to assume that
    a commonly accepted standard (which is the case with ANSI C) describe
    the common ground between implementations. Hence the standard is a
    very good source when finding out what the most common editing
    situations are.

It tells us what some of the common editing situations are, yes.  So
it is useful to look at the standard for many purposes, including this
one.  However, being a useful source of suggestions and insight is
quite different from laying down the law.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Dec 2004 03:57
Picon
Picon

Re: kmacro.texi

    I believe that `(emacs)Keyboard Macro Counter' and `(emacs)Keyboard
    Macro Step-Edit' are specialized sections and should be moved to
    emacs-xtra.  Would that be OK?

Yes, please do.

    We also decided some moths ago that it would be good to move
    kmacro.texi back to after the discussion of key bindings and related
    topics, which `(emacs)Save Keyboard Macro' heavily relies on.  Is this
    still OK?

Yes.

Your changes are basically good, but here are some specific comments.

    +   The maximum number of macros stored in the keyboard macro ring is
    + determined by the customizable variable  <at> code{kmacro-ring-max}.

This calls for an index entry.

    ! format to this default.  If you know the Elisp function  <at> code{format},
    ! then you can specify any format string that this function accepts and
    ! that makes sense with a single integer extra argument

Please change that to

    ! format to this default.   You can specify any format string
    ! that the  <at> code{format} function accepts and
    ! that makes sense with a single integer argument
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Dec 2004 03:57
Picon
Picon

Re: kmacro.el

    The new behavior is simple, with no surprises:

    Changing the format _never_ affects macros defined prior to the
    change.  (As already said there currently are situations where
    existing macros can be affected.)

    Changing the format when no kmacro is being defined or executed
    affects all macros defined from then on.  (Until the format is changed
    again.)

    Changing the format during macro definition changes the format of the
    macro being defined from that stage on, during definition and
    execution, but (unlike at present) does not affect subsequent macros
    still to be defined.

This seems clean to me.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Dec 2004 03:57
Picon
Picon

Re: Failure to update info files.

Does this fix it?

*** Makefile.in	20 Nov 2004 16:36:19 -0500	1.30
--- Makefile.in	30 Nov 2004 21:17:08 -0500	
***************
*** 124,130 ****
  distclean: clean

  maintainer-clean: clean
! 	rm -f elisp elisp-[1-9] elisp-[1-9][0-9] elisp.dvi elisp.oaux

  dist: $(infodir)/elisp elisp.dvi
  	-rm -rf temp
--- 124,131 ----
  distclean: clean

  maintainer-clean: clean
! 	rm -f elisp.dvi elisp.oaux
! 	cd $(infodir); rm -f elisp elisp-[1-9] elisp-[1-9][0-9] 

  dist: $(infodir)/elisp elisp.dvi
  	-rm -rf temp

Since the info files are generated by this makefile, I think it is
right for maintainer-clean in this makefile to delete them.
Permalink | Reply | 573 comments |
headers
Richard Stallman | 1 Dec 2004 03:57
Picon
Picon

Bootstrap shouldn't give up due to missing xrefs in the manual

Does this patch eliminate the problem?

*** Makefile.in	11 Nov 2004 09:58:10 -0500	1.298
--- Makefile.in	30 Nov 2004 21:19:32 -0500	
***************
*** 719,727 ****
  # put the info files in $(srcdir),
  # so we can do ok running make in the build dir.
  info: force-info
! 	(cd man; $(MAKE) $(MFLAGS) info)
! 	(cd lispref; $(MAKE) $(MFLAGS) info)
! 	(cd lispintro; $(MAKE) $(MFLAGS) info)
  dvi:
  	(cd man; $(MAKE) $(MFLAGS) dvi)
  	(cd lispref; $(MAKE) $(MFLAGS) elisp.dvi)
--- 719,727 ----
  # put the info files in $(srcdir),
  # so we can do ok running make in the build dir.
  info: force-info
! 	-(cd man; $(MAKE) $(MFLAGS) info)
! 	-(cd lispref; $(MAKE) $(MFLAGS) info)
! 	-(cd lispintro; $(MAKE) $(MFLAGS) info)
  dvi:
  	(cd man; $(MAKE) $(MFLAGS) dvi)
  	(cd lispref; $(MAKE) $(MFLAGS) elisp.dvi)
Permalink | Reply | 2 comments |
headers
Richard Stallman | 1 Dec 2004 03:57
Picon
Picon

Re: [Emacs-trunk-diffs] Changes to emacs/src/sysdep.c

The basic idea of the "emergency escape" feature is to provide a way
to get out of Emacs when it is not responding at all.

This is not needed on a window system, because you can make yourself
an xterm or whatever even if Emacs is not listening to you.  And you
could use the xterm to kill Emacs if that is what you want to do.

What did you wish to do using emergency escape under a window system?

    >> Maybe we could get the best of both worlds if we set it up so that
    >> quit can occur inside emacs_write only if it has been sitting there
    >> for 30 seconds or more since the last data it succeeded in writing.

    The idea sounds good, assuming you don't mean it to be specific to `write'.

The idea I had in mind is specific to e_write.  It is not needed for anything
else.  Most parts of Emacs will quit *very soon* if you type C-g.
Permalink | Reply | 7 comments |

Gmane