Juri Linkov | 1 Dec 2007 01:32
Favicon
Gravatar

Re: M-! in dired-mode

> M-! runs `shell-command' in `dired-mode'.  However, I cannot figure
> when it runs on file under point and when without a file at all, it
> seems to be completely random.  I mean, the buffer prompt does
> unambigously say whether it will be run on a file or not, but that
> prompt itself varies for no apparent reason and I couldn't find
> anything in help...
>
> Can anyone enlighten me (or just point to correct info node)?

`M-!' doesn't operate on dired files, but ! operates on files under
point with the prompt displaying their names.  So there is a clear
distinction: `!' works only in dired on its files, and `M-!' is a global
command.  My latest week-old unconfirmed patches provide a default value
for the command `M-!': when it is called in a file buffer then the
default value contains the current buffer's file name.  But it could be
improved also in a way that if `M-!' is called in a dired buffer, then
its default value could be a file under point in dired.

--

-- 
Juri Linkov
http://www.jurta.org/emacs/
Juri Linkov | 1 Dec 2007 01:34
Favicon
Gravatar

Re: occur API change proposal

> I propose changing the occur API to allow an optional predicate
> function.  For example, this is useful to invert a regular expression so
> you don't have to run occur on the whole buffer matching everything,
> then limit the results.

The occur engine currently hard-codes the function call of
`re-search-forward'.  Instead of this, we could do the same
as is done already in isearch for customization of the search
function using a variable `isearch-search-fun-function', and
add a new analogous variable `occur-fun-function'.

Even though such a variable will be useful for other purposes,
no simple function will allow inverting a regular expression.
Implementing this feature requires significant modification in
the logic of the occur engine: either changing the algorithm to
call `looking-at' at every line (very inefficient), or recording
a position of the previous match and outputing lines between it
and the current position (not easy to customize).

--

-- 
Juri Linkov
http://www.jurta.org/emacs/
Juri Linkov | 1 Dec 2007 01:35
Favicon
Gravatar

Re: desktop.el: autosave?

> auto-save-hook could do this job.

I use in .emacs:

  (defun my-desktop-save ()
    (interactive)
    ;; `desktop-owner' is a new function in Emacs 22.1.50 to check
    ;; for conflicts between two running Emacs instances.
    ;; We don't want automatic saving in the second Emacs process.
    (if (and (fboundp 'desktop-owner) (eq (desktop-owner) (emacs-pid)))
        (desktop-save "~")))

  ;; Save the desktop every hour
  (run-at-time 3600 3600 'my-desktop-save)

But maybe instead of requiring putting this code in .emacs for
every user who want to save the desktop periodically, we should
add a new user option to desktop.el that specifies time interval
of auto-saving?  I think the default value of `auto-save-timeout'
is too frequent for a heavy function `desktop-save'.  And also
standard auto-saving mechanism works on files, but the desktop
doesn't keep the desktop file permanently visited.

> Date: Fri, 30 Nov 2007 14:08:07 +0000 (GMT)
> From: Reuben Thomas <rrt <at> sc3d.org>
> To: bug-emacs <at> gnu.org
> Message-ID: <alpine.DEB.0.99999.0711301407250.4037 <at> localhost.localdomain>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> Cc:
(Continue reading)

Drew Adams | 1 Dec 2007 02:09
Picon
Favicon

custom type tests

Does anyone know of code that deals with custom types in such a way that you
could test whether the type of a user option is compatible with a given
type?

For instance, if a variable `foo' is of type `regexp' and `bar' is of type
`color', I would want a test for compatibility with type `string' to return
non-nil for each, since a regexp and a color are strings.

As another example, if `foo' is of type `string', I would want a test for
compatibility with type (choice (const nil) string) to return non-nil, since
a string is in the union of all strings and {nil}.

Any existing code that deals with subtypes this way? Any code that deals
with custom type tests, other than just `custom-variable-type' and (get __
'custom-type)?

I'm looking for code that would allow flexible type tests - subtyping, if
possible (see above), but also not differentiating between types such as
(choice (const :tag "toto" nil) string) and (choice (const nil) string) or
between (choice (choice (const nil) string) and (choice string (const nil)).

Any pointers to pertinent code or doc are appreciated. Think of it this way:
Given a custom type, how can I find all user options that have that type (or
a compatible type, such as a subtype)?
Lennart Borgman (gmail | 1 Dec 2007 02:38
Picon
Gravatar

Re: custom type tests

Drew Adams wrote:
> Does anyone know of code that deals with custom types in such a way that you
> could test whether the type of a user option is compatible with a given
> type?
> 
> For instance, if a variable `foo' is of type `regexp' and `bar' is of type
> `color', I would want a test for compatibility with type `string' to return
> non-nil for each, since a regexp and a color are strings.
> 
> As another example, if `foo' is of type `string', I would want a test for
> compatibility with type (choice (const nil) string) to return non-nil, since
> a string is in the union of all strings and {nil}.
> 
> Any existing code that deals with subtypes this way? Any code that deals
> with custom type tests, other than just `custom-variable-type' and (get __
> 'custom-type)?
> 
> I'm looking for code that would allow flexible type tests - subtyping, if
> possible (see above), but also not differentiating between types such as
> (choice (const :tag "toto" nil) string) and (choice (const nil) string) or
> between (choice (choice (const nil) string) and (choice string (const nil)).
> 
> Any pointers to pertinent code or doc are appreciated. Think of it this way:
> Given a custom type, how can I find all user options that have that type (or
> a compatible type, such as a subtype)?

I do not know exactly, but the :match property of a widget has the 
function you need. Look in cus-edit.el and wid-edit.el how this function 
is built. It does not look very easy to find out however.
(Continue reading)

Lennart Borgman (gmail | 1 Dec 2007 02:57
Picon
Gravatar

Re: custom type tests

Lennart Borgman (gmail) wrote:
> Drew Adams wrote:
>> Does anyone know of code that deals with custom types in such a way 
>> that you
>> could test whether the type of a user option is compatible with a given
>> type?
>>
>> For instance, if a variable `foo' is of type `regexp' and `bar' is of 
>> type
>> `color', I would want a test for compatibility with type `string' to 
>> return
>> non-nil for each, since a regexp and a color are strings.
>>
>> As another example, if `foo' is of type `string', I would want a test for
>> compatibility with type (choice (const nil) string) to return non-nil, 
>> since
>> a string is in the union of all strings and {nil}.
>>
>> Any existing code that deals with subtypes this way? Any code that deals
>> with custom type tests, other than just `custom-variable-type' and 
>> (get __
>> 'custom-type)?
>>
>> I'm looking for code that would allow flexible type tests - subtyping, if
>> possible (see above), but also not differentiating between types such as
>> (choice (const :tag "toto" nil) string) and (choice (const nil) 
>> string) or
>> between (choice (choice (const nil) string) and (choice string (const 
>> nil)).
>>
(Continue reading)

Stefan Monnier | 1 Dec 2007 04:11
Picon

Re: invisible

> I don't know.  `line-move-ignore-invisible' is a user option (although I
> fail to see how it's useful).  `(global-)disable-point-adjustment' is not.

global-disable-point-adjustment *is* a user option.

> IIUC a user might want to set `line-move-ignore-invisible' to nil
> in order to have C-n/C-p stop at or near invisible newlines.  In order
> to make this possible I set `disable-point-adjustment' to t.  I do this
> because for this particular goal the adjustment step is too clever.  But
> I don't see how replacing the one by the negation of the other would
> solve the problem.

I must be missing something: the relationship is pretty obvious to me
since your code sets disable-point-adjustment to t (i.e. forces Emacs to
behave as if global-disable-point-adjustment were t for this one
command) if and only if line-move-ignore-invisible is nil.

>>> ! 	      (unless line-move-ignore-invisible
>>> ! 		;; Interactively, disable point-adjustment when
>>> ! 		;; `line-move-ignore-invisible' is nil.
>>> ! 		(setq disable-point-adjustment t))
>> 
>> Why not put this directly inside `line-move' so it's not duplicated?

> Because I wanted to emphasize that this is for interactive use only
> and `interactive-p' is tested in next-/previous-line.  If for whatever
> reason people want to use next-/previous-line in a function, they
> should be allowed to disable point-adjustment as they like.  But I do
> not have a strong opinion about this, let's see whether my patch DTRT
> at all.  As Richard mentioned earlier adjusting one thing here breaks
(Continue reading)

Stefan Monnier | 1 Dec 2007 04:16
Picon

Re: Fwd: Patch for sgml-mode.el

>> Does the patch below fix those problems?
> Well, it probably does, but does the incompatible change of allowing
> mode-name to be a non-string bring any benefits?

The obvious one: no need to manually recompute the string when one of
its constituents changes.  I.e. sgml-xml-mode does not need to know that
enabling/disabling it can change the mode-name from/to SGML/XML or
HTML/XHTML.  Cleaner code, more obviously correct.

If you look at what Ibuffer does with its mode-name, you'll see that it
might also benefit from using this feature (tho I guess using
mode-line-process could be better so that the annotations don't show up
in the buffer's mode name in buffer lists).

        Stefan
Stefan Monnier | 1 Dec 2007 04:17
Picon

Re: unused local variables

>> Right.  So you're OK with adding (defvar my-dynamic-var) in one of the
>> files but not in both?  Why is that?

> I'm not really opposing. I don't like warnings, nor programming errors
> caused by subtle interactions (or unexpected ones). Once again: I like
> lexically scoped languages (Scheme excluded).  I'm just not sure
> littering packages with (defvar var) or (declare-function function) is
> better.  It certainly doesn't look clean.

I can assure you that warning about unused vars will only require very
few extra defvars.

        Stefan
Drew Adams | 1 Dec 2007 04:48
Picon
Favicon

RE: custom type tests

> >> Does anyone know of code that deals with custom types
> >> in such a way that you could test whether the type of
> >> a user option is compatible with a given type?
> >>
> >> For instance, if a variable `foo' is of type `regexp'
> >> and `bar' is of type `color', I would want a test for
> >> compatibility with type `string' to return non-nil for
> >> each, since a regexp and a color are strings.
> >>
> >> As another example, if `foo' is of type `string', I
> >> would want a test for compatibility with type (choice
> >> (const nil) string) to return non-nil, since a string
> >> is in the union of all strings and {nil}.
> >>
> >> Any existing code that deals with subtypes this way?
> >> Any code that deals with custom type tests, other than
> >> just `custom-variable-type' and (get __ 'custom-type)?
> >>
> >> I'm looking for code that would allow flexible type
> >> tests - subtyping, if possible (see above), but also
> >> not differentiating between types such as (choice
> >> (const :tag "toto" nil) string) and (choice
> >> (const nil) string) or between (choice (choice (const
> >> nil) string) and (choice string (const nil)).
> >>
> >> Any pointers to pertinent code or doc are appreciated.
> >> Think of it this way: Given a custom type, how can I
> >> find all user options that have that type (or a
> >> compatible type, such as a subtype)?
> >
(Continue reading)


Gmane