Skip to content
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

Closed
wants to merge 2 commits into from
Closed

Conversation

guoxiangyang
Copy link

update lisp/calendar/cal-china.el's chinese celestial and terrestrial name from pinyin to real chinese character

@alanthird
Copy link
Contributor

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.

@Fuco1
Copy link

Fuco1 commented Mar 30, 2017

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.

hubot pushed a commit that referenced this pull request Apr 7, 2017
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.
@pmetzger
Copy link
Contributor

@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.

@Fuco1
Copy link

Fuco1 commented Apr 12, 2017

@pmetzger Yea well, I stopped caring about that a long time ago as well... Emacs is beyond saving.

@pmetzger
Copy link
Contributor

@Fuco1 Trolling might be fun, but it isn't very productive.

@Fuco1
Copy link

Fuco1 commented Apr 12, 2017

@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.

@brotzeit
Copy link
Contributor

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.

@pmetzger
Copy link
Contributor

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.

@bpmcontrol
Copy link

@pmetzger Hi there, can you point me to the FSF's own git please?
Thanks.

@pmetzger
Copy link
Contributor

pmetzger commented Apr 28, 2017

@bpmcontrol If you look at the top of this very page, it says:
"emacs-mirror/emacs
mirrored from git://git.sv.gnu.org/emacs.git"

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.

hubot pushed a commit that referenced this pull request Feb 10, 2018
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.
@tumashu
Copy link
Contributor

tumashu commented Jan 5, 2019

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 :-)

@tumashu
Copy link
Contributor

tumashu commented Jan 5, 2019

@tumashu
Copy link
Contributor

tumashu commented Jan 5, 2019

@guoxiangyang emacs 的开发流程不是这样的, 对于偶尔的供献者,应该将你的更改 'git format-patch'
然后将 patch 发到 emacs-devel mailling list, 等待 emacs 的开发者评价,按照要求
更改,或者说明理由,等改的差不多后,emacs 的维护者就会将补丁合并到 master

另外:好像超过10行代码的更改,就需要签署 gpl 纸质协议,以前是这样,现在可能有
电子版的

@guoxiangyang
Copy link
Author

谢谢你的提醒,那样太麻烦了,本来就是顺手改一下.

flatwhatson pushed a commit to flatwhatson/emacs that referenced this pull request Nov 23, 2020
Remove pgtkconn, we no longer need it
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants