Re: none

Re: none

[Miles Bader]

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'

Re: none

[Sacha Chua]

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

Re: none

[Miles Bader]

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!

Re: none

[Sacha Chua]

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

Re: none

[Richard Stallman]

    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.

None

[Kenichi Handa]

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

None

[abrahamade]

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/

Re: none

[Kim F. Storm]

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

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: none

[Stefan Monnier]

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

Re: none

[Troy Hinckley]

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

Re: none

[Stefan Monnier]

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

Re: none

[Stefan Monnier]

> ("\\*.*\\*" 0 'dmp-face--fg:blue t)

Change the `t` above to `prepend` or `append`.


        Stefan

(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

Re: none

[Manuel Giraud]

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

Re: none

[Po Lu]

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

Re: none

[Eric Abrahamsen]

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.