however, when i click on post, it says
«We were unable to post your message
If you believe this is an error, please contact Google Support.»
I tried post the message as a new thread, but still same error. No
luck after clearing cookies and relogin and or restart Safari browser.
What's wrong?
I'm suspecting that google is checking the message content and think
it is spam? cause there are lots of spam blogs or spam newsgroup posts
that contains my name “Xah Lee” or my site and site content
“xahlee.org”. If so, what can i do about it? (i have often reported
such spams thru the report button or google blog help page)
The following is the message content.
----------------------
Xah wrote:
«I think the existance of the lisp scratch buffer is one of the major
usability problem of emacs that prevents emacs from being widely
adopted by most text editing audience.»
Giorgos Keramidas wrote:
> Hi Xah ,
> For what it's worth, I think I would appreciate an option that makes the
> current behavior of the *scratch* buffer tunable, i.e. by an option like:
> (defvar scratch-buffer-uses-fundamental-mode nil
> "Non-nil makes the *scratch* buffer use `fundamental-mode'.
> Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
> If you are not really interested to use `lisp-interaction-mode',
> but you would prefer to start all scratch buffers in
> `fundamental-mode', to start editing text instead of typing Lisp
> expressions, set the `scratch-buffer-uses-fundamental-mode'
> variable to a non-nil value.")
by having a New command with Ctrl+n key, it solves this problem with
scratch plus what you want.
• The New command is a standard across Mac, Windows, Unix (Linux). It
is familiar to all software users.
• The Ctrl+n shortcut for New is standard and familiar to all software
users.
• The New commmand (where the corresponding elisp command name might
will be named new-empty-buffer), can supplant completely the
functionality of *scratch* buffer.
• When users want to have a scratch buffer, he can create it by simply
pressing the shortcut, and when he doesn't want it, he can simply
close it with a standard keystroke Ctrl+w.
• Users can have multiple *scratch* buffers easily without the need to
look into emacs doc.
• The “*scratch*” name is not in some technical jargon sense the best
one. “*untitled*” or “untitled” is a better one, and widely used
across some 99% of OSes and applications. The name “*scratch*” is
unnecessarily narrow, as to indicate that the buffer's content is only
for temp purposes, while “untitled” can include the purpose of
scratch, and can be discarded just as “*scratch*”.
• The respawning of “*scratch*” buffer behavior is unusual, almost
unique to emacs among the thousands of application today. Letting user
have control to create and and discard such buffer is better.
• The “*scratch*” buffer is primarily used by elisp programers. Few
professional programers in the IT industry knows about lisp, and only
minor percentage of emacs users actually code emacs lisp.
> But I don't like the `personal attack' style that this text uses, and I
> don't really agree with *all* the proposed `modernization' features.
The Modernization of Emacs article at
http://xahlee.org/emacs/modernization.html does not have any “personal attack” writing style. Perhaps you were
thinking my other newsgroup posts elsewhere where this issue is
discussed.
> I don't really agree with *all* the proposed `modernization'
> features.
If you agree to some, please file a bug report, or help spread the
idea. Thanks for discussing this issue with me.
> If you were to split that document into smaller `features' and one of
> them was a proposal to add an option for the default mode of *scratch*
> buffers, and a good description of how you would suggest that we add a
> prompt for *scratch* buffers that are modified, I would be more than
> willing to help you with the testing and integration of any patches to
> the main Emacs source tree.
> My own idea about *scratch* buffers that do not fire up only in the
> current `lisp-interaction-mode' state is something like:
> * Add an option that may be set to a non-nil value to make *scratch*
> buffers use `fundamental-mode', or even better, an option that
> defines _which_ mode a *startup* buffer should use.
> Two possible variations of this option would be:
> ;;; Boolean option
> ;; A boolean option that makes *scratch* buffers fire up in
> ;; `fundamental-mode' by default. The option would be set to `nil'
> ;; by default, but it should be easy to tweak the option once and
> ;; keep it set forever.
> (defcustom scratch-buffer-uses-fundamental-mode nil
> "Non-nil makes the *scratch* buffer use `fundamental-mode'.
> Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
> If you are not really interested to use `lisp-interaction-mode',
> but you would prefer to start all scratch buffers in
> `fundamental-mode', to start editing text instead of typing Lisp
> expressions, set the `scratch-buffer-uses-fundamental-mode'
> variable to a non-nil value."
> :type 'boolean
> :group 'editing-basics
> :group 'convenience)
> ;;; A list of choices.
> ;; Still set to the default `lisp-interaction-mode'
> (defcustom scratch-buffer-startup-mode 'lisp-interaction-mode
> "The default mode to use for *scratch* buffers.
> If the value is `lisp' start in lisp-interaction-mode.
> If the value is `text' start in text-mode.
> If the value is `fundamental' start in whatever mode has been
> configured as the default `fundamental-mode'.
> If the value is a function, use that function to set-up the
> startup mode of *scratch* buffers."
> :type '(choice (const :tag "Lisp interaction mode" 'lisp)
> (const :tag "Text mode" 'text)
> (const :tag "Fundamental mode" 'fundamental)
> (function :tag "Custom mode"))
> :group 'editing-basics
> :group 'convenience)
> * Add the scratch buffer to the list of buffers that trigger a prompt
> if they are modified and the user types `C-x C-c' to leave Emacs.
> Right now one can open _one_ scratch buffer only. Emacs uses
> `buffer-modified-p' as the only criterion, but this doesn't work for
> scratch buffers now. It should probably be an option too, or even a
> function that checks `scratch-buffer-startup-mode' and decides. I
> haven't thought too much about this yet, so I am not sure if it
> sounds like a sensible thing to do.
I think your model can complicate the user interface.
A simple New menu command (create-empty-buffer) that creates a new
buffer in some customizable default mode, solves what you wanted and
it gives you extra power.
Emacs does not provide a user level function to create a new buffer.
It has just New, which actually creates a empty file. Most apps's New
command does not work like that. They actually just create a new
buffer, and only when user save it it becomes a file.
Creating a new buffer is actually quite useful. For example, well
known programer Stevey Yegg in his “Effective Emacs” blog list it as a
top 10 tip in emacs productivity. The emacs menu should have a New
command with Ctrl+n that calls create-empty-buffer.
-------------------------
PS as i mentioned in previous message, i did implement the above. In
my draft code,
• create-new-buffer will create a new empty buffer named “untitled”.
(this should be added the menu command under “File‣New” but i haven't
done that yet.)
• create-new-buffer has standard keyboard shortcut Ctrl+n.
• elisp command close-current-buffer will close the current buffer,
and if it is a buffer not associated with a file (such as “untitled”),
it'll ask user to save (unless it has no content)
• close-current-buffer has the standard keyboard shortcut Ctrl+w.
• close-current-buffer should have menu under “File‣Close”, but it is
not currently done. The existing “File‣Close” menu command calls kill-
this-buffer, which has 2 problems. (1) it doesn't have a shortcut. (2)
it doesn't ask users to save a non-file-associated buffer at all.
(this is major problem that leads to losing data; including
“*scratch*” buffer. The fact that emacs users dont seem to notice this
problem is because it doesn't have a keyboard shortcut, so that
actually nobody uses this command. Most use kill-buffer, which is
annoying because it promps even if the file is already saved.)
The code is practically usable, since i use it daily for about half a
year now with incremental improvement and bug fixes, but i'm sure it
can use a lot more polishing for public use.
It is GPL'd, so feel free to grab pieces for your own use or submit
into GNU.
one thing leads to another... i'm going to file a bug report (a
suggestion) on the “*scratch*” now.
(for some reason, google groups won't let me post this message... if
it went thru, that's cause i have to change the content to remove my
name Xah Lee or site xahlee .org cause spammers are using it)
It happens very often to me too during the day.......I think it's a
limitation Google is generally popping out when it believes an IP has
used enough bandwidth for some time!
My personal solution is to copy the message, click on the refresh
button of my browser. At this point, a captcha is proposed. Once
answered it, the thread is proposed again, then I reply, paste the
message and send.
Seemingly static IPs are more affected than dynamic IPs.
And finally, I wouldn't exclude that Google is trying to slow down and
discouraging with captchas a heavy use of some - or all - Usenet
groups.
An anti-spammer measure, but I wouldn't think it's aimed just at you.
> however, when i click on post, it says
> «We were unable to post your message
> If you believe this is an error, please contact Google Support.»
> I tried post the message as a new thread, but still same error. No
> luck after clearing cookies and relogin and or restart Safari browser.
> What's wrong?
> I'm suspecting that google is checking the message content and think
> it is spam? cause there are lots of spam blogs or spam newsgroup posts
> that contains my name “Xah Lee” or my site and site content
> “xahlee.org”. If so, what can i do about it? (i have often reported
> such spams thru the report button or google blog help page)
> The following is the message content.
> ----------------------Xah wrote:
> «I think the existance of the lisp scratch buffer is one of the major
> usability problem of emacs that prevents emacs from being widely
> adopted by most text editing audience.»
> Giorgos Keramidas wrote:
> > Hi Xah ,
> > For what it's worth, I think I would appreciate an option that makes the
> > current behavior of the *scratch* buffer tunable, i.e. by an option like:
> > (defvar scratch-buffer-uses-fundamental-mode nil
> > "Non-nil makes the *scratch* buffer use `fundamental-mode'.
> > Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
> > If you are not really interested to use `lisp-interaction-mode',
> > but you would prefer to start all scratch buffers in
> > `fundamental-mode', to start editing text instead of typing Lisp
> > expressions, set the `scratch-buffer-uses-fundamental-mode'
> > variable to a non-nil value.")
> by having a New command with Ctrl+n key, it solves this problem with
> scratch plus what you want.
> • The New command is a standard across Mac, Windows, Unix (Linux). It
> is familiar to all software users.
> • The Ctrl+n shortcut for New is standard and familiar to all software
> users.
> • The New commmand (where the corresponding elisp command name might
> will be named new-empty-buffer), can supplant completely the
> functionality of *scratch* buffer.
> • When users want to have a scratch buffer, he can create it by simply
> pressing the shortcut, and when he doesn't want it, he can simply
> close it with a standard keystroke Ctrl+w.
> • Users can have multiple *scratch* buffers easily without the need to
> look into emacs doc.
> • The “*scratch*” name is not in some technical jargon sense the best
> one. “*untitled*” or “untitled” is a better one, and widely used
> across some 99% of OSes and applications. The name “*scratch*” is
> unnecessarily narrow, as to indicate that the buffer's content is only
> for temp purposes, while “untitled” can include the purpose of
> scratch, and can be discarded just as “*scratch*”.
> • The respawning of “*scratch*” buffer behavior is unusual, almost
> unique to emacs among the thousands of application today. Letting user
> have control to create and and discard such buffer is better.
> • The “*scratch*” buffer is primarily used by elisp programers. Few
> professional programers in the IT industry knows about lisp, and only
> minor percentage of emacs users actually code emacs lisp.
> > But I don't like the `personal attack' style that this text uses, and I
> > don't really agree with *all* the proposed `modernization' features.
> The Modernization of Emacs article athttp://xahlee.org/emacs/modernization.html > does not have any “personal attack” writing style. Perhaps you were
> thinking my other newsgroup posts elsewhere where this issue is
> discussed.
> > I don't really agree with *all* the proposed `modernization'
> > features.
> If you agree to some, please file a bug report, or help spread the
> idea. Thanks for discussing this issue with me.
> > If you were to split that document into smaller `features' and one of
> > them was a proposal to add an option for the default mode of *scratch*
> > buffers, and a good description of how you would suggest that we add a
> > prompt for *scratch* buffers that are modified, I would be more than
> > willing to help you with the testing and integration of any patches to
> > the main Emacs source tree.
> > My own idea about *scratch* buffers that do not fire up only in the
> > current `lisp-interaction-mode' state is something like:
> > * Add an option that may be set to a non-nil value to make *scratch*
> > buffers use `fundamental-mode', or even better, an option that
> > defines _which_ mode a *startup* buffer should use.
> > Two possible variations of this option would be:
> > ;;; Boolean option
> > ;; A boolean option that makes *scratch* buffers fire up in
> > ;; `fundamental-mode' by default. The option would be set to `nil'
> > ;; by default, but it should be easy to tweak the option once and
> > ;; keep it set forever.
> > (defcustom scratch-buffer-uses-fundamental-mode nil
> > "Non-nil makes the *scratch* buffer use `fundamental-mode'.
> > Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
> > If you are not really interested to use `lisp-interaction-mode',
> > but you would prefer to start all scratch buffers in
> > `fundamental-mode', to start editing text instead of typing Lisp
> > expressions, set the `scratch-buffer-uses-fundamental-mode'
> > variable to a non-nil value."
> > :type 'boolean
> > :group 'editing-basics
> > :group 'convenience)
> > ;;; A list of choices.
> > ;; Still set to the default `lisp-interaction-mode'
> > (defcustom scratch-buffer-startup-mode 'lisp-interaction-mode
> > "The default mode to use for *scratch* buffers.
> > If the value is `lisp' start in lisp-interaction-mode.
> > If the value is `text' start in text-mode.
> > If the value is `fundamental' start in whatever mode has been
> > configured as the default `fundamental-mode'.
> > If the value is a function, use that function to set-up the
> > startup mode of *scratch* buffers."
> > :type '(choice (const :tag "Lisp interaction mode" 'lisp)
> > (const :tag "Text mode" 'text)
> > (const :tag "Fundamental mode" 'fundamental)
> > (function :tag "Custom mode"))
> > :group 'editing-basics
> > :group 'convenience)
> > * Add the scratch buffer to the list of buffers that trigger a prompt
> > if they are modified and the user types `C-x C-c' to leave Emacs.
> > Right now one can open _one_ scratch buffer only. Emacs uses
> > `buffer-modified-p' as the only criterion, but this doesn't work for
> > scratch buffers now. It should probably be an option too, or even a
> > function that checks `scratch-buffer-startup-mode' and decides. I
> > haven't thought too much about this yet, so I am not sure if it
> > sounds like a sensible thing to do.
> I think your model can complicate the user interface.
> A simple New menu command (create-empty-buffer) that creates a new
> buffer in some customizable default mode, solves what you wanted and
> it gives you extra power.
> Emacs does not provide a user level function to create a new buffer.
> It has just New, which actually creates a empty file. Most apps's New
> command does not work like that. They actually just create a new
> buffer, and only when user save it it becomes a file.
> Creating a new buffer is actually quite useful. For example, well
> known programer Stevey Yegg in his “Effective Emacs” blog list it as a
> top 10 tip in emacs productivity. The emacs menu should have a New
> command with Ctrl+n that calls create-empty-buffer.
> -------------------------
> PS as i mentioned in previous message, i did implement the above. In
> my draft code,
> • create-new-buffer will create a new empty buffer named “untitled”.
> (this should be added the menu command under “File‣New” but i haven't
> done that yet.)
> • create-new-buffer has standard keyboard shortcut Ctrl+n.
> • elisp command close-current-buffer will close the current buffer,
> and if it is a buffer not associated with a file (such as “untitled”),
> it'll ask user to save (unless it has no content)
> • close-current-buffer has the standard keyboard shortcut Ctrl+w.
> • close-current-buffer should have menu under “File‣Close”, but it is
> not currently done. The existing “File‣Close” menu command calls kill-
> this-buffer, which has 2 problems. (1) it doesn't have a shortcut. (2)
> it doesn't ask users to save a non-file-associated buffer at all.
> (this is major problem that leads to losing data; including
> “*scratch*” buffer. The fact that emacs
I tried to login using another google account, didn't help. I tried to
post as new message, or even just email thru the email author button,
it didn't let me neither. Although i was able to reply other message
in that thread.
for some reason i suspect it's checking on my message content. Am
somewhat pissed that i couldn't post my message.
> It happens very often to me too during the day.......I think it's a
> limitation Google is generally popping out when it believes an IP has
> used enough bandwidth for some time!
> My personal solution is to copy the message, click on the refresh
> button of my browser. At this point, a captcha is proposed. Once
> answered it, the thread is proposed again, then I reply, paste the
> message and send.
> Seemingly static IPs are more affected than dynamic IPs.
> And finally, I wouldn't exclude that Google is trying to slow down and
> discouraging with captchas a heavy use of some - or all - Usenet
> groups.
> An anti-spammer measure, but I wouldn't think it's aimed just at you.
> > however, when i click on post, it says
> > «We were unable to post your message
> > If you believe this is an error, please contact Google Support.»
> > I tried post the message as a new thread, but still same error. No
> > luck after clearing cookies and relogin and or restart Safari browser.
> > What's wrong?
> > I'm suspecting that google is checking the message content and think
> > it is spam? cause there are lots of spam blogs or spam newsgroup posts
> > that contains my name “Xah Lee” or my site and site content
> > “xahlee.org”. If so, what can i do about it? (i have often reported
> > such spams thru the report button or google blog help page)
> > The following is the message content.
> > ----------------------Xah wrote:
> > «I think the existance of the lisp scratch buffer is one of the major
> > usability problem of emacs that prevents emacs from being widely
> > adopted by most text editing audience.»
> > Giorgos Keramidas wrote:
> > > Hi Xah ,
> > > For what it's worth, I think I would appreciate an option that makes the
> > > current behavior of the *scratch* buffer tunable, i.e. by an option like:
> > > (defvar scratch-buffer-uses-fundamental-mode nil
> > > "Non-nil makes the *scratch* buffer use `fundamental-mode'.
> > > Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
> > > If you are not really interested to use `lisp-interaction-mode',
> > > but you would prefer to start all scratch buffers in
> > > `fundamental-mode', to start editing text instead of typing Lisp
> > > expressions, set the `scratch-buffer-uses-fundamental-mode'
> > > variable to a non-nil value.")
> > by having a New command with Ctrl+n key, it solves this problem with
> > scratch plus what you want.
> > • The New command is a standard across Mac, Windows, Unix (Linux). It
> > is familiar to all software users.
> > • The Ctrl+n shortcut for New is standard and familiar to all software
> > users.
> > • The New commmand (where the corresponding elisp command name might
> > will be named new-empty-buffer), can supplant completely the
> > functionality of *scratch* buffer.
> > • When users want to have a scratch buffer, he can create it by simply
> > pressing the shortcut, and when he doesn't want it, he can simply
> > close it with a standard keystroke Ctrl+w.
> > • Users can have multiple *scratch* buffers easily without the need to
> > look into emacs doc.
> > • The “*scratch*” name is not in some technical jargon sense the best
> > one. “*untitled*” or “untitled” is a better one, and widely used
> > across some 99% of OSes and applications. The name “*scratch*” is
> > unnecessarily narrow, as to indicate that the buffer's content is only
> > for temp purposes, while “untitled” can include the purpose of
> > scratch, and can be discarded just as “*scratch*”.
> > • The respawning of “*scratch*” buffer behavior is unusual, almost
> > unique to emacs among the thousands of application today. Letting user
> > have control to create and and discard such buffer is better.
> > • The “*scratch*” buffer is primarily used by elisp programers. Few
> > professional programers in the IT industry knows about lisp, and only
> > minor percentage of emacs users actually code emacs lisp.
> > > But I don't like the `personal attack' style that this text uses, and I
> > > don't really agree with *all* the proposed `modernization' features.
> > The Modernization of Emacs article athttp://xahlee.org/emacs/modernization.html > > does not have any “personal attack” writing style. Perhaps you were
> > thinking my other newsgroup posts elsewhere where this issue is
> > discussed.
> > > I don't really agree with *all* the proposed `modernization'
> > > features.
> > If you agree to some, please file a bug report, or help spread the
> > idea. Thanks for discussing this issue with me.
> > > If you were to split that document into smaller `features' and one of
> > > them was a proposal to add an option for the default mode of *scratch*
> > > buffers, and a good description of how you would suggest that we add a
> > > prompt for *scratch* buffers that are modified, I would be more than
> > > willing to help you with the testing and integration of any patches to
> > > the main Emacs source tree.
> > > My own idea about *scratch* buffers that do not fire up only in the
> > > current `lisp-interaction-mode' state is something like:
> > > * Add an option that may be set to a non-nil value to make *scratch*
> > > buffers use `fundamental-mode', or even better, an option that
> > > defines _which_ mode a *startup* buffer should use.
> > > Two possible variations of this option would be:
> > > ;;; Boolean option
> > > ;; A boolean option that makes *scratch* buffers fire up in
> > > ;; `fundamental-mode' by default. The option would be set to `nil'
> > > ;; by default, but it should be easy to tweak the option once and
> > > ;; keep it set forever.
> > > (defcustom scratch-buffer-uses-fundamental-mode nil
> > > "Non-nil makes the *scratch* buffer use `fundamental-mode'.
> > > Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
> > > If you are not really interested to use `lisp-interaction-mode',
> > > but you would prefer to start all scratch buffers in
> > > `fundamental-mode', to start editing text instead of typing Lisp
> > > expressions, set the `scratch-buffer-uses-fundamental-mode'
> > > variable to a non-nil value."
> > > :type 'boolean
> > > :group 'editing-basics
> > > :group 'convenience)
> > > ;;; A list of choices.
> > > ;; Still set to the default `lisp-interaction-mode'
> > > (defcustom scratch-buffer-startup-mode 'lisp-interaction-mode
> > > "The default mode to use for *scratch* buffers.
> > > If the value is `lisp' start in lisp-interaction-mode.
> > > If the value is `text' start in text-mode.
> > > If the value is `fundamental' start in whatever mode has been
> > > configured as the default `fundamental-mode'.
> > > If the value is a function, use that function to set-up the
> > > startup mode of *scratch* buffers."
> > > :type '(choice (const :tag "Lisp interaction mode" 'lisp)
> > > (const :tag "Text mode" 'text)
> > > (const :tag "Fundamental mode" 'fundamental)
> > > (function :tag "Custom mode"))
> > > :group 'editing-basics
> > > :group 'convenience)
> > > * Add the scratch buffer to the list of buffers that trigger a prompt
> > > if they are modified and the user types `C-x C-c' to leave Emacs.
> > > Right now one can open _one_ scratch buffer only. Emacs uses
> > > `buffer-modified-p' as the only criterion, but this doesn't work for
> > > scratch buffers now. It should probably be an option too, or even a
> > > function that checks `scratch-buffer-startup-mode' and decides. I
> > > haven't thought too much about this yet, so I am not sure if it
> > > sounds like a sensible thing to do.
> > I think your model can complicate the user interface.
> > A simple New menu command (create-empty-buffer) that creates a new
> > buffer in some customizable default mode, solves what you wanted and
> > it gives you extra power.
> > Emacs does not provide a user level function to create a new buffer.
> > It has just New, which actually creates a empty file. Most apps's New
> > command does not work like that. They actually just create a new
> > buffer, and only when user save it it becomes a file.
> > Creating a new buffer is actually quite useful. For example, well
> > known programer Stevey Yegg in his “Effective Emacs” blog list it as a
> > top 10 tip in emacs productivity. The emacs menu should have a New
> > command with Ctrl+n that calls create-empty-buffer.
> > -------------------------
> > PS as i mentioned in previous message, i did implement the above. In
> > my draft code,
> > • create-new-buffer will create a new empty buffer named “untitled”.
> > (this should be added the menu command under
"Is there a limit on how often I can post?
Yes, there are a couple ways in which posting frequency is limited.
One limit is the number of messages posted to any single group within
a short period of time. We also limit the number of messages a single
user or computer can post via our website in a short period of time.
If you reach the first limit, your posting ability will be frozen and
you'll be notified via email. The email will look something like this
message:
Your message could not be posted to the [groupname] group because
there have been too many messages posted to the group recently.
If you run into the second limit, you'll see a notification directly
on the Groups interface.
Please note that we're unable to provide the exact numbers that
trigger these posting limits as they are something we manipulate for
spam fighting purposes."
But I understand this has nothing to do with the actual "limitations"
triggering that (in)famous message ending with
"contact Google Support".
That message is likely triggered or by some "momentary" server
problems, or by detection of a "spike" in Google groups use from an IP
address. That's all.
i tried to post the same message but with rot13 transformation, and it
went thru right off.
So, apparently some string in the message content is ticking off
google's spam detector.
am quite pissed at google. From websites, you can read that there are
some tens of thousand spam blogs using google's blogger and seems
google is doing nothing about it or falling very much behind.
this effect me because in newsgroup or google blog search, when i
search my name (Xah or Xah Lee), half of the results are machine
generated spams. This has been going on for the past 1 year. And now i
can't even post.
-----------------------
Wikipedia: Spam blog↗.
Quote:
Splogs have become a major problem on free blog hosts such as
Google's Blogger service. By one estimate, about one in five blogs are
spam blogs.[1]
[1] = “One in Five Blogs Is Spam” (2005-12-21) By Brian Morrissey.
Adweek. (Source↗ 2008-09)
> I tried to login using another google account, didn't help. I tried to
> post as new message, or even just email thru the email author button,
> it didn't let me neither. Although i was able to reply other message
> in that thread.
> for some reason i suspect it's checking on my message content. Am
> somewhat pissed that i couldn't post my message.
> > It happens very often to me too during the day.......I think it's a
> > limitation Google is generally popping out when it believes an IP has
> > used enough bandwidth for some time!
> > My personal solution is to copy the message, click on the refresh
> > button of my browser. At this point, a captcha is proposed. Once
> > answered it, the thread is proposed again, then I reply, paste the
> > message and send.
> > Seemingly static IPs are more affected than dynamic IPs.
> > And finally, I wouldn't exclude that Google is trying to slow down and
> > discouraging with captchas a heavy use of some - or all - Usenet
> > groups.
> > An anti-spammer measure, but I wouldn't think it's aimed just at you.
> > > however, when i click on post, it says
> > > «We were unable to post your message
> > > If you believe this is an error, please contact Google Support.»
> > > I tried post the message as a new thread, but still same error. No
> > > luck after clearing cookies and relogin and or restart Safari browser.
> > > What's wrong?
> > > I'm suspecting that google is checking the message content and think
> > > it is spam? cause there are lots of spam blogs or spam newsgroup posts
> > > that contains my name “XahLee” or my site and site content
> > > “xahlee.org”. If so, what can i do about it? (i have often reported
> > > such spams thru the report button or google blog help page)
> > > The following is the message content.
> > > ----------------------Xahwrote:
> > > «I think the existance of the lisp scratch buffer is one of the major
> > > usability problem of emacs that prevents emacs from being widely
> > > adopted by most text editing audience.»
> > > Giorgos Keramidas wrote:
> > > > HiXah,
> > > > For what it's worth, I think I would appreciate an option that makes the
> > > > current behavior of the *scratch* buffer tunable, i.e. by an option like:
> > > > (defvar scratch-buffer-uses-fundamental-mode nil
> > > > "Non-nil makes the *scratch* buffer use `fundamental-mode'.
> > > > Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
> > > > If you are not really interested to use `lisp-interaction-mode',
> > > > but you would prefer to start all scratch buffers in
> > > > `fundamental-mode', to start editing text instead of typing Lisp
> > > > expressions, set the `scratch-buffer-uses-fundamental-mode'
> > > > variable to a non-nil value.")
> > > by having a New command with Ctrl+n key, it solves this problem with
> > > scratch plus what you want.
> > > • The New command is a standard across Mac, Windows, Unix (Linux). It
> > > is familiar to all software users.
> > > • The Ctrl+n shortcut for New is standard and familiar to all software
> > > users.
> > > • The New commmand (where the corresponding elisp command name might
> > > will be named new-empty-buffer), can supplant completely the
> > > functionality of *scratch* buffer.
> > > • When users want to have a scratch buffer, he can create it by simply
> > > pressing the shortcut, and when he doesn't want it, he can simply
> > > close it with a standard keystroke Ctrl+w.
> > > • Users can have multiple *scratch* buffers easily without the need to
> > > look into emacs doc.
> > > • The “*scratch*” name is not in some technical jargon sense the best
> > > one. “*untitled*” or “untitled” is a better one, and widely used
> > > across some 99% of OSes and applications. The name “*scratch*” is
> > > unnecessarily narrow, as to indicate that the buffer's content is only
> > > for temp purposes, while “untitled” can include the purpose of
> > > scratch, and can be discarded just as “*scratch*”.
> > > • The respawning of “*scratch*” buffer behavior is unusual, almost
> > > unique to emacs among the thousands of application today. Letting user
> > > have control to create and and discard such buffer is better.
> > > • The “*scratch*” buffer is primarily used by elisp programers. Few
> > > professional programers in the IT industry knows about lisp, and only
> > > minor percentage of emacs users actually code emacs lisp.
> > > > But I don't like the `personal attack' style that this text uses, and I
> > > > don't really agree with *all* the proposed `modernization' features.
> > > The Modernization of Emacs article athttp://xahlee.org/emacs/modernization.html > > > does not have any “personal attack” writing style. Perhaps you were
> > > thinking my other newsgroup posts elsewhere where this issue is
> > > discussed.
> > > > I don't really agree with *all* the proposed `modernization'
> > > > features.
> > > If you agree to some, please file a bug report, or help spread the
> > > idea. Thanks for discussing this issue with me.
> > > > If you were to split that document into smaller `features' and one of
> > > > them was a proposal to add an option for the default mode of *scratch*
> > > > buffers, and a good description of how you would suggest that we add a
> > > > prompt for *scratch* buffers that are modified, I would be more than
> > > > willing to help you with the testing and integration of any patches to
> > > > the main Emacs source tree.
> > > > My own idea about *scratch* buffers that do not fire up only in the
> > > > current `lisp-interaction-mode' state is something like:
> > > > * Add an option that may be set to a non-nil value to make *scratch*
> > > > buffers use `fundamental-mode', or even better, an option that
> > > > defines _which_ mode a *startup* buffer should use.
> > > > Two possible variations of this option would be:
> > > > ;;; Boolean option
> > > > ;; A boolean option that makes *scratch* buffers fire up in
> > > > ;; `fundamental-mode' by default. The option would be set to `nil'
> > > > ;; by default, but it should be easy to tweak the option once and
> > > > ;; keep it set forever.
> > > > (defcustom scratch-buffer-uses-fundamental-mode nil
> > > > "Non-nil makes the *scratch* buffer use `fundamental-mode'.
> > > > Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
> > > > If you are not really interested to use `lisp-interaction-mode',
> > > > but you would prefer to start all scratch buffers in
> > > > `fundamental-mode', to start editing text instead of typing Lisp
> > > > expressions, set the `scratch-buffer-uses-fundamental-mode'
> > > > variable to a non-nil value."
> > > > :type 'boolean
> > > > :group 'editing-basics
> > > > :group 'convenience)
> > > > ;;; A list of choices.
> > > > ;; Still set to the default `lisp-interaction-mode'
> > > > (defcustom scratch-buffer-startup-mode 'lisp-interaction-mode
> > > > "The default mode to use for *scratch* buffers.
> > > > If the value is `lisp' start in lisp-interaction-mode.
> > > > If the value is `text' start in text-mode.
> > > > If the value is `fundamental' start in whatever mode has been
> > > > configured as the default `fundamental-mode'.
> > > > If the value is a function, use that function to set-up the
> > > > startup mode of *scratch* buffers."
> > > > :type '(choice (const :tag "Lisp interaction mode" 'lisp)
> > > > (const :tag "Text mode" 'text)
> > > > (const :tag "Fundamental mode" 'fundamental)
> > > > (function :tag "Custom mode"))
> > > > :group 'editing-basics
> > > > :group 'convenience)
> > > > * Add the scratch buffer to the list of buffers that trigger a prompt
> > > > if they are modified and the user types `C-x C-c' to leave Emacs.
> > > > Right now one can open _one_ scratch buffer only.
