Package proposal: greader, an audio emacs reader for blind and dislexic people

Package proposal: greader, an audio emacs reader for blind and dislexic people

[Michelangelo Rodriguez]

Hi All,
I would to propose a package that reads countinuously a buffer, using 
speech synthesis.
It exists a package called emacspeak that makes emacs accessible, but my 
package is somewhat different:
It does not depend on emacspeak, and can use espeak or speech-dispatcher 
to perform reading.
It is my first package for emacs, and apart to make it available to all, 
i'm interested on suggestions on how to make my code better.
The project is at very earl stage of development, though it works already.
So, what is the next step?
thanks to all for feedback.
Michelangelo Rodriguez

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

[Tim Cross]

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

nIn addition to emacspeak, there is also a package called speechd.el, which
also does a similar thing, but uses speech-dispatcher.

My question would be why create yet another package which appears to do the
same thing rather than contribute to one of the other packages - what is it
about your package that is fundamentally different to either emacspeak
(very comprehensive, robust and powerful, with a well developed underlying
philosophy/approach) and speechd.el (minimalist, simple and lower learning
curve)?

Tim

On Tue, 29 Jan 2019 at 20:15, Michelangelo Rodriguez <
michelangelo.rodriguez@gmail.com> wrote:

> Hi All,
> I would to propose a package that reads countinuously a buffer, using
> speech synthesis.
> It exists a package called emacspeak that makes emacs accessible, but my
> package is somewhat different:
> It does not depend on emacspeak, and can use espeak or speech-dispatcher
> to perform reading.
> It is my first package for emacs, and apart to make it available to all,
> i'm interested on suggestions on how to make my code better.
> The project is at very earl stage of development, though it works already.
> So, what is the next step?
> thanks to all for feedback.
> Michelangelo Rodriguez
>
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 1811 bytes --]

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

[Michelangelo Rodriguez]

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



On Wed, 30 Jan 2019, Tim Cross wrote:

> nIn addition to emacspeak, there is also a package called speechd.el, which also does a similar thing, but uses speech-dispatcher. 
> My question would be why create yet another package which appears to do the same thing rather than contribute to one of the other packages - what is it about your package that is fundamentally different to either emacspeak (very
> comprehensive, robust and powerful, with a well developed underlying philosophy/approach) and speechd.el (minimalist, simple and lower learning curve)?
> 
Hi,
Greader is not an accessibility tool for emacs. It is specialized on 
reading contents of buffers, not in providing information about emacs 
sessions.
Greader is based on back-ends architecture, so does not depend on a 
single package (eg. on speech-dispatcher) that is known to be buggy, and 
back-ends for espeak and speech-dispatcher are already provided.
Greader has the possibility to make "audiobooks", switable to be listened 
with mobile devices.
In other words, greader serves a different purpose if compared to 
emacspeak and speechd-el, that are indeed great packages.
Yes, i considered the iidea of integrating greader into one of those 
packages, but it can result in a confusion, because as i sayd, that 
packages are semantically different.
> 
> On Tue, 29 Jan 2019 at 20:15, Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com> wrote:
>       Hi All,
>       I would to propose a package that reads countinuously a buffer, using
>       speech synthesis.
>       It exists a package called emacspeak that makes emacs accessible, but my
>       package is somewhat different:
>       It does not depend on emacspeak, and can use espeak or speech-dispatcher
>       to perform reading.
>       It is my first package for emacs, and apart to make it available to all,
>       i'm interested on suggestions on how to make my code better.
>       The project is at very earl stage of development, though it works already.
>       So, what is the next step?
>       thanks to all for feedback.
>       Michelangelo Rodriguez
> 
> 
> 
> 
> --
> regards,
> 
> Tim
> 
> --
> Tim Cross
> 
> 
>

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

[Tim Cross]

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

I'm not sure I follow. With the exception of the references to the back-end
TTS, I don't see anything in your proposed package that the other packages
don't already do. I can see that Emacspeak may be too sophisticated with
too much additional functionality that is not needed, such as session
information, but the primary purpose is to turn buffers into text. However,
Emacspeak is somewhat 'invasive', so I can appreciate that it may be
overkill for what you want. This is why I suggest you look at speechd.el,
which does not modify Emacs behaviour to the extent of Emacspeak and
essentially just takes buffer contents and sends them to speech-dispatcher.

I would not discount speech-dispatcher as a possible backend. I find
current versions stable and reliable. Having written a number of speech
services in the past, I know first hand how complex implementing a reliable
and functional interface is. There are a lot of hidden details which only
become obvious when you start to use the system. For example, when reading
a large buffer, being able to pause speech and restart from the position
you paused at while at the same time, ensuring that text is sent in
sufficiently large chunks to enable the TTS engine to turn it into good
quality speech  (chunk size is often critical to this), handling various
UTF characters, filtering out text which you don't want spoken (consider a
horizontal line of -----, do you want it to speak "horizontal line" or do
you want it to say 'dash' 80 times or say nothing, what is the 'cuitoff'
point ) etc. Implementing a proof of concept is fairly trivial, but
implementing something robust and usable is much much harder.

Tim

On Wed, 30 Jan 2019 at 18:09, Michelangelo Rodriguez <
michelangelo.rodriguez@gmail.com> wrote:

>
>
> On Wed, 30 Jan 2019, Tim Cross wrote:
>
> > nIn addition to emacspeak, there is also a package called speechd.el,
> which also does a similar thing, but uses speech-dispatcher.
> > My question would be why create yet another package which appears to do
> the same thing rather than contribute to one of the other packages - what
> is it about your package that is fundamentally different to either
> emacspeak (very
> > comprehensive, robust and powerful, with a well developed underlying
> philosophy/approach) and speechd.el (minimalist, simple and lower learning
> curve)?
> >
> Hi,
> Greader is not an accessibility tool for emacs. It is specialized on
> reading contents of buffers, not in providing information about emacs
> sessions.
> Greader is based on back-ends architecture, so does not depend on a
> single package (eg. on speech-dispatcher) that is known to be buggy, and
> back-ends for espeak and speech-dispatcher are already provided.
> Greader has the possibility to make "audiobooks", switable to be listened
> with mobile devices.
> In other words, greader serves a different purpose if compared to
> emacspeak and speechd-el, that are indeed great packages.
> Yes, i considered the iidea of integrating greader into one of those
> packages, but it can result in a confusion, because as i sayd, that
> packages are semantically different.
> >
> > On Tue, 29 Jan 2019 at 20:15, Michelangelo Rodriguez <
> michelangelo.rodriguez@gmail.com> wrote:
> >       Hi All,
> >       I would to propose a package that reads countinuously a buffer,
> using
> >       speech synthesis.
> >       It exists a package called emacspeak that makes emacs accessible,
> but my
> >       package is somewhat different:
> >       It does not depend on emacspeak, and can use espeak or
> speech-dispatcher
> >       to perform reading.
> >       It is my first package for emacs, and apart to make it available
> to all,
> >       i'm interested on suggestions on how to make my code better.
> >       The project is at very earl stage of development, though it works
> already.
> >       So, what is the next step?
> >       thanks to all for feedback.
> >       Michelangelo Rodriguez
> >
> >
> >
> >
> > --
> > regards,
> >
> > Tim
> >
> > --
> > Tim Cross
> >
> >
> >



-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 5011 bytes --]

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

[Michael Heerdegen]

Tim Cross <theophilusx@gmail.com> writes:

> nIn addition to emacspeak, there is also a package called speechd.el,
> which also does a similar thing, but uses speech-dispatcher.

But speechd is not part of the Emacs project, right?  I see it is
distributed in Melpa, but not in Gnu Elpa.  So I guess this is not a
reason to reject the suggested package, or do I miss something?

Michael.

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

[Tim Cross]

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

Speech-dispatcher is software installed on most Linux systems to provide
TTS services (as used by things like Orca and other accessibility tools).
It provides a unified interface to many TTS engines, such as espeak, but
many others as well. It has nothing to do with Emacs - it is just the
backend TTS service you would need (rather than implementing an espeak
specific interface). There is a speech-dispatcher lib for emacs which
provides the functions necessary for Emacs to send data to
speech-dispather. The speechd.el module uses this to send text to the TTS.

The advantage of using speech-dispatcher for your TTS service is that it
would provide support for many different TTS engines (quality and features
differ greatly between TTS engines - as too does support for different
languages).  The other advantage is that it provides a unified interface
for doing things like setting speech rate, volume, pitch,
pausing/restarting etc. I *thiink* speech-dispatcher will also work on OSX,
but probably not windows.

The speechd.el package will provide you with examples of how to take text
that is in a buffer and send it to speech-dispatcher to have it read out.
The library is small and well written (though suffering a little from 'bit
rot', so can probably be improved upon - but the general idea is sound and
will likely provide some clear examples. You will also see how you can
enhance the speech by adding support for different voices - both speechd.el
and Emacspeak use this technique - text is spoken in a different voice
based on the font-lock properties of a word. So, you could, for example,
have a eww buffer of a web page spoken such that headings are spoken in a
different voice to paragraph text etc. This can make the spoken text easier
to understand/follow for the listener. While speechd has this in a very
basic way, Emacspeak has a far more sophisticated version.

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.

On Thu, 31 Jan 2019 at 09:09, Michael Heerdegen <michael_heerdegen@web.de>
wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
> > nIn addition to emacspeak, there is also a package called speechd.el,
> > which also does a similar thing, but uses speech-dispatcher.
>
> But speechd is not part of the Emacs project, right?  I see it is
> distributed in Melpa, but not in Gnu Elpa.  So I guess this is not a
> reason to reject the suggested package, or do I miss something?
>
> Michael.
>


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 3748 bytes --]

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

[Michael Heerdegen]

Tim Cross <theophilusx@gmail.com> 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.

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

[Tim Cross]

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

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 <michael_heerdegen@web.de>
wrote:

> Tim Cross <theophilusx@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 4161 bytes --]

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

[Phil Sainty]

On 2019-01-31 16:13, Tim Cross wrote:
> 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.

I don't believe that's the case at all.

GNU ELPA packages are not part of core Emacs, and anyone can contribute
them (within the FSF rules).  If new Emacs releases might be held back
on account of any arbitrary ELPA package not working, this is the first
I've heard of it.  Maybe certain packages which are considered
particularly important might have such status in effect, and obviously
if bugs are reported against ELPA packages then they could be fixed,
but I don't think adding ELPA packages increases the amount of work
required to release new versions of Emacs?

After all, one of the acknowledged advantages of ELPA packages is that
they can be updated outside of Emacs release cycles, so it is *less*
important that ELPA bugs be fixed prior to an Emacs release, because
they can be fixed afterwards without the need of another Emacs release.


> 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.

Definitely not true.  GNU ELPA and MELPA are simply two instances of
package archives.  There are plenty of packages in GNU ELPA which are
nothing like "core" functionality, and plenty of packages in MELPA
that I wish had been contributed to either GNU ELPA or Emacs core.
It's not the case that the two archives were established for the
purposes you've described.  The only distinction I draw between them
is that one requires contributors to follow the FSF rules, and the
other does not.


> 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.

That can be a recipe for failure.  Too many packages get contributed
to MELPA, get popular, and then *can't* be "moved over" to GNU ELPA
because the author wasn't taking care of the copyright issue while it
was on MELPA, and suddenly finds that they've accepted code 
contributions
into their package which are blocking that move.  The more popular the
package becomes, the more likely that situation is to occur.  It's
better to start in GNU ELPA and ensure that this problem is avoided
from the outset.

(There's a LOT of good elisp out there which would benefit Emacs core,
but which will never do so because by the time it was "good enough" for
that to happen, it was also completely impractical to assign the 
copyright
to the FSF.)


-Phil

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

[Michelangelo Rodriguez]

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

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 <michael_heerdegen@web.de> wrote:
>       Tim Cross <theophilusx@gmail.com> 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
> 
> 
>

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

[Michelangelo Rodriguez]

Where i can find information about how to adere at the gnu standards?i'm 
sorry for my perhaps trivial question, but i'm newbie in emacs development 
and, at the same time, i want to start to contribute to the community. in 
a consistent way.
Thanks in advance.


On Thu, 31 Jan 2019, Phil Sainty wrote:

> On 2019-01-31 16:13, Tim Cross wrote:
>> 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.
>
> I don't believe that's the case at all.
>
> GNU ELPA packages are not part of core Emacs, and anyone can contribute
> them (within the FSF rules).  If new Emacs releases might be held back
> on account of any arbitrary ELPA package not working, this is the first
> I've heard of it.  Maybe certain packages which are considered
> particularly important might have such status in effect, and obviously
> if bugs are reported against ELPA packages then they could be fixed,
> but I don't think adding ELPA packages increases the amount of work
> required to release new versions of Emacs?
>
> After all, one of the acknowledged advantages of ELPA packages is that
> they can be updated outside of Emacs release cycles, so it is *less*
> important that ELPA bugs be fixed prior to an Emacs release, because
> they can be fixed afterwards without the need of another Emacs release.
>
>
>> 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.
>
> Definitely not true.  GNU ELPA and MELPA are simply two instances of
> package archives.  There are plenty of packages in GNU ELPA which are
> nothing like "core" functionality, and plenty of packages in MELPA
> that I wish had been contributed to either GNU ELPA or Emacs core.
> It's not the case that the two archives were established for the
> purposes you've described.  The only distinction I draw between them
> is that one requires contributors to follow the FSF rules, and the
> other does not.
>
>
>> 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.
>
> That can be a recipe for failure.  Too many packages get contributed
> to MELPA, get popular, and then *can't* be "moved over" to GNU ELPA
> because the author wasn't taking care of the copyright issue while it
> was on MELPA, and suddenly finds that they've accepted code contributions
> into their package which are blocking that move.  The more popular the
> package becomes, the more likely that situation is to occur.  It's
> better to start in GNU ELPA and ensure that this problem is avoided
> from the outset.
>
> (There's a LOT of good elisp out there which would benefit Emacs core,
> but which will never do so because by the time it was "good enough" for
> that to happen, it was also completely impractical to assign the copyright
> to the FSF.)
>
>
> -Phil
>

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

[Eli Zaretskii]

On January 31, 2019 8:04:43 AM GMT+02:00, Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com> wrote:
> Where i can find information about how to adere at the gnu
> standards?i'm 
> sorry for my perhaps trivial question, but i'm newbie in emacs
> development 
> and, at the same time, i want to start to contribute to the community.
> in 
> a consistent way.


Please study the file CONTRIBUTE in the Emacs source tree.  It includes a pointer to the GNU Coding Standards document, and much more.

Thanks for working on this.

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

[Tim Cross]

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

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.

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.



On Thu, 31 Jan 2019 at 16:55, Michelangelo Rodriguez <
michelangelo.rodriguez@gmail.com> 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 <
> michael_heerdegen@web.de> wrote:
> >       Tim Cross <theophilusx@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 8955 bytes --]

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

[Tim Cross]

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

OK, thanks for the correction.

On Thu, 31 Jan 2019 at 15:08, Phil Sainty <psainty@orcon.net.nz> wrote:

> On 2019-01-31 16:13, Tim Cross wrote:
> > 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.
>
> I don't believe that's the case at all.
>
> GNU ELPA packages are not part of core Emacs, and anyone can contribute
> them (within the FSF rules).  If new Emacs releases might be held back
> on account of any arbitrary ELPA package not working, this is the first
> I've heard of it.  Maybe certain packages which are considered
> particularly important might have such status in effect, and obviously
> if bugs are reported against ELPA packages then they could be fixed,
> but I don't think adding ELPA packages increases the amount of work
> required to release new versions of Emacs?
>
> After all, one of the acknowledged advantages of ELPA packages is that
> they can be updated outside of Emacs release cycles, so it is *less*
> important that ELPA bugs be fixed prior to an Emacs release, because
> they can be fixed afterwards without the need of another Emacs release.
>
>
> > 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.
>
> Definitely not true.  GNU ELPA and MELPA are simply two instances of
> package archives.  There are plenty of packages in GNU ELPA which are
> nothing like "core" functionality, and plenty of packages in MELPA
> that I wish had been contributed to either GNU ELPA or Emacs core.
> It's not the case that the two archives were established for the
> purposes you've described.  The only distinction I draw between them
> is that one requires contributors to follow the FSF rules, and the
> other does not.
>
>
> > 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.
>
> That can be a recipe for failure.  Too many packages get contributed
> to MELPA, get popular, and then *can't* be "moved over" to GNU ELPA
> because the author wasn't taking care of the copyright issue while it
> was on MELPA, and suddenly finds that they've accepted code
> contributions
> into their package which are blocking that move.  The more popular the
> package becomes, the more likely that situation is to occur.  It's
> better to start in GNU ELPA and ensure that this problem is avoided
> from the outset.
>
> (There's a LOT of good elisp out there which would benefit Emacs core,
> but which will never do so because by the time it was "good enough" for
> that to happen, it was also completely impractical to assign the
> copyright
> to the FSF.)
>
>
> -Phil
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 3790 bytes --]

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

[Michelangelo Rodriguez]

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



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 <michelangelo.rodriguez@gmail.com> 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 <michael_heerdegen@web.de> wrote:
>       >       Tim Cross <theophilusx@gmail.com> 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
> 
> 
>

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

[Michelangelo Rodriguez]

Hi All,
I moved the code to gitlab:
https://gitlab.com/michelangelo-rodriguez/greader
best regards,
Michelangelo Rodriguez

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think it would be good to include this functionality in ELPA.
I have no opinions about the particular packages.

  > Speech-dispatcher is software installed on most Linux systems to provide

Would you please call them "GNU/Linux systems", so as to give GNU
contributors (including the contributors to GNU Emacs) equal mention
when discussing this development of the GNU system?

See https://gnu.org/gnu/linux-and-gnu.html and
https://gnu.org/gnu/gnu-linux-faq.html, plus the history in
https://gnu.org/gnu/the-gnu-project.html.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Michael Heerdegen]

Tim Cross <theophilusx@gmail.com> writes:

> 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.

AFAIK there is no such requirement.  Lots of packages in Gnu Elpa are
synchronized from github - see "externals-list".


Michael.

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

[Michael Heerdegen]

Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com> writes:

> So, the link for the code is:
> https://github.com/michelangelo-rodriguez/greader.git

Thanks.  I tested it quickly.

The README said I should hit C-r to let it start reading, but it should
be C-r SPC, right?  That worked nicely at least.  + and - didn't work
OTOH, I got an error saying that the variable "greader-rate" is
undefined.  That variable is indeed declared nowhere.

There are also a lot of compiler warnings.  So a bit of code review
would probably be good, also text formatting (line breaks, capital
letters at sentence beginnings) should get some care, by someone not
blind, because it's probably easier for those (so I guess at least).

I think the package would be a good addition to Gnu Elpa.  If it is
accepted by Emacs developers, you have to sign some papers with legal
stuff.  AFAIK it's important that all contributors (of more than 15
lines or so) have also signed these papers, but it seems you are the
only contributor anyway.

After that someone can add your package to Gnu Elpa, or you can get an
account and add it by yourself.


Regards,

Michael.

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

[Stefan Monnier]

>> 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.
> AFAIK there is no such requirement.

Yes and no: technically, all GNU ELPA packages are hosted in the
elpa.git repository.  But for many packages, it's just a mirror, indeed.

> Lots of packages in Gnu Elpa are synchronized from github - see
> "externals-list".

Note also that the synchronization is 100% manual: someone needs to "git
push" the new data to elpa.git.


        Stefan

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

[Michelangelo Rodriguez]

On Tue, 5 Feb 2019, Michael Heerdegen wrote:

> Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com> writes:
>
>> So, the link for the code is:
>> https://github.com/michelangelo-rodriguez/greader.git
>
> Thanks.  I tested it quickly.
Hi Michael, Since i moved the code to gitlab, please clone this:
https://gitlab.com/michelangelo-rodriguez/greader.git
I will not keep updated github repo.
Thanks for your hints.
>
> The README said I should hit C-r to let it start reading, but it should
> be C-r SPC, right?  That worked nicely at least.  + and - didn't work
> OTOH, I got an error saying that the variable "greader-rate" is
> undefined.  That variable is indeed declared nowhere.
>
> There are also a lot of compiler warnings.  So a bit of code review
> would probably be good, also text formatting (line breaks, capital
> letters at sentence beginnings) should get some care, by someone not
> blind, because it's probably easier for those (so I guess at least).
>
> I think the package would be a good addition to Gnu Elpa.  If it is
> accepted by Emacs developers, you have to sign some papers with legal
> stuff.  AFAIK it's important that all contributors (of more than 15
> lines or so) have also signed these papers, but it seems you are the
> only contributor anyway.
>
> After that someone can add your package to Gnu Elpa, or you can get an
> account and add it by yourself.
>
>
> Regards,
>
> Michael.
>

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > AFAIK there is no such requirement.  Lots of packages in Gnu Elpa are
  > synchronized from github - see "externals-list".

It is not a requirement, but it is a good thing to do for any package.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)