Re: [OT] Re: realplay.el interface with Real Player v. 1879
Lucas Bonnet [EMAIL PROTECTED] writes: Richard Stallman [EMAIL PROTECTED] writes: You're wrong, EMMS is indeed a GNU project. It seems that EMMS is a GNU package--a separate one. I will look at the situation with EMMS and mplayer. What do you mean by situation? EMMS supports several command-line players; by default they are, in this order : - mpg321 - ogg123 - mplayer Which means that EMMS tries mpg321 (for mp3s), ogg123 (for ogg vorbis) and then mplayer (for pretty much everything else). EMMS does not recommend the use of mplayer. Does the simple fact of allowing users to use mplayer means encouraging? No, I don't beleive that is what Richard or anyone else is arguing. I think there are two issues that Richard is concerned about. 1. Free software that actively encourages the use of non-free software/codecs etc. (I don't believe mplayer does this). 2. Free software which, through the way it is configured/setup implicitly encourages the use of non-free software. This one is possibly the more common and perhaps incidious of the two because people may not realise what they are doing. An example would be if mplayer had a button that allowed you to easily download and install non-free codecs by simply clicking on that button. I've not seen this, but I've not looked at mplayer very closely or even read its documentation. The fact a piece of free software allows you to use non-free software/codecs in itself is not an issue. Rather its the extent to which it facilitates doing so that is of concern. the FSF isn't so ideological as to try and ban the use of free software - if they were, you wouldn't have distributions like Red Hat or companies like Oracle doing a GNu Linux distribution and the ability to run non-free packages. Rather, they don't want to implicitly or explicitly encourage the use of non-free software and they want people to be aware they are using non-free softtware when they do. this original debate started when Richard asked that an elisp package not encourage the use of realplayer by promoting as one of its benefits that it provided an easy interface to that bit of non-free software. He didn't say it couldn't do that or in any way indicate that it was or should be barred from doing so. I suspect he would prefer that the package promoted itself as providing a convenient interface to other free software and left the fact that it could be used to interface to realplayer as an available option for those wanting it bad enough (assuming there isn't a free alternative of course). regards, Tim -- tcross (at) rapttech dot com dot au ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
Re: keyboard-macro-timer.el
Richard Stallman [EMAIL PROTECTED] writes: It occurs to me that it would be more general to repeat the next or previous command at a given interval. If what you want to repeat is a keyboard macro, then you type a command to run the keyboard macro. True, that would be more general. It is probably just as convenient, and maybe simpler too. Would you like to give that a try? For executing previous command I did some investigation and looked up how `repeat' does it and it was way too complicated to me with a lot of handling of special cases. And when it comes to reading the next command, I would not even know where to begin. I see that there is the function `read-command' to read a commands name, but that does not seem very convenient. I guess I could also read the next keyboard sequence, and even if I manage executing the bound command, what if that command would require user interaction, e.g. response in the minibuffer? By forcing the user to record a keyboard macro for what he wants to repeat, I get around all these problems, problems that didn't even exist before you suggested the above... :) Anyway, thanks for the suggestion, it is a good idea, but way over my elisp capabilities. What could be a good idea, however, would be to add something similar to my hack to the kmacro package. I think it would fit quite well in there. /Mathias ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
Re: ;;; anything.el --- open anything
Hey Tamas, this patch adds a new buffer type with actions to switch or pop to it, just displaying it or killing it. --8---cut here---start-8--- diff -u /home/heimdall/elisp/anything.el.orig /home/heimdall/elisp/anything.el --- /home/heimdall/elisp/anything.el.orig 2007-07-20 12:00:26.0 +0200 +++ /home/heimdall/elisp/anything.el2007-07-20 11:59:14.0 +0200 @@ -58,8 +58,7 @@ ;; This is only an example. Customize it to your own taste! (defvar anything-sources `(((name . Buffers) (candidates . anything-buffer-list) -(action . ((Switch to Buffer . switch-to-buffer) - (Kill Buffer . kill-buffer +(type . buffer)) ((name . File Name History) (candidates . file-name-history) @@ -195,7 +194,11 @@ (Delete File . (lambda (file) (if (y-or-n-p (format Really delete file %s? file)) -(delete-file file))) +(delete-file file)) +(buffer . ((Switch to Buffer . switch-to-buffer) + (Pop to Buffer. pop-to-buffer) + (Display Buffer . display-buffer) + (Kill Buffer . kill-buffer) A list of (TYPE . ACTION) pairs specifying actions for sources which have no action defined. See the `action' attribute of `anything-sources' for possible action values.) Diff finished. Fri Jul 20 12:00:44 2007 --8---cut here---end---8--- Bye, Tassilo -- A child of five could understand this! Fetch me a child of five! ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
Re: [OT] Re: realplay.el interface with Real Player v. 1879
and perhaps you're missing some of the subtlety of david's point: if mplayer did not support non-free codecs, some (many) people wouldn't even consider giving GNU/Linux a try. This is exactly what I mentioned in my previous message. The mplayer approach sacrifices the appreciation of freedom to make today's free software more popular. In the short term, the results are good. In the long term, it is harmful, because it teaches people to aim for popularity rather than freedom. ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
Re: [OT] Re: realplay.el interface with Real Player v. 1879
The difference between Richard's and your perspective is that your approach is possibly focusing more on the usability issues and allowing users to benefit from a free platform while still being able to access proprietary content as easily as users of closed proprietary systems. I think Richard's perspective would be that this has the danger of giving up some of our freedoms without really realising what we may be sacrificing in the long term for a short term gain (i.e. access to the proprietary content). Richar's perspective is likely that if you believe your freedom is important enough, you will sacrifice short term access to the content in favor of protecting your long-term freedom. You have it exactly right. ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
Re: keyboard-macro-timer.el
For executing previous command I did some investigation and looked up how `repeat' does it and it was way too complicated to me with a lot of handling of special cases. We could move some of that code to a subroutine which you could call. That should be pretty straightforward. Having similar interfaces for the two repetition commands would also be a plus for simplicity and coherence. ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
Re: realplay.el interface with Real Player v. 1879
The non-free codecs that I'm talking about are the ones that are binary-only (or those that have non-free licenses; but I am not sure that case occurs). I don't see any ethical problem in distributing programs that are patented or illegal in certain countries, as long as their liceses are free. Those laws may be unjust, but they are not the program's fault. I was a bit misguided by the don't use gif pictures article on gnu.org. We never objected on ethical grounds to the distribution of GIF-making software -- by those who dared to do so, given the threats of patent suits. However, given that danger, we needed to try to discourage the use of GIF, to reduce the demand for GIF-making software. ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
Re: [OT] Re: realplay.el interface with Real Player v. 1879
It seems that EMMS is a GNU package--a separate one. I will look at the situation with EMMS and mplayer. What do you mean by situation? It means, the relevant facts. I don't want to reach a premature conclusion. Which means that EMMS tries mpg321 (for mp3s), ogg123 (for ogg vorbis) and then mplayer (for pretty much everything else). EMMS does not recommend the use of mplayer. Does the simple fact of allowing users to use mplayer means encouraging? No. There is a difference between invoking mplayer if it is installed, and recommending it. This suggests that there is no real problem regarding EMMS. ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
Re: [OT] Re: realplay.el interface with Real Player v. 1879
The fact a piece of free software allows you to use non-free software/codecs in itself is not an issue. Rather its the extent to which it facilitates doing so that is of concern. the FSF isn't so ideological as to try and ban the use of free software - if they were, you wouldn't have distributions like Red Hat or companies like Oracle doing a GNu Linux distribution and the ability to run non-free packages. Rather, they don't want to implicitly or explicitly encourage the use of non-free software and they want people to be aware they are using non-free softtware when they do. You have stated it very well. ___ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
