April 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Fix for supercite and the "emailname" attribute 25 years

Gregory Neil Shapiro

I've finally found time to track down a problem with supercite that has been plaguing me for a while. The "emailname" attribute was always returning the sender's first name instead of their username in the e-mail address. The problem is that sc-attribs-emailname calls sc-attribs-%＠-addresses which simply matches the first string which contains legal e-mail address characters. It uses the full sender string, e.g. "Gregory Neil Shapiro <gshapiro(a)sendmail.org>". In that case, the first string is "Gregory". This makes the "emailname" attribute useless as it is the same as "firstname". This is easily fixed by using sc-get-address to strip the comments from the e-mail address. The match string is now "gshapiro(a)sendmail.org" and sc-attribs-emailname properly returns "gshapiro". Below is a ChangeLog entry (for xemacs-patches) and a patch. Comments are welcome (maybe I don't understand what an email "terminus" is). 1999-04-01 Gregory Neil Shapiro <gshapiro(a)sendmail.org> * supercite.el (sc-attribs-chop-address): Use the e-mail address instead of the full sender string. This allows sc-attribs-emailname to return the first part of the e-mail address instead of the first name of the author if the sender string includes the authors name. *** supercite.el~orig Wed Dec 9 12:27:12 1998 --- supercite.el Thu Apr 1 23:05:01 1999 *************** *** 1185,1191 **** (midnames (reverse (cdr revnames))) (lastname (car revnames)) (initials (sc-attribs-strip-initials namelist)) ! (emailname (sc-attribs-emailname from)) (n 1) author middlenames) --- 1185,1192 ---- (midnames (reverse (cdr revnames))) (lastname (car revnames)) (initials (sc-attribs-strip-initials namelist)) ! (emailname (sc-attribs-emailname ! (sc-get-address from namestring))) (n 1) author middlenames)

1 participants
0 comments

XEmacs 21.0 binary-kits 25 years

Jason R Mastaler

SL Baur <steve(a)xemacs.org> writes: > > Do we do binary kits? > > Not yet. The plan is to continue the code/feature freeze with the > 21.1 series, except that each 21.1.x won't be considered, announced or > advertised as betas. There will be a 21.1.1 next weekend or shortly > thereafter. There will be a 21.1.2 about a week or so later, and so > forth. We need a new model of dealing with binary kits to take into > account frequent releases. My sentiments exactly. One way to think of the binary-kits is as a "go-ahead" from us to the user-base to switch to a particular release. Building good binary-kits takes time and patience and I think they should be made available only for rock-solid releases (such as 20.4). For releases in between there is always the source code for the more experienced users. For example, in between 21.0 and 21.1 we will have the chance to see how most people actually use the package system which will allow us to choose a better default for the binary-kits. I anticipate a full line of binary-kits for 21.1. Yes, I'd also like to work out a new methodology for binary-kits in the face of more frequent releases. I was bitten by the Mule bug at m17n99, so I'd like to continue the recent tradition of providing both Mule and non-Mule binary-kits for each platform. I'm also thinking of experimenting with a more automated method of building the binary-kits[1]. The current method of distributing a long, detailed README for builders to follow is too error prone. I end up having to hand-fix or reject many of the submissions because of omissions or mistakes. Anyway, I think this process could be improved. Please feel free to share your suggestions on these issues with myself or the list. Footnotes: 1. Such as how Apache does it: <http://dev.apache.org/binaries.html>

1 participants
0 comments

Re: Comparison between integer and character is constant nil (?2 and 0) 25 years

SL Baur

Karl Kleinpaste <karl(a)justresearch.com> writes in xemacs-beta(a)xemacs.org: > Hrvoje Niksic <hniksic(a)srce.hr> writes: >> Can't we just /debug/ those cases when they show up rather than >> flashing the warnings in my face > I disable the warning by adding "#if 0" to data.c every time I pick up > a fresh XEmacs beta, because every single article I display with Gnus > induces the warnings, apparently as a consequence of customizing > gnus-treat-date-lapsed to 'head. I see. > And yes, it's *really* annoying to get that mini backtrace on a tty, > which I use a lot. O.K. Would it be acceptable to you to make `ebola' be a type of error checking so you could disable it via configure? ie. --error-checking=all-but-ebola? or something like that?

2 participants
1 comments

I bow to the will of the intelligent 25 years

Colin Rafferty

Some people made some very strong arguments as to why newline-and-indet could really suck. I think that they are right in that it is more important to make things not suck than to make things cool. I will submit a patch to sample.emacs, as suggested. -- Colin

1 participants
0 comments

Re: Comparison between integer and character is constant nil (?2 and 0) 25 years

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org: ... > A better alternative yet would be to see if we can figure out what > "spurious" Ebola warnings look like and trap them. No can do. There are spurious Ebola warnings in the bytecompiler that can never be removed (they're suppressed by a special hack). Anything that looks something like (memq 3 '(?a ?b ?c 1 2 3)) is going to generate spurious Ebola warnings, yet the code is most likely correct.

1 participants
0 comments

Re: change \C-m binding to newline-and-indent 25 years

Colin Rafferty

Per Abrahamsen writes: > Colin Rafferty <craffert(a)ms.com> writes: >> Does anyone disagree? > Not today, there aren't. But maybe we should rebind `C-x', `C-c', and > `C-v' to `cut', `copy', and `paste' at the same time? I know that you are joking, but the difference is that I just want to enhance the functionality that users already are getting. I'm talking about a subtle change that enhances, the way that Oliver feels python-mode feels more natural. -- Colin

2 participants
1 comments

change \C-m binding to newline-and-indent 25 years

Colin Rafferty

This is a major change, so I thought it would be better to throw this out to the list, rather than just submitting a patch. For the last umpteen years, I have had the following two lines in .emacs: (global-set-key [(return)] 'newline-and-indent) (global-set-key [(linefeed)] 'newline) I cannot understand anyone who does not also have this. It does the right thing everywhere. In source buffers, it indents properly. In non-source buffers, it indents properly (i.e. not at all). Of all the people that I have shown this to, only one has not changed his bindings to match. There seems to me no reason why we should not make this the default. I imagine that somewhere in the dark past, there was no function `newline-and-indent', and that is why we still don't bind it to <return> by default. I propose that we make a change for the better. We should change one of the most used keys on the keyboard to a smarter and more functional binding. Does anyone disagree? -- Colin

6 participants
7 comments

Re: change \C-m binding to newline-and-indent 25 years

Dmitry Yaitskov

Didier Verna <verna(a)inf.enst.fr> wrote: > Colin Rafferty writes: > > Colin> (global-set-key [(return)] 'newline-and-indent) > > Oaow ... > > But sometimes, you _don't_ want to indent. In C, for instance, you > might want to make a few blank lines before the next line of code. And you > don't want them to be indented because otherwise, Martin is going to send a > mega-patch to correct this ;-) FWIW, in cc-mode on my system, repeatedly pressing return (which of course *is* bound to 'newline-and-indent) actually "indents" (as in "inserts tabs/spaces") only the last of a succession of blank lines. > Making people oblidged to use C-j instead of Return to simply go to > the next line is too much to ask, I think. OTOH, it may be said that making people use Ret *plus* Tab simply to do what 'newline-and-indent does is too much to ask :) -- Cheers, -Dima.

1 participants
0 comments

Re: change \C-m binding to newline-and-indent 25 years

Andrew Hobson

On 01 Apr 1999 10:31:25 -0500, Colin Rafferty <craffert(a)ms.com> said: > I propose that we make a change for the better. We should change one > of the most used keys on the keyboard to a smarter and more functional > binding. > Does anyone disagree? Please don't do this. IMHO, before changing a keybinding to do something different, you should be fixing something that's broken, not adding functionality that you think the user wants. IMHO, the right way to address this would be to improve the sample .emacs file and prominently refer to it in the documentation and splash screen. Drew -- "I would gladly give one hundred and fifty thousand dollars to have it proved there is no hell." -- Charteres

1 participants
0 comments

Re: change \C-m binding to newline-and-indent 25 years

Oliver Graf

Colin Rafferty <craffert(a)ms.com> writes: > Oliver Graf writes: > > Colin Rafferty <craffert(a)ms.com> writes: > > >> (global-set-key [(return)] 'newline-and-indent) > >> (global-set-key [(linefeed)] 'newline) > > > [In Python mode] ... I did not feel this behaviour as unnatural, so > > I think I like it. > > One person who won't complain. I'm glad to know that I'm not > completely insane. Or we are both ;-) > >> Does anyone disagree? > > > Nope. [but this may actually start a kind of delete/backspace discussion and > > may end in some theme -- the 'smart' theme ;-) -- or it ends on the custom > > group with all those options we can not decide on.] > > I don't think that this is the same as backspace/delete. The issue > the delete-key-deletes-forward haters had was that they didn't want > the "key above <enter>" to delete forwards on any keyboard. Just look at the discussion ;-) Regards, Oliver.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta April 1999