<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.emacs.devel">
    <title>gmane.emacs.devel</title>
    <link>http://blog.gmane.org/gmane.emacs.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106372"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106371"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106370"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106369"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106368"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106361"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106340"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106337"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106328"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106327"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106304"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106297"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106294"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106292"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106284"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106274"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106272"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106262"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106230"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.devel/106221"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106372">
    <title>problem report #99</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106372</link>
    <description>CID: 99
Checker: UNINIT (help)
File: base/src/emacs/src/keyboard.c
Function: kbd_buffer_get_event
Description: Using uninitialized value "bar_window" in call to function "make_lispy_movement"

Event var_decl: Declared variable "bar_window" without initializer
Also see events: [uninit_use_in_call]

4259       Lisp_Object bar_window;
4260       enum scroll_bar_part part;
4261       Lisp_Object x, y;
4262       unsigned long time;
4263 
4264       *kbp = current_kboard;
4265       /* Note that this uses F to determine which terminal to look at.
4266  If there is no valid info, it does not store anything
4267  so x remains nil.  */
4268       x = Qnil;
4269 
4270       /* XXX Can f or mouse_position_hook be NULL here? */

At conditional (1): "f != 0" taking true path
At conditional (2): "((f)-&gt;terminal)-&gt;mouse_position_hook != 0" taking false path

4271       if (f &amp;&amp; FRAME_TERMINAL (f)-&gt;mouse_position_hook)
4272         (*FRAME_TERMINAL (f)-&gt;mouse_position_hook) (&amp;f, 0, &amp;bar_window,
4273       </description>
    <dc:creator>Dan Nicolaescu</dc:creator>
    <dc:date>2008-12-01T15:57:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106371">
    <title>problem report #97</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106371</link>
    <description>CID: 97
Checker: RESOURCE_LEAK (help)
File: base/src/emacs/src/term.c
Function: init_tty
Description: Returned without freeing storage "area"

Event alloc_fn: Called allocation function "xmalloc" [model]
Event var_assign: Assigned variable "area" to storage returned from "xmalloc"
Also see events: [var_assign][leaked_storage]

3555   area = (char *) xmalloc (buffer_size);
3556 
3557   tty-&gt;TS_ins_line = tgetstr ("al", address);
3558   tty-&gt;TS_ins_multi_lines = tgetstr ("AL", address);
3559   tty-&gt;TS_bell = tgetstr ("bl", address);
3560   BackTab (tty) = tgetstr ("bt", address);
3561   tty-&gt;TS_clr_to_bottom = tgetstr ("cd", address);
3562   tty-&gt;TS_clr_line = tgetstr ("ce", address);
3563   tty-&gt;TS_clr_frame = tgetstr ("cl", address);
3564   ColPosition (tty) = NULL; /* tgetstr ("ch", address); */
3565   AbsPosition (tty) = tgetstr ("cm", address);
3566   CR (tty) = tgetstr ("cr", address);
3567   tty-&gt;TS_set_scroll_region = tgetstr ("cs", address);
3568   tty-&gt;TS_set_scroll_region_1 = tgetstr (</description>
    <dc:creator>Dan Nicolaescu</dc:creator>
    <dc:date>2008-12-01T15:56:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106370">
    <title>problem report #96</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106370</link>
    <description>CID: 96
Checker: UNINIT (help)
File: base/src/emacs/src/gtkutil.c
Function: update_frame_tool_bar
Description: Using uninitialized value "stock"

Event var_decl: Declared variable "stock" without initializer
Also see events: [uninit_use]

3865       Lisp_Object stock;
3866       GtkStockItem stock_item;
3867       char *stock_name = NULL;
3868       char *icon_name = NULL;
3869       Lisp_Object rtl;
3870       GtkWidget *wbutton = NULL;
3871       GtkWidget *weventbox;
3872       Lisp_Object func = intern ("x-gtk-map-stock");
3873       Lisp_Object specified_file;
3874 
3875       ti = gtk_toolbar_get_nth_item (GTK_TOOLBAR (x-&gt;toolbar_widget), i);
3876 

At conditional (3): "ti != 0" taking true path

3877       if (ti)
3878         {
3879           weventbox = gtk_bin_get_child (GTK_BIN (ti));
3880           wbutton = gtk_bin_get_child (GTK_BIN (weventbox));
3881         }
3882 
3883       image = PROP (TOOL_BAR_ITEM_IMAGES);
3884 
3885       /* Ignore invalid image specifications.  */</description>
    <dc:creator>Dan Nicolaescu</dc:creator>
    <dc:date>2008-12-01T15:54:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106369">
    <title>problem report #95</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106369</link>
    <description>CID: 95
Checker: FORWARD_NULL (help)
File: base/src/emacs/src/gtkutil.c
Function: update_frame_tool_bar
Description: Variable "img" tracked as NULL was passed to a function that dereferences it.

Event assign_zero: Variable "img" assigned value 0.
Also see events: [var_deref_model]

3863       struct image *img = NULL;
3864       Lisp_Object image;
3865       Lisp_Object stock;
3866       GtkStockItem stock_item;
3867       char *stock_name = NULL;
3868       char *icon_name = NULL;
3869       Lisp_Object rtl;
3870       GtkWidget *wbutton = NULL;
3871       GtkWidget *weventbox;
3872       Lisp_Object func = intern ("x-gtk-map-stock");
3873       Lisp_Object specified_file;
3874 
3875       ti = gtk_toolbar_get_nth_item (GTK_TOOLBAR (x-&gt;toolbar_widget), i);
3876 

At conditional (1): "ti != 0" taking true path

3877       if (ti)
3878         {
3879           weventbox = gtk_bin_get_child (GTK_BIN (ti));
3880           wbutton = gtk_bin_get_child (GTK_BIN (weventbox));
3881         }
3882</description>
    <dc:creator>Dan Nicolaescu</dc:creator>
    <dc:date>2008-12-01T15:52:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106368">
    <title>more problem reports</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106368</link>
    <description>
It seems that more possible issues have showed up since the last time I
looked at them.

Here's the current list:

 CID   Checker   Status  Function   File
View_134 UNINIT UNINSPECTED font_for_char base/src/emacs/src/fontset.c
View_133 FORWARD_NULL UNINSPECTED font_range base/src/emacs/src/font.c
View_132 UNINIT UNINSPECTED procfs_system_process_attributes base/src/emacs/src/process.c
View_132 UNINIT UNINSPECTED procfs_system_process_attributes base/src/emacs/src/process.c
View_131 UNINIT UNINSPECTED procfs_system_process_attributes base/src/emacs/src/process.c
View_130 UNINIT UNINSPECTED x_draw_glyph_string base/src/emacs/src/xterm.c
View_129 UNINIT UNINSPECTED ftfont_match base/src/emacs/src/ftfont.c
View_128 UNINIT UNINSPECTED ftfont_resolve_generic_family base/src/emacs/src/ftfont.c
View_127 UNINIT UNINSPECTED ftfont_list_family base/src/emacs/src/ftfont.c
View_126 UNINIT UNINSPECTED font_at base/src/emacs/src/font.c
View_125 UNINIT UNINSPECTED simple_search base/src</description>
    <dc:creator>Dan Nicolaescu</dc:creator>
    <dc:date>2008-12-01T15:51:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106361">
    <title>open large file with C code: is it realy should be so slow?</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106361</link>
    <description>I have problem with emacs responsibility,
I work with large enough C header files,
and when I want to scroll it using mouse's wheel or
page (up|down) keys emacs stop react on any keys, like (ctrl+g),
and eats 100% of CPU's time during long period,
I wonder is this a bug, or expected behaviour?

My cpu frequnce is 2200.000MHz.

elp results are:

Function Name                                              Call Count
Elapsed Time  Average Time
=========================================================  ==========
============  ============
font-lock-fontify-region                                   387
14.909457999  0.0385257312
font-lock-default-fontify-region                           387
14.904738000  0.0385135348
font-lock-fontify-keywords-region                          387
14.469801     0.0373896666
font-lock-fontify-syntactically-region                     384
0.4169809999  0.0010858880
font-lock-unfontify-region                                 387
0.0036489999  9.428...e-06
font-lock-mode                  </description>
    <dc:creator>Dave Milter</dc:creator>
    <dc:date>2008-12-01T10:01:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106340">
    <title>Problem with {beginning,end}-of-visual-line</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106340</link>
    <description>
I'm not sure if the behavior described below is a bug or not.

If it's a bug, I'll send a report bug.

Please, try with the latest Emacs CVS:


1. emacs -Q


2. Insert in the *Scratch* buffer:

WF012345678901234567890123456789012345678901234FW
| ;      »       »       »^      »       »ABC   |

Where:
- The very first line indicates the column (numbers), the fringes (F) 
and the window border (W).
- The character | represents the window border.
- The character ^ represents the point.
- The character » represents a TAB.


3. Shrink window:

WF0123456789012345678901234567890123456FW
| ;      »       »       »^      »     &lt;|
|&gt;  »ABC                                |


4. M-x beginning-of-visual-line RET

WF0123456789012345678901234567890123456FW
| ^;     »       »       »       »     &lt;|
|&gt;  »ABC                                |


5. M-x end-of-visual-line RET

WF0123456789012345678901234567890123456FW
| ;      »       »       »       »^    &lt;|
|&gt;  »ABC                                |


6. M</description>
    <dc:creator>Vinicius Jose Latorre</dc:creator>
    <dc:date>2008-11-30T20:28:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106337">
    <title>Coding systems documentation</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106337</link>
    <description>    +&lt; at &gt;c I think this paragraph is no longer correct.
    +&lt; at &gt;ignore
       Most coding systems specify a particular character code for
     conversion, but some of them leave the choice unspecified---to be chosen
     heuristically for each file, based on the data.
    +&lt; at &gt;end ignore

I think these still exist.  For example, there are `undecided' and friends.



</description>
    <dc:creator>Richard M Stallman</dc:creator>
    <dc:date>2008-11-30T16:43:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106328">
    <title>dbus library functions</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106328</link>
    <description>I'm interested in making a library of common dbus services available in
Emacs.

Three logical services would be Notify, On Screen Display, and Avahi.
Perhaps some of the power management information available via DBus
would be useful to battery.el, as well.

So, two questions:

1. Would building Emacs Lisp functions to encapsulate some of the DBus
   information be useful to include in the core?

2. Would it be better to create separate libraries (e.g. notify.el,
   osd.el, avahi.el) or a single one (e.g. freedesktop-dbus.el) for
   these functions?

Thanks,

Mark.




</description>
    <dc:creator>Mark A. Hershberger</dc:creator>
    <dc:date>2008-11-29T23:16:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106327">
    <title>.emacs.d/tramp - written/touched each time you exit Emacs?</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106327</link>
    <description>Dunno if this helps or is important, but I just fired up Emacs 23 (with my
libraries, not emacs -Q), opened Info and a couple files, and then exited Emacs.


While Emacs was exiting, I noticed a very brief message about Tramp - too quick
for me to read (which is not good, BTW). I did not access any remote files or
even try to during the brief session. As far as I know, I made no use of Tramp
whatsoever. AFAIK, my own code does not load or use Tramp behind the scene.

Curious, I looked around for a file related to Tramp and discovered
.emacs.d/tramp, which had just been updated. But the file content is nothing
new. I haven't used Tramp in a long time (I've always had problems getting it to
work on Windows), and there doesn't seem to be anything new in this file. The
only thing that might be new (I'm unfamiliar with the old content) is the last
line:

("started" t)))

I tried another session of Emacs and saw the same thing - the file `tramp' was
touched when I exited Emacs, but the content looks identical.

Ar</description>
    <dc:creator>Drew Adams</dc:creator>
    <dc:date>2008-11-29T23:03:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106304">
    <title>numeri</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106304</link>
    <description>Observe:

    M-: (get-char-code-property ?4 'numeric-value) RET
      =&gt; \4

What does the backslash signify in this case?



</description>
    <dc:creator>Eli Zaretskii</dc:creator>
    <dc:date>2008-11-29T14:36:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106297">
    <title>multi-threaded Emacs</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106297</link>
    <description>Hello,

I attached a small patch that enables basic threads in Emacs; it is just
a proof of concept and not usable yet, my goal was the execution of the
elisp code I included at the bottom.

In the new file thread.c these functions are defined:

(create-thread) 
(with-thread id '(code))
(kill-thread id)

The first one creates a suspended thread that is waiting for requests.
These requests are done by with-thread that allows the execution of
'(code) on the specified thread.  `kill-thread' is used to terminate a
thread execution by its id.

It is a prototype and the code is not very clean, still a lot of work
must be done in order to have working threads, but I think that have a
multi-threaded Emacs worths this effort.

My idea is to share global variables among threads while local bindings
are done locally to threads.

I haven't well investigated all problems that will raise using threads
in Emacs, the first one that come to my attention is the garbage
collector and at the moment I simply disable GC while the</description>
    <dc:creator>Giuseppe Scrivano</dc:creator>
    <dc:date>2008-11-29T13:32:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106294">
    <title>no executable emacs binary in exec-directory</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106294</link>
    <description>I thought that the currently running emacs binary should be in
exec-directory. That does not seem to be the case always. How do you
find it?



</description>
    <dc:creator>Lennart Borgman</dc:creator>
    <dc:date>2008-11-29T13:00:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106292">
    <title>Meta characters in strings</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106292</link>
    <description>Is this text from the ELisp manual still correct?

      Sometimes key sequences are represented as strings.  When a string is
    a key sequence, string elements in the range 128 to 255 represent meta
    characters (which are large integers) rather than character
    codes in the range 128 to 255.



</description>
    <dc:creator>Eli Zaretskii</dc:creator>
    <dc:date>2008-11-29T12:03:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106284">
    <title>A note about Antinews</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106284</link>
    <description>Since the purpose of Antinews is to help people use the previous Emacs
version, there is usually no need to mention features that are simply
absent in that version.  That situation will be clear enough to users
without help from the manual.

For instance, this

    &lt; at &gt;item
    Emacs can no longer be started as a daemon.  We decided that having an
    Emacs sitting silently in the background with no visual manifestation
    anywhere in sight is too confusing.

may not need mentioning, because --daemon will give an error message
saying it's not implemented, and other cases aren't affected.


The kind of change for which the user really needs help from Antinews
is where a feature works _differently_ in the previous version.
In those cases, the user might have trouble figuring out how to use
the old version without some sort of help.



</description>
    <dc:creator>Richard M Stallman</dc:creator>
    <dc:date>2008-11-29T09:17:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106274">
    <title>Excess consing comes from x-gtk-map-stock</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106274</link>
    <description>I think the excess consing, leading to frequent garbage collection,
comes from x-gtk-map-stock.  This is called by update_frame_tool_bar on
each redisplay, for each tool-bar item.  Each call advances
consing_since_gc by about 400 bytes, and this adds up rather quickly.



</description>
    <dc:creator>Chong Yidong</dc:creator>
    <dc:date>2008-11-28T22:38:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106272">
    <title>configure failure (CVS trunk)</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106272</link>
    <description>./configure: line 2784: syntax error near unexpected token `newline'
./configure: line 2784: `  mips-*-linux-gnu* | mipsel-*-linux-gnu* |'

--- emacs/configure.in.~1.577.~
+++ emacs/configure.in
&lt; at &gt;&lt; at &gt; -539,8 +539,8 &lt; at &gt;&lt; at &gt;
   ;;
 
   ## Mips Linux-based GNU system
-  mips-*-linux-gnu* | mipsel-*-linux-gnu* |
-  mips64-*-linux-gnu* | mips64el-*-linux-gnu* )
+  mips-*-linux-gnu* | mipsel-*-linux-gnu* \
+    | mips64-*-linux-gnu* | mips64el-*-linux-gnu* )
     machine=mips opsys=gnu-linux
   ;;
 



</description>
    <dc:creator>Ulrich Mueller</dc:creator>
    <dc:date>2008-11-28T22:19:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106262">
    <title>My contribution code for doc-view.el</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106262</link>
    <description>Hi, everyone!

Below is my contribution code for doc-view.el

------------------------------&gt; code start &lt;------------------------------

(defadvice scroll-other-window (around doc-view-scroll-up-or-next-page activate)
  "When next buffer is `doc-view-mode', do `doc-view-scroll-up-or-next-page'."
  (other-window +1)
  (if (eq major-mode 'doc-view-mode)
      (let ((arg (ad-get-arg 0)))
        (if (null arg)
            (doc-view-scroll-up-or-next-page)
          (doc-view-next-line-or-next-page arg))
        (other-window -1))
    (other-window -1)
    ad-do-it))

(defadvice scroll-other-window-down (around doc-view-scroll-down-or-previous-page activate)
  "When next buffer is `doc-view-mode', do `doc-view-scroll-down-or-previous-page'."
  (other-window +1)
  (if (eq major-mode 'doc-view-mode)
      (let ((arg (ad-get-arg 0)))
        (if (null arg)
            (doc-view-scroll-down-or-previous-page)
          (doc-view-previous-line-or-previous-page arg))
        (other-window -1))
    (other-window -1)
  </description>
    <dc:creator>Andy Stewart</dc:creator>
    <dc:date>2008-11-28T13:54:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106230">
    <title>server-window is not mentioned very much</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106230</link>
    <description>Is not `server-window' a rather important option for those using Emacs
 client? Shouldn't the possibilities it gives be mentioned in the
manual?



</description>
    <dc:creator>Lennart Borgman</dc:creator>
    <dc:date>2008-11-27T14:17:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106221">
    <title>Concerning delete-by-moving-to-trash on free systems</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106221</link>
    <description>Hi all,

I've just found out about that option, and basically it's nice.  But in
order to integrate emacs on the modern GNU desktop the moving to trash
should be in compliance with the Freedesktop.org Trash Specification [1]
on systems that support it.  This spec enables undoing of deletions
which requires storage of some metadata of course.

Beside from not conforming to this standard, the current implementation
has other drawbacks.

  - Delete a directory foo which contains the files a and b recursively
    (from within dired).  Then goto the trash-directory.  Now foo, a and
    b are side by side.

  - Now delete another file named a.  This file is really deleted,
    because a already exists in trash.  (Overwriting would be as bad as
    the current decision.)

Bye,
Tassilo
__________
[1] http://www.freedesktop.org/wiki/Specifications/trash-spec?action=show&amp;redirect=Standards%2Ftrash-spec



</description>
    <dc:creator>Tassilo Horn</dc:creator>
    <dc:date>2008-11-27T10:09:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.devel/106183">
    <title>My contribution code for Emacs.</title>
    <link>http://comments.gmane.org/gmane.emacs.devel/106183</link>
    <description>Hi, everyone!

I have three independent extensions for Emacs.
I want to contribute those extensions.

I have sign copyright of FSF and have PDF document of FSF.

But i don't know the detail process of contribute code to Emacs.

Any help?

Thanks.

  -- Andy.



</description>
    <dc:creator>Andy Stewart</dc:creator>
    <dc:date>2008-11-26T00:26:03</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.emacs.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.emacs.devel</link>
  </textinput>
</rdf:RDF>
