* Re: Update filename history after several actions [not found] ` <u8xxtqtpw.fsf@ID-24456.user.uni-berlin.de> @ 2005-10-04 5:02 ` Richard M. Stallman 2005-10-04 7:13 ` Tomas Zerolo 0 siblings, 1 reply; 9+ messages in thread From: Richard M. Stallman @ 2005-10-04 5:02 UTC (permalink / raw) Cc: emacs-devel I asked Would you like it if we changed find-file-noselect to put its argument into the history if it is not present? You responded: There should be all functions in the file-name-history that were edited in emacs, i.e. there were intentionally loaded t be edited or viewed by the user. So adding all file names at the level you suggest is not the right way, cause find-file-noselect can't decide whether the file was loaded to be edited or e.g. to be processed automatically. I suggest to add the file-name-history inclusion of file names at a more "upper" level in the call stack, as a result of a user oriented task. Doing this at a higher level would work, but it would be an ugly approach, requiring changes in many places. find-file-noselect has an argument NOWARN that probably ought to be--but isn't actually--provided as t by Lisp programs that visit files for their own reasons that users don't know about. It occurs to me that if we change these programs to pass t for this arg, which they should anyway, then if find-file-noselect adds the file name to the history if NOWARN is nil, it might give just the right results. What do others think of this idea? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Update filename history after several actions 2005-10-04 5:02 ` Update filename history after several actions Richard M. Stallman @ 2005-10-04 7:13 ` Tomas Zerolo 2005-10-08 0:04 ` Juri Linkov 0 siblings, 1 reply; 9+ messages in thread From: Tomas Zerolo @ 2005-10-04 7:13 UTC (permalink / raw) Cc: emacs-devel, Christoph Conrad [-- Attachment #1.1: Type: text/plain, Size: 484 bytes --] On Tue, Oct 04, 2005 at 01:02:26AM -0400, Richard M. Stallman wrote: [...] > find-file-noselect has an argument NOWARN that probably ought to > be--but isn't actually--provided as t by Lisp programs that visit > files for their own reasons [...] Sorry for the random and semi-offtopic nitpick -- but wouldn't be NOUSER or NONINTERACTIVE or something along these lines be a less misleading name? NOWARN suggests a (related but) different purpose to me. Regards -- tomás [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Update filename history after several actions 2005-10-04 7:13 ` Tomas Zerolo @ 2005-10-08 0:04 ` Juri Linkov 2005-10-09 18:16 ` Richard M. Stallman 0 siblings, 1 reply; 9+ messages in thread From: Juri Linkov @ 2005-10-08 0:04 UTC (permalink / raw) Cc: nospam, rms, emacs-devel >> find-file-noselect has an argument NOWARN that probably ought to >> be--but isn't actually--provided as t by Lisp programs that visit >> files for their own reasons [...] > > Sorry for the random and semi-offtopic nitpick -- but wouldn't be NOUSER > or NONINTERACTIVE or something along these lines be a less misleading > name? NOWARN suggests a (related but) different purpose to me. What about adding a new option with a list of command names compared in `find-file-noselect' with `this-command' before adding a file name to the history? Every package (e.g. dired.el, recentf.el) could add their own user-level command names to such a variable. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Update filename history after several actions 2005-10-08 0:04 ` Juri Linkov @ 2005-10-09 18:16 ` Richard M. Stallman 2005-10-10 6:14 ` Juri Linkov 0 siblings, 1 reply; 9+ messages in thread From: Richard M. Stallman @ 2005-10-09 18:16 UTC (permalink / raw) Cc: nospam, tomas, emacs-devel What about adding a new option with a list of command names compared in `find-file-noselect' with `this-command' before adding a file name to the history? Every package (e.g. dired.el, recentf.el) could add their own user-level command names to such a variable. That would be more cumbersome that any of the other alternatives we are considering. So I don't like it. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Update filename history after several actions 2005-10-09 18:16 ` Richard M. Stallman @ 2005-10-10 6:14 ` Juri Linkov 2005-10-11 14:46 ` Richard M. Stallman 0 siblings, 1 reply; 9+ messages in thread From: Juri Linkov @ 2005-10-10 6:14 UTC (permalink / raw) Cc: nospam, tomas, emacs-devel The simplest solution is to use the same method as employed by Recentf mode. It maintains the list of recently opened files, no matter what user-level command visited them, and doesn't include automatically processed files. It seems that users of Recentf mode are satisfied with its file list. So the same method could be used to add recently opened files to the file name history. To update the list of recently opened files, Recentf mode puts the function `recentf-track-opened-file' in `find-file-hook'. The following code does the same to add recently opened files to the history: (add-hook 'find-file-hook 'add-file-name-to-history) (defun add-file-name-to-history () "Add the name of the file just opened to the history." (when (and buffer-file-name (or (null file-name-history) (not (equal buffer-file-name (car file-name-history))))) (if history-delete-duplicates (delete buffer-file-name file-name-history)) (setq file-name-history (cons buffer-file-name file-name-history)))) -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Update filename history after several actions 2005-10-10 6:14 ` Juri Linkov @ 2005-10-11 14:46 ` Richard M. Stallman 2005-10-12 5:47 ` Juri Linkov 0 siblings, 1 reply; 9+ messages in thread From: Richard M. Stallman @ 2005-10-11 14:46 UTC (permalink / raw) Cc: nospam, tomas, emacs-devel The simplest solution is to use the same method as employed by Recentf mode. It maintains the list of recently opened files, no matter what user-level command visited them, and doesn't include automatically processed files. To update the list of recently opened files, Recentf mode puts the function `recentf-track-opened-file' in `find-file-hook'. How does that avoid recording files that are processed by Lisp programs that the user doesn't know about? If those programs use find-file-noselect, that would run find-file-hook, which would record the file name thus being processed. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Update filename history after several actions 2005-10-11 14:46 ` Richard M. Stallman @ 2005-10-12 5:47 ` Juri Linkov 2005-10-13 4:51 ` Richard M. Stallman 0 siblings, 1 reply; 9+ messages in thread From: Juri Linkov @ 2005-10-12 5:47 UTC (permalink / raw) Cc: nospam, tomas, emacs-devel > The simplest solution is to use the same method as employed by > Recentf mode. It maintains the list of recently opened files, > no matter what user-level command visited them, and doesn't include > automatically processed files. > > To update the list of recently opened files, Recentf mode puts > the function `recentf-track-opened-file' in `find-file-hook'. > > How does that avoid recording files that are processed by Lisp > programs that the user doesn't know about? If those programs use > find-file-noselect, that would run find-file-hook, which would > record the file name thus being processed. Recentf is quite an old package, and it seems its users are happy with the way it records recently opened files. Perhaps this means there are not many places where find-file-noselect is used for internal file processing (i.e. not intended for the users to know). In those places where such processing is required, a more preferable way is to insert the contents of a file into a temporary buffer. While I tried to run the code which uses find-file-hook I sent earlier, I noticed that often it adds too many file names to the history, even the files opened for editing (there were no file names left from internal file processing at all in my test). For example, I don't like that `next-error' adds every file it opens from the grep buffer. Also I don't like adding files visited in read-only mode by dired's "v" key. All this means that the question what file names to add to the history is rather a matter of personal preferences. A simple hook for `find-file-hook' is easy to put in .emacs. But even if this functionality will get into Emacs, I think it's better to leave the current default behavior (with only adding user input to the history) unchanged. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Update filename history after several actions 2005-10-12 5:47 ` Juri Linkov @ 2005-10-13 4:51 ` Richard M. Stallman 2005-10-13 14:10 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: Richard M. Stallman @ 2005-10-13 4:51 UTC (permalink / raw) Cc: nospam, tomas, emacs-devel Recentf is quite an old package, and it seems its users are happy with the way it records recently opened files. Perhaps this means there are not many places where find-file-noselect is used for internal file processing (i.e. not intended for the users to know). There are lots of them! Just search the Lisp sources for find-file-noselect. There are about 230 occurrences, and I think around 200 of them do something like this. Custom does it, bookmark.el does it, desktop.el does it, to list but a few. How does recentf interact with those packages? In those places where such processing is required, a more preferable way is to insert the contents of a file into a temporary buffer. That is definitely true. However, there are a lot of places to change--and it could be a difficult change, in places that alter the file and want to be careful not to lose it (places that use file-precious-flag). So I don't think that is a possible solution in the short term. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Update filename history after several actions 2005-10-13 4:51 ` Richard M. Stallman @ 2005-10-13 14:10 ` Stefan Monnier 0 siblings, 0 replies; 9+ messages in thread From: Stefan Monnier @ 2005-10-13 14:10 UTC (permalink / raw) Cc: Juri Linkov, tomas, emacs-devel, nospam > In those places > where such processing is required, a more preferable way is to insert > the contents of a file into a temporary buffer. > That is definitely true. However, there are a lot of places to > change--and it could be a difficult change, in places that alter the > file and want to be careful not to lose it (places that use > file-precious-flag). So I don't think that is a possible solution > in the short term. There's also the risk that the user has opened the file by hand with find-file in which case Emacs shouldn't modify the file without also updating the corresponding buffer. find-file-noselect takes care of that. Stefan ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-10-13 14:10 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87fys87vbv.fsf@ID-24456.user.uni-berlin.de> [not found] ` <E1EFXvj-00051R-HS@fencepost.gnu.org> [not found] ` <87r7br1rp9.fsf@ID-24456.user.uni-berlin.de> [not found] ` <E1EFtKY-0004Vy-2X@fencepost.gnu.org> [not found] ` <u8xxtqtpw.fsf@ID-24456.user.uni-berlin.de> 2005-10-04 5:02 ` Update filename history after several actions Richard M. Stallman 2005-10-04 7:13 ` Tomas Zerolo 2005-10-08 0:04 ` Juri Linkov 2005-10-09 18:16 ` Richard M. Stallman 2005-10-10 6:14 ` Juri Linkov 2005-10-11 14:46 ` Richard M. Stallman 2005-10-12 5:47 ` Juri Linkov 2005-10-13 4:51 ` Richard M. Stallman 2005-10-13 14:10 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.