Default save as file type
Volly
*.au3 file extension. When I do a File > Save As, I have to put in
***.au3 or the file will not have a file extension. How do I change
the lexer to do this, or is there some other tweak I need to do, or is
this just wishful thinking on my part?
Valik
Neil, I've thought of what I think is a solution to the problem Volly
brings up but before I spend time implementing it, I want to make sure
it falls under your "will accept a well written patch" criteria. The
idea is as follows.
- Add a new property "save.filter" or overload the "open.filter" to
populate the Save As dialog's filter (same semantics as the current
open.filter). I can go either way on which property would be used.
Assuming you like the idea in general I can implement whichever you prefer.
- Use an approach similar to Visual Studio 2008 (and probably all the
.NET versions) for automatically appending the file extension. What VS
does is automatically append the first extension in the active filter if
the file is being saved without an extension that appears in the filter.
For example, the C++ filter contains the extensions
"*.cc;*.cpp;*.cxx;*.tlh;*.tli". If you try to save a file called
"foo.bar" it would become "foo.bar.cc" since ".cc" is the first
extension in the list and ".bar" is not an extension in the list. If
you try to save a file called "foo.tlh" it would stay "foo.tlh" since
the tlh extension appears in active filter. Saving a file with an
arbitrary extension is only possible with the "*.*" filter active.
It appears that on Windows (the only platform I can code this for), it's
pretty simple to do the above. Is this something you would integrate
into core SciTE? I'm kind of tired of seeing the requests on the AutoIt
forum (and dealing with the issue myself) so I would like to work out a
solution to the problem.
--
- Valik
Frank Wunderlich
there was an property default.file.ext to define the extension for
saving, but this seems not to work anymore :(
i have thisd in my properties-file long time ago, it works, but in my
current test today it does not (sciteru 1.75.54). don't know if its also
deprecated in the original-version. its already in the documentation...
regards Frank
Neil Hodgson
> - Add a new property "save.filter" or overload the "open.filter" to
> populate the Save As dialog's filter (same semantics as the current
> open.filter). I can go either way on which property would be used.
> Assuming you like the idea in general I can implement whichever you prefer.
I'd expect users would be more likely to type an extension rather
than select from a list since the edit field is already being filled
in.
> If you try to save a file called
> "foo.bar" it would become "foo.bar.cc" since ".cc" is the first
> extension in the list and ".bar" is not an extension in the list. If
> you try to save a file called "foo.tlh" it would stay "foo.tlh" since
> the tlh extension appears in active filter. Saving a file with an
> arbitrary extension is only possible with the "*.*" filter active.
Multiple extensions are not that common on Windows so shouldn''t
foo.bar be treated as an explicit choice?
> It appears that on Windows (the only platform I can code this for), it's
> pretty simple to do the above. Is this something you would integrate
> into core SciTE? I'm kind of tired of seeing the requests on the AutoIt
> forum (and dealing with the issue myself) so I would like to work out a
> solution to the problem.
Something simple would be OK but this looks quite messy and
unlikely to be used.
Neil
Neil Hodgson
> there was an property default.file.ext to define the extension for
> saving, but this seems not to work anymore :(
default.file.ext was never supposed to do this - its role is to
specify the language properties used before the file has been saved
for the first time.
Neil
Valik
> Valik:
>
> I'd expect users would be more likely to type an extension rather
> than select from a list since the edit field is already being filled
> in.
>
> foo.bar be treated as an explicit choice?
>
I don't fully agree here. The idea is, the active filter automatically
appends an appropriate file extension. Since the active filter is
automatically set by the first filter in the property (same behavior as
open.filter and the Open File dialog), this has the effect of allowing
users to tailor their environment for the "most common need". For the
users I deal with, this is having ".au3" appended so they would place
the AutoIt filter first in the property (More specifically, Jos would
since he maintains the "SciTE4AutoIt" package). Other people who
developer primarily in C++ could set the C++ filter first. For people
who want explicit choices, set the All Files filter first. I don't
think people will need to do too much picking from the filter drop-down.
As for multiple extensions, look at C++, XML, plain-text files. All
these have multiple valid extensions that are commonly accepted. Never
mind any user specific extensions added onto the common ones. I, for
example, use a custom AutoIt file extension that is not officially used.
> Something simple would be OK but this looks quite messy and
> unlikely to be used.
I'm not sure if you mean messy internally or what's exposed to the user.
Internally, it's not going to matter, the premise remains the same.
Take the returned file name, check it's extension to see if there is an
extension (trivial with the information returned from GetSaveFileName(),
it's also trivial to see if the extension is in the filter). If not,
look up a default extension and append it (Either read a property or
pluck it from the filter). To be honest, implementation wise, I expect
my idea is only 3 or 4 lines more code to deduce the extension than it
is to read it from a property.
From the user-visible side, I don't see how it's messy, either. The
filter is visible in the dialog. This seems more intuitive to me than
having a non-visible property arbitrarily add a file extension. I think
the vast majority of users will fall in to two groups. Those who don't
care and take the functionality for granted, or those who read the
documentation, configure their own filter how they want and understand
how it works.
As for not using it, well, given that the current behavior is to do
nothing and people don't like the current behavior, I imagine it will
see use. At any rate, the thousands of users of the "SciTE4AutoIt"
package will directly benefit from it because we would set it up to
default to adding the ".au3" extension.
Anyway, I think the approach I've outlined simple, both in functionality
and in implementation. It also obeys the conventions set forth by a
tool that has already influenced a number of SciTE's features. If you
have a different approach, you'll have to outline it because I really
don't see how it can get much simpler. I'm sure some people would
suggest to overload the "default.file.ext" property but that's worthless
to me as I don't have that set to the file extension I /save/ to most
often. I don't see how adding a "default.save.ext" is any simpler than
giving the user full control over the save dialog, either.
It seems an impasse.
--
- Valik
Neil Hodgson
> I don't fully agree here. The idea is, the active filter automatically
> appends an appropriate file extension. Since the active filter is
> automatically set by the first filter in the property (same behavior as
> open.filter and the Open File dialog), this has the effect of allowing
> users to tailor their environment for the "most common need".
Do users commonly need .au3 added when an extension has been typed?
If I have been using AutoIt and then perform Save As "doc.txt" are you
really going to save the file as "doc.txt.au3"?
> As for multiple extensions, look at C++, XML, plain-text files. All
> these have multiple valid extensions that are commonly accepted. Never
> mind any user specific extensions added onto the common ones. I, for
> example, use a custom AutoIt file extension that is not officially used.
C++ and XML use different individual extensions rather than
multiple extensions such as .tar.gz as found on Unix. Is AutoIt
different with extensions like .script.au3 or .service.au3?
> I'm not sure if you mean messy internally or what's exposed to the user.
Its what is exposed to the user - it wouldn't do anything like what
I would be expecting it to.
Neil
Valik
> Valik:
>
>> I don't fully agree here. The idea is, the active filter automatically
>> appends an appropriate file extension. Since the active filter is
>> automatically set by the first filter in the property (same behavior as
>> open.filter and the Open File dialog), this has the effect of allowing
>> users to tailor their environment for the "most common need".
>
> Do users commonly need .au3 added when an extension has been typed?
> If I have been using AutoIt and then perform Save As "doc.txt" are you
> really going to save the file as "doc.txt.au3"?
>
>> As for multiple extensions, look at C++, XML, plain-text files. All
>> these have multiple valid extensions that are commonly accepted. Never
>> mind any user specific extensions added onto the common ones. I, for
>> example, use a custom AutoIt file extension that is not officially used.
>
> C++ and XML use different individual extensions rather than
> multiple extensions such as .tar.gz as found on Unix. Is AutoIt
> different with extensions like .script.au3 or .service.au3?
>
Ahh, I thought you did mean "multiple individual extensions", "not
multiple extensions one after the other". The answer is, "I don't think
so". However, this discussion is orthogonal to the issue at hand.
Users don't want to type an extension at all, they want it to default to
something sensible (for them, that being .au3).
>> I'm not sure if you mean messy internally or what's exposed to the user.
>
> Its what is exposed to the user - it wouldn't do anything like what
> I would be expecting it to.
>
> Neil
>
I've just checked Thunderbird, Firefox, Microsoft Office, Visual Studio
and another application. All of them automatically append a file
extension based on the selected filter. All of them do so even if the
user types in an extension. I didn't realize it, but seemingly lots of
applications (on Windows) do exactly what I'm suggesting and offering to
implement in SciTE. I never realized it until I just went looking for
examples. Hell, even Notepad does it!
So, maybe it's not what you expect, but it certainly seems that it's a
common practice on Windows. Even the most simple text editor in the
world, Notepad, does it. If that's not compelling enough, I don't know
what is!
At any rate, it's not like this is going to break anything, either. If
no filters are set, nothing happens. If the "All Files (*.*)" filter is
set, again, nothing happens. So there are certainly ways to avoid
automatically getting a file extension append with the approach.
If this isn't compelling enough information, then I give up. I must
admit, I didn't realize how common the practice was and I would never
have dreamed that even Notepad does it.
--
- Valik
Neil Hodgson
> Ahh, I thought you did mean "multiple individual extensions", "not
> multiple extensions one after the other". The answer is, "I don't think
> so". However, this discussion is orthogonal to the issue at hand.
> Users don't want to type an extension at all, they want it to default to
> something sensible (for them, that being .au3).
Some users, such as myself, do want complete control over file extensions.
> I've just checked Thunderbird, Firefox, Microsoft Office, Visual Studio
> and another application. All of them automatically append a file
> extension based on the selected filter. All of them do so even if the
> user types in an extension.
Visual Studio doesn't (just tried it) and its poor behaviour for a
general purpose text editor since it is common to be dealing with
different file extensions. This differs from applications where there
is mostly a preferred extension for a document type.
> So, maybe it's not what you expect, but it certainly seems that it's a
> common practice on Windows. Even the most simple text editor in the
> world, Notepad, does it. If that's not compelling enough, I don't know
> what is!
Utterly uncompelling - Notepad is not what I want SciTE to be.
> At any rate, it's not like this is going to break anything, either. If
> no filters are set, nothing happens. If the "All Files (*.*)" filter is
> set, again, nothing happens.
All Files is not the default filter: All Source is and the
extension that would be applied by default is .asm!
Neil
Valik
> Valik:
>
>> Ahh, I thought you did mean "multiple individual extensions", "not
>> multiple extensions one after the other". The answer is, "I don't think
>> so". However, this discussion is orthogonal to the issue at hand.
>> Users don't want to type an extension at all, they want it to default to
>> something sensible (for them, that being .au3).
>
> Some users, such as myself, do want complete control over file extensions.
Then don't set a filter, or set the All Files filter to be the default.
It's really that simple. You're saying "I won't accept this feature
because I don't want it" but nobody would be forcing you to use it. I
don't understand that perspective. What exists now is NOTHING. I want
to add an optional SOMETHING (that is not active by default) that does
what other Windows application do, what the users I deal with want it to do.
>> I've just checked Thunderbird, Firefox, Microsoft Office, Visual Studio
>> and another application. All of them automatically append a file
>> extension based on the selected filter. All of them do so even if the
>> user types in an extension.
>
> Visual Studio doesn't (just tried it) and its poor behaviour for a
> general purpose text editor since it is common to be dealing with
> different file extensions. This differs from applications where there
> is mostly a preferred extension for a document type.
>
What do you mean Visual Studio doesn't? Visual Studio 2008 most
certainly does exactly what I said. I also assert that SciTE *is* an
application where people use it with a preferred extension. For
example, there are several thousand users right now using it for nothing
but editing AutoIt scripts. I can't speak for others but I can
certainly speak for those several thousand.
>> So, maybe it's not what you expect, but it certainly seems that it's a
>> common practice on Windows. Even the most simple text editor in the
>> world, Notepad, does it. If that's not compelling enough, I don't know
>> what is!
>
> Utterly uncompelling - Notepad is not what I want SciTE to be.
I find that ridiculous, to be perfectly honest. I can't believe the
editor Jos (author of the AutoIt lexer, maintainer of SciTE4AutoIt) and
I managed to turn into an IDE is going to lack a feature Notepad can do.
>> At any rate, it's not like this is going to break anything, either. If
>> no filters are set, nothing happens. If the "All Files (*.*)" filter is
>> set, again, nothing happens.
>
> All Files is not the default filter: All Source is and the
> extension that would be applied by default is .asm!
>
> Neil
>
Now you're just making up reasons. I never said anything would be the
default filter. You seemed to have latched onto the musing where I
mentioned I could overload "open.filter" and just assumed that is
exactly what I would do and suddenly SciTE's default behavior would be
forever altered and it would become unbearably difficult to type a file
name with extension how you want.
This is obviously your program and your mind seems made up on the
subject. I must admit, I'm completely baffled at your "logic" in
rejecting the idea as it in no way affects people who don't elect to use
it (aka: You). I'm also a little puzzled why you aren't even trying to
work out a reasonable solution. You just continue to interject your
personal disdain for the functionality while offering no criticism or
insight into how to resolve the issue.
--
- Valik
Neil Hodgson
> Then don't set a filter, or set the All Files filter to be the default.
> It's really that simple.
Please state *exactly* what your proposal is.
> You're saying "I won't accept this feature
> because I don't want it" but nobody would be forcing you to use it. I
> don't understand that perspective. What exists now is NOTHING.
What exists currently works. Stating it is "NOTHING" does not
recognise that others have a different point of view.
> What do you mean Visual Studio doesn't?
If you give Visual Studio 2008 an explicit extension, then no
implicit extension is added.
> Visual Studio 2008 most
> certainly does exactly what I said.
That is not the behaviour that I see.
> Now you're just making up reasons. I never said anything would be the
> default filter. You seemed to have latched onto the musing where I
> mentioned I could overload "open.filter" and just assumed that is
> exactly what I would do and suddenly SciTE's default behavior would be
> forever altered and it would become unbearably difficult to type a file
> name with extension how you want.
If you don't fully explain the modification you are proposing then
I can only attempt to interpret those things you do say.
> This is obviously your program and your mind seems made up on the
> subject.
No. I am attempting to discuss the desired functionality with you
in order to solidify the proposal.
> I must admit, I'm completely baffled at your "logic" in
> rejecting the idea as it in no way affects people who don't elect to use
> it (aka: You). I'm also a little puzzled why you aren't even trying to
> work out a reasonable solution.
That is what I have been doing but you seem determined not to recognise that.
> You just continue to interject your
> personal disdain for the functionality while offering no criticism or
> insight into how to resolve the issue.
All 3 of my previous replies offered criticism.
Neil
Valik
specifically.
Neil Hodgson wrote:
> Valik:
>
> Please state *exactly* what your proposal is.
With the exception of "what property should I use", the idea *was*
fleshed out. I solicited for your preference on the name of the
property (something you have yet to answer and which is irrelevant now,
anyway). Outside of that, I don't know what other information you want.
So, let me try this again, and if you have any questions *ask them*.
- Add a new property, save.filter. Works just like open.filter except
it's for the Save As dialog (syntax is the same, the first item is the
default filter).
- The save.filter property is empty by default. This provides full
backwards compatibility. It must be manually populated in order to be
used. It is an opt-in feature unless you personally decided to
distribute SciTE with a pre-filled save.filter property.
- When saving with a filter active, the first file extension is
automatically appended unless the file has an extension listed in the
filter. This happens even if the user types an extension.
- The filter *.* will allow saving with an arbitrary file extension, no
default added. An empty filter also allows this.
- The feature will be Windows-only since I can not develop a GTK
counter-part.
Are there any questions?
PS: Visual Studio's behavior is more complex than I thought. You area
apparently typing an extension VS recognizes so it decides not to append
the default extension. In my test, I did not type something VS
recognized, so it did exactly as I described. I do not know what rules
VS uses, but I can see both behaviors now that I know how to invoke it.
--
- Valik
Philippe Lhoste
> I've just checked Thunderbird, Firefox, Microsoft Office, Visual Studio
> and another application. All of them automatically append a file
> extension based on the selected filter. All of them do so even if the
> user types in an extension.
I was sceptical but I must admit you are right. It is not what I
expected, if I type an extension, I expect it to be respected, not to
have a double extension.
> So, maybe it's not what you expect, but it certainly seems that it's a
> common practice on Windows. Even the most simple text editor in the
> world, Notepad, does it. If that's not compelling enough, I don't know
> what is!
Lol! Notepad is hardly an example to follow for anything!
Actually, I was surprised because this behaviour was often presented as
"brain dead" "feature" of Notepad.
Now, if it is an official or semi-official (from MS) behaviour of
Windows applications, I suppose SciTE should follow it.
I admit I haven't read your proposal, but here is what I would expect:
- By default, no change of behaviour: if I don't type an extension,
don't add one. If I type one, just keep it.
- If users choose so, they can set a default extension, possibly
depending on the current lexer. If so, the filter in the save dialogue
is set to that extension (showing only files of same type). If users
type an extension, SciTE would append the default extension anyway.
- Like in all the mentioned applications, if the file name+extension is
surrounded by double quotes (eg. "myfile.ext"), no change is made to
this name. This convention, even Notepad follows it!
Thus, everybody should be happy... =)
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
SteveD
> - If users choose so, they can set a default extension, possibly
> depending on the current lexer.
to implicitly set the extension to '.c'.
>If users
> type an extension, SciTE would append the default extension anyway.
be an
override? e.g. if I typed 'hello.cpp' in the Save As dialog, I would
certainly expect that to be respected.
Notepad's random attempts to add .txt to things is not a good thing,
IMHO.
Ah, the limitations of 'intuitive'!
steve d.
KHMan
> On Feb 22, 11:54 am, Philippe Lhoste <Phi...@GMX.net> wrote:
>> - If users choose so, they can set a default extension, possibly
>> depending on the current lexer.
>
> That would make sense. I would expect 'Save as' on hello.c
> to implicitly set the extension to '.c'.
>
>> If users
>> type an extension, SciTE would append the default extension anyway.
>
> That isn't intuitive to me. Surely supplying an extension is meant to
> be an
> override? e.g. if I typed 'hello.cpp' in the Save As dialog, I would
> certainly expect that to be respected.
I agree with Steve. I might need .cxx for a project; plus there
are so many kinds of C source files. This is not something I want
the editor to decide for me. However...
> Notepad's random attempts to add .txt to things is not a good thing,
> IMHO.
It would be okay if there is zero ambiguity. For a *nix person,
it's a pretty small win. I suppose Valik has a point, because some
projects I guess may be recommending SciTE out-of-the-box as
editors for their app, and some less experienced users will moan I
suppose when their UI experience breaks.
> Ah, the limitations of 'intuitive'!
Reading the thread discussion, I do see some kind of disconnect
somewhere. I tend to see SciTE as an editor for experienced users.
SciTE's behaviour is just nice for me, no surprises.
The problem is, perhaps a user like me (for example) is an
atypical Win32 user. Expert users will tend to choose to "show all
extensions" and probably "show hidden files" etc. for the shell
explorer. My usage experience is definitely different from that of
a less savvy user.
Would a user with "known extensions hidden" encounter problems
when creating files? Perhaps... Probably it would not matter to
users who are experienced programmers, but as Valik mentioned
IIRC, some Autoit users might have different expectations.
I dunno, perhaps others might like to weigh in on this...
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
Neil Hodgson
> - When saving with a filter active, the first file extension is
> automatically appended unless the file has an extension listed in the
> filter. This happens even if the user types an extension.
I do not see any benefit to adding an extension when the user has
already typed one.
Neil
Valik
I've just did a bit of research and discovered that my original proposal
is actually standard Windows behavior. Standard in that the API
GetSaveFileName() can be coaxed into doing it automatically. It even
includes the functionality mentioned Philippe Lhoste here:
> - Like in all the mentioned applications, if the file name+extension is
> surrounded by double quotes (eg. "myfile.ext"), no change is made to
> this name.
My proposed changes boil down to this:
- Add a new property, save.filter.
- Factor out the filter clean up code in SciTEWin::OpenDialog() to a
separate function.
- In SciTEWin::SaveAsDialog(), load the save.filter property, clean it
with the previously factored out function and pass it to
SciTEWin::ChooseSaveName().
- Modify SciTEWin::ChooseSaveName() to turn on the Windows standard
behavior.
- Document the Windows-only property.
Other than factoring out the filter-cleanup to a function, it's about 4
lines of code changes doing it this way.
--
- Valik
Neil Hodgson
> I've just did a bit of research and discovered that my original proposal
> is actually standard Windows behavior. Standard in that the API
> GetSaveFileName() can be coaxed into doing it automatically.
Since your proposal does not respect the user entering a full file
name including extension when a filter other than *.* is active, I
will not incorporate this into mainstream SciTE.
Neil
Philippe Lhoste
>> If users
>> type an extension, SciTE would append the default extension anyway.
>
> That isn't intuitive to me. Surely supplying an extension is meant to
> be an
> override? e.g. if I typed 'hello.cpp' in the Save As dialog, I would
> certainly expect that to be respected.
>
> Notepad's random attempts to add .txt to things is not a good thing,
> IMHO.
Actually, I fully agree, I don't need to be held by hand and I usually
supply the extension myself. Well, actually, I nearly never save a
buffer made from scratch, I usually create an empty file to edit instead...
But, it seems that's the expected behaviour in Windows, like it or not.
(I don't like it... ;-))
Now, perhaps it needs yet another properties to please experimented
users as well as newbies?
Valik
> Actually, I fully agree, I don't need to be held by hand and I usually
> supply the extension myself. Well, actually, I nearly never save a
> buffer made from scratch, I usually create an empty file to edit instead...
>
> But, it seems that's the expected behaviour in Windows, like it or not.
> (I don't like it... ;-))
>
> Now, perhaps it needs yet another properties to please experimented
> users as well as newbies?
>
The feature isn't actually as bad as it sounds. Further experimentation
shows it only adds an extension if you type in one not registered on
Windows (which is what I was doing in my tests, thus my mis-leading
thoughts).
At any rate, I no longer care. I have the feature in my version of
SciTE and in the very near future the users of the SciTE4AutoIt package
will also have it. I'm no longer interested in contributing to this
project so if anybody wishes to pursue this further, you'll be able to
find the incredibly minor changes I made in the future sometime once we
sort out how to distribute the source.
--
- Valik
mozers
> I usually code in AutoIt, and pretty much all my files end in the
> *.au3 file extension. When I do a File > Save As, I have to put in
> ***.au3 or the file will not have a file extension.
Choose extension at his creation.
This - only a variant.
> ---------------------------------------------------
--[[--------------------------------------------------
new_file.lua
----------------------------------------------
Replaces SciTE command "File|New" (Ctrl+N)
Creates new buffer in the current folder with current file extension
----------------------------------------------
Connection:
In file SciTEStartup.lua add a line:
dofile (props["SciteDefaultHome"].."\\tools\\new_file.lua")
--]]----------------------------------------------------
local function NewFile()
local newfile_path = props["FileDir"].."\\NewFile"
local newfile_ext = "."..props["FileExt"]
if newfile_ext == "." then newfile_ext = props["default.file.ext"] end
newfile_path = newfile_path..newfile_ext
-- warning disable:
--~ io.output(newfile_path) io.write("") io.close()
scite.Open(newfile_path)
return true
end
-- Add user event handler OnMenuCommand
local old_OnMenuCommand = OnMenuCommand
function OnMenuCommand (msg, source)
local result
if old_OnMenuCommand then result = old_OnMenuCommand(msg, source) end
if msg == IDM_NEW then
if NewFile() then return true end
end
return result
end
> ---------------------------------------------------
--
mozers
<http://scite.ruteam.ru>