* Re: iso-8859-1 and non-latin-1 chars
@ 2002-11-28 17:01 Dave Love
2002-12-02 15:47 ` Richard Stallman
0 siblings, 1 reply; 50+ messages in thread
From: Dave Love @ 2002-11-28 17:01 UTC (permalink / raw)
On querying a change, handa referred me to a thread which lead to it.
The archive loses threading info, sorry.
> Ok, I've just installed this change.
>
> 2002-11-18 Kenichi Handa <[13]handa@m17n.org>
>
> * language/cyrillic.el (cyrillic-iso-8bit): Make it safe.
>
> * language/european.el (iso-latin-1): Make it safe.
> (iso-latin-2, iso-latin-3, iso-latin-4, iso-latin-5, iso-latin-8)
> (iso-latin-9): Likewise.
>
> * language/greek.el (greek-iso-8bit): Make it safe.
>
> * language/hebrew.el (hebrew-iso-8bit): Make it safe.
>
> * language/lao.el (lao): Make it safe.
>
> * language/thai.el (thai-tis620): Make it safe.
I think this is the wrong thing to do. As rms said, it's a
user-visible change that affects more than Ispell. It breaks the
principle that Emacs tries to avoid losing information in coding
conversions (whereas XEmacs readily trashes data). If something uses
one of these encodings incorrectly now you can't recover the data as
you used to be able to.
Anyhow, if the issue is just Ispell, it's definitely the wrong fix.
ispell.el and similar stuff shouldn't send un-encodable text in the
first place. (If `?' happens to be one of the extra word characters
for Ispell, you'll lose anyway.)
With the development source, you can easily fix what Stefan complained
about as follows. There's more to it than that, though -- see the
comment in the diff. I haven't had time to sort that out, though I
did make changes to Flyspell along similar lines. That's easier,
since Flyspell already works word-wise (roughly), but of course you
likely run into problems displaying the choices without multilingual
menus.
[If you really wanted to fix such a thing just with a coding system
change, you could set up a scratch coding system for the job or
temporarily set a coding system property around the process setup.]
By the way, ispell.el in CVS isn't up-to-date with Stevens' version.
*** ispell.el.~1.133.~ Tue Nov 19 14:49:21 2002
--- ispell.el Mon Nov 25 15:41:02 2002
***************
*** 1347,1364 ****
(or quietly
(message "Checking spelling of %s..."
(funcall ispell-format-word word)))
! (ispell-send-string "%\n") ; put in verbose mode
! (ispell-send-string (concat "^" word "\n"))
! ;; wait until ispell has processed word
! (while (progn
! (ispell-accept-output)
! (not (string= "" (car ispell-filter)))))
! ;;(ispell-send-string "!\n") ;back to terse mode.
! (setq ispell-filter (cdr ispell-filter)) ; remove extra \n
! (if (and ispell-filter (listp ispell-filter))
! (if (> (length ispell-filter) 1)
! (error "Ispell and its process have different character maps")
! (setq poss (ispell-parse-output (car ispell-filter)))))
(cond ((eq poss t)
(or quietly
(message "%s is correct"
--- 1347,1369 ----
(or quietly
(message "Checking spelling of %s..."
(funcall ispell-format-word word)))
! (if (and enable-multibyte-characters
! (unencodable-char-position
! 0 (length word) (process-coding-system ispell-process)
! nil word))
! (setq poss (list word 1 nil nil))
! (ispell-send-string "%\n") ; put in verbose mode
! (ispell-send-string (concat "^" word "\n"))
! ;; wait until ispell has processed word
! (while (progn
! (ispell-accept-output)
! (not (string= "" (car ispell-filter)))))
! ;;(ispell-send-string "!\n") ;back to terse mode.
! (setq ispell-filter (cdr ispell-filter)) ; remove extra \n
! (if (and ispell-filter (listp ispell-filter))
! (if (> (length ispell-filter) 1)
! (error "Ispell and its process have different character maps")
! (setq poss (ispell-parse-output (car ispell-filter))))))
(cond ((eq poss t)
(or quietly
(message "%s is correct"
***************
*** 2604,2609 ****
--- 2609,2628 ----
(let (poss accept-list)
(if (not (numberp shift))
(setq shift 0))
+ (if (and enable-multibyte-characters
+ (fboundp 'unencodable-char-position))
+ ;; Avoid sending un-encodable input to the process, which can
+ ;; specifically confuse the current implementation. Fixme: Do
+ ;; it for 21.2 too. Fixme: The implementation here needs
+ ;; changing to check word-by-word (according to syntax tables,
+ ;; not a fixed list of characters) from known positions in the
+ ;; buffer, not not looking for matches of ispell output (which
+ ;; may be inappropriately encoded, for instance) in the
+ ;; original buffer.
+ (dolist (i (unencodable-char-position
+ 0 (length string) (process-coding-system ispell-process)
+ (length string) string))
+ (aset string i ?\ )))
;; send string to spell process and get input.
(ispell-send-string string)
(while (progn
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-11-28 17:01 iso-8859-1 and non-latin-1 chars Dave Love
@ 2002-12-02 15:47 ` Richard Stallman
2002-12-06 16:38 ` Dave Love
0 siblings, 1 reply; 50+ messages in thread
From: Richard Stallman @ 2002-12-02 15:47 UTC (permalink / raw)
Cc: emacs-devel
> 2002-11-18 Kenichi Handa <[13]handa@m17n.org>
>
> * language/cyrillic.el (cyrillic-iso-8bit): Make it safe.
...
I think this is the wrong thing to do. As rms said, it's a
user-visible change that affects more than Ispell. It breaks the
principle that Emacs tries to avoid losing information in coding
conversions (whereas XEmacs readily trashes data).
It would do that if users explicitly specify these coding systems by
name and if Emacs fails, when they subsequently save the file, to warn
that it can't handle all the characters.
Emacs normally does warn when the coding system doesn't handle all the
characters in the file. Is there a common scenario where that warning
is bypassed?
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-02 15:47 ` Richard Stallman
@ 2002-12-06 16:38 ` Dave Love
2002-12-09 6:08 ` Kenichi Handa
[not found] ` <E18LCz8-0004It-00@fencepost.gnu.org>
0 siblings, 2 replies; 50+ messages in thread
From: Dave Love @ 2002-12-06 16:38 UTC (permalink / raw)
Cc: handa, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> Emacs normally does warn when the coding system doesn't handle all the
> characters in the file. Is there a common scenario where that warning
> is bypassed?
I don't know how common, but for example: broken code (Gnus at times,
I'd bet) or customizations (select Latin-1 for your BBDB database) and
C-x RET c. Basically whenever the coding system is actually specified
rather than selected from the set of somehow-preferred coding systems.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-06 16:38 ` Dave Love
@ 2002-12-09 6:08 ` Kenichi Handa
2002-12-15 16:24 ` Dave Love
[not found] ` <E18LZqb-0007si-00@fencepost.gnu.org>
[not found] ` <E18LCz8-0004It-00@fencepost.gnu.org>
1 sibling, 2 replies; 50+ messages in thread
From: Kenichi Handa @ 2002-12-09 6:08 UTC (permalink / raw)
Cc: emacs-devel
In article <rzqhedrp0f5.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:
> Richard Stallman <rms@gnu.org> writes:
>> Emacs normally does warn when the coding system doesn't handle all the
>> characters in the file. Is there a common scenario where that warning
>> is bypassed?
> I don't know how common, but for example: broken code (Gnus at times,
> I'd bet) or customizations (select Latin-1 for your BBDB database) and
> C-x RET c. Basically whenever the coding system is actually specified
> rather than selected from the set of somehow-preferred coding systems.
Even if we write out a proper escape seqeucne for
unencodable characters in a file, those people who are not
familiar with handling coding systems can't read the file
correctly. If he reads it without C-x RET c, it will be
read as iso-2022-7bit or something like that, not as
iso-latin-1-with-esc. If he doesn't notice it, he will be
in a big confusion. If he reads it with C-x RET c
iso-latin-1, the escape sequence is not decoded, thus he
will see raw ESC codes.
So, my conclusion was that writing out those escape
sequences not only violates the commonly accepted concept
about a coding system, but also doesn't help people that
much.
Richard Stallman <rms@gnu.org> writes:
> If you specify a coding system with C-x RET c, and it doesn't
> handle all the text, should Emacs warn about that?
I think that is better, but, can we distinguish these cases
in Fwrite_region.
(1) coding system is specified by C-x RET c.
(2) coding system is specified by a code:
(let ((coding-system-for-write ...)) ...)
Or, do you think we should warn in both cases?
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-09 6:08 ` Kenichi Handa
@ 2002-12-15 16:24 ` Dave Love
2002-12-16 0:42 ` Kenichi Handa
` (2 more replies)
[not found] ` <E18LZqb-0007si-00@fencepost.gnu.org>
1 sibling, 3 replies; 50+ messages in thread
From: Dave Love @ 2002-12-15 16:24 UTC (permalink / raw)
Cc: emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> Even if we write out a proper escape seqeucne for
> unencodable characters in a file, those people who are not
> familiar with handling coding systems can't read the file
> correctly. If he reads it without C-x RET c, it will be
> read as iso-2022-7bit or something like that, not as
> iso-latin-1-with-esc. If he doesn't notice it, he will be
> in a big confusion. If he reads it with C-x RET c
> iso-latin-1, the escape sequence is not decoded, thus he
> will see raw ESC codes.
Sure, but the cases I'm particularly thinking of are actually
programs, not interactive use. I think it's better to get escape
codes, which can be reconstructed, than to get `?', which can't. I
realize this won't work generally, and will be different for Emacs 22.
In Emacs 22, it would be reasonable to do what yudit does (as far as I
remember) and write representations of the unicodes involved as \uxxxx
or similar.
> So, my conclusion was that writing out those escape
> sequences not only violates the commonly accepted concept
> about a coding system,
What concept do you mean, exactly?
> but also doesn't help people that much.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-15 16:24 ` Dave Love
@ 2002-12-16 0:42 ` Kenichi Handa
2002-12-19 22:35 ` Dave Love
2002-12-16 14:06 ` Stefan Monnier
2002-12-16 16:42 ` Richard Stallman
2 siblings, 1 reply; 50+ messages in thread
From: Kenichi Handa @ 2002-12-16 0:42 UTC (permalink / raw)
Cc: emacs-devel
In article <rzqlm2rfdx0.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:
> Sure, but the cases I'm particularly thinking of are actually
> programs, not interactive use. I think it's better to get escape
> codes, which can be reconstructed, than to get `?', which can't.
Yes, it's better for Emacs, but not for the other programs
(e.g. ispell). And such Emacs Lisp applications that use
wrong coding system should be fixed anyway.
> I realize this won't work generally, and will be different
> for Emacs 22. In Emacs 22, it would be reasonable to do
> what yudit does (as far as I remember) and write
> representations of the unicodes involved as \uxxxx or
> similar.
I was also thinking about that for emacs-unicode. Perhaps
using the same format as yudit is good. And, we'll provide
a command `recover-unencoded-characters'.
>> So, my conclusion was that writing out those escape
>> sequences not only violates the commonly accepted concept
>> about a coding system,
> What concept do you mean, exactly?
For instance, the MIME charset iso-8859-1 can encode Latin-1
chars only, and it's stateless, no escape sequences.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-16 0:42 ` Kenichi Handa
@ 2002-12-19 22:35 ` Dave Love
2002-12-23 6:40 ` Kenichi Handa
0 siblings, 1 reply; 50+ messages in thread
From: Dave Love @ 2002-12-19 22:35 UTC (permalink / raw)
Cc: emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> Yes, it's better for Emacs, but not for the other programs
> (e.g. ispell). And such Emacs Lisp applications that use
> wrong coding system should be fixed anyway.
Yes, my point is that ispell should be fixed, but people are avoiding
the issue. Other programs allow users to set a coding system for some
file and they sometimes set it wrongly; I think I mentioned BBDB
initially as a real example.
> > What concept do you mean, exactly?
>
> For instance, the MIME charset iso-8859-1 can encode Latin-1
> chars only, and it's stateless, no escape sequences.
But the issue is what happens when you tell them to encode something
they can't (safely) encode. They either have to produce some
more-or-less arbitrary result or to arrange to signal an error.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-19 22:35 ` Dave Love
@ 2002-12-23 6:40 ` Kenichi Handa
2002-12-23 12:27 ` Dave Love
0 siblings, 1 reply; 50+ messages in thread
From: Kenichi Handa @ 2002-12-23 6:40 UTC (permalink / raw)
Cc: emacs-devel
In article <rzqbs3h63i5.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:
> Kenichi Handa <handa@m17n.org> writes:
>> Yes, it's better for Emacs, but not for the other programs
>> (e.g. ispell). And such Emacs Lisp applications that use
>> wrong coding system should be fixed anyway.
> Yes, my point is that ispell should be fixed, but people are avoiding
> the issue.
I don't think the program `ispell' itself should be fixed.
When it requires a latin-1 input, sending an ESC sequence is
not good. We can't blame ispell for not interpreting that
ESC sequence properly.
But, ispell.el should be made more robust. When it finds an
unencodable character in a word, perhaps, it should show the
word as a misspelled word to a user instead of sending it to
the ispell program.
> Other programs allow users to set a coding system for some
> file and they sometimes set it wrongly; I think I mentioned BBDB
> initially as a real example.
Then BBDB should call select-safe-coding-system before
siliently using a specified coding system.
>> > What concept do you mean, exactly?
>>
>> For instance, the MIME charset iso-8859-1 can encode Latin-1
>> chars only, and it's stateless, no escape sequences.
> But the issue is what happens when you tell them to encode something
> they can't (safely) encode. They either have to produce some
> more-or-less arbitrary result or to arrange to signal an error.
Yes, or course. But, I think producing "?" is less
surprising than produing an ESC sequence.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-23 6:40 ` Kenichi Handa
@ 2002-12-23 12:27 ` Dave Love
2002-12-25 13:05 ` Kenichi Handa
0 siblings, 1 reply; 50+ messages in thread
From: Dave Love @ 2002-12-23 12:27 UTC (permalink / raw)
Cc: emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> I don't think the program `ispell' itself should be fixed.
I meant ispell.el, though it is unfortunate that we don't have a
spelling program that deals with multibyte encodings as far as I know.
> But, ispell.el should be made more robust. When it finds an
> unencodable character in a word, perhaps, it should show the
> word as a misspelled word to a user instead of sending it to
> the ispell program.
Yes, that's what I've implemented for flyspell. The problem is that
ispell.el sends a whole line to the subprocess (unlike flyspell).
Also it doesn't use the Emacs syntax table to decide what's a word.
> Then BBDB should call select-safe-coding-system before
> siliently using a specified coding system.
No, it should use a general coding system to store all text. I
implemented that, but people have used inappropriate values (either by
setting the relevant variable or via `file-coding-system-alist') and
there could be problems in the transition to the new version.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-23 12:27 ` Dave Love
@ 2002-12-25 13:05 ` Kenichi Handa
2002-12-31 17:14 ` Ken Stevens
` (2 more replies)
0 siblings, 3 replies; 50+ messages in thread
From: Kenichi Handa @ 2002-12-25 13:05 UTC (permalink / raw)
Cc: emacs-devel
In article <rzqr8c89ay9.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:
> Kenichi Handa <handa@m17n.org> writes:
>> I don't think the program `ispell' itself should be fixed.
> I meant ispell.el, though it is unfortunate that we don't have a
> spelling program that deals with multibyte encodings as far as I know.
Sure. Though, I see this mail in linux-utf8 mailing list.
On Wed Feb 6 16:18:23 2002 +0300 Maxim N. Bychkov wrote:
>>Good day.
>>
>>Could anybody explain me how to use unicode symbols in Ispell?
>>
>>Thank you in advance.
>>
>
>AFAIK you can't. But some ispell dictionaries, like
>esperanto, have a hack for command line -Tutf8 option to
>spellcheck UTF-8 text.
>> But, ispell.el should be made more robust. When it finds an
>> unencodable character in a word, perhaps, it should show the
>> word as a misspelled word to a user instead of sending it to
>> the ispell program.
> Yes, that's what I've implemented for flyspell. The problem is that
> ispell.el sends a whole line to the subprocess (unlike flyspell).
> Also it doesn't use the Emacs syntax table to decide what's a word.
But, I think it's not that difficult to fix this behaviour
so that it breaks a line at an unencodable word.
>> Then BBDB should call select-safe-coding-system before
>> siliently using a specified coding system.
> No, it should use a general coding system to store all
> text.
If that is possible (i.e. users allows that), yes. But,
why calling select-safe-coding-system is not good?
> I implemented that, but people have used inappropriate
> values (either by setting the relevant variable or via
> `file-coding-system-alist') and there could be problems in
> the transition to the new version.
Those people should have already encountered a problem as I
wrote before because they can't decode a text back with the
same coding system.
By the way, the function choose_write_coding_system ()
checks a coding system specified in file-coding-system-alist
by select-safe-coding-system.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-25 13:05 ` Kenichi Handa
@ 2002-12-31 17:14 ` Ken Stevens
2003-01-06 19:28 ` Dave Love
2003-01-06 19:18 ` Dave Love
2003-01-06 19:19 ` Dave Love
2 siblings, 1 reply; 50+ messages in thread
From: Ken Stevens @ 2002-12-31 17:14 UTC (permalink / raw)
Cc: emacs-devel
Kenichi Handa writes:
> >> I don't think the program `ispell' itself should be fixed.
>
> > I meant ispell.el, though it is unfortunate that we don't have a
> > spelling program that deals with multibyte encodings as far as I know.
>
> Sure. Though, I see this mail in linux-utf8 mailing list.
Ispell _does_ support multibyte characters. This was one of the
historical reasons ispell.el did not use emacs syntax tables to
determine word boundaries. (It supported latex words that included
escape sequences such as \'{o}, etc.)
I am not sure what it would take to support all the internal emacs
encodings, or if this would be the best approach. New libraries would
need to be built with the new syntax.
I have cc'ed Geoff Kuenning, since he is the ispell author.
regards -Ken
__________________________________________________________________________
Ken Stevens e-mail: k.stevens@ieee.org
http://www.kdstevens.com/~stevens/ispell-page.html
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-31 17:14 ` Ken Stevens
@ 2003-01-06 19:28 ` Dave Love
0 siblings, 0 replies; 50+ messages in thread
From: Dave Love @ 2003-01-06 19:28 UTC (permalink / raw)
Cc: Kenichi Handa
Ken Stevens <kstevens@ichips.intel.com> writes:
> Ispell _does_ support multibyte characters. This was one of the
> historical reasons ispell.el did not use emacs syntax tables to
> determine word boundaries. (It supported latex words that included
> escape sequences such as \'{o}, etc.)
I didn't think that's really the same thing, but it's a long time
since I hacked on ispell. Also, I don't see why Emacs couldn't match
such words the same as ispell.
Anyhow, as I don't know, what does one have to do to create and use a
dictionary for utf-8 text? I could probably add support for that.
> I am not sure what it would take to support all the internal emacs
> encodings, or if this would be the best approach.
It is only _external_ encodings that are relevant, and perhaps only
utf-8. [I don't know if spell-checking actually makes sense in the
Oriental languages which typically use the multibyte iso-2022
encodings.]
Note that Emacs could cope now with checking utf-8-encoded text
against a dictionary for an 8-bit character set as long as the text
concerned can be encoded in that set. The text will be appropriately
encoded when it is sent to the subprocess. I think that really
requires using Emacs's (multibyte) syntax tables, though.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-25 13:05 ` Kenichi Handa
2002-12-31 17:14 ` Ken Stevens
@ 2003-01-06 19:18 ` Dave Love
2003-01-07 13:01 ` Kenichi Handa
2003-01-06 19:19 ` Dave Love
2 siblings, 1 reply; 50+ messages in thread
From: Dave Love @ 2003-01-06 19:18 UTC (permalink / raw)
Cc: emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> > No, it should use a general coding system to store all
> > text.
>
> If that is possible (i.e. users allows that), yes.
They should not change it, but... (BBDB originally had no encoding
support, and some people took part of my advice to add .bbdb to
`file-coding-system-alist', but chose to ignore the actual coding
system :-(.)
> But, why calling select-safe-coding-system is not good?
It's not relevant. You need to be able to store all text in the file,
not just Latin-1 names, for instance. It's the same issue as for
auto-save files &c.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2003-01-06 19:18 ` Dave Love
@ 2003-01-07 13:01 ` Kenichi Handa
2003-01-10 10:59 ` Dave Love
0 siblings, 1 reply; 50+ messages in thread
From: Kenichi Handa @ 2003-01-07 13:01 UTC (permalink / raw)
Cc: emacs-devel
In article <rzq3co6dr3u.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:
> Kenichi Handa <handa@m17n.org> writes:
>> > No, it should use a general coding system to store all
>> > text.
>>
>> If that is possible (i.e. users allows that), yes.
> They should not change it, but... (BBDB originally had no encoding
> support, and some people took part of my advice to add .bbdb to
> `file-coding-system-alist', but chose to ignore the actual coding
> system :-(.)
>> But, why calling select-safe-coding-system is not good?
> It's not relevant. You need to be able to store all text in the file,
> not just Latin-1 names, for instance. It's the same issue as for
> auto-save files &c.
In that case, anyway using latin-1 is not appropriate.
Instead of enabling latin-1 to save all characters, bbdb
should be modified to use a better coding system.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-25 13:05 ` Kenichi Handa
2002-12-31 17:14 ` Ken Stevens
2003-01-06 19:18 ` Dave Love
@ 2003-01-06 19:19 ` Dave Love
2 siblings, 0 replies; 50+ messages in thread
From: Dave Love @ 2003-01-06 19:19 UTC (permalink / raw)
Cc: emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> > I meant ispell.el, though it is unfortunate that we don't have a
> > spelling program that deals with multibyte encodings as far as I know.
>
> Sure. Though, I see this mail in linux-utf8 mailing list.
I assumed ispell could be made to work with utf-8, though I've never
tried. The most unfortunate thing is that GNU Aspell seems to have
rejected multibyte when it had the opportunity to DTRT.
> But, I think it's not that difficult to fix this behaviour
> so that it breaks a line at an unencodable word.
Not that hard, but what is a word is somewhat complicated. I don't
know if there's any real advantage to presenting a whole line rather
than a word at a time, which seems to work OK for flyspell.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-15 16:24 ` Dave Love
2002-12-16 0:42 ` Kenichi Handa
@ 2002-12-16 14:06 ` Stefan Monnier
2002-12-19 22:33 ` Dave Love
2002-12-16 16:42 ` Richard Stallman
2 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2002-12-16 14:06 UTC (permalink / raw)
Cc: Kenichi Handa
> > So, my conclusion was that writing out those escape
> > sequences not only violates the commonly accepted concept
> > about a coding system,
> What concept do you mean, exactly?
One of the problems is that before the recent change, iso-latin-1 was
sometimes outputting non-latin-1 characters (i.e. bytes between
128 and 160). That breaks ispell and can break other programs as well.
Stefan
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-16 14:06 ` Stefan Monnier
@ 2002-12-19 22:33 ` Dave Love
0 siblings, 0 replies; 50+ messages in thread
From: Dave Love @ 2002-12-19 22:33 UTC (permalink / raw)
Cc: Kenichi Handa
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> One of the problems is that before the recent change, iso-latin-1 was
> sometimes outputting non-latin-1 characters (i.e. bytes between
> 128 and 160). That breaks ispell and can break other programs as well.
As I said, any such problems need fixing in ispell.el and friends.
However, I don't think the above causes ispell misalignment errors --
the original complaint (due to iso 2022 escape sequences being
produced). Anyway, the current code does nothing about C1 characters,
and there's no parameter to change that behaviour:
(memq 'iso-latin-1
(find-coding-systems-string (string (make-char 'latin-iso8859-1 #xa3)
128
(make-char 'latin-iso8859-2 #xa3))))
=> nil
(encode-coding-string (string (make-char 'latin-iso8859-1 #xa3)
128
(make-char 'latin-iso8859-2 #xa3))
'iso-latin-1)
=> "\243\200?"
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-15 16:24 ` Dave Love
2002-12-16 0:42 ` Kenichi Handa
2002-12-16 14:06 ` Stefan Monnier
@ 2002-12-16 16:42 ` Richard Stallman
2 siblings, 0 replies; 50+ messages in thread
From: Richard Stallman @ 2002-12-16 16:42 UTC (permalink / raw)
Cc: handa
Sure, but the cases I'm particularly thinking of are actually
programs, not interactive use. I think it's better to get escape
codes, which can be reconstructed, than to get `?', which can't.
Please describe one of these cases *precisely*, so we can see if we
agree with you.
^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <E18LZqb-0007si-00@fencepost.gnu.org>]
* Re: iso-8859-1 and non-latin-1 chars
[not found] ` <E18LZqb-0007si-00@fencepost.gnu.org>
@ 2002-12-15 16:25 ` Dave Love
2002-12-16 16:42 ` Richard Stallman
0 siblings, 1 reply; 50+ messages in thread
From: Dave Love @ 2002-12-15 16:25 UTC (permalink / raw)
Cc: handa
Richard Stallman <rms@gnu.org> writes:
> I suspect that in case 2 we sometimes want it to warn,
> but I am not certain. I think that making it warn in case 2
> is a good idea to start with.
No. That would significantly slow down the output operations. The
warning messages would typically be obscure to users anyhow, since
they'd come from the guts of packages.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-15 16:25 ` Dave Love
@ 2002-12-16 16:42 ` Richard Stallman
0 siblings, 0 replies; 50+ messages in thread
From: Richard Stallman @ 2002-12-16 16:42 UTC (permalink / raw)
Cc: handa
> I suspect that in case 2 we sometimes want it to warn,
> but I am not certain. I think that making it warn in case 2
> is a good idea to start with.
No. That would significantly slow down the output operations.
Would you explain why you think so? Given that in many cases Emacs
does check for such a problem and warn, in the usual case, why should
doing so in other cases cause any concern about speed?
^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <E18LCz8-0004It-00@fencepost.gnu.org>]
* Re: iso-8859-1 and non-latin-1 chars
[not found] ` <E18LCz8-0004It-00@fencepost.gnu.org>
@ 2002-12-10 23:47 ` Dave Love
2002-12-11 20:39 ` Richard Stallman
0 siblings, 1 reply; 50+ messages in thread
From: Dave Love @ 2002-12-10 23:47 UTC (permalink / raw)
Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> If you specify a coding system with C-x RET c, and it doesn't
> handle all the text, should Emacs warn about that?
I don't think so. That would amount to a significant overhead on all
i/o, since C-x RET c just amounts to binding
coding-system-for-{read,write} around the invocation of the command.
Perhaps you could special-case it somehow in interactive use, but the
issue is most relevant to the other case -- when data are written by a
program with an inappropriate coding system. You presumably can't do
anything about it for process output anyhow.
Is anyone actually taking care of the issues in Ispell/Flyspell?
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-10 23:47 ` Dave Love
@ 2002-12-11 20:39 ` Richard Stallman
2002-12-13 2:58 ` Kenichi Handa
0 siblings, 1 reply; 50+ messages in thread
From: Richard Stallman @ 2002-12-11 20:39 UTC (permalink / raw)
Cc: emacs-devel
> If you specify a coding system with C-x RET c, and it doesn't
> handle all the text, should Emacs warn about that?
I don't think so. That would amount to a significant overhead on all
i/o, since C-x RET c just amounts to binding
coding-system-for-{read,write} around the invocation of the command.
It could also bind a flag saying "do warn".
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-11 20:39 ` Richard Stallman
@ 2002-12-13 2:58 ` Kenichi Handa
2002-12-14 18:31 ` Richard Stallman
0 siblings, 1 reply; 50+ messages in thread
From: Kenichi Handa @ 2002-12-13 2:58 UTC (permalink / raw)
Cc: emacs-devel
In article <E18MDdz-0005Mz-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>> If you specify a coding system with C-x RET c, and it doesn't
>> handle all the text, should Emacs warn about that?
> I don't think so. That would amount to a significant overhead on all
> i/o, since C-x RET c just amounts to binding
> coding-system-for-{read,write} around the invocation of the command.
> It could also bind a flag saying "do warn".
How about the attached change? Shall I install it?
Notes on the change:
(1) I made a new variable coding-system-require-warning, and
universal-coding-system-argument binds it to t.
(2) If car of the arg DEFAULT-CODING-SYSTEM is t, it
indicates that select-safe-coding-system should not include
buffer-file-coding-system and most preferred coding system
in a list of coding systems tried by default.
Fwrite_region calls select-safe-coding-system in this way if
coding-system-require-warning is non-nil.
(3) Now a user can specify any coding system in
select-safe-coding-system on his risk. At least, this is
necessary when an unsafe coding sysetm is specified by C-x
RET c.
---
Ken'ichi HANDA
handa@m17n.org
Index: lisp/ChangeLog
===================================================================
RCS file: /cvs/emacs/lisp/ChangeLog,v
retrieving revision 1.4625
diff -u -c -b -r1.4625 ChangeLog
*** lisp/ChangeLog 13 Dec 2002 00:40:52 -0000 1.4625
--- lisp/ChangeLog 13 Dec 2002 02:51:25 -0000
***************
*** 1,3 ****
--- 1,12 ----
+ 2002-12-13 Kenichi Handa <handa@m17n.org>
+
+ * international/mule-cmds.el (universal-coding-system-argument):
+ Bind coding-system-require-warning to t.
+ (select-safe-coding-system): Handle t in the arg
+ DEFAULT-CODING-SYSTEM specially. Use read-coding-system to read a
+ coding-system to allow users to specify unsafe coding system on
+ their risk.
+
2002-12-13 Nick Roberts <nick@nick.uklinux.net>
* gdb-ui.el: Improve documentation strings.
Index: lisp/international/mule-cmds.el
===================================================================
RCS file: /cvs/emacs/lisp/international/mule-cmds.el,v
retrieving revision 1.211
diff -u -c -b -r1.211 mule-cmds.el
*** lisp/international/mule-cmds.el 12 Dec 2002 00:51:31 -0000 1.211
--- lisp/international/mule-cmds.el 13 Dec 2002 02:51:30 -0000
***************
*** 305,310 ****
--- 305,311 ----
(let ((coding-system-for-read coding-system)
(coding-system-for-write coding-system)
+ (coding-system-require-warning t)
(current-prefix-arg prefix))
(message "")
(call-interactively cmd))))
***************
*** 604,610 ****
Optional 3rd arg DEFAULT-CODING-SYSTEM specifies a coding system or a
list of coding systems to be prepended to the default coding system
! list.
Optional 4th arg ACCEPT-DEFAULT-P, if non-nil, is a function to
determine the acceptability of the silently selected coding system.
--- 605,614 ----
Optional 3rd arg DEFAULT-CODING-SYSTEM specifies a coding system or a
list of coding systems to be prepended to the default coding system
! list. However, if DEFAULT-CODING-SYSTEM is a list and the first
! element is t, the cdr part is used as the defualt coding system list,
! i.e. `buffer-file-coding-system' and the most prepended coding system
! is not used.
Optional 4th arg ACCEPT-DEFAULT-P, if non-nil, is a function to
determine the acceptability of the silently selected coding system.
***************
*** 624,634 ****
--- 628,644 ----
(not (listp default-coding-system)))
(setq default-coding-system (list default-coding-system)))
+ (let ((no-other-defaults nil))
+ (if (eq (car default-coding-system) t)
+ (setq no-other-defaults t
+ default-coding-system (cdr default-coding-system)))
+
;; Change elements of the list to (coding . base-coding).
(setq default-coding-system
(mapcar (function (lambda (x) (cons x (coding-system-base x))))
default-coding-system))
+ (unless no-other-defaults
;; If buffer-file-coding-system is not nil nor undecided, append it
;; to the defaults.
(if buffer-file-coding-system
***************
*** 653,659 ****
(not (assq preferred default-coding-system))
(not (rassq base default-coding-system))
(setq default-coding-system
! (append default-coding-system (list (cons preferred base))))))
(if select-safe-coding-system-accept-default-p
(setq accept-default-p select-safe-coding-system-accept-default-p))
--- 663,670 ----
(not (assq preferred default-coding-system))
(not (rassq base default-coding-system))
(setq default-coding-system
! (append default-coding-system
! (list (cons preferred base))))))))
(if select-safe-coding-system-accept-default-p
(setq accept-default-p select-safe-coding-system-accept-default-p))
***************
*** 821,840 ****
(mapcar (function (lambda (x) (princ " ") (princ x)))
codings)
(insert "\n")
! (fill-region-as-paragraph pos (point)))))
;; Read a coding system.
! (if safe
! (setq codings (append safe codings)))
! (let* ((safe-names (mapcar (lambda (x) (list (symbol-name x)))
! codings))
! (name (completing-read
(format "Select coding system (default %s): "
! (car codings))
! safe-names nil t nil nil
! (car (car safe-names)))))
! (setq last-coding-system-specified (intern name)
! coding-system last-coding-system-specified)))
(kill-buffer "*Warning*")
(set-window-configuration window-configuration)))
--- 832,850 ----
(mapcar (function (lambda (x) (princ " ") (princ x)))
codings)
(insert "\n")
! (fill-region-as-paragraph pos (point)))
! (insert "Or specify any other coding system
! on your risk of loosing the problematic characters.\n")))
;; Read a coding system.
! (setq default-coding-system (or (car safe) (car codings)))
! (setq coding-system
! (read-coding-system
(format "Select coding system (default %s): "
! default-coding-system)
! default-coding-system))
! (setq last-coding-system-specified coding-system))
!
(kill-buffer "*Warning*")
(set-window-configuration window-configuration)))
Index: src/ChangeLog
===================================================================
RCS file: /cvs/emacs/src/ChangeLog,v
retrieving revision 1.2994
diff -u -c -b -r1.2994 ChangeLog
*** src/ChangeLog 13 Dec 2002 02:35:34 -0000 1.2994
--- src/ChangeLog 13 Dec 2002 02:51:31 -0000
***************
*** 1,5 ****
--- 1,17 ----
2002-12-13 Kenichi Handa <handa@m17n.org>
+ * coding.c (coding_system_require_warning): New variable.
+ (syms_of_coding): DEFVAR it.
+
+ * coding.h (coding_system_require_warning): Extern it.
+
+ * fileio.c (choose_write_coding_system): Even if
+ Vcoding_system_for_write is non-nil, if
+ coding_system_require_warning is nonzero, call
+ Vselect_safe_coding_system_function.
+
+ 2002-12-13 Kenichi Handa <handa@m17n.org>
+
* coding.c (Funencodable_char_position): Set pend correctly.
2002-12-12 Jason Rumney <jasonr@gnu.org>
Index: src/coding.c
===================================================================
RCS file: /cvs/emacs/src/coding.c,v
retrieving revision 1.265
diff -u -c -b -r1.265 coding.c
*** src/coding.c 13 Dec 2002 02:35:51 -0000 1.265
--- src/coding.c 13 Dec 2002 02:51:33 -0000
***************
*** 367,372 ****
--- 367,374 ----
Lisp_Object Vselect_safe_coding_system_function;
+ int coding_system_require_warning;
+
/* Mnemonic string for each format of end-of-line. */
Lisp_Object eol_mnemonic_unix, eol_mnemonic_dos, eol_mnemonic_mac;
/* Mnemonic string to indicate format of end-of-line is not yet
***************
*** 7530,7535 ****
--- 7532,7546 ----
The default value is `select-safe-coding-system' (which see). */);
Vselect_safe_coding_system_function = Qnil;
+
+ DEFVAR_BOOL ("coding-system-require-warning",
+ &coding_system_require_warning,
+ doc: /* Internal use only.
+ If non-nil, on writing a file, select-safe-coding-system-function is
+ called even if coding-system-for-write is non-nil. The command
+ universal-coding-system-argument binds this variable to t temporarily. */);
+ coding_system_require_warning = 0;
+
DEFVAR_LISP ("char-coding-system-table", &Vchar_coding_system_table,
doc: /* Char-table containing safe coding systems of each characters.
Index: src/coding.h
===================================================================
RCS file: /cvs/emacs/src/coding.h,v
retrieving revision 1.64
diff -u -c -b -r1.64 coding.h
*** src/coding.h 19 Jul 2002 14:27:01 -0000 1.64
--- src/coding.h 13 Dec 2002 02:51:33 -0000
***************
*** 705,710 ****
--- 705,714 ----
system. */
extern Lisp_Object Vselect_safe_coding_system_function;
+ /* If nonzero, on writing a file, Vselect_safe_coding_system_function
+ is called even if Vcoding_system_for_write is non-nil. */
+ extern int coding_system_require_warning;
+
/* Coding system for file names, or nil if none. */
extern Lisp_Object Vfile_name_coding_system;
Index: src/fileio.c
===================================================================
RCS file: /cvs/emacs/src/fileio.c,v
retrieving revision 1.467
diff -u -c -b -r1.467 fileio.c
*** src/fileio.c 7 Dec 2002 21:39:50 -0000 1.467
--- src/fileio.c 13 Dec 2002 02:51:34 -0000
***************
*** 4624,4630 ****
--- 4624,4638 ----
if (auto_saving)
val = Qnil;
else if (!NILP (Vcoding_system_for_write))
+ {
val = Vcoding_system_for_write;
+ if (coding_system_require_warning
+ && !NILP (Ffboundp (Vselect_safe_coding_system_function)))
+ /* Confirm that VAL can surely encode the current region. */
+ val = call5 (Vselect_safe_coding_system_function,
+ start, end, Fcons (Qt, Fcons (val, Qnil)),
+ Qnil, filename);
+ }
else
{
/* If the variable `buffer-file-coding-system' is set locally,
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: iso-8859-1 and non-latin-1 chars
2002-12-13 2:58 ` Kenichi Handa
@ 2002-12-14 18:31 ` Richard Stallman
2002-12-17 11:41 ` None Kenichi Handa
0 siblings, 1 reply; 50+ messages in thread
From: Richard Stallman @ 2002-12-14 18:31 UTC (permalink / raw)
Cc: emacs-devel
Notes on the change:
(1) I made a new variable coding-system-require-warning, and
universal-coding-system-argument binds it to t.
(2) If car of the arg DEFAULT-CODING-SYSTEM is t, it
indicates that select-safe-coding-system should not include
buffer-file-coding-system and most preferred coding system
in a list of coding systems tried by default.
Fwrite_region calls select-safe-coding-system in this way if
coding-system-require-warning is non-nil.
(3) Now a user can specify any coding system in
select-safe-coding-system on his risk. At least, this is
necessary when an unsafe coding sysetm is specified by C-x
RET c.
I didn't have time to read the code (sorry), but that sounds ok to me.
^ permalink raw reply [flat|nested] 50+ messages in thread
* None
2002-12-14 18:31 ` Richard Stallman
@ 2002-12-17 11:41 ` Kenichi Handa
0 siblings, 0 replies; 50+ messages in thread
From: Kenichi Handa @ 2002-12-17 11:41 UTC (permalink / raw)
Cc: emacs-devel
In article <E18NH4s-0003g1-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> Notes on the change:
> (1) I made a new variable coding-system-require-warning, and
> universal-coding-system-argument binds it to t.
> (2) If car of the arg DEFAULT-CODING-SYSTEM is t, it
> indicates that select-safe-coding-system should not include
> buffer-file-coding-system and most preferred coding system
> in a list of coding systems tried by default.
> Fwrite_region calls select-safe-coding-system in this way if
> coding-system-require-warning is non-nil.
> (3) Now a user can specify any coding system in
> select-safe-coding-system on his risk. At least, this is
> necessary when an unsafe coding sysetm is specified by C-x
> RET c.
> I didn't have time to read the code (sorry), but that sounds ok to me.
I've just installed it in HEAD.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 50+ messages in thread
* (no subject)
@ 2024-04-11 14:43 Sébastien Gendre
2024-04-11 14:56 ` none Fraga, Eric
0 siblings, 1 reply; 50+ messages in thread
From: Sébastien Gendre @ 2024-04-11 14:43 UTC (permalink / raw)
To: emacs-orgmode
Hello,
When I try to execute a block of PlantUML in an Org document, I get an
error message:
"org-babel-execute-src-block: No org-babel-execute function for plantuml!"
I have configured Org mode to enable execution of plantUML source block
by adding this in my init.el:
(setq plantuml-default-exec-mode 'executable)
(setq org-plantuml-exec-mode 'plantuml)
(add-to-list
'org-babel-load-languages
'(plantuml . t))
Here is an example of PlantUML block:
#+begin_src plantuml :file ./images/FPGA/DCC/
@startuml
robust "Signal DCC" as DCC_sign
DCC_sign has +U,0,-U
@DCC_sign
0 is +U
+58 is -U
+58 is +U
+100 is -U
+100 is +U
+100 is -U
+100 is +U
+58 is -U
+58 is +U
+100 is -U
+100 is +U
+58 is -U
+58 is +U
+58 is -U
+58 is +U
+100 is -U
+100 is +U
@enduml
#+end_src
My version of Org-mode is: 9.6.15
What did I miss ?
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2024-04-11 14:43 Sébastien Gendre
@ 2024-04-11 14:56 ` Fraga, Eric
0 siblings, 0 replies; 50+ messages in thread
From: Fraga, Eric @ 2024-04-11 14:56 UTC (permalink / raw)
To: Sébastien Gendre; +Cc: emacs-orgmode
On Thursday, 11 Apr 2024 at 16:43, Sébastien Gendre wrote:
> When I try to execute a block of PlantUML in an Org document, I get an
> error message:
> [...]
> (setq plantuml-default-exec-mode 'executable)
> (setq org-plantuml-exec-mode 'plantuml)
I don't have either of these setq lines but I do have:
(setq org-plantuml-jar-path (expand-file-name "/usr/share/plantuml/plantuml.jar"))
I'm not sure what those settings you have defined are meant to do.
--
: Eric S Fraga, with org release_9.6.23-1314-g945046 in Emacs 30.0.50
^ permalink raw reply [flat|nested] 50+ messages in thread
* (unknown)
@ 2024-03-13 12:48 Eli Zaretskii
2024-03-13 13:57 ` none Po Lu
0 siblings, 1 reply; 50+ messages in thread
From: Eli Zaretskii @ 2024-03-13 12:48 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
> From: Po Lu <luangruo@yahoo.com>
> Date: Tue, 12 Mar 2024 23:02:10 -0400 (EDT)
>
> branch: master
> commit 6b40d557c4a9a4152565c1a1b0da49a1aaaec84f
> Author: Po Lu <luangruo@yahoo.com>
> Commit: Po Lu <luangruo@yahoo.com>
>
> Port more notification senders to non-XDG systems
>
> * doc/lispref/os.texi (Desktop Notifications): Document that
> `:timeout' is now implemented.
>
> * java/org/gnu/emacs/EmacsDesktopNotification.java
> (EmacsDesktopNotification): New field delay.
> (display1): Set delay on Android 8.0 and up.
>
> * lisp/erc/erc-desktop-notifications.el
> (erc-notifications-notify): Call Android or Haiku notification
> functions on those systems.
>
> * lisp/gnus/gnus-notifications.el (gnus-notifications-action)
> (gnus-notification-close): Remove dismissed notifications from
> the notification to message map.
> (gnus-notifications-notify): Call android-notifications-notify
> if possible.
>
> * src/androidselect.c (android_init_emacs_desktop_notification):
> Update accordingly.
> (android_notifications_notify_1): New argument TIMEOUT.
> (Fandroid_notifications_notify): New argument QCtimeout.
> (syms_of_androidselect) <QCtimeout>: New symbol.
This causes the following byte-compilation warning:
In gnus-notification-close:
gnus/gnus-notifications.el:91:36: Warning: Unused lexical argument `reason'
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2024-03-13 12:48 (unknown) Eli Zaretskii
@ 2024-03-13 13:57 ` Po Lu
2024-03-13 14:40 ` none Eric Abrahamsen
0 siblings, 1 reply; 50+ messages in thread
From: Po Lu @ 2024-03-13 13:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> This causes the following byte-compilation warning:
>
> In gnus-notification-close:
> gnus/gnus-notifications.el:91:36: Warning: Unused lexical argument `reason'
Thanks, I'll fix this tomorrow, though you could also install the
obvious change now:
diff --git a/lisp/gnus/gnus-notifications.el b/lisp/gnus/gnus-notifications.el
index 9ef21c91627..9c524de8ec4 100644
--- a/lisp/gnus/gnus-notifications.el
+++ b/lisp/gnus/gnus-notifications.el
@@ -88,7 +88,7 @@ gnus-notifications-action
;; an action of theirs) are selected
(assoc-delete-all id gnus-notifications-id-to-msg))
-(defun gnus-notification-close (id reason)
+(defun gnus-notification-close (id _reason)
"Remove ID from the alist of notification identifiers to messages.
REASON is ignored."
(assoc-delete-all id gnus-notifications-id-to-msg))
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: none
2024-03-13 13:57 ` none Po Lu
@ 2024-03-13 14:40 ` Eric Abrahamsen
0 siblings, 0 replies; 50+ messages in thread
From: Eric Abrahamsen @ 2024-03-13 14:40 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> This causes the following byte-compilation warning:
>>
>> In gnus-notification-close:
>> gnus/gnus-notifications.el:91:36: Warning: Unused lexical argument `reason'
>
> Thanks, I'll fix this tomorrow, though you could also install the
> obvious change now:
>
> diff --git a/lisp/gnus/gnus-notifications.el b/lisp/gnus/gnus-notifications.el
> index 9ef21c91627..9c524de8ec4 100644
> --- a/lisp/gnus/gnus-notifications.el
> +++ b/lisp/gnus/gnus-notifications.el
> @@ -88,7 +88,7 @@ gnus-notifications-action
> ;; an action of theirs) are selected
> (assoc-delete-all id gnus-notifications-id-to-msg))
>
> -(defun gnus-notification-close (id reason)
> +(defun gnus-notification-close (id _reason)
> "Remove ID from the alist of notification identifiers to messages.
> REASON is ignored."
> (assoc-delete-all id gnus-notifications-id-to-msg))
I just did this; the name of the function was missing an "s", too.
^ permalink raw reply [flat|nested] 50+ messages in thread
* (unknown)
@ 2022-07-21 11:36 Gregory Heytings
2022-07-21 16:11 ` none Manuel Giraud
0 siblings, 1 reply; 50+ messages in thread
From: Gregory Heytings @ 2022-07-21 11:36 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
a29a3ad55d breaks the build of master with:
cedet/semantic/symref/list.el:35:2: Error: Wrong type argument: number-or-marker-p, nil
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2022-07-21 11:36 (unknown) Gregory Heytings
@ 2022-07-21 16:11 ` Manuel Giraud
0 siblings, 0 replies; 50+ messages in thread
From: Manuel Giraud @ 2022-07-21 16:11 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Po Lu, emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
> a29a3ad55d breaks the build of master with:
>
> cedet/semantic/symref/list.el:35:2: Error: Wrong type argument:
> number-or-marker-p, nil
Hi,
I also have this error for some hours now but a29a3ad55d does not seem
to be at fault. I have the same error from building at 8e71e9b10333c.
(Sorry I don't have time now for a proper bisect).
--
Manuel Giraud
^ permalink raw reply [flat|nested] 50+ messages in thread
* (unknown)
@ 2021-12-20 2:29 Davin Pearson
2021-12-20 14:13 ` none Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: Davin Pearson @ 2021-12-20 2:29 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 795 bytes --]
I was wondering if you could make the following improvement to
GNU Emacs: Make it so that fonts with a nil for background-colour
have the fontification of the inner symbols shines through
to appear over higher layers, like so:
*abc* is fontified as a blue foreground with nil background
"*abc*" is fontified in light blue background with a black foreground
but should appear with a light blue background and a blue foreground.
Here is the Elisp code that I want the behaviour of which changed:
(set-face-foreground 'dmp-face--fg:blue "#000")
(set-face-background 'dmp-face--fg:blue nil)
("\\*.*\\*" 0 'dmp-face--fg:blue t)
--
Sorry about the delay in getting back to you.
I am only allowed my computer once per week
so that makes for a two-three week round trip in
getting back to you.
[-- Attachment #1.2: Type: text/html, Size: 1041 bytes --]
[-- Attachment #2: old-screenshot-20211212-181211.png --]
[-- Type: image/png, Size: 261635 bytes --]
[-- Attachment #3: new-screenshot-20121212-181236.png --]
[-- Type: image/png, Size: 262908 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* (unknown)
@ 2021-07-27 23:54 Troy Hinckley
2021-07-30 21:33 ` none Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: Troy Hinckley @ 2021-07-27 23:54 UTC (permalink / raw)
To: emacs-devel
Subject: Load order for elisp files
User-agent: mu4e 1.2.0; emacs 28.0.50
I am trying to better understand the bootstrap process for Emacs and I
have run into a chicken and egg problem. When looking for where the
basic functions are defined, I can see that defmacro and defun are defined in
byte-run.el. However the code needed to evaluate a macro is in
backquote.el. But backquote.el uses defun, which is defined in
byte-run.el. Which of these files is loaded first, and how does Emacs
work around this apparent causality dilemma?
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2021-07-27 23:54 (unknown) Troy Hinckley
@ 2021-07-30 21:33 ` Stefan Monnier
2021-07-31 5:09 ` none Troy Hinckley
0 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2021-07-30 21:33 UTC (permalink / raw)
To: Troy Hinckley; +Cc: emacs-devel
Troy Hinckley [2021-07-27 17:54:25] wrote:
> Subject: Load order for elisp files
> User-agent: mu4e 1.2.0; emacs 28.0.50
> I am trying to better understand the bootstrap process for Emacs and I
> have run into a chicken and egg problem. When looking for where the
> basic functions are defined, I can see that defmacro and defun are defined in
> byte-run.el. However the code needed to evaluate a macro is in
> backquote.el.
Hmm... no, the code in `backquote.el` is only used to macro expand uses
of backquotes (which are commonly used in macro definitions but not in
all of them) and `byte-run.el` is indeed careful not to use backquotes,
specifically because that would break the bootstrap.
IIRC there are cases where we rely on even more subtle details, more
specifically, I seem to remember that we have functions whose body uses
macros that aren't yet defined when we define the function, and this
still works OK because this is done at a stage where macro expansion is
still lazy, so the macros in the body of the function are only expanded
when the function gets called (or when it gets byte-compiled) both of
which "happen" to take place later, when the corresponding macros have
been defined.
Stefan
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2021-07-30 21:33 ` none Stefan Monnier
@ 2021-07-31 5:09 ` Troy Hinckley
2021-07-31 16:22 ` none Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: Troy Hinckley @ 2021-07-31 5:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
byte-run.el does use backquotes
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/byte-run.el#n122
However I had not thought about the impacts of lazy evaluation. I guess
this would require that you load the code twice: First with the
interpreter, then with the byte compiler, since you can't compile a macro
that has not been defined.
On Fri, Jul 30, 2021 at 3:33 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
> Troy Hinckley [2021-07-27 17:54:25] wrote:
> > Subject: Load order for elisp files
> > User-agent: mu4e 1.2.0; emacs 28.0.50
> > I am trying to better understand the bootstrap process for Emacs and I
> > have run into a chicken and egg problem. When looking for where the
> > basic functions are defined, I can see that defmacro and defun are
> defined in
> > byte-run.el. However the code needed to evaluate a macro is in
> > backquote.el.
>
> Hmm... no, the code in `backquote.el` is only used to macro expand uses
> of backquotes (which are commonly used in macro definitions but not in
> all of them) and `byte-run.el` is indeed careful not to use backquotes,
> specifically because that would break the bootstrap.
>
> IIRC there are cases where we rely on even more subtle details, more
> specifically, I seem to remember that we have functions whose body uses
> macros that aren't yet defined when we define the function, and this
> still works OK because this is done at a stage where macro expansion is
> still lazy, so the macros in the body of the function are only expanded
> when the function gets called (or when it gets byte-compiled) both of
> which "happen" to take place later, when the corresponding macros have
> been defined.
>
>
> Stefan
>
>
[-- Attachment #2: Type: text/html, Size: 2274 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2021-07-31 5:09 ` none Troy Hinckley
@ 2021-07-31 16:22 ` Stefan Monnier
0 siblings, 0 replies; 50+ messages in thread
From: Stefan Monnier @ 2021-07-31 16:22 UTC (permalink / raw)
To: Troy Hinckley; +Cc: emacs-devel
Troy Hinckley [2021-07-30 23:09:29] wrote:
> byte-run.el does use backquotes
> https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/byte-run.el#n122
> However I had not thought about the impacts of lazy evaluation.
Right [except evaluation is not lazy, only macro-expansion is].
> I guess this would require that you load the code twice: First with
> the interpreter, then with the byte compiler, since you can't compile
> a macro that has not been defined.
Indeed: we first load the interpreted code when dumping the
`src/bootstrap-emacs` executable, which is then used to compile the
preloaded files (and the compiler), after which we load them again (but
in their compiled form) to dump the final `src/emacs` executable.
Note that lazy macro-expansion is only used for some of the preloaded
files (more specifically for those loaded before `macroexp.el` in
`lisp/loadup.el`, where you can also see some hackish workaround we have
to use at that time).
Stefan
^ permalink raw reply [flat|nested] 50+ messages in thread
* (no subject)
@ 2021-05-06 13:58 Krupal
2021-05-07 4:15 ` none Bastien
0 siblings, 1 reply; 50+ messages in thread
From: Krupal @ 2021-05-06 13:58 UTC (permalink / raw)
To: bzg; +Cc: emacs-orgmode
Hi Bastien,
I'm interested in taking 'charge' of maintenance of 'orgmode.org/worg'.
My whole life revolves around org files. I use it extensively for
personal knowledge management, appointments, lessons, project management using
TaskJuggler, Python development using literate-programming, private journals,
finance using ledger, pdfs with org-noter, org-roam etc.
Without a doubt, 'worg' has at times given me solutions which weren't
available anywhere else in the whole www. At the same time, it is very
easy to come across very outdated information over there, and certain other
pages are just a bunch of unrelated comments.
It would be an honour to be able to contribute by trying to make it more
relevant and useful for both new users and expert users alike. It is
indeed a massive repository of extremely useful information.
Kind regards,
Krupal
^ permalink raw reply [flat|nested] 50+ messages in thread
* (unknown)
@ 2016-09-28 12:26 Takesi Ayanokoji
2016-09-28 17:05 ` none John Wiegley
0 siblings, 1 reply; 50+ messages in thread
From: Takesi Ayanokoji @ 2016-09-28 12:26 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
Hi developers.
I translated GNU Emacs manual "The Emacs Edirot" from English to Japanese.
Emacs-24.5: https://ayatakesi.github.io/#emacs-24.5-emacs
Emacs-25.1: https://ayatakesi.github.io/#emacs-25.1-emacs
So, how should I take next action.
Submit it to somewhere, or else?
(Currently I am sharing it by GitHub.)
Any ideas?
Thanks.
---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>
[-- Attachment #2: Type: text/html, Size: 1450 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2016-09-28 12:26 (unknown) Takesi Ayanokoji
@ 2016-09-28 17:05 ` John Wiegley
0 siblings, 0 replies; 50+ messages in thread
From: John Wiegley @ 2016-09-28 17:05 UTC (permalink / raw)
To: Takesi Ayanokoji; +Cc: emacs-devel
>>>>> "TA" == Takesi Ayanokoji <ayanokoji.takesi@gmail.com> writes:
TA> I translated GNU Emacs manual "The Emacs Edirot" from English to Japanese.
TA> So, how should I take next action. Submit it to somewhere, or else?
TA> (Currently I am sharing it by GitHub.)
This is a great contribution, Takesi, thank you! I'm not sure where other
languages go in our repository, since I don't see any others.
The only difficulty I can see will be maintaining this document to include
future changes, since few of us speak Japanese.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 50+ messages in thread
* (no subject)
@ 2005-06-04 0:56 Luc Teirlinck
2005-06-05 16:49 ` none Kim F. Storm
0 siblings, 1 reply; 50+ messages in thread
From: Luc Teirlinck @ 2005-06-04 0:56 UTC (permalink / raw)
Cc: Kim F. Storm
Is there a reason why this-original-command, unlike this-command,
returns a non-nil value when no command is running? The reason why
this originally annoyed me is no longer valid, so I do not need this
to be "fixed", but I thought that maybe it might just be due to an
oversight. What about the patch below? Grepping shows that
this-original-command, is only used in ido and cua. Basically, I
believe that only Kim has ever used it. What about the mini-patch
below? I can install if desired.
===File ~/keyboard.c-diff===================================
*** keyboard.c 26 May 2005 10:40:35 -0500 1.826
--- keyboard.c 30 May 2005 17:14:15 -0500
***************
*** 1522,1527 ****
--- 1522,1528 ----
Vthis_command = Qnil;
real_this_command = Qnil;
+ Vthis_original_command=Qnil;
/* Read next key sequence; i gets its length. */
i = read_key_sequence (keybuf, sizeof keybuf / sizeof keybuf[0],
============================================================
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2005-06-04 0:56 (no subject) Luc Teirlinck
@ 2005-06-05 16:49 ` Kim F. Storm
0 siblings, 0 replies; 50+ messages in thread
From: Kim F. Storm @ 2005-06-05 16:49 UTC (permalink / raw)
Cc: emacs-devel
Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> Is there a reason why this-original-command, unlike this-command,
> returns a non-nil value when no command is running?
It is an oversight. Please install your patch. Thanks.
> The reason why
> this originally annoyed me is no longer valid, so I do not need this
> to be "fixed", but I thought that maybe it might just be due to an
> oversight. What about the patch below? Grepping shows that
> this-original-command, is only used in ido and cua. Basically, I
> believe that only Kim has ever used it.
Maybe because until now, I'm the only one(?) who has seriously used
the new command remapping feature :-)
> What about the mini-patch
> below? I can install if desired.
>
> ===File ~/keyboard.c-diff===================================
> *** keyboard.c 26 May 2005 10:40:35 -0500 1.826
> --- keyboard.c 30 May 2005 17:14:15 -0500
> ***************
> *** 1522,1527 ****
> --- 1522,1528 ----
>
> Vthis_command = Qnil;
> real_this_command = Qnil;
> + Vthis_original_command=Qnil;
>
> /* Read next key sequence; i gets its length. */
> i = read_key_sequence (keybuf, sizeof keybuf / sizeof keybuf[0],
> ============================================================
>
>
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 50+ messages in thread
* None
@ 2003-03-07 12:20 abrahamade
0 siblings, 0 replies; 50+ messages in thread
From: abrahamade @ 2003-03-07 12:20 UTC (permalink / raw)
ido.fraietta@datamat.it,gul_clk1@yahoo.com,guma@crd.ge.com,gund28ezve@58jrsjj500.it,guru@domain.edu,gutschk@uni-muenster.de,gv7r9coar6f@vocnya05fhd.tv,gwheeler@vmguys.com,gwpyvvgvxv21c@kgcags6fe.it,gwqgbk367@xarky8bhwjb.com,gya7sjgh4mz@4w4bq4ne3.tv,gyatsola@hotmail.com,gymte81f8@0jbhbigg.fi,gz290odp@i8uu3skvz.to,h.l.miller@fz-juelich.de,h1rsmxfe9njhd@0d71xox9.com,h1sg8onwzm6fzy@ejirmgqf5.com,h28u4i6rce@p65crf3tae.net,h2sho2uoo2@rdck2mgxjjddho.to,h4mtjncuz3rp@j6ogi83v17kps.nl,h588oy3ono@c5hdu4fn.fi,h5ay9cte
@2chs@btv.ibm.com,hj6jh292thd@q6orpr5oo1xqe.nl,hj77y2pv@2bh91qdjdo.net,hkthsp31wpkag@frm6abepjw2n8f.tv,hmjbmn4w4y92@1omhkqcx62mmz.tv,hniksic@xemacs.org,hodel@servint.com,hofmanns@one.net,honchi_ng@my-deja.com,horia@z.rdsnet.ro
From: abrahamade@themail.com
Subject: TRUSTED PARTNERSHIP
X-Priority: 3
Authorized-User: abrahamade@themail.com
IP-Address: 66.178.47.75
Reply-To: abrahamade@themail.com
MIME-Version: 1.0
Content-type: text/plain
Message-Id: <200303070710890.SM00216@mail.TheMail.com>
Date: Fri, 7 Mar 2003 07:26:20 -0500
Dr. ABRAHAM ADESANYA
Nigerian National Petroleum Corporation,
Corporate Head Quater,
Falomo Shopping Complex,
Ikoyi, Lagos.
E-mail:abrahamade@themail.com
STRICTLY CONFIDENTIAL
The President/C.E.O.,
Seeking for a Dedicated and Committed Partnership in a
Business Proposal Worth US$26.5m.
Through some discreet inquiries from our Chambers of
Commerce, you and your organization were revealed as
being quite astute in private entrepreneur. On this on
this premise, we have no doubt in your ability to
handle a financial business of considerable
amount,which will form the bedrock of an extensive
business partnership in due course.
In unfolding this proposal,I want to count on your
status, as a respected executive of your company to
believe that you will handle it with all sincerity and
accord it absolute confidentiality that it deserves.
Being the secretary to the panel that is reviewing the
award of past project that discovered this fund, I
have been mandated to open a business relationship
with you on this mutually beneficial opportunity.
This business involves the remittance of US$26.5
million (Twenty Six Million, Five Hundred Thousand
dollars) only into your bank account from our apex
bank where this fund has been lying idle in a suspense
account. The money accrued through deliberate
over-invoicing of old project executed for the
Nigerian National Petroleum Corporation by some
foreign firms.
We have worked out this scheme to benefit us along
with any foreign partner who obliges us the
materials and channel to transfer out the fund into
his/her nominated account with a view to traveling
down to meet you thereafter so that we can have our
share.
In the past, we did encounter a great loss from our
previous experience with a Swiss who in trying to
assist us suggested that the transfer should be done
in three installments into his account.Together, we
were able to transfer the first installment which was
assumed to be a part payment of the contract sum
amounting to US$8.625M (Eight million, six hundred and
twenty five thousand dollars), into his account that
he gave us.He however disappeared into thin air on our
arrival at Zurich in Switzerland to collect our share.
Series of attempt to contact him proved abortive and
that is how we lost this whooping amount to the Swiss.
We have now fully worked out the operational
modalities to avoid any reoccurrence of such loss
and to forestall any hitch. If you would assist or
participate in this deal, then please endeavor to get
in touch with me immediately via my E-mail address as
written above.
In picking on you for this business, please note that
your expertise has been taken into consideration, as
you will be required to guide us through a wise
investment of our share of the fund in a viable and
profitable venture in your country.
In the world over, bigger firms who bid for various
contracts especially in third world countries like
ours can sub-contract some of them to other firms for
execution. That is your firm will be regarded as one
of those that executed one of such projects and
therefore entitled to receive the contract value. Be
rest assured that this transaction is 100% risk free
as there is actually no risk involved either now or in
the future for we are well connected in official
circle. Given our level of commitment at the moment,we
want to assure you that with full dedication on your
part, the objective of having this fund remitted would
have been realized within a period of two weeks.
It is hereby expressly agreed in principle that at the
end of the transaction, you will be entitled to 20% of
the entire sum, which you are free to withdraw as soon
as you confirm that the fund has been remitted into
your account.
I am awaiting your response most urgently whether you
are interested or not to enable me know the next move
to make.
Contact me directly on my Email address if you are
interested with your company name/address and your
personal tel/fax numbers.I shall forward my home
address,telephone and fax numbers to you once you
confirm your interest in assisting us.
Thanks.
Yours sincerely,
Dr. ABRAHAM ADESANYA
__________________________________________________________________
TheMail.com - Full featured premium email you can count on.
Sign-up today at http://www.themail.com/
^ permalink raw reply [flat|nested] 50+ messages in thread
* None
@ 2003-03-07 12:04 abrahamade
0 siblings, 0 replies; 50+ messages in thread
From: abrahamade @ 2003-03-07 12:04 UTC (permalink / raw)
m,emacs-bidi@gnu.org,emacs-devel@gnu.org,emacs-for-ns-announce@lists.princeton.edu,emacs-for-ns-users@lists.princeton.edu,emacs-rcp@amaunet.cs.uni-dortmund.de,emacs-rcp@ls6.cs.uni-dortmund.de,emeade@teknolust.com,emilio_tunon@nl.compuware.com, ew9xy3zqh@wsaj39r2qcu.org,ewrm7c4k@z61oazt9ou1iz4.org
From: abrahamade@themail.com
Subject: TRUSTED PARTNERSHIP
X-Priority: 3
Authorized-User: abrahamade@themail.com
IP-Address: 66.178.47.75
Reply-To: abrahamade@themail.com
MIME-Version: 1.0
Content-type: text/plain
Message-Id: <200303070646798.SM00100@mail.TheMail.com>
Date: Fri, 7 Mar 2003 07:06:09 -0500
Dr. ABRAHAM ADESANYA
Nigerian National Petroleum Corporation,
Corporate Head Quater,
Falomo Shopping Complex,
Ikoyi, Lagos.
E-mail:abrahamade@themail.com
STRICTLY CONFIDENTIAL
The President/C.E.O.,
Seeking for a Dedicated and Committed Partnership in a
Business Proposal Worth US$26.5m.
Through some discreet inquiries from our Chambers of
Commerce, you and your organization were revealed as
being quite astute in private entrepreneur. On this on
this premise, we have no doubt in your ability to
handle a financial business of considerable
amount,which will form the bedrock of an extensive
business partnership in due course.
In unfolding this proposal,I want to count on your
status, as a respected executive of your company to
believe that you will handle it with all sincerity and
accord it absolute confidentiality that it deserves.
Being the secretary to the panel that is reviewing the
award of past project that discovered this fund, I
have been mandated to open a business relationship
with you on this mutually beneficial opportunity.
This business involves the remittance of US$26.5
million (Twenty Six Million, Five Hundred Thousand
dollars) only into your bank account from our apex
bank where this fund has been lying idle in a suspense
account. The money accrued through deliberate
over-invoicing of old project executed for the
Nigerian National Petroleum Corporation by some
foreign firms.
We have worked out this scheme to benefit us along
with any foreign partner who obliges us the
materials and channel to transfer out the fund into
his/her nominated account with a view to traveling
down to meet you thereafter so that we can have our
share.
In the past, we did encounter a great loss from our
previous experience with a Swiss who in trying to
assist us suggested that the transfer should be done
in three installments into his account.Together, we
were able to transfer the first installment which was
assumed to be a part payment of the contract sum
amounting to US$8.625M (Eight million, six hundred and
twenty five thousand dollars), into his account that
he gave us.He however disappeared into thin air on our
arrival at Zurich in Switzerland to collect our share.
Series of attempt to contact him proved abortive and
that is how we lost this whooping amount to the Swiss.
We have now fully worked out the operational
modalities to avoid any reoccurrence of such loss
and to forestall any hitch. If you would assist or
participate in this deal, then please endeavor to get
in touch with me immediately via my E-mail address as
written above.
In picking on you for this business, please note that
your expertise has been taken into consideration, as
you will be required to guide us through a wise
investment of our share of the fund in a viable and
profitable venture in your country.
In the world over, bigger firms who bid for various
contracts especially in third world countries like
ours can sub-contract some of them to other firms for
execution. That is your firm will be regarded as one
of those that executed one of such projects and
therefore entitled to receive the contract value. Be
rest assured that this transaction is 100% risk free
as there is actually no risk involved either now or in
the future for we are well connected in official
circle. Given our level of commitment at the moment,we
want to assure you that with full dedication on your
part, the objective of having this fund remitted would
have been realized within a period of two weeks.
It is hereby expressly agreed in principle that at the
end of the transaction, you will be entitled to 20% of
the entire sum, which you are free to withdraw as soon
as you confirm that the fund has been remitted into
your account.
I am awaiting your response most urgently whether you
are interested or not to enable me know the next move
to make.
Contact me directly on my Email address if you are
interested with your company name/address and your
personal tel/fax numbers.I shall forward my home
address,telephone and fax numbers to you once you
confirm your interest in assisting us.
Thanks.
Yours sincerely,
Dr. ABRAHAM ADESANYA
__________________________________________________________________
TheMail.com - Full featured premium email you can count on.
Sign-up today at http://www.themail.com/
^ permalink raw reply [flat|nested] 50+ messages in thread
* None
@ 2003-01-11 16:32 Luc Teirlinck
0 siblings, 0 replies; 50+ messages in thread
From: Luc Teirlinck @ 2003-01-11 16:32 UTC (permalink / raw)
Cc: bug-gnu-emacs
Alan Mackenzie wrote:
Gnu Emacs Lisp Reference Manual v. 2.7.
There is no description of "[t]", as in
(define-key map [t] 'isearch-other-control-char)
on the page "Changing Key Bindings", where define-key is specified. I
couldn't find this information anywhere else, either.
It is explained in the section "Format of keymaps", Section 22.2 in
the printed version 2.6, m elisp m keymaps m format, if you are using
info.
Sincerely,
Luc Teirlinck.
^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <mailman.67.1042045834.21513.help-gnu-emacs@gnu.org>]
* None
@ 2003-01-08 16:46 unni krishnan
0 siblings, 0 replies; 50+ messages in thread
From: unni krishnan @ 2003-01-08 16:46 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/plain, Size: 117 bytes --]
is it possible for running Emacs21 on a redhat linux 7.1?
Catch all the cricket action. Download Yahoo! Score tracker
[-- Attachment #1.2: Type: text/html, Size: 274 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 50+ messages in thread
* None
@ 2003-01-02 7:32 unni krishnan
0 siblings, 0 replies; 50+ messages in thread
From: unni krishnan @ 2003-01-02 7:32 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/plain, Size: 640 bytes --]
>
> hello,
>
> i am a new user (student) of emacs.how can i
> do syntax coloring in emacs?
>
>It's simply, just type:
>M-x global-font-lock-mode
>If you don't have the Meta key (alt should be equal to Meta), you can
>type ESC-x global-font-lock-mode
>To make permanent this configuration, you must edit the .emacs file and
>insert the following line
>(global-font-lock-mode 1)
hi,
syntax coloring is not working.
thanks for response. i am using a linux 7.2
i have typed the command
M-x global-font-lock-mode
but the result is
"global font lock mode disabled"
Catch all the cricket action. Download Yahoo! Score tracker
[-- Attachment #1.2: Type: text/html, Size: 956 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 50+ messages in thread
* None
@ 2002-12-19 13:37 Maria_Kabila
0 siblings, 0 replies; 50+ messages in thread
From: Maria_Kabila @ 2002-12-19 13:37 UTC (permalink / raw)
58285@co.ulimit.com,jservotte@swing.be,blicjakarta@yahoo.com,julos@dvddd.com.,info@verviersima.be,courrier@cyberliege.be,sylvie.godefroid@sabam.be,thierry.dachelet@sabam.be,bertrand.cornu@caramail.com,gsthemelin@yahoo.fr,eloymarc@skynet.be
From: Maria_Kabila@themail.com
Subject: URGENT ASSISTANCE NEEDED
X-Priority: 3
Authorized-User: Maria_Kabila@themail.com
IP-Address: 216.139.180.23
Reply-To: Maria_Kabila@themail.com
MIME-Version: 1.0
Content-type: text/html
Message-Id: <200212062208125.SM00143@mail.TheMail.com>
Date: Thu, 19 Dec 2002 08:43:41 -0500
ATTN:PRESIDENT/CEO.
URGENT ASSISTANCE NEEDED
My greetings.
I know you will be amazed to read from me, but please
consider this letter as a request from a widow in need
of help.
I am Mrs. Maria Kabila, the last wife of late
President of Democratic Republic of Congo, Laurent
Kabila. I, on behalf of El-faruk's family decided to
solicit for assistance to transfer the sum of
US$22,000,000.00 (Twenty-two million United States
Dollars) to your personal account, believing that the
funds will be saved in your bank account for my
investment.
This money was part of the fund secured by my late
husband when he was still in power. As the wife he
relied on me, my attention was drawn to this said
amount of money in case of unforeseen circumstances.
This fear was actualised on the 16th January 2001 when
his bodyguard, Rasheed assassinated him.
Please do not hesitate to contact my immediate brother
El-Faruk jnr who is presently residing in Johannesburg, South Africa
through His private email address[el_faruk2001@yahoo.com] For more
information, because according to our culture here, I will morn my
husband for 24 months. Elfaruk jnr my brother will inform you of the
whole procedure, because I have give authorization to deal with you
on my behalf and on behalf of our family. He also has in his
possession all the necessary documentation relating to the funds.
For your assistance, we have agreed to offer you 20%
of the total amount, while 80% will be for our
investment in your country.
Finally, you are requested to maintain the secrecy of
this proposal. God bless you abundantly.
Yours truly,
Maria Kabila
<br>__________________________________________________________________
TheMail.com - Full featured premium email you can count on.
Sign-up today at http://www.themail.com/
^ permalink raw reply [flat|nested] 50+ messages in thread
* None
@ 2002-12-04 13:01 後藤 伸哉
0 siblings, 0 replies; 50+ messages in thread
From: 後藤 伸哉 @ 2002-12-04 13:01 UTC (permalink / raw)
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.
Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.
In GNU Emacs 21.2.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars)
of 2002-05-30 on vlsisv01
configured using `configure --x-includes=/usr/X11R6/include:/usr/local/include:/usr/openwin/include --x-libraries=/usr/X11R6/lib:/usr/local/lib:/usr/openwin/lib'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ja
locale-coding-system: japanese-iso-8bit
default-enable-multibyte-characters: t
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <tool-bar>
<Queue Message> <help-echo> <help-echo> <help-echo>
<tool-bar> <Queue Message> <tool-bar> <Queue Message>
<tool-bar> <Queue Message> <tool-bar> <Queue Message>
<help-echo> <tool-bar> <Queue Message> <help-echo>
<help-echo> <tool-bar> <Queue Message> <help-echo>
<help-echo> <tool-bar> <Send Message> <help-echo> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <tool-bar> <Queue Message> <help-echo>
<help-echo> <help-echo> <menu-bar> <Mew/Draft> <Send
Message> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
<files> <save-buffer> <help-echo> <menu-bar> <Mew/Draft>
<Queue Message> <down-mouse-1> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<drag-mouse-1> <down-mouse-1> <mouse-1> <down-mouse-3>
<mouse-3> <down-mouse-2> <mouse-2> <down-mouse-1> <mouse-1>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
<help-menu> <report-emacs-bug>
Recent messages:
Error while displaying tooltip: (error Undefined color lightyellow)
Save current buffer to its file
Wrote /home/ic1127/Mail/draft/3
No recipient!
Mark set
mouse-yank-at-click: Text is read-only
Auto-saving...done
Error while displaying tooltip: (error Undefined color lightyellow)
Send e-mail to Emacs maintainers
Loading emacsbug...done
^ permalink raw reply [flat|nested] 50+ messages in thread
* Text mode menu wishlist
@ 2002-09-09 15:53 Sacha Chua
2002-09-09 17:27 ` Alex Schroeder
0 siblings, 1 reply; 50+ messages in thread
From: Sacha Chua @ 2002-09-09 15:53 UTC (permalink / raw)
The EmacsWiki has a new node: http://www.emacswiki.org/cgi-bin/wiki.pl?TextMenu
---
We need a good replacement for tmm (f10) which does not confuse the
blind. A start is available as Lisp:textmenu.el. Read the
documentation for define-key and improve it.
---
Please define "confuse the blind." I need to know what people like or
don't like about tmm.el and textmenu.el. I have copious amounts of
free time and quite a great bit of interest in making this
work. Personal itches: changing keymaps and losing the ability to C-h
k.
--- (me)
I'd like to know people's thoughts on this. You can either add to the wiki,
post to emacs-devel or e-mail me directly, and I'll keep the wiki page updated. =)
--
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Text mode menu wishlist
2002-09-09 15:53 Text mode menu wishlist Sacha Chua
@ 2002-09-09 17:27 ` Alex Schroeder
2002-09-10 1:45 ` Sacha Chua
0 siblings, 1 reply; 50+ messages in thread
From: Alex Schroeder @ 2002-09-09 17:27 UTC (permalink / raw)
Sacha Chua <sacha@free.net.ph> writes:
> I'd like to know people's thoughts on this. You can either add to
> the wiki, post to emacs-devel or e-mail me directly, and I'll keep
> the wiki page updated. =)
People like me would like a simple buffer where we can use up and down
and RET to select a menu entry. This can be done in Lisp and works
for me.
Other people would like to see "real" menus in the console, but that
requires messing with the C code. The basic stuff is already there in
the MSDOS port (which has "real" menus), all we need is to do is port
that to curses or something. I think this would also work for the
blind which will probably use emacs -nw anyway. But it would not be
enough for me if I wanted to use a buffer-based menu eventhough I am
running X.
Alex.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Text mode menu wishlist
2002-09-09 17:27 ` Alex Schroeder
@ 2002-09-10 1:45 ` Sacha Chua
2002-09-10 7:41 ` Thien-Thi Nguyen
0 siblings, 1 reply; 50+ messages in thread
From: Sacha Chua @ 2002-09-10 1:45 UTC (permalink / raw)
Alex Schroeder <alex@emacswiki.org> writes:
> People like me would like a simple buffer where we can use up and down
> and RET to select a menu entry. This can be done in Lisp and works
> for me.
tmm does that, doesn't it? Or, well, it uses the history mechanism,
and you can pageup to get to the completion buffer...
> Other people would like to see "real" menus in the console, but that
> requires messing with the C code. The basic stuff is already there in
I can start studying ncurses and the Emacs C code if people feel that this is
important enough. =)
> blind which will probably use emacs -nw anyway. But it would not be
> enough for me if I wanted to use a buffer-based menu eventhough I am
> running X.
What would an ideal buffer-based menu be for you? Simple buffer, up
and down and ret, tab, mouse clicks, ability to go up to the parent
menu.. what else? =)
--
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Text mode menu wishlist
2002-09-10 1:45 ` Sacha Chua
@ 2002-09-10 7:41 ` Thien-Thi Nguyen
2002-09-10 7:48 ` Miles Bader
0 siblings, 1 reply; 50+ messages in thread
From: Thien-Thi Nguyen @ 2002-09-10 7:41 UTC (permalink / raw)
Cc: emacs-devel
Sacha Chua <sacha@free.net.ph> writes:
I can start studying ncurses and the Emacs C code if people feel that
this is important enough. =)
perhaps you can kill two birds w/ one stone by prototyping using
guile-ncurses, q.v.
thi
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Text mode menu wishlist
2002-09-10 7:41 ` Thien-Thi Nguyen
@ 2002-09-10 7:48 ` Miles Bader
2002-09-10 8:35 ` (no subject) Thien-Thi Nguyen
0 siblings, 1 reply; 50+ messages in thread
From: Miles Bader @ 2002-09-10 7:48 UTC (permalink / raw)
Cc: Sacha Chua, emacs-devel
Thien-Thi Nguyen <ttn@glug.org> writes:
> I can start studying ncurses and the Emacs C code if people feel that
> this is important enough. =)
>
> perhaps you can kill two birds w/ one stone by prototyping using
> guile-ncurses, q.v.
Um, emacs doesn't use curses.
You probably want to do this at the emacs glyph-matrix level.
-Miles
--
Suburbia: where they tear out the trees and then name streets after them.
^ permalink raw reply [flat|nested] 50+ messages in thread
* (no subject)
2002-09-10 7:48 ` Miles Bader
@ 2002-09-10 8:35 ` Thien-Thi Nguyen
2002-09-10 8:47 ` none Miles Bader
0 siblings, 1 reply; 50+ messages in thread
From: Thien-Thi Nguyen @ 2002-09-10 8:35 UTC (permalink / raw)
Cc: sacha, emacs-devel
From: Miles Bader <miles@lsi.nec.co.jp>
Date: 10 Sep 2002 16:48:40 +0900
Um, emacs doesn't use curses.
You probably want to do this at the emacs glyph-matrix level.
sorry, i thought we were talking about text menus.
(however, note the weasle-word "prototyping". :-)
thi
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2002-09-10 8:35 ` (no subject) Thien-Thi Nguyen
@ 2002-09-10 8:47 ` Miles Bader
2002-09-10 13:56 ` none Sacha Chua
0 siblings, 1 reply; 50+ messages in thread
From: Miles Bader @ 2002-09-10 8:47 UTC (permalink / raw)
Cc: sacha, emacs-devel
Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
> Um, emacs doesn't use curses.
>
> You probably want to do this at the emacs glyph-matrix level.
>
> sorry, i thought we were talking about text menus.
We were (or at least I was).
-Miles
--
`The suburb is an obsolete and contradictory form of human settlement'
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2002-09-10 8:47 ` none Miles Bader
@ 2002-09-10 13:56 ` Sacha Chua
2002-09-10 23:25 ` none Miles Bader
0 siblings, 1 reply; 50+ messages in thread
From: Sacha Chua @ 2002-09-10 13:56 UTC (permalink / raw)
Miles Bader <miles@lsi.nec.co.jp> writes:
>> Um, emacs doesn't use curses.
>> You probably want to do this at the emacs glyph-matrix level.
>> sorry, i thought we were talking about text menus.
> We were (or at least I was).
I am definitely talking about text menus. =) I use emacspeak -nw often
(inside screen), and I rely on the keyboard a lot. Besides, how can I
use Emacs' funky mouse-friendly menus if I don't have graphical output
or an easy to use mouse? =)
Right now I'm studying textmenu and tmm, trying to figure out what
kind of a menu system I really want. I guess most people don't think
tmm is broken (it's actually quite nice), but I wonder if it can be
improved. I'll go into hermit mode now and experiment with ways to do
so. Thanks for the input, and feel free to send more suggestions!
--
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2002-09-10 13:56 ` none Sacha Chua
@ 2002-09-10 23:25 ` Miles Bader
2002-09-30 5:59 ` none Sacha Chua
0 siblings, 1 reply; 50+ messages in thread
From: Miles Bader @ 2002-09-10 23:25 UTC (permalink / raw)
Cc: emacs-devel
On Tue, Sep 10, 2002 at 09:56:55PM +0800, Sacha Chua wrote:
> Right now I'm studying textmenu and tmm, trying to figure out what
> kind of a menu system I really want. I guess most people don't think
> tmm is broken (it's actually quite nice), but I wonder if it can be
> improved.
I think tmm is `broken' too, because:
(1) It operates differently from other menus so it's bound to confuse
beginners.
(2) Even once I got used to it a bit, I still found it very awkward to use:
(a) Moving between menus and sub-menus (it just replaces the contents of
the `menu buffer') is way too heavy-weight. A typical drop-down menu
implementation allows you to quickly scan through submenus seeing
what's there, while also preserving all the `parent context' for you
to see.
(b) The arrangement of menu items in the buffer seems often hard to read
quickly.
(c) I find the way the user-input (in the minibuffer) works annoying. I
don't really like using completion when choosing from a small set of
displayed items (because doing so requires me to stop and think about
which key to type corresponds to which displayed), I'd rather just
select directly from the list. You can scroll through the list in
the minibuffer using direction keys, but the `disconnected' nature of
it makes this awkward; it would be _much_ better to just manipulate a
cursor in the displayed list directly (you can do this sort of by
switching to the menu-window, but (1) that's an irritating extra step
you have to take, and (2) moving between menu-items once you're there
is still slow and clumsy [e.g., the huge initial comment that has to
be skipped, the double-column arrangement of items]
[I imagine that if you're using emacs-speak, BTW, you might disagree about
some of this]
(3) It's ugly as hell. Bleah.
-Miles
--
Occam's razor split hairs so well, I bought the whole argument!
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2002-09-10 23:25 ` none Miles Bader
@ 2002-09-30 5:59 ` Sacha Chua
2002-10-01 6:18 ` none Richard Stallman
0 siblings, 1 reply; 50+ messages in thread
From: Sacha Chua @ 2002-09-30 5:59 UTC (permalink / raw)
Miles Bader <miles@gnu.org> writes:
> (a) Moving between menus and sub-menus (it just replaces the contents of
> the `menu buffer') is way too heavy-weight. A typical drop-down menu
> implementation allows you to quickly scan through submenus seeing
Do you think it might be nice to have trees or outlines for menus,
like the way customize-browse does it? That seems like a fairly good
way of mimicking drop-down menus. Of course, there's something to be
said about native menus, but I think that native menus have been
discussed on this list before and there's probably a good reason why
we're still not using them.
> select directly from the list. You can scroll through the list in
> the minibuffer using direction keys, but the `disconnected' nature of
tmm allows me to cycle through menu items in the minibuffer by
pressing the up and down arrow keys. This seems to make sense, and
it's actually quite usable with Emacspeak. I still don't like how
accelerators change if something gets added to the menu, and the fact
that there seems to be no easy way to go back to the previous menu,
but it's actually more usable than I thought.
It might be nice to see ido-like functionality in the menu, though. =)
That would be, like, fun!
--
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: none
2002-09-30 5:59 ` none Sacha Chua
@ 2002-10-01 6:18 ` Richard Stallman
0 siblings, 0 replies; 50+ messages in thread
From: Richard Stallman @ 2002-10-01 6:18 UTC (permalink / raw)
Cc: emacs-devel
Of course, there's something to be
said about native menus, but I think that native menus have been
discussed on this list before and there's probably a good reason why
we're still not using them.
If "native menus" means displaying something on the tty that looks
like a pull-down menu and letting the user move through it,
the reason we are not using them is that nobody has implemented them.
We would definitely like to switch to them, but it takes work,
so the question is who wants to do the work.
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2024-04-11 15:03 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-28 17:01 iso-8859-1 and non-latin-1 chars Dave Love
2002-12-02 15:47 ` Richard Stallman
2002-12-06 16:38 ` Dave Love
2002-12-09 6:08 ` Kenichi Handa
2002-12-15 16:24 ` Dave Love
2002-12-16 0:42 ` Kenichi Handa
2002-12-19 22:35 ` Dave Love
2002-12-23 6:40 ` Kenichi Handa
2002-12-23 12:27 ` Dave Love
2002-12-25 13:05 ` Kenichi Handa
2002-12-31 17:14 ` Ken Stevens
2003-01-06 19:28 ` Dave Love
2003-01-06 19:18 ` Dave Love
2003-01-07 13:01 ` Kenichi Handa
2003-01-10 10:59 ` Dave Love
2003-01-06 19:19 ` Dave Love
2002-12-16 14:06 ` Stefan Monnier
2002-12-19 22:33 ` Dave Love
2002-12-16 16:42 ` Richard Stallman
[not found] ` <E18LZqb-0007si-00@fencepost.gnu.org>
2002-12-15 16:25 ` Dave Love
2002-12-16 16:42 ` Richard Stallman
[not found] ` <E18LCz8-0004It-00@fencepost.gnu.org>
2002-12-10 23:47 ` Dave Love
2002-12-11 20:39 ` Richard Stallman
2002-12-13 2:58 ` Kenichi Handa
2002-12-14 18:31 ` Richard Stallman
2002-12-17 11:41 ` None Kenichi Handa
-- strict thread matches above, loose matches on Subject: below --
2024-04-11 14:43 Sébastien Gendre
2024-04-11 14:56 ` none Fraga, Eric
2024-03-13 12:48 (unknown) Eli Zaretskii
2024-03-13 13:57 ` none Po Lu
2024-03-13 14:40 ` none Eric Abrahamsen
2022-07-21 11:36 (unknown) Gregory Heytings
2022-07-21 16:11 ` none Manuel Giraud
2021-12-20 2:29 (unknown) Davin Pearson
2021-12-20 14:13 ` none Stefan Monnier
2021-07-27 23:54 (unknown) Troy Hinckley
2021-07-30 21:33 ` none Stefan Monnier
2021-07-31 5:09 ` none Troy Hinckley
2021-07-31 16:22 ` none Stefan Monnier
2021-05-06 13:58 Krupal
2021-05-07 4:15 ` none Bastien
2016-09-28 12:26 (unknown) Takesi Ayanokoji
2016-09-28 17:05 ` none John Wiegley
2005-06-04 0:56 (no subject) Luc Teirlinck
2005-06-05 16:49 ` none Kim F. Storm
2003-03-07 12:20 None abrahamade
2003-03-07 12:04 None abrahamade
2003-01-11 16:32 None Luc Teirlinck
[not found] <mailman.67.1042045834.21513.help-gnu-emacs@gnu.org>
2003-01-09 3:15 ` None Bijan Soleymani
2003-01-08 16:46 None unni krishnan
2003-01-02 7:32 None unni krishnan
2002-12-19 13:37 None Maria_Kabila
2002-12-04 13:01 None 後藤 伸哉
2002-09-09 15:53 Text mode menu wishlist Sacha Chua
2002-09-09 17:27 ` Alex Schroeder
2002-09-10 1:45 ` Sacha Chua
2002-09-10 7:41 ` Thien-Thi Nguyen
2002-09-10 7:48 ` Miles Bader
2002-09-10 8:35 ` (no subject) Thien-Thi Nguyen
2002-09-10 8:47 ` none Miles Bader
2002-09-10 13:56 ` none Sacha Chua
2002-09-10 23:25 ` none Miles Bader
2002-09-30 5:59 ` none Sacha Chua
2002-10-01 6:18 ` none Richard Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.