Thanks for adding thaiword.el to the CVS. Shouldn't it be announced
somehow in the NEWS file? Additionally, I think it would be a good
idea to automatically use thai-forward-word and thai-backward-word
(which are supersets of forward-word and backward-word, respectively)
if `Thai' is selected as
Doing a grep search for `illegal' in the CVS tree of emacs I find many
places where it should be `invalid' instead -- the same holds for
`legal' which should often be replaced with `valid'. It's amazing for
me as an Austrian to see that native English speakers normally don't
make a clear distinct
There's a bug in tpu-edt.el where it defines keys in the global-map on
loading (e.g. when doing M-x customize-group RET emulations RET):
For tpu-edt.el to do this really is a bug.
Can someone fix that?
___
Emacs-devel mailing list
Emacs-devel@g
I am too overloaded to tell you step by step by email what debugger
commands to type. Maybe someone else can do it.
(gdb) p string1=0x40af4785
that told GDB to set the value of string1
to 0x40af4785. I don't think that's what you meant.
(gdb) pr
(88425796 .
That got an erro
A case-insensitive non-word search for `not' _should_ match `*Note'.
I agree.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
I plan to make some updates to files.el, which I submitted earlier.
But I have the following questions about VC. I guess _somebody_ must
know the answer:
1. `(emacs)Branches' contains:
Please note, however, that branches are only supported for RCS at
the moment.
I do not use branches mysel
> >> > (modify-syntax-entry ?\= "_ b12" st) ; comment start ==
> >>
> >> Yes, it seems the problem is that your 2-char comment
> sequence is made
> >> of symbol-chars, so there are cases where the code does
> things like "oh,
> >> here's a symbol, let's skip it" without checking whether
Juri Linkov wrote:
Did you mean "Info-hide-note-references set to nil"?
Yes.
Isearch ignores text with `invisible' text properties and hidden
overlays according to `buffer-invisibility-spec'.
Info-search ignores Info files headers, header lines and Tag Table
nodes.
None of which
Kim Storm wrote:
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Actually, the fact that search does not match `see' when
> Info-hide-note-references is enabled is also confusing, unless one
> knows the internals of Info-hide-note-references. However, it would
> be hard to do anything
> `*Note' _is_ a part of the text. It occurs in the output produced by
> `makeinfo --plaintext', which, since it is entirely plain text, does
> not have _any_ special markers. Anyway, rather than to argue over
> terminology, the important thing is: the user sees it, search has to
> find it. Note
> Info-search operates on plain text Info files without text properties
> set by Info-fontify.
>
> How does that happen? Does Info-fontify sometimes fail to be called?
Info-search searches the text on plain unfontified Info files (sometimes
fontification remains on parts of the Info file
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> How 'bout the patch below which makes no assumption (that I know of) about
>> substitute-in-file-name, and will thus work correctly even with weird
>> magic file name handlers.
>
> Regarding performance of my code: I just bumped into a performance
> pr
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
> In my previous mail I intended to say:
>
>> And the results are that stuff is not found indeed when using
>> isearch.
>
> Good!
>
>> query-replace-regexp, however, still finds it.
>
> Seems like a general prob
[ Please keep the discussions on the mailing-list. ]
>> > (modify-syntax-entry ?\= "_ b12" st) ; comment start ==
>>
>> Yes, it seems the problem is that your 2-char comment sequence is made
>> of symbol-chars, so there are cases where the code does things like "oh,
>> here's a symbol, let
David Kastrup <[EMAIL PROTECTED]> writes:
In my previous mail I intended to say:
> And the results are that stuff is not found indeed when using isearch.
Good!
> query-replace-regexp, however, still finds it.
Seems like a general problem with invisible text and replace.
Should it be fixed?
>
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Actually, the fact that search does not match `see' when
> Info-hide-note-references is enabled is also confusing, unless one
> knows the internals of Info-hide-note-references. However, it would
> be hard to do anything about that one. As I already sa
> How 'bout the patch below which makes no assumption (that I know of) about
> substitute-in-file-name, and will thus work correctly even with weird
> magic file name handlers.
Regarding performance of my code: I just bumped into a performance problem.
The problem is that substitute-in-file-name c
David Kastrup <[EMAIL PROTECTED]> writes:
> I just patched up preview-latex to place the invisible property on the
> overlays it creates (obviously, not the desired default behavior).
> Now this is using overlays, not text properties, but the results
> should be pretty much the same.
>
> And the r
Actually, the fact that search does not match `see' when
Info-hide-note-references is enabled is also confusing, unless one
knows the internals of Info-hide-note-references. However, it would
be hard to do anything about that one. As I already said, to me the
_real_ bug is that the Info-hide-note
> > `*Note' is a special tag, not part of the text.
> `*Note' _is_ a part of the text.
There are obviously different ways of looking at this, and the issue is not
just one of terminology (what we decide to call "text" or "content").
Perhaps we can agree that some people and some progr
Sorry for misspelling your name once more in my previous reply. I do
not know why I keep doing this.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Yuri Linkov wrote:
`*Note' is a special tag, not part of the text.
`*Note' _is_ a part of the text. It occurs in the output produced by
`makeinfo --plaintext', which, since it is entirely plain text, does
not have _any_ special markers. Anyway, rather than to argue over
terminology, the impo
> So I think you should leave the function `image-mode' unchanged
> and define a new function `image-mode-maybe' which does the new job.
> Then the entries in auto-mode-alist can call `image-mode-maybe'
> and `image-mode-maybe' can conditionally call `image-mode'.
>
> Want to try it that way?
I do
> `*Note' is a special tag, not part of the text. For instance,
> Web browsers don't display tags, and don't allow them to interfere
> while searching. Some browsers provide two search modes: search for
> text including link text, and separate mode to search only link text.
> And nobody asks for
Below is an alist of locales and tutorial titles extracted from first lines
of etc/TUTORIAL* files to put onto the link to the corresponding tutorial
depending on the current locale:
If we use that alist, we will have to maintain it every time
we add a new tutorial file.
So how about
Info-search operates on plain text Info files without text properties
set by Info-fontify.
How does that happen? Does Info-fontify sometimes fail to be called?
Anyway, when there are no such text properties, as far as I can see,
there is no problem and no need for any change. Search wil
>It is easy to add a test for Info-hide-note-references, but I think it
>would be more convenient to skip the `*Note ' tag even when it is visible.
>Searching for "not" is too tiresome when search stops at every cross
>reference.
>
> A search for `not' is going to stop at many place
> The current behavior annoys me because I make the French quotation mark
> '«' insert '« »' and put the point between the NBSP, because french
> quotations should be « like this », and if auto-fill mode gets in my way
> while I fill the quotation, I loose the NBSP.
I find NBSP to be a source of
Stefan wrote on 23 Mar 2005 14:34:51 +0100:
>>> Maybe NBSP shouldn't have whitespace syntax.
>> Whaaa? What syntax should it have instead?
>
> I guess punctuation. An NBSP *looks like* whitespace but its intended
> behavior is to not be treated like whitespace (at leasst according to this
> bug
[CVS 2005-03-01]
> Below is an alist of locales and tutorial titles [...]
>
> ("th".
> "à")
For this Thai text string (in UTF-8 encoding) I just get boxes. Doing
`C-u C-x =' I see that the characters are taken from the
`mule-unicode-0100-24ff' charset; the
> (declare (debug (sexp form form form form form &optional stringp)))
> X(define-generic-mode my-mode
> (list ?# ?% (+ 50 9))
> (list "abba" "ebbe" (concat "ob" "bo"))
> nil
> X(list "\\.mm\\'")X
> nil
> "This is My mode.")X
That's because when you execute the call to define-generic-m
BTW, any time you make a branch tag, it's also good to make a
corresponding non-branch `base' tag which is the trunk version the
branch is relative too. This info is deducible (though tiresome to
do) from the branch versions _until_ you decide to merge updates from
the trunk, at which point it's
Title: 2887726
Browse
Search
Shop
My eSoft
Community
Back to Software Overview
Home >
All Categories >
Computers >
Software >
Operating Systems >
Windows
Yuri Linkov wrote:
It is easy to add a test for Info-hide-note-references, but I think it
would be more convenient to skip the `*Note ' tag even when it is visible.
Searching for "not" is too tiresome when search stops at every cross
reference.
A search for `not' is going to stop at m
>>> +(keyboard-translate ?\177 ?\^h)
>>> +(keyboard-translate ?\^h ?\177)
>>
>> Doing it at top-level, means the change is applied when the file is read,
>> which is contrary to coding conventions.
> This is a terminal setup file, so doing it immediately is TRT here.
Oh, right, sorry, I guess I
Stefan <[EMAIL PROTECTED]> writes:
> Doing it at top-level, means the change is applied when the file is
> read, which is contrary to coding conventions.
There's a bug in tpu-edt.el where it defines keys in the global-map on
loading (e.g. when doing M-x customize-group RET emulations RET):
;;;
Le 23 Mar 2005, YAMAMOTO Mitsuharu a dit :
> On Thu, 10 Mar 2005 10:18:02 -0600, Ulrich Hobelmann <[EMAIL PROTECTED]>
> said:
>
> > To make Emacs display the stuff the following works:
>
> > (create-fontset-from-fontset-spec
> > "-apple-monaco-medium-r-normal--12-*-*-*-*-*-fontset-monaco,
> >
I have problems writing a debug declaration for define-generic-mode.
Maybe someone can help me?
define-generic-mode is defined like this:
(defmacro define-generic-mode (mode comment-list keyword-list
font-lock-list auto-mode-list
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Just to make sure: did you check that your patch works correctly when
> Info-hide-note-references is nil, where `not' _should_ match `*Note'?
> Personally, I have not had the time to follow this thread completely,
> but at first view, nothing in this seem
I am not sure what to do next. I tried this:
You need to display the value of regexp in Lisp syntax. That is done
with the pr command.
The problem is that I saw
(gdb) pr
17213013
which did not seem as useful. That is why I showed the results of
(gdb) pp regexp=13
[EMAIL PROTECTED] (Kai =?iso-8859-15?Q?Gro=DFjohann?=) writes:
> org-mode binds C- to move the current line down, but Emacs
> generally binds this to forward-paragraph. IMVHO the two behaviors
> are too different to match well: the general binding is a movement
> command, the org mode binding cha
Juri Linkov wrote:
Info-search operates on plain text Info files without text properties
set by Info-fontify. So it should rely on pure syntactical elements
like `*Note ' tags. This is implemented in my latest patch.
Just to make sure: did you check that your patch works correctly when
Richard Stallman <[EMAIL PROTECTED]> writes:
> 1. Set both `invisible' and `display' properties. It seems the
>display engine ignores the `invisible' property when the `display'
>property is present. But isearch still respects it.
>
> I agree that that way is the best--if we d
First of all, let me say that org-mode is a way cool thing! The
following are minor issues, really.
org-mode has a number of keybindings on S-, but CUA mode uses
S-. IMHO it would be useful to think of other bindings. (There
are bindings for S-, S-, S- and S-, at least.)
org-mode binds C- to m
Stefan <[EMAIL PROTECTED]> writes:
>> +(keyboard-translate ?\177 ?\^h)
>> +(keyboard-translate ?\^h ?\177)
>
> Doing it at top-level, means the change is applied when the file is read,
> which is contrary to coding conventions.
This is a terminal setup file, so doing it immediately is TRT here.
Richard Stallman <[EMAIL PROTECTED]> writes:
> Having the list of languages is good, but I think we also need to
> include a message in the user's language (as derived from the current
> locale), as others have suggested.
Below is an alist of locales and tutorial titles extracted from first lines
>> It seems the problem is due to `back-to-indentation' which skips chars with
>> a "whitespace" syntax and NBSP does have whitespace syntax.
>> Maybe NBSP shouldn't have whitespace syntax.
> Whaaa? What syntax should it have instead?
I guess punctuation. An NBSP *looks like* whitespace but its
> +(keyboard-translate ?\177 ?\^h)
> +(keyboard-translate ?\^h ?\177)
Doing it at top-level, means the change is applied when the file is read,
which is contrary to coding conventions.
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
>> in sh-mode: the $ in $test has syntax 2 = word in perl-mode
>> syntax 10 = character quote and in cperl-mode it's 9 = escape.
>>
>> I think it should at least be unique (I prefer the sh-mode
>> version as you can move the point across variables with M-f and M-b).
I decided the quote syntax for
[EMAIL PROTECTED] (Kim F. Storm) writes:
> Instead we can explicitly put an inivisible property together with the
> display property on a priece of "hidden" text which should be ignored
> by searches. That need a little work to check all uses of display
> properties, but it doesn't break any old c
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Here's a patch to handle debug-on-entry for autoloaded functions and
> compiled macros.
>
> The patch also solves a problem with cancel-debug-on-entry.
> Currently, it signals an error for built-in functions, autoloaded
> functions, and aliases that are
>> (defun gnus-parse-active ()
>> "Parse active info in the nntp server buffer."
>> - (save-excursion
>> -(set-buffer nntp-server-buffer)
>> + (with-current-buffer nntp-server-buffer
>> (goto-char (point-min))
> Are you sure that not saving (and restoring) point in
> nntp-server-buffer doesn
Here's a patch to handle debug-on-entry for autoloaded functions and
compiled macros.
The patch also solves a problem with cancel-debug-on-entry.
Currently, it signals an error for built-in functions, autoloaded
functions, and aliases that are not set to debug-on entry. The patch
makes cancel-d
> On Thu, 10 Mar 2005 10:18:02 -0600, Ulrich Hobelmann <[EMAIL PROTECTED]>
> said:
> To make Emacs display the stuff the following works:
> (create-fontset-from-fontset-spec
> "-apple-monaco-medium-r-normal--12-*-*-*-*-*-fontset-monaco,
> ascii:-apple-monaco-medium-r-normal--12-120-75-75
[EMAIL PROTECTED] (Kim F. Storm) writes:
> Instead we can explicitly put an inivisible property together with
> the display property on a priece of "hidden" text which should be
> ignored by searches. That need a little work to check all uses of
> display properties, but it doesn't break any old
$B40A4L5NA3NDj!*!*!*(B
$B:#$^$G!"[EMAIL PROTECTED],(B
$B9%I>$K$D$-!"A49q3HBg!*!*:#$,%A%c%s%9$G$9!#(B
$B"(%3%3$KEPO?$7$F$k=w$N;R$OK\Ev$G$9!#(B
1.$B5U!{=u4uK>[EMAIL PROTECTED](B
2.$B#S#M4uK>[EMAIL PROTECTED](B
3.$B:#F|[EMAIL PROTECTED](B
4.$BITNQ4uK>[EMAIL PROTECTED](B
[EMAIL PR
David Kastrup <[EMAIL PROTECTED]> writes:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
>> It would be wrong for preview-latex, probably one of the most
>> important applications extensively using the display property.
>>
>> With all due respect, I have not been shown a reason to consid
Miles Bader <[EMAIL PROTECTED]> writes:
> In sh, the $ is not really part of the name, so having
> emacs think it is can be quite annoying (the case that drives me nuts
> is that dynamic-abbrev won't complete `$FO' based on a previous
> `FOO_BAR=...'); this argues for giving the $ a n
58 matches
Mail list logo
