headers
T. V. Raman | 1 Jul 2007 02:18

suggestion: function: buffer-bytes

Emacs built-in buffer-size returns the number of characters ---
in some situations one needs the count of bytes. 
Here is a small function that does this --- perhaps it could be
ncluded in subr.el?

(defsubst buffer-bytes (&optional buffer)
  "Return number of bytes in a buffer."
  (save-excursion
    (and buffer (set-buffer buffer))
    (1- (position-bytes (point-max)))))

--

-- 
Best Regards,
--raman

      
Email:  raman <at> users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv <at> gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs
Permalink | Reply | 13 comments |
headers
Richard Stallman | 1 Jul 2007 02:30
Picon
Picon

Re: highlight current argument in Eldoc for Elisp

Thanks for posting the patch.  Would people please try it
and report any problems?

In a week, if nobody has reported problems, would someone
please install this?

(Paul, if nobody installs it then, please ping us.)
Permalink | Reply | 10 comments |
headers
Richard Stallman | 1 Jul 2007 02:30
Picon
Picon

Re: insert-file-contents and format-decode

     >     We have a plan for dealing with functions called by `format-decode'.  We
     >     do not have a plan yet for dealing with `after-insert-file-functions'.
     >     Shall we treat functions there the same way we treat functions called by
     >     `format-decode'?
     >
     > If it's good for one, it's probably good for the other.  Consistency
     > between the two features is also good.
     >
     > Do you see any reason NOT to do so?

    We could introduce one: Keep `format-decode' for practical use and
    `after-insert-file-functions' for applications that want to fine-tune
    every single step of the decoding process.

Incoherence is a minus, not a plus.  If there is no specific reason
to treat them differentlky, let's treat them the same!

    I already changed my mind: I now think instead that `format-decode' and
    `after-insert-file-functions' _should_ be able to detect whether the
    insertion is done at the beginning of the current buffer or any other
    position (simply by comparing the `begin' argument with `point-min'
    wthout any need to widen the buffer).

If you think that's useful, then let's not insert a save-restriction.

So the only remaining change to be done is to inhibit execution of
certain hooks in `format-decode' and around the calls to
`after-insert-file-functions'.

Would you like to implement this?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richard Stallman | 1 Jul 2007 02:30
Picon
Picon

Re: insert-file-contents and format-decode

    I currently run this in `insert-file-contents' once around the entire
    call sequence for `format-decode' and `after-insert-file-functions'.

That is the right way.

    Do we want undo boundaries before and/or after the insertion?

An editing primitive such as `Finsert_file_contents' should not make
any undo boundaries.  An undo boundary is made by the main editor loop
and by an explicit call to `undo-boundary'.

    I suppose we do not want to disable the hooks for the "non-insert-file"
    case, for example, interactive uses of `format-decode-region'.  Hence,
    your suggestion to handle undo in `insert-file-contents' implies that we
    have to disable these hooks in `insert-file-contents' too.

Right.

    Finally, I'm completely uncertain what to do about `format-insert-file':
    That function explicitly prompts for a format and does `format-decode'
    after inserting the file and running any `after-insert-file-functions'.
    Shall we treat this is as a sequence of

    (insert-file-contents filename nil beg end)

    (let ((format-alist nil))
       (format-decode-region (point) (+ (point) size) format))

    with _two_ `buffer-undo-list' entries and `after-change-functions'
    calls?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richard Stallman | 1 Jul 2007 02:30
Picon
Picon

Re: bad tool-bar icons in Emacs 22.1 release

    Probably it wasn't clear from the quoted context: The binaries on
    <ftp://ftp.gnu.org/gnu/emacs/windows> don't include DLLs required to
    display XPM (tool bar), PNG, JPEG and other images in Emacs.

For convenience, let's put these libraries on the site.
We should distribute the source alongside the binaries,
and we should make sure that the binaries have whatever
notices are required by the licenses.

Who would like to take charge of this?
Permalink | Reply | 10 comments |
headers
Richard Stallman | 1 Jul 2007 02:30
Picon
Picon

Re: Relicensing Emacs to GPLv3

    Just a reminder that when we went through the copyright exercise
    earlier in the year, it seemed to be the case that some of the images
    included in Emacs from Gnome/GTK were under GPLv2 (no "or later").
    Someone may wish to re-check these.

There is no legal conflict about the license of an image that Emacs
merely displays, so this is not a barrier to relicensing.  However, it
is not a good thing that GNOME images are licensed this way.

Can you tell me the specific file names of one or two of these images,
and where they come from in GNOME?

I don't need a complete list, just a couple of examples, fully
described.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Jul 2007 02:30
Picon
Picon

[pp_publiclists <at> yahoo.com: Setting term-default-fg-color/term-default-bg-color has no effect]

This can be installed as a tiny change.  Would someone please check whether
it is a good idea, and DTRT?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.9 required=5.0 tests=FORGED_YAHOO_RCVD,
	SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=no version=3.1.0
To: bug-gnu-emacs <at> gnu.org
From: Peter Povinec <pp_publiclists <at> yahoo.com>
Date: Sat, 30 Jun 2007 00:17:59 +0000 (UTC)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Setting term-default-fg-color/term-default-bg-color has no effect

Hi!

I use ansi-term a lot and like to have different color scheme for my term
buffers.  After upgrading to Emacs22 from 21.4 I notice that my setting of
term-default-fg-color/term-default-bg-color no longer has any effect.  I found
no documentation stating that it was not supported in Emacs22, so I suppose it
is a bug. 

I looked at the old 21.4 code and based on that created the following minimalist
patch, which is satisfactory in addressing the issue.  

HTH,
- --Peter

2007-06-25  Peter Povinec  <ppovinec <at> yahoo.com>

	* term.el: Honor term-default-fg-color and term-default-bg-color
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lennart Borgman (gmail | 1 Jul 2007 02:36
Picon
Gravatar

Re: bad tool-bar icons in Emacs 22.1 release

Richard Stallman wrote:
>     Probably it wasn't clear from the quoted context: The binaries on
>     <ftp://ftp.gnu.org/gnu/emacs/windows> don't include DLLs required to
>     display XPM (tool bar), PNG, JPEG and other images in Emacs.
> 
> For convenience, let's put these libraries on the site.
> We should distribute the source alongside the binaries,
> and we should make sure that the binaries have whatever
> notices are required by the licenses.

If the libraries are not included in the w32 Emacs binary download file 
would it not be better to just link to their locations? That way the 
user will get the latest version whenever he/she downloads the libaries.
Permalink | Reply | 5 comments |
headers
Drew Adams | 1 Jul 2007 02:42
Picon
Favicon

let HISTORY arg to read functions be a list of history variables

1. How about letting the HISTORY argument to read functions (e.g.
`read-string') be a list of history variables, in addition to letting it be
a single history variable? The histories would be appended for user
retrieval. The convention for saving the user input could be either that it
is added to only the first history or that it is added to each of the
histories.

Then, for example, you could write this and let users use a regexp from
either history:

(read-string "Regexp: " nil '(hi-lock-regexp-history regexp-history))

Here, `hi-lock-regexp-history' would presumably be more specific to the task
at hand, so it is placed first. Still, the user has access to more general
regexps from `regexp-history'.

This argument form should cohabit OK with the use of a list argument such as
(HISTORY . POS) to indicate a position, since POS cannot be a non-empty
list. Either we would not allow the position to be specified in the case of
multiple histories, or we would allow it only for the first history - e.g.
((hi-lock-regexp-history . 2) regexp-history).

2. Perhaps(?) even better would be to allow a two-element list as history
argumen: (VARS LIST), where VARS is a list of history variables to update
with the user's entered input and LIST is a history list (not a symbol) to
use for inputting.

That is, let the history to use for `M-p' etc. be an actual history list
(not a variable), and specify separately the history variables to be updated
with the user's entered input. This would let you do more than just append
(Continue reading)

Permalink | Reply | 5 comments |
headers
Drew Adams | 1 Jul 2007 03:07
Picon
Favicon

be able to replace during isearch

I have this feature in Icicles search, but the idea is not dependent on
Icicles. I think that a feature like this would also be useful to add to
isearch.

The idea is that you would not need to leave isearch to perform
replacements. Whenever you wanted to replace the current search occurrence,
you would hit a certain key. The first time you do this, you would be asked
for the replacement string.

The main advantage, besides not needing to exit isearch, is that instead of
being queried for each potential replacement, one by one, you replace only
those you want upon demand. You might not even have the intention of
performing replacement until you happened to notice, while searching, that
you wanted to change something. A minor advantage is that you can also
search-and-replace backward.

Nice-to-haves: In Icicles search, you can use any replacement expression
that is accepted by `query-replace-regexp', and there are additional key
bindings during search to (1) replace all and (2) redefine the replacement
to use. These would also be useful additions for isearch.

I'm not suggesting this as a replacement(!) for query-replace, but as an
enhancement to isearch. Query-replace is a different UI, and each has its
advantages.

Here is a bit more explanation of this feature in Icicles, but, as I say,
the idea is not Icicles-specific:
http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Search-And-Replace.
Permalink | Reply | 4 comments |

Gmane