Convert more function definitions to standard C.
* src/xdisp.c (window_box_edges, handle_single_display_spec)
(display_string): Convert definition to standard C.
* src/scroll.c (do_direct_scrolling, scrolling_1):
* src/dispnew.c (allocate_matrices_for_frame_redisplay)
(mirrored_line_dance):
* src/coding.c (code_convert_string):
* src/charset.c (map_charset_chars):
* src/ccl.c (Fccl_program_p, Fccl_execute, Fccl_execute_on_string)
(Fregister_ccl_program, Fregister_code_conversion_map):
* src/keyboard.c (kbd_buffer_nr_stored): Likewise.
(head_table): Make static and const.
GNU Project Electronic Mailing Lists and gnUSENET Newsgroups Last Updated 2006-06-03 Please report improvements to: gnu@gnu.org See the end of this file for copyright notice and copying conditions* Mailing list archivesThe GNU mailing lists are archived at http://lists.gnu.org.* Some GNU mailing lists are also distributed as USENET news groupsCertain GNU mailing lists are gated both ways with the gnu.allnewsgroups at uunet. You can tell which they are, because the namescorrespond. For instance, bug-gnu-emacs corresponds to gnu.emacs.bug;info-gnu-emacs, to gnu.emacs.announce; help-gnu-emacs, tognu.emacs.help; gnu-emacs-sources, to gnu.emacs.sources. Replacing`emacs' with some other program in those four examples shows youthe whole pattern.If you don't know if your site is on USENET, ask your systemadministrator. If you are a USENET site and don't get the gnu.allnewsgroups, please ask your USENET administrator to get them. If he hasyour feeds ask their feeds, you should win. And everyone else wins:newsgroups make better use of the limited bandwidth of the computernetworks and your home machine than mailing list traffic; and stayingoff the mailing lists make better use of the people who maintain thelists and the machines that the GNU people working with rms use (i.e. wehave more time to produce code!!). Thanx.* Getting the mailing lists directlyIf several users at your site or local network want to read a list andyou aren't a USENET site, Project GNU would prefer that you would set upone address that redistributes locally. This reduces overhead on ourpeople and machines, your gateway machine, and the network(s) used totransport the mail from us to you.* How to subscribe to and report bugs in mailing listsSend requests to be added or removed, to help-gnu-emacs-request (orinfo-gnu-request, bug-gdb-request, etc.), NOT to info-gnu-emacs (orinfo-gnu, etc.). Most <LIST_NAME>-request addresses are now handledautomagically by GNU Mailman.If you need to report problems to a human, send mail to gnu@gnu.orgexplaining the problem.Many of the GNU mailing lists are very large and are received by manypeople. Most are unmoderated, so please don't send them anything thatis not seriously important to all their readers.If a message you mail to a list is returned from a MAILER-DAEMON (oftenwith the line: ----- Transcript of session follows ----- don't resend the message to the list. All this return means is thatyour original message failed to reach a few addresses on the list. Suchmessages are NEVER a reason to resend a piece of mail a 2nd time. Thisjust bothers all (less the few delivery failures (which will probablyjust fail again!)) of the readers of the list with a message they havealready seen. It also wastes computer and network resources.It is appropriate to send these to the -request address for a list, andask them to check the problem out.* Send Specific Requests for Information to: gnu@gnu.orgSpecific requests for information about obtaining GNU software, or GNUactivities in Cambridge and elsewhere can be directed to: gnu@gnu.org* General Information about all listsPlease keep each message under 25,000 characters. Some mailers bouncemessages that are longer than this. If your message is long, it isgenerally better to send a message offering to make the large fileavailable to only those people who want it (e.g. mailing it to peoplewho ask, or putting it up for FTP). In the case of gnu.emacs.sources,somewhat larger postings (up to 10 parts of no more than 25,000characters each) are acceptable (assuming they are likely to be ofinterest to a reasonable number of people); if it is larger than that,put it in a web page and announce its URL. Good bug reports are short.See section '* General Information about bug-* lists and ...' forfurther details.Most of the time, when you reply to a message sent to a list, the replyshould not go to the list. But most mail reading programs supply, bydefault, all the recipients of the original as recipients of the reply.Make a point of deleting the list address from the header when it doesnot belong. This prevents bothering all readers of a list, and reducesnetwork congestion.The GNU mailing lists and newsgroups, like the GNU project itself, existto promote the freedom to share software. So don't use these lists topromote or recommend non-free software or documentation, likeproprietary books on GNU software. (Using them to post orderinginformation is the ultimate faux pas.) If there is no free program todo a certain task, then somebody should write one! Similarly, freedocumentation that is inadequate should be improved--a way in whichnon-programmers can make a valuable contribution. See also the articleat <URL:http://www.gnu.org/philosophy/free-doc.html>.* General Information about info-* listsThese lists and their newsgroups are meant for important announcements.Since the GNU project uses software development as a means for socialchange, the announcements may be technical or political.Most GNU projects info-* lists (and their corresponding gnu.*.announcenewsgroups) are moderated to keep their content significant andrelevant. If you have a bug to report, send it to the bug-* list. Ifyou need help on something else and the help-* list exists, ask it.See section '* General Information about all lists'.* General Information about help-* listsThese lists (and their newsgroups) exist for anyone to ask questionsabout the GNU software that the list deals with. The lists are read bypeople who are willing to take the time to help other users.When you answer the questions that people ask on the help-* lists, keepin mind that you shouldn't answer by promoting a proprietary program asa solution. The only real solutions are the ones all the readers canshare.If a program crashes, or if you build it following the standardprocedure on a system on which it is supposed to work and it does notwork at all, or if an command does not behave as it is documented tobehave, this is a bug. Don't send bug reports to a help-* list; mailthem to the bug-* list instead.See section '* General Information about all lists'.* General Information about bug-* lists and reporting program bugsIf you think something is a bug in a program, it might be one; or, itmight be a misunderstanding or even a feature. Before beginning toreport bugs, please read the section ``Reporting Emacs Bugs'' toward theend of the GNU Emacs reference manual (or node Emacs/Bugs in Emacs'sbuilt-in Info system) for a discussion of how and when to send in bugreports. For GNU programs other than GNU Emacs, also consult theirdocumentation for their bug reporting procedures. Always include theversion number of the GNU program, as well as the operating system andmachine the program was ran on (if the program doesn't have a versionnumber, send the date of the latest entry in the file ChangeLog). ForGNU Emacs bugs, type "M-x emacs-version". A debugger backtrace of anycore dump can also be useful. Be careful to separate out hypothesisfrom fact! For bugs in GNU Emacs lisp, set variable debug-on-error tot, and re-enter the command(s) that cause the error message; Emacs willpop up a debug buffer if something is wrong; please include a copy ofthe buffer in your bug report. Please also try to make your bug reportas short as possible; distill the problem to as few lines of code and/orinput as possible. GNU maintainers give priority to the shortest, highquality bug reports.Please don't send in a patch without a test case to illustrate theproblem the patch is supposed to fix. Sometimes the patches aren'tcorrect or aren't the best way to do the job, and without a test casethere is no way to debug an alternate fix.The purpose of reporting a bug is to enable the bug to be fixed for thesake of the whole community of users. You may or may not receive aresponse; the maintainers will send one if that helps them find orverify a fix. Most GNU maintainers are volunteers and all areoverworked; they don't have time to help individuals and still fix thebugs and make the improvements that everyone wants. If you want helpfor yourself in particular, you may have to hire someone. The GNUproject maintains a list of people providing such services. It isfound in <URL:http://www.gnu.org/prep/SERVICE>.Anything addressed to the implementors and maintainers of a GNU programvia a bug-* list, should NOT be sent to the corresponding info-* orhelp-* list.Please DON'T post your bug reports on the gnu.*.bug newsgroups! Mailthem to bug-*@gnu.org instead! At first sight, it seems to make nodifference: anything sent to one will be propagated to the other; but: - if you post on the newsgroup, the information about how toreach you is lost in the message that goes on the mailing list. Itcan be very important to know how to reach you, if there is anythingin the bug report that we don't understand; - bug reports reach the GNU maintainers quickest when they aresent to the bug-* mailing list submittal address; - mail is much more reliable then netnews; and - if the internet mailers can't get your bug report delivered,they almost always send you an error message, so you can find anotherway to get the bug report in. When netnews fails to get your messagedelivered to the maintainers, you'll never know about it and themaintainers will never see the bug report.And please DON'T post your GNU bug reports to comp.* or other gnu.*newsgroups, they never make it to the GNU maintainers at all. Pleasemail them to bug-*@gnu.org instead!* Some special lists that don't fit the usual patterns of help-, bug- and info-** info-gnu-request@gnu.org to subscribe to info-gnugnUSENET newsgroup: gnu.announceSend announcements to: info-gnu@gnu.orgThis list distributes progress reports on the GNU Project. It is alsoused by the GNU Project to ask people for various kinds of help. It ismoderated and NOT for general discussion.** gnu-misc-discuss-request@gnu.org to subscribe to gnu-misc-discussgnUSENET newsgroup: gnu.misc.discussSend contributions to: gnu-misc-discuss@gnu.orgThis list is for serious discussion of free software, the GNU Project,the GNU Manifesto, and their implications. It's THE place fordiscussion that is not appropriate in the other GNU mailing lists andgnUSENET newsgroups.Flaming is out of place. Tit-for-tat is not welcome. Repetitionshould not occur.Good READING and writing are expected. Before posting, wait a while,cool off, and think.Don't use this group for complaints and bug reports about GNU software!The maintainers of the package you are using probably don't read thisgroup; they won't see your complaint. Use the appropriate bug-reportingmailing list instead, so that people who can do something about theproblem will see it. Likewise, use the help- list for technicalquestions.Don't trust pronouncements made on gnu-misc-discuss about what GNU is,what FSF position is, what the GNU General Public License is, etc.,unless they are made by someone you know is well connected with GNU andare sure the message is not forged.USENET and gnUSENET readers are expected to have read ALL the articlesin news.announce.newusers before posting. If news.announce.newusers isempty at your site, wait (the articles are posted monthly), your postingisn't that urgent! Readers on the Internet can anonymous FTP thesearticles from host ftp.uu.net under directory ??Remember, "GNUs Not Unix" and "gnUSENET is Not USENET". We havehigher standards!** guile-sources-request@gnu.org to subscribe to guile-sourcesgnUSENET newsgroup: NONE PLANNEDGuile source code to: guile-sources@gnu.orgThis list will be for the posting, by their authors, of GUILE, Scheme,and C sources and patches that improve Guile. Its contents will bereviewed by the FSF for inclusion in future releases of GUILE.Please do NOT discuss or request source code here. Use bug-guile forthose purposes. This allows the automatic archiving of sources postedto this list.Please do NOT post such sources to any other GNU mailing list (e.gbug-guile) or gnUSENET newsgroups. It's up to each poster to decidewhether to cross-post to any non-gnUSENET newsgroup.Please do NOT announce that you have posted source code to guile.sourcesto any other GNU mailing list (e.g. bug-guile) or gnUSENET newsgroups.People who want to keep up with sources will read this list. It's up toeach poster to decide whether to announce a guile.sources article in anynon-gnUSENET newsgroup (e.g. comp.emacs or comp.sources.d).If source or patches that were previously posted or a simple fix isrequested in bug-guile, please mail it to the requester. Do NOTrepost it. If you also want something that is requested, send mail tothe requester asking him to forward it to you. This kind of traffic isbest handled by e-mail, not by a broadcast medium that reaches millionsof sites.If the requested source is very long (>10k bytes) send mail offering tosend it. This prevents the requester from getting many redundant copiesand saves network bandwidth.** gnu-emacs-sources-request@gnu.org to subscribe to gnu-emacs-sourcesgnUSENET newsgroup: gnu.emacs.sourcesGNU Emacs source code to: gnu-emacs-sources@gnu.orgThis list/newsgroup will be for the posting, by their authors, of EmacsLisp and C sources and patches that improve GNU Emacs. Its contentswill be reviewed by the FSF for inclusion in future releases of GNUEmacs.Please do NOT discuss or request source code here. Usehelp-gnu-emacs/gnu.emacs.help for those purposes. This allows theautomatic archiving of sources posted to this list/newsgroup.Please do NOT post such sources to any other GNU mailing list (e.ghelp-gnu-emacs) or gnUSENET newsgroups (e.g. gnu.emacs.help). It's upto each poster to decide whether to cross-post to any non-gnUSENETnewsgroup (e.g. comp.emacs or vmsnet.sources).Please do NOT announce that you have posted source code tognu.emacs.sources to any other GNU mailing list (e.g. help-gnu-emacs) orgnUSENET newsgroups (e.g. gnu.emacs.help). People who want to keep upwith sources will read this list/newsgroup. It's up to each poster todecide whether to announce a gnu.emacs.sources article in anynon-gnUSENET newsgroup (e.g. comp.emacs or comp.sources.d).If source or patches that were previously posted or a simple fix isrequested in help-gnu-emacs, please mail it to the requester. Do NOTrepost it. If you also want something that is requested, send mail tothe requester asking him to forward it to you. This kind of traffic isbest handled by e-mail, not by a broadcast medium that reaches millionsof sites.If the requested source is very long (>10k bytes) send mail offering tosend it. This prevents the requester from getting many redundant copiesand saves network bandwidth.Local variables:mode: outlinefill-column: 72End:Copyright (C) 1999, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010Free Software Foundation, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this file, to deal in the file without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the file, and to permit persons to whom the file is furnished to do so, subject to the following condition: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the file.arch-tag: 6e42bba8-7532-4a23-8486-99dbc5770a8e