Below is an implementation that works as follows:
after an attempt to leave the first Info node,
isearch fails with the following message:
Failing I-search: search string [failed in current node]
After leaving the first Info node with subsequent C-s or C-r,
isearch doesn't fail more in other
>> Sorry, I'm probably missing something, but I don't understand how this
>> would work.
>
> Simple: it wouldn't use run-hook* (or maybe it would introduce a new
> run-hook-filter).
Not using a hook seems to be simpler than writing a new run-hook-filter
function. How about the following? It seem
"Lennart Borgman" <[EMAIL PROTECTED]> writes:
> I find it very hard to guess what this define is for without reading the
> code. Using names like HAVE_MOUSE, HAVE_HOURGLASS makes it much more easy to
> guess IMO. And I think that is important if you are scanning the code
> quickly trying to find t
>> Sorry, I'm probably missing something, but I don't understand how this
>> would work. Since each function would only be modifying their own local
>> STRING variable, not the one that will actually be killed...
>
> It doesn't have to modify the variable `string', but its string value,
> e.g.
>
>
- Original Message -
From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> I don't see how this is more readable. One cannot understand the
> meaning of HAVE_HOURGLASS without grepping thru lots of places.
Hm ;-)
There is something I do not understand in your argument. How about
HAVE_MOUSE, HAVE
On Fri, 11 Mar 2005 16:20:56 -0800 (PST), Tak Ota
<[EMAIL PROTECTED]> wrote:
> Many word processors and text editors I know have explicit options to
> opt for "Match case" and "Match whole word only" when searching and
> replacing text strings.
query-replace has a "words-only" mode if you use the
What recent change?! I thought all changes were going to be cleared
through
me.
You stopped maintaining the calendar code long ago, so I asked
Glenn Morris to maintain it. He has been doing this for a year,
and doing a good job.
___
Emacs-d
All the consecutive chars with a non-nil font-lock-multiline property will
always be re-fontified together. E.g. if it is put on three consecutive
lines, a modification on any of the three lines will cause all three to be
re-fontified.
Is there a way they can use font-lock to inst
> All the consecutive chars with a non-nil font-lock-multiline property
> will always be re-fontified together. E.g. if it is put on three
> consecutive lines, a modification on any of the three lines will cause
> all three to be re-fontified.
> Is there a way they can use font-lo
Many word processors and text editors I know have explicit options to
opt for "Match case" and "Match whole word only" when searching and
replacing text strings. These features are not so obvious under
emacs. Though it is not a big deal for seasoned emacs users I cannot
imagine a novice user to d
Not to drag up old discussions, but I was reviewing some old patches that
I still use.
Back in Sep 2003, a request was made to exclude remote files from the
automatic cleanup process that recentf.el runs when it is enabled. The
discussion ended forking off into a discussion of performance of Tram
"Chong Yidong" <[EMAIL PROTECTED]> writes:
>>> I like the idea, but returning a value from a hook is rather
>>> inconvenient -- if there are multiple functions on the hook, which
>>> value should you use eventually?
>>
>>> Perhaps before-kill-functions should get START, END and STRING
>>> as argum
> From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Date: Fri, 11 Mar 2005 19:42:25 +0100
> Cc: [EMAIL PROTECTED], Eli Zaretskii <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> [EMAIL PROTECTED], emacs-devel@gnu.org
>
> From: "Jan D." <[EMAIL PROTECTED]>
>
> > > I believe HAVE_HOURGLASS should go int
You misunderstood: I'm not particularly happy about either of the
*-multiline text-properties. I wrote both of them, but neither of them is
satisfactory, really.
Could you write clearer documentation for them?
Providing a hook where the font lock pattern writer can extended the
It's
just a fact of life that major modes can't really use "new" elisp
features until they've penetrated fully into the installed user base -
after several years and several releases.
We can use this feature right away. There are a few major modes that
are distributed separately
Hi, Richard!
On Thu, 10 Mar 2005, Richard Stallman wrote:
>Even so, it would be several years before major modes could start
>using it in earnest, due to the need to continue supporting older
>Emacs versions.
>Supporting other Emacs versions is a secondary issue. We will start
>usin
- Original Message -
From: "Jan D." <[EMAIL PROTECTED]>
> > I believe HAVE_HOURGLASS should go into src\config.in. There is
> > already an
> > #ifdef HAVE_X_WINDOWS and I suggest putting something like this after
> > that
> > define:
> >
> >/* This is for the hourglass code in vario
> Sorry, I'm probably missing something, but I don't understand how this
> would work.
Simple: it wouldn't use run-hook* (or maybe it would introduce a new
run-hook-filter).
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists
This would require to have some configury stuff that would detect
whether HAVE_HOURGLASS should be defined or not. Since Windows
doesn't run the usual configure script (and neither does the DOS
port), adding such a define will require more hacking in these ports.
Especially since writing a test fo
- Original Message -
From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> > I think it would be much more readable if we had a special define.
>
> Not in this case, IMHO; see below.
>
> > This was my suggestion earlier:
> >
> > > I suggest removing the "#ifdef HAVE_X_WINDOWS" completely or (which
Ed Reingold <[EMAIL PROTECTED]> writes:
> What recent change?! I thought all changes were going to be cleared through
> me.
Glenn Morris is currently listed as maintainer. I don't know when
this changed.
;; Maintainer: Glenn Morris <[EMAIL PROTECTED]>
--
Alan Shutko <[EMAIL PROTECTED]> - I
>> I like the idea, but returning a value from a hook is rather
>> inconvenient -- if there are multiple functions on the hook, which
>> value should you use eventually?
>
>> Perhaps before-kill-functions should get START, END and STRING
>> as arguments where STRING is the result of buffer-substrin
> From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
>
> Date: Fri, 11 Mar 2005 17:03:28 +0100
>
> > HAVE_NTGUI is better than WINDOWSNT here, I think.
>
> I think it would be much more readable if we had a special define.
Not in this case, IMHO; s
- Original Message -
From: "Jason Rumney" <[EMAIL PROTECTED]>
> >>I have implemented code for hourglass on w32 now (or rather I should say
> >>Dave Hunter has done it, I just did a small amount of typing). Could we
> >>please get a decision on the issue above so that it is possible to get
> Date: Fri, 11 Mar 2005 13:44:30 +
> From: Jason Rumney <[EMAIL PROTECTED]>
> CC: Lennart Borgman <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
>
> HAVE_NTGUI is better than WINDOWSNT here, I think.
Agreed.
>>> + (defvar before-kill-functions nil
>>> + "List of functions called on the region before killing.
>>> + This abnormal hook is run before `kill-region' and
>>> + `copy-region-as-kill', with the beginning and end positions of
>>> + the killed region as the arguments.")
>>
>> I think it's usual
> (defvar kill-filters nil
> "List of functions for converting a string before it is killed.
> Each function should accept a single argument, a string, and
> return a string. Whenever a string is killed, it is passed as an
> argument to the first function in the list, and the return value
> of e
I'll stick my hand in the air here and say that I would favour people
putting effort into Cairo support rather than Xft.
Isn't Cairo being used in Gtk now? Could we get Cairo for free by
porting the buffer to Gtk?
GTK 2.6 does not use Cairo, the development version might. As for
"porting the buf
> Or perhaps a different approach:
>
> Run after-kill-hooks (a normal hook!) as the last thing in kill-region
> and copy-region-as-kill, i.e. after putting the string into
> the kill-ring. If necessary, the hooks can modify the head of
> the kill-ring as they please...?
There would be no way for
>> I think it's usually important to keep the property that killing doesn't
>> modify the buffer's text (when used in copy-as-kill), so rather than
>> having before-kill-functions modify the buffer's text just before it's
>> put in the kill-ring, it would be more convenient to make it return the
>>
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> + (defvar before-kill-functions nil
>> + "List of functions called on the region before killing.
>> + This abnormal hook is run before `kill-region' and
>> + `copy-region-as-kill', with the beginning and end positions of
>> + the killed region as the
> Would you like it if isearch failed before proceeding to the
> next Info node?
>
> I would. I suggested this long ago. It should first wrap, as Richard
> suggested. After the entire Info node has been searched, it should
> fail. A subsequent invocation should conti
> + (defvar before-kill-functions nil
> + "List of functions called on the region before killing.
> + This abnormal hook is run before `kill-region' and
> + `copy-region-as-kill', with the beginning and end positions of
> + the killed region as the arguments.")
I think it's usually important to
Eli Zaretskii wrote:
From: "Lennart Borgman" <[EMAIL PROTECTED]>
I have implemented code for hourglass on w32 now (or rather I should say
Dave Hunter has done it, I just did a small amount of typing). Could we
please get a decision on the issue above so that it is possible to get this
working
> From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Cc: "Eli Zaretskii" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
> "Jan D." <[EMAIL PROTECTED]>,
> "David Hunter" <[EMAIL PROTECTED]>,
> "Jason Rumney" <[EMAIL PROTECTED]>,
> "KOBAYASHI Yasuhiro" <[EMAIL PROTECTED]>
> Date: Fri, 1
> If we agree that those hooks are the proper approach, and you can
> write the proper doc for them, this is a trivial change, so I don't
> see why we have to wait.
>
> Especially if that means that longlines.el can go into 22.1.
Okay then. How about this patch?
While writing it, I figured out th
In article <[EMAIL PROTECTED]>, Reiner Steib <[EMAIL PROTECTED]> writes:
> There's a problem with this:
> - Save the attached file as "Latin-7.txt".
> - Start Emacs:
> $ LC_ALL=C emacs -Q Latin-7.txt
> - C-h v buffer-file-coding-system RET gives:
> ,
> | buffer-file-coding-system's value
"Chong Yidong" <[EMAIL PROTECTED]> writes:
> So I guess the best solution is to have an encoding hook for kills, and a
> decoding hook for yanks.
>
> I also think we should wait till after the release before implementing
> this (which hopefully shouldn't be a long wait...)
If we agree that those
I'll stick my hand in the air here and say that I would favour people
putting effort into Cairo support rather than Xft.
Isn't Cairo being used in Gtk now? Could we get Cairo for free by
porting the buffer to Gtk?
--
Geoff Teale
CMed Technology - [EMAIL PROTECTED]
__
> The idea of the yank-handler text property is that certain kill
> strings are encoded specially, and need to be decoded when they are
> yanked. Maybe longlines could use this instead of a new hook for
> yanking.
It is possible to use the yank-handler property to remove the newlines
from longlin
> > Would you like it if isearch failed before proceeding to the
> > next Info node?
> >
> > I would. I suggested this long ago. It should first wrap, as Richard
> > suggested. After the entire Info node has been searched, it should
> > fail. A subsequent invocation should continue th
> Its a bit more subtle than that. GUD tooltips use track-mouse (ordinary
> tooltips work at a lower level and don't rely on events in lisp). For
> a GUD tooltip to work, the lisp-level mouse-movement event must be
> generated in the buffer with the overlay arrow and the mode o
42 matches
Mail list logo
