-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update pinyi #8
update pinyi #8
Conversation
… name from pinyin to real chinese character
… name from pinyin to real chinese character
Hi, this github repository is just a copy, it's not used by the Emacs developers. I suggest you email your patch to [email protected] along with a quick description. |
I've mailed several patches to that ML and none got any reply (or maybe didn't even get through). It's really a fine system for the 1990, but these days... :/ I can't be arsed to fiddle around with email. And yes, my contributions are worthless if I don't want to set up email, etc etc. :D I've got plenty of that. |
The recent changes to src/casefiddle.c cause build failure as seen below: Starting program: /home/npostavs/src/emacs/emacs-bootstrapping/src/temacs --batch --load loadup bootstrap [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Loading loadup.el (source)... Using load-path (/home/npostavs/src/emacs/emacs-bootstrapping/lisp /home/npostavs/src/emacs/emacs-bootstrapping/lisp/emacs-lisp /home/npostavs/src/emacs/emacs-bootstrapping/lisp/language /home/npostavs/src/emacs/emacs-bootstrapping/lisp/international /home/npostavs/src/emacs/emacs-bootstrapping/lisp/textmodes /home/npostavs/src/emacs/emacs-bootstrapping/lisp/vc) Loading emacs-lisp/byte-run (source)... Loading emacs-lisp/backquote (source)... Loading subr (source)... Loading version (source)... Loading widget (source)... Loading custom (source)... Loading emacs-lisp/map-ynp (source)... Loading international/mule (source)... Loading international/mule-conf (source)... lread.c:3914: Emacs fatal error: assertion failed: !NILP (Vpurify_flag) Breakpoint 1, terminate_due_to_signal at emacs.c:363 363 signal (sig, SIG_DFL); (gdb) bt #0 0x0000000000579826 in terminate_due_to_signal at emacs.c:363 #1 0x000000000060ec33 in die at alloc.c:7352 #2 0x000000000066db40 in intern_c_string_1 at lread.c:3914 #3 0x0000000000576884 in intern_c_string at lisp.h:3790 #4 0x00000000005dc84f in prepare_casing_context at casefiddle.c:69 #5 0x00000000005dd37f in casify_object at casefiddle.c:311 #6 0x00000000005dd47f in Fcapitalize at casefiddle.c:356 #7 0x00000000006325ac in eval_sub at eval.c:2219 #8 0x0000000000632368 in eval_sub at eval.c:2184 #9 0x000000000063446c in apply_lambda at eval.c:2875 #10 0x00000000006329af in eval_sub at eval.c:2294 #11 0x000000000062d462 in Fprogn at eval.c:449 #12 0x000000000062d4cf in prog_ignore at eval.c:461 #13 0x000000000062f19c in Fwhile at eval.c:982 #14 0x00000000006321f4 in eval_sub at eval.c:2172 #15 0x000000000062d462 in Fprogn at eval.c:449 #16 0x000000000062f0c4 in Flet at eval.c:963 #17 0x00000000006321f4 in eval_sub at eval.c:2172 #18 0x0000000000632963 in eval_sub at eval.c:2290 #19 0x000000000062d462 in Fprogn at eval.c:449 #20 0x000000000062f0c4 in Flet at eval.c:963 #21 0x00000000006321f4 in eval_sub at eval.c:2172 #22 0x0000000000668caa in readevalloop at lread.c:1927 #23 0x0000000000667253 in Fload at lread.c:1332 #24 0x0000000000632683 in eval_sub at eval.c:2233 #25 0x0000000000668caa in readevalloop at lread.c:1927 #26 0x0000000000667253 in Fload at lread.c:1332 #27 0x0000000000632683 in eval_sub at eval.c:2233 #28 0x0000000000631be5 in Feval at eval.c:2041 #29 0x000000000057e1af in top_level_2 at keyboard.c:1121 #30 0x000000000062ffc7 in internal_condition_case at eval.c:1324 #31 0x000000000057e1f0 in top_level_1 at keyboard.c:1129 #32 0x000000000062f51e in internal_catch at eval.c:1091 #33 0x000000000057e0ea in command_loop at keyboard.c:1090 #34 0x000000000057d6d5 in recursive_edit_1 at keyboard.c:697 #35 0x000000000057d8b4 in Frecursive_edit at keyboard.c:768 #36 0x000000000057b55b in main at emacs.c:1687 Lisp Backtrace: "capitalize" (0xffffcf70) "format" (0xffffd130) "define-charset" (0xffffd370) "while" (0xffffd560) "let" (0xffffd7c0) "dolist" (0xffffd910) "let" (0xffffdb70) "load" (0xffffdfe0) "load" (0xffffe4a0) * src/casefiddle.c (syms_of_casefiddle): Declare four new symbols: Qtitlecase, Qspecial_uppercase, Qspecial_lowercase and Qspecial_titlecase. (prepare_casing_context): Use aforementioned symbols.
@Fuco1 Whether mailing patches to the mailing list works or not, this is not the main Emacs repository, just an unofficial mirror, so there's no reasonable way to expect that people sending patches in to an unofficial copy are going to get reasonable responses from the maintainers, and there's no way that your suggestions on how they might do better will be noticed here, either. |
@pmetzger Yea well, I stopped caring about that a long time ago as well... Emacs is beyond saving. |
@Fuco1 Trolling might be fun, but it isn't very productive. |
@pmetzger Believe me I'm not trolling, I'm simply stating my opinion and being compassionate with the OP. I've authored more Elisp than most people in the world and I have very many good reasons to be active in Emacs development. Unfortunatelly I have even more reasons not to be. |
What exactly are the reasons for not using github ? I think there are many users like fuco who would like to contribute and this mail stuff discourage them. |
The FSF has its own git hosting. They prefer it because it uses only free software. It is trivial to participate in emacs development; if the fact that you need to send your patches by a method other than github is a barrier you're not really trying very hard. |
@pmetzger Hi there, can you point me to the FSF's own git please? |
@bpmcontrol If you look at the top of this very page, it says: You may also be interested in the emacs development homepage, which is pretty easy to find using google: https://savannah.gnu.org/projects/emacs If you look at that page, you will also see the mailing lists used by the developers for communicating with each other, and used for users seeking help: https://savannah.gnu.org/mail/?group=emacs There's also an IRC channel. |
Latest Terminfo introduces terminal definitions that support direct color mode. The "Co"/"colors" capability is set to 0x1000000 on these terminals and Emacs is already compatible with them. However, if used Terminfo library hasn't been compiled with 32-bit value support, "Co"/"colors" is truncated to 0x7fff. In this case direct color mode support can be detected from the "RGB" capability flag. There are some minor problems if the color count isn't corrected from 0x7fff. First eight standard colors defined in xterm-standard-colors are shown correctly. However, their RGB values match the terminal settings, not the RGB values defined in xterm-standard-colors. Bright versions of these colors are shown incorrectly. They are interpreted as pixels #8 - #15, which are very dark shades of blue. * src/term.c (init_tty): Force terminal color count to 0x1000000 if "RGB" capability is present. * src/tparam.h: Define prototype for tigetflag. (Bug#30308) * doc/misc/efaq.texi (Colors on a TTY): Add information about direct mode terminals supported by Terminfo.
In normal way, patch should be send to emacs-devel mailling list, emacs developers will comment the patch, after edit and edit .... patch will be merged :-) |
@guoxiangyang emacs 的开发流程不是这样的, 对于偶尔的供献者,应该将你的更改 'git format-patch' 另外:好像超过10行代码的更改,就需要签署 gpl 纸质协议,以前是这样,现在可能有 |
谢谢你的提醒,那样太麻烦了,本来就是顺手改一下. |
Remove pgtkconn, we no longer need it
update lisp/calendar/cal-china.el's chinese celestial and terrestrial name from pinyin to real chinese character