(unknown)

(unknown)

[Takesi Ayanokoji]

[-- 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 --]

Re: none

[John Wiegley]

>>>>> "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

Re: translation of Emacs manual into Japanese

[Paul Eggert]

On 09/28/2016 10:05 AM, John Wiegley wrote:
> I'm not sure where other
> languages go in our repository, since I don't see any others.

This is the first complete translation of a manual that I know of. Until 
now, we've had only tutorials (e.g., etc/tutorials/TUTORIAL.ja) and a 
few reference cards (e.g., etc/refcards/sk-refcard.tex).

We could copy this contribution into doc/emacs-ja and distribute it as a 
standard part of GNU Emacs. Although you're right that it will probably 
trail behind the English-language version, that's much better than not 
having it at all. Perhaps a note could be put into the front, in 
Japanese, explaining this.

Re: translation of Emacs manual into Japanese

[Michael Albinus]

Paul Eggert <eggert@cs.ucla.edu> writes:

> This is the first complete translation of a manual that I know
> of. Until now, we've had only tutorials (e.g.,
> etc/tutorials/TUTORIAL.ja) and a few reference cards (e.g.,
> etc/refcards/sk-refcard.tex).

Years ago, there was a Japanese version of the Tramp manual. It was
released with Tramp 2.0 and 2.1.

I had to remove it in Tramp 2.2, because there were no updates.

Best regards, Michael.

Re: translation of Emacs manual into Japanese

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 28 Sep 2016 13:28:00 -0700
> 
> We could copy this contribution into doc/emacs-ja and distribute it as a 
> standard part of GNU Emacs.

That'd need to figure out where to install it by "make install".  Are
there any GNU conventions for that?

Re: translation of Emacs manual into Japanese

[Paul Eggert]

Eli Zaretskii wrote:
> That'd need to figure out where to install it by "make install".  Are
> there any GNU conventions for that?

Not as far as I know. We could install it as 'emacs-ja', I suppose.

After more looking I found a cache of Japanese translations of GNU manuals, here:

http://www.ring.gr.jp/pub/doc/gnu-info-j/index.html.en

They look like they haven't been maintained since they were created many years 
ago, and it's reasonable to worry that this might happen to the Emacs manual. We 
could install a Japanese translation that's marked as being for a recent 
version. If it isn't maintained we could eventually remove it.

Re: translation of Emacs manual into Japanese

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

Hi!

> The only difficulty I can see will be maintaining this document to include
> future changes, since few of us speak Japanese.

I didn't translate texi manual directory.

Instead, I extracted translatable string from emacs-24.5's texi to PO
files by using po4a utility, and then translate these PO file.
After translation, I generate translated emacs-24.5's texi files from
original texis and translated PO file by using po4a utility again.

Up to that, this was a heavy work for me because I translated over 600
pages manual from nearly scratch.
But after then, emacs-25.1 was released, updating translated manual was
easy.

I extracted translatable string from emacs-25.1's texi to PO  files by
using po4a utility, and then translate these PO file from emacs-24.5's
translated PO files by using gettext's merge utility.

At this point, this merged emacs-25.1's PO files ware almost Japanese but a
few part that made changes in this release remain English.

I translated untranslated part of PO files, and then generate Japanese
manual in fact.

But if I did not translate these PO manually, this cause emacs-25.1 manual
almost Japanese a few English.

This not means that the manual is outdated, it means up-to-date but not
completely translated.

So, if distribution includes translated PO files instead of translated texi
files, and if  any process(make's installation or maintainer's hand)
generaate translated manual from these PO files, maintain cost caused by
future changes will be reduced, I think.

1) gettext and po4a are used by GNUnited Nations that handles GNU's
websites internationalization.
See https://www.gnu.org/software/trans-coord/manual/gnun/gnun.html#Concepts

2) I maintain translated PO files by GitHub.
See https://github.com/ayatakesi/emacs-25.1-doc-emacs

Thanks.
---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>

[-- Attachment #2: Type: text/html, Size: 2383 bytes --]

Re: translation of Emacs manual into Japanese

[Eli Zaretskii]

> From: Takesi Ayanokoji <ayanokoji.takesi@gmail.com>
> Date: Thu, 29 Sep 2016 15:59:49 +0900
> 
> Instead, I extracted translatable string from emacs-24.5's texi to PO files by using po4a utility, and then
> translate these PO file.
> After translation, I generate translated emacs-24.5's texi files from original texis and translated PO file by using
> po4a utility again.
> 
> Up to that, this was a heavy work for me because I translated over 600 pages manual from nearly scratch.
> But after then, emacs-25.1 was released, updating translated manual was easy.
> 
> I extracted translatable string from emacs-25.1's texi to PO files by using po4a utility, and then translate these
> PO file from emacs-24.5's translated PO files by using gettext's merge utility.
> 
> At this point, this merged emacs-25.1's PO files ware almost Japanese but a few part that made changes in
> this release remain English.
> 
> I translated untranslated part of PO files, and then generate Japanese manual in fact.
> 
> But if I did not translate these PO manually, this cause emacs-25.1 manual almost Japanese a few English.
> 
> This not means that the manual is outdated, it means up-to-date but not completely translated.

AFAIU, the technique you used makes every paragraph of the manual a PO
string, and then translates each such string.  This, of course, avoids
translating the same text again for the next version, but it will
leave any changed paragraphs in their English form.  With time, more
and more of the manual will become English if the translation is not
updated, so the danger of becoming outdated still exists, sort of.

Thanks.

Re: translation of Emacs manual into Japanese

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

Of course I want to continue translation work in Emacs's future release ;-)

Regards.
---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>

2016/09/30 午前0:10 "Eli Zaretskii" <eliz@gnu.org>:

> > From: Takesi Ayanokoji <ayanokoji.takesi@gmail.com>
> > Date: Thu, 29 Sep 2016 15:59:49 +0900
> >
> > Instead, I extracted translatable string from emacs-24.5's texi to PO
> files by using po4a utility, and then
> > translate these PO file.
> > After translation, I generate translated emacs-24.5's texi files from
> original texis and translated PO file by using
> > po4a utility again.
> >
> > Up to that, this was a heavy work for me because I translated over 600
> pages manual from nearly scratch.
> > But after then, emacs-25.1 was released, updating translated manual was
> easy.
> >
> > I extracted translatable string from emacs-25.1's texi to PO files by
> using po4a utility, and then translate these
> > PO file from emacs-24.5's translated PO files by using gettext's merge
> utility.
> >
> > At this point, this merged emacs-25.1's PO files ware almost Japanese
> but a few part that made changes in
> > this release remain English.
> >
> > I translated untranslated part of PO files, and then generate Japanese
> manual in fact.
> >
> > But if I did not translate these PO manually, this cause emacs-25.1
> manual almost Japanese a few English.
> >
> > This not means that the manual is outdated, it means up-to-date but not
> completely translated.
>
> AFAIU, the technique you used makes every paragraph of the manual a PO
> string, and then translates each such string.  This, of course, avoids
> translating the same text again for the next version, but it will
> leave any changed paragraphs in their English form.  With time, more
> and more of the manual will become English if the translation is not
> updated, so the danger of becoming outdated still exists, sort of.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 2483 bytes --]

Re: translation of Emacs manual into Japanese

[Takesi Ayanokoji]

>> We could copy this contribution into doc/emacs-ja and distribute it as a
>> standard part of GNU Emacs.
>
> That'd need to figure out where to install it by "make install".  Are
> there any GNU conventions for that?
I checked internationalized info document, and I can't find any conventions
such like a internationalized man-pages.

Example of localized info I only found is TexLive's latex2e.info files
(latex2e.info and latex2e-es.info).

These info files are installed to
'/usr/local/texlive/2015/texmf-dist/doc/info/'
and that is not standard info directory.

If follow this example, japanese localized info name will be emacs-ja.info
and it will be installed Emacs data-directory's subdirectory(i.e. info/)
like Emacs TUTORIALs.

Regards.
---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>

Re: translation of Emacs manual into Japanese

[Katsumi Yamaoka]

On Wed, 28 Sep 2016 21:26:23 +0900, Takesi Ayanokoji wrote:
> 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

What great works!  I also have been working on the Japanese
translation of the Gnus manual[1] for years.  You are welcome to
incorporate it in your works if you wish.  For the traditional
reason it contains the manuals for auth, epa, sasl, and sieve,
that are not parts of Gnus, as well.

[1] http://www.jpl.org/gnus-doc-ja.html
    https://github.com/jpl-org/gnus-doc-ja.git
   (or github.com:jpl-org/gnus-doc-ja.git)

Regards,

Re: translation of Emacs manual into Japanese

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

Hi Yamaoka-san.

I read your translation.
And I think it is really great job.

But I can't imagin how to incorporate our jobs.
So, do you have any ideas to "incorporate" our jobs?

Regards.
---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>

2016/09/29 午後4:19 "Katsumi Yamaoka" <yamaoka@jpl.org>:
>
> On Wed, 28 Sep 2016 21:26:23 +0900, Takesi Ayanokoji wrote:
> > 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
>
> What great works!  I also have been working on the Japanese
> translation of the Gnus manual[1] for years.  You are welcome to
> incorporate it in your works if you wish.  For the traditional
> reason it contains the manuals for auth, epa, sasl, and sieve,
> that are not parts of Gnus, as well.
>
> [1] http://www.jpl.org/gnus-doc-ja.html
>     https://github.com/jpl-org/gnus-doc-ja.git
>    (or github.com:jpl-org/gnus-doc-ja.git)
>
> Regards,

[-- Attachment #2: Type: text/html, Size: 1656 bytes --]

Re: translation of Emacs manual into Japanese

[Katsumi Yamaoka]

On Fri, 30 Sep 2016 12:27:56 +0900, Takesi Ayanokoji wrote:
> Hi Yamaoka-san.

> I read your translation.
> And I think it is really great job.

> But I can't imagin how to incorporate our jobs.
> So, do you have any ideas to "incorporate" our jobs?

Oops, sorry.  Please ignore it.  You aren't going to work on
whole emacs manuals, are you? ;-)  Anyway, thanks again for the
great works.

>>>   Emacs-24.5: https://ayatakesi.github.io/#emacs-24.5-emacs
>>>   Emacs-25.1: https://ayatakesi.github.io/#emacs-25.1-emacs

;; Well, there used to be the Japanese translation of the ELisp
;; manual.  IIRC, that was corresponding to that of Emacs 20.
;; All Japanese Emacs players would greatly appreciate if...

Re: translation of Emacs manual into Japanese

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

> You aren't going to work on
> whole emacs manuals, are you? ;-)
Certainly, that's right.

> ;; Well, there used to be the Japanese translation of the ELisp
> ;; manual.  IIRC, that was corresponding to that of Emacs 20.
> ;; All Japanese Emacs players would greatly appreciate if...
Yes, that's right.
I started to translate elisp manual, but it has just started.
This is not easy work because I am elisp beginner.
https://ayatakesi.github.io/emacs/24.5/elisp.html#Simple-Types

Regards.
---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>

[-- Attachment #2: Type: text/html, Size: 807 bytes --]

Re: (unknown)

[Byung-Hee HWANG (황병희, 黃炳熙)]

Takesi Ayanokoji <ayanokoji.takesi@gmail.com> 께서 쓰시길,
 《記事 全文
 <CAN7WbibOXQGSCYbzErB9e9X3YinM3OmBinApAM15hecx4O7-PA@mail.gmail.com>
 에서》:

> 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.

Takesi-san, it is very hard work, i think. You are strong man. Anyway
thanks thanks thanks!!!

Sincerely,

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

(unknown)

[Eli Zaretskii]

> 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'

(unknown)

[Greg Minshall]

hi.  i would like to be able to write Emacs scripts ("#!...") that allow
a user to enter almost any option to the script itself, *without* having
to use double dashes ("--") to avoid colliding with Emacs option
processing.

looking at "--script" and "-x", this doesn't seem possible.

as a test case, given a simple script foo.sh (*), using "-x", and
invoking it with an option "--eval" gives this error:

----
% ./foo.sh --eval
emacs: Option '--eval' requires an argument
----

(that bare "--eval" *should* be an error if it were meant for Emacs
itself; however, it is meant for the Emacs script, which may have other
ideas of the syntax/semantics of "--eval".)

the below patch to src/emacs.c (**) treats a "-x" (and its "partner"
"-scripteval") like a "--" on the command line, and *seems* to allow
arbitrary options on the command line.  for example, with this patch
installed:

----
% ./foo.sh --eval
command-line-args-left (--eval)
----


i wonder if this might be of use for Emacs?  if there are worries about
backwards compatibility with "-x", well ... "-y" anybody?  :)

(i was thinking of writing a test to go with the patch, but the ERT
framework is maybe a bit awkward for tests of essentially
shell-command-line functionality.  i may have missed it, but i didn't
see anything in ./test/Makefile.in that seemed to be aimed at testing
command-line invocation of Emacs.)

cheers, Greg


(*) foo.sh
----
#!/usr/bin/env -S emacs -x

(message "command-line-args-left %s" command-line-args-left)

1
----


(**) proposed patch
----
diff --git a/src/emacs.c b/src/emacs.c
index 6101ed4004c..6e140177086 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -2795,9 +2795,10 @@ sort_args (int argc, char **argv)
        {
          int match;

-         /* If we have found "--", don't consider
-            any more arguments as options.  */
-         if (argv[from][1] == '-' && argv[from][2] == 0)
+         /* If we have found "--", or a "-x", don't consider any more
+            arguments as options.  */
+         if ((((argv[from][1] == '-') || (argv[from][1] == 'x')) && argv[from][2] == 0)
+             || !strcmp(argv[from], "-scripteval"))
            {
              /* Leave the "--", and everything following it, at the end.  */
              for (; from < argc; from++)
----

Re: (unknown)

[Jim Porter]

On 11/17/2023 7:13 PM, Greg Minshall wrote:
> (i was thinking of writing a test to go with the patch, but the ERT
> framework is maybe a bit awkward for tests of essentially
> shell-command-line functionality.  i may have missed it, but i didn't
> see anything in ./test/Makefile.in that seemed to be aimed at testing
> command-line invocation of Emacs.)

You could probably take some inspiration from the "Synchronous 
processes" section of the file test/lisp/eshell/esh-proc-tests.el. 
Essentially, you can just start a new Emacs instance in your ERT test 
and do whatever you like.

(unknown)

[Pedro Andres Aranda Gutierrez]

On Sat, 11 Mar 2023 04:45:21 -0800, Ongaro <david.ongaro@hamburg.de> wrote

> I don't understand this argument. If you're an Emacs user who uses
> tree-sitter the probability is high that you're also a developer so you
> need development tools like a compiler anyway. Especially in a
> "professional" programming environment. A sys-admin banning that would
> be an admin banning you from work.

Two things to bring another perspective:

1.- the probability is high, but what do we do with the (1-p)... shy
them away? ;-)
2.- with the current landscape, even professional developers can't
sometimes do what they need.
There is this balance between productivity and security, which I do
understand. I've already seen a couple of frighting attacks...

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

(unknown)

[Pedro Andres Aranda Gutierrez]

Joao Tavora wrote:

> This indeed works, I've fixed the manual which previously said that
> setting the variable globally "doesn't make sense".  It can be useful,
> if you know what you're doing.

;-)

> But I don't know if we should be recommending this over the use of
> eglot-server-program + :initializationOptions as described in section
> 5.1 User-specific configuration.  Will see.

Fine, I don't know either whether you should _recommend_.

But, at least mentioning that this can be done to have an initial configuration
to start with... There is no one fits all and some tweaks may be needed
in some projects, but an initial config can speed up the process and it is
'as bad as' putting the dir-locals in your git repo and someone opening it
with -say- vscode or vi ;-)

/PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

(unknown)

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

Rob writes:
> Regarding the writes to HOME, etc.  I think David covered that fairly
> well -- Debian runs emacs to "do things" (build .elcs, run tests, etc.)
> at package build time, package install time, and during package testing.
> In all of these cases, we're likely to want to avoid side-effects outside
> the build/test dir like writing .elc or .eln files to the current user's
> HOME, whether that's /root/ or /home/*.  It sounds like we may be able
> to accomplish that by redirecting everything to a temp dir, which is
> likely fine.

I know this may come late and be redundant, but just my .01 cents of
experience:
I have my own tweaked Debian infra to build emacs29 for Ubuntu and I have
native-compile enabled. All .eln files generated during build from the
emacs (git) source are stored in /usr/lib/emacs-xyz and are never
recompiled when I run emacs.

What actually gets natively compiled to $HOME/.emacs.d/eln-cache is any
package that I download from (m)elpa-xyz as a result of my
HOME/.emacs.d/init.el

I may be doing something wrong, but AFAIK it seems to work and I have the
same functionality on my Ubuntu natively-compiled Emacs and on the macOS
(both running +/- the same snapshot of the emacs master git branch), where
I have no native compilation.

I hope I somehow contributed something ;-)
/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2037 bytes --]

(unknown)

[Gregory Heytings]

a29a3ad55d breaks the build of master with:

cedet/semantic/symref/list.el:35:2: Error: Wrong type argument: number-or-marker-p, nil

(unknown)

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

> Date: Sat, 28 May 2022 08:43:13 +0800
> From: Po Lu <luangruo@yahoo.com>
> To: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: ns-do-applescript
> Message-ID: <87leumebby.fsf@yahoo.com>
> Content-Type: text/plain

> Richard Stallman <rms@gnu.org> writes:

> > I have never heard of "osascript".  What is that?  What systems
> > support it?  Does it exist on GNU/Linux?

> It's only present in macOS.
Right

> > Basically, what are the differences that make it better to use
> > osascript than applescript?

> I think that binary _is_ Apple's proprietary AppleScript interpreter,
Indeed it is

> but using it in a subprocess to retrieve only contacts data (which is
> already possible on free systems) must be more acceptable than Emacs
> including a C primitive to do the same thing.

Not only that. You can do things like raising Emacs to the top and other
system actions that would otherwise require (Objective-)?C functions in the
Emacs executable.

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2842 bytes --]

(unknown)

[Davin Pearson]

[-- 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 --]

(unknown)

[telegraph]

From telegraph@gmx.net  Mon Aug 23 20:37:01 2021
From: Gregor Zattler <telegraph@gmx.net>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: xterm [menu] key definition
In-Reply-To: <87k0kcovp4.fsf@no.workgroup>
References: <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
 <20210819024728.kgnf6jmpakqdto4p@Ergus> <87k0kcovp4.fsf@no.workgroup>
Mail-Followup-To: emacs-devel <emacs-devel@gnu.org>
Date: Mon, 23 Aug 2021 20:36:58 +0200
Message-ID: <87h7fgovn9.fsf@no.workgroup>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:HRO/ZXce88Iozn+9UJq+ekk0abWiVqAiW05nvxhROUw4xLXvaVA
 I8MJYVw59QFHLg4As0OZgf1yCpriSS+YQsdNhys754yK6pB/wk2+6i/PbDMRG3YQWQXBUpo
 tvTC4EpNZXzi5CJg4d4uCg+Wj9SxoajT3JMmIXMug1Xz00P1aemSpf0v6oIf5wFAQ/lSwTr
 D/dkF2dL88+BwVa6vBhhw==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:x+ng0FuV5Xw=:c1ueAnEJSAQkxkyqjZnCx1
 KN6IxRv+LnP6G96c416OIk26JuOsdDTIyiXvEUq6QzrLXZ5rgupHYTCvwJQGBvSvaDphMyFDW
 ST49PCmrRrxwWE1dbBVQ27MMr+q1Ny0ITq7KtafxKw1tmDO6FXXA5N8RaecNs6vDmCQtpbW9z
 /HKAM7MjtdvPVAgtFnY/AYbwK+/jXHEFARP5XNgHbQOOdf9n6GiLAP55AehHp6mv7J+f1yr/Y
 ciX0YuEm8kHEixainZ80as4FOQarr0Vetdd59a+BwIafQxT2iUR+brhxxJxEBH4GR7/F7yN5G
 Ftp4iQDM45po2gmJlveQrUj25Urfz6f0reLHFwE/OfQq9wHaElOvOeZUnOsE6xnxh/PL7kASV
 mbYfUxKk1iCdDC8thJtevvbox8fw8bwCSSzcgwwN1SvtkFXGmZxk1ah64ue4Re/slO35L2voM
 fN+xxT6j8MJwtERNEhJZxeGBgQMVlQ+HuErhFhx5zq96HJgNZh6mHER4/hwHyJ7VPWJDpcMqu
 +gQD5H75FMDrPdWeti2lUxpPbqNcVvEvlziv4agxtJGYTNn75GtI526JU20W/5f1oZuwwoFre
 f+oXHczb6XnEctuTuUlJfPQkBvqDfWTk0X7KvzqmyYJyNjJOmo74O/kIIySZbfhruL3HLs7ba
 r2ofHxlQsyJvZRiJ2sX8xbA5aYVI7830NBkvi3aQeQ2PpHpI3FUg8Z0+Hcumly9COz75+GbM3
 pSje0giAF92ACLFp9kbyeRwKJpdpaZy81alSigFqMF9l6gHvY9v1EP3lHX6L1vC1w9S/bTqoQ
 yioc6IwC4iqTnPQV4agbfB7Xyy3IRD2TDh3ntAVihDXMb6IjBr6jSL3dB8hKU9JUAOiBuGy20
 DtvVNkoryKhJQFjg9N8qtjj7NdZuG+iX4bhej2GzQc6/jqOvev4umnj8n1l7AWUiSJWeT3Mec
 auVYAJHcixI79uAPvWH/7R8F2vLv+mtt/oO+3OTz1KDSntG+OiwefVZFSn6tvtfi0cA2GRH/q
 HpF7JyrC/S5FP0PaE9nXV2526YQacHrPSpmbJB5sMxwpOBQ6UYbTV0y9OqtDIkKBh9mwOJ8jL
 nkPnOo63oY9QmXA63umgtmElXMZvdLieT/clPOiVNacWQUdXuMJKa29kw==
Content-Transfer-Encoding: quoted-printable

Hi Ergus,
* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
> * Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
>> I don't actually know about any keyboard with a print
>> button...
>
> wouldn't that be the PrtSc key which is on every standard PC
> keyboard right of F12 and above of Insert?
>
>> But I suppose there should be some. If someone has it;
>> please could you check with xev and cat+xterm what it
>> sends?
>
> Said key gives via cat on xterm:
>
> ^[[2~
>
> and xev says the same.

on debian buster, that is.


Ciao; Gregor
=2D-
 -... --- .-. . -.. ..--.. ...-.-

(unknown)

[telegraph]

From telegraph@gmx.net  Mon Aug 23 20:35:54 2021
From: Gregor Zattler <telegraph@gmx.net>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: xterm [menu] key definition
In-Reply-To: <20210819024728.kgnf6jmpakqdto4p@Ergus>
References: <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
 <20210819024728.kgnf6jmpakqdto4p@Ergus>
Mail-Followup-To: emacs-devel <emacs-devel@gnu.org>
Date: Mon, 23 Aug 2021 20:35:51 +0200
Message-ID: <87k0kcovp4.fsf@no.workgroup>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:sxHfD7zdrmCrHJSZln2GfPWmdbMMIDsRDQsLpU/nfq2YcMnLSwp
 hYDoOFW4h00C5RkEQiWqTD0Ghszr1rlMksOFjeCzf6UdQ6KCjGfM9H/0FNpGLz//8NEoqgM
 S5utAAvPbhusMs8u3C+lcawvEbL65zJofM+Ydv0o9vvHaRqEnoH26xvM2TKzTcYI3D+cvMJ
 tbufjgNLdJD0dp/gT0Usg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:0O6w3nRKzCM=:0yGavBBfSnyh5UA4ZyLNTu
 xZveGSXWYdvpP90089lYIVteVaqX2TjAGj5I0C+mVPtjbh++j7XzPszGW59UNb8XhbXv/RRAU
 PaKuQZQs2zeJi6m/mnUR28wuFqa9EJFXsUMLywX7A9pcq+nj88RJDkFOyOUucK8ZRDJczVJtq
 hCRthc8vZLS9I7t/BScUxTX0Gkr572eqLRSK7ZAnzyi28WyMc4Q67ujkJYogQakM7BESX2mqb
 n+cqLaM/SkXB4ftaF7C8YmAY7GFK64ACinZ71HIBSIVZhIDaFwmTiO3KSz0zuGFf9pYBndhTr
 iuv3dGLvRCBxYAxZ/8PDf2xts3TXZK6WpjTyQVjthqj5y9OwIYt2kZrgnV0PrbFfAm1H6RPcT
 xQqoU1Xhi3xaLOnNKx5DQp+M3P5/x1uu24XDKzXlVaAmN3r8tMcfbLFbE8Rk5+ikVt5xVHvXM
 pZHJA5ggu0HowH10nfZZ4b9dmeCitsqF9dVOA/sv9WsRdQ+M33ZsdYpk5UTaurTjfVU6JWaOG
 gScUUAQx9O2Iltx9m/jOlfw9aOZQ4cv9uNRiJc0ujo0Iv3T2oqkKoBjTVj5WUY2mqfPkKIhLe
 PqiVdMC2viIT1LzxgCRzghRqizF0E6OGu1twlQNqBMxo8J1MbU5OYo/uJ/QoF4DMY7Z7TgVyc
 4X3WbN7qsken+icUxr5UljsAhpg3Y9VdcF1aLJuFObC5ceIlMAylmUt0MzVfdhDGf4fy7lMWD
 3WVTDeehE5N+vf+gtoktTNzUUVujv6vDihkwb8M8cWBC0iDlLFf7a74EyzY+B4Hgc3Lc4HXGz
 C1HnGSPrG5xCYjzjGRaEulxTMjIBoCaBjj7UamceG6e+8preYjhjJlboGUEc2jWUAhUlK1E/I
 U92uRwgIm+mLukfNLQO/jzObm/a6Xd8xI8DXV3NGzqLWBNR5zZrhXErR2CM9bYihuPyN6Mw+t
 +v9efj6W3mrNpQEjsquqT7OrC3PVSRX8ZER0SkyOmvje3HyALBssD5NBvtOl1YBiYAFN2IbdH
 f2lclpuTkYQ73x9fe5OxwVoz71ASxro8z+oG1pRYVnwfWLwbNw+UK2n9qWxEblnARL9lfLqAr
 LRIc8W9CUi1Q6qGkLmdnpUYMF9eR2jPfzzqbhwIyj7rdZtkfYFCveiAPQ==
Content-Transfer-Encoding: quoted-printable

Hi Ergus,
* Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
> I don't actually know about any keyboard with a print
> button...

wouldn't that be the PrtSc key which is on every standard PC
keyboard right of F12 and above of Insert?

> But I suppose there should be some. If someone has it;
> please could you check with xev and cat+xterm what it
> sends?

Said key gives via cat on xterm:

^[[2~

and xev says the same.

Ciao; Gregor
=2D-
 -... --- .-. . -.. ..--.. ...-.-

(unknown)

[Troy Hinckley]

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?

(unknown)

[Ag Ibragimov]

Spacemacs (community-driven Emacs distribution/config) has a feature called Layers, Doom-Emacs (another community-driven Emacs config) has a similar feature (I think they are called Modules).

A Layer is a bundle of [related] Emacs packages that work together and very often tightly integrate (with one another) to provide a comprehensive set of features to achieve specific goals. For example, there are many language-specific Spacemacs layers: Python, Lua, Haskell, etc.
For example, the Python layer includes basic Python-related packages and sets defaults for Flycheck, Company, etc.
There also layers for tools like Docker or layers for version-control, et al.

So my question is: Has anyone ever thought about designing a sort of standardized module system? It would be great if we could have a unified model for creating such bundles.
Wouldn't be nice if for example, instead of discovering, installing and configuring a bunch of related packages, an Emacs user would say: "install LaTeX module" and then "customize "LaTeX module", etc.

Emacs ecosystem is growing. There are hundreds (maybe more) packages; standardizing a system that would allow the "plug-n-play" experience would be very nice. Otherwise, everyone would continue solving same problems in their own, unique ways, increasing entropy towards the "Lisp curse."

(unknown)

[siraben]

I'm new to contributing, so I was wondering if this is a viable
project to get started on.

I've noticed that development on the Emacs Calc has stalled
recently. /lisp/calc shows no commits since January 1 2018, which was
a copyright year update. I would like to contribute documentation to
many of the undocumented functions, and work on the symbolic
integration algorithm which, despite its complexity, still has great
difficulty with integration by parts and by substitution.

What are some recommended starting points for first-time contributors?

Thanks,

Ben Phipathananunth

(unknown)

[Mark Oteiza]

Hi,

I wrote the following to get rid of the 'apply' here.  The
expansion is something that, according to how byte-switch is described,
should compile to a switch/jumptable, but it isn't happening.

Applying the following, doing M-x byte-compile-file, and inspecting the
.elc/disassembly I am seeing a series of goto-if-nil.  Am I doing
something wrong?

diff --git a/lisp/json.el b/lisp/json.el
index 64486258cc..6990ddd0f5 100644
--- a/lisp/json.el
+++ b/lisp/json.el
@@ -683,6 +683,23 @@ json-readtable
     table)
   "Readtable for JSON reader.")
 
+(defmacro json-readtable-dispatch (char)
+  "Dispatch reader function for CHAR."
+  (declare (debug (symbolp)))
+  (let ((table
+         '((?t json-read-keyword "true")
+           (?f json-read-keyword "false")
+           (?n json-read-keyword "null")
+           (?{ json-read-object)
+           (?\[ json-read-array)
+           (?\" json-read-string)))
+        res)
+    (dolist (c '(?- ?+ ?. ?0 ?1 ?2 ?3 ?4 ?5 ?6 ?7 ?8 ?9))
+      (push (list c 'json-read-number) table))
+    (pcase-dolist (`(,c . ,rest) table)
+      (push `((= ,char ,c) (,@rest)) res))
+    `(cond ,@res (t (signal 'json-readtable-error ,char)))))
+
 (defun json-read ()
   "Parse and return the JSON object following point.
 Advances point just past JSON object."
@@ -690,10 +707,7 @@ json-read
   (let ((char (json-peek)))
     (if (zerop char)
         (signal 'json-end-of-file nil)
-      (let ((record (cdr (assq char json-readtable))))
-        (if (functionp (car record))
-            (apply (car record) (cdr record))
-          (signal 'json-readtable-error record))))))
+      (json-readtable-dispatch char))))
 
 ;; Syntactic sugar for the reader
 

(unknown)

[Paul Pogonyshev]

>>> Have you tried to measure the impact of your patch on the actual problem?
>> I mentioned 3%.
>
>That's the percentage impact on the number of lambdas.  I'm curious
>about its impact on actual problematic aspects, such as speed and code
>size (and compilation time, I guess).
>
>> Yes, it is practically negligible, but this is a first small patch and
>> I'm willing to work on improving generators further.
>
>Of course.

Actually, forget it. It's too complicated to jump through all the hoops here.

I would just be glad if someone applied the patch from bug 26068. It's a
fix, not an optimization, and there is example of a form, evaluation of
which it fixes.

And if you reply, *please*, keep me on CC, otherwise I won't see your
mail.

Paul

Re: (unknown)

[Mark Oteiza]

Paul Pogonyshev <pogonyshev@gmail.com> writes:

>>>> Have you tried to measure the impact of your patch on the actual problem?
>>> I mentioned 3%.
>>
>>That's the percentage impact on the number of lambdas.  I'm curious
>>about its impact on actual problematic aspects, such as speed and code
>>size (and compilation time, I guess).
>>
>>> Yes, it is practically negligible, but this is a first small patch and
>>> I'm willing to work on improving generators further.
>>
>>Of course.
>
> Actually, forget it. It's too complicated to jump through all the hoops here.

Darn.  Such improvements would be nice.

> I would just be glad if someone applied the patch from bug 26068. It's a
> fix, not an optimization, and there is example of a form, evaluation of
> which it fixes.

Applied, thanks.  AFAICT it didn't break any tests and didn't exacerbate
bug#12119 which the previous code was fixing.

Re: (unknown)

[Paul Pogonyshev]

>> I would just be glad if someone applied the patch from bug 26068. It's a
>> fix, not an optimization, and there is example of a form, evaluation of
>> which it fixes.
>
> Applied, thanks.  AFAICT it didn't break any tests and didn't exacerbate
> bug#12119 which the previous code was fixing.

Thank you. If you are familiar with the code involved, can you please also
look at bug 26073? It's related, but more difficult to fix. I added a patch to
the bug report, but I don't think the patch is ready for application. Maybe
someone could finish it.

Paul

(unknown)

[Chris Gregory]

Here is another patch that does more of this.
-- 
Chris Gregory

diff --git a/src/eval.c b/src/eval.c
index e50e26a..9e1d612 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1313,20 +1313,12 @@ internal_condition_case (Lisp_Object (*bfun) (void), Lisp_Object handlers,
 			 Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun ();
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun ();
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case but call BFUN with ARG as its argument.  */
@@ -1364,20 +1356,12 @@ internal_condition_case_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
 			   Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun (arg1, arg2);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (arg1, arg2);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case but call BFUN with NARGS as first,
@@ -1393,20 +1377,12 @@ internal_condition_case_n (Lisp_Object (*bfun) (ptrdiff_t, Lisp_Object *),
 						Lisp_Object *args))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val, nargs, args);
-    }
-  else
-    {
-      Lisp_Object val = bfun (nargs, args);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (nargs, args);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val, nargs, args) : val;
 }
 
 struct handler *

Re: (unknown)

[Andreas Schwab]

On Dez 28 2016, Chris Gregory <czipperz@gmail.com> wrote:

> Here is another patch that does more of this.

Nothing of that is valid C.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

(unknown)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

Hi!

About a year ago, the long time maintainer of the official Emacs user
interface on OS X (the "nextstep" or "NS" user interface), retired from
Emacs. This is very unfortunately, as he did a very, very good job for
during the years he was active.

When I found out about this, about six months ago, I stepped up as I had
some knowledge after having worked along side of him on some NS-related
features.

Unfortunately, my personal situation has since changed so I no longer can
handle the NS user interface by myself.

In other words, I'm looking for someone or a group of people who are
interested in enhancing Emacs on OS X, or at least making sure that it
doesn't stop working.

To make it easier to start working on the NS port, I've updated the README
and add a WISHLIST of features that I would like to see implemented.

I will still be around, but I find that time no longer permits me doing
much core development work.

Sincerely,
    Anders Lindgren

[-- Attachment #2: Type: text/html, Size: 1211 bytes --]

(unknown)

[steve]

From: Steve Purcell <steve@sanityinc.com>
Date: Mon, 8 Feb 2016 20:47:43 +1300
Subject: [PATCH] Safer prompt-regexp for postgres/vertica in
 sql-interactive-mode
--text follows this line--

Fixes issue 22596, whereby "_" is now not considered a word constituent
character in sql-interactive-mode, so prompts like "foo_dev# " are not
correctly detected.
---
 lisp/progmodes/sql.el | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/progmodes/sql.el b/lisp/progmodes/sql.el
index fd59f46..90c8dfe 100644
--- a/lisp/progmodes/sql.el
+++ b/lisp/progmodes/sql.el
@@ -462,9 +462,9 @@ sql-product-alist
      :list-all ("\\d+" . "\\dS+")
      :list-table ("\\d+ %s" . "\\dS+ %s")
      :completion-object sql-postgres-completion-object
-     :prompt-regexp "^\\w*=[#>] "
+     :prompt-regexp "^[[:alpha:]_]*=[#>] "
      :prompt-length 5
-     :prompt-cont-regexp "^\\w*[-(][#>] "
+     :prompt-cont-regexp "^[[:alpha:]_]*[-(][#>] "
      :input-filter sql-remove-tabs-filter
      :terminator ("\\(^\\s-*\\\\g$\\|;\\)" . "\\g"))
 
@@ -514,9 +514,9 @@ sql-product-alist
      :sqli-comint-func sql-comint-vertica
      :list-all ("\\d" . "\\dS")
      :list-table "\\d %s"
-     :prompt-regexp "^\\w*=[#>] "
+     :prompt-regexp "^[[:alpha:]_]*=[#>] "
      :prompt-length 5
-     :prompt-cont-regexp "^\\w*[-(][#>] ")
+     :prompt-cont-regexp "^[[:alpha:]_]*[-(][#>] ")
     )
   "An alist of product specific configuration settings.
 
-- 
2.7.1

Re: (unknown)

[Steve Purcell]

Sorry, messed up sending that patch by email, but it's hopefully helpful
nonetheless.

-Steve

(unknown)

[David Kastrup]

Unless objected to timely, I intend to push this change tomorrow.  It
should not affect current operation but brings Emacs' behavior for
synthesized Lisp events containing an "up-" modifier in line with the
current behavior of "down-" events.  Such events are not produced by
Emacs itself; no change in behavior for existing code is expected.

I have code that might eventually make it into ELPA that benefits from
these changes.

Re: (unknown)

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Unless objected to timely, I intend to push this change tomorrow.  It
> should not affect current operation but brings Emacs' behavior for
> synthesized Lisp events containing an "up-" modifier in line with the
> current behavior of "down-" events.  Such events are not produced by
> Emacs itself; no change in behavior for existing code is expected.
>
> I have code that might eventually make it into ELPA that benefits from
> these changes.

Ugh.  Sorry for the Subject line.  This concerns the patch in the
message with title:

[PATCH] Deal gracefully with up-events (Bug#19746)

-- 
David Kastrup

(unknown)

[Eli Zaretskii]

Bootstrapping master from the git repo, I see multiple error messages
like this:

  Eager macro-expansion failure: (error "Lisp nesting exceeds `max-lisp-eval-depth'")

Does anyone else see this?

Re: (unknown)

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Bootstrapping master from the git repo, I see multiple error messages
> like this:
>
>   Eager macro-expansion failure: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")
>
> Does anyone else see this?

Yes, I get the same thing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

(unknown)

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

Hi,

I'm a gnus newbie and using it for about two weeks in just one of my IMAP
mail accounts. I like it so far, but wonder at its marking system...

To the question: Does it make sense to not use gnus-ancient-mark "O"
completely? I want to see old marks that I laboriously set in previous
sessions, such as the gnus-del-mark "r" mark. It seems to be replaced by
"O" all the time.

If so how would I achieve this?

-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 621 bytes --]

Re: (unknown)

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> To the question: Does it make sense to not use gnus-ancient-mark "O"
> completely? I want to see old marks that I laboriously set in previous
> sessions, such as the gnus-del-mark "r" mark. It seems to be replaced
> by "O" all the time. 

"r" just marks stuff as read, and this isn't saved beyond that.  Any way
of marking stuff as read ends up in the same data set, so it's all
displayed as "O".

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: (unknown)

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

I see, so the difference between "r" and "R" is just for the current
"summary mode" session.

Curious, when does adaptive scoring kick in then? It does differentiate
between "r" and "R" doesn't it?

Thanks (and sorry for not including a subject, I stupidly forgot)
João

On Sat, Jul 6, 2013 at 4:22 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > To the question: Does it make sense to not use gnus-ancient-mark "O"
> > completely? I want to see old marks that I laboriously set in previous
> > sessions, such as the gnus-del-mark "r" mark. It seems to be replaced
> > by "O" all the time.
>
> "r" just marks stuff as read, and this isn't saved beyond that.  Any way
> of marking stuff as read ends up in the same data set, so it's all
> displayed as "O".
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog http://lars.ingebrigtsen.no/
>



-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 1610 bytes --]

Re: (unknown)

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> I see, so the difference between "r" and "R" is just for the current
> "summary mode" session.

Yes.

> Curious, when does adaptive scoring kick in then? It does
> differentiate between "r" and "R" doesn't it?

Adaptive scoring kicks in as you're leaving the summary buffer, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

(unknown)

[Eli Zaretskii]

Dmitry, could you please explain the reason(s) for the change below?

Vertical positions in a window can never be large enough to justify
using ptrdiff_t (on platforms where that is wider than a 32-bit
'int').  These are pixel positions on the Emacs display, so they
cannot be too large.  The type of 'first_vpos' looks especially
strange, since it is explicitly set to 1 at most.  I'm not aware of a
platform where an 'int' is not wide enough for a value 1 ;-)

Using inappropriate data types makes the code harder to read and
understand, because it hints that something non-obvious is going on
somewhere.

	 * xdisp.c (try_window_id): Change type of 'first_vpos' and 'vpos'
	 to ptrdiff_t.

  --- src/xdisp.c 2012-06-28 12:29:37 +0000
  +++ src/xdisp.c 2012-06-29 11:48:08 +0000
  @@ -17761,8 +17761,8 @@ try_window_id (struct window *w)
       {
	 /* Displayed to end of window, but no line containing text was
	   displayed.  Lines were deleted at the end of the window.  */
  -      int first_vpos = WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0;
  -      int vpos = XFASTINT (w->window_end_vpos);
  +      ptrdiff_t first_vpos = WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0;
  +      ptrdiff_t vpos = XFASTINT (w->window_end_vpos);
	 struct glyph_row *current_row = current_matrix->rows + vpos;
	 struct glyph_row *desired_row = desired_matrix->rows + vpos;