From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 902A97ABE6 for ; Sat, 11 Apr 2015 08:07:56 -0700 (PDT) Received: by widdi4 with SMTP id di4so10815073wid.0 for ; Sat, 11 Apr 2015 08:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=brkMdPLATL+pJVxaZuss3QzbdZb/vHvWDg9Fj+BcI7E=; b=DsWMYh6xqtrCl2jIuhRpyLWul5Pk0bfmrouKm1ASeqhIMlmgQT8fXw+gcLsgN5BexX Tp6zdB5WJeiMGv97aku+vDl4+BYhlU6SzEyuFbYvnapJreyc2iJs4flAhUy63Q7MPDu8 pSOpsaPKKD+5he0dwWVDAhSxK6ecDN78s9Ie20P4bkyJfGeeVr0tRP3YG07eKN1htywz yTzVbEPjSZEkuZG7pME4Tn4S8JjEO/qvh6EO2mq+2OLXRGHNy2COoVkk25t+cYa3UyS2 VCRTFZRd+h5C56CgvJENkY8Y2JbFjubmSVGxlbi/N64uCiOjGW4OIGacYZDdnV8BOrlO uMGg== X-Received: by 10.194.86.135 with SMTP id p7mr12173023wjz.89.1428764775198; Sat, 11 Apr 2015 08:06:15 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id ew5sm4411289wic.14.2015.04.11.08.06.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Apr 2015 08:06:14 -0700 (PDT) Date: Sat, 11 Apr 2015 16:06:11 +0100 From: Adam Thompson To: Karl Dahlke Message-ID: <20150411150611.GC9150@toaster.adamthompson.me.uk> References: <20150311103704.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zbGR4y+acU1DwHSi" Content-Disposition: inline In-Reply-To: <20150311103704.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] Ongoing Work X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 15:07:58 -0000 --zbGR4y+acU1DwHSi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 11, 2015 at 10:37:04AM -0400, Karl Dahlke wrote: > Adam, I like your thoughts and ideas; please continue to post them, > even if you seem at the outset to be in the minority. > You have been such an enormous help to us over the past two years. Thanks. It's interesting to get to work on a project like this, particularly as I need it in day-to-day work. > I am moving forward with the enhanced mime type, and link to content, > and connection to downloads, as per our discussions last week. > This one doesn't make my brain ache, so forward I march. > I already pushed a few changes along these lines. > One push fixes a bug in the makefile > that has been there for a while. Whilst thinking about this mime type thing, I wonder if we shouldn't have mailcap support, i.e. something like (not sure what the http header is for this, I assume same as= the mailcap file): mime { contenttype=3Dapplication/vnd.openxmlformats-officedocument.presentationml.= presentation viewer=3Dmailcap } That'd consult the mailcap mechanism for a pptx converter in the event that= I don't care about html formatting (which with powerpoints is usually the cas= e). Of course this is a bit contrived as I'd probably want to download these fi= les, but I've had cases where I'd actually rather display them, so being able to type space at the download prompt then pb to just convert = the thing to text would be rather nice. > This summer I'd like to make more structural changes, > as we did with the separate js process. > In other words, I'd like to jump back in. > We need to keep pushing, to make this a real project, > or in Adam's words, "relevant". > I've been distracted lately by other things, > like a very important (personal) court case that finally finished last we= ek, > and a math problem that's been sitting in my head for 35 years > and I finally decided god damn it to solve it. > It's really quite beautiful. > http://articles.eklhad.net/jumping > But I think next month things will settle down > and I can put more time / effort into edbrowse. Glad to hear that, will read the article when I finish writing this. > Of course we need to pick our design and direction carefully, > because a minute of thought is worth a megabyte of programming, > in any project. > A good rule of thumb is that if all three of us agree on a design, > then we should move forward with it. > That has worked well so far. Agreed. >=20 > I'm guessing the use of tidy5 to parse html and create a tree of objects > should be the next structural change. > And then getting a version of imap to run; though the three of us don't n= eed it, > it is often requested by users, > and I might like it if I had it and got use to it. I know imap is *often* requested, but I'm still not entirely convinced, given the way email works in edbrowse, that we should do it, particularly as there are existing programs like mailx (provided by a bunch= of debian packages at least) which provide a very ed-like email interface to e= mail already and support many more features than edbrowse's email support. I've actually looked at switching from mutt to a version of mailx (the heirloom-mailx version was the one I was thinking) because I kind of like the interface, but I'm just a bit too attached to my mutt config at the moment. What I'd like to see, as per previous posts, is a switch to separating out the sources of stuff to render (i.e. text files, DOM etc) from the actual rendering code, and the rendering code from the buffering mechanism. Obviously this is going to be a bit complicated, but I think it's worth at least exploring. This is currently partially done, but increasing the separation will be use= ful when looking at the next stage of this project. Cheers, Adam. --zbGR4y+acU1DwHSi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVKThjAAoJELZ22lNQBzHOLhwIAJhXoQD5KEtOdwCOH8lGJX7p jqX3CEXO91Q3N+4VJW9eQ2yH/JmZ7Sx2XXr+rlfX3b+4WmrA1QCoeFnad4QM1nTZ fZzA6z/2K+cu8lZXjWbGYzWO1AaaRDEICmt+cgiywPyPo+tUwaWlQ2sOJjaZ49gC ZVlg2jiXNKfg0M21rChqxwNMl5gygqBO9aSCIfi3qAQUADZxGM7aCCIRQWaWOdGc aj7iU9yK4+zmL0kY0GHzH+eRecKKcs+OCDG6hufJ3dlK7gx6fbYTos5oxZIuFbfa qg4d2kIsOzUjBXfFaJOaBkCU8+uL9aqg37gOXDbIKIM8PcCF5vqJKx54IERRBNc= =E/fS -----END PGP SIGNATURE----- --zbGR4y+acU1DwHSi--