emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Package proposal: greader, an audio emacs reader for blind and disle


From: Michelangelo Rodriguez
Subject: Re: Package proposal: greader, an audio emacs reader for blind and dislexic people
Date: Fri, 1 Feb 2019 05:47:43 +0100 (CET)
User-agent: Alpine 2.21 (DEB 202 2017-01-01)



On Fri, 1 Feb 2019, Tim Cross wrote:
Hi Tim,

I am also blind and use either Emacspeak or speechd.el on a daily basis.  I run 
mainly Emacspeak under either stumpwm or MATE. I don't use Orca, speakup or 
anything else, except Chrome and Chromevox when I need to access web content
which relies on Javascript (use eww when it doesn't). 
I read many different documents, web pages, source code etc every day. 
Emacspeak and/or emacs provide all the functions necessary to read a document 
by line, by paragraph, by page, beginning of buffer to cursor, cursor to end of 
buffer,
interactive mode (i.e. read paragraph and wait until you hit space to read next 
paragraph), by region, by sexp.  Likewise, speechd.el provides the basic 
functions, though lacks some of the more high level functionality of emacspeak -
but this is emacs, so it is fairly trivial to create custom functions to do 
whatever interaction with buffers you want. 

I work as a developer and have to interact with remote and local systems on a 
daily basis. There is also a fair amount of sys admin and dba work involved in 
what I do. Eamcspeak is able to meet all my requirements and a primary reason
why I wanted to try and understand why you found it was unable to do what you 
needed, requiring another package which seems to reproduce something which is 
already available.  

Your statement 

      neither emacspeak or speechd-el offers me the possibility to read a text 
      and move throwgh it while in reading.
      I have the idea that you think i don't know anothing about emacspeak and 
      speechd-el.


highlights what I'm trying to understand as both emacspeak and speechd will do 
this in different ways. For example, emacspeak-speak-browse-buffer will speak 
some of the buffer and then wait until you hit space, then moves cursor to the
next 'chunk' and speaks that etc.

From your last post, things are a little clearer. I can appreciate the idea of 
creating a package which only sends the content of a buffer to some back-end 
speech service. However, I think you will find there is still a lot of
complexity and challenges there if you want to create something robust enough 
it will be useful to others. This is why I suggest using speech-dispatcher on 
the back-end. Emacspeak does not use speech-dispatcher and I would estimate that
the most common support issues with the package, especially for new users, is 
getting the speech servers to work. While things have got better in the last 
few years, the different Linux distributions, different TTS engines, different
package versions etc, make this complex and difficult to manage. 
Infact the code i propose dials with speech-dispatcher too.
Have you tested it?>
One of the first things you will need to do is move your source repo to a 
'free' (GNU approved) repository hosting service - github.com is not.
Ok, thanks for the suggestion.
Savannah is a possible repo?
cheers.>


On Thu, 31 Jan 2019 at 16:55, Michelangelo Rodriguez <address@hidden> wrote:
      Hi,
      I'm blind, and so i know well how speechd-el and emacspeak works.
      In my particular case, i'm developing the solution i suggest because
      neither emacspeak or speechd-el offers me the possibility to read a text
      and move throwgh it while in reading.
      I have the idea that you think i don't know anothing about emacspeak and
      speechd-el.
      I use, for example, sspeakup to handle emacs, and greader to read text
      continuously, as it is really lighter in respect to activate emacspeak or
      speechd-el.
      So, the link for the code is:
      https://github.com/michelangelo-rodriguez/greader.git
      Regards, and thanks for the discussion.


      On Thu, 31 Jan 2019, Tim Cross wrote:

      > I responded to the message because I use an Emacs which converts 
buffers to spoken text on a daily basis and because I have written a number of 
speech services, so have some familiarity with the area. I've also made
      extensive use of
      > both Emacspeak and speechd.el. I suspect there has been few other 
responses because this is not something which many people want or have thought 
about. There are also lots of programs out there which can turn text of
      various formats
      > into speech and probably only a small number of people who would find 
doing so from within emacs much benefit.
      >
      > I didn't reject the package. I asked what the package did that was 
different to existing libraries which I felt provided very similar functionality 
to what is being proposed.  It still isn't clear to me what the proposed
      package would
      > add that isn't available in (for example) speechd.el. In fact, the 
proposed package seems to be a subset of what is available in speechd.el, Rather 
than having multiple packages that do very similar things, I would rather
      see that
      > effort all pulling in the same direction on a single package. 
      > I don't agree that everything should go into GNU ELPA just because it 
can The thing about GNU ELPA is that all the packages in there are actively 
maintained and kept up to date with current version of Emacs. The mor
      packages in there,
      > the more work is required to release new versions of Emacs. IMO the GNU 
ELPA repository is really for packages that represent core Emacs functionality. 
For non-core things, we have MELPA, which  sounds like a better fit
      for this
      > package. 
      >
      > Regardless, I think the better approach is to first develop and release 
the package in MELPA. If it becomes popular and the community believes it would be 
a good fit for GNU ELPA, it can be moved over to that repository. 
      >
      > On Thu, 31 Jan 2019 at 13:06, Michael Heerdegen <address@hidden> wrote:
      >       Tim Cross <address@hidden> writes:
      >
      >       > speechd.el is not part of core emacs and therefore is not in 
the GNU
      >       > ELPA repository. It is GPL'd. With something like the package 
you are
      >       > suggesting, you are probably best off developing it as a 
separate
      >       > project and once it becomes mature, see what interest there is 
in
      >       > having it moved into becoming part of the Emacs project. I 
suspect
      >       > this is unlikely as it isn't core Emacs functionality, but you 
never
      >       > know. Of course, that doesn't mean it cannot be a GNU project.
      >       >
      >       > BTW, you may want to choose a different name from greader - 
there have
      >       > been packages in the past called greader, which were interfaces 
to the
      >       > old Google Reader RSS interface.
      >
      >       I think you are confusing me with Michelangelo, I'm someone else.
      >
      >       I don't know much about the matter, but I wanted to understand 
why you
      >       rejected the suggested package and why no one else commented.
      >
      >       Maybe it would help us who aren't that familiar with the matter if
      >       Michelangelo could post his suggested package, or a link to it, 
so that
      >       we know what we speak about.
      >
      >       BTW I had the impression that you objected that Michelangelos 
package
      >       doesn't use speech-dispatcher, but AFAIU he told that it does.
      >
      >       Anyway, if we haven't something like this yet in Gnu Elpa, if it's
      >       useful, why not add it there.  I didn't mean to add it to the core
      >       distribution of course.
      >
      >
      >       Michael.
      >
      >
      >
      > --
      > regards,
      >
      > Tim
      >
      > --
      > Tim Cross
      >
      >
      >



--
regards,

Tim

--
Tim Cross



reply via email to

[Prev in Thread] Current Thread [Next in Thread]