"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> I would not dream of changing something as fundamental as string
> syntax for something as specific as filename handling, even if it were
> meant to be used on the GNU system.
Some sort of literal string syntax would also be very useful for
regul
If there exists a file named "~" in my ~/tmp/, I see funny things:
(expand-file-name (file-name-nondirectory "~/tmp/~") "~/tmp"), returns
=>/home/deego instead of /home/deego/tmp/~
That is a painful one. I am not sure what we could do to fix it,
other than make expand-file-name not
I get the error:
Debugger entered--Lisp error: (error "Constant symbol `:help' specified in
defvar")
(defvar :help (quote :help))
We used to defvar keyword symbols that way for compatibility with old
Emacs versions that did not have keywords as a feature. Since
packages continue d
The following patch to tooltip.el simplifies the standard value of the
tooltip-mode defcustom further than my original version.
The remaining `(fboundp 'x-show-tip)' is really necessary, even after
startup.
===File ~/tooltip.el-diff===
*** tooltip.el 04 Jul 2005 1
I have debug-on-error set to t. When I do an eval-buffer and there is an
undefined function:
(this-is-no-fun)
I get the error "Wrong type argument: stringp, nul
Does this fix it? (I installed a more elaborate patch.)
*** debug.el05 Jul 2005 00:45:47 -0400 1.90
---
[I sent this message a few weeks ago but did not get a response.
Could we get the discussion moving again?]
> I am not sure whether that relates to the suggestion I made:
>> I think that if we wrote a separate regexp for each kind of grep,
>> all together they would match a lot fewer
Question: How will users see/detect/understand this behavior? What will they
see in "Show initial Lisp expression"?
They will see an expression that recomputes the standard value
based on whatever conditions are relevant.
My approach, like the one Luc's original one, avoids the need
to co
(file-truename "~/tmp/~")
=> "/home/deego/tmp/~"
That is correct.
Yet, "~/tmp/~" is apparently the correct representation, as returned by
(directory-files "~/tmp" t)
They are both correct representations. However, I am surprised
that directory-files returns names using ~/. It
Sorry for the delay in reply, but it seems to me that using SetFile
would be easier, and more flexible.
(defun mac-set-creator-code-for-file ()
(call-process shell-file-name nil nil t shell-command-switch
(concat "/Developer/Tools/SetFile -c EMAx " buffer-file-name))
)
(add-hook 'after-sav
Doing this work is the only way to get the benefit, so let's do it.
If the solution below looks OK I will document it in the Elisp manual.
Other people will need to help with this, since I do not fancy
handling all 20-30 options, some of which I know nothing about, all
by myself.
I actually us
The following change:
* files.el (set-visited-file-name): Report the error
for "empty filename" earlier.
has problems.
Do `emacs -q -nbc'
C-x C-w
Call your new file "test", or whatever.
Result:
set-visited-file-name: Wrong type argument: stringp, nil
The small patch below fixes the proble
Drew Adams wrote:
Or what about just reusing keyword :initialize, perhaps redefining its
behavior to recognize this special case? After all, this is about
initializing the value. The case could be distinguished by supplying
:initialize with an argument `custom-initialize-set-runtime' (
I wrote:
> This patch to the CVS Emacs sources fixes the way that function
> x_calc_absolute_position() accounts for the Windows-drawn borders around
> a frame when converting a negative 'top or 'left parameter into the
> equivalent positive value.
I should have said what the symptom of the malfu
Some time ago, copyright years in a number of files were messed up
due to a misunderstanding of the policy.
Work was started to write a policy document, but it seems to have halted.
I am still waiting for Eben Moglen to respond to my repeated queries.
Until a clear policy is docu
Does setting gc-cons-threshold to a small value like 4000 increase the
likelihood of the crash? It's one of the things I try on sporadic
problems.
Remember that these crashes usually happen days or weeks apart. I
don't want to run in such a slow mode all the time, sorry.
_
Is it possible to tell Emacs not to interpret escape character in a
certain string? If I have something like this:
(setq str "some\thing\escaped")
Can this be changed without changing the literal so that Emacs takes
exactly what is in the string, without escaping any char
> However, as long as the (IMHO sensible) patches that Seiji Zenitani and
> I have provided (which only pertain to the OS X version) don't find their
> way into the core or get formally rejected with reasons given,
Mac-only patches are looked at only by the people that are interested
i
Richard M. Stallman wrote:
I would not dream of changing something as fundamental as string
syntax for something as specific as filename handling, even if it were
meant to be used on the GNU system. And since it is merely for the
sake of Windows, an unethical system that we aim to replace, the
Edward O'Connor <[EMAIL PROTECTED]> writes:
> A related issue that I *did* find disturbing: on recent versions of
> Fedora Core, the default Dired ordering interleaved dot-files with
> ordinary files, because of some DWIMish behavior of the underlying
> `ls' implementation. I added "setenv LC_ALL
[EMAIL PROTECTED] (Kim F. Storm) writes:
> Until a clear policy is documented, I would suggest that instead of
> the current _very incorrect_ copyright years, the previous list of
> (mostly correct) years is restored in the affected files.
...
> lisp/mh-e working Thien-Thi Nguy
(defvar rogue-var) ;; to silence the compiler for the next line.
(unless (default-boundp rogue-var) (setq rogue-var nil))
(defcustom rogue-var ...
...
:initialize 'custom-initialize-set
...)
Suppose we implement a keyword in defcustom that caus
(defvar rogue-var) ;; to silence the compiler for the next line.
(unless (default-boundp rogue-var) (setq rogue-var nil))
(defcustom rogue-var ...
...
:initialize 'custom-initialize-set
...)
Suppose we implement a keyword in defcustom that causes it to generate
all that.
Could those who are interested in Windows please discuss this
among themselves, not here?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Lennart Borgman <[EMAIL PROTECTED]> writes:
> In that example there are paths in MSYS format (ie unix
> format). However you can replace `pwd` with `pwd -W` and get those in
> w32 format. Then you get the problem I am thinking of. But thinking
> about it again this could perhaps be solved (worked
David Kastrup wrote:
I was thinking of an easier way of handling w32 file names. When
trying to build with MSYS it fails just because of the file name
Emacs got from somewhere is in w32 format.
What does "got from somewhere" mean? Could you provide an example?
Look under why you sh
I was wrong about MSYS "pwd -W". It actually gives the output in Emacs
w32 style. I can not remember what happened now then. I will have to try
again. Coming back.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo
What about my "real" question, about the tool-bar being "useless" on
MS Windows?
I do not use MS Windows, so I do not know. If you use MS Windows and
you actually can use the tool-bar, that part of the remark _must_ be
obsolete I guess. Maybe it still would turn on the tool-bar in other
si
Lennart Borgman <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>>>Is it possible to tell Emacs not to interpret escape character in a
>>>certain string? If I have something like this:
>>>
>>> (setq str "some\thing\escaped")
>>>
>>>Can this be changed without changing the literal so that Em
David Kastrup wrote:
Is it possible to tell Emacs not to interpret escape character in a
certain string? If I have something like this:
(setq str "some\thing\escaped")
Can this be changed without changing the literal so that Emacs takes
exactly what is in the string, without escaping any cha
[[Cc-ed on emacs-devel]]
I understand this is really not the right time for discussing new
feature development, but just a quickie:
Would anyone object if, for the multi-tty feature branch, we would
move towards autoloading/executing stuff in lisp/term/*.el in the
standard way instead of loading
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Is it possible to tell Emacs not to interpret escape character in a
> certain string? If I have something like this:
>
>(setq str "some\thing\escaped")
>
> Can this be changed without changing the literal so that Emacs takes
> exactly what is in th
>> Those customization variables can have a default value that lets them
>> cause different behavior only when under the Aquamacs theme.
>>
>> So I don't see this as a principal problem once themes work properly.
> Yes, but what about re-definitions of existing functions?
> Defadvice them and put
Is it possible to tell Emacs not to interpret escape character in a
certain string? If I have something like this:
(setq str "some\thing\escaped")
Can this be changed without changing the literal so that Emacs takes
exactly what is in the string, without escaping any characters?
_
Kim F. Storm wrote:
joakim <[EMAIL PROTECTED]> writes:
Im no expert on Cua mode, but I suppose the problem ought to be solveable
by adding mode specific hooks to change the keymaps of other modes
within the startup code of cua.el.
If you have specific suggestions, I can consider the
On 7 Jul 2005, at 15:20, David Kastrup wrote:
Making this process a bit easier, making it easier for the user to
undo some of these new 'defaults' by defining groups of
customizations in themes would certainly be desirable.
In Aquamacs, this is already the case for many customizations.
For so
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> On 7/7/05, Edward O'Connor <[EMAIL PROTECTED]> wrote:
>
>> I love how Emacs is a consistent environment across the various
>> operating systems it runs on, and would much prefer it for the
>> default Dired behavior to continue to be the same across
David Reitter <[EMAIL PROTECTED]> writes:
> I have implemented the single frame behavior (it takes more than
> OneonOne to do that), for example.
> And if I understand correctly what themes are supposed to do, I
> cannot but agree with you that the currently planned collections of
> customization
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> Is there anything left to do in order to turn on global-font-lock-mode
> by default? As far as I know it should be possible to do now.
>
> I have occasionally had crashes in Emacs that have been running for a
> while. I think there is st
joakim <[EMAIL PROTECTED]> writes:
> Im no expert on Cua mode, but I suppose the problem ought to be solveable
> by adding mode specific hooks to change the keymaps of other modes
> within the startup code of cua.el.
>
If you have specific suggestions, I can consider them.
--
Kim F. Storm <[EMA
On Thu, 07 Jul 2005 14:17:52 +0200, Lennart Borgman wrote:
>I agree to whole message. I have written EmacsW32 just for this above.
>It would be better if this idea was merged into Emacs. I think however
>that it has to coexist with themes in some way and perhaps themes can be
>the underlying st
Im no expert on Cua mode, but I suppose the problem ought to be solveable
by adding mode specific hooks to change the keymaps of other modes
within the startup code of cua.el.
/Joakim
LENNART BORGMAN wrote:
From: Joakim Verona <[EMAIL PROTECTED]>
If some windows users want emacs to be m
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Per Abrahamsen wrote:
> Thanks, but there are no buttons to push in Info?
There are plenty. All the cross references and menu buttons.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.or
LENNART BORGMAN schrieb:
> Interesting. I can see your point. However do you use w32? Do you not find it
> disturbing then that the ordering of files are different in Emacs than
> outside Emacs on w32?
> Maybe you never leave Emacs? But for newbies who are used to other apps under
> w32, would i
> From: "Drew Adams" <[EMAIL PROTECTED]>
> Date: Thu, 7 Jul 2005 15:53:58 -0700
> Cc:
>
> I don't think uid and gid will be too useful on Windows.
IMHO, they will be as useful as they are on Posix platforms; I don't
see any difference.
> Most Windows users will be on one-user (standalone, perso
Some time ago, copyright years in a number of files were messed up
due to a misunderstanding of the policy.
Work was started to write a policy document, but it seems to have halted.
Until a clear policy is documented, I would suggest that instead of
the current _very incorrect_ copyright years,
> Date: Fri, 08 Jul 2005 00:06:49 +0200
> From: Lennart Borgman <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> >>Since Emacs started its route much have changed. The users on different
> >>platforms now tend to request that applications adhere to what they are
> >>used to.
From: Joakim Verona <[EMAIL PROTECTED]>
> If some windows users want emacs to be more windows-gui consistent on
> their plattform, cant these changes go into Cua mode or something?
Yes, it is a good suggestion to use a global minor mode, but how should that be
done? Can the global minor mode key
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Peter Whaite wrote:
>
>>Why not just keep it simple. SPC scrolls. ENTER activates.
>>
I think its much more important that Emacs is consistent within itself
than that Emacs is consistent with some random gui.
So I think:
- Custom and Info should
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> This is one of between 20 and 30 (I forgot the exact number) options
> with a similar problem. Start `emacs -Q', do `M-x customize-rogue'
> and you get the list. If you choose "Erase Customization" for them in
> a Custom buffer, very unexpected things
Lennart Borgman <[EMAIL PROTECTED]> writes:
>>Why not just keep it simple. SPC scrolls. ENTER activates.
>>
>>
> Because I have several times pressed SPC instead of ENTER. I guess I
> will not be the only one - or I hope I will not be the only one. It is
> quite confusing and unexpected that t
50 matches
Mail list logo
