* proposal to make null string handling more emacs-y @ 2012-04-25 0:24 Steve Yegge 2012-04-25 4:45 ` Karl Fogel ` (5 more replies) 0 siblings, 6 replies; 59+ messages in thread From: Steve Yegge @ 2012-04-25 0:24 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 3178 bytes --] I haven't started a big flamewar and made fresh new enemies in what has to be at least three weeks. So. Here goes. I think we should change all the core string-manipulation functions to deal gracefully with nil arguments. Specifically, I want to change the smallest set of functions that may originate the infamous "wrong-type-argument (stringp, nil)" error, making them instead treat nil as if it were the empty string. By way of justification: * it's Lispy. Yes, most Lisp dialects got strings wrong, but that shouldn't stop us. Strings are just character sequences, and whether you like it or not, the nil/empty-list equivalence is part of Emacs's soul. Throwing an error on a nil string is a radical departure from the core philosophy. * wrong-type-argument (stringp, nil) is, anecdotally speaking, both the most common error encountered by casual users and the most feared, because it's incredibly difficult to debug. What's so hard about debugging it? It prevents Emacs from starting up! So your debugger, evaluator, etc. are all useless, and you're back to binary-partitioning of your .emacs file until you find the offending code. Setting debug-on-error works for more experienced users, *when* it works (which, combined with --debug-init is not very often). But even then, emacs stack traces are a poor-man's debugging tool at best. * changing the behavior is unlikely to break much code. Emacs libraries should already do nil-checking on string arguments. And nobody should be relying on error conditions for normal control flow, so no code should be depending on the string functions signaling this error. The second argument is the real reason I've come to believe we're doing it wrong. Emacs has amazingly powerful runtime debugging facilities. When Emacs is running, it's *_*alive_, and you can help newbies debug problems by sending them snippets of code to evaluate on the fly. If Emacs can't start up, or (worse) it gets into one of those horrid scenarios where some hook is throwing an error on almost every command and preventing the user from doing anything useful, then you're no longer in Emacs. You're in brokenville. All the advantages and pleasure of Emacs as a dev environment have vanished. In a way, I am arguing that Emacs is different from most other software, in that it is better for Emacs to fail silently and keep running than it is to fail noisily and prevent the user from doing any work. This is not by any means an argument you'd make about most software. But over twenty-five years of daily Emacs use, I've decided that throwing errors on nil strings -- however good the intentions may have been -- is doing more harm than good. Before you reject the idea out of hand, I'd like to ask that you consider carefully what behavior would be most consistent with the rest of Emacs, and would make best use of existing debugging and diagnostic facilities. Compared to lexical scoping, this change is pretty minor. ;-) -steve p.s. (string= nil "") would still yield nil, of course. I'm proposing that we treat nil as the empty string, not the other way around. [-- Attachment #2: Type: text/html, Size: 3907 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 0:24 proposal to make null string handling more emacs-y Steve Yegge @ 2012-04-25 4:45 ` Karl Fogel 2012-04-25 6:28 ` Miles Bader ` (4 subsequent siblings) 5 siblings, 0 replies; 59+ messages in thread From: Karl Fogel @ 2012-04-25 4:45 UTC (permalink / raw) To: Steve Yegge; +Cc: emacs-devel Steve Yegge <steve.yegge@gmail.com> writes: >Before you reject the idea out of hand, I'd like to ask that you >consider carefully >what behavior would be most consistent with the rest of Emacs, and >would make >best use of existing debugging and diagnostic facilities. > >Compared to lexical scoping, this change is pretty minor. ;-) > >-steve > >p.s. (string= nil "") would still yield nil, of course. I'm proposing >that we treat nil >as the empty string, not the other way around. Have you tried making the change in a dev tree and seeing what the first things to break are? I'm not sold on the idea anyway, I have to admit -- that "wrong-type" error has been a valuable source of early bug detection for me many times -- but the above seems like a worthwhile experiment for those who like the proposal and want to investigate it. -K ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 0:24 proposal to make null string handling more emacs-y Steve Yegge 2012-04-25 4:45 ` Karl Fogel @ 2012-04-25 6:28 ` Miles Bader 2012-04-25 6:34 ` Miles Bader 2012-04-25 13:21 ` Ted Zlatanov 2012-04-25 7:53 ` Helmut Eller ` (3 subsequent siblings) 5 siblings, 2 replies; 59+ messages in thread From: Miles Bader @ 2012-04-25 6:28 UTC (permalink / raw) To: Steve Yegge; +Cc: emacs-devel Steve Yegge <steve.yegge@gmail.com> writes: > * it's Lispy. Yes, most Lisp dialects got strings wrong, but that > shouldn't stop us. Strings are just character sequences, and whether > you like it or not, the nil/empty-list equivalence is part of Emacs's > soul. Throwing an error on a nil string is a radical departure from > the core philosophy. That's a pretty dubious claim... -miles -- A zen-buddhist walked into a pizza shop and said, "Make me one with everything." ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 6:28 ` Miles Bader @ 2012-04-25 6:34 ` Miles Bader 2012-04-25 13:21 ` Ted Zlatanov 1 sibling, 0 replies; 59+ messages in thread From: Miles Bader @ 2012-04-25 6:34 UTC (permalink / raw) To: Steve Yegge; +Cc: emacs-devel > * wrong-type-argument (stringp, nil) is, anecdotally speaking, both > the most common error encountered by casual users and the most feared, > because it's incredibly difficult to debug. What's so hard about > debugging it? It prevents Emacs from starting up! Come to think of it, _this_ is a pretty dubious claim too (or rather, it's a collection of dubious claims)... -miles -- `The suburb is an obsolete and contradictory form of human settlement' ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 6:28 ` Miles Bader 2012-04-25 6:34 ` Miles Bader @ 2012-04-25 13:21 ` Ted Zlatanov 2012-05-01 22:01 ` Randal L. Schwartz 1 sibling, 1 reply; 59+ messages in thread From: Ted Zlatanov @ 2012-04-25 13:21 UTC (permalink / raw) To: emacs-devel On Wed, 25 Apr 2012 15:28:59 +0900 Miles Bader <miles@gnu.org> wrote: MB> Steve Yegge <steve.yegge@gmail.com> writes: >> * it's Lispy. Yes, most Lisp dialects got strings wrong, but that >> shouldn't stop us. Strings are just character sequences, and whether >> you like it or not, the nil/empty-list equivalence is part of Emacs's >> soul. Throwing an error on a nil string is a radical departure from >> the core philosophy. MB> That's a pretty dubious claim... I see strings as a vector sequence, not a list sequence. Thus: (null (make-vector 0 "hello")) => nil (null (make-list 0 "hello")) => t So it makes sense to me that an empty string would be more like a 0-length vector. This is a painful area in Perl[1], which treats undef *and* several strings as equivalent in a boolean context. I think it would be painful in Emacs Lisp too. Ted [1] http://www.perlmonks.org/?node_id=862 and many others ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 13:21 ` Ted Zlatanov @ 2012-05-01 22:01 ` Randal L. Schwartz 0 siblings, 0 replies; 59+ messages in thread From: Randal L. Schwartz @ 2012-05-01 22:01 UTC (permalink / raw) To: emacs-devel >>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes: Ted> So it makes sense to me that an empty string would be more like a Ted> 0-length vector. This is a painful area in Perl[1], which treats undef Ted> *and* several strings as equivalent in a boolean context. I think it Ted> would be painful in Emacs Lisp too. Seconded. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 0:24 proposal to make null string handling more emacs-y Steve Yegge 2012-04-25 4:45 ` Karl Fogel 2012-04-25 6:28 ` Miles Bader @ 2012-04-25 7:53 ` Helmut Eller 2012-04-25 8:22 ` Eli Zaretskii ` (2 subsequent siblings) 5 siblings, 0 replies; 59+ messages in thread From: Helmut Eller @ 2012-04-25 7:53 UTC (permalink / raw) To: emacs-devel * Steve Yegge [2012-04-25 00:24] writes: > I haven't started a big flamewar and made fresh new enemies in what has > to be at least three weeks. So. Here goes. > > I think we should change all the core string-manipulation functions to deal > gracefully with nil arguments. Specifically, I want to change the smallest > set of functions that may originate the infamous "wrong-type-argument > (stringp, nil)" error, making them instead treat nil as if it were the empty > string. The smallest set of those functions seems to be the empty set (aka. nil or was it ""?). Helmut ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 0:24 proposal to make null string handling more emacs-y Steve Yegge ` (2 preceding siblings ...) 2012-04-25 7:53 ` Helmut Eller @ 2012-04-25 8:22 ` Eli Zaretskii 2012-04-25 14:28 ` Stefan Monnier 2012-04-25 14:51 ` Lars Magne Ingebrigtsen 2012-04-29 17:00 ` Andreas Röhler 5 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-04-25 8:22 UTC (permalink / raw) To: Steve Yegge; +Cc: emacs-devel > Date: Tue, 24 Apr 2012 17:24:57 -0700 > From: Steve Yegge <steve.yegge@gmail.com> > > I think we should change all the core string-manipulation functions to deal > gracefully with nil arguments. Specifically, I want to change the smallest > set of functions that may originate the infamous "wrong-type-argument > (stringp, nil)" error, making them instead treat nil as if it were the > empty string. I'm quite sure this will break gobs of existing code in Emacs. The entire display engine, for starters. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 8:22 ` Eli Zaretskii @ 2012-04-25 14:28 ` Stefan Monnier 2012-04-25 14:35 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-04-25 14:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Steve Yegge, emacs-devel >> I think we should change all the core string-manipulation functions to deal >> gracefully with nil arguments. Specifically, I want to change the smallest >> set of functions that may originate the infamous "wrong-type-argument >> (stringp, nil)" error, making them instead treat nil as if it were the >> empty string. Being a type zealot, I'm not sure I like this idea. This said, I'm not necessarily opposed to it. The argument that it's a super-common error and that it's always hard to debug doesn't convince me (I haven't noticed it to be significantly more frequent than other errors, nor that it's hard to debug). BTW, we shouldn't accept "hard to debug" as a fatality: we should try to make it easier. So I'd like to see an actual proposed patch for one, and some further arguments about why it would be a goo idea. > I'm quite sure this will break gobs of existing code in Emacs. The > entire display engine, for starters. I wonder what makes you think that would introduce lots of bugs, and why in the display engine. AFAICT this error is very rarely thrown, so turning it into some other behavior should have very little effect, if any. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 14:28 ` Stefan Monnier @ 2012-04-25 14:35 ` Eli Zaretskii 2012-04-25 15:30 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-04-25 14:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: steve.yegge, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Steve Yegge <steve.yegge@gmail.com>, emacs-devel@gnu.org > Date: Wed, 25 Apr 2012 10:28:05 -0400 > > > I'm quite sure this will break gobs of existing code in Emacs. The > > entire display engine, for starters. > > I wonder what makes you think that would introduce lots of bugs, > and why in the display engine. Code out there depends on nil being different from an empty string. In the display engine, if a string is nil, that's used as a flag. > AFAICT this error is very rarely thrown, so turning it into some other > behavior should have very little effect, if any. The suggestion, AFAIU, wasn't limited to error being thrown. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 14:35 ` Eli Zaretskii @ 2012-04-25 15:30 ` Stefan Monnier 2012-04-25 16:41 ` Miles Bader ` (3 more replies) 0 siblings, 4 replies; 59+ messages in thread From: Stefan Monnier @ 2012-04-25 15:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: steve.yegge, emacs-devel >> > I'm quite sure this will break gobs of existing code in Emacs. The >> > entire display engine, for starters. >> I wonder what makes you think that would introduce lots of bugs, >> and why in the display engine. > Code out there depends on nil being different from an empty string. > In the display engine, if a string is nil, that's used as a flag. AFAIK he's not suggesting to change that. He's only suggesting that instead of throwing an error some functions should behave as if they had received an empty string. E.g. like (concat "23" nil "45") does. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 15:30 ` Stefan Monnier @ 2012-04-25 16:41 ` Miles Bader 2012-04-25 16:45 ` Andreas Schwab ` (2 subsequent siblings) 3 siblings, 0 replies; 59+ messages in thread From: Miles Bader @ 2012-04-25 16:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, steve.yegge, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > AFAIK he's not suggesting to change that. He's only suggesting that > instead of throwing an error some functions should behave as if they had > received an empty string. E.g. like (concat "23" nil "45") does. Also kinda like the old "strlen (NULL) => 0" behavior (and generally, derefencing a pointer => 0)... Which was (1) sort of handy in some cases, and (2) really good at hiding bugs... -miles -- XML is like violence. If it doesn't solve your problem, you're not using enough of it. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 15:30 ` Stefan Monnier 2012-04-25 16:41 ` Miles Bader @ 2012-04-25 16:45 ` Andreas Schwab 2012-04-25 16:46 ` Juanma Barranquero 2012-04-26 21:20 ` Steve Yegge 3 siblings, 0 replies; 59+ messages in thread From: Andreas Schwab @ 2012-04-25 16:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, steve.yegge, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > E.g. like (concat "23" nil "45") does. That's not a good example since concat explicitly accepts lists as arguments. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 15:30 ` Stefan Monnier 2012-04-25 16:41 ` Miles Bader 2012-04-25 16:45 ` Andreas Schwab @ 2012-04-25 16:46 ` Juanma Barranquero 2012-04-26 21:20 ` Steve Yegge 3 siblings, 0 replies; 59+ messages in thread From: Juanma Barranquero @ 2012-04-25 16:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, steve.yegge, emacs-devel On Wed, Apr 25, 2012 at 17:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > He's only suggesting that > instead of throwing an error some functions should behave as if they had > received an empty string. E.g. like (concat "23" nil "45") does. Though, to be fair, `concat' is not special-casing anything. It's not behaving as if it had received an empty string, but an empty list: ELISP> (concat "ab" '(?x) "cd") "abxcd" ELISP> (concat "ab" '() "cd") "abcd" (Yes, I know you know it.) Juanma ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 15:30 ` Stefan Monnier ` (2 preceding siblings ...) 2012-04-25 16:46 ` Juanma Barranquero @ 2012-04-26 21:20 ` Steve Yegge 2012-04-26 22:11 ` Miles Bader 2012-04-27 1:10 ` Stefan Monnier 3 siblings, 2 replies; 59+ messages in thread From: Steve Yegge @ 2012-04-26 21:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel [-- Attachment #1: Type: text/plain, Size: 758 bytes --] If the general change is too risky, I think there are still a few functions that would benefit from being able to accept nils on a case-by-case basis. Examples: looking-at, string-match, search-forward-* string-to-list, string-to-vector, (maybe) string-to-number auto-save-file-name-p, backup-file-name-p directory-file-name, expand-file-name, file-name-as-directory and their ilk (all of which handle "" gracefully) rename-file, copy-file, delete-file ("no such file/dir" being more informative than "wrong type argument" here) write-file (prompts on empty string; might as well prompt on nil) There's a lot of code out there that's forced to do type assertions on string args that could be simplified if these common functions could accept nils. -steve [-- Attachment #2: Type: text/html, Size: 1264 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-26 21:20 ` Steve Yegge @ 2012-04-26 22:11 ` Miles Bader 2012-04-26 23:52 ` Steve Yegge 2012-04-27 1:10 ` Stefan Monnier 1 sibling, 1 reply; 59+ messages in thread From: Miles Bader @ 2012-04-26 22:11 UTC (permalink / raw) To: Steve Yegge; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel Steve Yegge <steve.yegge@gmail.com> writes: > There's a lot of code out there that's forced to do type assertions on > string args that could be simplified if these common functions could > accept nils. Maybe. But I think such changes must be justified on a case-by-case basis, with convincing use-cases ("in this very common situation, a nil naturally turns up where a string was expected"). Type-checking catches a lot of bugs, even in "loose" languages like lisp and end-user-targeted languages like elisp -- and I think the trend is generally towards _stricter_ checking and less fuzziness, even in scripting languages. -miles -- Egotist, n. A person of low taste, more interested in himself than in me. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-26 22:11 ` Miles Bader @ 2012-04-26 23:52 ` Steve Yegge 2012-04-27 0:29 ` Miles Bader 0 siblings, 1 reply; 59+ messages in thread From: Steve Yegge @ 2012-04-26 23:52 UTC (permalink / raw) To: Miles Bader; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1634 bytes --] On Thu, Apr 26, 2012 at 3:11 PM, Miles Bader <miles@gnu.org> wrote: > Steve Yegge <steve.yegge@gmail.com> writes: > > There's a lot of code out there that's forced to do type assertions on > > string args that could be simplified if these common functions could > > accept nils. > > Maybe. But I think such changes must be justified on a case-by-case > basis, with convincing use-cases ("in this very common situation, a nil > naturally turns up where a string was expected"). > For some of them this might be justified. For others, I see no point in failing to deal with nil values. There is nothing to be gained, and the downside is that some user is sitting there unable to start Emacs because two required packages -- packages that may be used only on demand or not at all -- are arguing over some runtime value. That's a big downside. > Type-checking catches a lot of bugs, even in "loose" languages like lisp > and end-user-targeted languages like elisp -- and I think the trend is > generally towards _stricter_ checking and less fuzziness, even in > scripting languages. It's a big stretch to call the Emacs equivalent of a Java NullPointerException "type checking". A very big stretch. NPEs are notorious for happening too late to be useful. By the time they happen, the root cause is often long gone, produced by something not on the current call stack. Preventing Emacs startup because of a sudden unexpected interaction in package dependencies does not seem like the right way for a text editor to work. -steve > -miles > > -- > Egotist, n. A person of low taste, more interested in himself than in me. > [-- Attachment #2: Type: text/html, Size: 2562 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-26 23:52 ` Steve Yegge @ 2012-04-27 0:29 ` Miles Bader 2012-04-27 3:20 ` Jeremiah Dodds 0 siblings, 1 reply; 59+ messages in thread From: Miles Bader @ 2012-04-27 0:29 UTC (permalink / raw) To: Steve Yegge; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel Steve Yegge <steve.yegge@gmail.com> writes: >> Maybe. But I think such changes must be justified on a case-by-case >> basis, with convincing use-cases ("in this very common situation, a nil >> naturally turns up where a string was expected"). > > For some of them this might be justified. For others, I see no point in > failing to deal with nil values. Signalling an error _is_ "dealing with nil values" (and very often the correct way). Anyway, I think the onus is on you to show that relaxing error-checking is justified. > There is nothing to be gained Clearly there is: less buggy code. > and the downside is that some user is sitting there unable to start > Emacs because two required packages -- packages that may be used only > on demand or not at all -- are arguing over some runtime value. > That's a big downside. WTF do you keep going on about Emacs startup? If Emacs is dealing poorly with errors during startup -- of which nil-when-a-string-was-expected is just one not particularly noteworthy example -- then Emacs' handling of errors during startup needs to be made robust. Just papering over the problem by ignoring bugs simply means Emacs will be more buggy. That hurts users. >> Type-checking catches a lot of bugs, even in "loose" languages like >> lisp and end-user-targeted languages like elisp -- and I think the >> trend is generally towards _stricter_ checking and less fuzziness, >> even in scripting languages. > > It's a big stretch to call the Emacs equivalent of a Java > NullPointerException "type checking". A very big stretch. Use whatever terminology you like. It doesn't change the issues. -miles -- Any man who is a triangle, has thee right, when in Cartesian Space, to have angles, which when summed, come to know more, nor no less, than nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 0:29 ` Miles Bader @ 2012-04-27 3:20 ` Jeremiah Dodds 2012-04-27 3:41 ` Miles Bader 2012-04-27 16:35 ` proposal to make null string handling more emacs-y Richard Stallman 0 siblings, 2 replies; 59+ messages in thread From: Jeremiah Dodds @ 2012-04-27 3:20 UTC (permalink / raw) To: emacs-devel Miles Bader <miles@gnu.org> writes: > Steve Yegge <steve.yegge@gmail.com> writes: >> and the downside is that some user is sitting there unable to start >> Emacs because two required packages -- packages that may be used only >> on demand or not at all -- are arguing over some runtime value. >> That's a big downside. > > WTF do you keep going on about Emacs startup? I believe this is because it seems that the "uh-oh i got a nil when I expected a string" error commonly happens on emacs startup, confusing new users, presumably after loading some big bunch of elisp. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 3:20 ` Jeremiah Dodds @ 2012-04-27 3:41 ` Miles Bader 2012-04-27 3:59 ` Jeremiah Dodds 2012-04-27 16:35 ` proposal to make null string handling more emacs-y Richard Stallman 1 sibling, 1 reply; 59+ messages in thread From: Miles Bader @ 2012-04-27 3:41 UTC (permalink / raw) To: Jeremiah Dodds; +Cc: emacs-devel Jeremiah Dodds <jeremiah.dodds@gmail.com> writes: >>> and the downside is that some user is sitting there unable to start >>> Emacs because two required packages -- packages that may be used only >>> on demand or not at all -- are arguing over some runtime value. >>> That's a big downside. >> >> WTF do you keep going on about Emacs startup? > > I believe this is because it seems that the "uh-oh i got a nil when I > expected a string" error commonly happens on emacs startup, confusing > new users, presumably after loading some big bunch of elisp. Does it? I don't think I've _ever_ seen that error at startup (though I've certainly had errors during startup)... -miles -- Cynic, n. A blackguard whose faulty vision sees things as they are, not as they ought to be. Hence the custom among the Scythians of plucking out a cynic's eyes to improve his vision. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 3:41 ` Miles Bader @ 2012-04-27 3:59 ` Jeremiah Dodds 2012-04-27 4:24 ` Miles Bader 0 siblings, 1 reply; 59+ messages in thread From: Jeremiah Dodds @ 2012-04-27 3:59 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel Miles Bader <miles@gnu.org> writes: > Jeremiah Dodds <jeremiah.dodds@gmail.com> writes: >>>> and the downside is that some user is sitting there unable to start >>>> Emacs because two required packages -- packages that may be used only >>>> on demand or not at all -- are arguing over some runtime value. >>>> That's a big downside. >>> >>> WTF do you keep going on about Emacs startup? >> >> I believe this is because it seems that the "uh-oh i got a nil when I >> expected a string" error commonly happens on emacs startup, confusing >> new users, presumably after loading some big bunch of elisp. > > Does it? I don't think I've _ever_ seen that error at startup (though > I've certainly had errors during startup)... > > -miles It's happened to me enough times over the course of the decade or so that I've been using emacs to remember it. I know that the first few times it happened, I was pretty green and got really confused for a while. Nowadays, I know how to figure out wtf is going on. Unfortunately I don't remember the specifics of what triggered the error for any of the times I ran into the issue. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 3:59 ` Jeremiah Dodds @ 2012-04-27 4:24 ` Miles Bader 2012-04-27 8:49 ` Thien-Thi Nguyen ` (2 more replies) 0 siblings, 3 replies; 59+ messages in thread From: Miles Bader @ 2012-04-27 4:24 UTC (permalink / raw) To: Jeremiah Dodds; +Cc: emacs-devel Jeremiah Dodds <jeremiah.dodds@gmail.com> writes: >>> I believe this is because it seems that the "uh-oh i got a nil when I >>> expected a string" error commonly happens on emacs startup, confusing >>> new users, presumably after loading some big bunch of elisp. >> >> Does it? I don't think I've _ever_ seen that error at startup (though >> I've certainly had errors during startup)... > > It's happened to me enough times over the course of the decade or so > that I've been using emacs to remember it. I know that the first few > times it happened, I was pretty green and got really confused for a > while. Nowadays, I know how to figure out wtf is going on. Startup is typically a particularly intense period of elisp execution in a short period of time, so it's not surprising if errors are more noticeable there, and particularly annoying, because they often leave Emacs in an uncertain state. But: (1) This particular type of error (nil when string expected) is just as, or even more, likely to occur over the rest of Emacs' execution. (2) Many other types of errors (whether bugs or transient errors because of e.g. environmental issues or something [can't open some file, network down, ...]) can occur during startup So there doesn't really seem to be all that much correlation between what Steve was complaining about and startup. To the extent his complaint is valid, it's a general issue, not a "startup issue." Moreover, if Emacs is clumsy at handling errors during startup (and I agree that it is), that's a problem that should be addressed generally in the startup mechanism, not by bandaids on only vaguely related areas. In other words, these these things look largely orthogonal. [If this particular bandaid were harmless maybe it should be added anyway, as a stop-gap to a more proper solution -- but it isn't harmless, at least when applied generally; in certain cases, it may be, of course.] -Miles -- `Life is a boundless sea of bitterness' ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 4:24 ` Miles Bader @ 2012-04-27 8:49 ` Thien-Thi Nguyen 2012-04-27 14:23 ` Nix 2012-04-28 2:07 ` Better startup error handling (was: proposal to make null string handling more emacs-y) Stefan Monnier 2 siblings, 0 replies; 59+ messages in thread From: Thien-Thi Nguyen @ 2012-04-27 8:49 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2376 bytes --] () Miles Bader <miles@gnu.org> () Fri, 27 Apr 2012 13:24:05 +0900 To the extent his complaint is valid, it's a general issue, not a "startup issue." Moreover, if Emacs is clumsy at handling errors during startup (and I agree that it is), that's a problem that should be addressed generally in the startup mechanism, not by bandaids on only vaguely related areas. In other words, these these things look largely orthogonal. [If this particular bandaid were harmless maybe it should be added anyway, as a stop-gap to a more proper solution -- but it isn't harmless, at least when applied generally; in certain cases, it may be, of course.] I have always longed for ‘load-in-progress’ to be, instead of a simple boolean, a counter of top-level forms (from a particular file/buffer). This light-weight mechanism could speed debugging by providing more specific information: ok: An error occurred while loading `/home/ttn/.emacs': better: An error occurred while loading `/home/ttn/.emacs' (Nth form): This could be used by the ‘--debug-init’ machinery, as well. On second thought (after glancing at lread.c ‘readevalloop’), even more direct would be simply to record the "position of the current top-level form". From *Backtrace* (invoking with ‘--debug-init’), evaluating expression: (with-current-buffer " *load*" (point)) yields related information, the "position just past the current top-level form", so i suppose everything can be done in Lisp, by providing: (with-current-buffer " *load*" (save-excursion (forward-sexp -1) (point))) in some non-expert-friendly way, after which, we can banish the laconic "bisect ~/.emacs" to the /second/ advised step (when the user realizes that it is not the current top-level form or its progeny that is the Real Problem, but some bad interaction between those and the other loosely-included cargo-cult copy-pasta). :-/ But hey, one step at a time... [To reproduce the above observations, create file /tmp/bad with contents "zorg", and add ‘(load-file "/tmp/bad")’ somewhere in ~/.emacs (or other init file).] Hmm, i just noticed that *Backtrace* now (as of 2005-07-10) displays the "just past" position for all frames, so i suppose to boil down this long post into something constructive, how about: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: debug.el.diff --] [-- Type: text/x-diff, Size: 2493 bytes --] lisp/emacs-lisp/debug.el | 24 ++++++++++++++++++++---- 1 files changed, 20 insertions(+), 4 deletions(-) diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el index b0813ae..bda05ac 100644 *** a/lisp/emacs-lisp/debug.el --- b/lisp/emacs-lisp/debug.el *************** *** 333,351 **** (cdr debugger-args) debugger-args) (current-buffer)) (insert ?\n))) ! ;; After any frame that uses eval-buffer, ;; insert a line that states the buffer position it's reading at. (save-excursion ! (let ((tem eval-buffer-list)) (while (and tem (re-search-forward "^ eval-\\(buffer\\|region\\)(" nil t)) (end-of-line) ! (insert (format " ; Reading at buffer position %d" ;; This will get the wrong result ;; if there are two nested eval-region calls ;; for the same buffer. That's not a very useful case. (with-current-buffer (car tem) ! (point)))) (pop tem)))) (debugger-make-xrefs)) --- 333,367 ---- (cdr debugger-args) debugger-args) (current-buffer)) (insert ?\n))) ! ;; After any frame that uses eval-buffer, for `read'-related error, ;; insert a line that states the buffer position it's reading at. + ;; For other errors, state the buffer position of the offending form. (save-excursion ! (let ((tem eval-buffer-list) ! (read-related-error-p ! (and ! ;; A `read'-related error, if any, is always singular and innermost. ! (eq 'error (car debugger-args)) ! (memq (car (cadr debugger-args)) ! ;; This is from grep xsignal1 lread.c -- is that OK? ! '(end-of-file ! invalid-read-syntax ! overflow-error))))) (while (and tem (re-search-forward "^ eval-\\(buffer\\|region\\)(" nil t)) (end-of-line) ! (insert (format " ; Reading%s at buffer position %d" ! (if read-related-error-p "" " form") ;; This will get the wrong result ;; if there are two nested eval-region calls ;; for the same buffer. That's not a very useful case. (with-current-buffer (car tem) ! (if read-related-error-p ! (point) ! (save-excursion ! (forward-sexp -1) ! (point)))))) ! (setq read-related-error-p nil) (pop tem)))) (debugger-make-xrefs)) [-- Attachment #3: Type: text/plain, Size: 173 bytes --] This distinguishes between ‘read’-related and other errors, but i'm unsure if the way of discernment is correct. (Too, it could be reworked to use ‘pcase’...) ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 4:24 ` Miles Bader 2012-04-27 8:49 ` Thien-Thi Nguyen @ 2012-04-27 14:23 ` Nix 2012-04-28 2:07 ` Better startup error handling (was: proposal to make null string handling more emacs-y) Stefan Monnier 2 siblings, 0 replies; 59+ messages in thread From: Nix @ 2012-04-27 14:23 UTC (permalink / raw) To: Miles Bader; +Cc: Jeremiah Dodds, emacs-devel On 27 Apr 2012, Miles Bader uttered the following: > (1) This particular type of error (nil when string expected) is just > as, or even more, likely to occur over the rest of Emacs' > execution. FWIW I saw this error very recently. It turned out to be a magit bug that could I believe have potentially caused data loss, so I'm very glad it was diagnosed so I could fix it -- even if it *was* annoying at first to have to debug this with a crippled (i.e. -Q) emacs. -- NULL && (void) ^ permalink raw reply [flat|nested] 59+ messages in thread
* Better startup error handling (was: proposal to make null string handling more emacs-y) 2012-04-27 4:24 ` Miles Bader 2012-04-27 8:49 ` Thien-Thi Nguyen 2012-04-27 14:23 ` Nix @ 2012-04-28 2:07 ` Stefan Monnier 2012-04-28 12:04 ` Better startup error handling Nix ` (2 more replies) 2 siblings, 3 replies; 59+ messages in thread From: Stefan Monnier @ 2012-04-28 2:07 UTC (permalink / raw) To: Miles Bader; +Cc: Jeremiah Dodds, emacs-devel > Moreover, if Emacs is clumsy at handling errors during startup (and I > agree that it is), that's a problem that should be addressed generally If someone wants to attack this, I'm all ears. The way I see it, we should ideally be able to load the .emacs in such a way that an error doesn't prevent the rest of the file from being loaded, and the error should be clearly signaled to the user with some kind of line-number information. In my wildest dreams I also imagine that we'd check for obsolete vars, hooks, and functions. Maybe even give the same kind of feedback that the byte-compiler gives about the code. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Better startup error handling 2012-04-28 2:07 ` Better startup error handling (was: proposal to make null string handling more emacs-y) Stefan Monnier @ 2012-04-28 12:04 ` Nix 2012-04-28 15:16 ` Stefan Monnier 2012-04-28 17:26 ` Lars Magne Ingebrigtsen 2012-04-30 8:43 ` Christian Lynbech 2 siblings, 1 reply; 59+ messages in thread From: Nix @ 2012-04-28 12:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel, Jeremiah Dodds, Miles Bader On 28 Apr 2012, Stefan Monnier spake thusly: > The way I see it, we should ideally be able to load the .emacs in such > a way that an error doesn't prevent the rest of the file from being > loaded, and the error should be clearly signaled to the user with some > kind of line-number information. Yes. This presumably means some sort of evaluator hook to execute some code between each toplevel form, or wrap each top-level form in a condition-case -- reader macros would I think handle it, but elisp doesn't have those. > In my wildest dreams I also imagine that we'd check for obsolete vars, > hooks, and functions. Maybe even give the same kind of feedback that > the byte-compiler gives about the code. Can't you do that trivially by loading .emacs into a temporary buffer in default.el, then byte-compiling it and throwing the results away? (In default.el because that way it picks up changes to the byte-compiler configuration that you may have made in .emacs.) Downsides: loads the byte-compiler even in sessions that don't need it, and notably inefficient. -- NULL && (void) ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Better startup error handling 2012-04-28 12:04 ` Better startup error handling Nix @ 2012-04-28 15:16 ` Stefan Monnier 2012-04-28 15:42 ` David Engster 2012-04-28 15:55 ` Drew Adams 0 siblings, 2 replies; 59+ messages in thread From: Stefan Monnier @ 2012-04-28 15:16 UTC (permalink / raw) To: Nix; +Cc: emacs-devel, Jeremiah Dodds, Miles Bader >> The way I see it, we should ideally be able to load the .emacs in such >> a way that an error doesn't prevent the rest of the file from being >> loaded, and the error should be clearly signaled to the user with some >> kind of line-number information. > Yes. This presumably means some sort of evaluator hook to execute some > code between each toplevel form, or wrap each top-level form in a > condition-case -- reader macros would I think handle it, but elisp > doesn't have those. Another way to do it is to not use `load' but to find-file .emacs and then eval-region chunk by chunk. >> In my wildest dreams I also imagine that we'd check for obsolete vars, >> hooks, and functions. Maybe even give the same kind of feedback that >> the byte-compiler gives about the code. > Can't you do that trivially by loading .emacs into a temporary buffer in > default.el, then byte-compiling it and throwing the results away? > (In default.el because that way it picks up changes to the byte-compiler > configuration that you may have made in .emacs.) Kind of. > Downsides: loads the byte-compiler even in sessions that don't need it, > and notably inefficient. Exactly: in theory it's straightforward, but doing it well will require more work. IIRC there are some other issues such as the fact that .emacs code tends to be very different from typical code in Elisp packages, and the kinds of things we want to flag aren't all the same (some things are acceptable/normal/unavoidable in one but not in the other). Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Better startup error handling 2012-04-28 15:16 ` Stefan Monnier @ 2012-04-28 15:42 ` David Engster 2012-04-28 15:55 ` Drew Adams 1 sibling, 0 replies; 59+ messages in thread From: David Engster @ 2012-04-28 15:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: Nix, Miles Bader, Jeremiah Dodds, emacs-devel Stefan Monnier writes: >>> The way I see it, we should ideally be able to load the .emacs in such >>> a way that an error doesn't prevent the rest of the file from being >>> loaded, and the error should be clearly signaled to the user with some >>> kind of line-number information. >> Yes. This presumably means some sort of evaluator hook to execute some >> code between each toplevel form, or wrap each top-level form in a >> condition-case -- reader macros would I think handle it, but elisp >> doesn't have those. > > Another way to do it is to not use `load' but to find-file .emacs and > then eval-region chunk by chunk. FWIW, I've written this for creating profiles of the init file: http://www.emacswiki.org/emacs/ProfileDotEmacs -David ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: Better startup error handling 2012-04-28 15:16 ` Stefan Monnier 2012-04-28 15:42 ` David Engster @ 2012-04-28 15:55 ` Drew Adams 2012-04-28 19:39 ` Stefan Monnier 1 sibling, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-04-28 15:55 UTC (permalink / raw) To: 'Stefan Monnier', 'Nix' Cc: 'Miles Bader', 'Jeremiah Dodds', emacs-devel > > Downsides: loads the byte-compiler even in sessions that > > don't need it, and notably inefficient. > > Exactly: in theory it's straightforward, but doing it well > will require more work. IIRC there are some other issues such as > the fact that .emacs code tends to be very different from typical > code in Elisp packages, and the kinds of things we want to flag > aren't all the same (some things are acceptable/normal/unavoidable > in one but not in the other). No flames please, but I have a different objection to this idea. Perhaps you hinted at in in your last sentence - not sure. Anyhooo... .emacs is something that many non-Lisper users use. Sometimes they load 3rd-party libraries from it. Sometimes they include 3rd-party snippets directly in it. Whether that makes sense in general or for any given library or snippet is beside the point here. It is done, and rather often, I believe. Some such libraries or snippets are designed to work with more than one Emacs version. As such, it can be the case that some of the byte-compiler warnings, e.g. function calls with the wrong number of args or functions not known to be defined, are not relevant in the end. The byte compiler is just not smart enough to get everything right, and understandably so. That is, some such warnings might be relevant and helpful to some users and are probably so to developers of the libraries or snippets included, but they are not necessarily relevant to some other users. And those are the users whom we are most worried about wrt the thread Subject line. They are the users who are least likely to know what to do when they run into a startup problem etc. And - and this is important in my experience - some users do not understand, or misunderstand, when then see such warnings. Warnings can even frighten people when they are not understood. I've gotten more than one question or bug report which I replied to by reassuring the user that some such warning is not really relevant in the current situation etc. I'm probably not alone in that. In sum, my objection is that we will be throwing warnings at users who will not necessarily understand them and will not necessarily need to see them anyway. And yes, I do think this is potentially a big problem, for both users and the developers of code they use. Throwing byte-compiler warnings at users to handle or prevent startup problems is the wrong cure, IMHO - really wrong. The byte compiler for any given Emacs version is what it is. It can be helpful but it is certainly not perfect. And in particular it is not always on target when it comes to code that has to work with different Emacs versions. This problem tends to get worse as the byte compiler gets more helpful (almost put that word in quotes ;-)), more verbose, more finnicky. Systematically applying the byte compiler to user .emacs files sounds like a colossally misguided idea, to me. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Better startup error handling 2012-04-28 15:55 ` Drew Adams @ 2012-04-28 19:39 ` Stefan Monnier 0 siblings, 0 replies; 59+ messages in thread From: Stefan Monnier @ 2012-04-28 19:39 UTC (permalink / raw) To: Drew Adams Cc: 'Nix', 'Miles Bader', 'Jeremiah Dodds', emacs-devel >> > Downsides: loads the byte-compiler even in sessions that >> > don't need it, and notably inefficient. >> Exactly: in theory it's straightforward, but doing it well >> will require more work. IIRC there are some other issues such as >> the fact that .emacs code tends to be very different from typical >> code in Elisp packages, and the kinds of things we want to flag >> aren't all the same (some things are acceptable/normal/unavoidable >> in one but not in the other). > No flames please, but I have a different objection to this idea. > Perhaps you hinted at in in your last sentence - not sure. Anyhooo... I largely agree, and that's indeed some of the issues I was hinting at. Rather than try to detect errors (such as wrong-number of args) which will/would be detected at run-time anyway, the purpose would be to detect use of obsolete/deprecated vars/functions/functionality. But as you mention, such warnings should be kept sufficiently discreet since a user may elect to keep "old" code if she uses the same .emacs with various versions/flavors of emacs. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Better startup error handling 2012-04-28 2:07 ` Better startup error handling (was: proposal to make null string handling more emacs-y) Stefan Monnier 2012-04-28 12:04 ` Better startup error handling Nix @ 2012-04-28 17:26 ` Lars Magne Ingebrigtsen 2012-04-30 8:43 ` Christian Lynbech 2 siblings, 0 replies; 59+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-04-28 17:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > The way I see it, we should ideally be able to load the .emacs in such > a way that an error doesn't prevent the rest of the file from being > loaded, and the error should be clearly signaled to the user with some > kind of line-number information. Yeah, that's a very good idea. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Better startup error handling 2012-04-28 2:07 ` Better startup error handling (was: proposal to make null string handling more emacs-y) Stefan Monnier 2012-04-28 12:04 ` Better startup error handling Nix 2012-04-28 17:26 ` Lars Magne Ingebrigtsen @ 2012-04-30 8:43 ` Christian Lynbech 2012-04-30 9:18 ` chad 2 siblings, 1 reply; 59+ messages in thread From: Christian Lynbech @ 2012-04-30 8:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel, Jeremiah Dodds, Miles Bader >>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Moreover, if Emacs is clumsy at handling errors during startup (and I >> agree that it is), that's a problem that should be addressed generally Stefan> If someone wants to attack this, I'm all ears. One suggestion that at least would help me a lot debugging problems during startup would be if emacs maintained some sort of stack of files being loaded. In other words, whenever an exception happens, there would be a way to see that not only did evaluation halt during such-and-such form but it happened during the load of file B that was loaded from file A that was in turn loaded from .emacs. In most cases, the actual error that halts the startup provides very little info by itself and it is almost always something that happens in one of the many libraries that I load during startup. Moreover, frequently the library is not really at fault but I am doing something (or fail to do something) that is (no longer) valid for my usage of the library. My .emacs is big enough that I have split it into a number of files so when I have problems, I must normally first evaluate .emacs form by form to find the next level culprit, then repeat the form-by-form evaluation of that to find which library to investigate. If I had some form of loading stack, I would know immediately. Obviously, there is tradeoff between newbie usability and guru info provided. It would be fine by me that such debugging info was not showed into the face of an innocent user but still was available to the knowledgeable. If we even could save some information about both error and the evaluation stack leading up to it, such that one was not forced to start over with some fancy option to get usable feedback, it would be double good. I these modern times, a lot of people do not start emacs from the commandline and thus may even have issues knowing how to do that. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Better startup error handling 2012-04-30 8:43 ` Christian Lynbech @ 2012-04-30 9:18 ` chad 0 siblings, 0 replies; 59+ messages in thread From: chad @ 2012-04-30 9:18 UTC (permalink / raw) To: Christian Lynbech; +Cc: Emacs developers [-- Attachment #1: Type: text/plain, Size: 387 bytes --] On Apr 30, 2012, at 1:43 AM, Christian Lynbech wrote: > > Obviously, there is tradeoff between newbie usability and guru info > provided. As a practical matter, don't most gurus set debug-on-error 't early in .emacs anyway? If not, I'd be curious as to why - that's been the first line of my .emacs more or less forever, and I thought it was common practice. *Chad [-- Attachment #2: Type: text/html, Size: 734 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 3:20 ` Jeremiah Dodds 2012-04-27 3:41 ` Miles Bader @ 2012-04-27 16:35 ` Richard Stallman 1 sibling, 0 replies; 59+ messages in thread From: Richard Stallman @ 2012-04-27 16:35 UTC (permalink / raw) To: Jeremiah Dodds; +Cc: emacs-devel I believe this is because it seems that the "uh-oh i got a nil when I expected a string" error commonly happens on emacs startup, confusing new users, presumably after loading some big bunch of elisp. This sort of error -- at startup or not -- is a sign of a real bug, a variable not properly set up. Making string functions not signal errors would paper it over, which does not mean things would work correctly. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-26 21:20 ` Steve Yegge 2012-04-26 22:11 ` Miles Bader @ 2012-04-27 1:10 ` Stefan Monnier 2012-04-27 1:16 ` Lars Magne Ingebrigtsen 2012-04-27 4:17 ` Steve Yegge 1 sibling, 2 replies; 59+ messages in thread From: Stefan Monnier @ 2012-04-27 1:10 UTC (permalink / raw) To: Steve Yegge; +Cc: Eli Zaretskii, emacs-devel > There's a lot of code out there that's forced to do type assertions on > string args that could be simplified if these common functions could > accept nils. I can believe that (it's often handy to use "nil-in-nil-out" when composing functions which may return nil). But there's also the risk that you hide real errors, leading to weird behaviors that are more difficult to track down. E.g. one package uses some other package's var before it's initialized, so with the current semantics you might get a clean error, whereas with your proposed semantics you might get some weird behavior where the user says why doesn't bar find my thingy even though C-h v foo-var tells me it's set to "/some/path"? -- Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 1:10 ` Stefan Monnier @ 2012-04-27 1:16 ` Lars Magne Ingebrigtsen 2012-04-27 16:35 ` Richard Stallman 2012-04-27 4:17 ` Steve Yegge 1 sibling, 1 reply; 59+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-04-27 1:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, Steve Yegge, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > I can believe that (it's often handy to use "nil-in-nil-out" when > composing functions which may return nil). But there's also the risk > that you hide real errors, leading to weird behaviors that are more > difficult to track down. I see allowing more nil values in string-ey functions as a very Lisp-ey thing to do. I'm really really happy that Emacs Lisp isn't Scheme-like. Stuff like (assq 'foo bar) ⇒ #f would just drive me totally batty. Battier. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 1:16 ` Lars Magne Ingebrigtsen @ 2012-04-27 16:35 ` Richard Stallman 2012-04-28 11:13 ` Eli Barzilay 0 siblings, 1 reply; 59+ messages in thread From: Richard Stallman @ 2012-04-27 16:35 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: eliz, steve.yegge, monnier, emacs-devel I'm really really happy that Emacs Lisp isn't Scheme-like. Stuff like (assq 'foo bar) ⇒ #f would just drive me totally batty. I think splitting apart the different meanings of nil in Lisp was an unfortunate mistake in Scheme. This sort of cleanliness is only desirable theoretically, not in practice. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 16:35 ` Richard Stallman @ 2012-04-28 11:13 ` Eli Barzilay 2012-04-28 17:02 ` Richard Stallman 0 siblings, 1 reply; 59+ messages in thread From: Eli Barzilay @ 2012-04-28 11:13 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > > I'm really really happy that Emacs Lisp isn't Scheme-like. Stuff like > > (assq 'foo bar) ⇒ #f > > would just drive me totally batty. > > I think splitting apart the different meanings of nil in Lisp was an > unfortunate mistake in Scheme. This sort of cleanliness is only > desirable theoretically, not in practice. As a (semi-fake) "Schemer", I can say that it's perfectly fine in practice too. It catches real errors. In analogy to what you wrote a few seconds later -- it catches errors that would otherwise get papered over. There's obviously a subjective line here, where Elisp and Scheme are going in different directions, and IIUC, Steve's point is that "" =~ nil is continuing in the same direction that elisp already went to. (But of course the question is how far you're willing to go, otherwise you end up with "wat".) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-28 11:13 ` Eli Barzilay @ 2012-04-28 17:02 ` Richard Stallman 2012-04-28 19:48 ` Stefan Monnier 2012-04-28 21:56 ` Eli Barzilay 0 siblings, 2 replies; 59+ messages in thread From: Richard Stallman @ 2012-04-28 17:02 UTC (permalink / raw) To: Eli Barzilay; +Cc: emacs-devel As a (semi-fake) "Schemer", I can say that it's perfectly fine in practice too. It catches real errors. In analogy to what you wrote a few seconds later -- it catches errors that would otherwise get papered over. The benefit of making () and false the same in Lisp is NOT a matter of suppressing errors. The benefit is that we can simplify programs by knowing that () and false are the same. If these cases happen in Scheme, they are errors. However, in Lisp it is very convenient that the empty list also represents false. Equating () and "" might perhaps give some benefit of simplifying programs. You could try looking for places where you could take advantage of that, to see how much convenience it gives. But this is a different matter from avoiding errors. I tend to think the benefit won't be big, but you can try to show I'm wrong. I am not sure there is any benefit to the fact that () is the same as (intern "nil"). -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-28 17:02 ` Richard Stallman @ 2012-04-28 19:48 ` Stefan Monnier 2012-04-28 21:56 ` Eli Barzilay 1 sibling, 0 replies; 59+ messages in thread From: Stefan Monnier @ 2012-04-28 19:48 UTC (permalink / raw) To: rms; +Cc: Eli Barzilay, emacs-devel > I am not sure there is any benefit to the fact that () is the same as > (intern "nil"). Indeed, it's actually something I dislike about Elisp (whereas I found the ()=false to be really handy, just like the 0=NULL= false in C). I've never found it to be useful, and it can be really inconvenient when you need to distinguish "a symbol" from "just the nil value". Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-28 17:02 ` Richard Stallman 2012-04-28 19:48 ` Stefan Monnier @ 2012-04-28 21:56 ` Eli Barzilay 2012-06-03 3:45 ` Richard Stallman 1 sibling, 1 reply; 59+ messages in thread From: Eli Barzilay @ 2012-04-28 21:56 UTC (permalink / raw) To: rms; +Cc: emacs-devel Four hours ago, Richard Stallman wrote: > As a (semi-fake) "Schemer", I can say that it's perfectly fine in > practice too. It catches real errors. In analogy to what you wrote a > few seconds later -- it catches errors that would otherwise get > papered over. > > The benefit of making () and false the same in Lisp is NOT a matter > of suppressing errors. Sure it is. (null? (< 1 2)) makes no semantic sense, and you get an error. In other lisps, (null (< 1 2)) makes no sense but instead of an error you get a convention of preferring `not'. The error that Scheme throws is suppressed, but using `null' like that is likely to be an error. (BTW, Scheme itself is doing the same when it treats any non-#f value as true. CLers would also argue that Scheme is also doing it when it treats identifiers in function positions the same as elsewhere.) > The benefit is that we can simplify programs by knowing that () and > false are the same. Right, and you get more of these benefits if it's also the same as "" and as 0, and there are additional benefits in the same direction: allow using `nil' as a function (that returns `nil' when called), allow adding numbers, strings, lists, etc with implicit coercions, maybe allow using numbers and lists as functions (as in arc), and allow referring to undefined variables and calling undefined functions. Each of these simplifies (and shortens) existing code, since they each encapsulate common code pattern. But each of these suppresses more bugs since more defective code runs to completion, returning bogus results instead of throwing an error. (I'm talking about defective in the sense of diverging from what the code should do, not in a technical execution sense where they're no longer bugs.) Note in particular that all of these are directly contributing to Steve's proposal: they lead to less frustraing errors, since more code will run without exceptions, implicitly doing something that likely should be done in today's elisp. Note also his reference to running code in a browser, where JS is a language that is very intentionally doing its best to continue running, with modern browsers going farther by not even showing most people errors. Arguing that some of these things are better or worse is wrong. It doesn't make sense to reject unifying "" and `nil' on one hand and reject separating false and '() on the other -- *unless* it's clear that it's a subjective decision. They are very clearly tradeoffs of convenience vs robustness. So the argument is not "scheme is wrong to distinguish false from nil, elisp is right to distinguish the empty string from nil". Instead, it should be an argument about the decision that most elispers do, and finding the right place on the line. > Equating () and "" might perhaps give some benefit of simplifying > programs. You could try looking for places where you could take > advantage of that, to see how much convenience it gives. But this > is a different matter from avoiding errors. (Avoiding errors is what started this thread...) > I tend to think the benefit won't be big, but you can try to show > I'm wrong. (I'm making a meta point about the argument, I don't have any preference for either side.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-28 21:56 ` Eli Barzilay @ 2012-06-03 3:45 ` Richard Stallman 0 siblings, 0 replies; 59+ messages in thread From: Richard Stallman @ 2012-06-03 3:45 UTC (permalink / raw) To: Eli Barzilay; +Cc: emacs-devel > The benefit of making () and false the same in Lisp is NOT a matter > of suppressing errors. Sure it is. (null? (< 1 2)) makes no semantic sense, and you get an error. In other lisps, (null (< 1 2)) makes no sense It does make sense. The distinction made in Scheme between nil and false does not exist. `null' and `not' are equivalent; it is not a matter of using one meaning a fallback for another. That () and false are the same object is a feature. > The benefit is that we can simplify programs by knowing that () and > false are the same. Right, and you get more of these benefits if it's also the same as "" and as 0, and there are additional benefits in the same direction: allow using `nil' as a function (that returns `nil' when called), allow adding numbers, strings, lists, etc with implicit coercions, maybe allow using numbers and lists as functions (as in arc), and allow referring to undefined variables and calling undefined functions. This idea is not ridiculous, but I am not convinced the benefits are worth the cost. Putting these changes in Emacs Lisp (as opposed to some new system) could lead to bad incompatibility problems. I am pretty sure there are things that depend on the fact that "" and nil are different objects. To get much benefit from nil = 0, I think we would need t = 1. Arguing that some of these things are better or worse is wrong. It doesn't make sense to reject unifying "" and `nil' on one hand and reject separating false and '() on the other -- *unless* it's clear that it's a subjective decision. Both of these decisions are a matter of comparing advantages. The advantages to be compared are different in the two cases, so there is no reason to think they should be decided alike. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 1:10 ` Stefan Monnier 2012-04-27 1:16 ` Lars Magne Ingebrigtsen @ 2012-04-27 4:17 ` Steve Yegge 2012-04-27 6:36 ` Eli Zaretskii 2012-04-28 2:02 ` proposal to make null string handling more emacs-y Stefan Monnier 1 sibling, 2 replies; 59+ messages in thread From: Steve Yegge @ 2012-04-27 4:17 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel [-- Attachment #1: Type: text/plain, Size: 4366 bytes --] On Thu, Apr 26, 2012 at 6:10 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote: > > There's a lot of code out there that's forced to do type assertions on > > string args that could be simplified if these common functions could > > accept nils. > > I can believe that (it's often handy to use "nil-in-nil-out" when > composing functions which may return nil). Indeed! > But there's also the risk > that you hide real errors, leading to weird behaviors that are more > difficult to track down. > Yes, this is a risk. However, it's happening right now, as we speak, all the time. When stuff works strangely, users find workarounds, and/or ask developer lists to help them diagnose it. When stuff doesn't work at all -- which is what happens when Emacs starts throwing runtime errors -- then it's a lot harder for end-users to find workarounds. So it seems to me that we are optimizing for our own convenience rather than that of end users. > E.g. one package uses some other package's var before it's initialized, > so with the current semantics you might get a clean error, whereas with > your proposed semantics you might get some weird behavior where the user > says > > why doesn't bar find my thingy even though C-h v foo-var tells me it's > set to "/some/path"? > I think we need to be really careful here. We're talking about these errors as if they are type assertions in the classic type-theoretic sense, and we are pointing at the well-documented benefits of early type warnings as a justification for leaving the errors in place. But type errors are for *developers*. They are supposed to happen at compile time. When you're running the byte compiler or the unit tests, you want it to fail loudly and early. But when you ship the software, and it's in the hands of end-users who may not be able to debug it, then unless it's running a nuclear reactor or an airplane, you want the software to be robust. Your browser shouldn't crash because of a misbehaved site; your web page shouldn't fail to load because of a misbehaved widget; your CAD program shouldn't stop functioning because of a misbehaved polygon. Yes, the resulting bug will be annoying, but it's far less annoying than having your work interrupted altogether. With that in mind, I'm really wondering what the big fear is here. As I said, I'm willing to concede that the generalized nil-always-acts-like-"" solution may be too risky or too intrusive. But for the list of specific functions that I followed up with, I think that for many of them it's quite natural to assume that they'd take nils. Here are examples of functions that already take nil as a string argument: (string< nil "") => nil (string= nil "") => nil (concat "a" nil "b") => "ab" (yes, it's "effectively" taking nil, but it's convenient!) (string-to-sequence nil 'vector) => [] (string-to-list nil) => nil I don't see any of these creating world-ending bugs, contrary to predictions. Similarly, I see a whole bunch of file-name manipulation functions that accept the empty string as an argument. But the empty string has no semantic meaning whatsoever as a valid filename. Without any semantic meaning, it's arguably a bug to pass one in. Yet someone came up with arbitrary definitions for all all these functions should handle an empty path. Let's suppose -- bear with me here -- that long ago a mechanism had been introduced into Emacs to prevent passing the empty string ("") to file-name manipulation functions, because it's not a valid path on any system. So all file-name functions would throw an "invalid path" argument when passed the empty string. And let's say I came along and proposed that we ought to accept the empty string for both user and programmer convenience, as it is clearly possible to give it reasonable semantics for the entire set of file-name functions. In this hypothetical (yet quite similar) scenario, I can guarantee you that people would be up in arms about how type assertions -- in this case, the assertion that the path is well-formed by virtue of being nonempty -- can help find all sorts of errors that might otherwise go undetected. And there would be dire predictions about introducing difficult-to-diagnose bugs. C'mon... we all know this is what would happen. But the empty strings are just fine. And the nils will be too. I promise! =) -steve [-- Attachment #2: Type: text/html, Size: 6003 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 4:17 ` Steve Yegge @ 2012-04-27 6:36 ` Eli Zaretskii 2012-04-27 19:05 ` Steve Yegge 2012-04-28 2:02 ` proposal to make null string handling more emacs-y Stefan Monnier 1 sibling, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-04-27 6:36 UTC (permalink / raw) To: Steve Yegge; +Cc: monnier, emacs-devel > Date: Thu, 26 Apr 2012 21:17:36 -0700 > From: Steve Yegge <steve.yegge@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > But type errors are for *developers*. They are supposed to happen at > compile time. When you're running the byte compiler or the unit tests, you > want it to fail loudly and early. This is Lisp, not C++ or even Java. Some Lisp code is never compiled at all. A notable example is the code you put in .emacs. > But when you ship the software, and it's in the hands of end-users > who may not be able to debug it, then unless it's running a nuclear > reactor or an airplane, you want the software to be robust. Your > browser shouldn't crash because of a misbehaved site; your web page > shouldn't fail to load because of a misbehaved widget; your CAD > program shouldn't stop functioning because of a misbehaved polygon. > Yes, the resulting bug will be annoying, but it's far less annoying > than having your work interrupted altogether. I don't think you can have an interpreted language without runtime exceptions. In Lisp, if you want robust programs, you need to catch exceptions and do something reasonable. Asking to avoid exceptions altogether is IMO impractical. > Similarly, I see a whole bunch of file-name manipulation functions that > accept the empty string as an argument. But the empty string has no > semantic meaning whatsoever as a valid filename. Without any semantic > meaning, it's arguably a bug to pass one in. The usual Emacs semantics for an empty file name is that it stands for the current directory. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 6:36 ` Eli Zaretskii @ 2012-04-27 19:05 ` Steve Yegge 2012-04-27 21:24 ` Drew Adams 2012-04-29 21:26 ` Odd formatting (was: proposal to make null string handling more emacs-y) Lars Magne Ingebrigtsen 0 siblings, 2 replies; 59+ messages in thread From: Steve Yegge @ 2012-04-27 19:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 2153 bytes --] On Thu, Apr 26, 2012 at 11:36 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > Date: Thu, 26 Apr 2012 21:17:36 -0700 > > From: Steve Yegge <steve.yegge@gmail.com> > > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > > > But type errors are for *developers*. They are supposed to happen at > > compile time. When you're running the byte compiler or the unit tests, > you > > want it to fail loudly and early. > > This is Lisp, not C++ or even Java. Some Lisp code is never compiled > at all. A notable example is the code you put in .emacs. Perhaps we need a strict mode, then. > > But when you ship the software, and it's in the hands of end-users > > who may not be able to debug it, then unless it's running a nuclear > > reactor or an airplane, you want the software to be robust. Your > > browser shouldn't crash because of a misbehaved site; your web page > > shouldn't fail to load because of a misbehaved widget; your CAD > > program shouldn't stop functioning because of a misbehaved polygon. > > Yes, the resulting bug will be annoying, but it's far less annoying > > than having your work interrupted altogether. > > I don't think you can have an interpreted language without runtime > exceptions. In Lisp, if you want robust programs, you need to catch > exceptions and do something reasonable. Asking to avoid exceptions > altogether is IMO impractical. > I agree with you. Fortunately that's not what I'm arguing. I'm arguing that for a very specific corner of the type system, we merge two separate meanings of nil. I'm arguing that the empty string as it is used today is, for all intents, just another nil. So it should not signal an error if they are treated the same. > > Similarly, I see a whole bunch of file-name manipulation functions that > > accept the empty string as an argument. But the empty string has no > > semantic meaning whatsoever as a valid filename. Without any semantic > > meaning, it's arguably a bug to pass one in. > > The usual Emacs semantics for an empty file name is that it stands for > the current directory. > That sounds like a wonderful semantics for a nil filename. -steve [-- Attachment #2: Type: text/html, Size: 3192 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: proposal to make null string handling more emacs-y 2012-04-27 19:05 ` Steve Yegge @ 2012-04-27 21:24 ` Drew Adams 2012-04-28 4:43 ` Steve Yegge 2012-04-29 21:26 ` Odd formatting (was: proposal to make null string handling more emacs-y) Lars Magne Ingebrigtsen 1 sibling, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-04-27 21:24 UTC (permalink / raw) To: 'Steve Yegge', 'Eli Zaretskii'; +Cc: monnier, emacs-devel > I've decided that throwing errors on nil strings -- however > good the intentions may have been -- is doing more harm than good. ... > I'm arguing that for a very specific corner of the type system, > we merge two separate meanings of nil. I'm arguing that the > empty string as it is used today is, for all intents, just > another nil. So it should not signal an error if they are > treated the same. Just because "" and () are similar in some ways does not mean that they should be treated as identical in general - any more than [] and () should be. "For all intents, just another nil" can apply to a lot of things, including 0 for whole numbers. Should we conclude also that throwing errors on nil numbers, like "nil strings", does more harm than good? No, you didn't make so general an argument - good. You limited it to "all the core string-manipulation functions" (not very clear to me), and even more specifically to "the smallest set of [core?] functions that may originate the infamous `wrong-type-argument (stringp, nil)' error". But that still quite general appeal wrt string type errors ("Throwing an error on a nil string is a radical departure from the core philosophy.") was countered by pointing out that sometimes it is TRT to raise such an error. And you yourself said in the same breath that "Emacs libraries should already do nil-checking on string arguments." Surely they do, and in some cases they raise an error as a consequence, and in some cases the only possible or the most appropriate error is the one being decried. As long as we discuss this at such a general level your argument will not go far, I'm afraid. So you say even more narrowly that there is a well-defined class of cases - a "corner" where you feel that "" and () should be equated and raising an error is wrong. I fear that even this more constrained hand-waving is still unlikely to cut the mustard, but if you nail it down clearly then maybe you can progress with it. If you are convinced that your argument is truly more general than what can be dealt with case by case, and you can accurately identify the "very specific corner of the type system" that merits such a change, then, by all means, identify it rigorously and give supporting arguments. IOW, be specific about your very specific corner. Specify the problem and its boundaries. Barring that, I'd add my voice to the advice already given by others: handle any particular functions that you feel ought to treat "" and () the same, but do not yet do so, on a case-by-case basis. Start with a specific function where you think it is bad design to distinguish "" from () and to raise an error when () is encountered but "" was expected (i.e., acceptable). For that function, point to a specific problem - e.g. a startup problem, since you refer to that. IOW2, give specific arguments for each such function as to why it should equate "" and (). IOW3, identify the specific problems you've run into - file a bug, for instance. You are much more likely to have others see your light if you are specific and clear. In fact, if you had started with a specific bug report, it's quite possible that others would themselves have made the same leap to your "corner", assuming it is well-defined. Finally, you say that the "real reason" for your quest is that if such an error is raised at startup then a newbie's goose is nuked. For that, I'm afraid, the replique given already is the right one: recipe please. It sounds like you or someone you know has stumbled on a bug that needs fixing. And that, I think, is the place to start. It is, after all, the real problem behind your real reason. FWIW, I am sympathetic to the problem you describe. I even filed a (non-specific, no-recipe, not-very-useful) bug report a while back that could perhaps be a poster child for the "worse" scenario you cite: "If Emacs can't start up, or (worse) it gets into one of those horrid scenarios where some hook is throwing an error on almost every command and preventing the user from doing anything useful, then you're no longer in Emacs. You're in brokenville. All the advantages and pleasure of Emacs as a dev environment have vanished." http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11105 And yes, debugging that one (in particular, but perhaps it is not really so particular) is not so simple. But the good news is that I see this particular behavior _only_ in Emacs 24, which is not yet released. So your argument about developers vs users, even in the narrow sense in which it might sometimes be appropriate, does not really apply here. The better news will be when the bug can be found and fixed. But so far at least I'm not convinced that your proposal is the right way to deal with this case. I'd sooner see it found and fixed than finessed. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 21:24 ` Drew Adams @ 2012-04-28 4:43 ` Steve Yegge 2012-04-28 6:58 ` Andreas Schwab 0 siblings, 1 reply; 59+ messages in thread From: Steve Yegge @ 2012-04-28 4:43 UTC (permalink / raw) To: Drew Adams; +Cc: Eli Zaretskii, monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 7904 bytes --] This is nicely argued. I've made the mistake of failing to record any information when I've encountered this specific error category that's been plaguing me. We've got ~4000 Emacs users at Google, and there is a core group of 20 or 30 folks who act as tech support for the rest. We've got a big net trolling along the bottom of the ocean, and we catch all sorts of unpleasant stuff, but we're just throwing it back rather than keeping records. So I don't have a bunch of bug repro cases, nor specific code that would have been cleaner had the lower-level functions accepted nil. The most recent occurrence is relatively fresh: I was observing some annoying behavior in a Google elisp library -- one that had been doing some path manipulation and choking on nil because, for whatever reason, `temporary-file-directory' had been bound to nil. So I fixed up the Google function to handle nil the same way it handles the empty string. And I glanced around and noticed that the same hack had been applied all over the place, sometimes smoothed over with macros or what have you. It was a lot of smoothing over what appears to be a core wrinkle. That said, it was just one example, and I have not kept good records -- in part because most Googlers are still on emacs 23, and I haven't wanted to file bugs until I can verify them in emacs24, which is more time than I've had to allot to it. I'm on emacs 24 now, and I'll be dutiful about it, but it's going to be another year or two at least before I'm able to respond to the demands for specific examples. But even then it seems unlikely that I'll report the majority of them, because once people start asking for hundreds of case-by-case justifications, the battle is lost. That's why I tried arguing it from the general case on the first go-round. But no matter. It was a thought experiment. I've planted a seed, and maybe in the coming years people will start evaluating any occurrences they may encounter of errors on nil-valued string args. In time we may have a corpus of evidence one way or the other. If not, I'll eventually have a pile of examples as I begin keeping better records. In the meantime, I very much like Stefan's argument to the effect that patches speak louder than words. I'll patch my local copy and start playing with it. I also like his observation that nil-in-nil-out aids function composition. Unfortunately, given that most of the arguments in this thread are focused on type assertions, it's unlikely that jumping on that bandwagon will turn the tide. In the shorter term, I hope to be able to get some concrete bug reports around emacs 24 startup behavior and/or library-loading behavior over the next few months, now that more of us are using it. -steve On Fri, Apr 27, 2012 at 2:24 PM, Drew Adams <drew.adams@oracle.com> wrote: > > I've decided that throwing errors on nil strings -- however > > good the intentions may have been -- is doing more harm than good. > ... > > I'm arguing that for a very specific corner of the type system, > > we merge two separate meanings of nil. I'm arguing that the > > empty string as it is used today is, for all intents, just > > another nil. So it should not signal an error if they are > > treated the same. > > Just because "" and () are similar in some ways does not mean that they > should > be treated as identical in general - any more than [] and () should be. > "For > all intents, just another nil" can apply to a lot of things, including 0 > for > whole numbers. Should we conclude also that throwing errors on nil > numbers, > like "nil strings", does more harm than good? > > No, you didn't make so general an argument - good. > > You limited it to "all the core string-manipulation functions" (not very > clear > to me), and even more specifically to "the smallest set of [core?] > functions > that may originate the infamous `wrong-type-argument (stringp, nil)' > error". > > But that still quite general appeal wrt string type errors ("Throwing an > error > on a nil string is a radical departure from the core philosophy.") was > countered > by pointing out that sometimes it is TRT to raise such an error. > > And you yourself said in the same breath that "Emacs libraries should > already do > nil-checking on string arguments." Surely they do, and in some cases they > raise > an error as a consequence, and in some cases the only possible or the most > appropriate error is the one being decried. > > As long as we discuss this at such a general level your argument will not > go > far, I'm afraid. > > So you say even more narrowly that there is a well-defined class of cases > - a > "corner" where you feel that "" and () should be equated and raising an > error is > wrong. I fear that even this more constrained hand-waving is still > unlikely to > cut the mustard, but if you nail it down clearly then maybe you can > progress > with it. > > If you are convinced that your argument is truly more general than what > can be > dealt with case by case, and you can accurately identify the "very specific > corner of the type system" that merits such a change, then, by all means, > identify it rigorously and give supporting arguments. > > IOW, be specific about your very specific corner. Specify the problem and > its > boundaries. > > Barring that, I'd add my voice to the advice already given by others: > handle any > particular functions that you feel ought to treat "" and () the same, but > do not > yet do so, on a case-by-case basis. > > Start with a specific function where you think it is bad design to > distinguish > "" from () and to raise an error when () is encountered but "" was expected > (i.e., acceptable). For that function, point to a specific problem - e.g. > a > startup problem, since you refer to that. > > IOW2, give specific arguments for each such function as to why it should > equate > "" and (). IOW3, identify the specific problems you've run into - file a > bug, > for instance. > > You are much more likely to have others see your light if you are specific > and > clear. In fact, if you had started with a specific bug report, it's quite > possible that others would themselves have made the same leap to your > "corner", > assuming it is well-defined. > > Finally, you say that the "real reason" for your quest is that if such an > error > is raised at startup then a newbie's goose is nuked. For that, I'm > afraid, the > replique given already is the right one: recipe please. It sounds like > you or > someone you know has stumbled on a bug that needs fixing. And that, I > think, is > the place to start. It is, after all, the real problem behind your real > reason. > > FWIW, I am sympathetic to the problem you describe. I even filed a > (non-specific, no-recipe, not-very-useful) bug report a while back that > could > perhaps be a poster child for the "worse" scenario you cite: > > "If Emacs can't start up, or (worse) it gets into one of > those horrid scenarios where some hook is throwing an error > on almost every command and preventing the user from doing > anything useful, then you're no longer in Emacs. You're in > brokenville. All the advantages and pleasure of Emacs as a > dev environment have vanished." > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11105 > > And yes, debugging that one (in particular, but perhaps it is not really so > particular) is not so simple. > > But the good news is that I see this particular behavior _only_ in Emacs > 24, > which is not yet released. So your argument about developers vs users, > even in > the narrow sense in which it might sometimes be appropriate, does not > really > apply here. > > The better news will be when the bug can be found and fixed. But so far at > least I'm not convinced that your proposal is the right way to deal with > this > case. I'd sooner see it found and fixed than finessed. > > [-- Attachment #2: Type: text/html, Size: 10346 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-28 4:43 ` Steve Yegge @ 2012-04-28 6:58 ` Andreas Schwab 0 siblings, 0 replies; 59+ messages in thread From: Andreas Schwab @ 2012-04-28 6:58 UTC (permalink / raw) To: Steve Yegge; +Cc: Eli Zaretskii, monnier, Drew Adams, emacs-devel Steve Yegge <steve.yegge@gmail.com> writes: > The most recent occurrence is relatively fresh: I was observing some > annoying > behavior in a Google elisp library -- one that had been doing some path > manipulation > and choking on nil because, for whatever reason, `temporary-file-directory' > had > been bound to nil. So I fixed up the Google function to handle nil the > same way > it handles the empty string. And I glanced around and noticed that the same > hack had been applied all over the place, sometimes smoothed over with > macros > or what have you. It was a lot of smoothing over what appears to be a core > wrinkle. I see many places that check if temporary-file-directory is bound at all, but none that special cases a value of nil. This is just to support Emacs before 20.3 where the variable didn't exist yet. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 59+ messages in thread
* Odd formatting (was: proposal to make null string handling more emacs-y) 2012-04-27 19:05 ` Steve Yegge 2012-04-27 21:24 ` Drew Adams @ 2012-04-29 21:26 ` Lars Magne Ingebrigtsen 2012-04-30 7:48 ` Odd formatting Steinar Bang 1 sibling, 1 reply; 59+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-04-29 21:26 UTC (permalink / raw) To: Steve Yegge; +Cc: ding, emacs-devel Steve Yegge <steve.yegge@gmail.com> writes: > I agree with you. Fortunately that's not what I'm arguing. I'm arguing > that > for a very specific corner of the type system, we merge two separate > meanings of nil. I'm arguing that the empty string as it is used today > is, > for all intents, just another nil. So it should not signal an error if > they are > treated the same. Totally off topic, I was looking at how strange your messages are rendering and wondering whether the mail reader was interpreting your messages incorrectly or something. But here's the (sort of) raw source of that text: <div>I agree with you. Fortunately that's not what I'm arguing. I'm arguing that</div><div>for a very specific corner of the type system, we merge two separate</div> <div>meanings of nil. I'm arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div> (This is the text/html part of the multipart message you send.) So your mail reader is wrapping (apparently) random parts of the text in <div> section, and <div> section are rendered by shr.el as a block-level elements (which is quite normal, I think). You're posting through Gmail, so I expect to see a lot more of this kind of stuff in the future. Does anybody know why Gmail is doing this, and what shr should be doing to this, er, stuff to render it properly? I can't see any hints in the source of the message that these <div>s are supposed to be non-block-level elements, but perhaps I'm missing something... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Odd formatting 2012-04-29 21:26 ` Odd formatting (was: proposal to make null string handling more emacs-y) Lars Magne Ingebrigtsen @ 2012-04-30 7:48 ` Steinar Bang 2012-04-30 10:14 ` Antoine Levitt 0 siblings, 1 reply; 59+ messages in thread From: Steinar Bang @ 2012-04-30 7:48 UTC (permalink / raw) To: emacs-devel; +Cc: ding >>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>: > Totally off topic, I was looking at how strange your messages are > rendering and wondering whether the mail reader was interpreting your > messages incorrectly or something. But here's the (sort of) raw source > of that text: > <div>I agree with you. Fortunately that's not what I'm arguing. I'm arguing that</div><div>for a very specific corner of the type system, we merge two separate</div> > <div>meanings of nil. I'm arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div> > (This is the text/html part of the multipart message you send.) Note that the text/plain version of the message is foramatted exactly like the bit you quoted. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Odd formatting 2012-04-30 7:48 ` Odd formatting Steinar Bang @ 2012-04-30 10:14 ` Antoine Levitt 2012-04-30 13:27 ` Nix 0 siblings, 1 reply; 59+ messages in thread From: Antoine Levitt @ 2012-04-30 10:14 UTC (permalink / raw) To: emacs-devel; +Cc: ding 30/04/12 09:48, Steinar Bang >>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>: > >> Totally off topic, I was looking at how strange your messages are >> rendering and wondering whether the mail reader was interpreting your >> messages incorrectly or something. But here's the (sort of) raw source >> of that text: > >> <div>I agree with you. Fortunately that's not what I'm arguing. I'm arguing that</div><div>for a very specific corner of the type system, we merge two separate</div> >> <div>meanings of nil. I'm arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div> > >> (This is the text/html part of the multipart message you send.) > > Note that the text/plain version of the message is foramatted exactly > like the bit you quoted. Looks like he's writing his email in emacs, with emacs wrapping, and then pasting it into gmail, which then adds further (and different) wrapping. Not much gnus can do, I think. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: Odd formatting 2012-04-30 10:14 ` Antoine Levitt @ 2012-04-30 13:27 ` Nix 0 siblings, 0 replies; 59+ messages in thread From: Nix @ 2012-04-30 13:27 UTC (permalink / raw) To: emacs-devel On 30 Apr 2012, Antoine Levitt uttered the following: > 30/04/12 09:48, Steinar Bang >>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>: >> >>> Totally off topic, I was looking at how strange your messages are >>> rendering and wondering whether the mail reader was interpreting your >>> messages incorrectly or something. But here's the (sort of) raw source >>> of that text: >> >>> <div>I agree with you. Fortunately that's not what I'm arguing. I'm arguing that</div><div>for a very specific corner of the type system, we merge two separate</div> >>> <div>meanings of nil. I'm arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div> >> >>> (This is the text/html part of the multipart message you send.) >> >> Note that the text/plain version of the message is foramatted exactly >> like the bit you quoted. > > Looks like he's writing his email in emacs, with emacs wrapping, and > then pasting it into gmail, which then adds further (and different) > wrapping. Not much gnus can do, I think. Yeah. I suspect the Emacs wrapping is considered hard returns, and gmail is adding further soft returns on top of that, and then expressing each hard return as a <div>. Solution, "don't do that then", since I doubt there is a way to turn off wrapping in gmail or to get it to stop treating each explicitly-entered RET as a <div>. -- NULL && (void) ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-27 4:17 ` Steve Yegge 2012-04-27 6:36 ` Eli Zaretskii @ 2012-04-28 2:02 ` Stefan Monnier 1 sibling, 0 replies; 59+ messages in thread From: Stefan Monnier @ 2012-04-28 2:02 UTC (permalink / raw) To: Steve Yegge; +Cc: Eli Zaretskii, emacs-devel > compile time. When you're running the byte compiler or the unit tests, you > want it to fail loudly and early. But when you ship the software, and it's > in the hands of end-users who may not be able to debug it, then unless > it's running a nuclear reactor or an airplane, you want the software to be > robust. Most of the time throwing an `error' doesn't prevent the user from getting his job done. E.g. it doesn't "crash" Emacs. And while the user may not be able to debug it himself, he is able to get a backtrace and send it to us, whereas with a more permissive semantics, you don't get anything, so fixing the problem will require more interactions with the user. IOW, I think the problem is when an error makes Emacs unusable, and we should focus on this (which is typically an issue that's not dependent on the kind of error signaled, but the context where it's signaled). > With that in mind, I'm really wondering what the big fear is here. I have no big fear about your proposal. I expect it won't make much difference. > I don't see any of these creating world-ending bugs, contrary to > predictions. I don't expect any change you suggested would bring a significant number of bugs. The only downside I mention is that it might hide some bugs (which would have existed regardless of that change) and make them more difficult to track down and fix. Of course, maybe it will also fix some bugs. And maybe it will also allow us to simplify some Lisp code. I general I like the idea of treating lists and vectors uniformly, and strings are one particular kind of vector. But Emacs is a conservative system, so changes have to go slow. Send us a patch that covers the most obviously beneficial cases (ideally with some code cleanup made possible by the new semantics), Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 0:24 proposal to make null string handling more emacs-y Steve Yegge ` (3 preceding siblings ...) 2012-04-25 8:22 ` Eli Zaretskii @ 2012-04-25 14:51 ` Lars Magne Ingebrigtsen 2012-04-29 17:00 ` Andreas Röhler 5 siblings, 0 replies; 59+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-04-25 14:51 UTC (permalink / raw) To: Steve Yegge; +Cc: emacs-devel Steve Yegge <steve.yegge@gmail.com> writes: > I think we should change all the core string-manipulation functions to > deal gracefully with nil arguments. I think it's an intriguing idea. Let's look at some not-quite-real bits of code. We get a string from a map, and then, if it exists, we want to insert it twice, capitalised. Because `capitalize' bugs out on a nil parameter, this is how we do it today: (let ((foo (plist-get map 'foo))) (when foo (setq foo (capitalize foo)) (insert foo) ... (insert foo))) The "problem" here being the dreaded `setq'. For reading comprehension, its nice to not mutate variables. If we instead allowed `capitalize' to take a nil parameter, we'd have the more readable (let ((foo (capitalize (plist-get map 'foo)))) (when foo (insert foo) ... (insert foo))) And we can get away with a much more functional style if we allowed `insert' to take nil as a parameter (meaning "insert nothing"): (insert (capitalize (plist-get map 'foo))) instead of (let ((foo (plist-get map 'foo))) (when foo (insert (capitalize foo)))) I also often see code like (well, the equivalent of) (let ((foo (capitalize (or (plist-get map 'foo) "")))) ...) to avoid all the checking and `setq'-ing, but this makes the code less clear, and you end up with nonsensical tests like `(zerop (length foo))' later in the code if you really need to check whether you had a `foo' there anyway. I don't really see much of a downside to allowing (many) stringey functions to take nil as a parameter. And there's an upside. So why not? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-25 0:24 proposal to make null string handling more emacs-y Steve Yegge ` (4 preceding siblings ...) 2012-04-25 14:51 ` Lars Magne Ingebrigtsen @ 2012-04-29 17:00 ` Andreas Röhler 2012-04-29 17:08 ` Drew Adams 5 siblings, 1 reply; 59+ messages in thread From: Andreas Röhler @ 2012-04-29 17:00 UTC (permalink / raw) To: Steve Yegge; +Cc: Emacs developers Am 25.04.2012 02:24, schrieb Steve Yegge: > (string= nil "") what's strange for me in context: (if "" (message "%s" "empty string proved true") (message "%s" "empty string proved false")) ==> "empty string proved true" Andreas ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: proposal to make null string handling more emacs-y 2012-04-29 17:00 ` Andreas Röhler @ 2012-04-29 17:08 ` Drew Adams 2012-04-29 17:29 ` Andreas Röhler 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-04-29 17:08 UTC (permalink / raw) To: 'Andreas Röhler', 'Steve Yegge' Cc: 'Emacs developers' > > (string= nil "") > > (if "" > (message "%s" "empty string proved true") > (message "%s" "empty string proved false")) > ==> "empty string proved true" "" is not equal or eq or eql to nil. But "" is string= to nil. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-29 17:08 ` Drew Adams @ 2012-04-29 17:29 ` Andreas Röhler 2012-04-29 18:01 ` Drew Adams 2012-04-29 19:51 ` PJ Weisberg 0 siblings, 2 replies; 59+ messages in thread From: Andreas Röhler @ 2012-04-29 17:29 UTC (permalink / raw) To: Drew Adams; +Cc: 'Steve Yegge', 'Emacs developers' Am 29.04.2012 19:08, schrieb Drew Adams: >>> (string= nil "") >> >> (if "" >> (message "%s" "empty string proved true") >> (message "%s" "empty string proved false")) >> ==> "empty string proved true" > > "" is not equal or eq or eql to nil. > But "" is string= to nil. > > in other words said: if the empty list is nil, why the empty string should yield true? for me (equal nil "")==> t would be plausible ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: proposal to make null string handling more emacs-y 2012-04-29 17:29 ` Andreas Röhler @ 2012-04-29 18:01 ` Drew Adams 2012-04-29 19:51 ` PJ Weisberg 1 sibling, 0 replies; 59+ messages in thread From: Drew Adams @ 2012-04-29 18:01 UTC (permalink / raw) To: 'Andreas Röhler' Cc: 'Steve Yegge', 'Emacs developers' > if the empty list is nil, why the empty string > should yield true? for me (equal nil "")==> t > would be plausible Seeing a new patch of sky, our worm has designs of wiggling its way out of the almost open can... But "" is a very short worm, and it has a long way to wiggle... ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: proposal to make null string handling more emacs-y 2012-04-29 17:29 ` Andreas Röhler 2012-04-29 18:01 ` Drew Adams @ 2012-04-29 19:51 ` PJ Weisberg 1 sibling, 0 replies; 59+ messages in thread From: PJ Weisberg @ 2012-04-29 19:51 UTC (permalink / raw) To: Andreas Röhler; +Cc: Steve Yegge, Drew Adams, Emacs developers [-- Attachment #1: Type: text/plain, Size: 855 bytes --] On Sunday, April 29, 2012, Andreas Röhler <andreas.roehler@online.de> wrote: > Am 29.04.2012 19:08, schrieb Drew Adams: >>>> >>>> (string= nil "") >>> >>> (if "" >>> (message "%s" "empty string proved true") >>> (message "%s" "empty string proved false")) >>> ==> "empty string proved true" >> >> "" is not equal or eq or eql to nil. >> But "" is string= to nil. >> >> > > in other words said: > > if the empty list is nil, why the empty string should yield true? > > for me > > (equal nil "")==> t > > would be plausible Think of it as converting nil to a string when necessary. `string=' requires strings, so nil is treated as "". `equal' doesn't require strings, so nil is treated as nil. -- -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. [-- Attachment #2: Type: text/html, Size: 1248 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2012-06-03 3:45 UTC | newest] Thread overview: 59+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-04-25 0:24 proposal to make null string handling more emacs-y Steve Yegge 2012-04-25 4:45 ` Karl Fogel 2012-04-25 6:28 ` Miles Bader 2012-04-25 6:34 ` Miles Bader 2012-04-25 13:21 ` Ted Zlatanov 2012-05-01 22:01 ` Randal L. Schwartz 2012-04-25 7:53 ` Helmut Eller 2012-04-25 8:22 ` Eli Zaretskii 2012-04-25 14:28 ` Stefan Monnier 2012-04-25 14:35 ` Eli Zaretskii 2012-04-25 15:30 ` Stefan Monnier 2012-04-25 16:41 ` Miles Bader 2012-04-25 16:45 ` Andreas Schwab 2012-04-25 16:46 ` Juanma Barranquero 2012-04-26 21:20 ` Steve Yegge 2012-04-26 22:11 ` Miles Bader 2012-04-26 23:52 ` Steve Yegge 2012-04-27 0:29 ` Miles Bader 2012-04-27 3:20 ` Jeremiah Dodds 2012-04-27 3:41 ` Miles Bader 2012-04-27 3:59 ` Jeremiah Dodds 2012-04-27 4:24 ` Miles Bader 2012-04-27 8:49 ` Thien-Thi Nguyen 2012-04-27 14:23 ` Nix 2012-04-28 2:07 ` Better startup error handling (was: proposal to make null string handling more emacs-y) Stefan Monnier 2012-04-28 12:04 ` Better startup error handling Nix 2012-04-28 15:16 ` Stefan Monnier 2012-04-28 15:42 ` David Engster 2012-04-28 15:55 ` Drew Adams 2012-04-28 19:39 ` Stefan Monnier 2012-04-28 17:26 ` Lars Magne Ingebrigtsen 2012-04-30 8:43 ` Christian Lynbech 2012-04-30 9:18 ` chad 2012-04-27 16:35 ` proposal to make null string handling more emacs-y Richard Stallman 2012-04-27 1:10 ` Stefan Monnier 2012-04-27 1:16 ` Lars Magne Ingebrigtsen 2012-04-27 16:35 ` Richard Stallman 2012-04-28 11:13 ` Eli Barzilay 2012-04-28 17:02 ` Richard Stallman 2012-04-28 19:48 ` Stefan Monnier 2012-04-28 21:56 ` Eli Barzilay 2012-06-03 3:45 ` Richard Stallman 2012-04-27 4:17 ` Steve Yegge 2012-04-27 6:36 ` Eli Zaretskii 2012-04-27 19:05 ` Steve Yegge 2012-04-27 21:24 ` Drew Adams 2012-04-28 4:43 ` Steve Yegge 2012-04-28 6:58 ` Andreas Schwab 2012-04-29 21:26 ` Odd formatting (was: proposal to make null string handling more emacs-y) Lars Magne Ingebrigtsen 2012-04-30 7:48 ` Odd formatting Steinar Bang 2012-04-30 10:14 ` Antoine Levitt 2012-04-30 13:27 ` Nix 2012-04-28 2:02 ` proposal to make null string handling more emacs-y Stefan Monnier 2012-04-25 14:51 ` Lars Magne Ingebrigtsen 2012-04-29 17:00 ` Andreas Röhler 2012-04-29 17:08 ` Drew Adams 2012-04-29 17:29 ` Andreas Röhler 2012-04-29 18:01 ` Drew Adams 2012-04-29 19:51 ` PJ Weisberg
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.