edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] Ongoing Work
Date: Sat, 11 Apr 2015 16:06:11 +0100	[thread overview]
Message-ID: <20150411150611.GC9150@toaster.adamthompson.me.uk> (raw)
In-Reply-To: <20150311103704.eklhad@comcast.net>

[-- Attachment #1: Type: text/plain, Size: 3822 bytes --]

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=application/vnd.openxmlformats-officedocument.presentationml.presentation
viewer=mailcap
}

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 case).
Of course this is a bit contrived as I'd probably want to download these files,
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 week,
> 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.

> 
> 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 need 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 email
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 useful
when looking at the next stage of this project.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

      reply	other threads:[~2015-04-11 15:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-11 14:37 Karl Dahlke
2015-04-11 15:06 ` Adam Thompson [this message]

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=20150411150611.GC9150@toaster.adamthompson.me.uk \
    --to=arthompson1990@gmail.com \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /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).