Gnus development mailing list
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: Re: My thoughts on the Gnus source code
Date: Wed, 17 Feb 2016 22:12:46 +0800	[thread overview]
Message-ID: <87twl7whlt.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <8737ssprg9.fsf@thinkpad.rath.org>

Nikolaus Rath <Nikolaus@rath.org> writes:

> On Feb 13 2016, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>> Nikolaus Rath <Nikolaus@rath.org> writes:
>>

[...]

>> 1. I don't think there's anything inherently unsuitable about Elisp for
>>    writing a MUA (or any other type of software). It's a general
>>    programming language, a little different from Python or other more
>>    popular languages, but it comes with a full complement of modern
>>    programming features.
>
> You may be right. But I think in that case the relevant modern
> programming features have a bit of a visibility problem. They are rarely
> found in existing code (probably because most of it predates them), and
> there also don't feature prominently in the "Emacs Lisp Reference
> Manual".

That's definitely fair to say. And I think Emacs development energy gets
split between "making Elisp a better language" and "making Emacs a
better editor". But the tools are there.

[...]

> I don't object to using buffers at all, I object to using them to pass
> data around between functions. For example, I think a much better format
> to pass around message headers would be a list of alists. That way, if a
> function wants to access a specific header it doesn't have to
> re-implement RFC822 parsing but it simply uses assq et al. And even
> better, if I messed up and passed a buffer containing a full message
> instead of a sequence of headers, things are going to fail loudly
> instead of weird things happening silently.
>
>>    I understand there are such things out there as Real
>>    Parsers, and that they're difficult to write, and that maybe we could
>>    benefit by having one
>
> That's why you don't write the parser, but use a parser generator
> :-). 

Apparently we have not one but two parser generators! Have you looked at
the manuals for Bovine and Wisent? Bovine claims to be the simpler of
the two. The manuals seem quite geared towards parsing source code
buffers, but maybe they would do just as well for parsing IMAP server
output? It's not something I know much about (it's also not my
particular itch!).




  reply	other threads:[~2016-02-17 14:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 20:44 Nikolaus Rath
2016-02-13  3:52 ` Eric Abrahamsen
2016-02-14 16:33   ` Random832
2016-02-14 19:33     ` Sebastian Christ
2016-02-16  2:25     ` Eric Abrahamsen
2016-02-16  2:39       ` Lars Ingebrigtsen
2016-02-16  7:33         ` Eric Abrahamsen
2016-02-16  7:49           ` Lars Ingebrigtsen
2016-02-16  8:03             ` Eric Abrahamsen
2016-02-16 16:09   ` Nikolaus Rath
2016-02-17 14:12     ` Eric Abrahamsen [this message]
2016-03-26 11:42 ` external editor (was: My thoughts on the Gnus source code) Uwe Brauer
2016-03-28 17:08   ` external editor Nikolaus Rath
2016-03-29 10:05     ` Uwe Brauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87twl7whlt.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).